中兴通讯某分组产品敏捷转型实践

本产品从2014年开始正式推行敏捷转型，到2016年实现产品级敏捷，大概用了两年时间。本文是根据我在中兴通讯这两年的经验做的总结，见识比较肤浅，且大部分是靠回忆写下来的，免不了存在一些不一致的地方。

一、     敏捷转型方案

1     项目概况

•       产品用途：中国移动IPTN承载网络传输设备

•       项目团队：开发120人+测试30人

•       产品需求数（Feature）：约500条

•       用户故事数（Userstory）：约3000条

•       新开发单板：10块

•       新增修改代码：约300W行

•       测试用例数：自动化7000+手工3000

•       研发周期（立项到设计定型）：约1年

2     转型思路

•       研发过程遵循公司HPPD研发过程框架，结合CMMI过程域，推广敏捷实践

•       敏捷推进工作遵循从团队级敏捷向项目级敏捷、产品级敏捷演进的思路

–      团队级敏捷

•      定位于软件开发团队内部，团队7-15人，涉及软件开发与系统测试部

•      敏捷实践范围局限在团队范围，团队间实践内容和能力水平差异性较大，团队间协同工作能力弱

–      项目级敏捷

•      定位于PDT内研发组工作，以研发项目为载体，涉及规划部、软件开发部、系统测试部、中试部等多个角色和团队

•      敏捷实践的范围拓展到整个研发项目层面，适用于强项目组织的敏捷开发团队，弱化或取消了部门

•      追求多角色、团队协同工作能力，以提升项目研发质量和效率为目的

–      产品级敏捷

•      定位于整个PDT团队和HPPD产品研发全流程

•      敏捷实践范围涉及到PDT团队各个领域

•      以市场需求驱动、高效内部成本和风险控制为主线、以客户价值实现为中心的产品研发过程

3     组织结构调整

•       改变以前的矩阵式，每个团队都由SM+PO+Team组成，形成特性团队

•       SM：从开发经理、测试经理、SE或其他业务骨干中产生

•       PO：一般是熟悉业务的技术骨干，如SE

•       Team：含开发（软件、逻辑、微码）、测试

4        SM与PO的职责

•       SM职责：

–      引导各项Scrum活动

–      与团队一起向PO承诺迭代的输出物

–      跟踪迭代内的任务进展，带领团队按时完成迭代任务目标

–      管理与其他团队的依赖，团队的外部协调、对外接口

–      帮助团队移除工作中障碍

–      和团队一起做绩效考核，听取团队的声音，尊重团队意见

–      关注团队能力提升，包括团队成员的业务技能和软技能

•       PO职责：

–      维护Backlog，及时根据竞争对手、市场变化和客户反馈调整列表

–      需求不明确时与产品级PO沟通

–      从客户的使用场景中挖掘出对其最有价值的特性，并及时传达到团队

–      负责回答团队关于测试场景的问题，让测试场景尽可能地与客户使用场景一致

–      PO参加每日立会，回答业务问题，但不干预管理工作

–      参加需求梳理会，负责回答团队关于澄清需求的问题，确定userstory验收标准

–      参加计划会，和团队共同确定每个团队迭代输出的内容

–      参加评审会，在团队内验收工作产品，最好请到真实用户来验收

–      参加回顾会，搜集对产品方面的改进意见

5     敏捷框架

•       团队级：系统方案完成到系统测试结束，主要是特性团队

•       项目级：产品需求包确定到验证阶段结束，特性团队+测试团队

•       产品级：整个产品开发周期（运营与维护阶段前），特性团队+测试团队+硬件组+中试组+生产组+电源+工艺结构

6     敏捷方案

•       应用项目：所有软件、软硬件系统项目

•       立项标准：

–      明确关键需求

–      明确发布迭代周期或版本发布里程碑

•       项目组成：强项目组织的敏捷开发团队，弱化或取消了部门

•       交付条件：团队级敏捷满足系统测试准出条件（成果鉴定），项目级敏捷满足验证测试准出条件（设计定型），产品级敏捷满足小批量生产验证准出（生产定型）

7     敏捷模型

•       把产品的三个层级：产品级、项目级、团队级的活动整合在一起。

二、     敏捷转型实践

1     每日站会

•       每天早上8:45准时开始，按迭代轮流组织

•       团队轮流发言，站在看板前面，手上拿着故事卡讲

•       SM收集需要在项目SOS站会上沟通的问题

2     SOS

•       角色

–      各特性团队SM、QA、敏捷教练必须参加，PM视情况进行旁听和补充

•       沟通内容

–      上次会议结束到现在，我们组做了什么？

–      这次会议以后，我们组主要任务是什么？

–      我们遇到了什么困难，期望什么样的协助？

–      我们需要跨组解决的问题有哪些？

•       输出

–      待解决的问题列表和当前状态更新

–      好的建议和方法记录

•       不做什么

