敏捷scrum入门

SM官网：https://www.scrumcn.com/agile/scrum-knowledge-library.html

敏捷文章：https://www.scrumcn.com/agile/scrum/category/scrum-agile-practices

 

一、敏捷开发

1.1 什么是敏捷？

敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

1.2 什么是敏捷开发？

敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。

自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

1.3 敏捷开发简史

20世纪90年代初，一些轻量级的软件开发方法越来越受到公众的关注，这些方法包括：
1991, Rapid Application Development（RAD）
1994 Dynamic systems development method (DSDM)
1995, Scrum
1996, Crystal Clear ，Extreme Programming (XP)
1997, Feature-driven development（FDD）

这些方法论强调了开发团队和业务干系人之间的密切合作；

商业价值频繁交付；

紧密合作的自组织团队，以及代码匠艺、验证和交付代码的巧妙方法。

2001年，17位软件开发人员聚集在犹他州的Snowbird，讨论他们的共同想法和各种软件开发方法。经过讨论他们达成了在价值观和原则的共识，并共同发布了敏捷软件开发宣言和相应的十二条原则，宣告了敏捷开发运动的开始。会议之后，敏捷联盟成立，鼓励业界从业者进一步探索和分享想法和经验。

 

1.4 敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

1.5 敏捷开发十二原则

         我们遵循以下原则：

1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。                       ------项目
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。     ------项目
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。                       ------项目
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。                                             ------团队
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。    -----团队
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。                                 -----团队
7. 可工作的软件是进度的首要度量标准。                                                                                   -----项目
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。       ------项目
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。                                                   -----项目
10. 以简洁为本，它是极力减少不必要工作量的艺术。                                                                 -----项目
11. 最好的架构、需求和设计出自自组织团队。                                                                            ------团队
12. 团队定期地反思如何能提高成效，并依此调整自身的行为表现。                                            -----团队

 

1.6 敏捷实践编年史

        https://www.scrumcn.com/agile/scrum-knowledge-library/agile-practices-timeline.html

1.7 敏捷词汇表

Scrum： Scrum无对应中文翻译
Agile： 敏捷
Lean： 精益
Iterative：迭代式的
Iteration：迭代
Agile Manifesto： 敏捷宣言
Empirical： 经验性的
Empirical Process：经验性过程
Transparency： 透明性
Inspect and Adapt： 检视与调整
Sprint：原意为冲刺，Scrum中的Sprint无对应中文翻译，指一个迭代
Sprint Goal：Sprint目标
Product Owner ：产品负责人 简称PO
Scrum Master ：简称SM, 一般不翻译
Development Team ： Scrum开发团队
Scrum Team：指PO,SM和开发团队
Scrum Roles：Scrum角色，指PO,SM和开发团队
Emergent ：涌现的
Product Backlog：产品待办列表，指需求清单
Sprint Backlog：Sprint待办列表，指Sprint任务清单
Sprint Burn-down Chart：Sprint燃尽图，团队用于做Sprint内的进展跟踪
Release Burn-down Chart:  发布燃尽图，产品负责人做发布进展跟踪
Sprint Planning Meeting: Sprint计划会议
Daily Scrum Meeting：每日站会
Sprint Review Meeting：Sprint评审会议
Sprint Retrospective Meeting: Sprint回顾会议
Product Backlog Refinement: 产品待办列表梳理
Product Backlog Item: 产品待办清单条目，简称PBI
User Story: 用户故事，指一条需求
Story Point：衡量用户故事的工作量大小的计量单位
Velocity: 团队速度
Sprint Task: 实现一条需求需要做的一个技术任务
Definition of Done: DoD，完成的定义
Stakeholders： 干系人
Backlog： 待办列表
Artifact ：工件
Estimation ：估算
Collaboration： 协作
Scaling Scrum：大规模Scrum

1.8 敏捷书单

       https://www.scrumcn.com/agile/scrum-knowledge-library/books.html

 

二、SCRUM

2.1 什么是scrum?

Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。

Scrum流程如下图：

Scrum的历史

• • 1986年，竹内弘高和野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：
    • 他们将这种新的整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而团队“作为一个整体前进，把球传来传去”。
    • 他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。
  • 1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为scrum，在竹内弘高和野中郁次郎的文章中提到的橄榄球术语。
  • 1990年代初，Ken Schwaber在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。
  • 1993，Jeff Sutherland 在Easel公司开发了一种类似的方法，并首次称之为Scrum。
  • 1995年，在奥斯汀举办的OOPSLA ’95上，Jeff Sutherland 和Ken Schwaber联合发表了论文首次提出了Scrum概念。Ken Schwaber和Jeff Sutherland 在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。
  • 2001年，Ken Schwaber与Mike Beedle合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。
  • 2001年，Jeff Sutherland和Ken Schwaber参与了犹他州的17人聚会，参与发布了《敏捷宣言和十二原则》。
  • 2002年，Ken Schwaber和Mike Cohn创办了Scrum Alliance。

SCRUM框架

Scrum框架包括3个角色、3个工件、5个事件、5个价值：

3个角色

1. 1. 产品负责人（Product Owner）：
   2. Scrum Master
   3. 开发团队

3个工件

1. 1. 产品Backlog（Product Backlog）
   2. SprintBacklog
   3. 产品增量（Increment）

5个事件

