Mike Cohn专栏

Scrum_tp2

如何克服每日Scrum会议的四大常见反对意见

/分类： /编辑：

我完全理解一些团队成员对参与每日站会的抵制。我也不喜欢开会。但有些会议是有用的，值得花时间投入。我把运行良好的每日站会归入此列。

在本文中，我将分享如何应对每日站会的四条常见异议。然后，我将分享运行良好的每日站会的一些特性，这能使其不被与会者抵制。
Read more →

Scrum_tp3

组织敏捷转型常见的六大误解，你知道几个？

/分类： /编辑：

组织会出于多种原因而采用敏捷方法。一些组织希望能提高生产率和缩短产品上市时间，另一些组织希望能够获得更成功的产品，还有一些组织希望能增强开发人员与业务人员间的协作，以提升质量或提高团队成员的工作满意度。

当然，还有许多组织采用敏捷是希望能同时实现这些好处的组合。

但是，为了能从敏捷中尽可能多地获得好处，组织似乎也存在很多误解。在本文中，我想谈谈关于敏捷产品开发的六个误解。
Read more →

产品负责人

是时候取消Scrum的产品负责人角色了吗

/分类： , /编辑：

Scrum只有三个正式角色：Scrum Master、产品负责人和团队。对于程序员、测试人员、数据库工程师、分析人员、设计人员等角色，并不加以区分。

例如，测试人员也只是团队成员之一。测试人员与其他团队成员共有同一个职责：在冲刺结束时开发一个潜在可发布产品增量，以实现冲刺目标。

在每位团队成员帮助团队实现这一目标的方式方法上，会存有差异。测试人员会尽可能地从冲刺待办列表中选取测试工作，而设计人员则会选取设计工作。
Read more →

Scrum

ScrumMaster指南：Scrum Master的情景领导力模型

/分类： /编辑：

作者：Mike Cohn

译者：李洁（Jerry Li）

审校：廖靖斌（Eric Liao）

本文由Mike Cohn授权翻译，未经许可请勿转载

 

几年前，我把几个高尔夫球打到湖里了，一起打球的朋友给了我一些建议。现在那位朋友打高尔夫球已经不比我强了，但他仍在没完没了地建议。他说：“问题是，你得把球打得更远。” 他这样说还不如告诉我，“问题是，你打了很多次才把球打进球洞。”  我当然需要打得更远。但怎么做到呢？

类似的，你们可能也被告诫过——ScrumMaster、敏捷教练或敏捷项目经理都可能告诫你——敏捷项目管理是要领导团队而非管理团队。

Read more →

Scrum_tp

团队需要Scrum Master做这六件事

/分类： /编辑：

我一直在和你的团队交流，好吧，可能不是你正在带的团队，而是很多和他们类似的团队。这些团队跟我分享了他们期待Scrum Master做的六件事情。

1. 帮助他们理解职责边界

敏捷团队被告知他们是自组织的。但是，这并不意味着每个企业的自组织都完全一样。比如说：

  • 团队是否有权将团队的技术需求添加到Sprint中？
  • 团队是否可以决定谁在这个团队中？
  • 团队是否可以在不询问Scrum Master的情况下改变他们的Sprint长度？
  • 在未经许可的情况下，团队可以在工具、团建活动或任何其它事情上花多少钱？

等等等等，这个列表可以无限长。
Read more →

Scrum_TP

给Scrum Master的十个建议，你值得拥有

/分类： /编辑：

你想成为一个优秀的Scrum Master吗？

我想是的，除非你是一个产品负责人或者其他的角色。我作为一个Scrum Master已经有20多年了，这些年，我给出了很多很多的建议，也收到了很多建议。我甄选出了我认为最棒的十个建议给大家。

1. 如果没有和团队商议，请不要代表团队做任何承诺。

作为一个Scrum Master，你没有任何权利代表团队接受需求变更，不管它有多小。即使你可以完全确定团队可以搞定它。你可以这么来回答：“我需要和团队沟通后再确认是否可以接受。”
Read more →

scrum会议

Scrum团队的会议太多了吗？

/分类： /编辑：

在进行CSM（认证Scrum Master）授课时，我听到的最常批评之一是“Scrum团队有太多的会议了”。

由于Scrum具有每日Scrum站会、Sprint计划会议、Sprint评审会议、Sprint回顾会议，甚至可能还有产品待办列表精化会议，也就不难理解为什么人们会这样评论。

但是让我们看看这是不是真的。
Read more →

Scrummaster

Scrum Master角色可能消失吗？

/分类： /编辑：

当一个团队逐步成长的时候，Scrum Master投入的时间越来越少，但是一个团队可以完全没有Scrum Master吗？

Scrum Master通过教练、指导、引导团队，使得他们的团队开发出伟大的产品。对一个初次接触Scrum的组织中的一个新的团队而言，这是一个具有挑战性而且耗时的工作。
Read more →

scrumcn_userstory

用户故事，史诗故事和主题故事

/分类： , /编辑：

敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项（Product Backlog）中的特性描述文字，来替代传统长篇大论的需求文档。

我们发现用户故事是最好的描述方式，这种形式能够捕获到特性足够多的信息，并促进产品负责人和团队在后续进一步交流。用户故事是从人（通常是系统的用户或者客户）渴望新功能的视角来对特性进行描述。

用户故事一般会采用以下这种简单格式进行描述：“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性，但只要能围绕着故事进行交流，用户故事可以以任何形式进行描述。
Read more →

Scrum中文网

反对迭代0：停止拖延，开始迭代

/分类： , /编辑：

很多项目都不会一开始就完全就绪——例如，需要分配人员和准备工作。为了处理这些项目开始前的任务，很多团队使用了“迭代0”的做法。虽然理解其由来，但我仍然感到担心。以下是我的理由。

停止“迭代0”的三个理由：

首先，尽管很难相信，但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有：需要组建团队，包括调配人员到项目上或雇佣新人；需要获取或者设置硬件设备；需要写一个初始的产品待办列表（即使只是高度概要的）。然而现实情况是：诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成（一个完全是正常的和传统模式的迭代一），同时至少还可以交付了某些潜在可发布产品增量。
Read more →