转载-企业团队赋能之敏捷实践

 

 

团队开创新局面

仁联集团科技版块新仁类产研团队成立两年之际面临新的挑战, 无论是领导还是业务团队提出更高的要求, 核心归纳如下:

• 一支40人的产研大团队，如何确保效能？
• 在资源无法均衡的情况下，如何可以实现效益最大化？
• 在快速迭代的版本下，如何确保资源按时输出？
• 一切事物无时无刻都在发生变化，如何快速响应变化？

只有顺应变化，应时而变，应势而变，不断开拓创新，一年前我们在CTO汪涯汪总已判断出团队改革的必要和紧迫性，大家在CTO的带领下开启了敏捷之旅，一年后我们来看看我们的敏捷建设成果:

敏捷之旅成果

企业全局普及敏捷

• 理念累积出自于生产制造, 建筑行业, 及不少工程领域
• 不仅仅限于产研, 各业务后勤部门都可以引入(当然, 实际的结果预料之中, 别的部门才不会理你)
• 企业效率提升, 不仅仅是产研的事, 是企业上下所有人都需要认知的事
• 是全球不少成功企业的思想实践和经验合集, 是适应变化快速交付的最佳实践之一

明确宏观排期及需求输入

• 所有产品实施，包含在项目制，迭代制中
• 迭代制两周一迭代，需求池化管理，依据公司战略及阶段性业务ROADMAP排定优先级
• 产品经理提前两周细化高优先级需求，并经过业务评审
• 产研在迭代期前探讨需求，提前介入风险及技术预研事项,
  资源按轻重缓急安排

需求宣导会

• 产品经理在会上宣导需求及背景，让团队成员了解需求的始末
• 对于复杂的场景，团队成员可以提出疑问，以便识别是否有问题
• 鼓励研发和测试质疑需求合理性和业务可用性，通过探讨需求，提高需求的质量，减少需求开发反复
• 通过及时解答反馈，提高团队成员的参与感

需求计划会

• 需求宣导后将反馈最终结果，对无法实现需求归纳总结，纳入后续需求池，待产品经理优化完善后再纳入迭代池
• 任务拆分到最小的可交付故事，评估故事点，并且让团队成员自行认领
• 鼓励团队成员跨职能开发，让成员可以不断学习和成长，以实现资源利用最大化(通常会在项目经理职责范围确立成员的开发范围, 有计划性的跨业务DOMAIN进行开发)
• 最后会上会明确Sprint目标，承诺交付范围

每日站会

• 沟通3部曲：昨天，今天，遇到了什么问题
• 让信息同步，所有成员都能知晓状态
• 一旦遇到阻碍，及时暴露出来，以最快的速度响应解决

 

 

 

 

限制Scrum团队的规模，提高沟通效率

• 大团队如果不拆分团队的话，排期冲突和资源利用冲突加剧，沟通协调成本剧增，整体效率会严重变低。
• 有计划地拆产品线，拆业务DOMAIN，拆核心模块，明确边界，确立团队职责范围
• 每个Scrum团队都有产品、开发和测试， 一般不超过10人，限制Scrum团队的规模，保证Scrum的效率
• 每日由项目经理（团队成员轮流当, 每个Scrum迭代也由项目经理把控整体, 也承担Scrum Master的职能）及时跟进和同步状态，确保项目进展健康
• 重大项目，独立看板，独立站会，确保大项目完成冲刺

每周周会，建立Scrum团队之间的协作机制

• 随着业务的发展，多个Scrum团队需要一起进行产品定义和确定技术方案，复杂的协同需要有机制来保证，每周周会就是Scrum团队的定期会议，在这个会议上，我们会讨论各个Scrum团队的进度，遇到的问题，跨团队协作，资源协调等等

需求规范化

需求评审规范化

 

 

需求交付周期

流程规范化

 

 

质量保证流程

• 冒烟流程。所有任务必须通过冒烟后才能提测，稳固代码质量
• 单元测试。各应用单元测试覆盖率最高的应用达到100%
• 自动化测试。核心业务场景自动化测试，确保产品质量。

敏捷迭代循环改进

• 定期回顾上一迭代期改进行动
• 上一迭代期研发效能指标
• 确定下一期改进行动
• 流程守护
• 版本owner培养

拥抱敏捷后的变化

• 明确的团队目标，无阻碍的交流环境，不断成长的心。
• 积极的心态，不再害怕变化，以不变应万变，以万变应不变
  
  

 

• 效能提升目标

除了产研运与业务部门之间协作的效率，产研间磨合的效率，研发团队本身对交付的改进也达到目标

 

 

 

 

 

 

 

 

 

 

 

 

 

本文转载自，侵权删：https://zhuanlan.zhihu.com/p/102081448

------ 文章知识无好坏之别，但有良莠之分，只要能为我所用皆为好文。 ------