1. 1. Sprint（Sprint本身是一个事件，包括了如下4个事件）
   2. Sprint计划会议（Sprint Planning Meeting）
   3. 每日站会（Daily Scrum Meeting）
   4. Sprint评审会议（Sprint Review Meeting）
   5. Sprint回顾会议（Sprint Retrospective Meeting）

5个价值

1. 1. 承诺 – 愿意对目标做出承诺
   2. 专注– 把你的心思和能力都用到你承诺的工作上去
   3. 开放– Scrum 把项目中的一切开放给每个人看
   4. 尊重– 每个人都有他独特的背景和经验
   5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

SCRUM理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：

第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

 

2.2 scrum官方权威指南

        https://www.scrumcn.com/agile/scrum_guide.html

 

2.3 scrum@scale指南

       https://www.scrumcn.com/agile/scrumatscale.html

 

2.4 scrum master

Scrum Master是Scrum的三个角色之一，另外两个角色是产品负责人和开发团队。Scrum Master需要正确地理解Scrum，基于Scrum指南对Scrum的定义，来推动Scrum的正确实施。Scrum Master通过帮助Scrum团队中的每个人正确地理解Scrum思想、价值观、原则和实践来做到这一点。

Scrum Master是Scrum团队的教练

作为教练，Scrum Master需要指导团队，包括开发团队和产品负责人，尽一切可能帮助他们达到最高水平。 对于一个新的Scrum团队来说，团队对Scrum过程还不熟悉，Scrum Master要像运动教练一样，帮助团队理解Scrum的核心思想和价值观，讲解Scrum的游戏规则，示范相关的Scrum实践。 经过一段时间的运行之后，团队熟悉了Scrum的运作机制和游戏规则。Scrum的关键活动，团队已经可以通过自组织开展起来。这个时候，Scrum Master应该像生活教练那样，通过倾听和提问来帮助团队持续改进。

作为教练，Scrum Master可以通过如下的这些方式帮助团队：

1. 1. 指导，通过知识讲解、示范、游戏、沙盘演练等方式传递知识，帮助团队掌握Scrum的思想和实践。团队在实践Scrum的过程中，帮助团队答疑解惑。
   2. 引导， 引导团队运作Scrum过程，建立和优化协作环境，促进团队内外有效地沟通和协作， 帮助团队移除障碍。
   3. 观察，关注团队的日常工作，了解他们的工作方式，仔细思考和分析他们为什么会这么做，发掘可能的改进机会。
   4. 反馈，给予团队反馈，分享你观察到的情况（必要时，可以提供可视化图表或数据），尽可能地帮助他们自己发现问题，并提出改进思路。
   5. 支持，团队受阻时，想办法帮助团队移除障碍，帮助团队争取外部的支持。保护团队专注目标，不受外界干扰。

作为教练，Scrum Master的工作内容包括：

1. 1. Scrum Master 服务于产品负责人 Scrum Master 以各种方式服务于产品负责人，包括：
   • • 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
     • 找到有效管理产品待办列表的技巧；
     • 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
     • 理解在经验主义的环境中的产品规划；
     • 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
     • 理解并实践敏捷性；以及，
     • 按要求或需要引导 Scrum 事件。
   1. Scrum Master 服务于开发团队 Scrum Master 以各种方式服务于开发团队，包括：
   • • 在自组织和跨职能方面给予开发团队指导
     • 帮助开发团队创造高价值的产品；
     • 移除开发团队工作进展中的障碍；
     • 按要求或需要引导 Scrum 事件；以及，
     • 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。
   1.  Scrum Master 服务于组织 Scrum Master 以各种方式服务于组织，包括：
   • • 带领并指导组织采纳 Scrum；
     • 在组织范围内规划 Scrum 的实施；
     • 帮助员工和干系人理解并实施 Scrum 和经验产品开发；
     • 引发能够提升 Scrum 团队生产率的改变；以及，
     • 与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性。
   1. Scrum Master 服务于团队之外的相关干系人
   • • Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master是Scrum团队的服务式领导

根据Scrum的定义，Scrum Master是一个服务式的领导（也叫仆人式领导）。仆人式领导是一种领导哲学，领导者的主要目标是服务。当领导者改变思维方式并首先服务时，他们和员工一样受益。他们的员工获得个人成长，同时由于员工不断增长的承诺和参与，也促进了组织的发展和增长。

作为服务式的领导，Scrum Master要确保自己的服务满足团队最高优先级的需要。服务式的领导不会通过权利来命令和控制团队，他们不会问：“你们今天要为我做些什么呢？”，而是问：“为了让你和团队更高效，需要我做些什么呢？”。Scrum Master通过自己的个人影响力来领导团队，他的领导艺术在于帮助团队发现问题，引导团队自己解决问题。

Scrum Master对流程负责

Scrum Master是Scrum团队的过程权威，为了保证团队正确的运作Scrum过程、遵守Scrum过程的原则和纪律，Scrum Master需要被充分授权。Scrum Master对团队成员没有权威，他不负责招人或裁人，他可能无法说：“你被解雇了”，但是Scrum Master可以说：“我已经决定，下个月开始我们尝试为期两周的Sprint”。Scrum Master的核心使命是持续帮助团队改进过程，以实现最大化的价值交付。 Scrum Master保护团队 Scrum Master也经常被视为团队的保护者。保护团队专注在已承诺的目标上，不受外界干扰，不过度承诺。例如，过度激进的产品负责人给予团队太大压力，Scrum Master要确保团队不会这些压力而过度承诺Sprint的目标。

Scrum Master是变革的发起人

