EDUCBA-敏捷实践笔记-全-

EDUCBA 敏捷实践笔记（全）

001：简介 🚀

在本节课中，我们将学习敏捷项目管理的基础知识。我们将从理解什么是项目和项目管理开始，然后探讨传统项目管理的局限性，并介绍敏捷方法的核心概念、价值观和原则。最后，我们将对本章内容进行总结。

什么是项目？

项目是为创造独特的产品或服务而进行的临时性努力。

需要理解的是，项目的交付成果是独特的，这与重复性的运营工作不同。项目有明确的开始和明确的结束。项目由目标驱动，启动时总是着眼于特定的最终成果。它独立于人力投入和持续时间，不是持续性的活动（例如提供24/7的移动支持服务或电力供应，这些属于运营工作）。

“独特”意味着过去未曾做过的事情。“明确的结束”并不意味着持续时间短。项目是渐进明细的，从顶层到底层逐步细化。当项目不再需要或目标无法达成时，项目就会终止。项目启动后，可能达成全部目标、部分目标，也可能因为目标无法实现而废弃。

什么是项目管理？

项目管理是将知识、技能、工具和技术应用于项目活动，以满足项目要求的过程。

项目是团队成员跨越业务社区、IT社区及其他利益相关者的共同努力。要管理如此多的人员，需要特定的知识、技能、工具和技术来实现目标。项目管理是通过适当应用和整合47个逻辑上分组的项目管理过程（包含过程组）来完成的。

管理项目通常需要：

  • 识别项目需求：需求应被充分理解、详细阐述，并获得所有相关方同意，以便项目交付特定目标。
  • 管理利益相关者：项目涉及发起人、执行委员会、项目经理、业务部门、领域专家、测试团队等众多利益相关者。管理他们的利益、保持他们的高参与度和士气，是获取项目价值的关键。
  • 平衡项目约束：项目在时间、成本和质量方面存在约束。单一约束的变化会导致其他约束的变化，平衡这些约束是项目管理的核心。

项目集与项目组合

在项目管理领域，还有两个常用术语：项目集和项目组合。

  • 项目集：作为一组进行管理的项目群。它能降低风险、实现规模经济并改进管理。
  • 项目组合：项目或项目集的集合。将它们组合在一起是为了促进有效管理，以实现战略业务目标。

将类似的项目分组为项目集或项目组合，可以带来规模经济、效率提升以及协同与协作。例如，开发iPhone系列的项目可以归入“iPhone开发项目组合”；而为手机或平板开发屏幕的项目，可以归入“移动屏幕项目集”。

什么是敏捷？

传统的项目管理方法存在一些局限性。在90年代末期，出现了几种强调克服传统方法短板的方法论，它们促进了开发人员和业务专家之间的紧密协作。

以下是敏捷方法的核心特点：

  • 开发与业务的紧密协作：传统项目管理中，业务方将需求文档交给开发人员，开发人员阅读文档，如有疑问再回头咨询业务方，然后进行开发、测试。在项目90%的时间消耗后，他们向业务方展示成果。通常，业务方会说：“这不是我们想要的。”为了避免这种情况，敏捷建议开发人员和业务专家紧密协作，从而在需求和项目开发之间实现敏捷性和紧密协调。
  • 面对面沟通：编写文档并提交给开发团队会耗费大量时间。而面对面沟通可以捕捉言语和非言语线索，解答疑问，寻求澄清，从而使开发团队对业务需求有深刻理解，开发成果更贴近业务所需。
  • 频繁交付可部署的业务价值：传统项目管理需要大量时间才能将成果交付给业务方。而敏捷强调频繁交付可部署的业务价值，业务方可以尽早使用和测试，从而避免返工、废弃等非增值活动。
  • 紧密、自组织的团队：敏捷项目管理方法的设计旨在形成有凝聚力的团队。团队在协调良好的环境中工作，项目团队内部没有隔阂，其框架有助于实现团队的自组织。
  • 适应需求变更：敏捷承认需求会发生变更，会经历反复讨论和筛选过程，最终将最合适或最受青睐的需求纳入开发。这使得不可避免的需求变更不会成为危机。

本章总结

本节课我们一起学习了敏捷项目管理的基础。我们首先定义了项目（为创造独特产品或服务的临时性努力）和项目管理（应用知识、技能以满足项目要求的过程）。接着，我们区分了项目集和项目组合的概念。然后，我们探讨了传统项目管理的局限性，并引出了敏捷方法。我们了解到，敏捷通过紧密协作、面对面沟通、频繁交付、自组织团队和拥抱变更等方式，旨在更高效、更灵活地交付价值。在接下来的章节中，我们将深入探讨敏捷宣言、原则和具体框架。

002：敏捷方法

在本节课程中，我们将学习敏捷方法的核心概念、历史演变及其价值体系。我们将了解敏捷包含哪些具体方法，以及这些方法背后的基本原则。

什么是敏捷方法？🤔

现在，我们来理解什么是敏捷方法。

敏捷方法包含五种主要方法，它们共同构成了敏捷体系。这五种方法是：Scrum、极限编程、Crystal、IBM RUP（Rational Unified Process）以及动态系统开发模型。

在后续章节中，我们将深入探讨这些方法。目前只需记住，当我们谈论敏捷时，这五种方法都包含在内。这些方法的不同变体都被统称为敏捷方法。

敏捷方法的演进历程 📜

上一节我们介绍了敏捷方法的构成，本节中我们来看看敏捷方法是如何发展演变的。

简而言之，我们来理解敏捷的演进过程。

  • 1970年：在管理大型系统开发时，Royce首次描述了瀑布模型，并指出了它是一个糟糕的想法。
  • 1970年代初：人们开始认识到瀑布模型存在缺陷，需要一些新的方法来帮助项目团队更好地进行开发并满足客户期望。
  • 1971年：Weinberg发表了《计算机编程心理学》，探讨了如何以更好、更有效的方式进行计算机编程。
  • 1986年：Brooks在《人月神话》中提出了一个学说，倡导如何通过调整某些项目管理方法来更好地利用团队的努力或可用性。
  • 1986年：Sutherland和Schwaber提出了最初的Scrum方法。
  • 1987年：DeMarco和Lister提出了敏捷方法。
  • 1994年：Bland Software的Kamship App提出了如何加速或以更好方式进行软件开发。
  • 1994年：动态系统开发方法问世。
  • 1997年：Cockburn提出了Crystal方法论。
  • 1998年：DeLuca提出了特性驱动开发。
  • 2000年：Highsmith提出了自适应软件开发。
  • 2000年：Beck提出了极限编程。

敏捷宣言的诞生 🎯

了解了敏捷的演进后，我们来到其发展历程中的一个关键节点。

2001年，极限编程的成功开始起到催化作用。

2001年2月，17位实践者组织了一次研讨会。所有参与者虽然在具体细节上存在分歧，但都认同他们有一些共同点。

因此，完整的敏捷宣言声明在2001年诞生。次年，成立了非营利性的敏捷联盟。

最初那17位在具体细节上意见不一的实践者，后来加入了成千上万同样在细节上持不同意见的同行。

敏捷的四大价值支柱 💎

这些实践者共同提出了一份宣言，称为价值体系。这份宣言经过讨论并发布，旨在释放项目管理领域的价值。

以下是敏捷框架下的声明：

我们正在通过实践和帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们开始重视：

个体和互动 高于 流程和工具
可工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项（流程和工具、详尽文档、合同谈判、遵循计划）具有价值，但我们更重视左项（个体和互动、可工作的软件、客户合作、响应变化）。

整个项目管理的范式因此发生了转变。过去强调拥有完善的流程和工具、编写详尽的需求文档、进行供应商与客户之间的合同编写与谈判、制定前期计划来启动项目。而现在，重点更多地转向了个体与互动、产出可部署到业务中的可工作软件（让客户尽早体验并反馈所需变更）、与客户协作以带来满意度和价值（确定最相关的功能），以及预先假设项目启动时感知的需求将会发生变化，并在此变化出现时积极主动地响应。

这些就是敏捷宣言提出的四大支柱或价值体系。现在让我们深入理解敏捷宣言中发布的每一个价值体系。

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

敏捷专注于自我赋能、自我激励的跨职能团队。

  • 自我赋能：意味着团队成员了解自己的角色，知道对他们的期望，并且他们的思维方式都倾向于创造价值。他们被赋能去为项目创造价值。
  • 自我激励：核心理念是，与其管理员工，不如向他们展示更大的蓝图，从而激励他们主动创造价值。因此，重点更多地放在激励团队成员而非管理他们。
  • 跨职能团队：意味着业务专家、领域专家、技术开发人员、测试人员共同协作，以产出最佳的项目可交付软件功能。敏捷方法中嵌入了这种跨职能的同步、协调和团队合作。

成员亲自协作以解决共同问题。在传统的项目管理方法中，如果团队成员遇到问题，他会将问题记录到问题管理系统中，或向职能主管或项目经理寻求澄清，问题可能就此停滞。而在敏捷方法论中，成员们通过协作来解决共同问题。由于强调个体和互动，他们以预定的频率（通常每天至少一次）会面，这些互动有助于人们解决共同问题。随着问题以更快的速度得到解决，项目进展也会更加顺利。

工具支持不能取代互动。正如声明所说，重点更多地放在互动上。因此，工具仅在需要时使用，但首要选择是人与人之间的互动。互动是首要的，只有当互动无法产生预期结果时，才需要使用工具。

简而言之，个体和互动是有用的，它们在激励团队精神、解决跨职能问题和推动项目进展方面，比流程和工具更具优势。

2. 可工作的软件高于详尽的文档

接下来，我们看看第二个价值体系。

本节课总结

本节课中，我们一起学习了敏捷方法的基本构成，回顾了其从1970年代至今的演进历史，并深入探讨了2001年《敏捷宣言》所确立的四大核心价值支柱：个体和互动高于流程和工具、可工作的软件高于详尽的文档、客户合作高于合同谈判以及响应变化高于遵循计划。这些原则共同构成了敏捷思维的基石，指导着现代软件开发和项目管理的实践。

003：客户协作 🤝

在本节课中，我们将学习敏捷宣言中的核心价值之一：“客户协作胜过合同谈判”。我们将探讨这一原则如何改变传统的客户-供应商关系，以及它如何通过促进开放协作来提升项目价值。

传统模式：合同谈判 📜

在传统项目管理模式中，项目通常遵循以下流程：

  • 客户有特定工作需求。
  • 客户通过招标流程选择若干供应商。
  • 双方起草并签署合同。
  • 客户根据合同条款期待交付成果。
  • 供应商根据合同约定期待获得服务报酬。

由于合同具有法律约束力，双方的所有互动、行动和冲突都以合同为基准进行协商。

敏捷模式：客户协作 🔄

上一节我们介绍了以合同为中心的局限，本节中我们来看看敏捷思维如何转变这一模式。敏捷提倡在客户与供应商或服务提供商之间建立协作关系。

其目标是创造一个开放、健康的合作氛围，以最优化的方式交付价值，并尽量避免法律诉讼或范围外的争论。这是敏捷在其宣言中推广的广泛框架或价值体系。

在传统系统中，客户通常只在交付阶段介入，验收时才发现产品不符合预期。为了避免给客户带来这种“惊喜”，敏捷要求客户从项目启动之初就以预定的频率参与进来。

以下是客户深度参与带来的关键转变：

  • 客户成为开发过程的一部分：客户了解开发进展，有机会测试和部署开发成果，并在需要时提供反馈。
  • 避免“写文档、等软件”的低效模式：客户通过日常参与，能够掌控和理解项目开发活动。
  • 客户成为过程的所有者：客户不再仅仅是最终的验证者，而是作为过程所有者提供有效输入、使用开发成果并给出反馈，使过程更简化。
  • 打破供应商与客户的隔阂：敏捷框架确保项目交付物符合价值体系，各方都能从项目中获益，因此在出现问题时不会相互推诿。

核心实践：响应变化而非遵循计划 🔄

传统项目管理方法论通常始于定义所有需求，签署后再开始开发。一旦需求变更，由于存在“变更冻结”，开发团队会对变更产生抵触。

敏捷项目管理方法论避免了这种场景。它提倡拥抱变化，而非抗拒变化。

敏捷预先承认变化必然会发生，并将这些变化纳入项目工作范围。为了响应变化，敏捷通过每日站会等方式讨论、辩论、接受、开发、测试并吸收变更。

整个重点在于预先为变更请求做好准备，并在早期阶段容纳这些变化，从而避免软件所需变更产生巨大的积压。

总结 📝

本节课中我们一起学习了“客户协作胜过合同谈判”这一敏捷核心价值观。我们对比了以合同谈判为基础的传统模式与以开放协作为基础的敏捷模式。关键在于让客户从项目开始就持续参与，成为开发过程的所有者，并建立一种能够积极拥抱和响应变化的协作文化，从而更高效地交付业务价值。

004：应对变化 vs. 遵循计划

在本节课中，我们将学习敏捷宣言中的第四个价值体系：“响应变化 高于 遵循计划”。我们将探讨这一原则的含义、它与传统项目管理方法的区别，以及它如何通过12条原则来具体实现。

从遵循计划到响应变化

上一节我们讨论了客户协作的重要性，本节中我们来看看敏捷如何对待项目中的变化。

在传统的项目管理方法中，计划通常在项目的早期阶段就制定完成。所有团队成员都致力于完成计划内的任务。如果需要执行计划外的、额外的工作，开发团队通常会对此产生抵触。

而敏捷宣言及其价值体系则提倡响应变化，而不是遵循计划。敏捷推荐，当客户和供应商都对项目状态有清晰的理解时，响应变化会更容易。

假设你正在开发一款iPhone手机。最初的规格要求屏幕响应时间在2毫秒以内。然而，一旦开发启动，某个竞争对手发布了一款响应时间为1毫秒的手机。如果你仍然坚持最初2毫秒的规格，那么无论你的产品做得多好，都可能没有顾客愿意购买。因此，规格需要向上修订，要求低于1毫秒。

在这种场景下，如果供应商和客户都固守最初的规格，产品将失去市场竞争力。为了更切合实际，敏捷宣言提倡客户和供应商共享对项目状态的清晰理解。他们知道哪些变化会给软件带来积极影响，并且他们的行动会尽早地适应这些变化。

渐进明细与滚动式规划

敏捷方法采用自上而下的滚动式规划。他们从高级别的规格开始，随着迭代的进行，在每次迭代中引入更详细的说明或更清晰的需求。这种滚动式方法有助于软件开发。

在传统方法中，你在开始时定义需求，然后开始开发。而在敏捷中，你定义高级别的范围，并通过滚动式波浪来逐步细化需求。

总结来说，敏捷为处理变化、采纳变化分配了时间预算，并确保变化能为整个软件交付物带来积极价值。

支撑价值体系的12条原则

敏捷在发布宣言和四个价值体系的同时，也发布了12条原则。这些原则是对价值体系的补充，并进一步详细说明了敏捷项目管理方法如何帮助客户获得更大价值。以下是支持敏捷宣言中四个价值体系的12条原则。

原则一：尽早持续交付有价值软件

我们的最高优先级是通过尽早和持续地交付有价值的软件来满足客户。

第一原则指出，我们希望尽早将软件交付给客户。“尽早”意味着在尽可能短的时间内，而不是让客户等待很久才能看到软件的雏形。我们将持续交付已完成的软件，以便客户可以使用、提供反馈。任何可以容纳的变更都能被纳入，整个重点在于为业务产生价值。

第一原则表明，我们将尽可能早地交付软件，进行持续交付，容纳变更，促进软件演进，并将价值持续传递给业务。

例如，在开发iPhone时，随着组件和组装的完成，业务方可以逐步体验到网络连接、屏幕响应、Wi-Fi连接、音频质量水平和下载速度等特性。

原则二：欢迎需求变化

即使在开发后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。

与传统项目管理方法抵制变化不同，敏捷欢迎变化。它理解变化对于保持客户业务和为客户提供竞争优势至关重要。

因此，敏捷方法论以欢迎变化的方式进行工作。变化被提出来讨论、被充分理解、被深入辩论。团队会讨论容纳这些变化的各种方案，选择可行的方案，实施变化，并将其传递给客户。这就是客户偏爱敏捷方法论的原因，因为它欢迎变化，而变化在商业运营中是必要的。

原则三：频繁交付可工作软件

频繁地交付可工作的软件，交付周期从几周到几个月不等，且倾向于较短的周期。

与给出需求后等待很长时间才能获得测试软件不同，客户会获得有限的软件交付，以便他们可以开始使用、提供反馈、引入变化、进一步提升价值。整个重点是以尽可能短的频率交付软件或阶段成果。

原则四：业务人员与开发者密切合作

在整个项目过程中，业务人员和开发人员必须每天一起工作。

敏捷有每日站会这种简短的楼层会议。团队进行互动，讨论计划完成的工作、已交付的内容、遇到的挑战、所需的协调以及任何变化。项目团队内部的这种紧密互动有助于在团队成员之间建立清晰度，有助于聚焦对业务最重要的事情，并确保项目内的快速周转。

在传统项目中，通常允许3到5个工作日来评审文档。如果你花5个工作日来评审和确认需求文档，那么实际开发后的测试可能需要超过两周，然后缺陷被反馈回来进行修复。大量的时间浪费在团队成员之间的来回互动上。敏捷原则试图克服传统项目管理方法的这一缺点，其设计的项目互动方式使得开发人员和业务人员从开始到实现预期价值都紧密合作。

本节课中，我们一起学习了敏捷的第四个核心价值“响应变化高于遵循计划”，并了解了支撑这一价值的前四条敏捷原则。我们看到了敏捷通过欢迎变化、频繁交付和紧密协作，如何更灵活、更有效地应对不确定性和市场需求，从而持续为客户交付价值。

005：敏捷十二原则（下）🔧

在本节课中，我们将继续学习敏捷宣言背后的十二项原则。我们将重点探讨从第五项到第十二项原则，这些原则深入阐述了如何构建团队、促进沟通、衡量进度以及实现持续改进，是敏捷实践落地的核心指南。

上一节我们介绍了敏捷原则中关于客户协作和响应变化的部分，本节中我们来看看关于团队构建和高效工作的原则。

第五项原则：激发个体，构建团队 👥

第五项原则关注的是参与业务和项目团队的人员。敏捷思想认为，与其管理人员的活动，不如赋能他们，给予他们自由以释放才能，鼓励他们在开发活动中进行创新，并在项目社区内协作与同步。因此，整个原则的核心是围绕积极主动的个体来构建团队。

当个体知道自己拥有自由和授权，并且无需进行无价值的报告和跟踪活动时，他们的积极性会得到提升，他们对项目的贡献也会变得更有意义。

这种环境一旦建立，项目就能努力实现更高的目标，从而有助于取得积极的成果。

第六项原则：面对面的沟通 💬

第六项原则强调面对面的沟通。全球公认，面对面的沟通是最有效的，因为你可以获取语言和非语言的线索，可以向互动对象寻求澄清，并且发生摩擦或冲突的机会更小。

因此，敏捷原则鼓励客户与供应商之间、业务与开发社区之间、项目经理与团队之间进行面对面的沟通或对话。

第七项原则：可工作的软件是进度的首要度量标准 📈

第七项原则指出，可工作的软件是衡量进度的首要标准。

这与将需求文档或业务蓝图作为进度主要标准的方式相反。除非有可供业务使用的可工作软件，否则项目不会获得任何进展认可。因此，只有当产出对业务社区有用时，才能衡量项目的里程碑或进度。

第八项原则：提倡可持续的开发节奏 ⏱️

敏捷提倡可持续的开发。赞助者、开发者和用户应该能够无限期地保持恒定的节奏。敏捷项目管理框架的设计，更多地关乎速度、敏捷性，以及以可持续的方式提前交付价值和最终成果。

如你所知，许多无价值的活动或时间会浪费在项目冲突和问题上。敏捷方法论通过以下方式避免所有这些情况：

  • 提供自我激励的团队成员。
  • 促进他们进行面对面的互动。
  • 使所有思维过程或行动都倾向于产出可工作的软件。

正是通过这种方式，严谨性、速率、迭代、障碍管理、问题管理等所有活动，共同帮助在项目框架内实现可持续的开发。

第九项原则：持续关注技术卓越和良好设计 🔬

第九项原则指出，持续关注技术卓越和良好设计能增强敏捷性。

敏捷承认并认识到，技术卓越和良好设计是产出强大软件的支柱。因此，关注点在于将技术卓越和良好的设计能力引入项目团队中。

第十项原则：简洁——最大化未完成工作的艺术 ✂️

第十项原则是关于简洁性——最大化未完成工作的艺术至关重要。

在项目中，如果团队成员的行为倾向于产生无价值的活动，就无法获得最大的工作成效。

因此，敏捷引入了简洁的哲学：坚持最相关、最重要的事情，以及如何以最优的方式交付。敏捷也强调不做那些不能直接为项目软件带来价值、不能为最终客户带来价值、会导致返工或日后需要废弃的工作。

敏捷将焦点集中在避免所有此类工作，只做对软件开发有积极影响的工作。

第十一项原则：最好的架构、需求和设计出自自组织团队 🏗️

第十一项原则指出，最好的架构、需求和设计出自自组织团队。

这意味着，如果团队成员和他们的项目团队是自组织的，如果他们能够创新、跳出框框思考，那么最好的架构、最好的软件、最好的设计就会从团队中涌现出来。

为了交付独特的东西，为客户获得竞争优势，最好的架构和设计需要从团队成员中涌现，而这需要团队是自组织的。因此，敏捷方法致力于培养自组织团队和项目社区内的高度积极性。

第十二项原则：定期反思与调整 🔄

第十二项原则指出，团队定期反思如何能变得更高效，并相应地调整自身行为。

因此，会议被规划出来，让敏捷项目中的所有团队成员和角色坐下来回顾，讨论哪些做对了，哪些没做对，哪些可以做得更好，有哪些积极面和消极面，以及如何进一步改进。

他们就是这样反思项目上已完成的活动，并尝试将学到的经验纳入接下来的迭代中。为了给项目带来更高的效率，通过这样做，项目社区和团队就处于持续改进的道路上。

他们不重复过去的错误，将生产力和效率带入项目工作中，进而帮助项目以更快、更有效的方式实现价值。

本节课中我们一起学习了敏捷十二原则的后半部分。我们探讨了如何通过激发个体和构建自组织团队来释放创造力，强调了面对面沟通的重要性，并明确了以可工作的软件作为核心的进度衡量标准。我们还理解了保持可持续的开发节奏、追求技术卓越、践行简洁之道以及定期进行团队反思，是确保敏捷项目能够持续、高效交付价值的关键实践。这些原则共同构成了敏捷思维落地的坚实基础。

006：敏捷价值观框架 🎯

在本节课中，我们将学习敏捷方法论的核心价值观，并将其与传统项目管理方法进行对比。我们将深入探讨敏捷如何通过关注价值来克服传统“三重约束”的局限，并介绍敏捷框架的基本阶段。

理解敏捷价值观

上一节我们介绍了敏捷的核心理念，本节中我们来看看其具体的价值观体系。

在传统项目中，存在关于范围、质量和成本的“三重约束”。当你改变范围时，范围的变化会对质量或成本产生显著影响。当你想要提升质量时，范围和成本也需要向上调整。因此，这种三重约束在传统项目管理方法论中占主导地位。

而在敏捷方法中，所有这些三重约束都通过坚持价值而被克服，这里的价值包括外在质量和内在质量。当团队围绕成本、进度和范围工作时，他们引入了敏捷性。良好的沟通、可工作的软件产出以及协作，使得成本、范围和进度上的约束在敏捷方法论中被克服。

适应与确认

接下来我们探讨“适应”与“确认”这一组价值观。

在敏捷中，存在一个更倾向于业务和用户社区需求的灵活发布计划。规划的重点在于按特性进行：哪些特性优先级高，哪些特性是业务最迫切需要的。范围是灵活的，因此，关于范围和团队速率的变化都可以被交付。并且，在每一次迭代中都有学习发生。

相比之下，传统项目管理中的“确认”方法采用基线发布计划。一旦计划被基线化，交付物需要相当长的时间才能到达业务方手中，这导致了业务与项目团队之间的脱节。

以下是两种方法的关键区别列表：

  • 规划方式：传统项目管理按任务规划，而敏捷方法论规划交付价值。
  • 范围处理：传统项目管理基线化范围，而敏捷中范围是灵活的，范围根据团队的敏捷性以及客户和供应商的参与度来调整。
  • 学习时机：传统项目管理中，所有开发完成后进行测试，缺陷才被项目团队知晓并修复，学习发生在最后。而在敏捷中，学习发生在每一次迭代中，因为每次迭代都会向业务方交付可工作的软件，业务方提供反馈，项目团队从而获得学习。

因此，敏捷是适应性的，而传统项目管理方法论是确认性的。

领导与管理

理解了适应与确认的区别后，我们来看看“领导”与“管理”这一价值观。

