读《敏捷项目管理与PMI-ACP应试指南》第9章笔记

读《敏捷项目管理与PMI-ACP应试指南》第9章笔记

本章主要介绍了Scrum、XP、Lean等这些敏捷方法论主要的家族成员，逐一介绍了它们的选择、方法、工具、角色和责任。

它们以不同的方式拥护着敏捷宣言，通过不同的实践支持着敏捷宣言的价值观和原则。

9.1大致介绍

现实用的多且复杂。

对于考试而言，主要就是Scrum（司克兰）、XP（极限编程）和Lean（精益）。

各自在市场份额：Scrum-56％，XP-5％，Lean-3%。

让我们从最普及的方法Scrum开始

9.2 Scrum

Scrum诞生于于20世纪90年代，主要创始人是Ken Schwaber（肯·斯瓦布）和Jeff Sutherland（杰夫·萨瑟兰）。

Scrum的三大支柱是：可视性、检验和适应性。这三大支柱，既作用于过程，也作用于结果。换句话说，产品及其创造产品的过程，应该是透明和高度可见的（可视化程度高）、可检验的（可度量的），并且能够快速适应环境（可以落地的）的。

Scrum是高度迭代的方法，Scrum活动遵循简短、快速迭代和增量交付，持续改进的原则。

Scrum主要的运作机制简述如下：

组织层面：

开始时，产品负责人首先需要用通俗的语言介绍整个项目的总体愿景。关注系统是什么，确保系统实现的每个环节都是可售功能的一部分。

接下来，产品负责人需要讲产品需求列在一张优先级列表（产品未完项）中。产品未完项最初由产品负责人根据什么产品需求可以产出最高价值来决定，后面的产品未完成项会不断地变化。

这些产品未完成项被划分到不同的发布版本中，这些发布版本是需求的集合。

团队层面：

当产品未完项确定后，团队把优先级高的未完项挑选出来。形成一个冲刺（Sprint，Scrum的世界里，把“迭代”称为“冲刺”）。

Scrum以冲刺的形式开始工作。

冲刺，是以“计划”会议为起点标志的30天迭代。

在我们的Scrum世界里，规划会议最好不要超过8小时（8小时，看起来很长时间了）。

规划会议：上半场，产品负责人与团队讨论优先级最好的需求特性。大家讨论，并向产品负责人提问题，最后挑选出在在30天冲刺期内完成的功能；下半场，团队规划好冲刺蓝图并定义任务层面的细节，把冲刺期期内计划完成的用户故事记录在冲刺未完项中。

规划会议后，每日站立会议。不超过15分钟，固定的时间和地点进行。问三个问题：⑴上次会议后，你做了什么？⑵你今天计划多什么？⑶你遇到了什么问题？

冲刺阶段的最后，有个半天（4小时）的冲刺审查会（评审会、审核会）。团队和关键相关方都会参加，目的是展示所开发的“新产品”功能并讨论下一个冲啊包含的需求特性。

团队构建可交付功能到产品负责人，产品负责人决定该交付的功能是否应该立即发布，还是再推迟到将来的版本发布。

最后的最后，冲刺还有一个回顾会议。团队自行讨论，关注点在于哪些功能已经实现，哪些需要改善并在Scrum框架内做出调整，

注意：产品负责人不会参加冲刺回顾会议。

9.3 Scrum角色

1.产品负责人（PO）

  主要职责有7点：

①作为干系人的代表（通常代表重要客户）。

②与项目外界沟通的联络员。

③PO和发起人合作确保项目有足够的资金投入。

④帮助创建需求特性和发布计划的初始未完项。

⑤负责编写用户故事。

⑥梳理产品未完项并对其进行优先级的排序。

⑦参加迭代规划会议的上半场，和团队讨论用户故事（从功能的角度）

2.团队

主要工作是开发产品。

特点：通用的专才，成员之间可以灵活互换工作内容。

3.ScrumMaster

主要职责：

①帮助团队遵循（遵守）Scrum流程。

②帮助新入职员工了解Scrum是如何在项目中运作的，

③负责将Scrum融入整个企业文化中去，

