[Day25] Scrum 与交付型专案

「我们公司做的是接案，跟 Scrum 的迭代精神不符，还适合用 Scrum 开发吗？」

这个问题的雷点在於接案-交付型团队，与产品团队的几个矛盾处：

1. 交付型专案，通常合约限制的交付项目与时程，而产品团队有高度自主权。
2. 产品负责人 (Product Owner) 与专案经理 (Project Manager) 的工作内容不尽相同。
3. 交付型专案没有迭代验证的概念，只有准时交付。

理论上来看，用 Scrum 架构套在交付型专案开发，的确会有水土不符的问题。但实际用 Scrum 运行交付团队的经验告诉我，透过开发系统中 Refinement 与估点的实践，对准时交付的风险管理，其实有更好的效果。仅管 PO 与 PM 的工作内容大不同，在开发系统中与团队的互动模式，基本上是一样的。

专案时程评估

对软件开发案来说，一般来说，在签约前，甲乙方会针对开发范围，验收条件等进行谈判。对於开发时程的画押，专案经理就需要开发团队的协助。此时专案经理可以根据初步的开发范围与设计文件，撰写成阶层化的待办清单 (Backlog)，如下图。

通常，在初步的时程评估上，会由每个领域的技术主管进行「粗估」；但我建议在这个阶段，就应该让团队介入，得到的评估结果，会比技术主管单方面的输出准确一些。接下来，PM 带着 Backlog 召开 Refinement 会议，由团队针对 Story 进行讨论，然後「粗」估点，这个阶段不要求精准，而是要得到由开发团队认可的参考值。

如上图， PM 此时可以得到整个专案的总点数，经过换算，就可以得到开发时间的预估值。(换算方式请见 Day13-重塑 Planning 会议)。

这个方式的好处在於：

1. 团队在很早期就已经有心理准备
2. 时程与对应的开发范围是整个团队的讨论结果，可信度较高，减少谈生意的人乱画押带来的风险

甘特图

当 PM 没有开发团队做後盾时，只能凭职场经验，脑补开发团队的开发时间，拉出想像中的甘特图。但透过 Refinemet 与估点後，甘特图上的时间可靠度也就提高了。一旦完成签约後，就可以开始进行细部的 Refinement 与估点。如下图，从粗估到细估後，路径图也会从模糊，变成清晰。

值得一提的是，理想状况下，细估後的时程应该会缩短；但如果细估後发生点数大幅膨胀的情况，此时专案风险就会升高。也是给 PM 提前准备应对的机会。

燃烬图

在点数系统的辅助下，团队每日对任务的完成度，可以透过更新点数得到。透过燃烬图 (如下图) 的绘制，PM 可以透过量化的数据观测团队开发状况，将心力专注在沟通协调专案事务。

上图中，我圈起两个值得注意的观察点：

观察点 1:

在开发过程中，总点数没有稳定下降，反而上升。表示初始计画的点数可能被低估，或是客户临时新增了需求。透过数据，即可掌握风险。一般而言，膨胀的点数在 40% 之内，透过不得已的加班手段，都还有机会拯救。

观察点 2:

逼近交期，但离稳定燃点的理想值差距愈来愈大，此时可能必须与团队协调加班。而 PM 可以估算出加班造成的成本支出。

我带过的「产品团队」与「专案团队」刚好各占一半，都是用相同的开发系统在处理不同的开发情境。从结果来看，都可以达成交付任务。回到一开始的问题，我认为跑不跑 Scrum 并不是关键，而是规画工作的执行方式，以及如何建立透明化的讯息流，才是重点。