在敏捷中，团队为自己设定目标。而在传统方法中，为团队成员提供任务清单。任务不一定产生价值，而目标肯定能为项目带来价值。因此，在设定目标方面，敏捷相比为团队成员定义任务具有更好的方法。

以下是两种模式下团队管理的核心差异：

  • 管理基础：传统方法中，团队成员通过任务被管理；而在敏捷中，团队成员通过他们带来的价值所依据的原则被管理。
  • 团队性质：敏捷强调创建自管理团队，因此管理上的汇报和开销更少。由于团队自我激励，他们能产生更好的结果。
  • 潜力发挥：在传统项目管理中，人们等待被告知需要做什么，并且只做被告知的事情，团队的完整潜力未被充分利用。而在敏捷中，团队的完整潜力得到发挥，团队不断超越自己的绩效基准，努力以更高的成果给团队带来惊喜。

敏捷框架概述

在对比了价值观之后，现在让我们来理解敏捷的实施框架。敏捷框架的第一步是“构想”，随后是“愿景”、“推测”、“准备发布计划”、“探索”和“适应”。然后，“适应”会进入下一个“推测”、“发布计划”、“探索”和“适应”的循环。一旦这些迭代完成，项目进入“收尾”阶段。

接下来，我们通过图示来了解每个阶段的具体工作。

敏捷框架详解

上一节我们概述了敏捷框架，本节中我们详细看看每个阶段。

构想阶段

在构想阶段，设计并规划项目的愿景、目标、约束、项目社区及其互动。这包括定义项目的全部内容、项目预期实现的目标、可能面临的约束或挑战、项目社区成员（关键干系人、业务方、开发者）以及他们的互动方式。

推测阶段

“推测”一词多用于交易术语，但敏捷所采用的整体方法是保持范围灵活性，并尝试在给定预算内交付最大价值，这就是推测的含义。敏捷团队不是预先承诺交付物，而是进行推测。在推测阶段，制定发布计划，该计划仅说明可以交付哪些特性以及大致的时间线。

探索阶段

进入探索阶段后，团队在较短的迭代中计划并交付经过测试、可运行的用户故事，不断寻求降低风险和不确定性。在探索阶段，他们承接用户故事或需求进行开发，将开发成果交付给业务社区并寻求反馈。

适应与循环

根据探索阶段获得的反馈，团队进入“适应”阶段，调整计划、范围或方法。随后，这又会引导至新的“推测”、“发布计划”和“探索”循环，形成一个持续的改进周期。

本节课中，我们一起学习了敏捷方法论的核心价值观，包括其如何以价值为中心克服传统约束，以及“适应”优于“确认”、“领导”优于“管理”的理念。我们还介绍了敏捷框架的基本阶段：构想、推测、探索和适应，理解了这是一个通过短迭代和持续反馈循环来交付价值并不断学习的动态过程。

007：敏捷团队构成

在本节课中，我们将要学习敏捷框架的“适应”与“收尾”阶段，并深入了解敏捷方法的起源、主要构成以及敏捷项目团队的核心角色与职责。

适应与收尾阶段概述

上一节我们介绍了敏捷框架的“构想”、“推测”和“探索”阶段。本节中我们来看看最后两个阶段：“适应”与“收尾”。

在“适应”阶段，成果被交付，当前状况受到监控。团队的绩效得到监控与提升，并且团队会根据需要随时适应变化。

在“收尾”阶段，团队进行总结。他们分享关于项目整体开发和软件的学习成果，并庆祝所取得的储备成果。我们将在第2章更详细地了解这个框架。目前，我们已简要概述了敏捷框架的五个阶段：构想、推测、探索、适应和收尾。

敏捷方法的起源与构成

现在，让我们来理解这些敏捷方法是如何出现的，以及它们是如何被命名的。

这个敏捷方法类别包含五种主要方法：

  • Scrum：起源于1986年。
  • DSDM：即动态系统开发方法，于1995年发展起来。
  • Crystal：于1997年提出。
  • FDD：即特性驱动开发，于1998年提出。
  • XP：即极限编程，于1999年提出。

请始终记住，敏捷方法包含这五种主要类别。任何单一方法都可以最好地利用这些方法中的任何一种，或者将它们全部结合使用。因此，这些方法通常是组合在一起使用的。

大多数组织从一系列敏捷实践中组合出他们的敏捷方法。当今常见的敏捷实践结合了所有上述命名流程的元素。因此，任何用于产品开发或软件项目的敏捷方法，都是所有这些元素的组合。

敏捷团队的角色与构成

现在，让我们花些时间来理解项目团队的构成。

虽然敏捷不是一个特定的流程，但一个通用的流程生命周期和角色已经出现。因此，所有敏捷项目都具有本质上通用的流程生命周期和角色。

在敏捷开发中，人员通常扮演三种“超级角色”之一。敏捷项目有三种角色，参与敏捷项目的人员会扮演这三种超级角色之一。并且，人员通常可以在这些角色之间自由转换。请记住，利益相关者拥有多重“帽子”。他们根据项目需求在项目中行动，并且可以随着情况需求更换“帽子”、转换角色。

因此，敏捷团队拥有三种团队角色，它们被称为超级角色。这些角色是可以互换的。一个敏捷流程会经历特定的流程生命周期并包含这些角色。

现在，让我们来理解团队的责任与构成。

一般来说，敏捷团队由以下成员构成：

  • 开发者：这些人员编写代码、开发界面、进行集成。
  • 架构师：这些人员负责设计人员、流程、产品、合作伙伴之间的整体交互，这被称为业务或企业架构。
  • 测试者：这些人员确保交付物符合需求。如果不符合，则修复缺陷并重新测试。因此，测试者在验证和确认方面扮演重要角色。
  • 业务分析师：这些人员确保需求被很好地获取。他们关注业务流程的数字化，确保产出的软件满足最终需求。
  • 用户界面设计师和交互设计师：这些人员确保两个系统、两个流程能够以和谐的方式相互交互，并且业务价值链中的所有交互都被捕获并数字化，以产生业务成果。

这些是敏捷项目中的关键角色。从通用的敏捷术语角度来看，如果你是软件构建的一部分，你就是团队的一员。因此，构建团队就是敏捷团队，他们是敏捷团队的一部分，将进行业务开发。

总结

本节课中我们一起学习了敏捷框架的最后两个阶段——“适应”与“收尾”，了解了敏捷方法的五大主要起源（Scrum, DSDM, Crystal, FDD, XP），并深入探讨了敏捷团队的核心构成。我们明确了敏捷团队通常包含开发者、架构师、测试者、业务分析师以及界面/交互设计师这几种关键角色，并且这些“超级角色”在项目中可以根据需要灵活转换。理解这些角色和流程是组建高效敏捷团队的基础。

008：团队构成（续）👥

在本节中，我们将继续探讨敏捷团队中的关键角色，特别是Scrum Master/教练和产品负责人。理解这些角色的职责对于构建一个高效协作的敏捷团队至关重要。

上一节我们介绍了敏捷团队的基本构成，本节中我们来看看两个核心的引导与决策角色。

Scrum Master/教练 🧑‍🏫

Scrum Master或教练帮助团队保持流程顺畅运行。

他确保团队中的每个人都理解自己的角色和职责。因此，教练能带来关于角色和职责的清晰性。

他帮助团队成员获得支持和培训。他是理解团队成员“热力图”的人，即了解团队成员的能力差距、培训需求，以及偶尔需要的手把手支持。

他处理阻碍团队速度的问题和障碍。他充当加速器的角色，确保那些拖慢流程或项目进度的问题能够得到快速有效的解决。

他协助规划会议、产品评审会议和回顾会议。因此，规划、由业务方进行的评审，以及关于管理变更的回顾会议，所有这些都是在Scrum Master或教练的帮助下完成的。

通常，教练这个角色在过去传统的软件开发方法中，可能由项目经理或开发负责人担任。那些在业务社区或项目社区中拥有一定权威和竞争力的人，通常会被提名为Scrum Master或教练。Scrum Master或教练的角色至关重要，因为他们充当加速器，明确每个人的分工，在需要时提供培训和支持，并确保回顾会议和产品评审能有效进行。

产品负责人 📋

现在让我们来理解产品负责人是谁。“产品负责人”这个名称来源于Scrum框架，而“客户”角色名称则来源于极限编程。

产品负责人描述要构建什么，并对产品交付后的成果负责。因此，产品负责人是构建物的设计和规格的监护人，他确保其与业务需求保持一致，并且客户建议的任何变更不会对整体构建产生负面影响。

虽然这个角色听起来是单个人的职责，但整个团队都会支持这个角色，以确保在产品所有权在项目内得到良好处理。

以下是支持这一角色的团队成员及其职责：

  • 业务分析师：确保对业务正确的内容被传达和开发出来。
  • UI设计师和交互设计师：确保开发是用户友好的，并且用户界面根据业务需求达到最优。
  • 架构师：确保可靠性、健壮性和性能得到处理。
  • 测试人员：确保开发在验证和确认方面满足业务需求。
  • 领域专家：确保遵循行业最佳实践。
  • 用户：确保开发适合使用，并且采用特定软件能带来效率。

第一章总结与练习 📚

至此，我们完成了第一章“敏捷项目介绍”的学习。

在本章中，我们一起学习了：

  • 典型的项目管理方法论是什么？
  • 什么是项目管理、项目集管理和项目组合管理？
  • 什么是敏捷宣言？
  • 敏捷所倡导的四个价值观是什么？
  • 十二项原则是什么？
  • 我们理解了敏捷项目框架。
  • 我们理解了团队构成。
  • 我们理解了几个关键角色。

现在是练习时间。我们在这里列出了几个问题，需要你进行回答。请完成这个练习，你有30分钟时间解答以下五个问题：

  1. 列举传统项目管理方法与敏捷项目管理方法的两个区别。
  2. 定义敏捷方法的五种类型。
  3. 列出敏捷宣言的显著特点。
  4. 绘制并解释敏捷框架。
  5. 说出三个重要的敏捷团队角色。

请完成这个练习，它将有助于进一步巩固你对敏捷项目管理框架的理解。

当你完成这个练习后，我们将进入下一章：敏捷项目框架。

敏捷实践：01：Scrum实践导论 🚀

在本节课中，我们将要学习Scrum这一敏捷实践的核心概念、框架和运作方式。Scrum是一个帮助团队在最短时间内交付最高业务价值的轻量级框架。

什么是Scrum？

Scrum是一种敏捷过程，它使我们能够专注于在最短时间内交付最高的业务价值。因此，Scrum的首要原则是在最短时间内交付最高价值。

它允许我们快速且反复地检查实际可工作的软件。业务方设定优先级，团队则自组织地决定交付最高优先级特性的最佳方式。

每隔两周到一个月，每个人都能看到真实可工作的软件，并决定是将其作为产品发布，还是在下一个冲刺中继续增强。

Scrum是一个框架，人们可以在其中处理复杂的适应性问题，同时高效且创造性地交付最高价值的产品。Scrum有三个特点：一、轻量级；二、易于理解；三、极难精通。

Scrum是一个自20世纪90年代初以来就被用于管理复杂产品开发的过程框架。Scrum本身不是一个构建产品的过程或技术，而是一个框架，你可以在其中运用各种过程和技术。Scrum能清晰地展示你的产品管理和开发实践的效果，以便你进行改进。

Scrum框架的构成

Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架内的每个组件都有特定目的，对Scrum的成功和使用至关重要。

使用Scrum框架的具体策略各不相同，并在相关文档中描述。Scrum的规则将事件、角色、工件以及它们之间的管理关系和交互绑定在一起。这些规则在培训文档的主体部分有详细描述。

Scrum建立在称为经验主义的经验过程控制理论之上。经验主义主张知识来源于经验，并基于已知信息做出决策。Scrum采用迭代和增量的方法来优化可预测性和控制风险。

经验过程控制的三大支柱支撑着每一次实践：透明度、检视和适应。

  • 透明度：过程的显著方面必须对负责结果的人可见。透明度要求这些方面根据共同标准定义，以便观察者对所看到的内容有共同理解。例如，所有参与者必须共享一个指代过程的共同语言，执行工作的人和接受工作产品的人必须共享一个“完成”的共同定义。
  • 检视：Scrum使用者必须频繁检视Scrum工件和达成目标的进展，以发现不可取的偏差。检视不应过于频繁以至于妨碍工作。当熟练的检视者在工作现场勤勉地执行时，检视最为有益。
  • 适应：如果检视者确定过程的某个或多个方面偏离了可接受的范围，并且将导致产品不可接受，则必须调整过程或被处理的材料。必须尽快进行调整，以最小化进一步的偏差。

Scrum规定了四个正式的检视和适应机会，在Scrum事件部分有描述：Sprint计划会议、每日Scrum站会、Sprint评审会议和Sprint回顾会议。

Scrum的特点

上一节我们介绍了Scrum的框架和支柱，本节中我们来看看Scrum的具体特点。

关于团队：团队是自组织的。团队自己组织团队会议、评审、回顾和沟通。

关于过程：产品开发在一系列为期一个月的冲刺中进行。软件或产品的开发作为月度冲刺的一部分推进，其中从待办事项列表中选取项目进行开发。有每日站会、月度冲刺，最终从冲刺中产生可交付的产品。

关于需求：需求以产品待办事项列表中的项目形式捕获。因此，产品待办列表是一个占位符，是所有产品开发的输入来源。来自用户故事的所有需求都被捕获在产品待办列表中。

关于工程实践：Scrum没有规定特定的工程实践。因此，Scrum与特定的工程实践无关，你可以使用一种、两种或多种工程实践的组合来进行产品开发。

Sprint流程

作为敏捷过程之一，Scrum的运作遵循一个清晰的流程。

以下是最常用于阐述冲刺过程的示意图。左侧是产品待办列表，由用户故事组成。基于产品待办列表，确定一个冲刺目标，并创建冲刺待办列表。

冲刺待办列表经历为期30天的冲刺，每个30天的冲刺包含24小时的日循环周期。在冲刺结束时，会产生潜在可交付的产品增量。

因此，Scrum的逻辑流程是：产品待办列表 -> 冲刺待办列表 -> 30天冲刺 -> 潜在可交付的产品增量。

冲刺的节奏与工作方式

Scrum项目通过一系列冲刺取得进展，这类似于极限编程的迭代。冲刺的典型持续时间最多为一个日历月。通常不允许冲刺超过30天。

固定的持续时间能带来更好的节奏感，因为团队成员习惯于在预定的时间内完成冲刺待办列表，他们习惯于进入开发和交付可交付产品的30天周期。一旦开始冲刺，团队内部就会形成一种节奏和韵律。

产品在冲刺期间进行设计、编码和测试，因此所有设计、编码和测试活动在冲刺期间同时进行。

重叠式开发

这里展示的图表显示了两种方法：第一种是顺序式，第二种是重叠式。

在顺序式开发中，需求、设计、编码和测试这些阶段一个接一个地进行，阶段之间几乎没有重叠。

而在重叠式开发中，你可以看到需求、设计、编码和测试同时发生。重叠式开发的基本原理是，Scrum团队不是一次做完所有的一件事，而是一次同时做每件事的一小部分。

这两种方法各有优缺点，但目前我们将讨论具有巨大优势的重叠式开发方法。

Scrum框架的三要素

Scrum框架包含三大要素：角色、事件和工件。

以下是每个要素的具体内容：

  • 角色：产品负责人、Scrum Master、开发团队。
  • 事件：Sprint计划会议、每日Scrum站会、Sprint评审会议、Sprint回顾会议。
  • 工件：产品待办列表、冲刺待办列表、产品增量。

总结

本节课中我们一起学习了Scrum实践导论。我们了解到Scrum是一个旨在快速交付价值的敏捷框架，其核心在于经验主义的三大支柱：透明度、检视和适应。Scrum通过固定周期的冲刺、自组织团队和重叠式开发来运作，其框架由明确的角色、事件和工件构成。掌握Scrum需要理解这些基础概念并在实践中不断应用和优化。

010：产品负责人、Scrum主管与团队 👥

在本节课中，我们将要学习Scrum框架中的三个核心角色：产品负责人、Scrum主管和开发团队。理解这些角色的职责和特点，是成功实施Scrum的基础。

产品负责人 📋

上一节我们介绍了Scrum的基本规则，本节中我们来看看第一个核心角色——产品负责人。

产品负责人负责最大化产品价值和开发团队工作的价值。具体实现方式可能因组织、Scrum团队和个人而异。产品负责人是唯一负责管理产品待办事项列表的人。

产品待办事项列表管理包括以下工作：

  • 清晰地表达产品待办事项列表项。
  • 对产品待办事项列表中的条目进行排序，以最好地实现目标和使命。
  • 确保开发团队执行工作的价值。
  • 确保产品待办事项列表对所有人可见、透明和清晰，并显示Scrum团队接下来要做什么。
  • 确保开发团队充分理解产品待办事项列表中的条目。

产品负责人可以自己完成上述工作，也可以让开发团队来完成。然而，产品负责人对此仍负有最终责任。产品负责人是一个人，而不是一个委员会。产品负责人可以在产品待办事项列表中代表委员会的意愿，但任何想要更改待办事项优先级的人都必须说服产品负责人。

为了让产品负责人成功，整个组织必须尊重他/她的决定。产品负责人的决定体现在产品待办事项列表的内容和排序中。任何人都不允许告诉开发团队去执行另一套不同的需求，开发团队也不允许按照其他人的指令行事。

总结来说，产品负责人的职责如下：

  • 定义产品特性：作为产品的负责人，他设计产品的特性、功能和各方面。
  • 决定发布时间与内容：他决定发布的日期和内容。
  • 负责产品盈利：确保投资能产生正回报，例如净现值、投资回报率对客户而言是积极的。
  • 根据市场价值确定特性优先级：产品负责人将运用自己的专业知识和技能，收集所有必要信息，根据市场价值来决定特性的优先级。
  • 在每次迭代中调整特性与优先级：随着迭代进行，产品负责人有机会对特性和优先级进行进一步的微调，不断添加、删除或调整特性和优先级。
  • 质量控制：作为质量控制的把关者之一，他接受或拒绝工作成果。

Scrum主管 🛡️

了解了产品负责人的职责后，接下来我们认识Scrum团队中的另一个关键角色——Scrum主管。

Scrum主管负责确保Scrum被理解并得到贯彻。Scrum主管通过确保Scrum团队遵循Scrum理论、实践和规则来做到这一点。Scrum主管是Scrum团队的仆人式领导者。

Scrum主管帮助团队外的人员理解哪些与Scrum团队的互动是有益的，哪些不是。Scrum主管帮助每个人改变这些互动方式，以最大化Scrum团队创造的价值。

Scrum主管为产品负责人提供服务，方式包括：

  1. 寻找有效的产品待办事项列表管理技术。
  2. 清晰地向开发团队传达愿景、目标和产品待办事项列表项。
  3. 教导Scrum团队创建清晰、简洁的产品待办事项列表项。
  4. 在经验主义环境中理解长期规划。
  5. 理解并实践敏捷性。
  6. 根据需要或要求，促进Scrum事件。

同样地，Scrum主管也为开发团队提供服务，包括：

  1. 指导开发团队进行自组织和跨职能协作。
  2. 教导并引导开发团队创造高价值产品。
  3. 移除阻碍开发团队进度的障碍。
  4. 根据需要或要求，促进Scrum事件。
  5. 在尚未完全采纳和理解Scrum的组织环境中指导开发团队。

此外，Scrum主管也为整个组织提供服务，方式包括：

  1. 领导并指导组织采纳Scrum。
  2. 规划组织内的Scrum实施。
  3. 帮助员工和利益相关者理解并实施Scrum和经验性产品开发。
  4. 推动变革以提高Scrum团队的生产力。
  5. 与其他Scrum主管合作，提高Scrum在组织中的应用效果。

总结来说，Scrum主管的职责如下：

  • 在项目中代表管理层。
  • 负责推行Scrum价值观和实践。
  • 移除障碍。
  • 确保团队功能完整且高效。
  • 促进所有角色和职能之间的紧密合作。
  • 保护团队免受外部干扰。

开发团队 👨‍💻👩‍💻

最后，我们来了解Scrum框架中负责交付价值的核心执行者——开发团队。

开发团队由专业人士组成，他们在每个Sprint结束时完成交付一个潜在可发布的、“完成”的产品增量。只有开发团队的成员才能创建这个增量。

开发团队由组织构建并授权，以组织和管理他们自己的工作，由此产生的协同作用优化了团队的整体效率和效能。

开发团队具有以下特征：

  1. 自组织：没有人（甚至包括Scrum主管）会告诉开发团队如何将产品待办事项列表转化为潜在可发布的功能增量。
  2. 跨职能：作为一个团队，拥有创建产品增量所需的所有技能。
  3. 无头衔：Scrum不为开发团队成员设定除“开发者”以外的任何头衔。无论个人承担何种工作，此规则没有例外。
  4. 集体负责：个别开发团队成员可能拥有专业技能和专注领域，但责任属于整个开发团队。
  5. 无子团队：开发团队内部不包含专门负责特定领域（如测试或业务分析）的子团队。

开发团队的规模：最佳的开发团队规模是足够小以保持灵活，又足够大以完成重要工作。少于3名成员会减少互动并导致生产力增益降低。规模过小的团队可能在Sprint期间遇到技能限制，导致无法交付潜在可发布的增量。超过9名成员则需要过多的协调工作。规模过大的团队会给经验性过程管理带来过多复杂性。产品负责人和Scrum主管的角色不计入此人数，除非他们也参与Sprint待办事项的工作。

总结来说，团队通常有 5到9人。团队构成是跨职能的，主要包括开发者、测试员等，例如程序员、测试员、用户体验设计师等。成员应为全职，例外情况下某些成员可以是兼职，例如数据库管理员。

本节课中我们一起学习了Scrum框架的三个核心角色：产品负责人负责定义价值与优先级，Scrum主管负责移除障碍与保障流程，开发团队负责交付可工作的产品增量。这三个角色各司其职又紧密协作，共同构成了Scrum团队成功的基础。

011：Scrum与经验性过程控制 🚀

在本节课中，我们将学习敏捷项目管理中的核心框架——Scrum。我们将从理解其理论基础“经验性过程控制”开始，逐步探讨Scrum的角色、会议和工件，帮助你掌握这一流行敏捷方法的基本构成。

什么是经验性过程控制？🤔

上一节我们介绍了课程的整体议程，本节中我们来看看第一个核心概念：经验性过程控制。

经验性过程控制模型，为那些定义不完善且产出不可预测、不可重复的过程，提供了通过频繁检视和调整来实施控制的方法。

在一个过程中，存在两类情况：

  • 定义完善的过程：能产生完美、可重复的结果。
  • 定义不完善的过程：无法产生可重复的产出。

例如，开发一个预期在10分钟内执行的软件。如果该软件始终能在10分钟内给出稳定输出，则过程是完善的。如果其输出有时是2分钟，有时是20或50分钟，则产出了不可重复的结果。经验性过程方法正是针对这类定义不清晰、产出不一致的过程，进行频繁的检视和调整。因此，检视与调整是经验性过程的支柱。

定义过程 vs. 经验过程 🔄

理解了经验性过程后，我们有必要将其与传统的定义过程进行对比，以明确各自的适用场景。

定义过程，顾名思义，是制定了可重复且能产出符合质量标准的输出的过程。这被称为定义过程控制。你知道软件能给出稳定的测试结果，你知道界面响应能稳定在毫秒级。这些都是稳定且符合质量标准的产出，是定义过程的关键特征。定义过程被清晰地规划出来，是表述精确的流程，其产出也是一致、可靠且符合质量标准的。质量学、持续改进、六西格玛等方法的旅程，正是将不可预测的过程转变为定义过程。

以下是定义过程与经验过程的主要区别：

  • 定义过程：当底层机制被充分理解时，采用定义建模方法。定义过程基于建模方法，其关键输入、驱动因素、影响最终结果的参数都已被充分理解。你对过程拥有大部分信息，变量在控制之中，对其有足够的知识。
  • 经验过程：当过程过于复杂，无法采用定义方法时，则采用经验过程。当过程过于复杂，有多个参数影响最终结果，且这些参数与输出之间没有非常标准或线性的关系时，就是经验过程。例如，一个软件能检测95%的缺陷，但5%的缺陷需要人工检查才能捕获。这类过程对其输入、参数、变量的信息掌握度较低，无法给出符合预期的稳定输出，经验方法就适用于此类过程。

定义过程具有成本优势，产品可作为商品定价。因为变量少、标准差小、信息充分，你可以将产品商品化，并将成本优势传递给客户。如果商品化产品符合质量要求，而经验过程控制则返工率高、成本更高。如果过程定义不清晰、存在复杂性、无法将产品商品化、必须为每次开发采取定制化方法，那么成本自然更高，经验过程控制就成为生产该产品的唯一选择。

经验过程的平衡与支柱 ⚖️

