敏捷实践——计划执行

      记得刚毕业找工作的时候被面试官问了一个相信所有程序员都会被问到的问题：“假如项目没做完第二天就要交付了怎么办？”相信当时被BS的原因也是这一个问题没回答好吧。类似的问题在前段时间又被问到：“项目延期你是怎么处理的？”在回答完之后才发现原来不知不觉间自己已经找到了问题的答案。

      继续按照《敏捷软件开发：原则、模式与实践》上的脉络来说说我们迭代过程中的计划吧。

初始探索

       用户素材都确定以后设计人员会分门别类，根据他们对代码的认知程度设计成一个个特性并分配工作量然后加入到版本计划当中。这里要关注的是，因为设计人员都是从开发转过来的，所以他们很清楚多少行代码可以完成一个特性，再根据由以往版本的战斗力（每人每天工作量）得到特性的大致完成时间，当然具体的安排还是有开发根据实际情况去安排到实际的版本迭代中。

发布计划

       一个计划的制定归根到底无非就是那三样东西：要干什么（用户素材）、要干多久（开发速度）和怎么干（素材取舍）。所以在公司引以自豪的研发流程的第一阶段，设计大牛们就根据上一个迭代的特性工时估算出程序员们的战斗力到底有多强，然后和一线还有解决方案扯淡，扯淡的结果就是版本要完成多少特性（PS：这里强调是估算，因为在后面几个迭代会不断塞需求进来）。最后一个版本计划就生成了，当然形式上还是要委员会评审一下通过。至于怎么个估算法，请原谅我还没到那个圈子上去混过所以只是给出自己的推测。

      用户素材主要有以下几种来源：一线客户提的实际需求（包括一线收集的实际需求和PK要求的指标）；版本策略定的需求（包括提高竞争力的需求和搞死竞争对手的需求）；还有就是某位高层突发奇想的需求。。。

迭代计划

       所以我们的特性组长在其他人猛投当前版本或者当前迭代的时候，他们就已经在根据上面得到的特性和工作量来安排下个迭代的人力投放了，虽然我们总能听到直接主管大发牢骚说我们每人投啦，我们超管道啦，但是最好该弄的还是要弄，该加班的还是要加班。当然开发可以选择把一些低风险的特性延后在下一个迭代去完成，这也导致一些本来低风险的特性变成了高风险的特性。开发在这个期间唯一能争取到只有两个：一是要版本给人，二是跟测试协商先交一部分，剩下的就是跟兄弟们打鸡血然后挑战大工作量特性了。还是要补充一点，并不承诺在迭代期间版本不会加工作量的哦！

任务计划

      迭代开始前几天，也就是上个迭代转测以后，领域的成员们就会看到下一迭代个人的工作安排好让自己心里有个底，同时大特性的负责人也开始准备各种特性澄清会议和制定特性计划了。在迭代的第一周（我们通常是一周）各领域的特性成员们集结完成并开始特性澄清和协商联调计划。这里充分体现了敏捷的计划制定原则——为下两周做详细计划，为下三个月做粗略计划，再以后就做极为粗糙的计划。

      在迭代进行期间，每天的早会上主管会问你同一个问题：特性是否有风险？这样貌似简单的一个问题却成为保证版本顺利往下走的关键。在早会上每个成员都会听到其他人的特性情况，也都可以提出自己的意见来降低特性的风险，最为关键的是主管在问题还未出现之前就已经识别到了风险并做出应对措施来规避或者提前解决问题。

      到这里，文章开头的问题答案已经呼之欲出了：项目永远不可能延期，因为在执行计划的过程中就已经提前识别了风险并做出了应对措施（规避风险或者调整计划）。

最后提醒自己一下：提前发现的问题不叫问题，叫风险，因为风险是可控的！