Scrum入门

Scrum中定义有三个角色 产品负责人 ScrumMaster 开发团队 另外还会提到两个常见角色（经理和项目经理）在Scrum当中的职责。 产品负责人 职责 产品负责人最大的职责是为产品的投入产出比（ROI）负责，即最大化团队的投入产出比。在Scrum当中，由于Sprint是时间盒（即时间是固定的），且成本（软件开发中人力成本是最大的成本，其他忽略不计）也是固定的，那么最大化投入产出比就是如何做出最有价值的产品增量。 创建产品愿景 创建与维护产品Backlog（插播一句，Jeff Patton同学很不喜欢Backlog这个词，听起来产品还没有开始开发就落后了，如果谁有更好的词我们可以一起交流） 主持产品Backlog优化会（增加、删除、修改或细化用户故事，并根据需要进行排序） 协调干系人与开发团队之间的沟通 参加团队的Scrum会议 在Sprint计划会上和团队一起决定当前Sprint的开发内容 接受或拒绝团队的产品增量 决定何时发布 所需技能 根据上述的职责，作为产品负责人需要以下技能： 业务能力 - 产品负责人首先要对产品以及所在行业有较深的认识和理解。这样才能根据业务价值来对不同的需求进行排序，或者对产品的整体方向有感觉。 技术能力 - 虽然产品负责人不必是技术专家（SME），但懂一些技术对于需求排序、拆分、优化是有很大帮助的，特别是在参加Sprint计划会的时候，可以很容易的理解开发团队。 决策力 - 产品负责人接受或拒绝产品增量，那么对于产品负责人他就要有授权，可以决策哪些是可以接受，哪些要拒绝。以及决定什么时候发布，什么特性优先级高等等重要事项。 沟通协调能力 - 产品负责人需要有很强的沟通协调能力，因为他是干系人与团队之间的润滑剂。 谁来担任 简单的回答，可以完成上述职责并拥有上述技能的人都可以来担任产品负责人。较常见的是产品经理担任。我见过的还有项目经理、架构师等不同岗位转型为产品负责人的。 ScrumMaster 职责 Scrum权威 - ScrumMaster是团队中最熟悉和了解Scrum框架的，并可以根据实际情况对团队进行指导。 辅导团队和产品负责人 - 如果产品负责人或团队不知道该怎么办，ScrumMaster需要提供相应的辅导、培训或支持。 保护团队 - 在一个Sprint中，ScrumMaster要保护团队不受打扰，可以专注于Sprint目标和承诺。 移除障碍 - ScrumMaster要善于发现障碍，并可以帮助团队移除障碍，包含但不限于个人障碍，团队障碍以及组织级的障碍。 变革大师 - ScrumMaster不仅要在团队内实行Scrum，还要能够影响并促进组织或整个公司内的变革。 所需技能 热情 - 首先ScrumMaster需要是一个有热情（Passion）的人。热爱并喜欢自己的工作，充满激情，并且可以感染周围的人。 主动学习 - 学习是永无止境的，作为ScrumMaster，需要主动的学习，补充自己的短板，刻意的练习，成为真正的master（大师）。 善于提问 - ScrumMaster不一定是所有问题（尤其是技术上的）的大师，但他一定要能善于启发团队思考并行动。这往往是通过提问来实现的。好的问题可以让团队清晰的认识到自己。 耐心 - 对于变革要有耐心，可以容忍团队犯错误。让团队在错误中学习并成长。 协作沟通 - ScrumMaster需要和团队沟通，了解个人障碍和团队障碍。也需要和团队外的干系人沟通，来排除障碍或了解他们的期望。总体说，ScrumMaster需要较强的沟通能力（和产品负责人类似）。 公开透明 - Scrum的三大支柱之一就是透明。因此作为ScrumMaster也需要公开透明，不仅仅是团队的进展要透明，所有的沟通交流也需要是透明的。只有信息透明，才能产生信任与尊重。详情可以参考《克服团队协作的五种障碍》 谁来担任 常常问道的一个问题是，ScrumMaster是全职工作吗，可以兼职吗？对于一个新组建的团队，我强烈建议全职的ScrumMaster。因为有很多的事情需要ScrumMaster来做，参考上面的职责。如果是成熟的团队，ScrumMaster可以兼职，但不建议既做ScrumMaster又做开发工作；但可以同时是两个团队的ScrumMaster，因为工作类型是相似的。

