我之前的敏捷实践一直都是在产品团队尝试的。一直觉得敏捷更适合产品开发，项目不适合。主要原因之一是项目的愿景更多的是客户自己的，自研产品视角就会有所不同。从价值交付的角度，团队更有共鸣；而作为乙方做很难捕获到，另外项目周期相对固定，这会对敏捷所强调的试错等思想的应用造成很大的压力。不过今年正好参与了一个项目，客户恰恰点名要应用敏捷方式来运行。作为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这种电子看板上。步骤如下：
- 和客户排列初始用户故事的优先级。
- 根据用户期望的Release时间画线。
- 通过前三次迭代，估算出team单次迭代的速率。例如：单次能够完成的story point或者story个数。人天也可以，只要是团队熟悉和认可的。
- 用速率推算剩余用户故事需要的迭代次数，并在用户故事地图上标记出来哪些用户故事包含在哪次迭代中。
- Share用户故事地图给客户，并跟随迭代随时调整新增或者替换掉的用户故事。
- 用用户故事地图作为可视化平台，讨论可行的Release时间。UAT时间也可以在这上面进行讨论。
迭代期间除了Scrum Event还需要什么
我们Scrum的5个Event都是正常来做的。不过由于客户的情况无法参与和Team一起。所以都是Team、BA、SM一起在做Scrum的活动和Event。客户方干系人除了梳理会参与需求讨论和Backlog优先级排列外，还通过传统项目方式的Event来了解项目的进展情况。例如：每周的项目同步会。每个月的高阶项目干系人参加的项目汇报会等。梳理会结合两个传统的项目同步会组成和客户的同步透明的环境。对项目整体进展随时调整打下了基础。
写在最后
本文是对一个进行中敏捷项目的阶段性总结，对于团队级的敏捷实践，项目和产品开发没有不同，都是一样的，所以本文没有过多描述。希望通过梳理，将真实的敏捷项目和产品开发实践中的不同点进行整理。同时也能给小伙伴们带来一些参考。
