DevOps实施：项目群管理（PPM）中的需求和计划管理

本文面向的是企业IT用户（尤其是每年要投入数以百计的人力，开发维护十几个甚至几十个上百个上不同系统的企业），在组织范围内的计划和需求消耗太多的问题。而对于只有十几个人的单一产品团队来说，也许对这部分不用做特别考虑。

主要问题是：

1）你的企业是否花了大量的人力和时间在计划上？

2）是否有大量的需求处于等待开发状态？

3）是否有很高比例的需求在最初定义好之后需要重复再修改？

4）开发出来的需求是否有很高比例其实没有被最终用户所使用？

如果你的企业存在这样的情况，请继续阅读。

我们来看一个典型的项目开发声明周期模型：

虽然很多项目已经在采用Agile/Scrum的方法进行开发，但在一头（从业务想法到开发团队可执行的需求）一尾（从代码完成到上线）还是典型的瀑布式。

IT面对的问题是试图用瀑布模型来尽早确定软件的功能（Scope），发布日期（Schedule)和资源/成本（Cost）。但对软件来说，这个三角形的三边总是处于变化过程中（尤其是功能和日期），很难在一开始确定下来，而是始终处于动态变化过程中。但对企业管理而言，IT又不能把所有的计划都推后，不作出任何承诺。

这里的重点是针对长期战略性、中期提供附加值、和短期不可预测的需求采取不同的计划策略。

根据HP固件系统的例子：

1. 长期（6个月或以上）战略性（MUST）的工作：因为软件（固件系统）要配合新型号打印机产品发布的日期，而这个日期一般是希望很早就确定下来的。所以软件开发部门一定做到按时交付这类需求。这里的策略是：此种计类型的工作只占用工程师团队50%或以下的总工作量。
2. 中期（3~6个月）提供附加值（NICE-TO-HAVE) 的工作：保证核心系统能够按照确定日期按时交付之后，接下来有一部分需求是业务希望能够提供给客户、带来附加价值或者提升客户体验的新功能。对于这部分需求，维护一个粗粒度的估计列表，并赋予优先级，而且保证占用工程师团队的工作量不能超过30%。此种类型的工作也应包含一些必要的重构，增加
3. 短期（3个月以内）临时出现、紧急或计划外（UNPLANNED)的工作：对于这种类型的工作，只做短期计划，比如1~2个迭代的需求，并且控制工作量占总工作量的20%以内。

还是用健身作比喻，如何你希望在新年的第一天开始做个详尽的计划，规定每一天要健身多长时间，做几组规定动作，可能要不了多久你就会发现很不现实。更好的做法是长期来讲你要达成什么目标，是力量训练、跑10KM，还是有氧运动，而且要预留出足够让自己可以灵活时间。这个是长期的战略目标，中短期可以结合其他类型的训练。这样才能保证不是花了很长时间做计划，然后发现不可执行。

再来回顾一下我们的DevOps实施框架图：

我们下一讲会关注在 API / 微服务的理解上。

END