–      不在会上具体解决问题

•      无法快速定位的问题，确定跟进人和参与者，会后专题讨论，项目增加一张故事卡跟踪

•      复杂的技术和业务相关问题，提交给项目组，统一安排架构组讨论解决

•       其他

–      每人1分钟，总时间控制在20-30分钟

–      鼓励组间协作，鼓励跨组沟通

3     需求澄清/梳理会

•       需求是可以分层次的，就像计划可以分层次一样

•       Epic/Feature/User Story是用于区分需求颗粒度的标签

•       项目级PO与团队级PO一起分析Feature

•       一起确定Feature的优先级、工作量、责任团队、验收准则

•       项目级PO确定下一迭代的Backlog

•       团队PO将Feature拆分成US

4     迭代计划会

•       PO在会前将Feature拆分US，确定验收准则

•       PO讲解US，团队估算US工作量

•       团队认领US，并拆分出Task

•       PO确定迭代内完成的Spring Backlog

5     迭代回顾会

•       原则：

–      每个人对自己的工作都已全力以赴，都充分考虑了当前的情况，施展了自己的技能，调用了可调用的资源。

聚焦	散焦
探索	而不是辩护
对话	而不是争论
交流	而不是争吵
理解	而不是防备

•       议程：

–      PO验收团队任务

•      PO与团队一起验收SprintBacklog中的US，验收通过的关闭US

•      未完成的移出本迭代，并判断在后续哪个迭代完成，阻塞问题移到阻塞区

–      团队回顾总结

•      团队成员在便签纸上列出本迭代做的好的、需要改进的问题

•      SM将问题分类

•      团队成员投票表决出三个需要保持的，三个需要改进的

•      团队讨论出三个需要改进的问题的改进措施

6     持续集成

•       入库前的走查

–      入库前，先完成静态工具检查，通过后由结对走查人走查代码，走查通过后才合入代码。

–      代码合入日志严格按照模板填写：特性编号、影响分析、建议测试方法、修改人、走查人等信息。

•       每日架构组审查

–      架构组制定代码走查统一模板

–      每日17:00-17:30，架构师抽查业务组当天提交的代码，发现违反规则的提出整改意见，并录入到相关业务组的Sprint Backlog中

–      架构组每月月底对各架构师代码审查发现的问题进行分析汇总，对项目发布月度报告。

•       CI持续集成：

–      每天晚上12点触发Pclint、Klockwork、行覆盖率、复杂度等检测工具、全量构建、自动化冒烟测试，早上7点自动推送结果，空余时间运行全量自动化测试

7     分层测试

•       测试分层

–      Story层，开发自测

–      Feature层，业务组负责自测、联调，专业测试组负责系统测试

–      Epic层，专业测试组负责（方案测试）

•       测试策略制定

–      版本整体测试策略由版本经理和测试经理一起制定，包括版本计划、测试时间、测试规划，SM下发测试任务

•       新功能测试用例

–      开发自测用例、联调用例由PO牵头，输出场景，测试工程师编写用例，邀请规划SE参与评审

–      系统测试用例，由专业测试组牵头，邀请PO\工程\规划\TSE参与讨论工程场景和用例制定

•       测试流程

–      开发自测（自动化+手工）>联调测试>自动化冒烟测试>专业组系统测试（自动化+手工）>中试部验证》

8     DOD：

•       DOD：完成的定义，基于“随时可向用户发布”的目标，制定的衡量团队工作是否已经完成的定义，由团队和PO协商并达成一致。

•       DOD的好处：

–      共同协商的完成定义，是团队的自我承诺

–      清晰和明确的完成定义保证每次迭代是高质量的

–      DOD的关键点：

–      团队自协商

–      基于交付对象

–      不断改进

•       DOD分类：

–      每个环节都可以定义一个DOD，比如：需求DOD、开发DOD、CI DOD、测试DOD、计划会DOD……

9     度量

•       度你所做，为优而量！每个活动都可以定义相应的度量指标

•       尽量自动化度量，并实时展示

 

10  COP：

•       COP 实践社区

–      COP的工作协议由COP成员讨论得出

–      COP的运作要透明化，工作协议、活动纪要、产出物等要及时公布

–      COP倡导以面对面沟通为主，其他沟通方式为辅

–      COP通过成员的定期回顾不断的完善其运作机制

•       COP的角色

–      组长：对应COP的负责人，负责推动社区的发展和进步

–      专家：COP内获得大家认可的 ，COP不是被组织任命，而是被大家推举的，成为COP专家一是靠自身的技术影响力，二靠对COP的贡献

–      参与者：对相应技术领域感兴趣的同事

•       COP的运作方式

–      COP活动在固定时间举行，活动前，参与者把打算讨论的议题和建议发给COP组长，或者组长主动收集

–      COP组可以创建活动日历，向全员公开

–      员工在COP的贡献积累为“贡献点数”，在绩效考核时参考