文档介绍
2018-7-23明道创始人任向晖你好，我是明道创始人任向晖，上期内容跟大家了敏捷开发中项目期限控制的问题，以及其他行业带来的启发。今天，想跟大家聊聊想要更好地控制项目进度和周期，软件业该怎么做？其实敏捷开发中也并没有完全抛弃进度，它只是说响应变化要优先于遵循计划。而因为迭代更新的周期相对稳定（2-4周），所以看起来敏捷开发模式没有延期的问题。再不济也是割舍了一些完不成的特性，作为一个不算成功的迭代来复盘。预测在2-4周内能够完成的特性开发量相对容易，稍有经验的ScrumMaster都能够基本估准确。但并非所有的软件开发迭代都是这么短的周期。在新版本开发、复杂的企业SaaS特性开发中，一个迭代经常需要超过一个月，再加上必要的测试和灰度发布，可能轻易超过两个月。我统计了一些常用APP的版本更新历史，发现80%以上的APP更新频度在两个月以上。所以，我们必须要把进度要素重新纳入敏捷开发的管理范畴内。这意味着，看似简洁的SCRUM开发看板，在InProcess（开发中）这一栏中的任务内容，需要建立另外一套计划和跟踪系统才能实现更可靠的进度控制。而在敏捷开发之外，传统的软件开发计划和建筑工程项目管理相比，大多也欠缺详尽的进度计划，而只是笼统的定义了几个粗放节点。如果是业务部门人员和外包客户达成协议，软件工程人员往往在交付时间要求上缺少发言权。很多软件外包项目的所谓开发交付计划都是根据客户要求的时点往前倒推而已。很多时候，别说客户了，就连自己人也很容易拿交付的时点来倒逼开发团队。是不是应该倒算排期是一个很难回答的问题，企业总是面临客户的需求压力和竞争压力。问题的关键不在于交付期限的来源，而是有了交付期限以后，我们应该怎样细分软件研发工作的关键里程碑。软件研发的里程碑到底应该怎样定义？我相信这个问题很多研发团队都做过探索。按照设计交付、编码完成、测试发布和验证发布这样的粗线条节点划分虽