硝烟中的scrum和XP——我们如何实施scrum读后笔记

Posted 2021-04-25 机器学习集结号

作为一个PM，TA有可能熟练掌握五大过程组，十大管理，能够有条不紊的推进管理项目，推进项目，沟通需求。但是，在高速发展的今天，如果TA不知道Scrum，那就未免有些out了，很可惜小蛮就是后者。为了不彻底被拍死在沙滩上，小蛮启动了学习大法，花了小半天搞定《硝烟中的scrum和XP——我们如何实施scrum》这本入门级的小书。本文主要技术了小蛮在本书的所学所想，主要包含一些相关概念、技巧技能以及相关经验。 

1. 相关概念

（1）关于Scrum；关于sprint；关于backlog；

Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。[1]

（2）什么是XP？Scrum与XP有什么关系？

XP是指极限编程，与scrum一样，也是敏捷（agile）开发流程的一种实践，在本书中对XP提到的非常少，想要了解极限编程的读者，可以参考[2]。就目前的调研来讲，XP作为一种敏捷开发实践，在于scrum的对阵中，已经偃旗息鼓了[3]，而且据笔者调研了众多项目经理岗位招聘职责，部分岗位职责中都会有“具备敏捷开发经验”类似字眼，部分会直接提到scrum，但是罕见出现“XP极限编程”相关内容。

2.Scrum的重要元素；

（1）Scrum的团队角色安排

产品负责人（Product Owner），是管理产品待办事项列表的唯一责任人，首要目标对团队的目标进行清晰的定义，用现在的行话是“敏捷状态下的产品经理，做对的事情”。

Scrum Master是团队中一个服务式领导，首要目标是负责确保 Scrum 被理解并实施，用现在的行话“敏捷状态下的项目经理，负责将事情做对，让Scrum中的每一项故事点都按照对的方向执行”。

开发团队，不解释，本书中认为团队规模3~8人最为合适，根据不同的团队实际（技术水平、磨合时间等）进行调整。（本书中，考虑将测试工程师纳入开发团队）。

（2）Scrum的三个工件

产品待办事项列表（Product Backlog），实际上就是产品的需求清单，是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源，产品负责人负责产品待办事项列表的内容、可用性和优先级。

Sprint 代办事项列表（SprintBacklog），是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划，就是当前sprint的规划目标的集合。

产品增量（Increment），增量是一个Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。

（3）Scrum事件

Sprint（Sprint本身是一个事件，包括了如下4个事件，具体内容可以参考书中相应章节），一个Sprint是指一个1周－4周的迭代，它是一个时间盒。Sprint的长度一旦确定，保持不变。Sprint的产出是“完成”的、可用 的、潜在可发布的产品增量。Sprint 在整个开发过程中的周期一致。

• Sprint计划会议（Sprint Planning Meeting）

• 每日站会（Daily Scrum Meeting）

• Sprint评审会议（Sprint Review Meeting）

• Sprint回顾会议（Sprint Retrospective Meeting）

3.本书框架

4.读完本书的两点感受

（1）内容全面，简约而不简单

覆盖了从基本定义，日常操作，复杂情形以及注意事项的所有内容；

（2）以实战为主，脱离教条主义

没有长篇大论的枯燥理论，用实际的sprint ，实际的sprintlog，实际的看板，实际的操作讲述scrum实践，作者作为一名充当多个角色的领导，在文中也展现出了自己的管理天赋，对于常见的棘手事情，通常会给出几种解决方案以供参考。

5.本书精典摘录

• 其实，敏捷不是说出来的，是干出来的。

  
  

• backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。

• 我们最终总结出了最喜欢的长度：三个星期。绝大部分团队的sprint长度都是三周。

• 产品负责人是领域专家，他可以指导团队的前行方向，但不应该被牵扯到乱七八糟的扯淡细节中。

个人认为，本书作为需要了解敏捷项目管理，需要实行敏捷管理团队，是一本不可多得的好书。

参考---------------------------

[1]http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

[2]https://baike.baidu.com/item/xp/776028

[3]https://www.zhihu.com/question/30547608