敏捷（八）敏捷计划：应对现实

2019独角兽企业重金招聘Python工程师标准>>>

一、静态计划的症结

团队有些变动 。。。。

你注意到不如预期的那么快了。。。。

你的客户发现他们真正要的不是原来的。。。

时间不够用了。。。。

为了应对此类现实，我们的计划方式要能够：

向客户交付极具价值的东西。

保持高度的可见性、公开及诚信

做出的承诺要能遵守。

必要时，使我们能够适应和改变计划。

二、开始敏捷计划

简单来说，敏捷计划无非就是看团队有多快能将用户故事变 要工作的、生产就绪的软件，然后用其计算出何时能完成工作。

为了对交付日期有一个大概的了解，我们用项目所需的全剖工作量除以估算的团队速率，计算出需要多少迭代才能交付项目。这就是项目计划：

迭代次数 =   全部工作是 /  估算的团队速率

三、在范围方面灵活处置

敏捷项目通过在范围处理方面保持灵活来维持计划的完整性。坚持让客户摒弃旧的故事并添加新故事，敏捷团队不仅可以使其工作符合项目要求，同时又能让客户有机会改变想法（不用付出过高的代价）。

敏捷原则：拥抱变化，即使是在项目开发后期。要善于利用需求变化，帮助客户获得竞争优势。

四、第一个计划

1、创建用户故事清单

为了对范围内、范围外的待做事项设置期望值，敏捷团队会从主用户故事清单中选出故事子集，然后将其做为一个发布来处理。

定义发布：一次发布就是对客户有意义、值得他们去打包和部署的一组按逻辑归纳的故事。

敏捷原则：要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

2、估算规模

项目中最大的资源学浪费。软件中常用的特性分解：一直在用：7%、经常会用13%、偶尔用过16%、很少用过19%、从未用过45%。

3、划分优先顺序

让客户从业务价值角度来对主用户故事列表划分优先顺序，这样他们才能用最小的投资获得最大的收益。

4、估算团队速率

团队速率 =  完成的故事 /  迭代

但是我们的故事规模经常会发生变化，因此团队速率通常会是：团队速率 = 完成的故事点数 /  迭代

5、挑选一些日期

对日期设期望值有两个选择。你可以按日期交付或者按特性集交付。

五、燃尽图

我们用纵轴表示剩余的工作量（工作天数或点数），而在横轴以迭代次数记录时间。只需要记录下每个迭代的工作量（点数），然后将其绘制在图表中。斜线的斜率就是团队速率（团队每个迭代完成的工作量）。

完成了多少工作

还剩多少工作

团队速率

我们预期的完成日期

与之相对应的有燃起图。

六、将项目转入敏捷

如果无需一个完整的交付启动计划，但是要让大家都知道下列几点。

为什么要进行这个项目。

正在试图完成什么。

谁是客户。

需要移除的最大障碍是什么。

谁是那个扣动扳机的人。

七、付诸实践

变化无处不在。有时，我们需要在展示和管理变化方面具有一些创意。

转载于:https://my.oschina.net/xuqiang/blog/115470