在Scrum实施的过程中，会暴露出很多团队或组织方方面面的问题或困难，如果要让组织真正的获得Scrum带来的价值，组织必须做出改变，以解决这些问题，克服这些困难。Scrum Master必须积极推动组织进行变革，比如引导团队改变工作方式，引入新的管理实践或工程实践，导入新的工具，影响管理层进行组织变革或调整等等。

 

2.5 每日站会的四条建议：

1 不要在计划会议上就分配完所有工作

许多团队在召开计划会议时，会把所有的工作都分配到个人。

这并非是一种好的做法。因为，如果在计划会议上就分配完所有工作，那么就很容易导致在迭代中每个团队成员只关注自己而不关注他人。

更好的做法是，不要在计划会议上就分配完所有工作，而是要改为在每日站会上确定工作分工。只有这样做，才能让整个团队始终保持对整体迭代目标和进展的关注。

2 每日站会上，不要过人，而要过故事

许多团队在召开每日站会时，会让团队成员依次进行工作陈述。

这种做法并不妥当。因为，如果在每日站会上让团队成员依次进行工作陈述，就会很容易把每日站会开成是针对每位团队成员的工作汇报和纠偏会议。

更好的做法是，按照优先级依次回顾每个故事的完成情况、讨论遇到的问题和规划当天的安排。只有这样做，才能把会议焦点从关注人转向关注迭代工作。

3 Scrum Master尽量只引导，尽量少发表意见

我看到，许多Scrum Master在很积极地参与到每日站会的工作讨论，例如：代替团队成员陈述昨天的工作完成情况，对工作进行点评和给出工作建议，直接向团队成员进行工作任务分配，等等。

在每日站会上，谁发言最多，谁就会自然而然地成为会议上所有人员瞩目的焦点。如果Scrum Master的管理行为过于积极，往往就会打击团队成员参与工作讨论的积极性，而自然而然地把每日站会开成工作汇报会。

更好的做法是，Scrum Master尽量只做会议引导，引导团队成员们进行协作和思考，而非开成以自身为主的管理会议。

需要强调的是，如果Scrum Master发现团队成员的迭代工作安排中出现了严重问题，还是应当给出必要的反馈，但最好在团队成员已经充分交流后再给出，而不要一开始就把问题抛出来。

4 让团队成员轮流主持每日站会

如果Scrum Master想要减少自己在每日站会上的发言，以更大程度上促进团队成员间的交流，可以考虑让团队成员轮流主持每日站会。

需要强调的是，如果要让团队成员来主持每日站会，必须先进行必要的每日站会主持方法和技巧培训，否则可能会把每日站会开得很糟糕。

 

2.6 资源下载

        https://www.scrumcn.com/agile/scrum-resources-download-myaction.html

 

三、极限编程XP

3.1 极限编程入门

极限编程（英语：Extreme programming，缩写为XP），是一种软件工程方法学，是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。

极限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。

极限编程的创始者是肯特·贝克、沃德·坎宁安和罗恩·杰弗里斯，他们在为克莱斯勒综合报酬系统（C3）的薪水册项目工作时提出了极限编程方法。肯特·贝克在1996年3月成为C3的项目负责人，开始对项目的开发方法学进行改善。他写了一本关于这个改善后的方法学的书，并且于1999年10月将之发行，这就是《极限编程解析》（2005第二版出版）。克莱斯勒在2000年2月取消了实质上并未成功的C3项目，但是这个方法学却一直流行在软件工程领域中。至今，很多软件开发项目都一直以极限编程做为他们的指导方法学。

 

3.1.1 极限编程的目标

极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更将导致开发成本急速增加，而这样的需求变更在一些发展极快的领域中是不可避免的。

极限编程通过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。

 

3.1.2 极限编程的12个核心实践

短交付周期

极限编程和Scrum一样采用迭代的交付方式，每个迭代1-3周时间。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。

计划游戏

XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。针对这两个问题，XP中又两个主要的相应过程：

软件发布计划（ReleasePlanning）。客户阐述需求，开发人员估算开发成本和风险。客户根据开发成本、风险和每个需求的重要性，制订一个大致的项目计划。最初的项目计划没有必要（也没有可能）非常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程中被不断地调整以趋精确。

周期开发计划（IterationPlanning）。开发过程中，应该有很多阶段计划（比如每三个星期一个计划）。开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新功能，或者会在一个周期内同时做两方面的工作。但是，经过每个开发周期，用户都应该能得到一个已经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。每过两三个星期，客户总能够实实在在地看到开发人员已经完成的需求。在XP里，没有什么“快要完成了”、“完成了90%”的模糊说法，要不是完成了，要不就是没完成。这种做法看起来好像有利有弊：好处是客户可以马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做出来的东西，可能会很不满意甚至中止合同。实际上，XP的这种做法是为了及早发现问题、解决问题，而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加哪个内容等等。

结对编程

结对编程是指代码由两个人坐在一台电脑前一起完成。一个程序员控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构，不断的对第一个程序员写的代码进行评审。

结对不是固定的：我们甚至建议程序员尽量交叉结对。这样，每个人都可以知道其它人的工作，每个人都对整个系统熟悉，结对程序设计加强了团队内的沟通。这与代码集体所有制是息息相关的。

可持续的节奏

团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

代码集体所有

