本文是关于作者在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 项目敏捷开发的一点个人心得,希望能对处于相同环境的朋友提供一点参考。