在对比了两种过程后，本节我们来深入看看经验过程的一些关键特性，特别是如何平衡复杂性与它的三大支柱。

让我们通过一个简单的图表来理解经验过程。Y轴是需求复杂性，X轴是技术复杂性。如图所示，如果需求复杂性高，技术复杂性就需要最小化；反之，如果技术复杂性非常高，需求就需要简单化。这个倒C形曲线表明，需要在需求复杂性和技术复杂性之间取得适当平衡，保持开发的简洁性，并逐步为产品增加技术和需求的复杂性。

经验过程有三个核心特征：

  1. 它主张知识来源于经验，并根据已知信息做出决策。因此，经验是经验性过程的基石。因为它提供了历史信息，建立了基准，让你知道如何在困难情况下导航、克服复杂性，并根据已知信息决策，将未知因素搁置一旁，更侧重于利用现有信息支持决策。
  2. 支撑经验性过程实施的三大支柱是：透明、检视、调整。
    • 透明：关于什么在起作用、什么不起作用、什么过程产生什么输出、存在哪些缺陷、有哪些返工、关键关注领域是什么、某项决策有哪些信息或数据支持。
    • 检视：进行频繁的检视。除非你检视，否则无法获得正确的信息。因此，要努力建立信息库以支持决策，进行频繁检视并收集关于结果、输出一致性、可重复性等信息。
    • 调整：正在开发/生产的内容适应得如何？存在哪些适应挑战？以便规划和引入进一步的改进。

这就是经验性过程的关键特征。接下来，我们将在下一节中了解Scrum。

本节课总结：本节课我们一起学习了敏捷项目管理的核心基础。我们首先探讨了经验性过程控制的概念，理解了它通过检视和调整来管理复杂、不确定的项目。接着，我们对比了定义过程与经验过程的适用场景与区别。最后，我们深入分析了经验过程的平衡艺术及其三大支柱：透明、检视、调整，为接下来学习具体的Scrum框架打下了坚实的理论基础。

012：冲刺评审 🚀

概述

在本节课中，我们将学习敏捷开发中冲刺评审的核心流程。我们将从冲刺规划开始，了解团队如何从产品待办事项列表中选取任务，并详细探讨每日站会的运作机制、目的及其规则。

冲刺规划流程 📋

上一节我们介绍了敏捷的基本框架，本节中我们来看看冲刺规划的具体步骤。

幻灯片展示了一个高层次的冲刺规划流程。团队首先审视一个有优先级的产品待办事项列表，然后创建冲刺待办事项列表。这个过程由引导者（通常是Scrum Master）来推动。

冲刺待办事项列表 是用于规划冲刺和交付可发布工作项给客户的依据。

以下是团队创建冲刺待办事项列表的步骤：

  1. 选择任务：团队从产品待办事项列表中选取他们承诺能够完成的项目。
  2. 选择标准：选择的标准基于那些能为客户创造最大价值，并且能在规定时间内交付给客户的功能主题。
  3. 分解与估算：基于团队的输入创建冲刺待办事项列表，识别具体任务，并对每个任务进行估算（通常为1到16小时）。
  4. 任务排序：将冲刺待办事项分解为任务，创建任务序列，并估算每个任务所需时间。

这个过程需要所有团队成员协作完成，而不是由个人或Scrum Master单独决定。规划时通常会考虑高层设计。例如，如果团队正在设计一个招聘门户网站，他们可能会预估中间层开发需要8小时，用户界面编码需要4小时，编写测试用例需要4小时，等等。冲刺规划就是这样完成的。

每日站会详解 🗣️

完成了冲刺规划，团队就进入了冲刺执行阶段。在这个阶段，每日站会是保持同步和调整方向的关键活动。

每日站会 是一个限时15分钟的活动，目的是让开发团队同步工作进展并为接下来24小时制定计划。

这是通过检视自上次站会以来的工作，并预测在下次站会前能完成什么来实现的。每日站会每天在相同时间、相同地点举行，以减少复杂性。

在会议期间，每位开发团队成员需要说明：

  • 自上次会议以来完成了什么？
  • 在下次会议前计划做什么？
  • 遇到了什么障碍？

开发团队利用每日站会来评估朝向冲刺目标的进展，以及评估完成冲刺待办事项列表中工作的趋势。每日站会优化了开发团队达成冲刺目标的可能性。开发团队经常在站会后立即开会，重新规划冲刺剩余的工作。

每天，开发团队都应该能够向产品负责人和Scrum Master说明，他们打算如何作为一个自组织团队协作，以完成目标并在冲刺剩余时间内创造预期的增量。

Scrum Master确保开发团队召开此会议，但会议由开发团队负责主持。Scrum Master教导开发团队将每日站会控制在15分钟的时间盒内。

如果团队需要超过15分钟，Scrum Master会询问所有人：“我们需要讨论一些重要事项，这会超出15分钟的时间盒。大家是否同意再延长五分钟？” 如果所有人都同意，会议继续；否则，会议在15分钟后结束。

Scrum Master强制执行规则：只有开发团队成员可以参与每日站会。每日站会不是状态汇报会议，而是为那些将产品待办事项转化为增量的人服务的。

每日站会能改善沟通、消除其他不必要的会议、识别并移除开发障碍、突出并促进快速决策，以及提高开发团队的产品知识水平。这是一个关键的检视和调整会议。

每日站会的基本原理是确保细粒度的协调：

  • 团队完成了什么
  • 团队正在做什么
  • 他们需要什么帮助
  • 需要解决哪些风险问题以保证团队有效运作

它旨在寻求承诺（今天结束前能完成什么？），推动团队成员完成每日工作，提出障碍以便被理解、解释和解决。整个生态系统会对表现不佳的成员施加压力，以提升他们的表现，使其与同伴匹配，同时评估朝向冲刺目标的进展。

以下是每日站会的关键参数：

  • 频率：每日举行。
  • 时长：15分钟。
  • 形式：站立会议。
  • 性质：不是问题解决会议，而是一种以不同方式进行的会议。
  • 参与者：仅限团队成员参加。Scrum Master和产品负责人可以旁听。
  • 作用：有助于避免不必要的会议。这是团队必须参加的唯一会议，因此他们的会议承诺在此完成。
  • 责任：团队负责主持此会议。这是自组织团队的责任。

会议的核心问题是：

  1. 你昨天做了什么？
  2. 你今天打算做什么？
  3. 有什么阻碍你的进展吗？

总结

本节课中，我们一起学习了敏捷冲刺评审的两个核心环节。首先，我们详细了解了冲刺规划的流程，包括如何从产品待办事项中选取和估算任务以形成冲刺待办事项列表。接着，我们深入探讨了每日站会的目的、规则和最佳实践，认识到它是团队同步、识别障碍和保持冲刺进度的关键日常活动。掌握这些实践，有助于团队更高效地协作并交付价值。

013：Sprint评审会议 🧑‍💻

在本节课中，我们将要学习Scrum框架中的一个关键会议——Sprint评审会议。我们将了解它的目的、参与者、时间安排以及会议的具体流程。

Sprint评审会议在Sprint结束时举行，目的是检视本次Sprint产出的增量成果，并根据需要调整产品待办事项列表。

会议目的与性质

上一节我们介绍了Sprint评审会议的基本定位，本节中我们来看看它的核心目标和会议风格。

Sprint评审会议是一个非正式的会议。在会议期间，Scrum团队和利益相关者会基于已完成的成果进行协作，讨论接下来可以做什么。演示增量成果的目的是为了获取反馈并促进协作。

会议时间安排

了解了会议的性质后，我们来看看它的时间是如何安排的。

这是一个有时限的会议。对于一个月的Sprint，评审会议时间按比例设定。对于更短的Sprint，分配的时间会更少。例如，一个两周的Sprint，其评审会议时长通常为两小时。

会议核心流程

明确了时间安排，接下来我们深入探讨Sprint评审会议的具体流程和构成要素。

Sprint评审会议包含以下几个核心环节：

以下是会议的具体步骤：

  1. 产品负责人说明完成与未完成项：产品负责人识别在本次Sprint中哪些工作已经完成，哪些尚未完成。
  2. 开发团队讨论过程与问题：开发团队讨论在Sprint期间哪些方面进展顺利，遇到了什么问题，以及这些问题是如何解决的。
  3. 演示工作成果并答疑：开发团队演示已完成的工作，并回答关于增量成果的问题。
  4. 审视产品待办事项列表：产品负责人讨论当前的产品待办事项列表状态，并根据进度数据预测可能的完成日期。
  5. 全体协作规划下一步：整个小组（包括团队和利益相关者）协作讨论接下来要做什么。

因此，Sprint评审会议为后续的Sprint计划会议提供了宝贵的输入信息。

会议产出与规则

在走完上述流程后，会议会产生明确的产出。同时，为了确保会议高效，有一些重要的规则需要遵守。

Sprint评审会议的结果是一个修订后的产品待办事项列表，该列表定义了下一个Sprint可能的产品待办事项项。产品待办事项列表也可能进行整体调整，以应对新的机遇。

为了确保团队专注于为最终客户交付价值，而不是花费过多精力准备会议，有一条“两小时准备时间”规则适用于Sprint评审会。这意味着没有人会为准备Sprint评审花费超过两小时。

会议形式总结

最后，我们来总结一下Sprint评审会议的典型形式。

团队展示在本次Sprint中完成的工作，通常包括新功能或底层架构的演示。会议中不使用幻灯片，讨论以面对面形式为主，并包含对开发产品的演示。整个团队都参与评审会议。

本节课中我们一起学习了Sprint评审会议。我们了解到它是一个在Sprint结束时举行的、非正式的检视与调整会议，核心目的是展示增量、获取反馈并协作规划下一步。会议有固定的时间盒，遵循特定的流程，并产出修订后的产品待办事项列表，为下一个Sprint的规划奠定基础。

014：回顾性研究

在本节课中，我们将要学习Scrum框架中的两个核心事件：每日站会和冲刺回顾会。我们将了解它们的目的、结构、参与角色以及如何有效执行，以帮助团队持续改进。

每日站会

上一节我们介绍了冲刺规划，本节中我们来看看团队如何保持日常同步。每日站会是一个限时15分钟的活动，旨在让开发团队同步工作，并为接下来的24小时制定计划。

该活动通过检视自上次站会以来的工作，并预测在下一次站会前可以完成的工作来实现。

每日站会每天在固定时间和地点举行，以减少会议复杂性。在会议中，每位开发团队成员需要说明：

以下是每位成员需要回答的三个核心问题：

  • 自上次会议以来完成了什么？
  • 下次会议前计划做什么？
  • 遇到了什么障碍？

开发团队利用这些信息来评估向冲刺目标的进展，并评估冲刺待办列表中工作的完成趋势。每日站会优化了开发团队达成冲刺目标的可能性。

开发团队通常在每日站会后立即碰头，重新规划冲刺剩余的工作。每一天，开发团队都应该能够向产品负责人和Scrum Master解释，他们打算如何作为一个自组织团队来达成目标，并在冲刺剩余时间内完成预期的增量。

Scrum Master确保开发团队召开此会议，但开发团队负责主持每日站会。Scrum Master教导开发团队将每日站会控制在15分钟的时间盒内。Scrum Master强制执行规则：只有开发团队成员可以参与每日站会。

每日站会不是状态汇报会议，而是为那些将产品待办列表转化为增量的人服务的会议。每日站会能够：

  • 改善沟通
  • 消除其他不必要的会议
  • 识别并移除开发障碍
  • 突出并促进快速决策
  • 提升开发团队的项目知识水平

这是一个关键的检视与调整会议。因此，每日站会主要用于获取产品反馈、展示开发进展以及促进障碍移除和团队协作。

冲刺回顾会

了解了每日的检视调整后，我们来看看在冲刺周期结束时，团队如何进行更全面的反思。冲刺回顾会为Scrum团队提供了一个检视自身并制定改进计划的机会，以便在下个冲刺中实施。

冲刺回顾会发生在冲刺评审会之后、下一个冲刺规划会之前。

这是一个限时会议，对于为期一个月的冲刺，会议时长通常为3小时。对于更短的冲刺，按比例分配更少的时间。

冲刺回顾会的目的是：

  1. 检视上一个冲刺在人员、关系、过程和工具方面的表现。
  2. 识别并排序做得好的主要事项和潜在的改进点。
  3. 制定计划，以改进Scrum团队的工作方式。

Scrum Master鼓励Scrum团队在Scrum过程框架内，改进其开发过程和实践，使其在下一个冲刺中更高效、更愉快。在每个冲刺回顾会期间，Scrum团队会通过适时调整“完成的定义”来规划提高产品质量的方法。

在冲刺回顾会结束时，团队应该已经识别出将在下一个冲刺中实施的改进项。在下个冲刺中实施这些改进，是对Scrum团队自身的检视与调整。尽管改进可以在任何时候实施，但冲刺回顾会提供了一个专注于检视与调整的正式机会。

因此，冲刺回顾会定期举行，以审视哪些做法有效、哪些无效。它在每个冲刺结束后进行。参与者包括Scrum Master、开发团队和产品负责人。有时还会对回顾会本身进行回顾，评估回顾会的计划和执行情况。

其重点是观察和促进。通常的步骤是：停止做、开始做、继续做。

以下是团队在回顾会中常问的问题：

  • 我们应该停止哪些活动？
  • 我们应该开始哪些活动？
  • 我们应该继续哪些活动？

这些问题旨在帮助团队即兴发挥、进一步加快速度、加强协作等。

本节课中我们一起学习了每日站会和冲刺回顾会。每日站会是团队每日同步和快速调整的短会，而冲刺回顾会是团队在每个冲刺结束后进行深度反思和制定系统性改进计划的关键会议。两者都是Scrum框架中实现持续改进和适应变化的核心实践。

015：冲刺会议 🏃‍♂️

在本节课中，我们将要学习敏捷开发中一个核心的会议——冲刺规划会议。我们将了解它的目的、结构、参与角色以及如何有效地执行，以帮助团队在固定周期内交付可工作的产品增量。

团队组织与仪式

理想的敏捷团队是自组织的，通常不设头衔，但这在实践中较为少见。团队成员通常只在冲刺之间进行调整。

现在，我们来看看Scrum框架中的核心仪式。一个冲刺周期主要包括以下活动：

  • 冲刺规划：规划本冲刺的工作。
  • 冲刺执行：进行日常开发工作，包括每日站会。
  • 冲刺评审：对产品增量进行检查。
  • 冲刺回顾：对开发过程进行检查和改进。

接下来，让我们深入探讨冲刺规划会议。

深入冲刺规划会议

冲刺规划会议的目的是为即将到来的冲刺制定计划。该计划由整个Scrum团队协作创建。

会议时长是固定的。对于一个月的冲刺，会议时间盒为8小时。对于更短的冲刺，会议时间按比例缩短。例如，一个两周的冲刺，规划会议时长为4小时。

冲刺规划会议由两个部分组成，每个部分的时间各占会议总时长的一半。这两个部分分别回答以下两个核心问题：

  1. 本次冲刺要交付什么？
  2. 如何完成这些工作？

第一部分：本次冲刺要做什么？🎯

在这一部分，开发团队需要预测在冲刺中将要开发的功能。产品负责人向开发团队展示已排序的产品待办事项列表，整个Scrum团队协作理解冲刺的工作内容。

本部分的决策依据包括：

  • 最新的产品待办事项列表
  • 最新的产品增量
  • 开发团队在本冲刺的预计产能
  • 开发团队过往的表现

只有开发团队能够评估在接下来的冲刺中可以完成什么。在开发团队预测了要交付的产品待办事项后，Scrum团队共同制定一个冲刺目标。冲刺目标是通过实现产品待办事项列表要在本次冲刺中达成的目的，它为开发团队构建产品增量提供了指引。

第二部分：选定的工作如何完成？🔧

在选定了冲刺的工作内容后，开发团队需要决定如何将这些功能构建成“已完成”的产品增量。为本冲刺选定的产品待办事项项及其交付计划，合称为冲刺待办事项列表。

开发团队通常从设计系统开始，规划如何将产品待办事项转化为可工作的产品增量。工作可以按规模或预估工作量来划分。在规划会议中，团队会规划足够的工作量，以便能预测在即将到来的冲刺中可以完成的任务。开发团队会将冲刺头几天的工作分解为一天或更小的单位。

开发团队是自组织的，他们自行承担冲刺待办事项列表中的工作。在规划会议期间以及整个冲刺中，产品负责人可能需要在场，以澄清选定的产品待办事项，并在开发团队认为工作过多或过少时协助调整。开发团队也可以邀请其他人参会，以提供技术或领域建议。

在冲刺规划会议结束时，开发团队应该能够向产品负责人和Scrum主管解释，他们打算如何作为一个自组织团队来完成冲刺目标并创建预期的产品增量。

会议流程与产出总结

简而言之，在冲刺规划中，团队和产品负责人协作，帮助团队确定在即将到来的冲刺中能将多少产品待办事项转化为功能。团队通过识别将选定产品待办事项转化为功能所需的任务，来创建称为“冲刺待办事项列表”的计划。

下图展示了冲刺规划会议的流程：

输入包括：

  • 团队产能
  • 产品待办事项列表
  • 业务条件
  • 当前产品与技术状态

会议分为两部分：

  1. 第一部分：确定优先级。分析和评估产品待办事项列表，并选定冲刺目标。
  2. 第二部分：制定计划。决定如何实现冲刺目标，进行设计，从产品待办事项项中创建任务，并估算冲刺待办事项列表。

输出是：

  • 冲刺目标
  • 冲刺待办事项列表

理解冲刺目标

冲刺目标为开发团队在实现冲刺内的功能时提供了一定的灵活性。开发团队在工作时会始终牢记这个目标。为了满足冲刺目标，他们会实现相应的功能和技术。

如果实际工作与开发团队的预期不同，他们会与产品负责人协作，在冲刺内协商调整冲刺待办事项列表的范围。冲刺目标可能是产品路线图中更大目标的一个里程碑。

总结

本节课中，我们一起学习了敏捷Scrum框架中的冲刺规划会议。我们了解到，这是一个结构化的、时间盒限定的会议，旨在回答“做什么”和“怎么做”两个核心问题。会议需要整个团队（产品负责人、Scrum主管、开发团队）协作参与，最终产出明确的冲刺目标和可执行的冲刺待办事项列表，为冲刺的成功执行奠定坚实基础。理解并开好冲刺规划会议，是确保团队高效交付价值的关键一步。

016：更多关于冲刺会议的内容

在本节课中，我们将学习产品待办事项列表和冲刺待办事项列表的具体构成与区别。我们将通过示例来理解这两个核心敏捷工件，并了解它们在冲刺规划会议中的作用。

产品待办事项列表示例

上一节我们介绍了冲刺会议的基本流程，本节中我们来看看支撑这些会议的核心工件。首先，我们来看一个产品待办事项列表的示例。

如图所示，这是一个非常简单的列表。列表中的条目就是进入待办事项列表的用户故事。

列表基于条目如何被添加或收到新反馈的方式设置了不同的列。

以下是一个示例产品待办事项列表所包含的内容：

  • 列出没有父故事的任务。
  • 指明跟踪器类型。
  • 下载简化的路线图报告。
  • 显示高优先级关闭项或子任务。

这里展示的是一种示例产品待办事项列表，供参与者参考。

理解冲刺待办事项列表

了解了产品级的规划列表后，接下来我们聚焦于一次冲刺周期内的具体计划。现在让我们来理解冲刺待办事项列表。

冲刺待办事项列表是为本次冲刺所选出的产品待办事项列表条目的集合，外加一份交付产品增量并实现冲刺目标的计划。

冲刺待办事项列表是开发团队对下一次增量中将包含哪些功能、以及交付这些功能所需工作的预测。

本节课中我们一起学习了产品待办事项列表与冲刺待办事项列表。产品待办事项列表是产品所有需求的动态清单，而冲刺待办事项列表是从中选取的、计划在本次冲刺内完成的具体任务集合，它包含了实现冲刺目标的详细工作计划。理解这两个列表的区别与联系，是有效进行冲刺规划的基础。

敏捷实践：P17：增量与完成的定义 📈

在本节课中，我们将要学习Scrum框架中的两个核心概念：增量 和 完成的定义。理解这两个概念对于确保团队交付高质量、可用的产品至关重要。

理解增量

上一节我们介绍了Scrum的基本框架，本节中我们来看看其中一个重要的产出物：增量。

增量是在一个Sprint期间完成的所有产品待办事项项的总和，再加上之前所有Sprint中完成的增量。在Sprint结束时，新的增量必须是“完成的”。

这意味着它必须处于可用状态，并且符合Scrum团队对“完成”的定义。无论产品负责人是否决定实际发布它，增量本身都必须是可用的。因此，增量的重点是完成一部分产品待办列表，并在开发、测试和功能验收等所有方面都达到完成标准，使其成为潜在可交付给客户的产品。

完成的定义

理解了增量的概念后，我们需要明确什么才算是“完成”。从Scrum的角度来看，当描述一个产品待办事项项或一个增量“完成”时，团队中的每个人都必须理解“完成”的含义。

虽然这在不同团队间差异很大，但每个Scrum团队的成员必须对“工作完成”有一个共享的理解，以确保透明度。这个共享的理解就是 “完成的定义”。

完成的定义被Scrum团队用来评估产品增量上的工作何时完成。同一个定义也指导开发团队在Sprint计划会议中了解能选择多少产品待办事项项。每个Sprint的目的都是交付符合团队当前“完成的定义”的、具有潜在可发布功能的增量。

开发团队每个Sprint都交付一个产品功能增量。这个增量是可用的，因此产品负责人可以选择立即发布它。每个增量都是累加到所有先前增量之上的，并且经过测试，确保所有增量能协同工作。

随着Scrum团队的成熟，其“完成的定义”预计会扩展，包含更严格的标准以实现更高质量。

“完成的定义”的前提是，每个人都必须理解“完成”时所处的状态。因此，对于进行中工作的完成度，应该有一个一致的看法。它在团队内部应被一致理解，尽管不同团队之间可能不同。

“完成的定义”也指导团队在Sprint计划会议中了解能选择多少工作项，目的是在每个Sprint结束时，交付可以交付给客户的、具有潜在可靠功能的增量。此外，“完成的定义”在项目过程中可能会发生变化。

以下是“完成的定义”通常包含的一些检查项示例：

  • 代码已编写并通过同行评审。
  • 代码已合并到主分支。
  • 单元测试和集成测试已通过。
  • 功能已通过验收测试。
  • 用户文档已更新。
  • 产品负责人已确认功能符合要求。

增量的类型

根据其用途，增量主要可以分为两种类型：

  • 开发增量：主要用于内部开发、集成和测试，是构建最终产品的基础。
  • 演示增量：具备足够完整的功能，可以展示给利益相关者（如产品负责人、客户）以获取反馈。

总结与Scrum的完整性

本节课中我们一起学习了Scrum中的增量和完成的定义。增量是可用的、潜在可发布的工作总和，而“完成的定义”是团队对工作完成标准的共同协议，确保透明度和质量。

最后需要强调的是，Scrum的规则是不可变的。虽然只实施Scrum的部分内容是可能的，但结果不再是Scrum。Scrum只作为一个完整的整体存在时才能良好运作，并作为容纳其他技术、方法和实践的容器。

Thank you。

018：用户故事入门 🧩

在本节课中，我们将学习敏捷项目管理中的核心概念——用户故事。我们将了解用户故事是什么、什么是史诗和主题、一个好的用户故事由哪些部分组成、如何编写用户故事，以及在敏捷项目中，各利益相关方在用户故事方面的角色与职责。

什么是用户故事？🤔

用户故事描述了对用户或系统/软件的购买者有价值的功能。用户故事由三个方面组成：

  1. 书面描述：用于规划和提醒的故事文字说明。
  2. 对话：用于充实故事细节的讨论。
  3. 测试：传达和记录细节，并可用于确定故事何时完成的验收标准。

因此，用户故事描述了对购买者或用户有价值的功能。它包含书面描述、用于充实细节的对话，以及用于确认完成的测试。

用户故事示例

  • 正确示例：
    • 用户可以搜索工作。
    • 公司可以发布新的职位空缺。
    • 用户可以限制谁可以查看她的简历。
  • 错误示例：
    1. 软件将用 C++ 编写。
      • 错误原因：用户需要给出需求或说明他们期望的功能或价值，而不是直接进入解决方案模式。
    2. 程序将通过连接池连接到数据库。
      • 错误原因：同上，用户没有给出需求，而是进入了解决方案模式。

用户故事不需要以传统的需求文档风格来扩充。它是客户与团队成员之间的一项协议，用于在迭代期间细化需求。它强调口头沟通而非书面沟通，并且其大小适合用于规划。它应尽可能简短，是一种沟通工具，而非文档。用户故事本身不是需求文档，需求需要通过讨论来捕获。

用户故事的通用流程 📋

