讨论不能停 |《敏捷软件开发实践 估算与计划》译者答疑

在上一次的免费赠书活动中，不少小伙伴留下了自己关于估算与计划的问题。今天小编再次邀请到《敏捷软件开发实践 估算与计划》中文版的译者——金明，选取了其中两个问题为大家重点剖析。

金明

ThoughtWorks首席咨询师，ScaleWorks PaaS云产品业务负责人。拥有多年企业与互联网应用开发经验，专注于敏捷精益、持续交付、DevOps以及云计算，曾多次担任ThoughtWorks持续交付大会担任演讲嘉宾。目前主要关注如何通过云计算实现企业内部精益IT与业务对齐，即将在5月7日的 技术雷达峰会（北京）上分享话题：《云与大数据，建立商业创新的加速杠杆》。

欢迎大家点击右下角 写留言 参与提问~ 

讨论，当然不能停！

估计总是不准，而且花费不少时间，老板觉得不准程序员不靠谱，程序员也很郁闷！

 “估计不准”的潜台词是需求的工作量和计划，与实际的开发不符。这背后的原因有很多，略举几例：

1. 需求的验收标准是否清晰，与其他需求的依赖关联是否明确？

2. 参与估计的程序员对需求验收标准的理解是否到位，是否理解了需求的复杂度？

3. 参与估计的程序员、分析人员、测试人员是否对交付计划进行了足够的讨论，大家能否达成一致？

4. 开发的过程中，需求是否发生了变更？这些变更是否经过了需求、开发与测试的一致确认？

5. 开发的过程中，开发人员是否偏离了原始的计划，例如过度关注于技术或细节，没有遵循原始的计划？

6. 开发团队的实际开发速度是否被比较准确的度量，制定的计划是否超出了实际的开发速度？

所以，这里面有组织的因素、有个人的因素、有技术的因素，有方法的因素，往往需要全流程、系统性的分析和解决。下面有一些建议：

1. 团队的每个角色对于自己的工作交付物要有比较清楚的要求和认知，例如分析人员定义足够清晰的需求，开发人员交付满足验收标准的代码

2. 尽量选择短周期的迭代式开发流程，在开发过程中通过站会、持续集成、showcase等实践缩短交付进度对个体的反馈

3. 需求的估计使用故事点单位，不要使用完成日期。估算时，针对需求的复杂度来估算大小，而非单个个体所需要的时间长度。

4. 坚持通过燃尽图度量团队的实际开发速度，按照实际的开发速度来进行估算后续的计划

5. 在团队和组织层面建立和维护足够的安全感和信任，程序员需要尽力保证自己对于进度的承诺

6. 培养分析、开发和测试人员的能力，提高对业务知识、技术和工具的熟悉

7. 如果开发对于实现没有把握，可以限定一个很短的时间段，让开发人员先技术“穿刺”（Spike）一下，了解实现的风险

敏捷的关键在于个体与信任，信任来自于每个个体对自己的承诺能否真正达成，来自于每个个体寻求帮助时能否被及时响应，来自于每个个体是否能够开放分享自己的心得。信任是双向的，任重而道远，共勉。

敏捷过程强调对事实的尊重和对变化的肯定，落到商务实际上，还是会限定工时和金钱。从项目初期的估算和计划方面，如何保证在商业活动中，先拿回项目，并更好的在预算范围内进行交付？

这个问题很好，其实涉及了多个小问题：敏捷的项目决策、敏捷的合同、敏捷的客户关系、敏捷的项目交付、敏捷的项目工作量估算以及敏捷的项目交付计划表等。每个主题其实都可以详细来论述，但由于这些在书里或者网上都已经有很多的材料，这里就不详细讨论了。这里主要集中于“当商务需求具有较高不确定性的时候，如何去设定项目的范围？”这一问题展开。

首先，敏捷的原则之一就是“客户协作胜于合同谈判”，商务合作的本质是甲乙双方一起合作，在一定的时间、资源和成本的前提下，乙方帮助甲方实现甲方的目标，帮助甲方获得价值，实现双方的互惠双赢。我们所有的讨论都是基于“双赢”的前提下展开，一锤子买卖或者“双方如何勾心斗角”不在我们讨论的范围之内。

因此，基于“双赢”的目标，当客户需求不明朗的时候，我们会建议先做一个短期（几天到几周，一般一周或两周）的“启动”（Inception）项目，这个项目的目标在于梳理后续待交付的需求、技术选型等并制定相应的交付计划时间表。

在这个“启动”项目中，我们会派遣专业的业务分析师、技术架构师、原型设计师以及一些特殊的专家人员，与客户的所有干系人（从高层到一线人员）开展一系列紧张高效的工作坊，包含且不仅限于如下的工作坊：

* 需求工作坊：按照敏捷用户故事的层级，从“Vision－Theme－Epic－Story”的流程，通过“Design Thinking”的理念“发散－收敛”，并借助于一系列的产品效果原型，梳理出项目的目标效果和故事需求清单等。与客户方达成共识。

* 技术工作坊：了解客户当前的技术栈、技术规划，根据后续交付的业务需求，梳理项目应该采用的技术架构、技术选型和开发工具。过程中，可能会针对一些未澄清的技术风险点进行“穿刺”（Spike）。与客户方达成共识。

* 质量工作坊：了解客户当前的测试方法和工具，针对后续交付的业务需求，建议合理的测试策略、自动化测试工具以及质量原则。与客户方达成共识。

* 交付计划工作坊：基于上述的故事清单、技术选型和质量策略，以及其他的相关材料，与客户方的领导一起设定故事需求的优先级，遴选出后续项目的合作范围；完成故事需求的工作量估算；制定项目的交付计划、版本计划以及迭代计划。与客户方达成共识。

* 项目管理工作坊：了解客户的项目管理方法和需求，讨论双方如何更有效地沟通、合作，制定相应的沟通计划、汇报计划、项目风险管理策略、需求变更策略等。与客户方达成共识。

通过以上的工作坊和材料，客户对于待交付的产品需求、后续项目合作的交付内容以及计划都有了比较清晰的认识，双方对项目的交付也尽可能地达成共识。因此，双方可以更好的进行项目的商务协作与洽谈了。

▽

《敏捷软件开发实践 估算与计划》试读版本

点击 阅读原文

购买渠道
京东 

当当  

亚马逊