代码集体所有意味着每个人都对所有的代码负责；这一点，反过来又意味着每个人都可以更改代码的任意部分。结队程序设计对这一实践贡献良多：借由在不同的结队中工作，所有的程序员都能看到完全的代码。集体所有制的一个主要优势是提升了开发程序的速度，因为一旦代码中出现错误，任何程序员都能修正它。

在给予每个开发人员修改代码的权限的情况下，可能存在程序员引入错误的风险，他／她们知道自己在做什么，却无法预见某些依赖关系。完善的单元测试可以解决这个问题：如果未被预见的依赖产生了错误，那么当单元测试运行时，它必定会失败。

编码规范

XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现代码集体所有的重要前提之一。

简单设计

XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不断前进和发展的过程。从这个角度看，XP是把设计做到了极致。

测试驱动开发

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

测试驱动开发的基本过程如下：

①　快速新增一个测试

②　运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过

③　做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法

④　运行所有的测试，并且全部通过

⑤　重构代码，以消除重复设计，优化设计结构

简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号

重构

XP强调简单的设计，但简单的设计并不是没有设计的流水账式的程序，也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重构（Refactoring）。这个名字最早出现在MartinFowler写的《Refactoring:ImprovingtheDesignofExistingCode》这本书中。

Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。

系统隐喻

为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”

持续集成

集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

现场客户

在极限编程中，“客户”并不是为系统付帐的人，而是真正使用该系统的人。极限编程认为客户应该时刻在现场解决问题。例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。客户负责编写故事和验收测试，现场客户可以使团队和客户有更频繁的交流和讨论。

 

3.1.3 极限编程的4个价值

除了XP实践，极限编程还提倡四大价值：沟通、简单、回馈、勇气。

沟通

构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。

极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。

简单

极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。

反馈

XP团队重视反馈，反馈越快越好。在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：

来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。

来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。

来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。

反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”

勇气

极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。

 

3.1.4 极限编程的5个原则

组成极限编程基础的原则，正是基于上面描述的那几条价值。在系统开发项目中，这些原则被用来为决策做出指导。与价值相比，原则被描述的更加具体化，以便在实际应用中更为简单的转变为具体的指导意见。

1. 快速反馈

当反馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。与传统开发方法不同，与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他／她能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。

单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中，应需求变更而做出修改的系统将出现怎样的反应，正是通过单元测试来给出直接反馈的。比如，某个程序员对系统中的一部分代码进行了修改，而假如这样的修改影响到了系统中的另一部分（超出了这个程序员的可控范围），则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。

2. 假设简单

假设简单认为任何问题都可以”极度简单”地解决。传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样做。

3. 增量变化

极限编程的提倡者总是说：罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。比如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。

4. 拥抱变化

可以肯定地是，不确定因素总是存在的。“拥抱变化”这一原则就是强调不要对变化采取反抗的态度，而应该拥抱它们。比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员，必须拥抱这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。

5. 高质量的工作

没人喜欢拖泥带水，每个人都期望出色的完成工作。极限编程的提倡者认为范围、时间、成本和质量这个四个软件开发的变量，只有质量不可妥协的。

 

3.2 持续集成

集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。

大师Martin Fowler对持续集成是这样定义的:

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

 

3.2.1 持续集成的价值

• • 减少风险

一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况，减少假定。

• • 减少重复过程

减少重复的过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及反馈。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多的投入到动脑筋的、更高价值的事情上。

• • 任何时间、任何地点生成可部署的软件

持续集成可以让您在任何时间发布可以部署的软件。从外界来看，这是持续集成最明显的好处，我们可以对改进软件品质和减少风险说起来滔滔不绝，但对于客户来说，可以部署的软件产品是最实际的资产。利用持续集成，您可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。不采用持续集成的情况下，这些问题有可能到交付前的集成测试的时候才发现，有可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致项目失败。

• • 增强项目的可见性

持续集成让我们能够注意到趋势并进行有效的决策。如果没有真实或最新的数据提供支持，项目就会遇到麻烦，每个人都会提出他最好的猜测。通常，项目成员通过手工收集这些信息，增加了负担，也很耗时。持续集成可以带来两点积极效果：

(1)有效决策：持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和缺陷率。

(2)注意到趋势：由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息。

• • 建立团队对开发产品的信心

持续集成可以建立开发团队对开发产品的信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。

 

3.2.2 持续集成的要点

1.统一的代码库

2.自动构建

3.自动测试

4.每个人每天都要向代码库主干提交代码

5.每次代码递交后都会在持续集成服务器上触发一次构建

6.保证快速构建

7.模拟生产环境的自动测试

8.每个人都可以很容易的获取最新可执行的应用程序

9.每个人都清楚正在发生的状况

10.自动化的部署

       

        3.2.3 持续集成的原则

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。

2. 开发人员每天至少向版本控制库中提交一次代码。

3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

5. 每次构建都要100%通过。

6. 每次构建都可以生成可发布的产品。

7. 修复失败的构建是优先级最高的事情。

 

3.3 结对编程

结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计。同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早已习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处．只是这些好处必须经过缜密的思考和计划才能真正体现出来。而另一方面，两个有经验的人可能会发现配对编程里没有什么技能的转移，但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案，而且错误更少。

结对编程还有其他多种好处：
1、直接的、连续的代码回顾。
2、与别人工作会增加责任和纪律性。
3、同时理解一个问题。
4、在有人盯着的时候去偷懒要困难得多！
两个程序员具有相同的缺点和盲点的可能性很小，所以我们当我们采用结对编程的时候会获得一个强大的解决方案。而这个解决方案恰恰是其它软件工程方法学中所没有的。
在我们平时的编程当中，如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度)，那么你势必会希望寻求帮助，无论是从信息量庞大的Internet网络里，还是从身边的技术大师里，你都会拼了老命去解决(前提是你有对计算机知识的势爱)。这个时候不妨采用结对编程试一下，其它的不说，可能感觉就不同。

 

