敏捷软件开发:原则-敏捷开发 瀑布开发

至此，我们就可以进入产品开发（生产）阶段了。

在工业领域，MVP开发一般在实验室或研究中心完成。 经过测试验证后，按照产品文件标准在特定工厂进行批量生产。

实物产品在量产过程中遵循“精益管理”的思想。 精益管理要求在企业的一切活动中运用“精益思想”。 “精益思想”的核心是投入最小的资源，包括人力、设备、资金、材料、时间和空间，按时创造尽可能多的价值，为客户提供新的产品和及时的服务。

精益管理的目标可以概括为：在为顾客提供满意的产品和服务的同时，将浪费降到最低。

企业生产活动中存在很多浪费现象，常见的有：

努力消除这些浪费是精益管理最重要的内容。

由于我在实体产品规模化生产领域缺乏实战经验，这里就不多说了。 在互联网领域，精益思想同样适用，在敏捷开发中得到充分体现。

在本节中，我将重点讲解敏捷开发的本质，以帮助互联网/软件产品经理提高客户满意度、降低成本、提高质量、加快流程和提高资本投入，从而实现组织社会价值的最大化。 .

1. 敏捷开发宣言

敏捷开发以用户需求的演化为核心，采用迭代、循序渐进的方式进行产品开发。 在敏捷开发中，产品项目在建设初期被划分为多个子产品，每个子产品的结果都经过测试，具有可视化、集成化、可操作化的特点。

换言之，就是将一个大产品拆分成多个相互关联但又可以独立运作的小产品模块或功能，分别完成，产品在这个过程中始终处于可用状态。

2001 年，17 位敏捷方法论的倡导者和支持者聚集在犹他州的雪鸟滑雪胜地，起草了一份说明敏捷组织原则的文件。 本文档基本上代表了不同敏捷方法的共同点。 我们称之为“敏捷宣传”，又称敏捷软件开发宣言。 它指导以人为中心的迭代软件开发方法。 具体的四个核心值如图5 -14所示。

图5-14 敏捷开发推广

1. 个人和交互优于流程和工具

项目是通过人来完成的，流程和工具可以帮助人，但永远不会自己完成工作。

虽然流程和工具是好东西，但它们有时也会成为障碍。 面对面的直接沟通比一些程序性的文件和工具沟通要高效得多。

当然，最好是将多方沟通达成的共识形成一个简短的文件。

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

可用软件的价值很重要，因为软件是支持业务目标的东西，它是为客户提供高价值的可用软件（而不是文件）。

通常，敏捷项目的进度是通过开发了多少可用软件来跟踪和报告的。 但这并不是说文档没有用。 在大多数项目中，适量的文档是有益且必要的。

敏捷通过寻找“恰到好处”的文档来避免这种情况。 原则是任何文档的创建都应与为客户创造的价值直接相关，无论该价值反映在现在还是将来。

3. 合同谈判中的客户合作

这一价值的核心是尽可能贴近您的客户。 客户最清楚自己想要什么，甚至指定需求的过程也需要反复试验。 在合同谈判中试图避免所有的反复试验是不现实和徒劳的。

定位您与客户的关系很重要，您是选择与客户抗争，还是选择与客户合作制定对所有人都有利的方法解决方案？ 敏捷团队更愿意朝着与客户相同的方向工作，而不是背离客户。

4. 响应变化高于遵循计划

任何从事过软件项目的人都知道，这些项目的本质就是变化。 就连底层技术也在日新月异，不断开辟新的途径和可能性。 对变化的反应速度决定了您在市场上的灵活性。 如果你遵守规则，你就会被市场甩在后面。 你永远会比市场慢半拍，你的市场会慢慢被蚕食掉。

当你阅读这个宣言时，你会发现它是最高原则的，因为敏捷方法论在最高层次上是一致的，但每个方法在具体细节上是不同的。 除了敏捷宣言之外，还有 12 条原则的支持文档，这些文档为敏捷宣言提供了更多扩展细节。

原则一

