华为云DevOps系列之 —— 持续规划与设计（五）团队与协作

团队与协作

Scrum 中的角色

Scrum 团队 - 角色分工概览

Product Owner - 产品负责人

• 客户代表
• 定义所有产品功能
• 决定产品发布的内容以及日期
• 对产品的投入产出负责
• 根据市场变化对需要开发的功能排列优先顺序
• 合理的调整产品功能和迭代顺序
• 认同或者拒绝迭代的交付

Product Owner - 特征

• “一” 个人，而非一个委员会
• 被授与产品（“做什么”）决策权
• 承诺投入到合作中并且在需要时被团队找到
• 企业家、系统思考者、创新者
• 驱动产品走向成功
• 提供产品领导力
• 和所有人合作
• 理想情况下是真正的用户来担任
  

Product Owner - 职责

• PO是？
  • 产品经理？愿景和方向，结果负责
  • 需求分析？业务分析和需求分析
  • 需求管理？维护、终止和变更
  • 项目管理？优先级排序和项目状态跟踪
  • 质量保障？检查产品结果
  • 客户代表？产品体验/接受拒绝
  • 对外职责？老板、客户和用户、营销和销售…

Product Owner - 使命

• 建立产品愿景
• 负责最大化投资回报
• 从”为什么“开始
• 定义产品功能（”做什么“）
• 确保迭代输出准备好
• 根据反馈，为更好地实现业务目标将产品Backlog排定优先级顺序和调整需求代办清单
• 决定版本发布日期和内容
• 参加各个Sprint事件（计划会议和评审会议）
• 接受或退回工作成果

Dev Team - 开发团队

• 经典团队拥有 5-9 人
• 跨职能团队
• 全职投入且长期存在
  • 特殊职能可以例外（例如，数据库管理员）
• 团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开发时发生调整
• 团队自我组织和管理
  • 没有管理者头衔
  • 全员负责制
  • 团队承担大部分微观管理工作并决定如何一起工作

Dev Team - 使命

• 与客户紧密工作在一起
• 决定迭代的工作容量
• 每个迭代交付产品增量
• 对”怎样做“和交付质量负责
• 管理 Sprint Backlog 并跟踪进度
• 找到团队内部合作的最佳方法
• 与其他团队及相关方协作
• 持续自我改进

Dev Team（1）跨职能团队

Dev Team（2）特性团队

Dev Team（3）全栈工程师

Scrum 团队文化

• 共赢的文化
• 团队成功
• 个人发展
• 立足现实
• 挑战极限
  

Scrum Master 职责

• 并非传统的团队或项目经理，没有管理头衔和权力
• 是一个具备影响力的仆人式Leader（非Manager）
• 面向管理层时代表团队；面向团队代表管理层
• 领导团队完成Scrum的实践以及体现其价值，不代表团队做出决定
• 排除团队遇到的困难
• 确保团队的胜任其工作，并保持高效的生产率
• 使得团队紧密合作，使得团队个人具有多方面职能的工作能力
• 保护团队不受到外来无端影响，被授权的“牧羊犬”
• 团队和组织变革的代理人
  

Scrum Master 核心能力

Scrum 事件

• Sprint
• Sprint 计划会议 Sprint Planning
• 每日 Scrum 站会 Daily Scrum
• Sprint 评审会议 Sprint Review
• Sprint 回顾会议 Sprint Retrospective

Sprint

• Scrum 项目周期以一组迭代周期 ”Sprints“ 组成
  • 可以和极限开发的迭代周期类比
• 典型的迭代周期为 2-4 周或者最多一个自然月
• 一个固定的周期能够创造出项目的更优美的节奏感
• 产品的设计，开发，测试全部都在一个迭代内完成

一个迭代周期的长短的设定取决于您能够保障多长时间需求变化不影响到产品开发

Sprint 计划会议

• 什么是 Sprint 计划会议
  • 每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品 Backlog，输出是团队迭代 Backlog
• 分成两个阶段
  • 第一个阶段：选取用户故事，确定迭代目标
    • PO 与团队一起从 Product Backlog 中选择待完成的用户故事
  • 第二个阶段：拆分任务，创建迭代 backlog
    • 团队拆分和确认任务，给出工作量估算
• Sprint 计划会议的好处
  • 通过充分讨论，使团队成员对任务和完成标准理解一致
  • 团队共同参与，促进团队成员更认真对待自己的承诺
• Sprint 计划会议的关键要点
  • 充分参与：Scrum Master确保PO和Team充分参与讨论，达成理解一致
  • 相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求（2-4周）
  • 确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序

每日 Scrum 站会

• 执行
  • 每天都会开
  • 15分钟结束
  • 站着开会
• 不是为了解决问题
• 避免无关的讨论
• 更新 Sprint Backlog，包括增减任务项、更新任务进度和状态
• 每日站立会议的好处
  • 增加团队凝聚力，产生积极的工作氛围
  • 及时暴露风险和问题
  • 促进团队内成员的沟通和协调
• 每日站立会议的关键要点
  • 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯
  • 高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）
  • 问题跟踪：Scrum Master应该记录下所有的问题并跟踪解决
  • 每日站立会议促进团队沟通协调，及时暴露问题。

Sprint 评审会议

• 团队按照Backlog中的问题，逐个地介绍这次Sprint的结果，和演示新功能
• 如果产品负责人想要改变功能，添加一个新问题到产品 Backlog 中
• 如果对功能有一个新的想法，添加一个新问题到产品 Backlog 中
• 如果小组报告项目遇到阻碍现在还没能解决，把该障碍加入到障碍 Backlog
• 团队达成对这次 Sprint 的结果和整个产品的开发状态的共识
• 展示“真实”的产品：Team 应在真实环境中展示可运行的软件，判断是否达到“完成”标准
• 收集反馈：PO 根据验收情况及客户反馈意见，及时调整产品 Backlog
• 迭代验收的好处：
  • 通过演示可工作的软件来确认项目的进度，具有真实性
  • 能尽早的获得用户对产品的反馈，使产品更加贴近客户需求

Sprint 回顾会议

• 回顾会议
  • 在每个 Sprint 结束后，对于当前的迭代周期做一个阶段性的总结，包括好的方面和不好的方面，帮助团队在下一个迭代中扬长避短，对于一个团队的健康发展很有好处
• 主要指导原则
  • 不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下， 都尽其所能做出了最好的成绩
    
• 一般可以从以下几个方面来进行回顾
  • 开发团队效率如何
  • 开发团队合作如何
  • 项目进展曲线是否平衡
  • 开发团队前端和后端的分工如何
  • 测试团队的缺陷报告率如何
  • 开发周期中有没有被严重 Block 的因素
  • 有没有需求方面的不明确导致 Rework
  • 在任务分配方面有没有不均衡，导致个别人太忙或者太闲
    

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