3.4 测试驱动开发

测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

Kent Beck先生最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了《测试驱动开发》一书，详细说明如何实现。经过几年的迅猛发展，测试驱动开发已经成长为一门独立的软件开发技术，其名气甚至盖过了极限编程。

 

3.4.1 基本原理

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

测试驱动开发的基本过程如下：

①　快速新增一个测试

②　运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过

③　做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法

④　运行所有的测试，并且全部通过

⑤　重构代码，以消除重复设计，优化设计结构

简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。

 

3.4.2一个生动比喻

举个比较生动的例子，这个例子你一定已经在很多关于TDD的文献资料上都看到过，但它确实是一个不错的比喻。在此我进行了一些加工和扩展。

盖房子的时候，工人师傅砌墙，会先用桩子拉上线，以使砖能够垒的笔直，因为垒砖的时候都是以这根线为基准的。TDD就像这样，先写测试代码，就像工人师傅先用桩子拉上线，然后编码的时候以此为基准，只编写符合这个测试的功能代码。

而一个新手或菜鸟级的小师傅，却可能不知道拉线，而是直接把砖往上垒，垒了一些之后再看是否笔直，这时候可能会用一根线，量一下砌好的墙是否笔直，如果不直再进行校正，敲敲打打。使用传统的软件开发过程就像这样，我们先编码，编码完成之后才写测试程序，以此检验已写的代码是否正确，如果有错误再一点点修改。

你是希望先砌墙再拉线，还是希望先拉线再砌墙呢？如果你喜欢前者，那就算了，而如果你喜欢后者，那就转入TDD阵营吧！详细可参阅。

 

3.4.3 本质和优势

或许只有了解了测试驱动开发的本质和优势之后，你才会领略到她的无穷魅力。 测试驱动开发不是一种测试技术，它是一种分析技术、设计技术，更是一种组织所有开发活动的技术。相对于传统的结构化开发过程方法，它具有以下优势：

1) TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。因为关注用户反馈，可以及时响应需求变更，同时因为从使用者角度出发的简单设计，也可以更快地适应变化。

2) 出于易测试和测试独立性的要求，将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，提高系统的可扩展性和抗变性。而且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。

3) 将测试工作提到编码之前，并频繁地运行所有测试，可以尽量地避免和尽早地发现错误，极大地降低了后续测试及修复的成本，提高了代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。

4) TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。完整的测试会帮助我们持续地跟踪整个系统的状态，因此我们就不需要担心会产生什么不可预知的副作用了。

5) TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。

6) TDD可以减轻压力、降低忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。

7)快速的提高了开发效率

 

3.4.4 现状和前景

测试驱动开发的技术已得到越来越广泛的重视，但由于发展时间不长，相关应用并不是很成熟。现今越来越多的公司都在尝试实践测试驱动开发，但由于测试驱动开发对开发人员要求比较高，更与开发人员的传统思维习惯相违背，因此实践起来有一定困难。 美国不少著名软件公司如IBM很早就开始向敏捷转型，在此过程中，TDD通常是最重要也最艰难的一个，正如IBM开发转型部门副总裁Sue Mckinney所言：测试驱动开发前景非常诱人，但是“在这个过程中我们的付出可能也是最多的。”Forrester的高级分析师Dave West认为，测试驱动开发（TDD）就像是“圣杯”，但是“如果能达到这个目标，付出再多的辛苦也是值得的。”

我想，测试驱动开发的推广过程中，首要的问题是将开发人员长期以来形成的思维观念和意识形态转变过来，开发人员只喜欢编码，不喜欢测试，更无法理解为什么没有产品代码的时候就先写单元测试；其次是相关的技术支持，测试驱动开发对开发人员提出了更高的要求，不仅要掌握测试和重构，还要懂得设计模式等设计方面的知识。

正像每种革命性的产物刚刚产生之初所必然要经历的艰难历程，测试驱动开发也正在经历着，但她正在逐渐走向成熟，前途一片光明。相信未来几年内，国内的一定会越来越多的软件企业开始普及测试驱动开发。

 

四、敏捷开发实践集

4.1 用户故事

用户故事是从用户的角度来描述用户渴望得到的功能。

一个好的用户故事包括三个要素：

1.     角色：谁要使用这个功能。

2.     活动：需要完成什么样的功能。

3.     商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：As a <Role>, I want to <Activity>, so that <Business Value>.

中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

 

Ron Jeffries的3个C

关于用户故事，Ron Jeffries用3个C来描述它：

卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

 

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则：

独立性（Independent）

要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）

一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）

每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）

开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）

一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）

一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

 4.2 故事点

故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。

当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。

团队不要采用100、200、300，或者1百万、2百万、3百万，而要使用1、2、3。估算结果是比值，而不是绝对值。

 

故事点包括什么内容

由于故事点数代表了开发用户发故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。这可能包括：

• • 要开展的工作的数量
  • 工作的复杂度
  • 要开展的工作中存在的任何风险或不确定性

在用故事点估算时，必须要考虑以上每一个因素。让我们看看每个因素是如何影响故事点的。

 

要开展的工作数量（The Amount of Work）