项目的初始故事通常在故事编写研讨会中完成，但故事可以在项目期间的任何时间编写。在研讨会中，每个人尽可能多地集思广益，提出故事。有了初始的故事集后，开发人员会估算每个故事的规模。

为什么由客户编写故事？

客户团队（而非开发人员）编写用户故事主要有两个原因：

  1. 每个故事必须用业务语言（而非 C++ 或连接池等技术术语）编写，以便客户团队能对故事进行优先级排序，决定将其纳入迭代或发布。
  2. 客户团队拥有主要的产品愿景，最适合描述产品的行为。

为什么使用用户故事？✨

上一节我们介绍了用户故事的定义，本节我们来看看使用用户故事的优势。用户故事强调口头沟通而非书面沟通。它们对用户和开发人员都易于理解。用户故事的大小适合规划，适用于迭代开发。并且，用户故事鼓励推迟细化细节，直到你对真正需要的东西有了最好的理解。

用户故事的“3C”原则 🃏

现在，让我们深入了解用户故事的核心框架——“3C”原则。

1. 卡片 (Card)

用户故事通常写在一张 3x5 英寸的便签卡上。这张卡片可能会附有注释、估算等信息。因此，卡片上会简要记录需求，并可能有一些注释来进一步阐述需求，以及一些粗略的估算。

2. 对话 (Conversation)

用户故事背后的细节在于与产品负责人和客户的对话中浮现。当用户提出一个用户故事时，他/她只给出非常简要的需求描述。例如，一个用户故事描述可能是“公司可以发布新的职位空缺”。这只是项目团队获得的简短信息。随后，客户和项目团队会进行讨论，进一步细化这个用户故事。这个对话更多的是理解这个需求是什么、高层期望是什么、包含什么、排除什么、存在哪些依赖关系，以便这个用户故事可以被纳入迭代开发。

3. 确认 (Confirmation)

确认（即验收标准）用于确认故事被正确引用。这一点非常重要，因为在执行验收测试时，需要回溯到该需求所属的用户故事。最重要的标准之一就是回溯并检查最初的高层需求是否得到满足。

验收测试是验证故事是否按照客户团队预期的方式开发的过程。一旦迭代开始，开发人员开始编码，客户团队就开始指定测试。根据客户团队成员的技术熟练程度，这可能意味着从在故事卡背面编写测试到将测试放入自动化测试工具中的任何事情。对于技术性更强的任务，客户团队中应包含一名专注且熟练的测试人员。

测试应尽早编写，甚至在迭代开始前，如果你能大致猜测下一个迭代的内容。尽早编写测试非常有帮助，因为客户团队的更多假设和期望能更早地传达给开发人员。

例如：
假设你写了一个故事：“用户可以用信用卡支付她购物车中的商品。”然后你在故事卡背面写下这些简单的测试：

  • 使用 Visa、Mastercard 和 American Express 进行测试。
  • 使用 Diner‘s Club 进行测试（通过/失败）。
  • 使用 Visa 借记卡进行测试（通过/失败）。
  • 使用有效、无效和缺失的卡 ID 号（来自卡背面）进行测试。
  • 使用过期的卡进行测试。
  • 使用不同的购买金额进行测试，包括超过卡限额的金额。

通过这种方式，编写了验收测试，并根据原始的用户故事或需求获得了确认。

总结：记住“3C”——卡片、对话和确认。

如何编写用户故事 ✍️

关于用户故事，始终要记住：作为一个想要此功能的用户。需要提及用户想要什么，以及为什么需要它。如果用户或业务获得了该功能，会发生什么变化、会产生什么积极影响、业务会做什么、业务能期待什么好处。

因此，用户故事的三个要素是：

  • 作为 (As a) [用户角色]
  • 我想要 (I want) [功能]
  • 以便于 (So that) [价值/收益]

公式：作为 <用户角色>，我想要 <功能>，以便于 <价值/收益>。

总结 📚

本节课我们一起学习了敏捷项目管理中的用户故事。我们了解了用户故事的定义、组成部分和“3C”原则（卡片、对话、确认）。我们还探讨了为什么由客户编写故事、用户故事的优势以及标准的编写格式。理解并正确应用用户故事，是进行有效迭代规划和交付有价值产品功能的基础。在接下来的章节中，我们将继续探讨史诗、主题等更宏观的敏捷规划概念。

019：史诗与主题 🎯

在本节课中，我们将要学习敏捷开发中的两个重要概念：史诗和主题。我们将了解它们的定义、区别、类型以及如何拆分史诗，帮助你更好地组织和管理大型需求。

概述

上一节我们介绍了用户故事的基本概念。本节中，我们来看看当用户故事变得过于庞大时，我们如何处理。我们将重点探讨史诗和主题，它们是管理大型和复杂需求的关键工具。

什么是史诗？ 📖

史诗是一个大型的用户故事。它过于庞大，无法在单个迭代中实现。因此，它需要在某个时间点被分解成更小的用户故事。

传统上，一个用户故事是用户需求的简短描述。例如：

  • 用户能够搜索工作。
  • 公司能够发布新的职位空缺。
  • 用户能够限制谁可以查看她的简历。

这些都是简单的用户故事。但是，如果用户故事是“公司可以发布一个新职位”，那么这背后意味着公司需要拥有一个职位管理门户。这就构成了一个庞大的用户故事集合。我们可以说，这不再是一个简单的用户故事，而是一个史诗，因为它太大，无法在一个迭代中完成，需要被分解。

例如，“公司可以拥有一个职位门户”这个史诗可以被分解为：

  • 公司可以发布简历。
  • 公司可以搜索候选人。
  • 公司可以下载简历。
  • 公司可以筛选简历。

这些就是分解后的不同用户故事。这就是史诗如何被转化为多个用户故事的过程。

什么是主题？ 🧩

主题是一组相关的用户故事，这些故事可以组合在一起，作为一个单一实体进行估算或发布计划。

史诗构成大型故事，而主题构成相关故事的集合，可用于估算或发布计划。

回到职位门户的例子，“通过筛选简历”、“通过下载筛选简历”、“通过自动匹配工具筛选简历”这三个用户故事就形成了一个主题，即“访问简历并从中筛选出少数简历”。这三个故事都属于“公司拥有一个职位门户”这个史诗。

简而言之，史诗是一个大型故事，而主题是一组相关的用户故事，可以组合或作为一个单一实体进行估算或发布计划。

史诗与主题的关系 🔗

在某些情况下，一个大的史诗可能包含一个主题。然而，我们通常将史诗视为未来要添加的大型功能的占位符。而主题的作用是将一组相关的故事分组在一起。

学生有时会混淆史诗和主题。有时它们可能相等，但要理解，我们总是将史诗写为大型故事的占位符。从这个大型故事中，我们分解出具有集成功能的主题，这些主题可用于估算和发布计划。

此外，史诗通常来自自上而下的规划，而主题是在自下而上时创建的。

理解这个区别：史诗对应于自上而下。意思是，先识别一个大的用户故事，然后将其分解为主题，再进一步分解为用户故事。这种方法是：从一个更大的故事开始，分解为子功能，再进一步分解为功能。

而主题是在底层创建的。例如，在职位门户的例子中，“简历搜索”、“简历匹配”、“简历发布”这些可能成为在底层创建的主题。

主题和史诗之间没有预定义或固定的层级关系，但史诗通常处于顶端，而主题处于底层。史诗通常比主题大。但在某些情况下，一个主题可能包含多个史诗。

想象一种情况，一个主题可能包含多个史诗。以职位门户为例，如果你有一个“简历处理”主题，那么“下载简历”、“匹配简历”、“索引简历”是其中的三件事。而在这三者中，“简历处理”本身也可以成为一个史诗，成为一个更大的故事。

因此，方法是灵活的，但基本原则是明确的：史诗是一个占位符，是一个更大的故事；主题在底层，包含集成的用户故事，可用于估算和发布计划。

史诗的类型 🧱

现在让我们也了解一下史诗的类型。广义上讲，史诗有两种类型：复合型故事和复杂型故事。

在复合型故事中，一个史诗由多个较短的故事组成。它是一个由大量较短用户故事复合而成的整体。例如我们举过的例子：“拥有一个职位门户”是一个史诗，而较短的用户故事是“简历发布”、“简历搜索”、“简历下载”、“简历匹配”等。

复杂型故事本质上是庞大的，并且不容易被分解。例如，“处理简历”可能是一个复杂的故事，它无法被进一步分解。

所以，复合型故事，你可以分离出组成部分1、2、3；但在复杂型故事中，你无法真正分离其组成部分，也无法进行分解。

记住有两种类型的史诗：复合型故事，由多个短故事组成；复杂型故事，本质庞大且无法分解。

如何拆分复合型史诗 ✂️

现在让我们了解如何拆分复合型史诗。

正如我们所看到的，复合型史诗由多个较短的故事组成。

以下是拆分复合型故事的几种方式：

  1. 按数据边界拆分：这主要是沿着故事所支持的数据边界进行拆分。
  2. 按操作边界拆分：这是第二种拆分类型，基于故事内执行的操作进行拆分。例如，如果你有一个“搜索工作”的用户故事，你可以按操作拆分：在互联网上搜索、通过分类广告搜索、按地点搜索、按职位名称搜索、按薪资搜索。
  3. 移除横切关注点：这是关于创建两个版本的故事，一个支持横切关注点，另一个不支持。
  4. 不满足性能约束：这将功能性和非功能性方面分开。当你有一个软件需求时，功能性需求是软件应该做什么（例如，搜索引擎应该快速、准确，给出最可能的结果），而非功能性需求涉及可靠性、可维护性、可用性等。因此，与功能相关的用户故事归为一类，与非功能相关的用户需求归为另一类。你可以通过这种方式拆分复合型故事。
  5. 按混合优先级拆分故事：如果较小的故事具有不同的优先级，则将其拆分为更小的故事。你可以根据“必须拥有”、“最好拥有”等来拆分故事，并相应地分配优先级。然后，优先开发“必须拥有”的用户故事，一旦完成这些必须的需求，再处理“最好拥有”的需求。这样，你就可以根据混合优先级对故事进行优先排序。

总结

本节课中，我们一起学习了敏捷开发中的史诗与主题。我们明确了史诗是过于庞大、需要分解的大型用户故事，而主题则是用于估算和发布计划的相关用户故事集合。我们探讨了两者的关系、史诗的两种类型（复合型与复杂型），并重点介绍了拆分复合型史诗的五种实用方法。掌握这些概念有助于更好地管理和规划大型、复杂的项目需求。

020：史诗与主题 🎯

在本节课中，我们将学习如何拆分复杂的故事，并了解构成一个好用户故事的标准。我们将通过具体示例和核心原则，帮助你掌握评估和优化用户故事的技巧。

拆分复杂故事的方法 🔍

上一节我们介绍了史诗与主题的概念，本节中我们来看看如何将复杂的故事拆分为更小、更易管理的部分。

根据定义，复杂故事无法直接聚合为更小的故事，因为其中的各个部分相互关联。因此，我们需要特定的方法来处理。

以下是拆分复杂故事的两种主要方法：

  • 通过调研拆分：此方法涉及研究和确定可行性。你可以设定一个时间盒（Time-boxed Spike）来探索解决方案。通过深入调研，你可以明确实现路径，从而将复杂故事分解。
  • 通过开发拆分：此方法涉及为产品的用户故事添加功能。例如，对于一个“自动化功能”的复杂故事，你可以先选取其中一小部分进行开发，通过一系列的增量开发来逐步拆分整个故事。

总而言之，一个复合型故事可以通过以下几种边界进行拆分：

  1. 数据边界
  2. 操作边界
  3. 横切关注点
  4. 性能约束
  5. 混合优先级

而一个复杂故事则可以通过调研和开发这两种途径来拆分。

什么是好的用户故事？ ✅

理解了如何拆分故事后，我们接下来需要判断一个用户故事本身是否“好”。一个好的用户故事是有效规划和开发的基础。

我们将通过一系列示例来直观感受。请判断以下用户故事是好是坏，并思考原因：

  1. 用户可以在Windows XP和Linux系统上运行该软件。
    • 答案：好故事。 它明确了用户价值（跨平台使用）和验收条件。
  2. 所有图表绘制将使用第三方库完成。
    • 答案：不是好故事。 用户不关心技术实现细节，只关心“能否绘制出所需的图表”这一结果。
  3. 用户可以撤销最多50个操作命令。
    • 答案：好故事。 它描述了具体的、对用户有价值的功能。
  4. 软件将在6月30日前发布。
    • 答案：不是好故事。 这是一个项目约束或目标，应在发布规划中考虑，而非作为一个功能故事。
  5. 软件将使用Java语言编写。
    • 答案：通常不是好故事。 除非产品是面向Java程序员的类库，否则用户不关心实现语言。这属于技术决策。
  6. 用户可以从下拉列表中选择其国家。
    • 答案：好故事。 它清晰描述了用户需要完成的一个具体操作。
  7. 系统将使用Log4J将所有错误信息记录到文件中。
    • 答案：不是好故事。 与示例2类似，它过度指定了技术方案，而非关注“系统需要记录错误信息”这一用户或业务需求。
  8. 如果用户超过15分钟未保存工作，系统将提示其保存。
    • 答案：好故事。 它描述了系统应有的、对用户友好的行为。
  9. 用户可以选择“导出到Excel”功能。
    • 答案：好故事。 它陈述了一个明确的用户需求。
  10. 用户可以将数据导出为XML格式。
    • 答案：好故事。 它定义了一个具体的、可验收的功能点。

好用户故事的六大特征 📋

通过以上示例，我们获得了一些感性认识。敏捷实践为我们提供了更系统的评估标准，即好用户故事的六大特征（INVEST原则）：

以下是构成一个好用户故事的六个关键特征：

  • 独立的：故事应尽可能独立，避免与其他故事产生依赖。依赖关系会导致优先级排序和计划制定变得困难，也会让估算更复杂。
    • 示例：假设有三个关于支付的故事：“用户可以用Visa卡支付”、“用户可以用Mastercard支付”、“用户可以用American Express支付”。这三个故事高度依赖相同的底层支付接口。
    • 解决方法：
      1. 合并：将它们合并为一个更大的独立故事，如“用户可以用信用卡支付”。
      2. 重新拆分：按不同维度拆分，例如“用户可以用一种信用卡支付”和“用户可以用另外两种信用卡支付”。
      3. 双重估算：如果必须保留依赖，可以为卡片标注两个估算值：一个是在依赖故事完成前的估算（较高），一个是在之后的估算（较低）。
  • 可协商的：用户故事的细节应该是可以讨论的，它不是一份不可更改的合同。故事卡是对话的起点。
  • 有价值的：每个故事都必须对用户或客户体现明确的价值。它应该回答“为什么需要这个功能？”的问题。
  • 可估算的：开发团队应该能够估算完成该故事所需的工作量。如果故事太大或太模糊而无法估算，就需要进一步拆分或澄清。
  • 小的：故事应该足够小，以便在一个迭代（Sprint）内完成。通常团队会设定一个故事点的上限。
  • 可测试的：故事必须有清晰的验收标准，以便判断其是否完成。一个不可测试的故事意味着需求不明确。

独立性尤为重要，因为依赖故事会带来估算和执行上的问题。用户故事作为一个可度量的开发单元，应尽量保持独立。如果存在依赖，就必须考虑上述的合并或拆分策略。

本节课中我们一起学习了如何拆分复杂的故事，并通过INVEST原则深入了解了优秀用户故事应具备的六大特征：独立、可协商、有价值、可估算、小型化和可测试。掌握这些标准，将帮助你编写出更清晰、更易于管理和交付的用户故事，从而提升敏捷开发的效率。

021：什么是优质用户故事 📝

在本节课中，我们将学习优质用户故事应具备的五个核心特征。理解这些特征有助于我们编写出对团队和客户都有价值的用户故事，从而更有效地进行敏捷开发。

特征二：可协商性 🤝

上一节我们介绍了用户故事的第一个特征。本节中，我们来看看第二个特征：可协商性。

用户故事是可协商的，它们不是必须严格执行的书面合同或硬性需求。这意味着故事可以与客户和项目团队进行讨论。

以下是可协商性的具体体现：

  • 并非故事卡上的每一项都必须进入开发阶段。
  • 基于讨论，某些项目可能被舍弃。
  • 基于讨论，可能会增加某些额外功能。

因此，优质的用户故事是一个可以实现双赢的关键要素。故事卡是对功能的简短描述，其细节需要在客户与开发团队的对话中进行协商。因为故事卡是发起对话的提示，而非详尽的需求文档，所以它无需包含所有相关细节。

让我们来看一个例子：用户提出“我想要一个搜索功能”。这是一个非常高层级的用户故事描述。

但当客户和项目团队进行面对面协作讨论时，用户故事会被细化：软件将具备基于关键词或字母数字索引的搜索功能，它能搜索互联网、内网和企业资源，并且搜索结果会有一个0到5分的排名。这就是客户与项目开发团队通过协商，使故事需求得到增强的过程。

特征三：对用户或客户有价值 💎

现在，让我们理解优质用户故事的第三个特征：对用户或客户有价值。

故事必须被用户所重视。但严格地说“每个故事都必须被用户重视”是不准确的。许多项目包含的故事并不直接为用户所重视。这里需要区分用户（软件的使用者）和购买者（软件的采购者）。

假设一个开发团队正在构建一款软件，它将被部署在一家拥有5000台电脑的大公司。对于这样的产品，购买者可能非常关心所有5000台电脑是否使用相同的软件配置。这可能导致一个故事的产生：“所有配置信息都从中央位置读取”。

用户可能不关心配置信息是如何获取的，但购买者会关心。因此，用户故事应该带来最重要的价值，关注那些比其他无关紧要的事情更重要的方面。

特征四：可估算性 📏

优质用户故事的第四个特征是可估算性。

开发人员应该能够估算用户故事。这对于确定优先级、纳入版本发布计划以及让客户和项目团队理解交付该故事所需的工作量都至关重要。开发人员需要能够估算，或至少猜测故事的规模或将其转化为可运行代码所需的时间。

故事无法被估算通常有三个常见原因：

  1. 开发人员缺乏领域知识。
  2. 开发人员缺乏技术知识。
  3. 故事太长或太大。

对于过于庞大而无法可靠估算的故事，有时可以将其写成史诗，例如“求职者可以找到工作”。史诗可以作为占位符或提醒，代表系统中需要讨论的大型部分。如果你决定暂时忽略系统的某些大型部分，可以考虑编写一两个史诗来覆盖它们，并可以为其分配一个粗略的估算值。

特征五：规模适中 ⚖️

优质用户故事的第五个特征是规模适中。

过大或过小的故事都无法用于有效规划。有些故事可能太大，有些可能太小，有些则刚刚好。故事规模之所以重要，是因为如果故事太大或太小，你就无法在规划中使用它们。判断一个故事规模是否合适，最好基于团队的能力、知识以及所使用的技术。

拆分故事

史诗通常分为两类：复合型故事和复杂型故事。

  • 复合型故事：通常有多种方式进行拆分。常见的拆分方式是按“增、删、改、查”这样的操作边界进行。如果故事足够小，也可以保留为一个故事。另一种方法是沿数据边界进行拆分，例如将简历的每个组成部分视为可单独添加和编辑的项。
  • 复杂型故事：本质上是大型故事，不容易分解为一组组成部分故事。如果故事因为存在不确定性而变得复杂，你可能希望将其拆分为两个故事：一个用于“调研”，一个用于“开发”新功能。

例如，假设开发人员拿到一个故事：“公司可以用信用卡支付职位发布费用”，但团队中没有人有信用卡处理经验。他们可以选择这样拆分故事：

  1. 调研基于网络的信用卡处理。
  2. 用户可以用信用卡支付。

合并故事

有些故事太小。一个过小的故事通常是指开发人员认为为其编写卡片或进行估算所花的时间，可能比实际实现这个改动还要长。漏洞报告、用户界面更改通常是这类过小故事的常见例子。

处理微小故事的一个好方法（在极限编程团队中很常见）是将它们合并成更大的故事，使其工作量大约在半天到几天之间。合并后的故事会被赋予一个名称，然后像其他任何故事一样进行计划和开发。

例如，假设一个项目有五个更改某些屏幕颜色的请求，开发人员估算出所涉及的总工作量，然后将整个集合视为一个单一的故事来处理。如果你选择使用纸质便签卡，可以通过用一张封面卡将它们钉在一起来实现这一点。

所以，故事可能太小、太大或规模适中。对于过大的故事，你可以拆分它们；对于过小的故事，你可以合并它们，努力使故事的规模恰到好处，以便你能够估算、计划、开发和发布这些故事。

本节课中，我们一起学习了优质用户故事的五个核心特征：可协商性、有价值、可估算性和规模适中。掌握这些特征，并灵活运用拆分与合并的技巧，将帮助你创建出更清晰、更实用、更能驱动项目成功的用户故事。

022：优秀用户故事的特征解析 📝

在本节课中，我们将深入探讨优秀用户故事的核心特征，特别是其“可测试性”和“完整性”。理解这些特征有助于我们编写出清晰、有效且便于团队执行的用户故事。

上一节我们介绍了用户故事应具备的六个特征，本节中我们重点来看看“可测试性”这一关键特征。

可测试性 ✅

优秀用户故事的第六个特征是可测试性。用户故事必须以可被测试的方式编写。成功通过测试证明该故事已开发完成。如果故事无法被测试，开发者如何知道编码工作何时结束？

不可测试的故事通常出现在非功能性需求中。非功能性需求是关于软件本身，而非其直接功能的要求。

例如，考虑以下非功能性故事：

  • 用户觉得软件易于使用。
  • 用户绝不需要长时间等待任何屏幕加载。

按此写法，这些故事是不可测试的。只要可能，测试应实现自动化。这意味着应追求99%的自动化率，而非10%。你几乎总能实现比想象中更多的自动化。

当产品以增量方式开发时，情况可能瞬息万变，昨天还能工作的代码今天可能就失效了。你需要自动化测试来尽早发现此类问题。

只有极少数测试无法实际实现自动化。例如，一个用户故事写道：“无经验的用户无需培训即可完成常见工作流程。”这个故事可以被测试，但无法自动化。测试此类故事可能需要人因专家设计包含观察环节的测试，并选取有代表性的无经验用户作为随机样本。这类测试可能耗时且昂贵，但故事本身是可测试的，并且可能适用于某些产品。

而“用户绝不需要长时间等待任何屏幕加载”这个故事是不可测试的，因为它使用了“绝不”这个词，并且没有定义“长时间”的具体含义。证明某事“绝不”发生是不可能的。一个更简单、更合理的目标是证明某事“极少”发生。这个故事可以改写为：“新屏幕在95%的情况下在2秒内加载完成。”这样，甚至可以编写一个自动化测试来验证它。

另一个例子：“用户可以创建和修改自动化职位搜索代理。”用户应能创建自动化搜索代理，也应能修改此类代理。因此，可测试性以及对需求的验证和确认，是优秀用户故事非常重要的一个方面。

所以，让我们重复一遍，优秀用户故事的六个特征是：独立的、可协商的、有价值的、可估算的、小的、可测试的。

完整的故事 🎯

一个优秀的故事通常也是一个完整的故事。那么，什么是完整的故事呢？

Soren Lauesen在2002年在其需求技术纲要中提出了任务完整性的概念，这一思想同样适用于用户故事。一个完整的故事是指，其完成意味着实现了一个有意义的目标，并让用户感到自己完成了一些事情。

例如，假设“大富翁招聘网站”项目包含这样一个故事：“招聘人员可以管理她已发布的广告。”这不是一个好故事。管理已发布的广告是一项永远不会完全结束的持续性活动。相反，它可以被更好地构建为一组完整的故事。

以下是该故事可能分解出的完整子故事示例：

  • 招聘人员可以查看她某一条广告的申请者简历。
  • 招聘人员可以修改某一条广告的截止日期。
  • 招聘人员可以删除与职位不匹配的申请。

以上每一个完整的故事都是原故事（不完整）的一部分。在完成其中一个完整故事后，用户很可能获得一种成就感。

编写完整故事的愿望需要与竞争性需求相权衡。请记住，故事还需要足够小以便估算，并且能方便地安排进单个迭代周期。但同时，故事必须足够大，以避免过早地捕捉不必要的细节。

本节课总结

本节课中，我们一起学习了优秀用户故事的两个重要特征：可测试性与完整性。我们了解到，可测试的故事是确保开发质量与进度的基础，而完整的故事则能带给用户明确的完成感和价值。结合之前学习的独立性、可协商性、有价值、可估算和足够小等特征，我们便能构建出真正高效、实用的用户故事，从而驱动敏捷项目的成功。

023：深入探讨优秀用户故事的定义 📝

在本节课中，我们将学习如何定义和编写一个优秀的用户故事。用户故事是敏捷开发中表达需求的核心工具，一个优秀的故事能确保团队始终关注用户价值，并高效地交付软件。我们将从六个关键方面来剖析优秀用户故事的特征。