④鼓励其他员工去引导每日站立会议。而不是只有他自己完成。

9.4 极限编程（XP）

第一、极限编程的运作流程是怎么样的呢？

（1）客户定义用户故事，且不断更新故事。

问：客户通过用户故事来定义最初的应用程序功能有什么目的呢？

答：用户故事可以通过捕捉“小规模场景”来“设想”用户与系统客户（注意：什么是系统客户？）是如何交互的。

（2）团队成员把用户故事分解成故事点。

（3）软件开发结对编程。一个程序员负责编写代码工作，另外一个负责观察高层次问题，如集成和功能当方面问题。

第二、极限编程的规则

XP项目的迭代周期短于典型的Scrum迭代，一般是1周到3周不等。

迭代运作方式

（1） 迭代开始（规划会议）时，

    ①团队和客户会讨论客户希望得到的用户故事和需求特性。

      ②团队把这些用户故事和特性分解成特定的任务，并把工作任务分配给具体人员。

      ③开发人员将通过分配故事点来估计工作量。

（2）开发-测试驱动型开发

      客户定义验收和测试标准后，程序员结对一起开发，开发完，测试完，客户验收完，用户故事就可以应用了

（3）工作系统在迭代结束时不断交付。由于迭代持续每周一次的频率，通常不会每周都向最终用户交付更新，有时会将一个完整的迭代版本发布给用户群。

注意：

1、每次迭代都要高质量的交付。

2、短迭代周期鼓励团队做尽可能少的工作以及“一次仅做一次”，来提高效率（类似精益里“拉动”的思想）

9.5 极限编程的12个实践

极限编程（XP）的核心

1.计划游戏。目标：实现价值最大化

2.小版本。聚焦最小可售功能（MMF）

3.比喻。换一种思维，看问题。激发

4.简单设计。简便、效率高。

5.测试。完全彻底的测试。

6.重构。

7.结对编程。

8.集体代码所有权。团队集体负责制。

9.持续集成。

10.可持续开发速度。想办法保持一种持续的节奏和速度。

11.现场客户。一定要有客户或客户代表在工作现场。

12.编码标准。

初始XP团队用以下6种方法：

计划游戏

小版本

测试

结对编程

重构

持续集成。

其他6种，随着后面团队成熟了，再去推广。

9.6 极限编程的角色

1.XP教练。支持团队，不是发号施令的领导或老板。

2.XP客户。产品专家。参与团队的计划游戏，帮助团队确定需求优先级。

3.XP程序员。结对开发。

4.XP跟踪员。根据项目计划来评估和沟通进展情况，3项基本工作是跟踪发布计划、迭代计划和验收测试。

5.XP测试员。帮助客户获得验收标准、转换为验收测试，执行测试并把测试结果反馈给整个团队。

9.7 精益

精益软件开发体系源于丰田和其革命性的生产制造流程项目。7个原则也适合于软件开发。

1.消除浪费。

用价值流程图分析活动，识别其中的浪费。常见的浪费有：多余的形式会议、规划、文档、测试或某项功能。

2.强化学习。

精益追求持续学习和改进。

通过更短的迭代和迭代的直接耦合测试，不断调整过程去适应环境；用简短的实验去发现达成目标的最好方法。

3.尽可能晚做决策。

  敏捷拥抱并适应变化的，晚做决策，这样精益能保持更多开放的选择，使团队更好地应对变化。

4.尽可能快交付。

尽可能快地把可靠功能交付到客户中，并获取客户反馈，再将这些反馈在系统中实现。

5.授权团队。

精益项目是授权团队决策的，这些决策由整个团队来负责。

6.构建完整性。

重构也是一个构建完整性的一部分。重构本质上是重新组织代码，并使代码在理念上与解决方案一致，这是达成任务最有效方式。

7.全盘检视。

（1）需要对解决方案做整体的研究，而不是仅仅盯着技术那一块。

（2）要求团队了解解决方案是如何实现市场化的。

（3）甚至需要了解最初引发项目的商业需求。

总结：第9章，重点介绍了敏捷家族的分支如Scrum、XP极限编程和精益。每个方法的角色和其职责要搞清楚。