Mike Cohn专栏
敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项（Product Backlog）中的特性描述文字，来替代传统长篇大论的需求文档。
我们发现用户故事是最好的描述方式，这种形式能够捕获到特性足够多的信息，并促进产品负责人和团队在后续进一步交流。用户故事是从人（通常是系统的用户或者客户）渴望新功能的视角来对特性进行描述。
用户故事一般会采用以下这种简单格式进行描述：“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性，但只要能围绕着故事进行交流，用户故事可以以任何形式进行描述。
Read more →
很多项目都不会一开始就完全就绪——例如，需要分配人员和准备工作。为了处理这些项目开始前的任务，很多团队使用了“迭代0”的做法。虽然理解其由来，但我仍然感到担心。以下是我的理由。
停止“迭代0”的三个理由：
首先，尽管很难相信，但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有：需要组建团队，包括调配人员到项目上或雇佣新人；需要获取或者设置硬件设备；需要写一个初始的产品待办列表（即使只是高度概要的）。然而现实情况是：诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成（一个完全是正常的和传统模式的迭代一），同时至少还可以交付了某些潜在可发布产品增量。
Read more →
尽管我尽了最大努力来澄清，但是仍然流传这样一种说法：故事点数是对复杂度的度量。这种说法是完全错误的。真相是，除非复杂度已经对完成用户故事的工作量造成影响，否则其复杂度并不重要。
让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟，而我因为正拄着拐杖所以需要走10分钟。
你和我不能在花费时间上达成一致。对你来说走5分钟是对的，而对我来说走10分钟也是对的。如果采用分钟、小时、天等时间单位进行估算，问题就会比较棘手——由于我们处于不同的生产率水平，这会导致我们无法在估算上达成一致。
Read more →
很少有Scrum文献会说每日站会需要按团队成员逐个发言。然而大多数团队恰恰都是这样做的，但这可能不是最好的方式。
当每日站会是逐个团队成员进行的时候，团队成员会很容易丢掉所讨论的待办事项的上下文。例如，可能第一位团队成员正在处理前两个产品待办事项，第二位团队成员正在处理第二个和第五个产品待办事项，第三位团队成员也在处理其中这些待办事项中的一个，同时花费少量精力处理另一个无人的待办事项。
Read more →
几周前，我参加了一个很痛苦的迭代计划会。类似的会议你可能也参加过，团队竭尽所能试图分析出本次迭代所要完成的所有任务，并就每一个任务具体需要花费多少小时进行无休止的争论。
然而这种级别的细节讨论其实是不需要的。
迭代计划会的目的是从产品列表中挑选出本次迭代要完成的条目，并对如何完成有一个大致的想法，达到这个目的并不需要团队了解每一个任务，当然更不需要团队知道某个任务是需要花费4小时还是5小时。
Read more →
我偶尔会听到一些比较冒失的言论—在sprint结束时还遗留了未完成的工作是非常糟糕的，应该严格禁止。 我能理解未完成工作的危险性，也从不反对敏捷宣言中关于可工作软件的价值观，但是，我还是要说这个言论是错的。 真正危险的不是未完成的工作，而是未完成工作的不断累积。 Read more →
本文给出了一套用于思考如何设计一个合理的团队结构的指导原则。每一个指导原则，以向现有团队或者拟议的团队提出一个问题的形式出现，并且这些问题需要迭代地询问。询问现有团队或拟议团队每一个问题后，根据答案改变团队结构；当团队结构改变后，重新再询问，直到对于每一个问题，你都可以回答“是”。
Read more →
我在之前的帖子里曾写过对sprint进行编号除了用数字之外还有其他选择吗？今天这篇帖子我来说说一些团队给sprint编号时使用的的一个非常特殊的数字—0。
Sprint0这个概念在有些团队中变得越来越常见，所以我们很有必要来思考一下它到底是不是个好的提议。 Read more →
推广有三个目标。第一，为接下来的ADAPT周期的传递打好基础。通过宣传现在的成功，对创造新一轮的改善意识会有一个跳跃性的开始。第二，通过传播其他团队获得的一些好的消息，加强现有团队的敏捷行为。最后是第三个目标，在直接参与Scrum实施的群体之外创造敏捷意识和兴趣。许多这样的群体如人力资源、销售、市场营销、运维和设备，可以对你的成功转型产生非常重要的影响。在转型阶段，你要积极跟进，确保这些团队不会把开发组织从敏捷思维中拉回来。
Read more →