1. 包含用户角色 👤

优秀用户故事的第二个方面是包含明确的用户角色。

如果项目团队已经识别了用户角色，就应该在编写故事时利用它们。例如，与其写“用户可以发布她的简历”，不如写成“求职者可以发布她的简历”。这种差异看似微小，但以这种方式编写故事能让开发者始终将用户置于思考的中心。

开发者将不再面对一个空白的、可互换的用户列表，而是开始思考软件需要满足的、真实而具体的用户。

康泰克斯特拉公司是极限编程的早期采用者之一，他们使用一个简短的模板来编写故事。每个故事都遵循以下格式：

我作为 <角色>， 想要 <功能>， 以便 <业务价值>

你可以尝试使用这个模板或创建自己的模板。这样的模板有助于区分重要的需求与琐碎的需求。

因此，始终将角色融入用户故事中，这样开发者就会始终考虑具体的用户，并交付高质量的软件。

2. 为单一用户编写 ✍️

优秀用户故事的第三个方面是为单一用户编写。

故事在针对单一用户时通常最易读。对于许多故事而言，为单个或多个用户编写并无区别。然而，对于某些故事，这种区别可能非常显著。

例如，考虑故事“求职者可以从网站上删除简历”。这可能被解读为“一个求职者可以删除她自己的简历”，也可能被理解为“可以删除他人的简历”。

因此，始终使用主动语态编写故事。主动语态的故事更易于阅读和理解。例如，与其说“简历可以被求职者发布”，不如说“求职者可以发布简历”。

3. 进行估算三角测量 📐

在完成最初几个估算后，就可以进行估算的三角测量。

三角测量估算指的是根据一个故事与一个或多个其他故事的关系来估算其规模。假设一个故事被估算为4个故事点，第二个故事被估算为2个故事点。当同时考虑这两个故事时，程序员应认同4点故事的大小大约是2点故事的两倍。

然后，当他们估算一个故事为3点时，他们应认同它大致比2点故事大，但比4点故事小。

4. 不过度关注用户界面 🖥️

优秀用户故事的第五个方面是不过度关注用户界面。

用户界面对于软件开发非常重要，因为它提供了访问途径、差异化的用户体验以及使用的便捷性。然而，如果过度关注UI，创造价值的焦点就会偏移。

因此，焦点不应过多地放在UI上，而应放在软件带来的价值上。

用户故事是一种非常灵活的格式，适用于描述许多系统的大部分功能，但它并非适用于所有情况。如果你需要用用户故事的形式表达某些需求，那就这样做。例如，用户界面指南通常用包含大量屏幕截图的文档来描述。同样，除了用户故事，你可能还需要记录并商定重要系统之间的接口，特别是当其中一个由外部供应商开发时。

如果你发现系统的某些方面可以通过其他格式更好地探索，那就使用那种格式。使用能提高效率的格式。

5. 包含验收测试 ✅

优秀用户故事的最后一个方面是包含验收测试。

验收测试带来了完成一个优秀用户故事所必需的标准。如果你满足了这些标准，就可以成功地说用户故事已完成。

验收测试是验证故事的过程。我们开发的每个功能都应完全按照客户团队的预期方式工作。

一旦迭代开始，开发者开始编码，客户团队就开始指定测试。根据客户团队成员的技术熟练程度，这可能意味着从在故事卡背面写下测试，到将测试放入自动化测试工具中。

对于这项任务中技术性更强的部分，客户团队中应包含一名专注且熟练的测试人员。

6. 尽早编写测试 ⏱️

测试应尽可能在迭代早期编写，甚至可以在迭代开始前稍早一点进行，如果你能大致了解下一个迭代将包含什么内容。

尽早编写测试极其有用，因为客户团队的更多假设和期望能更早地传达给开发者。

例如，假设你编写了故事“用户可以用信用卡支付她购物车中的商品”。然后你在故事卡背面写下简单的测试：用Visa卡、万事达卡和美国运通卡测试。测试大莱俱乐部卡。测试过期卡。测试不同的购买金额。

这就是验收测试如何让你确信它满足了大部分条件。

本节课中，我们一起学习了优秀用户故事的六个关键特征：包含用户角色、为单一用户编写、可进行估算三角测量、不过度关注UI、包含验收测试以及尽早编写测试。掌握这些要点，将帮助你编写出清晰、有价值且可执行的需求，从而推动敏捷团队交付高质量的软件产品。

024：如何撰写优质用户故事 📝

在本节课中，我们将要学习如何撰写优质的用户故事。用户故事是敏捷开发中表达需求的核心工具，它以用户为中心，描述用户希望系统为其完成什么功能。我们将从理解用户角色和用户画像开始，逐步介绍撰写用户故事的三步流程。

理解用户角色与用户画像 👥

上一节我们介绍了用户故事的基本概念，本节中我们来看看撰写用户故事的第一步：理解用户角色和用户画像。

用户角色和用户画像都是捕捉和传达用户基本理解的有效手段，但它们存在区别。

  • 用户画像 描述的是用户本身。它们是具象化的模型，旨在模拟真实的用户，甚至包括照片、背景信息和个人历史。这种拟真性有助于团队建立同理心，从用户视角思考问题。
  • 用户角色 描述的是用户与系统之间的关系。它们是抽象的模型，专注于那些与呈现和交互设计最相关的方面。用户角色是一个集合，它定义了代表一组用户及其与系统交互的属性。

角色建模步骤通常包含以下四步：

  1. 头脑风暴，列出初始的用户角色集合。
  2. 组织初始集合。
  3. 合并相似的角色。
  4. 精炼角色定义。

例如，一个用户角色可以是“培训师亚当”，他是一名资深职位专家，专攻律师事务所招聘。

创建用户画像 🎭

对于某些最重要的用户角色，值得更进一步，为其创建用户画像。用户画像是用户角色的虚构代表。

一个用户画像不仅仅是给用户角色加个名字。它需要被充分描述，让团队中的每个人都感觉认识这个人。例如，之前提到的“马里奥”（负责为公司发布新职位）可以被详细描述。

以下是创建用户画像时通常包含的信息：

  • 姓名与照片
  • 教育背景与工作经验
  • 喜好与厌恶
  • 人口统计信息

注意：用户画像不是真实用户的直接映射。在创建前，必须确保进行了足够的市场和人口研究，使所选画像能真正代表产品的目标受众。

一个扎实的用户画像定义，配上一张照片，能让团队对用户有透彻的了解。由于定义通常较长，建议写在纸上并张贴在团队的公共区域。你不需要为每个用户角色都创建画像，但可以为最关键的一两个主要角色创建。

从角色/画像到用户故事 📖

在识别了用户角色，并可能创建了一两个用户画像后，你就可以开始用具体的角色或画像名称来撰写用户故事，而不是使用泛指的“用户”。

使用角色或画像名称撰写故事，并不意味着其他角色不能执行这些功能，而是意味着在讨论或编码该故事时，思考特定用户角色或画像会带来益处。

例如，与其写：

用户可以将职位搜索限制在特定的地理区域。

不如写成：

地理搜索者可以将他的职位搜索限制在特定的地理区域。

这样写故事时，可能会让你想起正在毛伊岛找工作的艾伦，从而使故事更具表现力和上下文。

总结 ✨

本节课中我们一起学习了撰写优质用户故事的方法。我们首先区分了用户角色（抽象的关系模型）和用户画像（具象的用户代表），并介绍了创建它们的步骤。接着，我们了解到为关键角色创建详细的用户画像能增强团队的代入感。最后，我们实践了如何利用具体的角色或画像名称来撰写更生动、更具上下文意义的用户故事，从而更好地指导开发和设计。记住，核心在于始终从用户的角度出发，思考他们需要系统做什么。

025：如何撰写优质用户故事（续篇） 🧩

在本节课中，我们将继续学习撰写优质用户故事的两种高级技巧：极端角色法与故事撰写工作坊。我们将探讨如何运用这些方法来激发创意、收集需求，并确保讨论聚焦于核心价值。

理解极端角色法 🎭

上一节我们介绍了用户画像等基础方法，本节中我们来看看一种更具创意的技巧——极端角色法。这是一种在设计新系统时可以考虑的第二种技巧，它建议我们思考具有极端特征的用户。

极端角色法建议，不要只为典型的用户（例如一位衣着光鲜、驾驶宝马车的管理顾问）设计系统，而应考虑具有夸张个性的用户。作者以设计个人数字助理（PDA）为例，建议考虑为以下极端角色设计：

  • 一名毒贩。
  • 教皇。
  • 一位同时周旋于多位男友之间的20岁女性。

考虑极端角色很可能引导你发现那些原本可能被忽略的需求。例如，很容易想象，毒贩和那位有多位男友的女性可能都希望PDA能维护多个独立的日程表，以防设备被警察或某位男友看到。教皇可能对保密性需求较低，但可能希望字体更大。

然而，虽然极端角色法可能催生新的故事，但很难判断这些故事是否应该被纳入产品。因此，可能不值得投入大量时间，但你可以尝试使用极端角色法。至少，你可以花几分钟有趣地思考一下教皇会如何使用你的软件，这可能会带来一两个有价值的洞见。

核心概念：考虑极端角色 -> 可能发现隐藏需求 -> 需评估其产品价值

总而言之，考虑具有夸张个性的用户可能会引发出新的用户故事。

理解故事撰写工作坊 ✍️

既然用户故事会在项目中不断演变和更替，我们就需要一套轻量、可迭代使用的技巧来收集它们。一些最有价值的创作故事集的技巧包括用户访谈、问卷调查、观察和故事撰写工作坊。

让我们花些时间更深入地了解故事撰写工作坊。在故事撰写工作坊期间，重点应放在数量而非质量上。即使你最终会以电子方式保存故事，在工作坊期间也请使用卡片。让想法自然涌现并写下来。一个现在看起来糟糕的想法，可能在几周后显得很出色，或者它能启发另一个故事。

此外，你不希望陷入冗长的辩论或完善某个故事的细节中。如果一个故事是多余的，或者之后被更好的故事取代，你只需撕掉那张卡片即可。同样，当客户为版本排列故事优先级时，她可以将低质量的故事赋予低优先级。

有时，工作坊的某些参与者很难开始或突破某个瓶颈。在这种情况下，能够参考竞争产品或类似产品会非常有益。请注意工作坊中是谁在贡献想法。偶尔会有参与者在大部分或全部会议期间保持沉默。如果出现这种情况，请在休息时与该参与者交谈，确保她对流程感到舒适。有些参与者不愿在同事和上级面前发言，这就是为什么在会议期间不评判故事想法非常重要。一旦参与者确信他们的想法只会被记录下来，而不会在此时被争论，他们就会更愿意贡献。

最后，需要重申的是，用户故事工作坊期间的讨论应保持在非常高的层面。目标是在尽可能短的时间内写出许多用户故事。这不是设计界面或解决问题的时候。

以下是故事撰写工作坊的关键要点：

  • 参与者：包括开发者、用户、产品客户、产品负责人以及任何能做出贡献的人。
  • 时机：应在发布计划之前进行。
  • 工具：应使用卡片。
  • 讨论层级：保持在高层级，不试图设计界面或解决问题。

总结 📝

本节课中，我们一起学习了两种提升用户故事撰写质量的高级技巧。极端角色法通过考虑具有夸张特征的用户，帮助我们跳出思维定式，发现潜在需求。故事撰写工作坊则提供了一个高效、协作的环境，鼓励团队快速产生大量故事创意，并强调在初始阶段追求数量与广度，而非细节与深度。掌握这些方法，能让你的需求收集过程更具创造性和包容性。

026：职责与责任

在本节课中，我们将学习用户故事完成后，不同项目干系人（特别是客户和开发人员）所承担的职责与责任。我们将明确各方在用户故事识别、编写、测试和验收过程中的具体任务。

📝 线框图：快速原型与反馈工具

上一节我们介绍了用户故事编写工作坊，本节中我们来看看线框图。

线框图是一种原型吗？是的。它是一种低保真度的原型，是一种获取反馈的快速且低成本的方式。因此，一旦开发出线框图，就很容易获得反馈和用户输入，通过调整一些方框的位置、对齐方式并获得签字确认。

线框图更多地关乎信息展示。它规划了信息如何在页眉、页脚、列、功能区、菜单、子菜单以及下钻操作中显示。它列出了可用的功能列表、这些功能对应的权限，以及用户如何在软件中导航。

线框图还给出了信息的相对优先级。通过“相对”一词，意味着你将拥有层级式的下钻信息：首先在全局层面获得摘要，下钻后可以进入国家级视图，进一步下钻会进入州级，再下钻则会进入区级。这种分层级的相对信息展示是必要的，因为将所有信息显示在一个屏幕上是不可能的，否则用户的理解、分析和解读将面临挑战。

线框图也设定了展示特定信息类型的规则。例如，如果用户有一个选择菜单，那么相关的规则将被设定：如果用户选择输入A，输出应与A组相关；或者，如果用户给出某些输入，基于此会进行某些算术计算，并相应地显示结果。因此，线框图能够为展示特定类型的信息设定规则。

线框图还能展示不同场景对显示效果的影响。例如，如果存在参数设置，当用户设置某些参数时，线框图也能展示这些参数设置对最终输出的影响。

以下是一个基本线框图的示例：

  • 左上角可以看到公司或软件的标志。
  • 有一个购物篮项目。
  • 流程从登录/创建账户开始，然后进入主屏幕，依此类推。

你可以开发这样的线框图。它是一种快速有效的原型，通过它你可以获取需求、微调需求、设定条件、构建规则，并推进用户故事的编写。

至此，我们完成了关于用户故事的第四章内容。

👥 干系人的职责与责任

现在我们将理解他们在用户故事方面的责任。这里的“他们”指的是项目干系人。关于用户故事，他们各自有什么责任呢？

客户的责任

客户的责任是识别适当的角色。这里的“适当角色”指的是Scrum主管、产品负责人、开发人员、测试人员、业务用户等。

客户需要参与识别用户角色和人物角色的过程。如你所知，用户故事关乎用户角色和人物角色。而客户对用户角色和人物角色有很好的了解，因此客户在提供用户角色和人物角色输入方面的参与，对项目成功至关重要。

客户需要编写故事。每个客户都是业务用户，都有一些需求，因此他或她需要编写适用的故事。在编写故事时，要确保每个故事至少能关联到一个用户或人物角色。因此，编写用户故事并确保其附属于用户角色或人物角色，这种组合将为开发人员进行开发提供完整的图景。这对于有效的软件开发非常关键。

如果你在编写故事时需要帮助，你有责任安排和主持故事编写工作坊。因此，如果你遇到困难或需要帮助，最好的方法是设立一个故事编写工作坊，设定主题，列出需要编写的用户故事清单，获取关键干系人的输入，并逐一编写故事。

开发人员的责任

那么，开发人员在用户故事方面有什么责任呢？

首先，开发人员应参与识别用户角色和人物角色的过程。负责开发软件的开发人员应该帮助并参与其中，以便更好地理解用户角色和人物角色。这样，当他拿到用户故事时，就能通过编码有效地进行开发。

开发人员可以参与编写用户故事。对于非功能性需求或某些功能性需求，开发人员也可以编写用户故事；或者，当客户难以写出好的用户故事时，开发人员可以自己编写故事。

在早期的章节中，我们讨论过用户故事也需要验收测试。因此，你需要编写验收测试。要编写验收测试，你需要有一个用户故事，为每个用户故事编写一个验收测试。对于项目中的所有用户故事，你都需要为每个独立的故事准备验收测试。一旦你能对单个用户故事进行验收测试，你就可以编写称为SUT的系统测试，以整体测试系统。这样，你将为发布做好准备。

验收测试的职责划分

关于验收测试的编写，职责划分如下：客户负责编写验收测试。客户提供需求，因此他也需要给出需要满足的条件，以便用户故事的验收得以完成。编写的测试应尽可能为故事增加价值和清晰度。不仅要编写验收标准，还要编写具体的值。例如，如果你需要屏幕响应时间为2毫秒，容差为±0.1毫秒，那么你需要写明屏幕响应时间应在1.9毫秒到2.1毫秒之间。如果需要检查分贝值，你需要说明通过声级计检查分贝值。

因此，客户编写了用户故事，客户编写了验收测试，开发人员完成了开发。现在是客户执行验收测试的时候了。通过进行验收测试，用户将第一时间提供信息和反馈，说明开发是否符合预期，是否满足验收测试概述的质量要求。

所以，开发人员在验收测试中也扮演着重要角色。开发人员负责在可能和需要的情况下，自动化执行验收测试。正如我们所理解的，敏捷原则之一就是自动化测试。因此，对于从客户那里收到的验收需求，开发人员应该将其自动化。例如，Fitnesse、TestComplete是自动化工具之一，市场上还有很多专业的测试自动化工具，如IBM Rational等。

开发人员还负责考虑额外的验收测试。如果开发人员认为有更多需要测试的内容，而客户提供的验收测试覆盖不足，他可以全面地填补空白，编写额外的标准以使验收测试更全面。

开发人员负责对代码进行单元测试，这样就不需要为故事的每一个微小细节都指定验收测试。因此，在客户进行验收测试之前，开发人员会进行单元测试，以便修复一些微小的缺陷。真正由客户识别的缺陷，是那些在开发代码中仍然存在的缺陷；否则，大多数缺陷都由开发人员自己识别和修复了。

📚 总结

本节课中，我们一起学习了用户故事完成后各方职责的划分。我们明确了客户在识别角色、编写故事和验收测试中的核心作用，以及开发人员在理解需求、协助编写、实施自动化测试和进行单元测试中的关键责任。理解并履行这些职责，是确保用户故事被正确理解、开发和验收，从而推动敏捷项目成功的重要基础。

027：估算导论 🎯

在本节课中，我们将学习敏捷项目管理中的估算。我们将探讨什么是估算、为什么需要估算，以及如何在敏捷项目中估算规模、工作量和持续时间。课程将介绍“不确定性锥”的概念，并解释估算如何随着项目进展而变得更加精确。

什么是估算？🤔

上一节我们介绍了本章的主题，本节中我们来看看估算的基本定义。

估算是对项目将花费多长时间或多少成本的预测。它是一种预测，用于决定是否启动项目、了解项目所需资源（主要是人力资源、时间和成本），以及在项目进行中，对照估算来评估实际进展。

估算是对一项活动或产品的数值近似。在敏捷项目中，我们通过用户故事获取需求，并估算所有用户故事所需的工作量。我们还会估算测试、部署和发布所需的工作量。通过自下而上、自上而下、专家意见或类比等方法汇总这些估算，我们就能得出项目的总持续时间。估算可以在活动或流程层面进行，具体取决于项目经理希望分解的详细程度。也可以对产品本身进行估算。

牛津词典将估算定义为“近似的判断”。因此，估算本身是近似的，其准确度也因估算阶段和估算类型而异。例如，粗略估算非常模糊，数量级估算范围较大，而专家判断或确定性估算则较为准确，可能在实际成本或时间的-10%到+5%之间浮动。请记住，预测不是占星术，而是基于特定事实、数据和统计的。敏捷项目经理管理估算，使其尽可能接近实际结果。估算的接近程度是项目经理的成功因素之一。如果偏差过大（即需要额外的时间、成本或资源），项目经理就必须与利益相关者、发起人和客户沟通，这反过来会给项目经理带来负面印象。

总而言之，估算是一种预测。我们对活动、流程或产品进行估算，并且需要准确或接近实际成本，这样在交付价值所花费的成本和时间方面就不会出现意外或冲击。

不确定性锥 📊

上一节我们定义了估算，本节中我们来看看影响估算精度的“不确定性锥”。

“不确定性锥”阐述了估算的可变性如何随时间变化。如图所示，在项目初期，对于项目范围、工作量、成本和功能存在高度的不确定性。随着你推进到产品定义阶段，不确定性会降低。进入详细需求阶段，不确定性进一步减少。当你进行用户界面设计和软件开发时，不确定性继续降低。最终，在测试和发布阶段，不确定性几乎变为零。

从逻辑上理解：当你开始处理产品范围、其工作量、成本和功能时，你对产品的了解很少，因此处于高度不确定性的阶段。当你获得产品定义时，你开始将事物纳入框架，明确包含和排除的内容。当你获得用户故事和详细需求时，你确切知道要做什么，但在集成、适配和发布方面仍存在一些不确定性。通过开发用户界面、设计软件、建立企业架构等步骤，你尽可能地消除了不确定性。因此，“不确定性锥”描绘了估算可变性随时间的变化：在项目上花费的时间越多，确定性就越高，不确定性则降低。

我们在敏捷项目中估算什么？📝

上一节我们了解了不确定性如何影响估算，本节中我们来看看在敏捷项目中具体估算哪些内容。

在敏捷项目中，我们主要估算三样东西：规模、工作量和持续时间。

  • 规模：指的是一个版本中包含多少用户故事，包含哪些功能。这构成了项目的“大小”。
  • 工作量：指的是构建、开发或编码这些用户故事，并进行测试和发布所需的人力投入。
  • 持续时间：指的是从项目开始到发布所需的时间。持续时间是通过获取需求、规划活动、为活动分配资源、为“资源-活动”组合分配时间，然后汇总得出的。你估算每个用户故事的持续时间，然后汇总所有用户故事及其所需时间，从而得出项目的总持续时间。

总结 📚

本节课中我们一起学习了敏捷项目管理中的估算基础。我们首先明确了估算是对项目时长或成本的预测，用于决策和追踪进展。接着，我们探讨了“不确定性锥”的概念，理解了项目初期的不确定性最高，并随着项目细节的明确而逐渐降低。最后，我们明确了在敏捷项目中需要估算的三个核心要素：规模（如用户故事数量）、工作量（所需的人力投入）和持续时间（项目总时长）。掌握这些基础概念是进行有效敏捷估算的第一步。

028：尺寸测量 📏

在本节课中，我们将要学习敏捷项目中如何测量工作的“尺寸”。我们将探讨传统方法与敏捷方法的区别，并重点理解故事点和理想人天这两个核心的尺寸度量单位。

概述

准确估计工作规模是项目规划的基础。传统上，我们通过代码行数、功能点或用例点来衡量软件规模。然而，在敏捷开发中，我们主要使用故事点和理想人天来评估用户故事或特性的规模。本节将详细介绍这两种方法及其应用。

传统尺寸测量方法

在深入敏捷方法之前，我们先回顾一下传统的尺寸测量方式。

传统上，测量软件规模时，通常使用代码行数。但并非所有代码行都能为软件增加价值，例如注释行、文件头尾和循环结构等。因此，除了代码行数，传统方法还会测量功能点，即代码中包含多少功能点；以及用例点，即开发和项目中包含多少用例点。这些是传统的估算方式。

敏捷尺寸测量方法

上一节我们介绍了传统方法，本节中我们来看看敏捷方法的核心度量单位。

在敏捷开发中，尺寸的主要度量单位是故事点和理想人天。

故事点

故事点是用于表达用户故事、特性或其他工作项整体规模的度量单位。

当我们使用故事点进行估算时，会为每个工作项分配一个点值。我们分配的具体数值本身并不重要，重要的是数值之间的相对关系。例如，一个被估值为2个故事点的故事，其工作量应该是估值为1个故事点的故事的两倍，同时也应该是估值为3个故事点的故事的三分之二。

以下是两种常见的初始估算方法：

  • 第一种方法：选择一个你预期会完成的、较小的工作项，并将其估值为1个故事点。
  • 第二种方法：选择一个看起来中等规模的工作项，并给它一个你预期使用范围内的数字（例如3或5）。

理想人天

在软件项目中，用理想时间来预测一个事件的持续时间，几乎总是比用实际流逝的时间更简单、更准确。

理想时间与实际流逝时间不同，并非因为超时、不完整的传递或“受伤”，而是因为我们每天都会经历的自然开销。在任何一天，除了处理项目计划内的活动，团队成员可能还需要花时间处理邮件、给供应商打支持电话、面试分析师职位的候选人以及参加多个会议。

理想时间不等于实际流逝时间的更多例子包括：支持当前版本、技能提升时间、会议、演示、个人事务、电话、特殊项目、培训、邮件审阅和走查、面试候选人、任务切换、修复当前版本的缺陷以及管理评审。

当经理问团队成员“这需要多长时间？”时，问题就可能出现。团队成员回答“五天”。经理于是在日历上数出五天并标记出来。然而，团队成员真正的意思是“如果我只做这一件事，需要五天。但我还有很多其他事要做，所以实际上可能需要两周。”此外，多任务处理也会扩大理想时间与实际流逝时间之间的差距。就像足球教练不会让球员同时去打一场高优先级的冰球比赛一样，被要求多任务处理的软件开发者在切换任务时会损失大量效率。

在估算软件项目时，我们可能会选择用理想人天来估算用户故事或其他工作。当使用理想人天估算时，你假设被估算的故事是你唯一要做的工作，开始时所需的一切都已就绪，并且不会有任何中断。