如果要开展的工作越多，工作量的估算值当然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个只需要输入一小段文本的字段。

第二个网页并不比第一个网友更复杂。字段之间是不存在交互的，每个字段只不过是一点文本而已。因此第二个网页并不存在额外的风险。这两网页之间的唯一区别就是第二页有更多的事情要做。

应该给予第二个网页更多的故事点数。但它即使有多了100倍的字段数，可能仍然得不到多100倍的点数。毕竟，由于规模经济效应，第二个网页的工作量可能只是第一个网页的工作量的2或3或10倍。

 

风险和不确定性（Risk and Uncertainty）

产品待办项的风险和不确定性会影响其故事点估算值。

如果产品待办项的干系人在询问需求事说得不清不楚，那么团队在估算时应当把不确定性也反映在估算结果中。

如果要实现一项功能时需要改动一段缺乏自动化测试的、结构脆弱的老代码，那么估算结果中也应该反映这个风险。

 

复杂度（Complexity）

在进行故事点估算时，还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。

现在考虑另一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或社会安全号码；另一些字段则需要做信用卡号码的校验和验证。

页面上的字段之间还需要相互交互。如果用户输入一个VISA卡，会显示三位CVV字段。但是如果用户输入美国运通卡，则需要显示四位CVV字段。

尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，需要花更多时间才能实现。开发人员出错的可能性更大，因此不得不采取一些预防和纠正措施。

这种额外的复杂度都应该反映在所提供的估算结果中。

 

要考虑所有因素：工作数量、风险和不确定性，和复杂度

把这三个因素合成一个数字并提供一个估算值，貌似是不可能的。然而其实是可能的，因为可以统一到工作量这个因素。

首先，估算人员要考虑的是：完成产品待办项所描述的那些工作，到底需要多少工作量。

然后，估算人员要考虑的是：在处理产品待办项的风险和不确定性方面需要付出多少工作量。通常可以通过考虑到问题发生的风险以及风险确实发生会造成的影响来做到。因此，例如，一个可能会发生并将消耗时间的风险将会增加估算值，而一个不太可能发生且无关紧要的风险则不会增加估算值。

此外，估算人员还要考虑要开展的工作的复杂度。复杂的工作需要花费更多的心思，可能需要进行更多的试错试验，可能需要与客户进行更多的反复，还可能需要花费更长的时间来验证和改正错误。

所有这三个因素必须都结合考虑。 

 

要考虑“完成的定义”中的要求

故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事（并且这是一个好主意）这个事项，那么创建这些测试的工作量也应该包含在故事点估算结果中。

故事点可能是个难以把握的概念。但是花时间去充分理解——故事点数代表着其工作的数量、复杂度及其风险和不确定性——将会是值得的。

 

4.3 敏捷估算

在介绍敏捷估算的方法之前，我们先来回顾一下基于人天的传统估算的思路。传统的工作量估算是估计一个绝对值，单位是人天或者人时。

比如：

David喝完一小杯热咖啡花费1.2个小时（工作量 1.2人时）

David喝完一大杯热咖啡花费2.4个小时（工作量 2.4人时）

由于人的能力是有差异的，所以David的工作量对于Tom来讲可能就不适用，Tom喝完一小杯热咖啡可能需要1.5小时。这样一来，工作量、参与人以及完成这些工作的时间周期就是强相关的，因为强相关会带来如下挑战：

1.  做计划时必须把人和周期关联到具体的任务上，会让计划很复杂。

2.   团队成员的分工发生变化时对计划的影响比较大，管理和维护计划成本高。（这是甘特图的价值所在 ）

3.   由于第二条的原因，这种工作量的估算方式不利于团队协作。

接下来，我们来看看敏捷估算的思路。 在探讨具体的思路之前，我们先思考一下做估算的目的什么，通常有两个目的：

1.   核算成本和周期，我们要了解这这个项目或产品的投资回报。

2.   做计划，根据项目的需要，我们要知道什么时间点应该交付什么内容才可以满足市场、用户或客户的期望。

做敏捷估算时，请先忘掉人天或人时，敏捷估算关注的是工作量的规模（大小），而不关心谁来做，不关心花多长时间做完。它的规模计量单位使用的是一个抽象的单位——故事点，故事点是一个相对值，是一个相对倍数，和人天，人时没有关系，它和公里、吨、摄氏度类似，只是一个计量单位而已。我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是 1 个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍， 是 2个故事点，大杯是小杯的三倍，所以工作量是3个故事点。

敏捷估算的步骤：

1.  找一个参考基准，作为一个故事点。比如：把开发一个简单的查询页面工作量作为基准，定义为一个故事点。

2.  拿其它的故事和基准进行比较，估算他们之间的倍数，从而得到其它故事的故事点数。比如：查看个人基本信息这个故事和开发一个简单的查询页面的规模差不多大，所以它也是1个点，录入个人基本资料的这个故事要复杂一些，大概时3个点。

 3 . 累计产品backlog中的所有故事，得到所有故事总的故事点数。

得到了总的故事点规模，我们还要知道团队速度。团队速度是指：1个敏捷团队在一个迭代中完成的故事点总数。比如：某Scrum团队1个迭代可以完成 80个故事点，那么80个点就是他们的速度。

有了总的规模，我们也知道了团队一个迭代的速度，我们就可以很容易推算多少个迭代可以做完。 如下图所示，总的规模是1600个点，团队总共8个人，每个迭代完成80个点，我们就可以推算20个迭代完成。 每个迭代2周，所以40周可以完成，8个人40周的成本投入也可以很容易得出。

