写在前面
曾经有个聋子看人放炮仗，说，怎么好好地一个花纸卷，放地上，一会儿说散就散了呢？因为他的感官缺少了一个维度，因此他没有办法理解爆竹怎么引爆的。
作为PM，你在生活中可能是一个特别二的人，但是项目中你只能敏感。
“聋子系列”一共三部分：
“信息透明”部分集中说一下如何发现、解决信息不透明的问题；
“微调”部分说的是，进入项目组以后，如何逐步调整自己和团队；
“检验”部分说的是，敏捷项目中的项目检验指标；
透明、微调适应、检验。你觉得这三个关键词还用在哪儿了？
检验
检验并不是什么高科技的词，其实我们身边充满了检验。“检验”通俗的说就是“合格标准”，有很多事情可能你都想不到那个就是“检验”，比如：
赛跑，谁跑得快谁赢，怎么检验？弄根绳子横终点，谁先拿肚子顶上，谁赢；
跳高，谁跳的高谁赢，怎么检验？弄个杆子架起来，谁先拿屁股碰掉，谁输；
想象一下啊，赛跑发令枪响了以后，一伙子人即使不知道怎么算赢，但是仍然人人争先恐后；另一伙子人努力的助跑，往垫子上摔，垫子前面既没有裁判，也没有杆子，但是那伙子人还是兴奋的不行。
这不有病么？这可能么？
那么凭什么做项目的时候就可以没有检验，却期望每一个人跟打了鸡血似的干活呢？
检验，不仅得有，而且得让所有人都知道，得让所有人都能灵活了解。举个例子啊，问一个赛跑运动员“如果组委会找不到绳子放在终点怎么办？”，他可能一下傻了，拍着脑袋说“我去，这问题老大了。。。”么？
但是，如果你拉住一个PM，问他“如果客户又提了很多新需求”或者“如果团队主力病倒了”，再或者“如果BA和Developer对于标准不统一了”怎么办，他还真的有可能傻了，拍着脑袋说“我去，这问题老大了。。。”
这些看似“老大”的问题，都和“检验”相关，听我细说说。
首先，ATDD是指导思想
全称是Acceptance Test Driven Development。为什么加上个A呢？用TDD不是挺好的么？加上A以后，更能够说明和强调这不是一个技术手段，是项目管理手段。而TDD仅仅是ATDD用到的一种技术实践。
ATDD这个东西，用极端的话说：所有的模块都是为测试而开发的。以这个思想为指导，在所有模块构建的时候，就应该想好了怎么测试。换句话说，作为一个开发，如果你发现你即将要做的功能自己都不知道怎么做成自动化测试的，说明你没想好，或者BA给你的就是一个“假功能”。那就放下键盘，先找BA画逻辑图吧，肯定你的理解不全面。
有了ATDD指导思想以后，下面的这些是方法：
code review、Retro
知道这两个活动的人可能会奇怪，为什么把这两个看似不相关的东西放在一起说呢？其实仔细想想啊，他们的作用是一样的，只不过Code review是给技术宅准备的；retro是给项目组准备的（当然也包括技术宅），他们的作用都是回顾过去，找到问题，找到现行和标准之间的差异，讨论改进办法；
kick-off meeting、sign-off、show case、CI
如果说code review和retro是概念性的和粗粒度的，那么这四样东西就是更加具体的行动和做法。
首先，每一个iteration开始的时候，都要有Kick-off meeting，在这个会议上，BA讲解这个迭代中的全部故事卡，PM将这个迭代的目标与大家讨论，达成一致。这就好比赛跑中告诉运动员“看见前面的绳子没有，谁先拿肚子顶上谁赢”；
然后，在这个Iteration结束的时候，所有的故事卡BA都应该已经sign-off了，每一个故事卡完成以后，BA都要确定“按照要求”完成了，这就好比冲过终点后，运动员们对于名词有了认可；
接着，show case meeting，在这个会议上，项目组把产品增量给客户演示，得到客户的反馈。这就好比裁判最终认可了比赛成绩；
最后一个，CI。CI是个啥，CI是Continuous integration的缩写，是一种方法，CI可以保证每一次提交都不会破坏整体的功能，还记得上面提到的TDD么？只有用了TDD以后，CI server才可以完成自动编译、测试、打包等事情，保证一切顺利。
Story card & Planning Wall
这两个东西也必不可少，他们是一个项目的全部载体，在以前，项目的需求“藏”在电脑的某个深层的目录的文档里（除了岛国片你可能藏得更深之外，很难再找到藏得更深的东西了）；项目的计划藏在甘特图里面，这个漂亮、光鲜的图虽然随时可用，但是受到责难的苦主一般第一句话就是：这是个“假计划”，情况变了，这个计划是2个月以前的，现在早变了。而此时，PM除了后悔自己没有“及时”修改甘特图之外，还后悔自己没有早点儿认识黑社会的打手。
敏捷开发是怎么解决这个问题的呢？用故事卡，故事卡就是需求，既有描述又有测试标准，团队每天的工作就是围着这些故事卡。Planning Wall就是贴满了这些卡的一面墙，谁说文档就一定要在电脑里面，我边上这堵墙就不能当成一个文档么？
最后，我们说一下：Velocity Estimation
在软件项目中，最难做的“检验”的事情，恐怕就是团队的产能了。
我们都知道，在付钱的时候，人总会问一句：多少钱？
比如你想买一个电脑，销售会说我这里有10种，价格从3千到3万块，相同的电脑我这里的价格不算贵；
比如你想买个房子，销售会说这个房子每平米6万，按照建筑面积算，公摊小，我这里的价格不算贵；
那凭什么客户想做一个软件的时候，人问多少钱，我们就忸忸怩怩的呢？
这又涉及到另外一个问题：你一天吃几碗干饭？
人，最可贵的品质就是知道自己吃几碗干饭。作为一个PM，你除了要知道你自己，还要知道团队能吃几碗干饭。我们先不展开说，就说这个比喻：“干饭”，你是不是需要知道“多大的碗”，“饭有多干”？这些是外部的关键点，你是不是还需要知道“自己当时饿不饿”、“有没有好菜”这类的内部关键点？
单说“干饭”这事，你就已经评估不出来了。何况更加复杂的团队产能估计（Velocity Estimation）。
不过，敏捷项目管理还真的有招：用“故事点”评估。（这篇文章说的是“检验”，所以评估方法就不细说了，想听的话，留个言啥的，我单写一个文章说“敏捷团队产能评估”）
每个迭代以后，PM都会得到一个新的以故事点为单位的团队产能，PM要做的就是拿这个与以前的比较、预估，得到一个最新的“更准点儿”的产能数据，用于衡量下一个迭代。如果项目的时间很长，比如1年（24个迭代），那么在7，个迭代以后，就应该可以得到相对准确的产能，PM也能拍着胸脯应对客户的这类问题了，因为他会了“检验团队产能”。
更多文章，去《艺术家死得福》