所以请记住，理想人天更多地关乎你的优先级：你是只做一件事还是同时处理多件事？开始工作时你是否拥有所有资源？工作中是否有任何中断或干扰？

理想人天作为规模度量

当我们估算一个用户故事所需的开发、测试和验收的理想人天数时，无需考虑团队工作环境开销的影响。例如，开发一个特定界面需要我1个理想人天。无论我是受雇于一个没有额外开销或时间要求的初创公司，还是一个庞大的官僚机构，这1个理想人天的工作量是不变的。

当然，在时钟或日历上实际流逝的时间会有所不同。在低开销的初创公司，我可能接近完成1个理想人天的工作。随着对我时间要求的增加，我能用于项目交付物的时间就减少了，完成1个理想人天工作所需的实际流逝时间就会增加。

当忽略组织开销的考虑时，理想人天可以被视为另一种规模估算，就像故事点一样。一个以理想人天数表达的规模估算，可以使用速率以与用户故事点完全相同的方式转换为持续时间估算。

因此，理想人天是指不考虑迭代周期、只做此项工作且所有资源可用的情况下，一个资源完成任务所需的时间。由于组织设置带来的各种开销会加在估算的理想时间之上，这就导致了实际流逝时间多于理想人天。

敏捷项目如何估算规模并推导工期

了解了核心概念后，我们来看一个具体的应用示例。

假设你需要为组织开发一个招聘门户，该项目总规模为 400个故事点。团队的速度是 每个冲刺完成20个故事点。

那么，所需的冲刺数量可以通过以下公式计算：

所需冲刺数 = 总规模 / 团队速度

代入数值：

所需冲刺数 = 400 / 20 = 20个冲刺

所以，完成这个项目大约需要20个冲刺。

总结

本节课中我们一起学习了敏捷项目中的尺寸测量。我们了解到，敏捷方法摒弃了传统的代码行数等度量，转而使用故事点来衡量工作的相对规模，以及使用理想人天来估算在理想条件下的纯工作时间。关键在于理解理想时间与实际日历时间的区别，并学会通过 规模 / 速度 = 所需冲刺数 这个基本公式，从规模估算推导出项目的大致工期。至此，我们完成了对估算的介绍。

029：深入理解理想日与规模估算

在本节中，我们将深入探讨“理想日”的概念，并学习如何对理想日进行规模估算。上一节我们介绍了“理想的一天”是什么，本节中我们来看看理想日的具体构成及其与“实际耗时”的区别。

什么是理想日？

理想日是指，当你100%专注于某项特定活动，且没有任何中断时，完成该活动所需的时间。这意味着：

  • 这是你唯一的工作任务。
  • 所有必要的工具、资源、设备和人力支持都已就绪。
  • 没有会议、电话、邮件或其他事务的干扰。

因此，理想日代表了一项任务可能的最短估计时间。

理想日与实际耗时

与理想日相对的是实际耗时。在实际工作中，你无法避免各种中断和资源限制，因此完成同一任务实际花费的时间总会超过理想日。

以下是构成实际耗时的主要部分：

  • 支持当前发布：包括文档编写、测试、确保用户采纳度、培训最终用户等。
  • 病假时间：因身体不适而无法工作的时间。
  • 会议与演示：包括每日站会、定期评审、客户咨询、电话会议。准备演示、进行演示以及根据反馈修改所花费的时间也属于此类。
  • 个人事务：例如处理银行交易、支付账单、接送机等。
  • 电话沟通：回答疑问、澄清问题、寻求信息等。
  • 特殊项目：参与组织战略倡议，如提供需求反馈、面试资源、确保项目治理合规等。
  • 培训：为适应新技术或新版本而进行的学习或授课。
  • 电子邮件：日常大量的邮件阅读、回复和报告分发。
  • 评审与走查：在敏捷项目中，包括每日评审、演示、周度回顾、审计以及代码走查等。
  • 面试候选人：为项目招募新成员。
  • 任务切换：由于多任务处理，根据优先级切换任务所消耗的时间。

核心概念总结

我们可以用以下公式来理解理想日与实际耗时的关系：

实际耗时 = 理想日 + 所有中断与等待时间

或者，更直观地通过代码逻辑表示：

def calculate_elapsed_time(ideal_days, interruptions):
    """
    计算实际耗时。
    ideal_days: 理想日估算。
    interruptions: 所有中断任务消耗的时间列表。
    """
    total_interruption_time = sum(interruptions)
    elapsed_time = ideal_days + total_interruption_time
    return elapsed_time # 返回值总是大于 ideal_days

本节课中，我们一起学习了理想日的精确定义，并详细分析了导致实际耗时远超理想日的各种因素。理解这两者的区别，对于做出更准确的项目时间估算至关重要。下一节，我们将探讨如何利用这些概念进行有效的任务规模估算。

030：什么是经过时间 ⏱️

在本节课中，我们将深入探讨敏捷估算中的两个核心概念：“理想天数”与“经过时间”。我们将学习它们的定义、区别、应用场景以及如何利用它们来优化项目管理和识别时间浪费。

理想天数的特性

上一节我们介绍了“理想天数”的基本概念，本节中我们来看看它的具体特性。

理想天数无法在不同成员间简单相加。因为理想天数高度个人化，它取决于个人的专业技能水平、教育背景、工作效率以及处理工作的方式。每个人利用时间创造项目价值或产出的方式、减少干扰和多任务处理的能力都不同。

理想天数更容易向团队外部人员解释。因为外部人员不了解项目环境的具体挑战、团队面临的管理开销以及需要遵守的合规审查流程。

理想天数在初始估算时更为容易。因为它只考虑纯粹的开发、测试或发布等工作所需的时间，无需纳入其他干扰因素。

理想天数可以促使公司正视时间浪费活动。当同时掌握了理想天数和实际经过时间的数据时，可以计算两者之间的比例。如果经过时间相对于理想天数的比例过高，则表明存在大量时间浪费，公司需要对此进行审视和优化。

在许多采用成熟软件的公司中，会追踪用于开发工作的“生产性时间”（接近理想时间）和用于其他活动的“非生产性时间”（经过时间的一部分）。在一个高效的公司里，理想时间通常不超过总经过时间的60%。

即使使用理想天数进行估算，最终也应将其视为工作规模的度量，而非直接的努力量。项目不可能在纯粹理想的时间或场景下交付。理想天数构成了估算的基础，然后需要根据项目的具体情况增加相应的管理开销，从而得出实际所需的努力量。

以下是理想天数关键特性的总结：

  • 个人化：基于个人能力，不可跨成员累加。
  • 对外解释性：易于向不熟悉项目细节的外部人员说明。
  • 易估性：初期估算更简单，仅包含核心工作时间。
  • 诊断性：通过对比“经过时间”，能揭示时间浪费。
  • 基础性：是估算工作规模的基础，需叠加开销以得到实际努力。

从理想天数到实际努力

理解了理想天数的特性后，我们来看看如何将其转化为实际的项目努力估算。

理想天数提供了在完美条件下完成工作所需时间的基准。然而，现实项目充满各种开销和干扰。因此，估算不能止步于理想天数。

实际所需的努力（Effort）需要通过以下公式在理想天数（Ideal Days）的基础上计算得出：

Effort = Ideal Days + Overheads

其中的“管理开销”（Overheads）需要根据多个项目因素进行调整，主要包括：

  • 项目的质量与精度标准：更高的标准需要更多的评审和返工时间。
  • 项目面临的风险水平：高风险可能需要更多的沟通、预案和问题处理时间。
  • 可用资源的状况：资源不足或技能不匹配会增加协作和等待时间。

通过系统性地评估并添加这些开销，团队才能从理想的“规模”估算，得到更贴近现实的“努力”估算，从而制定出可行的项目计划。

课程总结

本节课我们一起学习了敏捷估算中“理想天数”与“经过时间”的核心概念及其应用。

我们明确了“理想天数”是个体化、纯工作的理论时间，适用于初期估算和对外沟通；而“经过时间”是包含所有中断和开销的实际日历时间。两者之间的差距是识别和优化时间浪费的关键指标。最后，我们掌握了如何以理想天数为基础，通过叠加项目特定的管理开销，来计算出更准确的实际项目努力估算。

理解并善用这两个概念，能帮助团队做出更可靠的承诺，并持续改进工作流程，提升效率。

031：故事点估算 📊

在本节课中，我们将学习敏捷开发中一个核心的估算概念——故事点。我们将了解什么是故事点，它如何工作，以及几种实用的估算方法。

什么是故事点？

上一节我们介绍了用户故事的概念，本节中我们来看看如何衡量这些故事的“大小”。

故事点用于估算用户故事的相对规模。它关注的是相对思维，即一个故事相对于其他故事，在开发、测试、发布等环节所需的总工作量是多少。其核心是比较每个故事之间的相对“大小”。

故事点的“大小”受两个因素影响：任务的复杂度和任务的数量。重要的是，故事点是一个无单位的纯数字，它衡量的是规模本身。

故事点估算的优势

故事点估算有助于推动跨职能团队的协作行为。因为在进行故事点估算时，你需要综合考虑开发、测试、发布计划、适配等所有方面的努力。

这种估算方式不会因为任务的逐步细化或汇总而“衰减”或失效，故事点总数会持续累加，它是对规模纯粹的衡量。

此外，故事点估算通常更快。因为你使用的是相对规模估算，而不是传统的、耗时很长的自底向上估算。它是一种简单、易懂、快速且有效的估算方式。

团队可以自行定义故事点。团队是自我调节、自我管理的，他们定义自己的故事点和估算标准。由于最终是由团队来交付项目工作，因此他们的估算通常被认为更切合实际。

主要的估算方法

理解了故事点的概念后，我们来学习几种具体的估算技术。对于那些了解传统项目管理方法的人，会熟悉一种叫做“专家判断”的方法。


项目管理是艺术与科学的结合，涉及技术、人脑的敏锐性，有些任务几秒就能完成，有些则需要很长时间。以下是三种核心的估算方法：

  1. 专家判断
    当专家被问及某项工作需要多长时间时，他们的意见至关重要。那些在类似项目上有工作经验、具备专业知识的专家，他们的判断是估算的重要依据。

  2. 类比估算
    这种方法试图与历史数据关联，或与类似项目进行比较来得出估算。虽然没有单一标准，但可以基于经验进行推算。
    例如：如果上一个项目中开发一个接口需要10天，当前项目有10个类似接口，那么可以合理估算需要 10天 × 10个接口 = 100天 的工作量。同样，如果有100个测试脚本，每个脚本测试需要1小时，那么测试总时间可估算为100小时。

  3. 分解估算
    “分解”意味着将故事或特性拆分成更小的部分。
    例如，假设你要开发一款智能手机软件。你可以将开发工作分解为：基础电话系统、互联网功能、智能手机应用程序。然后，应用程序又可以进一步分解为游戏、银行应用等。
    通过将大型工作逐级分解为层次化的细小工作，你可以为每个最小的“原子”任务分配估算的时间和精力，然后将它们汇总起来，从而得到整个项目的估算。分解估算就是将大工作拆分成小部分，分别估算，再累加得到总估算。

非常关键的是要记住：专家判断、类比估算和分解估算是三种主要的估算方法。

总结

本节课中，我们一起学习了敏捷估算的核心工具——故事点。我们了解到故事点是一种衡量工作相对规模的无单位方法，它促进跨职能协作，并且估算高效。我们还掌握了三种实用的估算技术：依靠经验的专家判断、参考历史的类比估算，以及化整为零的分解估算。掌握这些方法，能帮助团队更准确、更快速地进行项目规划。

032：什么是估算 📊

在本节课中，我们将要学习敏捷项目中的估算方法。我们将探讨三种主要的估算方式，理解最适合的估算单位，并学习如何通过非线性序列和“史诗/主题”来处理不同粒度的需求。掌握这些技巧，可以帮助团队更准确、更高效地进行项目规划。

三种估算方法 🧠

上一节我们介绍了估算的重要性，本节中我们来看看具体的估算方法。主要有三种方式，它们根据可用时间、专家资源以及所需精度的不同而有所区别。

以下是三种核心的估算方法：

  • 专家意见：由经验丰富的团队成员基于个人知识和直觉进行估算。
  • 类比：将当前待估算的工作项与过去已完成、且规模已知的类似工作项进行比较。
  • 分解：将大型、复杂的工作项拆分成多个更小、更易于估算的部分，分别估算后再汇总。

选择合适的估算单位 📏

理解了基本方法后，我们需要知道如何量化估算值。研究表明，人类最擅长估算处于一个数量级范围内的事物。例如，你能较好地估计去最近超市、餐厅和图书馆的相对距离（图书馆可能比餐厅远一倍）。但如果让你估算到月球或邻国首都的距离，准确性就会大大降低。

因此，我们希望大多数估算值都能落在一个合理的数量级范围内。在实践中，有两种常用的非线性估算序列效果很好。

以下是两种推荐的估算标度序列：

  • 斐波那契序列：1, 2, 3, 5, 8, 13...。这个序列的间隔随着数字增大而适当扩大（例如，1到2的差是1，5到8的差是3），这反映了对更大工作项估算时存在的不确定性。
  • 2的幂次序列：1, 2, 4, 8...。这个序列中每个数字都是前一个数字的两倍（2 = 1*2, 4 = 2*2, 8 = 4*2）。

这两种非线性序列都很好用，我个人略微偏好第一种。关键在于，要预先定义好序列中使用的数字，避免使用像666或67这样看似精确但实际无法区分的值。我们无法辨别1.5%的差异。

处理大型工作项：史诗与主题 🗺️

虽然我们希望用户故事的估算规模在一个数量级内，但这并非总能实现。如果我们过早地将所有功能都拆分成精细的故事来估算，可能会在不确定是否要开发的功能上投入过多分析成本。

对于不确定是否近期会开发、或需要先进行粗略成本估算的大型功能，通常可以写成一个更大的用户故事，这被称为史诗。史诗的估算范围通常在20到100或200故事点以上。

此外，一组相关的用户故事（例如用回形针夹在一起）也可以被组合起来，作为一个整体进行估算或发布规划，这被称为主题。

通过将一些故事聚合为主题，并将一些故事写为史诗，团队可以减少在估算上花费的精力。但必须认识到，对史诗和主题的估算，其不确定性远大于对具体的、小型用户故事的估算。

实践指南：何时拆分，何时保留 🔧

那么，在实践中该如何应用呢？对于即将在近期或下一个迭代中开展工作的用户故事，它们需要足够小，以确保能在单个迭代内完成。这类条目应使用1, 2, 3, 5, 8这样的序列在一个数量级内进行估算。

对于那些可能距离实现还有好几个迭代的条目，则可以暂时保留为史诗或主题。为了估算这些更大的条目，可以在你偏好的序列（如1, 2, 3, 5, 8）基础上，增加13, 20, 40, 100等更大的单位。

本节课中我们一起学习了敏捷估算的核心知识。我们了解了三种估算方法（专家意见、类比、分解），认识到在一个数量级内进行估算最为准确，并掌握了使用非线性序列（如斐波那契数列）的技巧。最后，我们学会了通过“史诗”和“主题”来管理不同粒度的工作项，从而在估算精度和规划效率之间取得平衡。记住，估算的目的是为了更好的规划和沟通，而非追求虚假的精确。

敏捷实践：章节3.2.1：如何进行估算

在本节中，我们将学习如何对史诗（Epic）进行估算，并介绍一种将任务估算与故事点相关联的分析方法。

估算大型需求（史诗）时，直接评估其整体复杂度通常很困难。因此，一个有效的方法是将其分解为更小、更易于管理的用户故事。

以下是估算史诗的步骤：

首先，需要将大型的史诗级需求分解为多个独立的用户故事。每个用户故事应代表一个完整且有意义的功能点。

  • 分解示例：以一个用户故事“作为求职者，我应该能够搜索工作，以便找到合适的工作”为例。这是一个较大的需求（史诗），可以将其分解为三个子需求：
    • 子故事1：作为求职者，我应该能够使用关键词搜索，以便找到合适的工作。
    • 子故事2：作为求职者，我应该能够使用地点搜索，以便找到合适的工作。
    • 子故事3：作为求职者，我应该能够使用薪资范围搜索，以便找到合适的工作。

分解完成后，接下来需要对每一个较小的用户故事进行独立估算，通常使用故事点来评估其相对规模。

  • 独立估算：在初始估算中，上述三个子故事可能都被赋予了8个故事点。
  • 整体校准：在后续的校准过程中，团队可能会重新评估整个史诗（E）的总体工作量。例如，经过讨论，整个“搜索工作”史诗最终被估算为20个故事点，而不是简单相加的24点。这体现了估算的协商和调整过程。

关键点：务必记住，先对所有用户故事进行分解，然后再对单个用户故事进行估算。故事点的总和不一定等于史诗的最终估算值，团队校准至关重要。

上一节我们介绍了通过分解来估算史诗的方法。接下来，我们看看另一种更为分析性的估算方法：将任务估算与故事点相关联。

这种方法基于历史数据统计，通过分析不同故事点所对应任务的实际完成时间分布来进行估算。下图展示了这种关系：

图表说明如下：

  • Y轴：表示任务完成的概率。
  • X轴：表示任务所需的持续时间（小时）。
  • 估算逻辑：
    • 一个 1故事点 的任务，可能需要 0到24小时 完成，其平均时间（均值）约为 12小时。
    • 一个 2故事点 的任务，可能需要 12到36小时 完成，其平均时间约为 24小时。
    • 一个 3故事点 的任务，可能需要 24到60小时 完成，其平均时间约为 48小时。

在实际估算中，可以取这些平均时间（12小时、24小时、48小时）作为对应故事点的参考耗时。这是一种基于统计信息的分析工具，有助于建立工作量与故事点之间更量化的关系。

本节总结

本节课中，我们一起学习了两种主要的估算方法：

  1. 史诗估算：通过将大型史诗分解为较小的用户故事，分别估算后再进行整体校准，从而得出史诗的故事点。
  2. 分析估算：利用将任务估算与故事点相关联的统计方法，基于历史数据确定不同故事点所对应的平均完成时间，为估算提供量化参考。

掌握这些方法，可以帮助团队更准确、更一致地评估待办事项的工作量，从而进行有效的迭代规划。

034：一种估算技术 🃏

在本节课中，我们将要学习敏捷项目中一种流行的估算工具——计划扑克。这是一种结合了专家意见、类比和分解的快速、可靠且参与度高的估算方法。

概述 📋

计划扑克是敏捷团队进行工作估算的最佳方式之一。它将专家意见、类比和分解结合成一种令人愉快的估算方法，旨在快速得出可靠的估算结果。其核心在于快速和参与性，让团队成员享受估算过程。

如何进行计划扑克 🎮

上一节我们介绍了计划扑克的概念，本节中我们来看看具体的操作步骤。

参与者与准备

计划扑克会议应包含团队中的所有“开发者”。在敏捷项目中，“开发者”指所有程序员、测试员、数据库工程师、分析师、用户交互设计师等。团队规模通常不超过10人。如果超过，最好分成两个独立估算的小组。

  • 产品负责人参与会议，但不进行估算。
  • 会议开始前，为每位估算者准备一副卡片。
  • 每张卡片上印有一个有效的估算数字，例如：0, 1, 2, 3, 5, 8, 13, 20, 40, 100。
  • 这些卡片可以重复使用。

估算流程

以下是计划扑克会议的标准流程：

  1. 陈述故事：由主持人（通常是产品负责人或分析师）朗读需要估算的用户故事或主题的描述。
  2. 提问与澄清：团队成员可以就故事细节提问，主持人进行解答。
  3. 私下估算：所有问题解答完毕后，每位估算者私下选择一张代表其估算值的卡片。
  4. 同时亮牌：待所有人都做出选择后，所有估算者同时亮出卡片，展示各自的估算值。
  5. 讨论差异：此时估算值很可能出现显著差异。这是正常且有益的。估算最高和最低的成员需要解释其理由（例如，高估者可能考虑了额外工作，低估者可能想到了自动化方案）。讨论的目的是理解不同视角，而非攻击他人。
  6. 重新估算：经过简短讨论后，每位估算者再次私下选择卡片进行重新估算，并同时亮牌。
  7. 达成共识：目标是通过几轮讨论和估算，让团队的估算值收敛到一个合理的、大家都能接受的单一数值上。共识比绝对精确更重要。

核心原则与技巧

在了解了基本流程后，我们来看看确保计划扑克成功的一些核心原则。

  • 目标不是绝对精确：计划扑克的目标并非得出一个能经受住未来一切考验的“完美”估算，而是快速、低成本地得到一个有价值的、合理的估算。
  • 处理差异：估算差异是好事，它揭示了团队成员对故事复杂度的不同理解。通过讨论这些差异，团队能对需求达成更一致的认识。
  • 达成合理共识：估算的最终目的是就一个“合理”的时间达成小组共识，而不是执着于“准确”的数字。例如，如果多数人估算是5，而一人估算是3，可以询问低估算者是否同意5这个结果。

总结 🎯

本节课中我们一起学习了计划扑克这种敏捷估算技术。我们了解到它是一种快速、参与性强的团队活动，通过结合专家意见、类比和分解，并经过多轮私下估算与公开讨论，最终帮助团队就用户故事的工作量达成一个合理的共识估算。记住，其核心价值在于促进沟通和理解，而非追求数学上的精确。

035：规划扑克详解 🃏

在本节课中，我们将学习敏捷估算的核心实践——规划扑克。我们将了解其操作流程、关键原则、最佳实践时机以及它为何如此有效。通过掌握这些内容，你将能够带领团队进行高效、准确的用户故事估算。

讨论的适度性 ⚖️

上一节我们介绍了规划扑克的基本概念，本节中我们来看看执行过程中的一个关键原则：讨论的适度性。

进行规划扑克时，讨论的适量或适度程度至关重要。在估算时，进行一定程度的初步设计讨论是必要且恰当的。然而，在设计讨论上花费过多时间，会使团队陷入“投入-精度曲线”的误区，即投入时间远超精度提升的收益。

使用计时器控制讨论 ⏳

为了确保讨论高效且不超时，一个有效的方法是使用一个两分钟的沙漏计时器。将其放在进行规划扑克的桌子中央，任何与会者都可以在讨论过长时将其翻转。当沙子在两分钟内流尽时，无论是否达成一致，都必须进行下一轮出牌。如果仍未达成一致，讨论可以继续，但必须有人立即再次翻转计时器，将讨论限制在又一个两分钟内。

在实践中，计时器很少需要被翻转超过两次。这种方法能帮助团队学会更快速地进行估算。

处理大规模估算任务 👥

有时，尤其是在新项目开始时，可能需要估算的项目非常多。此时，让所有人参与同一轮规划扑克可能不理想。一个合理的替代方案是使用“国王的替身”模式，即只让部分代表参与估算。

更好的做法是将大团队拆分成两到三个小组，每个小组必须至少包含三名估算者。关键在于确保各小组的估算标准一致。例如，当你的团队称一个故事为“3个故事点”时，其工作量最好与我的团队所称的“3个故事点”保持一致。

为实现这种一致性，可以采取以下步骤：

  1. 开始时，让所有团队一起进行约一小时的联合规划扑克会议。
  2. 共同估算10到20个用户故事。
  3. 确保每个团队都获得这些故事及其估算结果的副本。
  4. 各团队以此作为基准，来估算分配给他们的其他故事。

规划扑克操作步骤 📝

以下是使用规划扑克进行估算的关键步骤：

  1. 准备阶段：为每位估算者分发一套估算卡。
  2. 讲解故事：产品负责人（PO）澄清待估算的用户故事细节。
  3. 私下估算：每位估算者根据所需工作量（小时或天数）私下选择一张估算卡。
  4. 同时亮牌：所有估算者同时亮出自己选择的卡。
  5. 讨论差异：重点讨论估算最高和最低的成员，请他们阐述理由。
  6. 达成共识：团队讨论并寻求对最终估算值的共识。
  7. 记录并继续：总结估算结果，产品负责人继续下一个故事的估算。

何时进行规划扑克 🗓️

了解何时进行规划扑克至关重要。团队通常需要在两个不同时间点进行：

  1. 项目启动或首次迭代时：在项目正式启动前或在其最初几次迭代中，通常需要估算大量待办事项。估算初始的故事池可能需要团队进行两到三次会议，每次持续一到三小时。具体时长取决于待估算项的数量、团队规模以及产品负责人澄清需求的能力。
  2. 迭代过程中：团队需要付出持续努力，以估算在迭代期间新识别的任何故事。有两种常见做法：
    • 在每次迭代临近结束时，计划一个非常简短的估算会议。这通常足以估算迭代期间出现的任何新工作，并允许在规划下次迭代时考虑这些工作的优先级。
    • 肯特·贝克（Kent Beck）曾建议在墙上挂一个信封，将所有未估算的故事放在信封上。当个人有几分钟空闲时，可以从信封中取出一两个故事进行估算。团队为自己设定规则，通常是所有故事必须在当天或迭代结束前完成估算。