我们的最高目标是通过尽早和持续交付有价值的软件来满足我们的客户。 敏捷团队可以快速向客户交付可用的软件，并且开放快速更新，为客户带来最高优先级的价值。

原则二

欢迎提出需求变更，即使是在项目开发的后期； 善于利用需求变更帮助客户获得竞争优势。

传统项目管理的一个原则是试图影响和控制引起变化的因素。 敏捷项目管理预计需求会发生变化并实际接受这些变化，即使它们发生在项目的后期。

快速响应和适应变化可以为客户带来显着的竞争优势，以应对新的机遇。

原则 3

持续交付工作软件的周期时间可以从几周到几个月不等，而且越短越好。

不同的敏捷方法论使用不同的迭代周期，但都比较短。 关键是要快速向客户交付可用的软件，并使用该软件获得有意义的回报。 较短的迭代周期让团队专注于客户价值。

原则 4

在项目过程中，业务人员、产品经理和开发人员必须在一起。 敏捷的项目管理，让业务人员、产品经理和开发人员彼此靠近，并且经常在同一个地方一起工作。

这样，业务人员和开发人员之间就没有隔阂，因为业务人员和开发人员的共同目标是通过可用的软件向客户交付价值。

原则 5

善于激励项目人员，为他们提供所需的环境和支持，相信他们能把事情做好。

传统的项目管理往往对员工进行微观管理，不仅告诉他们做什么，还告诉他们怎么做，无意中形成了一种自上而下的管理方式。

敏捷项目建立一个强大的团队并积极避免微观管理，需要一个自律的团队，自发地告诉开发人员该做什么。 提供相关资源，给予鼓励，信任团队完成任务。

原则 6

无论是团队内部还是团队之间，最有效的沟通方式就是面对面的交谈。 在敏捷项目管理中，非正式的口头交流比正式的书面交流更为普遍。 这个想法是，与来回发送电子邮件或交换文件相比，两个人坐在一起制定解决方案效率更高。

面对面的沟通是敏捷项目管理的精髓。 这种交流是公开的，任何团队成员都可以自由参与对话。

原则 7

可用软件是进度的主要衡量标准。 计划和文件可能有用，但当基本目标发生变化时，它们可能会失去价值。

传统项目往往极其纠结，项目的不断更新让文件成为一种负担。 真正的价值是通过结果来表达的，而结果又是通过可用的软件来表达的。

原则 8

敏捷流程促进可持续发展。 项目方、开发人员和用户应该能够保持持续稳定的进度。

可持续发展的重点是团队，团队将努力保持稳定和可持续的进度，使团队成员在迭代周期结束时不至于仓促行事。

理想的目标是保持可持续的步伐，这样团队成员就不会感到过度的压力和倦怠，但能够保持理想的工作强度。

原则 9

技术的改进和设计的不断改进将提高敏捷性。 设计越好，越容易维护，即使有变化，稳定的高质量项目也比低质量的项目更能让团队快速响应变化。

准则 10

简明扼要，就是尽量减少不必要的工作。 这是一门艺术，被所有敏捷方法所接受，尤其是精益方法。 关键点是保持对客户价值的关注，毫不犹豫地削减不增加价值的活动。 保持简单不仅是一种愿望，而且是一项基本原则。

准则 11

最好的架构、需求和设计来自自组织团队。

自组织是敏捷团队的核心要素之一。 当一个团队是自组织的时，这意味着团队自己决定如何分配工作以及由谁来做特定的工作，而不是人力资源或管理层。 不仅小团队可以自组织，更大的跨职能团队也可以自组织。

准则 12

团队有责任定期反思如何才能更有效，并相应地调整团队的行为。

敏捷项目中最可预测的事情是变化。 在传统项目中，最常见的是在项目或阶段完成时开会总结，而敏捷则试图通过更频繁的回顾来完成这项工作。 在回顾中，团队查看每次迭代中完成的工作或发布，并评估下一次如何改进他们的实践。 每日站立会议——每天开会 15 分钟——是协调团队努力、团队自我评估和自我调节的另一种重要方式。

