从一个乙方视角聊聊敏捷项目

我之前的敏捷实践一直都是在产品团队尝试的。一直觉得敏捷更适合产品开发，项目不适合。主要原因之一是项目的愿景更多的是客户自己的，自研产品视角就会有所不同。从价值交付的角度，团队更有共鸣；而作为乙方做很难捕获到，另外项目周期相对固定，这会对敏捷所强调的试错等思想的应用造成很大的压力。不过今年正好参与了一个项目，客户恰恰点名要应用敏捷方式来运行。作为 ScrumMaster 和项目经理一起合作有了一次不一样体验。目前项目刚过了 1/3，对这次乙方项目的敏捷尝试的感受做一些总结。

客户的合作胜过合同谈判

首先第一点无论是自研项目还是作为乙方参与的项目，对于敏捷团队服务的客户而言，构建信任是至关重要的。客户的合作是建立在对彼此专业度的认可基础上的。信任才可能有后续的顺畅的合作。转变这个思维方式，避免拿合同或者需求规格说明书(FS)和客户说事的传统。这也是敏捷项目和传统项目最大的区别。成本、项目时间、范围、质量这些因素中，更看重的是交付对客户来说有价值高质量的软件。如果客户认可并愿意合作那么范围甚至是项目时间真的是可以谈的。我这次参与的项目。客户甚至愿意单独拿出额外预算应对可能的新增需求。而新增的需求如果对客户是有价值的，客户也愿意延长项目时间。同时客户也愿意在迭代过程中用新涌现的需求替换已经过时的。小伙伴听到这里也许会感慨，这个客户真不错呀。确实，如果客户本身对敏捷思想有认识，你是幸运的。少了引导客户的工作。更容易达成合作。

标书期间的评估和实际有差距怎么办

因为项目投标期间的评估大部分都是基于经验和拍脑袋，里面水分有多有少大家都是知道的。而实际进行项目的时候水分多了自然心里高兴，那如果估计少了呢？方法还是——构建信任关系，和客户坦诚沟通。先了解客户真实需求，投标时候的需求一般只是标书上面的简单描述，而乙方也加有大量的假设。如果实际需求和表述上的文字存在理解偏差，同时之前的假设也有变化都会对实际开发过程中的工作量造成影响。和客户沟通，明确之前的假设和理解的出入，新的解决方案的工作量变化。我个人的建议，新工作量一定要更贴合实际，如果工作量减少，也要和客户明确，并将多余的评估预留给项目可用池子中；如果工作量增加，根据项目实际情况可以和客户讨论额外付费或者无需付费，只需要争取额外开发时间。还有一种，基于对项目整体需求的理解，对于一些优先级较低的功能，或者相关联的功能，是否可以进行替换？这些都是可以操作的方向，减少范围变更对项目的影响。无论哪种方式，透明、开放、诚实都是最重要。这可以赢得客户的信任。

敏捷合同 VS 传统合同

网上有很多敏捷合同的描述以及建议，感兴趣的小伙伴可以自行搜索。这部分我想分享一下我在项目中的感受。大家都认为固定总价合同是最不适合敏捷项目的。但是现实中往往项目大部分仍然是固定总价。因为对于甲方来说这种风险最小。乙方要承担项目失败的风险。不过换个角度想一下，项目失败了，双方其实都损失了，不只是金钱，甲方损失了时间同时也没有得到他想要的东西。我参与的这个项目仍然是固定总价合同。在和客户实际工作过程中随时沟通工作量的变化，就像上面提到的，遇到减少的工作量及时沟通，加入项目可用池中为后续增加的工作量做 Buffer。另外获取客户信任，当遇到增加工作量的任务及时举手，和客户明确对项目影响范围，有何应对方案。是否可以替换某些需求来达到降低风险等。这些都需要 Project Manager 对敏捷思想的理解，并能结合项目管理经验来影响客户。当然我这次比较幸运的是，客户准备了一笔额外预算来应对项目的变化。所以客户已经有心理预期，并愿意为变化买单。

敏捷团队人员有哪些角色