我个人喜欢在墙上挂一个信封来存放未估算故事的想法。然而，我更倾向于当有人有空进行估算时，他至少找到另一个人，然后他们通过规划扑克的方式共同进行估算。

规划扑克为何有效 ✅

规划扑克之所以效果显著，基于以下几个原因：

  1. 汇聚专家意见：规划扑克汇集了多位专家的意见进行估算。这些专家来自软件项目的各个职能领域，组成了一个跨职能团队，因此比任何个人都更适合完成估算任务。乔安森（Joensson）在完成对软件估算文献的全面研究后得出结论：最有能力解决任务的人应该对其进行估算。
  2. 激发讨论与论证：规划扑克会引发活跃的对话，估算者需要向同伴论证其估算值的合理性。这已被证明能提高估算的准确性，尤其是在不确定性较高的项目上。被要求论证估算值也被证明能产生更好补偿缺失信息的估算结果，这对于用户故事常常故意保持模糊的敏捷项目尤为重要。
  3. 结合群体智慧：研究表明，对个体估算值进行平均以及进行小组讨论都能带来更好的结果。规划扑克以小组讨论为基础，这些讨论最终会形成一种对个体估算值的“平均”。
  4. 充满趣味性：最后，规划扑克行之有效是因为它很有趣。

总结 📚

本节课中我们一起学习了规划扑克这一核心敏捷估算实践。我们明确了适度讨论的原则，学会了使用计时器控制会议节奏，掌握了处理大规模估算的分组技巧，并梳理了从准备到共识的完整操作步骤。我们还探讨了在项目启动和迭代过程中进行估算的最佳时机，并深入分析了规划扑克之所以有效的四大原因：汇聚专家智慧、促进深度论证、结合群体判断以及其自带的趣味性。掌握这些知识，你将能有效地运用规划扑克提升团队估算的效率和准确性。

敏捷实践：03_02_04：什么是重估计 📊

在本节课中，我们将要学习敏捷开发中的一个重要概念——重估计。我们将探讨在什么情况下需要进行重估计，以及如何正确地进行重估计，以确保项目评估的准确性和一致性。

概述

我们已经了解了估算的基本概念。在实际项目中，存在一些特定的场景和情况，在这些时候，我们需要对已经估算过的用户故事进行重新估算，这就是重估计。

何时进行重估计？

重估计是指对之前已经估算过的某些用户故事再次进行估算。一个很自然的问题是：我们何时需要进行重估计？

答案是：当用户故事的内容发生变化时，我们就需要进行重估计。

关于使用故事点或理想天数进行估算，一个最常见的问题是：我们何时进行重估计？要回答这个问题，关键在于记住：故事点和理想天数是对待实现功能的整体规模和复杂性的估算。

故事点尤其不是对实现该功能所需时间的估算，尽管我们常常会陷入这种思维误区。实现一个功能所需的时间是其规模（以理想天数或故事点估算）和团队速度（反映其进展速率）的函数。

如果我们记住故事点和理想时间估算的是规模，那么就更容易理解：我们只应在认为一个故事的相对规模发生变化时，才进行重估计。在使用故事点或理想点数时，我们不会仅仅因为一个故事的实际实现时间比预想的要长就进行重估计。

速度是平衡器

理解这一点最好的方式是通过一些例子。速度是一个强大的平衡器，因为每个功能的估算是相对于其他功能的估算来进行的。我们的估算是完全正确、稍有偏差还是完全不正确，这并不重要。重要的是它们要保持一致。我们不能简单地掷骰子来决定估算值。

然而，只要我们的估算保持一致，通过最初几个迭代来衡量速度，就能让我们逐渐掌握一个可靠的进度计划。

对部分完成的故事进行重估计

当团队在一个迭代中只完成了某个故事的一部分时，你可能也希望进行重估计。

假设团队正在处理一个故事：“作为教练，我希望系统能推荐每个项目中应该由谁游泳。” 这个故事最初被估算为5个故事点，但它实际上比预想的要复杂。

如果故事被完成、测试并被产品负责人接受，团队将获得全部点数。但如果故事有任何部分未完成，他们在迭代结束时将得不到任何点数。这是最容易评估的情况：如果一切都完成了，他们将获得全部点数；如果有任何缺失，他们将得不到点数。

如果团队很可能在下一个迭代中完成故事的剩余部分，这种方法效果很好。他们在第一个迭代中的速度会略低于预期，因为他们没有因部分完成故事而获得点数。

然而，在第二个迭代中，速度将高于预期，因为他们将获得全部点数，尽管部分困难的工作在迭代开始前已经完成。只要每个人都记住，我们主要关注的是团队长期的平均速度，而不是某个特定迭代中速度的起伏，这种方法就很好。

然而，在某些情况下，故事的未完成部分可能不会在下一个迭代中完成。在这些情况下，允许团队为已完成的故事部分获得部分点数可能是合适的。剩余的故事（原始故事的一个子集）会根据团队当前的知识进行重新估算。

在这种情况下，原始故事被估算为5点。如果团队认为他们完成的子集相当于3个故事点或理想天数，他们将给自己记上相应的点数。原始故事的未完成部分可以被重写为一个更小的故事（例如，“作为教练，我希望系统能推荐每个接力项目中应该由谁游泳”），然后团队可以相对于所有其他故事来估算这个更小的故事。合并后的估算值不一定需要等于原始的5点估算。

以下是处理未完成故事点数分配的两个最佳解决方案：

  1. 避免有任何未完成的故事。
  2. 使用足够小的故事，这样部分完成就不再是一个问题。

重估计的目的

现在让我们来理解重估计的目的。需要记住的一点是：不要过度担心是否需要重估计。

重估计更像是一种精炼，是基于迄今为止的旅程进行微调。

每当团队感觉一个或多个故事相对于其他故事被错误估算时，就应进行重估计。尽可能少地重估故事，以使相对估算重新回到正轨。将重估计作为估算未来用户故事的学习经验。未能从中学习是唯一的真正失败。

从每个重估计的故事中学习，并将经验转化为成功。

总结

本节课中，我们一起学习了敏捷开发中的重估计概念。我们明确了重估计是指在用户故事内容发生变化时，对其规模进行重新评估。关键在于理解故事点估算的是相对规模和复杂性，而非绝对时间。我们探讨了在故事部分完成时进行重估计的策略，并强调了速度作为长期平衡器的作用。最后，我们指出重估计的核心目的是学习和持续改进，应将其视为微调和精炼过程，而非对失败的指责。

敏捷项目管理：第5章：基于价值的优先级排序 📊

在本章中，我们将学习如何为敏捷项目中的工作项进行优先级排序。我们将探讨影响优先级决策的关键因素，包括财务价值、开发成本、学习价值和风险降低价值，并介绍最小可市场化价值的概念。

上一节我们介绍了本章的学习目标，本节中我们来看看优先级排序中的关键因素。

确定一个主题的价值是困难的。敏捷项目中的产品负责人经常收到模糊且大多无用的建议：“根据业务价值确定优先级”。因此，我们需要更具体的考量因素。

以下是影响优先级排序的四个关键因素：

  1. 财务价值：拥有该功能能为组织带来或节省多少资金。
  2. 开发成本：开发和可能支持新功能所需的成本，这通常来自故事点估算。
  3. 学习价值：通过开发功能所创造的新知识的数量与重要性。
  4. 风险降低价值：通过开发功能所消除的风险量。

由于大多数项目旨在节省或赚取资金，前两个因素通常在优先级讨论中占主导地位。然而，为了进行最优排序，充分考虑学习和风险对项目的影响至关重要。

接下来，让我们深入了解第一个因素：财务价值。

优先级排序的第一个因素是主题的财务价值，即组织因包含该主题的新功能而将赚取或节省的资金。

确定主题价值的一个理想方法是估算其在未来一段时间（通常是接下来的几个月、季度或几年）内的财务影响。如果产品将进行商业销售，这可以做到。

例如，一个新的文字处理器或带有嵌入式软件的计算机器。估算主题的财务回报可能很困难，这通常涉及估算新增销售额、平均销售额（包括后续销售和维护协议）、销售增长的时间点等。

由于这种估算的复杂性，通常需要一个替代方法来估算价值。因为主题的价值与其对新用户和现有用户的吸引力相关，所以可以使用非财务的吸引力衡量标准来代表价值。

本节课中我们一起学习了基于价值的优先级排序。我们探讨了财务价值、开发成本、学习价值和风险降低这四大关键因素，并理解了在商业目标主导下，仍需全面考量学习与风险以做出最优决策。我们还了解到，在直接财务估算困难时，可以通过衡量功能吸引力来间接评估价值。

038：什么是风险优先级 📊

在本节课中，我们将学习如何评估和优化产品待办事项列表的优先级。我们将深入探讨决定优先级的关键因素，特别是成本、学习量和风险，并学习如何综合这些因素做出最优决策。

上一节我们介绍了价值在优先级排序中的核心作用，本节中我们来看看其他几个同样重要的决定因素。

成本 💰

成本是决定功能整体优先级的巨大决定因素。许多功能在了解其成本之前看似美好。成本的一个重要但常被忽视的方面是，成本会随时间变化。例如，今天添加国际化支持可能需要四周的工作量，但六个月后再添加可能需要六周。因此，在优先级排序时，最佳做法通常是进行粗略的估算转换。

以下是常见的成本估算方法：

  • 将故事点或理想人日转换为货币价值。

学习量 📚

在许多项目中，大量总体努力是为了追求新知识，或通过承担项目来投资开发技能集和能力。承认并考虑这种努力对项目至关重要。获取新知识很重要，因为在项目开始时，我们永远无法预知项目结束时需要知道的一切。

团队发展的知识可分为两个领域：

  • 产品知识：关于将要开发什么的知识，包括哪些功能会被包含，哪些不会。团队拥有的产品知识越多，就越能更好地决定产品的性质和功能。
  • 项目知识：关于产品将如何被创造的知识。例如，关于将使用的技术、开发人员的技能、团队如何协同工作等知识。

风险 ⚠️

与“新知识”概念紧密相关的是优先级排序的最后一个因素：风险。几乎所有项目都包含大量风险。就我们的目的而言，风险是任何尚未发生但可能发生，并且会危及或限制项目成功的事情。

项目中有许多不同类型的风险，包括：

  • 进度风险：我们可能无法在十月前完成。
  • 成本风险：我们可能无法以合适的价格购买。
  • 功能风险：我们可能无法完成工作。

此外，风险可分为技术风险或业务风险。一个经典的矛盾存在于项目的高风险、高价值功能之间：项目团队应该首先关注可能破坏整个项目的高风险功能，还是应该首先关注Tom Gilb所说的“多汁部分”——那些能带来最直接项目回报的高价值功能？

为了在两者之间做出选择，让我们考虑每种方法的缺点：

  • 风险驱动型团队接受他们执行的工作可能最终被证明是不需要或低价值的可能性。他们可能会为最终被证明不必要的功能开发基础设施支持，因为产品负责人根据从用户那里学到的东西，在项目进展中不断细化她对项目的愿景。
  • 另一方面，只关注价值而排除风险的团队可能会在开发大量应用程序后，遇到危及产品交付的风险。

当然，解决方案是在确定优先级时，既不给予风险也不给予价值绝对的至高地位。为了最优地确定工作优先级，必须同时考虑风险和价值。

风险-价值关系象限 📈

这体现在风险-价值关系象限中。在Y轴上我们有风险，在X轴上我们有价值，我们得到四个象限。

为了结合这四个优先级因素，首先考虑功能的价值相对于其成本。这为你提供了主题的初始优先级顺序。那些具有高价值成本比的主题应该首先完成。

接下来，考虑其他优先级因素，将主题向前或向后移动。假设一个主题基于其价值和成本处于中等优先级。因此，该主题倾向于在当前发布周期的中期进行。然而，开发这个故事所需的技术风险很高。这将使该主题在日程安排上的优先级向前移动。

这种初始排序，然后进行前后调整，不一定是一项正式活动。每一步都可以，并且经常完全发生在产品负责人的脑海中。然后，产品负责人通常会向团队展示她的优先级，团队可能会根据他们的评估，促使产品负责人稍微改变优先级。

因此，一个高价值、高风险的事项应该首先完成，其次是高价值、低风险的事项，然后是低价值、低风险的事项，而高风险、低价值的事项应该完全避免。

本节课中我们一起学习了优先级排序的四个关键因素：价值、成本、学习量和风险。我们了解到，最优的优先级决策需要平衡这些因素，特别是利用风险-价值象限来指导决策，确保团队首先处理高价值且高风险的事项，以最大化项目成功的机会并降低总体不确定性。

敏捷实践：04_01_03：基于价值的优先级排序 📊

在本节课中，我们将要学习敏捷开发中的一个核心实践：基于价值的优先级排序。我们将了解如何客观地对产品待办事项进行排序，并深入探讨决定优先级的四个关键因素：价值、成本、风险和学习。

现在，我们来理解优先级排序。优先级排序依赖于价值、成本、风险和学习这四个参数。我们将逐一分析每个参数如何影响优先级决策。

价值 💰

价值指的是主题（Theme）或功能所带来的财务收益。它衡量的是组织通过实现新功能能够赚取或节省多少钱。

通常，确定价值的一个理想方法是估算其在未来一段时间（例如未来几个月或几个季度）内的财务影响。这对于即将商业化销售的产品（例如新的文字处理软件或带有嵌入式软件的计算机）尤其适用。

然而，精确估算财务回报可能很复杂，因为这通常涉及预测新增销售额、平均交易价值、后续维护协议等。由于这种复杂性，采用非财务的“需求度”指标来代表价值通常很有用。简而言之，价值就是功能为组织带来的财务收益。

核心公式：
价值 = 功能带来的预期财务收益

成本 💸

成本是决定功能整体优先级的巨大因素。因为你需要先投入资金，之后才能获得收益。许多功能在了解其成本之前看起来都很美好。

一个常被忽视的方面是，成本会随时间变化。例如，今天添加国际化支持可能需要四周的工作量，但六个月后再添加，可能就需要六周。在优先级排序时，一个有效的方法是将故事点或理想人日粗略地转换为货币成本。因此，成本是指将功能、特性或软件变为现实所需的资金支出。

核心概念：
成本 = 实现功能所需的工作量（可转换为货币估算）

风险 ⚠️

与“新知识”概念紧密相关的是优先级排序的第三个因素：风险。几乎所有项目都包含大量风险。

对我们而言，风险是指尚未发生但可能发生，并且会危及或限制项目成功的事情。项目风险有多种类型，包括：

  • 进度风险：可能无法在十月前完成。
  • 成本风险：可能无法以合适的价格购买到硬件。
  • 功能风险：可能无法让某个功能正常工作。

此外，风险可分为技术风险和商业风险。项目中常存在高价值功能与高风险功能之间的权衡。团队应该先处理可能颠覆整个项目的高风险功能，还是应该先专注于能为客户带来最直接回报的高价值“精华部分”？

让我们考虑两种方法的缺点：

  • 优先处理风险：团队可能开发出最终被证明是不必要或低价值的基础设施或功能，因为产品负责人的愿景会随着项目进展和用户反馈而调整。
  • 优先处理价值：团队可能在遇到危及产品交付的风险之前，已经开发了应用程序的很大一部分，导致前期投入可能因风险而白费。

学习 📚

每个项目都是一次新的体验，都涉及获取新知识。在许多项目中，大量整体精力都花在追求新知识上。承认这种努力并将其视为项目的基础至关重要。

新知识之所以重要，是因为在项目开始时，我们永远无法预知项目结束时需要知道的一切。团队获得的知识可分为两个领域：

  1. 产品知识：关于将要开发什么的知识。包括对包含哪些功能、不包含哪些功能的了解。团队掌握的产品知识越多，就越能做出关于产品性质和功能的明智决策。
  2. 项目知识：关于如何创建产品的知识。例如，关于将使用的技术、开发人员的技能、团队协作效率等方面的知识。

获取这两类知识都是项目成功的关键，因此在排序时需要考虑哪些工作项能最大程度地促进团队学习。

本节课中，我们一起学习了基于价值的优先级排序方法。我们明确了优先级排序并非随意决定，而是需要系统性地评估价值、成本、风险和学习这四个核心维度。理解并平衡这些因素，能够帮助团队更科学地决定工作顺序，从而最大化项目成果，并更有效地应对不确定性。记住，优先级是一个动态过程，需要根据项目进展和新获取的知识持续进行审视和调整。

040：卡诺模型 📊

在本节课中，我们将学习一个重要的需求优先级排序工具——卡诺模型。该模型通过分析客户满意度与功能实现程度之间的关系，帮助我们有效区分和优先处理产品功能。

概述 📋

卡诺模型是一种用于理解和分类客户需求、以指导产品功能优先级排序的框架。它将产品功能分为三类：基本型需求、期望型需求和兴奋型需求。理解这三类需求有助于团队集中精力开发最能提升客户满意度的功能。

卡诺模型详解 📈

上一节我们介绍了优先级排序的重要性，本节中我们来看看卡诺模型的具体构成。该模型通过一个坐标图来展示三类需求与客户满意度的关系。纵轴（Y轴）代表客户满意度，横轴（X轴）代表功能实现程度。图中有三条不同颜色的曲线，分别代表三类属性。

  • 基本型需求：图中红色曲线。这是产品“必须有”的属性。即使这些功能实现得再好，客户满意度也不会显著提升；但若缺失，客户会极度不满。其满意度曲线相对平缓。
    • 公式/概念：满意度 = f(实现度)，当实现度达到基础阈值后，函数增长近乎为零。
  • 期望型需求：图中绿色曲线。这类需求是“越多越好”。客户满意度与功能的实现数量或质量成正比增长。其满意度曲线呈线性。
    • 公式/概念：满意度 ∝ 实现度（正比例关系）。
  • 兴奋型需求：图中黄色曲线。这是超出客户预期的功能，能带来极大的满意度提升。即使只实现一部分，也能显著提高客户满意度；但若没有，客户也不会感到不满。其满意度曲线呈指数增长。
    • 公式/概念：满意度 ∝ e^(实现度)（指数关系）。

三类功能特征与应用 🎯

基于卡诺模型的理论，我们可以将产品功能具体划分为三类。以下是每类功能的详细说明及其在优先级排序中的应用。

1. 阈值功能（基本型需求）
这类功能是产品成功的必要条件，常被称为“必须有”的功能。

  • 示例：酒店房间的床、浴室、书桌和清洁程度。
  • 特点：提升这类功能的性能对客户满意度影响甚微。但只要满足基本需求，客户就不会不满意。
  • 优先级策略：必须全部开发，并在产品发布前可用。它们不需要在每次迭代中都开发，但必须在发布时具备。

2. 线性功能（期望型需求）
这类功能遵循“越多越好”的原则。

  • 示例：酒店房间的面积、健身房的设备和种类。
  • 特点：客户满意度与功能的数量或质量线性相关。产品价格常与这类属性挂钩。
  • 优先级策略：应尽可能多地完成这类功能，因为每一个都能直接带来更高的客户满意度。当然，需避免产品因功能过多而变得臃肿。

3. 兴奋点与惊喜功能（兴奋型需求）
这类功能能带来极大的满足感，常能为产品增加溢价。

  • 示例：酒店房间内置的蒸汽浴室。
  • 特点：缺少它们不会降低客户满意度（因为客户原本不知道），但拥有它们会极大提升满意度。因此常被称为“未知需求”。
  • 优先级策略：在时间允许的情况下，应优先考虑纳入至少几个这样的功能到发布计划中。

总结 ✨

本节课中，我们一起学习了卡诺模型。该模型由狩野纪昭博士提出，它将功能分为基本型（必须有）、期望型（线性相关）和兴奋型（惊喜）三类。通过应用这个模型，团队可以清晰地聚焦于：首先确保所有基本功能就位；然后尽力实现更多的期望功能以线性提升满意度；最后，在资源允许时纳入兴奋功能，为产品创造惊喜和差异化优势。这为新产品发布过程中的功能优先级排序提供了清晰、有效的指导。

041：财务价值 💰

在本节课中，我们将学习如何从财务角度评估和优化敏捷项目中的功能优先级。我们将探讨几种量化功能价值的方法，包括相对权重法、MoSCoW分类法以及基于财务收益（如增加收入或节约成本）的优先级排序策略。

相对权重法 ⚖️

上一节我们介绍了多种优先级排序思路，本节中我们来看看一种更细致的量化方法——相对权重法。这种方法不仅考虑功能存在时带来的正面收益，也考虑其缺失时造成的负面惩罚。

该方法主要依赖产品负责人引导下的专家集体判断。团队对下一个版本中考虑的功能进行评估。每个功能都会从两个维度打分：

  • 相对收益：如果实现该功能，会带来多少好处。
  • 相对惩罚：如果不实现该功能，会招致多少损失。

收益和惩罚的估算与故事点估算类似，采用相对尺度。通常使用1到9的标度进行评分。

以下是具体的计算步骤：

  1. 列出功能：在第一列列出所有待评估的功能。
  2. 评分：为每个功能评定相对收益（1-9分）和相对惩罚（1-9分）。
  3. 计算总值：将每个功能的收益分与惩罚分相加，得到该功能的“总值”。
  4. 计算价值百分比：将所有功能的“总值”求和，然后计算每个功能的“总值”占总和的百分比，此即该功能的“价值百分比”。
  5. 评估成本与风险：类似地，为每个功能评定相对成本（1-9分）并计算“成本百分比”；评定相对风险（1-9分）并计算“风险百分比”。
  6. 计算优先级：优先级相对于价值和成本而定。计算 优先级 = 价值百分比 / 成本百分比。比值越高，优先级越高，因为这意味着投入单位成本能创造更高的价值。

通过这种方法，我们可以得到所有功能的绝对价值与成本评级，那些相对于成本能带来更高价值的功能应优先开发。

MoSCoW 分类法 🗂️

理解了量化的相对权重法后，我们再来看看一种基于分类的经典优先级框架——MoSCoW法。此方法将功能分为以下四个类别：

  • 必须有：这些功能是产品发布前必须包含的，缺少它们产品无法上市。
  • 应该有：这些功能对发布并非关键，但对用户具有高价值，应尽可能包含。
  • 可以有：这些功能是“锦上添花”的，如果不需要太多努力或成本就可以实现。当项目进度面临风险时，这些功能将首先被移出范围。
  • 不会有：这些是已提出的功能，但在当前计划周期内被明确排除在范围之外，可能会在未来的开发阶段考虑。

MoSCoW模型源自DSDM（动态系统开发方法）方法论，它通过清晰的分类帮助团队聚焦于核心价值。

财务价值优先排序 💵

无论是相对权重法还是MoSCoW法，其核心都在于衡量“价值”。从财务角度看，价值创造主要源于两个方向：为企业带来更多收入，或通过提升运营效率来节约成本。

增加收入

预测功能的财务价值是产品负责人的职责，但也需要与团队成员及其他部门（如销售、市场）协作。收入增长可以来自以下三个方面：

  1. 新收入：通过吸引全新客户群体或开拓全新业务领域带来的收入。例如，为医院开发的软件经过增强后，成功销售给健康保险公司，开辟了全新的收入来源。
  2. 增量收入：促使现有客户购买更多、升级或购买附加服务带来的额外收入。例如，软件新增可选模块，或支持与第三方应用集成而收取的咨询费。
  3. 保留收入：为防止因功能缺失而导致现有客户流失所必须保护的收入。例如，若不升级软件以支持多医生诊所的排班功能，就可能失去那些正在发展的客户。

节约成本

任何组织都有提升运营效率的空间。开发软件，无论是内部使用还是对外销售，都可能通过以下方式实现成本节约：

  • 自动化或简化耗时长的任务。
  • 改善部门间的集成与沟通。
  • 降低员工流失率，缩短新员工培训时间。
  • 提高流程准确性，减少返工和废品。
  • 合并多个流程，进行业务流程重组。

通过关注这些方面，敏捷项目可以为企业创造显著的财务价值。

本节课中我们一起学习了：如何运用相对权重法（通过公式 优先级 = 价值百分比 / 成本百分比）对功能进行量化排序；如何使用MoSCoW分类法（必须有、应该有、可以有、不会有）对功能进行定性分类；以及如何从财务角度（增加新收入、增量收入、保留收入，以及提升运营效率节约成本）来理解和优先排序功能价值，从而确保开发工作始终聚焦于为企业和用户带来最大效益。

042：内部收益率、净现值与投资回收期 💰

在本节课中，我们将学习在多个项目或主题中进行优先级排序时，用于评估和比较投资价值的三个核心财务决策工具：净现值、内部收益率和投资回收期。理解这些概念能帮助我们更理性地决定将资源投入何处。

货币的时间价值 ⏳

上一节我们介绍了项目优先级决策的四个关键点，本节中我们来看看第一个基础概念：货币的时间价值。要决定未来一笔钱在今天的价值，我们需要思考：今天需要在银行存入多少钱，才能在将来增长到那个目标金额。