Scrum入门基础系列之Scrum框架 读过几本Scrum书的人，想必对于Scrum框架都可以如数家珍，如Scrum的3个角色，5个会议，3个工件。在展开这些内容之前，我想先介绍一下Scrum的价值观以及敏捷宣言。 敏捷宣言[1] 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体与互动 胜于 流程与工具 可工作的软件 胜于 详尽的文档 客户协作 胜于 合同谈判 响应变化 胜于 遵循计划 也就是说，尽管右项有其价值，我们更看重左项。 Scrum价值观[2] 专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。 勇气：我们需要勇气去迎接各种挑战。 公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。 承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。 尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。 Scrum框架 Scrum框架是不是银弹，也不是灵丹妙药。实行Scrum不需要团队成员都是精英。因为Scrum只是快速的把问题暴露出来，以至于我们无法忽视和忍受它。Scrum框架是一个团队的流程框架，由自组织的团队进行改进完善。该框架主要包含角色，会议和工件三大部分。 角色 产品负责人（Product Owner） - Scrum中对产品负有全部责任的唯一人。产品负责人需要创建和维护产品Backlog，并需要参加必须的Scrum会议，如Sprint计划会、Sprint评审会等。详情可以期待下一篇博文（Scrum角色）。 ScrumMaster - 这个角色是Scrum框架提出的新角色。他需要对整个Scrum框架非常熟悉，还需要是一个变革大师。在Scrum中，ScrumMaster没有授权，而还需要完成很多的工作，如移除风险等。 开发团队 - 开发团队指的是跨职能的自组织团队。开发团队中可能包含开发人员、测试人员、用户体验工程师、数据库专家等。开发团队负责完成端到端的工作，从而在Sprint结束的时候可以完成产品增量。 会议 Sprint计划会 - Sprint计划会主要分为2部分：做什么和如何做。Scrum团队一起决定他们要做什么，以及如何构建、测试承诺的工作。在计划会议过程中，产品负责人的重要职责之一是解释澄清模糊的需求。最后的产出为Sprint目标和Sprint Backlog。详情敬请期待后续博文。 每日例会（Daily Scrum） - 每天的15分钟站立会议。Scrum团队一起回答三个问题：从上一次例会到现在我完成了什么（重点在于是否完成承诺，以及暴露风险）？从现在到下一次例会我计划完成什么（重点在于承诺）？有什么风险或障碍（尽早暴露问题风险）？ Sprint评审会（Review） - 在Sprint评审会上，产品负责人接受或拒绝团队完成的用户故事。（注：产品负责人应该在平时的工作中进行评审，而不是只在评审会上进行这些工作）这是一个非正式的会议，准备时间不要超过1小时。（注：但必备的准备工作还是需要的） Sprint回顾会（Retrospective） - Scrum团队一起检视和调整他们的工作方法，以达到成熟高效的自组织团队。 产品Backlog梳理会（Product Backlog Refinement） - 由产品负责人组织协调干系人或团队一起进行产品Backlog梳理，包含但不限于新增需求，删除需求，修改需求，拆分需求，改变需求顺序等等。 工件 产品Backlog - Scrum中需求存放的清单，常见的格式为用户故事，也可以包含其他类型的内容，如缺陷、用例、史诗故事等。 Sprint Backlog - 由Sprint中承诺的故事和相应的任务组成。在Sprint过程中，团队每天都会更新Sprint Backlog，在每日例会上讨论并同步有关Sprint Backlog的信息。