11 KiB
第57讲 | 敏捷中的期限之殇，软件业该怎么做？
你好，我是明道创始人任向晖，上期内容跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带来的启发。今天，想跟大家聊聊想要更好地控制项目进度和周期，软件业该怎么做？
1.将进度要素纳入敏捷开发
其实敏捷开发宣言中也并没有完全抛弃进度，它只是说响应变化要优先于遵循计划。而因为迭代更新的周期相对稳定（2-4周），所以看起来敏捷开发模式没有延期的问题。再不济也是割舍了一些完不成的特性，作为一个不算成功的迭代来复盘。
预测在2-4周内能够完成的特性开发量相对容易，稍有经验的ScrumMaster都能够基本估准确。但并非所有的软件开发迭代都是这么短的周期。在新版本开发、复杂的企业SaaS特性开发中，一个迭代经常需要超过一个月，再加上必要的测试和灰度发布，可能轻易超过两个月。我统计了一些常用APP的版本更新历史，发现80%以上的APP更新频度在两个月以上。
所以，我们必须要把进度要素重新纳入敏捷开发的管理范畴内。
这意味着，看似简洁的SCRUM开发看板，在In Process（开发中）这一栏中的任务内容，需要建立另外一套计划和跟踪系统才能实现更可靠的进度控制。
而在敏捷开发之外，传统的软件开发计划和建筑工程项目管理相比，大多也欠缺详尽的进度计划，而只是笼统的定义了几个粗放节点。如果是业务部门人员和外包客户达成协议，软件工程人员往往在交付时间要求上缺少发言权。很多软件外包项目的所谓开发交付计划都是根据客户要求的时点往前倒推而已。很多时候，别说客户了，就连自己人也很容易拿交付的时点来倒逼开发团队。
是不是应该倒算排期是一个很难回答的问题，企业总是面临客户的需求压力和竞争压力。问题的关键不在于交付期限的来源，而是有了交付期限以后，我们应该怎样细分软件研发工作的关键里程碑。
2.软件研发的关键里程碑
软件研发的里程碑到底应该怎样定义？我相信这个问题很多研发团队都做过探索。按照设计交付、编码完成、测试发布和验证发布这样的粗线条节点划分虽然容易，但对进度管理并没有实质性的帮助。而且，对于敏捷开发项目来说，设计交付甚至都不是一个一刀切的工作，有一部分细化设计工作完全可能在编码工作开始以后再进行。
当我们从建筑工程行业寻找灵感的时候，发现他们的关键里程碑是各个分部分项工程的准备、入场和验收，而且每个分支工程所需要的工时在计划时能够比较准确地衡量。虽然软件开发远远没有建筑工程的分工项目那么多，但是要做到可靠进度管理的基本前提是一样的。
制造业的规律也同样提供了线索。工件在工序上的转移是一个明确的物理过程，进入B工序的前提是完成A工序，每个工序所需要的工件加工时间只要能够被精确衡量，整个制造过程所需要的时间和资源就能够被事先计划清楚。而这个计划过程是在工件进入加工之前用专门的排程工作事先完成的。
那软件业如何采用类似的思想来提高自己的进度管理水平呢？
首先，软件开发要根据前端开发、后端开发和测试的主要专业分部建立细化的专业里程碑。一般前端开发工作依据设计阶段产生的页面来清点前端组件开发工作量。在模块化开发的过程中，还要注意对通用组件的合并归纳。一般而言，页面数量越多的应用，前端开发的工作量越大，模块化程度越低的项目，工作量越大。后端开发则根据数据对象和功能特性的设计来细化出接口列表和数量。如果不涉及特殊计算，大部分企业应用的开发工作量和接口数量成正比。而黑盒测试所需要的时间则和以上前后端开发量的总计成正比。
理解了这个规律，再复杂的软件开发项目也可以像建筑工程那样列出整个开发测试工作的关键里程碑。
在分割这些里程碑的时候，达成里程碑所需要的工作时间一般要细化到一周工作量以内的颗粒度，否则开发过程中的按周检查就失去了意义。
那谁能够有这个专业能力来定义这些关键里程碑呢？其实和建筑工程一样，团队并不需要一个全能的高手，而是应该由负责前后端和测试工作的专业工程师一起评估给出。制定计划和执行计划的人如果是一致的，计划达成的概率就会更高。当然，因为前后端开发工作不可避免地需要相互协调，以确定科学的次序，所以这个制定过程总是依赖产品和研发人员的集体会议。但这样的会议因为目标清晰，就是为了产出里程碑列表，所以效率可以得到保证。
下图就是一个根据以上原则和方法创建的复杂开发项目关键里程碑列表。为了便于每周的检查和跟踪，特意没有做成甘特图模式，而是将里程碑项目根据期限进行分组，每组就是一周内应该达成的里程碑。开发小组在周末进行的检查完全基于这个开发进度计划。
按照这个方法，能不能根据迭代的总期限（比如四周）进行倒推呢？当然可以！而且，这样的倒推，才让敏捷开发中重要的响应变化原则得到体现。在没有可靠进度计划之前，产品研发团队对于一个迭代所需要装进去的开发内容总是容易产生争议，大部分争议集中在用户价值上。但是，用户价值是需要使用数据加以佐证的，在新产品、新特性的开发过程中，往往还没有足够的用户数据来帮助决策，这时候，特性功能对交付时间的影响就成了另外一个关键决策要素。
当我们不得不尊重一个大版本的交付总期限时，团队就能在细分到每周的开发里程碑表中找到均衡，更容易达成一致。有时候，团队会毫不犹豫地在开发计划中将某个特性划去，因为它极有可能带来整个项目延期的风险。
以上介绍的是在敏捷开发模式下的进度计划要素。这个基本方法当然也可以用于一个全新产品和项目的研发过程，只不过，这时除了具体的模块定义、接口定义和页面组件定义带来的开发工作时间计划外，还需要留下足够的项目整体架构时间。这些初始化的架构工作包括项目成员参与技术方案调研和论证、数据结构的初始化设计、通用类库的定义，以及在这个过程中和产品需求方的沟通工作等。根据需求来源的性质和清晰度差异，它们通常要占据团队2-4周的时间。
3.跟踪、响应和及时沟通
制定和落实了进度计划，是不是就不会有意外呢？当然不一定。无论是自己的产品，还是客户的委托开发项目，变更有的时候是难以杜绝的。为了保证最终交付的质量，我们宁可冒险去接受某些变更，也不会对已知的失误无动于衷。
但接纳变更，响应变化的前提是持续对里程碑计划进行维护。让最新版本的里程碑计划能够体现出变更后的情况。和其他行业不同，软件行业一般不需要做完整的基线对比，所有的变化都应该反映在从今天往后的新计划中。从这一点看，对进度的控制并不破坏敏捷项目管理的基本原则。
此外，当周不能完成里程碑的原因不仅仅是需求的变更，还可能是开发过程中遇到的技术实现问题。我们永远无法保证研发人员事先已经掌握了所有的技能和知识，开发过程中随时可能会遇到成员的能力瓶颈和信息断层。解决这个问题的办法和建筑业、制造业一样——及时的会商。
开发人员有时会怯于提出问题，担心自己遇到的阻力会影响团队的进度，所以一个人闷头花了过长的时间，而事实上可能有更好的解决方案或者完全可以接受的变更。为了保证能做到这样的及时会商，团队可以约定在周中（比如周三下午）安排一次期中检查，由产品、研发和必要的管理层一起参加，主动去发现这样的执行瓶颈，以避免到周末的时候面对不得不被动接受延期的现实。当然，为了做到更高密度的跟踪，研发团队内部也应该坚持SCRUM开发要求中的每日站会。
所以，在研发过程中，跟踪进度、响应问题和及时主动沟通是保证进度的基本手段。
4.按期交付的激励
最后，我们要谈一谈按期交付的激励问题。很多开发团队为了解决按期交付的问题，都设计过各种各样的激励计划，其中最常见的就是项目按期交付的额外物质激励或者假期奖励，名曰项目冲刺奖。甚至还把提前交付的时间长度作为奖励的一个变量。
从我们长期的研发管理实践看，这样的做法有百害无一利。因为，它会让管理的重心盯向结果，而不是必要的过程，从而忽略投入在那些让项目如期完成的原因上。
过度强调如期交付的奖励，会让团队成员忽略质量，不愿意花费时间在计划和沟通上，而且一定会制造研发人员和产品设计人员之间的矛盾。如果前者对交付时间负责，后者对用户满意度负责，这之间的冲突和撕裂是可以想象得到的。
最好的按期交付激励应该落到平时。如果能够细化到按周评估的里程碑，就给了我们庆祝small win的机会，按周的如期交付也是如期交付，同样值得奖励，甚至如果周四就完成了当周的开发里程碑，周五就可以是一个自由工作时间。
对于软件研发人才，更宝贵的激励是能力的迅速提升。如果研发成员都参与过进度计划工作，尝试过科学拆解研发里程碑，他们将来的能力将不仅仅是更出色的程序员，而是能够管理更复杂项目的主管人才。
这种体验，只要是做过相关工作，尝到过胜利果实的研发人员都能够迅速体会到。这就像在足球赛场上，赢得最终比赛是激励，但除此之外，如果球员能够组织一次有效的进攻，赢得一个进球，或者成功化解和阻挡一次险恶的进攻，这些都是非常有效的激励。
最后，你们是如何控制项目进度和交付期限的呢？欢迎在留言中告诉我们。感谢您的收听，我们下期再见。