“敏捷”不是第一次听说了，但是和“生态”联系在一起却是很新鲜。这次的主讲者陈勇，是TechExcel中国区咨询总监，和以前多次请来的专家不尽相同，给人感觉相当能够调动与会者的情绪，很生动，很吸引人，一定是有过多年的培训经历。

今天的内容主要围绕着敏捷实践展开的，颇为受益，借此机会感谢陈勇，也感谢老谷。要点如下：

很多公司从传统方式转为敏捷开发时，由于自身限制而无法整体实现敏捷：

1、团队有明确分工，看到需求就知道是谁的。

2、成员自己估算自己的任务

问题出来了，既然要敏捷，那么2是一定要破除的，一定要让大家自己估算自己的任务，这样才能实现承诺，进而激励工作效率。敏捷要求团队尽量弥合分工，尝试一起做估算。

Scrum计划尝试解决R问题和D问题

所谓R问题就是：这个需求说的是什么？实现到何种程度？标准如何？0缺陷吗？等等。这个是需求问题。在Scrum计划会议的上半截，Product Owner要给大家统一讲解需求，有问题的人随时提问。剩下的事情是：谁会有问题？当然是任务的负责人。而我这个客户由于前面说的原因，提问的人就一个人，自然也只有他彻底明白了任务的需求，而其他人事不关己，高高挂起。有时其他人也听到了一些有有疑惑的东西，但既然负责人都说明白了，我还要问什么呢……也就不问了，就埋下了隐患。

计划的第二个问题，是D问题（设计问题）：这个需求用什么方法实现最好？有没有现成的代码可以复用？完全复用，还是需要改动一下，还是改动也没用因为留有后遗症？可惜程序员都不擅长言谈，计划会议上也难以让他把整个实现思路讲一遍，这时候，就需要用别的方法了。每天早上20分钟给大家讲讲需求和设计，然后挨个问一个问题：你今天听了需求和设计，打算写多少代码？他们就用手比划：2个屏幕，还是5个屏幕。如果我感觉和我想的差不多，就过；如果差别很大，就问问屏幕里边有什么。用这种方法，只要几秒钟，就能对上暗号，“多半”他没有听错想错，也不会做错。

好了，R问题和D问题都解决了，剩下的是：刚才说过，任务都有一个负责人，别人怎么才能替他关心他的R和D问题呢？在那个客户那里，采取了两次步骤。前几个迭代，小组长（手底下有3/4个人）和那个人一起打牌（计划扑克），也就是让小组长和手下具体负责人一起计划后几个迭代：先把任务分配到小组（3/4个人）不指定具体负责人，先估算，再分配。这样大家不确定是否是自己的事情，不敢怠慢，都会用心得提问需求问题，用心地讨论实现方法，讨论过程中很快发现，有些需求没有想到，有些方法是错误的。当然，大家用计划扑克的方法，如果大家数字相同，不会讨论直接通过，有人太多或者太少，才会讨论。这样大大节约了时间，又达到了目的。另外，如果有3个人一起估算，这时候就会产生“同行压力”，没有人想证明自己是“笨蛋”，所以他们不会故意高估任务，因为自己的同事（技术背景/职位相同）在和自己一起估算，别人说2天能完，自己偏说4天，显然有问题。要知道这个工作还没有分配，未必是自己的工作。这种同行压力效果比领导压力好。

通过刚才的例子，我们会发现敏捷这里就直接说Scrum把：是一个经过实践总结出来的方法

他们当年也一定遇到过类似的问题，所以才说：尽量不分工，而是建立跨职能团队，“所有人干所有事”，才能取得良好的计划效果。如果把跨职能团队去掉，仍然开计划会，仍然有PO，仍然让大家自己估算自己的任务，效果就很差了。这就如一个生态系统，各个部分是联动的，不能轻易去掉其中一个。了解了生态系统，就会知道：要上敏捷，尽量完整地接受敏捷，而不要卡在中间，效果不会很好的。

敏捷中计划扑克的玩法是这样的：

1. 讲解需求和提问，直到没有问题

2. 几个人一起扣着出牌

3. 翻牌，最多的和最少的PK，除非他们差别很小

4. 大家听他们两位PK（一般一位会“占理”一些），回到2

5. 中间有任何对需求的分歧，PO解释（有时候PO也解释不清楚，这个需求显然还太模糊）

在这个过程里边，人们显然不愿意故意高估或低估（PK中很难给大家一个满意的答案的），而寻求真是结果的愿望会占据上风。这其实就是Delphi的变形，Delphi也是匿名的，但是太慢了。

特别喜欢计划扑克这个概念，我想即使不使用敏捷，这个方法对于任务估算也是非常有用的，充分发挥团队的作用，避免产生歧义的返工，大大的提高效率。

另外，我自己也有些问题没来得及请教，如果甲方要求乙方使用敏捷开发，对乙方应该有些什么要求呢？甲方自身应该具备什么样的条件呢？

ITPub博客

8.25 ITPUB在线交流——敏捷生态

最新文章