用最小的文档代价实现准确的敏捷工时估算

工时估算问题一直困扰着众多敏捷团队,一方面有效估算高度依赖文档信息,另一方面“文档”是团队最不愿意看和不愿意做的事。记得前几年执教MSE(线上软件工程硕士program)“敏捷项目管理”课程时,每周会出一个讨论题,其中一个是:“有效敏捷估算需要的最小信息有哪些?”这个问题的答案其实在很大程度上可以解决如何平衡文档建立、维护的成本和估算准确度。虽然,这个问题也一直被忽略。


 
前两天意外收到一封已经毕业的MSE学生的电子邮件,其中有两个附件:一个是IEEE颁发的最佳论文证书,一个是以上面问题开展讨论的文章,邮件主题是:迟来的答案。我花了大半个晚上读完了这篇文章,它确实全面、具体回答了我的问题,最佳论文奖确实不虚。
 
文章的三位作者花了数月时间,对25个国家121位有经验的敏捷实践者做了科学、详尽的调研,清晰展示了敏捷工时估算的现状,梳理了估算必要的文档信息,给出了两条有价值的建议。这些结论对中国敏捷实践者,众多敏捷教练和CMMI咨询师和评估师(敏捷开发模式超过了75%以上的CMMI评估),敏捷工具开发者都会有些帮助。
 
下面是这篇1万多字的文章的核心结论:
 
绝大多数敏捷团队使用并认可文档作为估算的依据
1. 97%的敏捷团队使用文档作为工时估算的依据。
2. 74%使用文档作为估算依据的团队认为这些文档信息非常重要,24%认为有些重要重要,只有2%认为不重要。
 
关于重估算
1. 重估算的主要原因:
   –
 
重要估算来源,如需求文档,有较大的变更。
   –
 
高估了研发能力或计划不现实

2. 不做重估算的主要原因:
   –
 
刚性需求、进度、投入资源
   –
 
做不完的需求自动放入下个迭代
   –
 
已设置
buffer
3. 文档变更导致的重估算的频率高于其他来源的变更导致的重估算频率。
 
估算所需最小文档信息
1. 功能需求
2. 用户故事
3. DoDdefinition of done
4. UI wireframes
5. 验收标准
6. 任务依赖关系
7. 非功能需求
8. API指南
这八类文档信息被绝大多数团队认为是工时估算的依据,如果这些信息不完整,不准确会导致估算的错误。
 
估算文档质量普遍有问题
但令人懊恼的问题是,上述八类文档信息都存在各种问题,如不完整,变更未及时更新,描述存在二义性、不够详细等,是导致估算错误的重要原因。维持高质量的估算依赖文档是许多敏捷团队面临的挑战。
 
Just-in-timejust-enough是使文档最小化的有效方法
远粗近细,随着迭代的展开,逐步细化迭代需求文档是减少文档成本的重要手段。
 
两条建议
建议1:迭代计划前,确保所需信息已文档化,避免不必要的估算假设。
 
建议2:希望工具开发者尽快推出可以识别所列估算文档质量问题的工具,识别遗漏需求和不一致之处,这也是敏捷工具的一大空白。  
 
对于估算的价值和方法,敏捷社区存在很大的争议。作者用深入、严谨的调研结果表达了自己的观点,做了一件有价值的事。这让我想起了一句常常给学生的忠告:努力让自己变成一个有知识的人,而不是只有一堆观点的人!


用最小的文档代价实现准确的敏捷工时估算》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/244.html