敏捷估算要点小结：

1.   相对估算，使用故事点作为单位，故事点是一个相对倍数。

2.  估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人天，人时无关。

3.  敏捷估算关注团队的速度，不关注单个人的速度。

4.  通过总规模和团队速度，推算周期。

 

4.4 领任务

敏捷开发团队（Scrum团队）在每天开每日站会的时候会领取当天的任务，这个实践在敏捷开发中叫做sign-up-for-tasks即领任务。这个实践源自极限编程，在1998年，极限编程最早期的介绍中提到了，“指派任务”和“领任务”是传统方式和极限方式的一个显著区别。

领任务是指，团队成员在任务卡上写上自己的名字，或者贴上自己的照片，表明这个任务，由这个成员来负责。 领任务的活动通常在开展每日站会的时候进行。领任务的方式体现了团队自组织的工作方式，传统模式下的经理指派任务是命令和控制的工作方式。

领任务的实践看似简单，但是在实践中往往很难做好，通常存在如下几个方面的误区：

误区一：我们的团队不是很主动，如果不给他们分派任务，他们就无法开展工作。

敏捷团队的工作方式和传统的经理领导的团队的工作方式的一个最主要的差别在于决策机制。经理领导的团队，由经理来决定谁做什么，团队成员听经理的安排就可以了。敏捷团队，由团队来决策谁做什么，是团队商量着办。

有人可能认为，经理决策不是很好吗，又快又好，因为经理知道谁的能力怎么样。但是，这种决策机制带来的问题是，第一，对经理依赖比较大，经理的能力决定项目的成败；第二，团队比较被动，参与感比较差；第三，责任在经理肩上，团队只负责完成被安排的任务。

领任务，背后的核心逻辑是团队负责和团队决策。所以，如果要让团队能够很好的开展领任务的工作方式，第一件要做的事情是让团队学会协作和集体决策。

团队的Scrum Master可以引导团队制定他们的工作协议（自组织团队的工作约定，这个在后续的实践文章中介绍），包括如何决定团队每天的目标，如何决定每个人如何对每天的团队目标进行贡献，以及如何分工合作等约定。在每天开站会的时候，大家按照约定来商量着办。

误区二：如果大家都领简单的任务怎么办？

如上面误区一中介绍的那样，团队领任务，核心逻辑是团队决策，而不是个体自我决策，不是我想领什么任务都可以。团队决策的时候，需要基于迭代的目标来分析每天的目标，基于团队每天的目标来决定团队成员每个人的目标。

误区三：如果能力比较差的人，领取了比较难的任务，他完不成怎么办？

自组织团队的团队决策机制，让每个团队成员有了更多的参与机会。然而，自组织团队的目标是迭代成功、项目成功。

自组织鼓励团队的参与，和挑战更高的目标，让团队成员能够不断成长。所以，能力差的人，领取到比较难的任务，这种情况是可能发生的。但是，自组织团队要根据任务的进展情况，及时的发现可能产生的风险和障碍，必要的时候让其他队员进行协助，以确保迭代的目标不受影响。

 

4.5 精益创业

概念

精益创业(Lean Startup)是硅谷流行的一种创新方法论。它的核心思想是，先在市场中投入一个极简的原型产品，然后通过不断的学习和有价值的用户反馈，对产品进行快速迭代优化，以期适应市场。

由来

精益创业（Lean Startup）由硅谷创业家Eric Rise2012年8月在其著作《精益创业》一书中首度提出。但其核心思想受到了另一位硅谷创业专家Steve Garry Blank的《四步创业法》中“客户开发”方式的很大影响，后者也为精益创业提供了很多精彩指点和案例。   很多IT从业人员在了解精益创业后认为，其核心理念可以追溯到软件行业的敏捷开发管理。例如“最小可用品”与“原型建模”非常相似，都追求快速的版本迭代，以及时刻保持与客户的接触并获得反馈等等，精益创业可以理解为敏捷开发模式的一种延续。

三大法宝

从《精益创业》一书中提到的主要思路和脉络，结合在现实中使用的频率，精益创业提到的三个主要工具是：“最小可用品”、“客户反馈”、“快速迭代”。   最小可用品–是指将创业者或者新产品的创意用最简洁的方式开发出来，可能是产品界面，也可以是能够交互操作的胚胎原型。它的好处是能够直观的被客户感知到，有助于激发客户的意见。通常最小可用品有四个特点：体现了项目创意、能够测试和演示、功能极简、开发成本最低甚至是零成本。   客户反馈–是指通过直接或间接的方式，从最终用户那里获取针对该产品的意见。通过客户反馈渠道了解关键信息，包括：客户对产品的整体感觉、客户并不喜欢/并不需要的功能点、客户认为需要添加的新功能点、客户认为某些功能点应该改变的实现方式等；获得客户反馈的方式主要是现场使用、实地观察。对于精益创业者而言，一切活动都是围绕客户而进行，产品开发中的所有决策权都交给用户，因此，如果没有足够多的客户反馈，就不能称为精益创业。   快速迭代–是针对客户反馈意见以最快的速度进行调整，融合到新的版本中。对于互联网时代而言，速度比质量更重要，客户需求快速变化，因此，不追求一次性满足客户的需求，而是通过一次又一次的迭代不断让产品的功能丰满。所以，才会有微信在第一年发布了15个版本，扣扣保镖3周上线的记录。

