本文是关于作者在To B 项目敏捷开发的一点个人心得，希望能对处于相同环境的朋友提供一点参考，一起来文中看看~
通过尽早和不断交付有价值的软件满足客户需要——敏捷宣言。
笔者于2015年第一次接触敏捷开发且第一次碰触Scrum，当时scrum的理念确实为笔者的打开了一扇开发的窗，但结合自身境遇，仔细分析后认定敏捷比较适合于做内部的产品，不适合做ToB解决方案型项目（以下简称Tob项目），原因如下：
立场：Tob项目甲乙双方关系为被服务与服务的关系，甲方希望最少成本做最多的事，节约成本，乙方希望项目可以利润最大化，提高收益。
背景：ToB项目甲方期初需要经历项目可行性研究、项目立项、项目评审等过程，前后需准备大量的描述材料，如果实施结果与预期目标偏差过大，会被审计组审计。同时，也会对项目申请人的能力产生质疑，因此客户的建设理念往往倾向于传统瀑布模式，注重交付成果的一致性。
合同：ToB项目以固定总价合同模式居多，固定总价合同前期就有明确的范围、进度、成本、交付成果等要求。
观点：ToB项目团队往往会由甲乙双方共同组成，双方背后都有不同的利益组织，因此观点比较复杂，针对共同目标双方患难与共，但同时又因各为其主，会在一些细节上产生分歧，尤其是在变更的时候，因为会涉及到成本、进度等要素，弄得每一次变更都像打架一样。
倾注：ToB项目建设往往由甲方业务方申请，IT部门承建，受益人与负责人不为同一人，由于利益、职责不同，甲方负责人的投入热忱也不尽相同。
因此ToB解决方案型项目使用敏捷模式可谓如履薄冰，稍有不慎便有需求蔓延、影响交付的风险。
2018年1月，笔者所在的公司承接了某地产龙头的云视频平台建设项目，该集团信息化事业部有着比较丰富的项目建设经验，本项目为总价合同模式，预计建设周期9个月，合同签定之初甲方项目总监就要求项目快速上线，尽早满足该集团业务诉求，优惠条件是项目组可以不用驻场开发（笔者所在公司与项目现场相隔千里）。
笔者权衡再三，与甲方约定项目采用敏捷开发模式，并且达成了具体落地方法，具体如下：
一、架构职责
架构职责：由甲方项目总监、产品经理、乙方项目经理、产品经理、开发经理、测试经理组成项目核心团队。
甲方项目经理：负责需求筛选，优先级排序，协调甲方技术、业务人员配合本项目建设等工作；
乙方项目经理：负责编写WBS、编制项目计划、信息同步、风险跟踪等工作；
乙方产品经理：负责需求收集、梳理、分析、原型制作、需求确认、改进方案等工作；
乙方技术经理：负责构建系统架构、指导开发、外部接口对接、重点问题攻坚工作等工作；
乙方测试经理：负责组织测试规划、方案、用例、BUG管理、培训等工作。
二、拆分阶段
拆分阶段：将原9个月的建设周期拆分成三个阶段，即每三个月一个大阶段，每阶段里再拆分成3个小迭代，每个小迭代均提供有价值的交付物。
每个大阶段提前三周做需求收集、需求分析、需求排序等工作，规划好本阶段的工作内容，以及完成第一个小迭代的交互稿细化；
每个小迭代前两周做需求收集、需求分析、需求排序、交互稿细化等工作；
每个小迭代内如无特殊情况，不做项目变更；
第一个阶段不做小迭代拆分（建设初期初始化的事情太多：如确定需求基线、整体架构设计、硬件资源、网络资源、域名、安全检查、各种评审以及新团队成员组建磨合等）；
三、沟通模式
沟通模式：现场会议、电话会议、IM、邮件等。
会议纪要：邮件形式面向项目组与会人员及双方领导，每次会议。
阶段成果确认：邮件形式面向对应负责人及双方领导，每阶段。
乙方内部敏捷沟通模式：站会、周会、回顾会。
各大阶段前两周，甲乙双方当面交流，一般交流周期为一周（很重要！）。
四、需求范围
需求范围：以需求规格说明书为需求基线，并辅以需求变更单.
以需求规格说明书为需求基线；
需求收集、需求分析、需求排序阶段甲乙双方共同参与，并达成共识；
统一思想，拥抱变更，重点强调本项目会有较多变更，大家心里上一定要认同这一点，当出现变更时，双方一同分析变更影响（含工作量、工期、建设节奏等），达成共识后，迅速对变更需求给予确认；
在双方达成共识的基础上，该项目基本按即定计划执行，项目整体提前1个月，即用时8个月建设完成，在完成的同时也整理一下个人的心得。
互信：互信非常重要，本项目由于分小迭代上线，在对最终用户需求做出及时反馈的同时，项目组也面对着大量的变更，是否符合变更，变更工作量多少均达成共识，虽然大家是为一个项目服务，但背后利益群体不同，达成互信非常不易；
互助：本项目在建设的过程中除遇到变更外，因甲方客观情况需要，曾尝试过双周迭代，项目组很好的满足了甲方高层级的业务需求，双方的友谊更进了一步；
互补：甲方项目经理出身产品设计，本项目中兼了甲方产品经理和甲方项目经理两个职务，由于项目管理经验和技术能力相对薄弱，项目组会对该项目经理给予一定的帮助，一同面对项目中的问题，帮助其快速成长，该项目经理成长后，在很大程度上对项目起了推动作用；
迅速确认：由于本项目有大量的变更，为防止这些变更遗漏、事后无法追述等情况，在确定变更后，双方迅速确认；同时，阶段性成果也要迅速确认；
节奏：本项目直接参与建设人员平均人数为30人，峰值时达到45人左右，如何保障大团队能一直高效的工作，节奏很重要，项目组通过提前规划需求、提前出交互稿的形式，使大团队每轮迭代后均后新任务执行；
不足：ToB项目，尤其是首次合作的ToB项目，项目的约束条件会很多，干系人沟通渠道的很大，需要用大量的时间来识别及应对，而此时实现短期项目上线，进度风险特别大，本项目第一阶段就因沟通不够充分，导致延期上线一周。
最后，此次项目虽然通过敏捷的方式取得了成功，但个人总结ToB项目在总价合同的模式下，想要实现敏捷必须要具备以下几点要素：
甲方IT建设的成熟度要高；
双方理解并认同敏捷的模式；
乙方项目经理要有很好的控场能力，并且对项目的走向有一定的前瞻能力。
以上为我在To B 项目敏捷开发的一点个人心得，希望能对处于相同环境的朋友提供一点参考。
