敏捷开发一千零一问系列之二十七：各自分工下如何扑克牌估算？

问题

原问题摘录以下：

开发组中可能同时进行几个专项开发，那么就有人参与这个专项，不参与另外一个专项。
那么扑克估算的时候，针对某一专项的任务，要怎样作，是不是开发组全部人员都参加评估，仍是这个专项相关的人员才参与？

可能一个专项就一两我的来作，专门估算，跟单独拍脑壳差异不大；
若是你们一块儿估算，存在效率很低的问题；
 

分析

估算的目的是什么？

在估算以前，一个很是重要的必定要问本身的问题是：估算的缘由或目的是什么？

估算有不少缘由，但实际上有些不太经得住推敲，或者说若遇到有人喜欢杠头，则很难反驳。好比：

1. 为了知道多少行代码能够完成（若是用代码行估计）。

杠头：不管知道是1000行仍是不知道，作完了一数都是1000行，为何要提早估计呢？（这个是我8年前被问到的一个问题）

2. 为了知道多久才能完成，以便作计划。

杠头：咱们计划都是反推的，领导说多久，咱们就作多久，估算有什么价值？

……

那么有哪些估算是完好缺乏或极具价值的呢？大体有两种。

1. 在报价/合同发生以前的估算

若能在此之间完成估算，就能把握商务的主动。即便“被迫签定合同”，作到“内心有数”仍是要好不少。

这个属于早期造价估算，之后再详述，但能够参考http://cheny.blog.51cto.com/3988930/1102202。

2. 能改善结果的估算

若是以前觉得要1000行——并且直接作也真的要1000行，结果估算完了发现只要100行，就很值得估算。

若是以前觉得要100天——并且直接作也真的要100天，结果估算完了发现只要10天，也很值得估算。

这个是扑克牌估算的最佳应用场景。

预备活动

原理

估算能改善估算结果的原理是：经过沟通共享信息，从而下降浪费。

通常而言浪费活动有两种：

1. 需求理解错误形成的浪费

在估算中，经过不一样的人、不一样侧面的问题，来抽丝剥茧发现需求的真相，能够有效避免这种浪费。

测试人员和开发人员共同估算，是一种弄清楚需求的常见方法。尤为是开发人员，因为常常深刻内核，因此经常听到一点点需求，就想固然地理解为本身曾经想过的一个相似需求，而后急于思考实现方法。

2. 实现方法错误/重复形成的浪费

一种是重复代码，从新发明轮子……；

一种是错误实现，好比曾经有人因为不擅长使用“模板”（就是泛型），而把1个函数写成65个；

一种是蛮干，好比曾经有人为了图省事使用硬编码来实现码流打包拆包，结果码流在接下来的日子里不断变化，结果骑虎难下，2个月的工做由于质量低下而被扔掉，2周就从新设计编码结束了。

……

水平不一样、负责不一样部分的程序员充分沟通、共同估算能够避免这些状况。尤为是高手、老手，能够提醒新手避免犯错。

浪费与反浪费

必须意识到一点，尽管估算能够防止浪费，估算自己也要花费时间，所以要思考估算的效率。

提升效率的方法包括：

1. 若无必要，不牵涉太多人员进行估算

139团队是一种方法，就是若是咱们有13我的，那么尝试分为3组，每组有4我的，这四我的是基本估算单元。他们应该负责类似的功能，平时也坐在一块儿，所以沟通起来比较顺畅。

2. 尝试使用较大的颗粒度

经常据说有敏捷开发实践者把任务且分到2小时左右的，甚至有0.5小时的。这里不直接说应不该该切分，而是提醒一下：4我的吵吵15分钟，就是1小时。咱们能够花费1小时，但必定要知道得到了什么，若是真的值得，就去作；若是不值得，就换大一点的颗粒度。

3. 尝试更快速的估算方法

扑克牌估算就是一种很快速的方法了，由于若是出牌数字相同，基本上就不讨论了（若是第一次就相同，推荐让一我的说一下，其余人没有太大的不一样意见就过）。

方案

分析清楚了，方案就比较好写了。

方案1最容易实现但效果也最很差，后面的则效果好但实施起来更费劲。