敏捷开发的业务目标是尽早交付价值。 价值的传递不仅仅是早晚两天上线的问题，而是早点上线能为自己和客户带来更大的价值。 交货越晚，价值越低。 更快不是绝对的速度，而是更早的时间，也就是通过迭代交付，批量交付，更早交付。

同时灵活应对变化。 当今世界，越界颠覆的案例数不胜数。 企业的核心竞争力不再是现有能力有多强，而是能否灵活应对变化、快速学习。

注意：在新产品开发中使用敏捷时，必须考虑整体价值的交付。 这种交付是可以交付给用户的交付，是面向市场的交付。

我曾经遇到过一个创业团队，花了一年半的时间，迭代了26个版本，还是没有完成用户交付，没有把产品推向市场。 这种悲剧应该尽量避免。 使用最小可行产品（MVP）方法可以有效避免这种情况的发生。

2. Scrum敏捷开发

在敏捷实践体系中，迭代交付模型是敏捷开发的核心要素。

敏捷开发方法有很多种，Scrum提供了迭代管理和持续改进的框架，如图5-15所示。 Scrum中的主要角色包括类似于负责维护流程和任务的项目经理的Scrum Master角色，代表利益相关者的产品负责人，以及包括所有开发人员在内的开发团队。

图 5-15 Scrum 敏捷开发流程

Scrum 是一个过程框架（一种过程、计划、模式，用于高效地开发软件），包括一系列实践和预定义的角色。

Scrum 最大的特点是灵活的增量交付，这需要团队之间开放的沟通和协作。 首先，产品经理收集整理需求，然后与开发团队确定开发清单，然后进入开发冲刺状态，随后是日常会议和后期改进。 在实际应用中，我们通常将其分为以下5个步骤。

1. 第 1 步：创建用户需求列表

产品的需求可能来自客户、团队或产品经理的想法。 这些要求的描述必须满足：作为 ______，我希望 ______ 来完成 ______。 这样做的好处是让整个团队更容易理解需求并达成共识。 图 5-16 显示了一个例子。

图5-16 用户需求列表（产品功能需求）

2. 第二步：召开规划会议，制定发展规划（规划版）

Scrum Master 负责组织计划会议。 产品经理和团队会根据需求的重要性和开发量确定开发优先级，进行工作量预估，制定迭代开发计划（从需求列表中选择高优先级的故事（用户需求）为目标这次迭代。

这个目标的时间周期是1到4周，然后细化Story形成Sprint Backlog（迭代待办事项）。

一旦开发团队接受了这些开发任务，他们应该在不修改交付标准的情况下按时完成。

3. 第 3 步：执行迭代计划（任务板）

首先，你需要确定每个Sprint（开发冲刺）的周期。 较短的周期可以更频繁地发布产品版本，因此您可以更快地收到客户的反馈并修复错误。

这个时期一般为1至4周。 当然，你可以根据团队的成熟度或迭代任务，确定一个合适的迭代周期，比如2周，让开发人员更加专注地工作。

所谓冲刺，就是在一定时间内全身心投入开发。 在这个阶段，通常使用看板来管理需求。 每张卡片都是一项开发任务。 工作完成后，可以把卡片移到下一阶段，用看板来管理需求。

如图5-17所示： 也可以使用专门的软件来管理看板，比如国外的Jira，国内的明道。

图 5-17 敏捷开发项目管理仪表盘

在冲刺中的每一天，都有一个项目状态会议，称为“每日站会”。 会议在固定地点和每天同一时间举行，团队经常对迟到者进行处罚（例如罚款、俯卧撑和在脖子上挂橡皮鸡玩具）。

无论团队规模大小，会议都限制在 15 分钟以内。 所有与会者都应起立，每个人都必须发言。

会议的目的是讨论当前任务的状态。 推荐的汇报形式是：我昨天做了什么？ 接下来我要做什么？ 你现在遇到什么障碍和问题？

请注意，团队成员不需要在会议期间讨论每个问题。 它仅用作重要信息的反馈渠道。 有关具体问题的委员可在会后当面交流。 这样效率更高，避免浪费无关成员的时间。