今天需要投资的金额，以便在未来获得一个已知的数额，这被称为现值。

  • 简单案例：如果我的资金能获得10%的收益，并且我希望一年后拥有1000元，那么我今天需要投资910元。换句话说，在10%的利率下，910元就是一年后1000元的现值。
  • 如果我的资金能获得20%的收益，那么我今天只需要投资约830元。

将未来金额折算回现值的过程被称为贴现。显然，用于贴现未来金额的利率对于确定未来金额的现值至关重要。组织用来贴现未来资金的利率被称为其机会成本，它反映了为进行此项投资而放弃的其他投资的回报率。

无论是个人还是组织，我们都有多种投资机会。组织可以将资金投入银行、股票、房地产，或者投资于各种项目。如果一个组织过去项目的典型回报率是20%，那么新项目就应该以同样的20%为标准进行评估。该组织20%的机会成本意味着，投资新项目就等于放弃了其他能带来20%回报的投资机会。

净现值 📊

理解了现值，我们就可以引入净现值了。净现值衡量的是一个项目预期能带来多少以今日现值计算的回报。它是项目所有现金流入和流出以现值形式计算的总和。

要确定净现值，需要将一系列未来价值的每个项目的现值相加。其公式如下：

公式：
NPV = Σ [F / (1 + i)^n]
其中：

  • F = 未来价值
  • i = 利率（贴现率）
  • n = 期数

例如，如果未来一笔钱是4000卢比，在10%的利率下，其净现值约为3309卢比。

使用净现值来比较和确定优先级，其优势在于计算简单且易于理解。然而，净现值的一个主要缺点是：比较两个不同现金流项目的价值可能会产生误导。

假设我们需要在两个项目间选择：

  • 项目A需要巨额前期投资，净现值为10万。
  • 项目B只需要少量前期投资，净现值也为10万。

显然，我们更倾向于投资那个占用现金更少但净现值相同的项目。因此，我们真正需要的是能以百分比形式表达项目回报率的方法，以便直接比较。我们通常偏好净现值更高的项目。

内部收益率 📈

内部收益率衡量的是投入项目的资金价值增长的速度。它计算的是使项目现金流入现值总和等于现金流出现值总和的贴现率。

其计算公式与净现值相同，区别在于我们需要计算的是那个使现金流入和流出相等的利率 i。

公式（求解 i ）：
0 = Σ [F / (1 + IRR)^n]
其中 IRR 即为内部收益率。

内部收益率提供了以百分比形式表达项目回报率的方法。如果说净现值衡量的是项目预期能带来多少绝对金额的回报，那么内部收益率衡量的就是投资增值的速度。通过内部收益率，我们可以更直接地比较不同项目。我们通常偏好内部收益率更高的项目。

投资回收期 ⏱️

除了将现金流视为一个现值总额或一个利率，我们还可以从另一个角度看待它：收回初始投资所需的时间。这被称为投资回收期。

投资回收期是指以项目产生的净现金流入形式，收回净投资额所需的时间长度。考虑货币时间价值的投资回收期计算，被称为贴现投资回收期。

我们通常偏好投资回收期更短的项目。

项目比较与总结 ✅

综上所述，在基于价值比较项目时，我们有三个参数：

以下是三个核心评估指标的比较准则：

  • 净现值：选择净现值最高的项目更好。
  • 内部收益率：选择内部收益率更高的项目更好。
  • 投资回收期：选择投资回收期更短的项目更好。

重要提示：比较项目时应使用相同的参数。不要用一个项目的净现值去和另一个项目的投资回收期比较，因为这缺乏统一或理性的比较基础。

此外，投资回报率也是一个相关指标，其公式为：
ROI = (净利润 / 投资成本) × 100%
它指示了你的投资以何种速度回收成本并转化为现金。

本节课中，我们一起学习了净现值、内部收益率和投资回收期这三个关键财务工具。它们从不同角度（总回报额、回报速度、回本时间）帮助我们量化项目价值，是在资源有限情况下进行科学优先级排序的重要依据。

敏捷实践：从思维模式出发的应用、评估与优化：04_02_01：最小可市场化特性 (MMF) 🎯

在本节中，我们将学习敏捷优先级排序中的一个强大概念——最小可市场化特性。我们将了解它的定义、核心属性以及它在产品开发中的实际应用。

概述

最小可市场化特性是敏捷开发中的一个关键概念，它帮助我们聚焦于为用户提供价值的最小功能单元。理解并应用这一概念，能有效提升产品交付的效率与市场响应速度。

什么是 MMF？

现在，我们来理解敏捷优先级排序中的一个强大概念，即最小可市场化特性。

一个最小可市场化特性，是能够为你的市场提供价值的最小功能集合。无论这个市场是使用定制软件的内部用户，还是使用商业软件的外部客户，它都是为了让客户感知到价值而必须实现的最小功能集。

MMF 由三个核心属性定义：最小、可市场化和特性。

  • 特性：指用户或市场自身能感知为有价值的东西。
  • 可市场化：意味着它能为客户提供显著价值。这种价值可能包括：收入增长、成本节约、竞争优势、品牌形象提升或客户体验增强。

一个发布版本，就是一系列可以在同一时间框架内一起交付的 MMF 的集合。

如何确定 MMF 的边界？

上一节我们定义了 MMF，本节中我们来看看如何在实际操作中确定一个功能是否达到了 MMF 的标准。

首先，理解“最小”这个概念。如果拆分一个功能会导致其故事无法向客户进行市场推广，那么就不应该进行拆分。为了帮助做出这个决策，可以始终问一个问题：“这个功能是否值得在向客户介绍新版本功能的假想邮件中，拥有自己的一个要点？” 如果答案是否定的，那么就不要拆分它。

MMF 仅规定了在我们开始着手开发时，期望的功能规模。

MMF 的演进过程

了解了 MMF 的判定标准后，我们来看看它在产品待办事项列表中的动态演进过程。

通常，MMF 是一系列更大特性的“后代”。随着这些特性在待办事项列表中优先级上升、重要性增加，我们将其分解以提供更多细节。

例如，一个名为“地理标记照片”的特性，是“照片分享”特性的后代。而“照片分享”又是“iPhone 客户端”特性的后代。“iPhone 客户端”则是最初“移动端支持”特性的后代。像“移动端支持”、“iPhone 客户端”和“照片分享”这些高层级特性可能已不在待办事项列表中，但它们的数十个“后代”特性（即具体的 MMF）仍在。这就是一个特性的演进过程，其中增加更多细节是自然有机的。

总结

本节课中，我们一起学习了最小可市场化特性。我们明确了 MMF 是能为市场提供价值的最小功能单元，它具备“最小”、“可市场化”和“特性”三个属性。我们学会了通过“是否值得单独宣传”来判定功能拆分的边界，并理解了 MMF 如何从宏观特性中逐步细化、演进而来。掌握 MMF 有助于团队聚焦核心价值，实现快速、有效的产品迭代。

敏捷实践：04_02_02：最小可市场化特性（MMF）详解 🎯

在本节课中，我们将要学习敏捷开发中的一个核心概念——最小可市场化特性（Minimum Marketable Feature， 简称MMF）。我们将探讨其定义、构成要素、与用户故事的区别，以及它在实际工作流中的应用。

什么是MMF？🤔

最小可市场化特性（MMF）是指一个最小的、完整的、可发布的产品功能单元。它必须能为客户提供明确的价值，并且能够独立推向市场。

上一节我们介绍了敏捷思维，本节中我们来看看如何将这种思维落实到具体的、可交付的特性上。

MMF的三大构成要素 🔑

一个合格的MMF必须同时满足以下三个条件：

1. 最小化（Minimum）

它必须是实现某个客户目标所需的最小功能集合。这意味着它不包含任何多余或“锦上添花”的部分。

核心公式：MMF = 实现核心客户价值的最小功能集

2. 市场化（Marketable）

该特性必须能为客户创造可感知的价值，并值得单独发布。你需要问自己：“这个特性有市场价值吗？”如果答案是否定的，那么它很可能不应该作为一个MMF存在，因为它没有为客户创造额外价值。

像史蒂夫·乔布斯这样的远见者或许能在客户意识到之前就洞悉其需求。但对于我们大多数人而言，开发一个不被客户认可价值的特性，至少应该引起我们的高度警惕。

3. 特性（Feature）

它必须展示产品的外在行为，是客户能够看到、使用并感知的东西。

以下是符合“特性”定义的例子：

  • 购物车
  • 3.5毫米耳机插孔

以下是不符合“特性”定义的例子（它们可能是实现特性所必需的活动，但其本身不是特性）：

  • 设计数据库架构
  • 注塑成型研究

MMF与用户故事的区别 📖

MMF与Scrum或极限编程中典型的用户故事有所不同。

  • 用户故事通常较小，是开发团队的工作单元。多个用户故事可能共同构成一个MMF。
  • MMF的规模则稍大一些，它不会再被分解成更小的特性，但其本身已足够独立发布。通常，每完成一个MMF就可以进行一次产品发布。

一个MMF可以用一个用户故事的格式来描述：作为一个 <用户角色>， 我想要 <某个功能>， 以便于 <达成某种价值>。

在使用MMF时，团队不会将这个用户故事拆分成更小的故事。可以这样思考：将所有共享同一个“以便于”（即相同商业价值）的用户故事聚集起来，就构成了你的一个MMF。

MMF的工作流程 🔄

MMF工作流程是开发过程中面向客户的部分。我们在这一领域的工作变革对客户产生了最大的影响，并获得了积极的反馈。

它使我们能够：

  1. 将客户与具体的技术实现隔离开来。
  2. 让客户始终保持对应用程序行为的关注。

对于我们的大多数客户而言，向精益开发流程的转型是他们首次接触任何类型的敏捷环境，因此这一流程的设计清晰易懂至关重要。

总结 📝

本节课中我们一起学习了最小可市场化特性（MMF）。我们明确了MMF是最小、可独立发布、为客户提供价值的功能单元，它由最小化、市场化、特性三个要素构成。MMF比用户故事规模更大，且通常对应一次发布。通过采用MMF工作流，团队可以更专注于为客户交付可感知的价值，并有效管理产品开发过程。

理解并应用MMF，能帮助团队避免开发无用功能，确保每一次迭代都能产出切实的市场价值。

敏捷实践：课程四：章节二：最小可上市功能 (MMF) 工作流与识别

在本节课中，我们将学习最小可上市功能的工作流程、估算方法以及如何识别和构建一个最小可上市产品。这些知识将帮助你以更精益、更高效的方式交付客户价值。

MMF工作流程

MMF工作流程是我们开发过程中面向客户的部分。我们在这一领域的改变对客户产生了最大的影响，并获得了积极的反馈。它使我们能够将客户与具体的实现细节隔离开来，让他们专注于应用程序的行为表现。

我们向精益开发流程的转型，是我们大多数客户首次接触任何类型的敏捷环境。可以理解，他们中的许多人感到不适应，坦白说，我们最初也有同感。让我们和客户成功完成这次转型的关键，是建立在良好关系基础上的信任。我们通过保持高度透明来巩固这种信任。我们让客户知道，这对我们来说也是一次重大变革，并且我们正在学习和完善我们的流程。既然客户是项目团队的重要组成部分，我们就应该公开征求他们的意见，以改进流程。

估算MMF

以下是MMF的估算方法：

  • 每个MMF会被赋予一个规模估算值，例如：小、中、大或特大。
  • 这些估算可以在MMF处于待办事项列表中的任何时候进行分配。
  • 有时，在MMF被加入待办事项列表时就进行估算；有时，直到我们即将将其拉入“待处理”队列时才进行估算。
  • 确定特定MMF规模的具体方法并不固定，这是一个基于对MMF描述的直觉和最佳判断的简单过程。
  • 尽管没有标准的计算流程，但一些客户发现这些估算在帮助确定优先级方面非常有价值。我们曾有客户做出决定，认为三个小MMF的综合价值超过一个大MMF的价值，从而将它们优先拉入待处理队列。

一旦MMF被拉入待处理队列，其估算值就成为我们回答客户“我多久能拿到这个功能？”这一问题的主要工具。估算并非一成不变。随着我们对MMF范围的理解加深，以及我们获得更多知识，我们能够做出更好的估算。有时，开发一个更高优先级的MMF会影响工作流中靠后MMF的估算。我们的估算越准确，它们就越有价值、越有用。我们会根据系统的整体利益，在必要时更新估算。如果规模变化超过一个等级（例如从小变为大，或从特大变为中），则会触发一次审查，以了解为何对原始估算做出如此重大的调整。

尽管设定估算的过程是一种有根据的猜测，但我们希望持续提高做出准确猜测的能力。

如何识别MMF

上一节我们介绍了MMF的估算，本节我们来看看如何识别MMF。我们需要思考应用程序的目标或项目愿景。以下是识别核心功能的关键步骤：

  1. 聚焦项目目标：思考哪些功能对于实现项目目标是必不可少的。
  2. 区分“必须有”和“最好有”：以同样的方式，我们需要区分功能的必要性，优先考虑那些“必须有”的功能。
  3. 应用MoSCoW法则：MMF包含两个元素：MoSCoW（必须有、应该有、可以有、不会有）和“阈值”。MoSCoW法则帮助我们确定功能的优先级。

理解最小可上市产品

为了创建一个新产品，我们需要展望未来，预测产品大致会是什么样子。然而，对于没有完美预见力的人来说，正确预测未来极其困难。毕竟，关于未来唯一确定的事情就是它的不确定性。没有任何市场研究技术能提供100%准确的预测，尤其是在颠覆性创新领域，正如克莱顿·克里斯坦森在《创新者的窘境》一书中指出的：不存在的市场无法被分析。

因此，投资新产品总是伴随着风险。我们可能瞄准了错误的市场细分、错误的产品或错误的功能，或者产品推出时市场已经发生了变化。

构想一个精益的最小产品：最小化投资风险的一个绝佳策略是构想一个功能集尽可能小的精益最小产品。这样的产品被称为最小可上市产品。它只包含足以成功推出、营销和销售产品的最基本功能集。

开发一个最小产品比开发一个功能更丰富的雄心勃勃的产品更快、更便宜。如果产品失败，损失的时间和金钱更少；如果成功，产品能更早开始盈利。此外，最小产品允许我们更早获得反馈，从而能更快地根据市场反应调整产品。我们遵循“先推出，再完善”的座右铭，而不是试图一开始就创造完美的产品。请注意，产品质量必须从一开始就是合格的，否则可能难以调整产品，缺陷可能会阻碍其被市场接受，甚至损害品牌。

迈向最小可上市产品的步骤：以下是创建精益最小产品的具体步骤：

  1. 限制目标群体：为少数人而非多数人构建产品。正如史蒂夫·布兰克在《四步创业法》中建议的。例如，如果你使用用户画像来描述目标群体成员，请考虑移除某个画像的影响。产品还能销售吗？如果能，就通过放弃该画像来缩小目标群体。一旦你为早期客户做出了出色的产品，你就有能力通过吸引新客户的新增量版本来建立初步的成功。
  2. 理解价值主张并精选功能：理解你产品的价值主张，只选择那些对满足目标群体需求至关重要的功能。要有勇气和纪律暂时舍弃所有其他功能。选择最小的功能集并不意味着创造一个平淡或简陋的产品，而是专注于那些对产品成功至关重要的优先事项。例如，如果你在编写用户故事，请审查每个故事或史诗，并问自己：没有它，产品能发布吗？如果能，就排除这个故事。正如法国作家安托万·德·圣-埃克苏佩里所说：“完美不在于无以复加，而在于无可删减。”

MMF与发布的关系

那么，MMF和发布规划有关系吗？答案是肯定的。发布应该包含MMF。当你尝试进行发布时，它应该是一个最小可上市的功能集。必须有几个对客户有吸引力的功能，或者能为客户提供一些可识别的价值。

谁识别主题价值？ 是产品负责人识别主题价值，因为他是产品的负责人，拥有识别主题价值所需的知识、技能和专长。

“成本”指的是什么？ “成本”指的是开发所需的花费。故事点估算可以代表成本，也就是开发主题所需的资金，是为完成开发所投入的金额。

从风险/价值角度看，应优先开发哪些功能？ 应该优先开发高风险、高价值的功能。因为这能降低风险，并为客户提供高价值。

总结

本节课中，我们一起学习了最小可上市功能的工作流程、基于直觉的规模估算方法，以及如何通过聚焦核心价值、应用MoSCoW法则和构建最小可上市产品来识别MMF。我们还探讨了MMF与发布的关系，以及从风险和成本角度进行优先级排序的原则。掌握这些概念，能帮助团队更高效、更灵活地交付客户真正需要的价值，同时有效管理项目风险和投资。

046：规划学导论 🗺️

在本节课中，我们将要学习敏捷项目管理中的规划。规划是项目成功的关键，缺乏规划往往导致项目失败。我们将探讨规划的重要性、常见失败原因以及敏捷规划的核心方法。

规划的重要性与失败原因

上一节我们提到了规划的重要性，本节中我们来看看项目规划失败的常见原因。根据项目管理协会（PMI）的数据，许多项目在成本、时间和功能交付上都面临挑战。

以下是导致项目失败的主要数据：

  • 成本超支：近三分之二（64%）的项目显著超出成本估算。
  • 功能浪费：产品中包含的功能中，有64%很少或从未被使用。
  • 时间延误：项目平均超出计划时间100%。

这些数据表明，项目经理在规划时需要重点关注客户需求、团队技能以及行业变化，并利用历史数据、自动化工具和最佳实践进行科学预测。

敏捷规划的核心：缩短反馈循环

如果反馈循环保持简短，那么“计划-执行-检查-行动”（PDCA）的周期就能更早完成，从而创造价值并使项目更加敏捷。反馈循环越短，对项目越有利。

反馈循环涉及需求澄清、开发、测试和部署等一系列快速连续的活动。通过多次冲刺迭代和发布，敏捷项目能够实现更灵活的规划。

敏捷规划方法与实践

基于对敏捷四大核心价值的理解，我们可以关注敏捷团队在实践中的工作方式。这些价值共同导向了高度迭代和增量的软件开发过程。

以下是敏捷团队工作的主要方式：

  • 作为一个团队工作：团队紧密协作。
  • 短周期迭代：工作在短的迭代周期内进行。
  • 每次迭代交付成果：每个迭代结束时都交付可工作的、经过测试的软件。
  • 聚焦业务优先级：工作重点始终围绕最高业务价值。
  • 检视与调整：定期回顾并调整工作方式。

多层次规划：发布、迭代与每日

一个项目如果规划远超规划者的视野，并且没有留出时间让规划者抬头审视新情况并做出调整，那么它就会面临风险。敏捷团队通过三个不同的时间层面进行规划来应对此风险。

这三个规划层面是：发布、迭代和当前日。大多数敏捷团队只关注这三个层面的规划。

  • 发布规划：考虑为产品或系统的新版本开发哪些用户故事或主题。其目标是确定项目范围、进度和资源的合理方案。发布规划在项目开始时进行，并会在整个项目期间（通常在每次迭代开始时）持续更新。
  • 迭代规划：在每个迭代开始时进行。产品负责人根据刚完成的迭代成果，确定团队在新迭代中应处理的高优先级工作。由于视野比发布规划更近，迭代规划会讨论将功能需求转化为可工作、可测试软件所需的具体任务。
  • 每日规划：大多数敏捷团队使用每日站会来协调工作，同步每日努力。团队在会议中明确并修订他们的计划，将规划视野限定在下次会议之前。

通过在这三个时间层面（发布、迭代、每日）进行规划，敏捷团队能够聚焦于可见且重要的内容进行规划。

图表展示了随着时间推移，团队互动的层次。开始时互动频繁，随后逐渐减少。较大的波峰代表发布层面的集中互动，而较小的波峰则代表迭代期间的互动。

本节课中我们一起学习了敏捷项目管理中规划的关键作用。我们了解了项目失败的常见数据、缩短反馈循环的重要性、敏捷团队的工作实践，以及通过发布、迭代和每日三个层面进行渐进式规划的方法。有效的敏捷规划是动态、聚焦且适应变化的，是项目成功交付价值的基石。

047：最后一刻规划的优势 🎯

在本节课中，我们将探讨敏捷规划中的一种特定方法——“最后一刻规划”，并分析其相对于传统前期规划的优势。我们将了解这种方法如何帮助团队更清晰地定义项目愿景、交付物和用户故事。

概述

上一节我们介绍了不同的规划方法。本节中，我们来详细看看“在最后一刻进行规划”这一具体方法。

“最后一刻规划”指的是在“最后责任时刻”进行规划。当团队在最后责任时刻进行规划时，能够获得对整个项目的清晰愿景。

最后一刻规划的核心优势

以下是采用最后一刻规划方法所带来的主要好处。

  • 项目全景更清晰：最终的目标、交付物、预期用途、法规要求和可能的测试方案等元素都会变得更加明确和清晰，对项目团队可见。
  • 定义发布周期：团队可以在制作发布版本时，以确定的间隔为接下来的两个发布定义发布日期。
  • 持续聚焦价值交付：团队始终专注于向客户交付可发布的工作成果、价值或最小可市场化功能（MMF）。

如何管理功能与发布

这种方法有助于为当前发布定义最小可市场化功能，并将其他功能安排到未来的发布中。

因此，最后一刻规划通过交付最小可市场化功能的方式为客户提供价值，同时也能将未包含在近期发布（如发布一和发布二）中的其他功能，妥善安排到发布三和发布四中。

用户故事与迭代准备

这种方法还有助于定义当前发布的所有用户故事。因为你在最后一刻进行规划，所以能获得用户故事，并进一步尝试为其添加细节、做好备注。

从为开发进行估算的角度来看，用户故事已准备就绪。对当前迭代和下一次迭代的故事进行优先级排序也成为可能。

需求细化与验收测试

由于你正在进行最后一刻的责任规划，可以为当前迭代中的故事明确详细的需求和验收测试。

通过与客户互动，需求得以详细展开，同时你也能获得验收测试的输入信息，从而全面理解当前的迭代和发布。

计划与资源配置

团队可以明确计划与资源。你知道团队以及软件开发所需的工具都是可用的。

总结

本节课我们一起学习了“最后一刻规划”在敏捷实践中的优势。我们看到，这种方法通过延迟决策，使团队能基于更清晰、更完整的项目信息来规划工作，从而更有效地定义范围、排列优先级，并持续专注于向客户交付最大价值。

048：时间盒 📦

在本节课中，我们将要学习敏捷实践中的一个核心概念——时间盒。我们将了解它的定义、作用原理，以及它如何帮助团队聚焦并提升生产力。

什么是时间盒？⏳

时间盒是指为整体开发工作设定固定的时间限制，并让其他特性（如范围）随之灵活变动。

在敏捷开发中，时间被视为一个固定约束。其原则是在固定的时间内，交付最优的功能特性。与传统项目不同，传统项目会获得交付产品所需的全部时间，而敏捷的焦点在于利用可用时间持续交付产品。因此，范围是动态的，可以根据团队的速度、故事点或理想日期进行调整。

为何要使用时间盒？🎯

时间盒之所以重要，是因为它能带来聚焦。以下是使用时间盒的几个关键原因：

  1. 带来高度聚焦：团队明确知道他们拥有有限的时间和资源进行交付，他们的焦点始终是向客户交付最小可上市功能以创造价值。
  2. 提升生产力：由于整个项目环境都导向创造价值，时间限制带来的同侪压力有助于提高团队的生产力。
  3. 实现时间价值：时间是项目的宝贵资源。时间盒促使团队合理利用时间，努力为客户交付价值。
  4. 鼓励创新与创造：在有限的时间内，团队需要专注于创造性的工作，为客户创造价值。

敏捷团队的规划层级 🗺️

上一节我们介绍了时间盒的概念与目的，本节中我们来看看敏捷团队如何在实际规划中应用时间盒。大多数敏捷团队主要关注三个最核心的规划层级。

以下是这三个核心规划层级：

  • 版本规划：决定即将发布的内容，例如发布1、发布2，剩余的特性则进入发布3、发布4的待办列表。
  • 迭代规划：为了交付某个版本（如发布1），团队会进行迭代规划，尝试选取相关的主题进行开发。
  • 每日规划：在更细粒度上，团队进行每日规划，确保工作持续向前推进。

总结 📝

本节课中我们一起学习了敏捷实践中的时间盒。我们了解到，时间盒通过设定固定时间限制来约束项目，迫使团队聚焦于在有限时间内交付最大价值。它不仅能提升团队的生产力和专注度，还能强化时间作为宝贵资源的意识，并鼓励创造性工作。最后，我们看到了时间盒思想在敏捷团队版本规划、迭代规划和每日规划这三个核心层级中的具体体现。

posted @ 2026-03-29 09:13  绝不原创的飞龙  阅读(2)  评论(0)    收藏  举报