中兴通讯某分组产品敏捷转型实践
本产品从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的贡献积累为“贡献点数”，在绩效考核时参考