还能再被标题“骗”进来的请自觉去面壁三十分钟哈哈哈。
真实的标题是《我的敏捷经历-II》，上一集在这里：《我和姑娘们不可不说的故事》。
实施敏捷
“工欲善其事必先利其器”，在正式启动项目之前，我们先组织了好几次团队学习，弄清楚了敏捷的基本思路，例如敏捷宣言、迭代的基本流程、别人的敏捷经验等。然后，我们照搬了一套迭代流程，一边熟悉流程、加深理解，一边对流程做出修改、优化。最后，我们不仅很好的完成了项目目标，而且梳理了一套自己的敏捷流程、收获了一支非常有战斗力的敏捷团队，可谓一举三得、不虚此行了。
迭代流程
在项目初期，我们为一次迭代规划了三个星期的时间。最主要的原因是我们还不熟悉敏捷模式，担心时间太短会跟不上。初期的迭代流程还是比较“纯净”的，只有计划会、站会和回顾会。
随着我们越来越得心应手，设计评审、代码评审等流程也被安排上了，三周时间都略显捉襟见肘，压缩到两周就太强人所难了。于是，我们最后梳理的敏捷流程是这样的：
计划会
一日之计在于晨，晨光熹微于深夜；一年之计在于春，春色初来于寒梅。每个敏捷迭代都始于计划会，而计划会始于上一个迭代的尾声——这也算是一种“以终为始”吧。
在上一个迭代行将结束时，产品就应该排定需求优先级，并明确、细化高优先级的需求。必要时，产品可以叫上开发、测试同事开小会，但不建议开全体会议来讨论问题——这种大会效率极低。有了这样的准备工作，我们在计划会上就可以确定本次迭代的需求范围了。
由此可以看出为什么“产品人员对项目的长期规划和对需求的理解程度这两点非常重要”了。如果没有长期规划，很容易陷入计划会上无需求可做、迭代中间却临时安插需求的困境。
不仅如此，缺乏长期规划还可能导致需求完成开发后压根不上线、不启用，甚至在下一个迭代中就下线的自我矛盾之中。如果对需求理解程度不够，那么排定需求优先级、明确和细化需求等工作就会变得“道阻且长”，后续工作也会举步维艰。
分配任务和估算点数
在计划会上确定需求范围后，要不要即刻分配任务并估算工作量？大多数开发人员不愿意这样做，因为计划会上的需求常常不够细致、明确。基于这样的需求来做出估算，颇有点盲人骑瞎马夜半临深池的感觉，风险太大。
但是，敏捷开发要求在计划会上做出估算。
哪些需求、任务应放在本次迭代中、哪些应放到后续迭代中，这不仅需要考虑需求任务的优先级，还应该考虑迭代的容量和需求任务的工作量：你总不能把保龄球塞进高尔夫球洞里吧。
而且，从一个迭代所完成的工作量数据中可以分析出团队的工作效率，从多个迭代完成的工作量数据中可以分析出团队的提高程度。这样就可以更加理直气壮地去要求升职加薪了哈哈。
所以，在计划会上做出估算，可以说是功在当代、利在千秋。
虽然是初学者，不过我们在计划会上做出了有意义的估算。
这首先要归功于我们的产品S姐，她的需求清晰明了、洞若观火，给我们的估算打下了坚实的基础。还有我们的C姐，她都会很积极的带领团队沟通需求、为计划会做好准备。最后，到了计划会上，项目组会对本次迭代的需求进行评审，如果认为需求还不够完善、不能进入设计开发阶段，那么就不会把它纳入本次迭代的范围中，自然也不需要对它进行估算。有了这三个前提，在计划会上进行估算可谓水到渠成。
敏捷的任务点数估算，说难不难、说易不易。我先按时间顺序描述下我们团队使用过的三种估算方法。
按工时估算
最初，我们使用的是最简单、最容易想到的方法：按工时估算。一个任务需要1人天，那就是8人时；需要2人天，就是16人时。迭代中，除了请假之外，每天扣除一天的工时。
这种估算方式非常简单易行，很适合我们这种初次实施敏捷的团队。但是，这种估算法存在着显而易见的问题：如果不请假，我们每天都能完成8小时的工作，因而每天都会扣除8个任务点数。反映到燃尽图上，它就是一条与计划线完全重合的直线。
因此，这种估算方式无法追踪迭代进度中的问题，更无法帮助我们协调资源解决问题。
这个问题的核心原因在于：敏捷的任务点数是用来衡量工作量的，而工时是用来衡量工期的。
举个例子来说，“这锅饭有一斤米”，这是对“量”的估算；而“吃三顿才能吃完”，这是对“时间”的估算。用“时间”来估算“量”，是种南辕北辙、缘木求鱼的做法。
因此，在经历了几次这样的问题迭代后，我们就换了一种估算方法。
按功能点估算
新的方法是当时技术部大力推行的功能点估算法。简而言之，这种估算方法是根据系统中的接口、表等数据和几个公式来量化度量软件规模的一种方法。它的估算结果是代表工作量的一个数字，而非代表工期的人时，因而非常契合敏捷估算的要求。
借助于功能点估算法，我们可以准确地追踪项目进度。举例来说，假定一次迭代需时五天，迭代任务需要完成两个接口和三张表的开发，据此计算出的功能点数是3+5+3+2+2=15。在迭代中，三张表相关的开发工作耗去了头两天时间，接口相关开发工作却受困于某个技术难题，导致花了一天时间却还在原地踏步。这样，第四天站会上的燃尽图就应当是这样的：
从这张燃尽图中，我们可以清楚地看到：在3月2日，项目进度只是略有滞后；但是到3月3日的时候，进度已经落后很多了。这个时候，项目组就应有所警觉或行动了：例如向组内或组外的技术达人寻求协助，以亡羊补牢、赶上进度。
从估算工作量这点上看，功能点估算法和敏捷开发简直是佳偶天成。但是尺有所短，这种估算方法也存在一定的弊端。
首先是它的学习曲线比较陡峭。功能点估算法中包含很多比较费解的名词、定义和公式，掌握起来比较困难。
其次，实际使用中，常常要花费较长时间才能完成一次估算，这会使得时间有限的计划会更加仓促。
此外，功能点估算法有较大的局限性。如前所述，它是基于接口、库表等“数据”进行估算的，因此不适用于技术优化、模块重构、算法改进这类与业务数据关系不大的工作。可是在现代软件项目中，这类工作是在所难免、甚至可以说是必不可少的。面对它们，功能点估算法就力不从心了。
顺带一提，想要了解功能点估算法的话，可以参考功能点估算法以及这个网页上列出的参考文献。虽然这种方法存在不足之处，但是它还算是一种比较科学的、可以量化的工作量估算方法。
扑克牌法估算
由于功能点估算法的上述问题，我们最后放弃了它，而转向了一种更加经验主义、但是更加简便易行的方法：扑克牌法。
“扑克牌法”这个名字听起来很天马行空不知所云，但是实际上它就两步，比“把大象装进冰箱”还简单。
首先，每个人根据个人经验估算一个任务点数；然后，去掉一个最高分，去掉一个最低分，再计算出平均值。duang的一声，一个任务估算完了。
当然，纸上得来终觉浅。说起来虽然简单，但是实践起来还会有问题。
首当其冲的问题就在于：虽然大多数人都有估算工期的经验，但是估算工作量就有点丈二金刚摸不着头脑了。我们项目组虽然经历过功能点估算法的洗礼，但是要靠个人经验来估算，还是有些无从下手。
我们项目组的解决办法参考“基准任务”进行估算。首先，选定一个“基准任务”并为它指定一个点数。然后，为比它更复杂的任务估算更大的点数，为比它更简单的任务估算更少的点数。
例如，我们项目组以“新建一张表并提供简单查询功能”为基准任务，指定这个任务的点数为5。那么，“新建一张表并提供增删改查功能”一般会估算为15点，“定时查询当天数据并计算统计数据”会被估算为8点，“在已有库表基础上修改查询功能”会被估算为3点，等等。
这种方法的缺点在于很难确定“基准任务”：它应该是大家都很熟悉的、比较简单的、比较有代表性的任务，否则它很难作为标尺来度量其它任务。但是，如果找到了一把趁手的标尺，那么任务估算就是水到渠成的事了。
第二个问题实际只是估算流程的问题：在估算过程中，如果不能同时给出结果，那么很可能出现临时更改自己的估算值的情况——虚荣或者从众的心理很容易把合作变成博弈。
每日站会
每日站会是敏捷模式中最容易上手的一项流程：不就是每天站着开个会嘛，能站起来的就会开^_^。
每日站会的流程也确实很简单，每位成员说清楚三点即可：昨天做了什么、今天计划做什么、当前工作中遇到了哪些问题。
我们也是带着这样的理解，开始了日复一日的每日站会。
但是，在最初的照猫画虎之后，问题便接踵而至了。
问题一：站会太长
第一个问题在于：大家都太喜欢在站会上讨论问题细节了。就像星星之火可以燎原一样，站会上提出的每一个点都会引发“家里几口人、人均几亩地、地里几头牛”这样打破砂锅问到底式的大讨论。结果，原定十五分钟的站会每次都要四五十分钟才能结束。这样低的效率让所有人都叫苦不迭。
这个问题与研发人员的沟通表达能力有关，与面对和解决问题时的抽象能力有关，与团队会议组织方式有关，与很多方面都有关。我们从团队会议组织方式入手，采用了一个比较简单粗暴的方法：指定一名主持人，由主持人掌控每个人发言的时长。一旦出现展开讨论的迹象，主持人必须立刻叫停，参与讨论者必须立刻停止。在我们的实践中，主持人叫停几次之后，站会上讨论细节导致时间过长的问题就销声匿迹了。会后由提出问题的同事负责、指定的几位同事协助继续跟进问题、推动解决。
问题二：流于形式
可是，一波未平，一波又起。不再讨论具体的问题之后，站会就像失去它的灵魂一样，变成了单纯的每日形式。“我昨天做了这个任务，遇到了这个问题，今天继续处理这个问题”。除此之外呢？个人的进度有没有落后？团队的进度有没有落后？落后了多少？要怎么赶上来？这些问题本来应该通过站会来发现和解决。但是，我们的站会甚至发现不了这些问题，解决它们更是无从谈起。
敏捷开发以“快速响应变化”为人津津乐道。对外部需求的变化，敏捷模式以快速迭代来响应；对迭代周期中的变化，则以每日站会来跟踪和应对。但是，站会如何跟踪迭代周期内的变化呢？
我们的答案是会议纪要。这个会议纪要如同每日站会一样简单，就只是记录了“我昨天做了什么，遇到了什么问题，今天要做什么”。虽然是简单的记录，但是我们从此就知道了哪些任务延期了、哪些问题需要什么资源或协助。这样一来，迭代周期内进度不明的问题就迎刃而解了。
岔开说一句，会议纪要是一件不起眼的小工具，但是它却能帮你翘起地球。如果开会时间太长，就很容易“见尾不见首”：这时，会议纪要就是一份备忘录，用来完整地记录下会议内容。如果开会时间短，会后就会遗留一大堆任务：这时，会议纪要就是后续工作的任务列表。而且，当会议留下了后续工作时，会议纪要不仅可以用来记录任务，还可以用作任务跟进的清单。所以说，会议纪要就像天机老人的木棍：看似平平无奇，却可以排在兵器榜的第一位。
我们的站会纪要也很平平无奇，只是一个Excel而已。相较于JIRA、IceScrum等专门工具，Excel需要自己多花心思来支持敏捷模式，但是它胜在简单、灵活、人人会用（好吧也许不是人人都会用）。一份站会纪要大概长这样（CS/WYC/LX/ZXM是姑娘们的名字缩写，你看这真的是“我和姑娘们不可不说的故事”）：
从上面这份站会纪要中可以看出：前端框架问题已经困扰LX好几天了。此时项目经理就应当关注、并处理潜在的风险了。
问题三：不够直观
这份会议纪要简便易行，并且确实“功勋卓著”，但它也存在一些缺陷。
首先，它不直观。如果我不说，你要花多久才能从上面这张表里看出谁的进度落后了？“一张图表胜过一百行文字”，就是因为文字表述不如图表那么直观。
其次，会议纪要并不能够告诉我们延期风险的严重性。仍以上表为例，LX的任务进度确实有问题；但这问题有多严重？有没有必要让其他人来协助？看不出来。
第三，会议纪要只能发现进度滞后，却不能发现进度超前——虽然这种情况不经常发生，但我们也应该注意到它。
最后还有一点：会议纪要千般好，可是它不是瑞秋（划掉）燃尽图=。=作为“原教旨主义者”，我想了个法子，把会议纪要和燃尽图“嫁接”在了一起：
其实方法也很简单……通过Excel来维护一下每个人的任务点数，并根据任务点数绘制出团队以及个人的燃尽图即可。当然，排版方面就看各自的喜好和审美了。
通过燃尽图可以一眼看出谁的进度滞后了、进度滞后的严重性。不过，燃尽图不能准确定位出是什么原因导致了进度落后，这还需要站会纪要的协助。当然，燃尽图的作用不仅仅体现在每日站会的进度跟踪上。在后续的回顾总结以及迭代“升级”上，它还有更大的用武之地。
几乎所有团队的敏捷尝试都始于每日站会。但是，有很多团队的敏捷终于每日站会。慢慢地，站会流于形式，敏捷徒有其表，令人扼腕。
无论敏捷还是瀑布，都是项目管理的方式。两者之间也许没有明显的优劣，但无论用哪一种都比不做管理、放任自然要好。虽然每种模式会有一定的局限性，但是它们的适用范围都很广。而不管使用哪一种，都要有能够透彻理解这种开发模式的管理员和能够忠实履行管理流程的团队。 如果说某种开发模式有水土不服、不适合某个项目组，我认为基本上都是这个原因导致的。