常用方法

1. 精简式反馈   大多数团队认为，只有开发出一个功能完整、看起来很美观的界面之后，才能将其展示给客户以获得反馈。事实证明，只要将一些简单的模型功能组织在一起，并提供可点击的区域，同样可以获得有价值的反馈。事实反复证明，消费者十分愿意与这些可点击的功能互动，就好像它们是最终的产品。这可以帮助创业公司了解其设计是否有效，在真正进行大规模开发工程之前，这是一个十分伟大的方法。   2. 客户采访   不要闭门造车，而要通过收集数据来支持产品设计。具体而言，要走出去，找到自己产品的潜在客户，通过与他们交流来找到解决问题的答案。对于该方法，开发者也许已经听过上百次了，并且也认可，但要真正把它培养成习惯并不容易。   3. 以小见大   要想迅速了解消费者是否喜欢一项新功能，只需通过推出该功能的一小部分即可。产品定制创业公司CustomMade就是如此，开发者希望让访问者借鉴他人的项目来获得灵感。但没有必要费力地开发出整个功能，因此仅推出了第一个按钮。当开发者看到大量访问者点击该按钮时，就知道应该把这一功能继续完成。经过调整和优化，用户互动明显提升。   4. 判断   开发者可以将竞争对手的产品看作是一个免费的原型。观察消费者如何使用这些产品，他们喜欢哪些功能，哪些功能用不到，甚至令人厌恶。了解这些，开发者在进行产品设计、营销和销售时就会做出更好的决定。   5. 微调查   精益创业人士需要使用一项有效的调查模式，尽量让调查与当前的研究内容紧密结合。例如，如果想知道顾客为何选择企业的一项定价计划，就可以给出一个小的弹出式调查问卷，而不是可能需要几天后才能看到的电子邮件。   此外，阅读100个简短的用户反馈获得的内容远比知道32%的人选“B”更多。   6. 真正数据原型   当为优惠券网站RetailMeNot设计优惠券页面时，设计者需要真正的优惠券数据来评估设计。设计者花费了两天时间来创建原型，尽管还有不少问题，也不具备太多功能，但却可以从消费者那里获得许多有价值的反馈。   反馈发现，最初约50%的想法不合理。后来又重复了三次，建立原型并展示给消费者，最终使创新的设计更具可用性，点入率显著提升。   7. 实地考察   最初，某个项目组与Foundation Medicine合作来完善其临床肿瘤基因组学报告。因此项目组决定参观一下肿瘤中心，观察医生是如何使用报告的。后来发现，他们努力设计出的报告通常是通过传真来接收的，小字体很难看清，各种颜色信息也是多余的。尽管这是一个很容易解决的问题，但只要到了现场才能发现问题。

优点

一是快速，精益创业模式下，所有的创新行为和想法都必须在最短的时间呈现出来，抛弃一切暂不重要其他功能，把极简的功能展现给客户，无论成功或失败，都能够以最快的速度知道结果。   二是低成本，过往“十年磨一剑”式的长期研发，其最终成果推出后，有可能发现花费了大量人力、物力和时间所开发出的产品，并不是客户所需要的。这种巨大的浪费除了会给创业者、企业带来绝大的经济损失之外，还对团队的士气形成巨大打击，不少团队成员会纷纷出走。而精益创业所采用的“频繁验证并修改”的策略，确保不会在客户认可之前投入过高的成本。   三是高成功率，虽然创新充满风险，成功系数低，但也不是没有套路可遵循。按照精益创业的模式，从“最小可用品”出发，过程中每一次迭代都可以寻找客户进行试用，了解客户对产品的看法，寻找产品的不足和客户希望增加乃至修改的功能点。当一路上持续遵循客户的意见进行开发后，项目组的不断纠偏的成果就是产品越来越符合客户想要的效果，而不是开发团队闭门想象的样子。通过持续的“测试–调整”以及快速迭代，创新的成功率能够大大提升。

适用范围

精益创业来源于互联网行业，是软件开发的一种新模式。但其背后的“客户验证”思想在大量非IT领域得到应用。例如美剧的拍摄，往往都会先拍摄一部几十分钟的先导片，交代主要的人物关系、矛盾冲突、故事背景，然后邀请几十位观众参加小规模试映会，再根据观众的反馈来决定剧情要作那些修改，是否需要调整演员，以及决定是否投拍。在每一季结束时，制作方又会根据收视率和观众意见，决策是砍掉该剧还是订购新一季内容。这种周拍季播的模式，把所有的决策权交给观众，让制作方的投资以及失败成本降到了最低，是一种典型的精益创业方式。   整体而言，精益创业适合客户需求变化快、但开发难度不高的领域，比如软件、电影电视、金融服务等领域。在国内，除互联网企业外，酒店管理领域的“今夜酒店特价”就采用这种小步试错的方式进行开发，一些传统企业如中信银行信用卡中心利用精益创业进行信用卡产品及客户服务的创新，并把三大法宝固化到项目管理机制中。   由于精益创业需要经常进行客户验证，因此对于一些客户验证成本较高、或者技术实现难度较大的工作并不适合。比如大型赛事，服务客户是全体运动员，但想要获得他们的频繁反馈是比较困难的。又比如航天工程，客户需求是比较明确、清晰的，主要难点在于飞行器的技术实现和对接控制。

 

4.6 最小可行产品

       https://www.scrumcn.com/agile/scrum/19067.html