4. 第四步：产品测试与演示

因为每个 Sprint 的目标都是交付可用的产品功能，所以测试非常重要。

减少测试周期的方法有很多，比如可以减少需求数量，或者让开发参与测试。

当一个Story完成后，也就是Sprint Backlog完成，也就是一个Sprint完成了。 在这一点上，我们有一个演示会议，也称为审查会议。

产品负责人和客户都要参加（最好公司老板也参加），Scrum团队的每个成员都要向他们展示自己完成的软件产品（这个会议很重要，一定不能取消）。

5. 第 5 步：回顾会议和下一个 Sprint 计划

每次冲刺后，召开冲刺回顾会议。

回顾会议也称为总结会议。 会议时间限定为4小时，以轮流发言的方式进行。 一轮 Sprint 计划。

3. Sprint冲刺会

Sprint 计划是 Scrum 中的一个事件。 Sprint 计划的目的是定义 Sprint 中可以交付的内容以及如何完成该工作。

Sprint 计划由整个 Scrum 团队协作完成。 与体育世界不同，Scrum 鼓励始终全速前进，以便在不断学习和改进的同时交付可工作的软件。

在Scrum中，一个Sprint是一个固定的时间段，所有的工作都完成了，也就是一个迭代周期。 在采取行动之前，必须设定冲刺时间，您需要决定时间间隔的长短、冲刺的目标以及从哪里开始。

冲刺计划会议通过设置议程和优先级来启动冲刺。 如果做得正确，它还会为团队创造动力并提供成功的环境。 糟糕的冲刺计划会通过设定不切实际的期望来破坏团队。

为了保证sprint的顺利进行，flush计划中包含了几个会议来支持sprint流程，如图5-18所示。

图 5-18 Sprint 计划包括会议

举办一场伟大的冲刺计划活动需要一些纪律。 产品负责人必须结合从以前的 Sprint 评审中吸取的教训、利益相关者的反馈以及他们对产品的愿景来为 Sprint 做准备。

为了提高透明度，产品待办列表应该是最新的并且细化以提供清晰度。

Backlog 细分在 Scrum 中是一个可选事件，因为有些 Backlog 不需要它。 然而，对于大多数团队来说，最好让团队在 Sprint Planning 之前一起审查和完善 Backlog。

进入 Sprint 计划的一个很好的起点是 Product Backlog，因为它提供了可能成为当前 Sprint 一部分的“内容”列表。 团队还应该查看增量完成的现有工作并查看容量。

输出 Sprint 计划会议的最重要成果是团队可以描述 Sprint 的目标以及他们将如何开始朝着这个目标努力。 这在 Sprint Backlog 中是可见的。

Sprint 计划应限制在每周不超过两个小时。 因此，例如，为期两周的 Sprint 计划会议不会超过两个小时。 这被称为“时间限制”，或者为团队完成一项任务设置最长时间，在本例中为计划冲刺。

Scrum Master（敏捷教练）负责确保了解会议时间。 如果团队在时间范围内完成之前很高兴，那么活动就结束了。 时间范围是允许的最长时间，没有最短时间限制。

在制定冲刺计划的过程中，很容易“卡壳”，把注意力集中在应该先完成哪项任务、由谁来完成、需要多长时间。

对于复杂的工作，您开始的信息水平可能很低，而且大部分信息都基于假设。 Scrum 是一个经验过程，这意味着您不需要提前计划，而是边做边学。

Sprint 计划需要一定程度的评估。 团队需要定义 Sprint 中可以做什么和不能做什么： 估计团队可以承受的工作量和能力。

良好的评估需要一个基于信任的环境，在该环境中可以免费获得信息，并在此过程中讨论假设。 如果在评估中以消极的、对抗的方式进行工作，那么很可能评估的工作量会很大，造成不必要的资源浪费。

人们很容易陷入 sprint 计划的细节，而忘记 sprint 计划的重点是为下一个 sprint 建立一个“恰到好处”的计划。 该计划不应该成为团队的背后捅刀子的机器，相反，它应该将团队的注意力集中在有价值的结果上，并为组织提供保护。