传统 Scrum Team 组成是 Product Owner，Dev Team，ScrumMaster。项目中由于各种因素可能会相对复杂。例如 PO 可能是甲方出，因为他们懂业务。但是 Dev Team 是乙方的，最好的情况当然是双方坐到一起来工作。不过经常情况是甲方 PO 会有很多其他工作，无法全职参与和 Team 的沟通。有时候甚至 PO 和 Team 使用不同语言。这时候就会存在 BA，是的，传统项目中的需求分析人员在敏捷项目中依然需要。BA 作为 Team 和 PO 之间的桥梁还有润滑剂，将需求高保真的传递给 Team。所以我所在的敏捷项目中的角色有：PO，BA，ScrumMaster，Team，Project Manager。

如何安排需求搜集过程

传统项目会在开发前集中做需求搜集，并形成正式的需求说明文档(FS)，让客户签字后开始执行。我这次的项目采用结合 Scrum 梳理会(refinement Meeting)的方式。也就是每一个进行中的 Sprint 中会开 3~4 次梳理会，这期间和客户一起梳理下一次 Sprint 的内容。梳理会可以采用敏捷工作坊，或者传统项目的 low-fi design 结合的宣讲的形式进行。最终也可以结合客户和团队的习惯形成一个简单的 Sprint 范围内的 FS，用于达成一致。没有完整项目的 FS，每一个 Sprint 单独形成自己的 FS。项目的整体范围就是项目标书描述的内容，而这些内容在开始 Sprint 前都是可以变化的。这也印证了敏捷宣言中的最后一条：响应变化高于遵循计划。

UAT 怎么做

传统项目在上线前会有 UAT(User Acceptance Testing)的过程，用来确认即将上线的软件是符合客户预期的。在敏捷开发方式中，每一次迭代结束都可以交付一个潜在可发布的软件给客户。不过实际过程中很可能我们走了迭代，但是上线之前还是必须通过客户的 UAT。那 UAT 的时候 Team 是继续进行迭代开发呢？还是停下来服务 UAT？我们采取的方法是并行。Team 迭代继续，在迭代 timebox 范围内 PM 和 BA 参与组织客户进行 UAT。这期间提出的 feedback 可以和后续迭代的梳理会一起讨论 backlog 的优先级。同样可以和客户讨论是否需要替换后续功能或者增加额外功能费用。还有一点，结合项目和 Team 的实际情况，和客户协商，UAT 可以在几次 Sprint 后组织一次。

Release 时间如何推算

我这个项目有 3 个大的阶段上线时间，一开始可以采用用户故事地图的方式，将标书中的初始需求用用户故事的形式排列到一个共享位置，例如一个 Excel，或者一个物理看板上，或者 Miro 这种电子看板上。步骤如下：

1. 和客户排列初始用户故事的优先级。

2. 根据用户期望的 Release 时间画线。

3. 通过前三次迭代，估算出 team 单次迭代的速率。例如：单次能够完成的 story point 或者 story 个数。人天也可以，只要是团队熟悉和认可的。

4. 用速率推算剩余用户故事需要的迭代次数，并在用户故事地图上标记出来哪些用户故事包含在哪次迭代中。

5. Share 用户故事地图给客户，并跟随迭代随时调整新增或者替换掉的用户故事。

6. 用用户故事地图作为可视化平台，讨论可行的 Release 时间。UAT 时间也可以在这上面进行讨论。

迭代期间除了 Scrum Event 还需要什么

我们 Scrum 的 5 个 Event 都是正常来做的。不过由于客户的情况无法参与和 Team 一起。所以都是 Team、BA、SM 一起在做 Scrum 的活动和 Event。客户方干系人除了梳理会参与需求讨论和 Backlog 优先级排列外，还通过传统项目方式的 Event 来了解项目的进展情况。例如：每周的项目同步会。每个月的高阶项目干系人参加的项目汇报会等。梳理会结合两个传统的项目同步会组成和客户的同步透明的环境。对项目整体进展随时调整打下了基础。

写在最后

本文是对一个进行中敏捷项目的阶段性总结，对于团队级的敏捷实践，项目和产品开发没有不同，都是一样的，所以本文没有过多描述。希望通过梳理，将真实的敏捷项目和产品开发实践中的不同点进行整理。同时也能给小伙伴们带来一些参考。

【欢迎关注我的博客】