方案1

在彻底一贫如洗历来没有估算过的团队，若是他们原本业务也是各自负责一块，建议先以“技术相同”为条件拉几我的在一块儿估算；若是这几我的平时就坐在一块儿更好，能够在平时补充一些会上讲不到的地方。

在公开课课堂训练这种完全“强分工”的环境下，我发现只要技术说的通，两家公司的人均可以在一块儿估算的，况且一个团队的小组内部。但前提是产品经理要能说明需求。

不过初期必定会发现估算很花时间，由于初次估算的时候不少背景知识都不知道，甚至那位直接负责此事的人也说不清楚，因此沟通的成本比较高。若是你们月月都花上一天讨论，很快就能够避免对基本背景知识的交流了。

刚开始的两三个月，不用太强求有何效果，你们互相理解了背景，就是个效果。

方案2

一点点创建有固定组织结构的小组，而后把估算组与小组绑定。

139团队是一种，其实即便简单任命一个小组长而后带领其余3～4我的开发某种东西，就能够称之为一个固定的小组了。

固定的小组应该开发相对接近的功能（技术是否相同反而次要），即便技术不一样也能够从不一样的角度提出本身的见解。有不少人认为，若是我不懂某个技术，就说不出来那部分的开发要多久，这个其实不对。若是我距离那我的不到5米远，咱们在开发同一个模块的不一样部分而已，他用的技术也不涉及广义相对论之类的很费解的内容，人们就没有理由对某个技术“说不什么意见出来”，尤为是小组的组长。

在01年的团队中，咱们的25人的部门经理基本上参加过每一个小组的开发，包括相似机顶盒这样的和PC彻底不一样的开发平台。当时机顶盒小组发现代码里边有一些难以处理的缺陷，他就过去“顺便帮忙”，结果是发现整个代码过于混乱，因而用了两周他就重构了整个机顶盒里边的代码结构，在C环境下实现了接近C++的面向对象结构。固然要作到这一点须要至关天才的人。但若是只在3～4我的的范围内，这件事情就不那么复杂，人才也不须要太好。

方案3

创建L型代码结构。L型代码结构具体状况请参考松结对编程系列中的相应文章（大约第9篇左右开始，当前有三篇）。

我如今和程序员也“分工”，估算虽然不作（如今只有两我的，沟通太多了因此前面提到的估算的第二个目的早实现了），但给他布置任务的时候，会讨论每一个方法的实现方法。主要的讨论内容，是告诉他两样东西：

1. 整个业务过程相似我编写过的哪一个部分，能够做为总体过程的参考（通常集中于View/Controller两个层面）。

2. 可能用到哪一个底层类和函数（集中于Model，咱们的Model库占总代码量的67%，多数是我在编写个人上层应用时顺便写的，他也作过维护）。

第二部门有时候我不会主动交流，由于看过1以后基本上就能看出来，有疑问时再交流。

L型代码给估算带来了几个变化：

1. L型代码的高层调用过程很是容易理解，所以关于“如何实现”的讨论比较简单，不用涉及太深的底层实现。

2. 很容易找到类似业务的模块作参考。

咱们平均一个Controller大约有5～10个函数（好比“用户”的增删改查等操做：UsersControler.Index/Details/Create/BatchCreate/Delete/Freeze/Edit），每一个函数的代码量是4～5行，因此若是要学另一种东西的增删改查全过程，看完这50行代码就能大概了解整个过程了。

3. 因为底层库都用过，很容易找到使用样例（用IDE搜）。

4. 每次讨论的时候，会发现须要扩展一些底层库还没有实现的功能，不管谁最终实现它们，讨论过程两我的都知道要多这个功能了，对将来充分复用颇有帮助。

不过，L型代码要完全造成相对困难，对“顺便”产生底层库的人要求比较高。

 

固然最后一个问题：“大家不但不打牌，还甚至不估算，这算敏捷吗？”

怎么说呢，这么久以来，咱们没有由于新人参加而发生从新发明轮子的事情，代码也没有由于新人来了而发生迅速增长或质量降低，人们知道代码中发生的几乎全部重大变化……目的达到了，过程就不重要了。