Scrum 的一个关键原则是认识到客户可以在项目过程中改变他们的想法和改变他们的需求，而预测和计划方法不能轻易地解决这种不可预见的需求变化。

同样，Scrum 采用经验方法——承认需求无法被完全理解或定义，因此专注于如何使开发团队能够快速响应新出现的需求。

4.积压用户故事

Sprint 目标在较高层次上描述了 Sprint 的目标敏捷软件开发:原则，但也可以在编写 Backlog 用户故事条目时反映出来。

为了切身了解客户的需求，一些产品设计营销和研发团队尝试采用基于客户情境的脚本引导设计方法，通过观察客户、讲故事、写脚本、再现客户情境等方式来沟通和传达客户需求。和经验。 利用人的内心思维和语言表达的基本能力编故事讲故事，将设计人员和产品开发人员带入产品使用的情境中。 通过这种情境故事，让设计师分享与产品设计相关的信息自我内化吸收，转化为团队交流。

用户故事是从客户的角度描述工作的好方法，如图 5-19 所示。 用户描述将缺陷、问题和改进重新集中在客户寻求的结果上，而不是观察到的问题上。 通过向用户故事添加清晰、可衡量的结果，您可以评估何时完成。

图 5-19 示例用户故事

项目中不同的参与者有不同的需求，产品经理想要跟踪进度，开发人员想要实现，产品经理想要功能，产品老板有更高的视角，而用户想要一个可用的系统，在这些相互冲突的视角中，是很很难做出一个大家都支持和满意的决定，并保持一个恒定的平衡。

整个项目组就像一辆四驱车。 一个字的强度就相当于一个轮子转得太快，对产品来说是一种损失，导致汽车的方向偏离。

通过共同构建产品的全景图敏捷软件开发:原则，让项目组的每一个人，包括用户，站在高处俯视产品。 这种在同一个空间的多点对多点的共识自然就完成了。

通过这种一目了然、格式一致的故事地图，项目组中的每个人都可以获得足够的信息，从而使项目的开发过程清晰明了，如图5-20所示。

用户故事地图作为一种有效的需求工具，可以实现多角色、多视角。

通过合作沟通，全面了解用户需求。 涉及的主题包括如何以故事地图的形式描述用户需求，以及如何分解和优化需求。 如果通过团队合作积极吸取教训，洞察用户需求，开发出真正有价值的、小而美的产品和服务。

图 5-20 用户故事地图示例

用户故事地图是让用户参与设计他们想要的产品的便捷方式。 我们原型阶段的所有内容都来自于用户故事地图，因为故事地图是用户全程参与，所以我们整个设计过程中都有用户。

参与式设计的对立面是体验式设计。

在设计新产品时，体验式设计在前期高度依赖用户研究，包括用户访谈和用户观察，但用户不会成为产品设计的真正参与者。 后期基本靠设计师经验，几乎没有用户。 .

但参与式设计“用户故事地图”，让用户以简洁明了的方式参与其中，还原场景。 每个用户故事都是站在用户的角度来做的，让大家可以快速的知道用户想要什么，为什么要。

用户故事易于阅读和理解。 我们边讲故事边绘制页面框架，这样可以激发用户的积极性，成为产品设计的参与者。

同时，随着用户逐渐掌握如何通过故事来口头描述自己的需求，项目组成员与用户之间的关系也变得更加亲密和主动，这种良性循环让每个人都受益。

思考：过去，我们有两种方式来达成用户/产品需求。 一是文件。 当你打开它们，那些格式化的语言就变成了世界上最好的摇篮曲。 如果读成这样，写它的人会怎么样呢？ 写文档的产品经理心里肯定会有一个疑问：“这东西写的认真吗？”

有文档看就好，有的产品经理会直接跟团队成员聊天，写用户故事地图，就算需求交出来，你觉得这两种方式哪个更敏捷有效？ 这里的共识是点对点，或者点对多点，信息传递也会带来信息内容的丢失，甚至是错误的信息。