敏捷管理（一）——什么是敏捷开发？为什么要采用敏捷？

为什么要提倡敏捷？

从20世纪50年代到90年代，满足沟通场景和信息交换场景的基本条件并不能让人们像今天（2021年）那样通过屏幕看到彼此的面部表情。

市场信息交流不频繁。用今天的眼光来看，当时的商业环境进步极其缓慢。公司从信息发布到实施可能需要几个月的时间。在那个时候，领导者具有前瞻性的眼光非常重要。要求比今天高得多。这并不意味着当今的商业环境不需要前瞻性的观点。

与20世纪50年代至90年代的商业环境相比，如今的商业环境发生了翻天覆地的变化，通信基础设施使得金钱绕地球一圈仅需8秒。人们可以随时开始视频会议。只需打开通信设备即可将决策传达到底层。

如今，人们接收到的信息越来越多。他们的思想和思维每天都会受到这些信息的影响，他们下一步的行动也可能会受到这些信息的影响。整个商业环境每天都在快速变化。这迫使公司更快地做出决策并更快地将新产品推向市场。

每个管理者、每个企业家都知道，一旦公司规模变大、员工增多，就很难快速推出新产品。就像篮球运动员的身体发育一样。如果你退休并停止打篮球，你的体重就会很容易增加。一旦体重增加，你的运动速度就会减慢。即使这位运动员想要重返比赛，也必须重新训练腰、腿、手等部位，注意每个部位。那么企业能否像想要重返赛场的运动员一样，简化团队、小步快跑来实现这种拉动呢？拍摄时（新产品），身体可以快速、华丽、敏捷地参与。

什么是敏捷？

相信无数学过敏捷或者读过敏捷书籍的朋友心里都会有这个疑问。什么是敏捷？敏捷意味着什么？这个问题没有标准答案，因为每种管理方法都是根据不同企业的发展和企业文化量身定制的。

敏捷是基于这样一个事实：在当前的商业环境中，客户对价值交付的要求变得越来越迫切。敏捷技术和方法将有效管理各种颠覆性技术，特别是新的设计，以前没有做过的工作是探索性的。随着可确定的工作日益自动化，项目团队也变得越来越多。从事高度不确定的工作。

此外，敏捷的第一原则将客户满意度作为最高要求。为了保持竞争优势并与时俱进，组织不仅要关注内部，还要放眼外部，关注客户体验。

小型组织和初创公司能够更快地生产满足客户需求的产品。不断变化的商业环境将继续推动大公司采用敏捷思维，以保持竞争力并维持现有的市场份额。

总结：为了在短时间内探索可行性，并根据评估和反馈快速调整，大公司在这次调整过程中通过拆散、大团队变小团队来实现小步快跑。

敏捷的优点

团队成员有更强的成就感和归属感。

更快地将产品投入市场，产品价值能尽快得到市场的验证和修正。

敏捷的缺点

需求的同步开发带来了返工的风险。

为了避免跳槽时效率下降（20%~40%），要求团队成员尽可能具备全栈技能，俗称T型人才。

项目生命周期类型

类型

描述

场景

预测生命周期

（瀑布流）

前期确定项目范围、时间和成本，假设目标和要求明确且不变。

目标明确，需求明确且不变。

一次性交付，行业基础扎实。

增量生命周期

总体目标是明确的。

每次下周期交付的模块都会根据市场情况进行重新调整

管理进度风险。

处理小的需求变更，但难以处理影响架构的变更。

迭代生命周期

总体目标不明确

渐进细化、反复细化

管理技术风险。

不断变化的需求。

敏捷生命周期

（适应）

它结合了迭代和增量，旨在应对大量变化。迭代周期比迭代和增量的生命周期短，大约2到4周。

环境快速变化。

要求和范围很难确定。

适合定义较小的增量改进。

每个项目都有自己的生命周期类型。传统的生命周期是预测生命周期，也称为瀑布生命周期。我们每次开发的时候，都假设目标明确，需求明确，并且需求不会改变。

增量生命周期：前期定义电商产品，规划中分为直通车模块、购物车模块、活动场地模块。刚发布的时候就发布了直通车模块。原本购物车模块是要在下一个版本中发布的，但根据市场反馈，假期即将到来，拥有活动场地可以更好地吸引用户。所以在下一个版本中，将会发布活动场地模块。整体顺序为直通车模块、活动场地模块、购物车模块。

迭代生命周期：可以帮助创建团队交付和反馈的节奏，团队将为交付和反馈创建增量。

敏捷生命周期：

摘要： 每个生命周期都有自己的特点。在大多数实际情况下，生命周期的使用是根据不同的实现环境进行组合的。例如，早期设计时采用瀑布流周期，项目开发过程中采用敏捷生命周期。当大多数公司从传统的项目管理过渡到敏捷时，他们通常会经历一个增量生命周期。

敏捷核心理念 敏捷价值观

1、个体交互高于流程工具：项目执行者永远是人，人是项目的核心。有优秀的成员，但是如果没有好的流程来控制，优秀的成员做事就会像没有头一样。苍蝇终于感到灰心丧气了。如今，竞争变得越来越激烈。企业还是需要规则和流程。这并不意味着他们不需要流程。过程中如果没有良好的沟通，就无法更好地促进项目的成功，甚至可能会失败。

2、可用的软件高于完整的文档：看得见、摸得着的高质量软件（工作成果）对每个人来说都是有价值的。如果是看不见、摸不着的，谁会相信言语呢？ 。在产生工作成果的过程中，如果没有文档，那将是一场灾难。只有完成工作的人才知道工作的结果。敏捷还需要文档，强调轻量级、高价值的文档，例如每天更改为每周。

3.客户合作高于合同谈判：大多数公司与客户协商软件的价格，然后客户扔下一笔钱。之后，他们等到所有工作完成后，才与客户沟通并交付。得到的产品不好。满足客户的期望。与客户保持经常沟通，每个里程碑完成后与客户进行沟通和确认，及时发现并改进问题，而不是等客户发现后再进行更改。如果问题被客户发现，客户会产生不信任，甚至可能随意修改。

4、应对变化胜于遵循计划：敏捷并不意味着不需要计划，而是需要更多的计划和计划，并试图在可控的时间范围内控制不确定性。毕竟，减少不确定性的唯一方法就是通过做某件事或者模拟来获得反馈，并根据反馈不断调整计划，即计划-执行-调整，这有点类似于戴明圈的PDCA。

敏捷原则

1、目的：尽早持续交付有价值的软件，满足客户需求，从而让客户满意。

2、态度：敏捷变革提倡价值变革，因此欢迎需求变革。

3. 专注于：尽早并经常交付可用的软件。

4、合作：业务与开发共同推开信息孤岛的围墙。

5、核心：人是项目的核心。激励项目人员是基于所需的环境和支持。

6.沟通：尝试面对面沟通。

7. 标准：可用的软件是衡量的首要标准。

8、倡导：敏捷不提倡加班，而是始终保持稳定的节奏。急功近利很容易让团队陷入崩溃的状态。

9、追求：持续关注和改进优秀的技术和设计，提高项目敏捷性。

10. 基本原则：尽量减少不必要的工作。如果能够用最简单的方式实现需求是最好的。重构是在实现新需求的过程中随时清除冗余代码、重构，防止系统混乱的重要途径。

11.团队：最好的架构、需求和设计来自于自组织团队。整个团队分担责任，任务以团队为基础进行分配。

12、调整：团队定期反思、回顾、总结经验。如果在项目结束时进行总结，经验的总结不会立即给组织或项目带来实际帮助。相反，通过随时总结，团队成员就会认识到问题，并推动自己采取行动解决问题。

敏捷宪章

项目章程：您可以了解项目为何重要、团队前进的方向以及项目的目标。帮助团队学习如何围绕项目一起工作和协作。至少，团队还需要一个项目愿景和目标。为什么要做这个项目？谁将从中受益？如何受益？必须满足什么条件才算项目完成？我们将如何合作？

团队章程：团队价值观、可持续发展速度和核心工作时间；工作协议、时间范围、完整性和工作流程限制；基本规则、会议发言规则；团队规范，对待会议时间。

主流敏捷方法论

项目是关于完成确定的工作和不确定的工作。传统的软件开发模型和瀑布模型认为所有工作都是恒定的，变更的识别被推迟到最终的测试或用户使用阶段。反馈周期很长，大大增加了返工或变更的成本。由此可见传统软件开发的官僚、缓慢、巨大的问题。

敏捷通过短周期迭代快速响应和适应变化，并尽早交付可用的迭代。

极限编程 (XP)

极限编程是 Kent Baker 在 1996 年提出的。

XP核心价值观

简单：从最简单的开始，通过不断的重构达到最好的效果。

沟通：鼓励定期的口头沟通和反馈。

反馈：系统反馈（测试单位）、客户反馈、团队反馈。同时，编程中的乐观主义是危险的，及时反馈才是解决之道。

勇气：只为今天的需要编写代码，而不考虑明天。这是为了避免陷入设计困境并在其他问题上花费过多不必要的精力，并知道何时丢弃现有代码。

尊重：团队成员中，每个人都确保提交的更改不会导致编译失败，或导致现有测试用例失败。坚持追求高品质，坚持通过重构寻找手头工作的最佳解决方案。

XP 生命周期

在 XP 中，轻量级需求称为用户故事，通常用于发布和冲刺计划。

典型的冲刺持续 2 周：

1、本次冲刺期间，开发人员将采用结对编程的方式编写代码；

2、所有开发的软件都会经过严格、频繁的测试；

3、获得客户认可后才会小规模发布；

注：探针是降低风险的技术方法，整个发布过程中都会使用探针。示例包括学习新技术、评估、验收标准的定义以及通过产品了解用户行为的过程。

XP 核心实践

完整的团队：客户、开发人员、测试人员等都在同一个屋檐下工作。

规划游戏：需求分析是通过规划游戏来完成的。这个过程分为三个阶段：检测、分解需求；策划、制定和发布计划；调整，根据实际情况调整计划。

小版本：新版本在很短的周期内增量发布。体现了敏捷的特点。统一的软件开发流程强调冲刺开发。

共同所有权：所有代码都强调每个人都有责任。如果一个人的代码中出现错误，另一个人可以修复它。并执行严格的代码控制。

编码标准：没有统一的编码标准，代码的所有权共享是不可能的。

可持续的速度：强调以恒定的速度工作，不强调加班。

隐喻：隐喻常用于交流中以加快理解速度。

持续集成：及早发现并消除隐患，从而减少因引入重构和集体代码所有权而带来的问题之痛。

测试驱动开发：编写测试程序的时间越少，代码的效率和质量就越差，发现bug并解决它们的时间就越长。

重构：是一种在不影响功能实现的情况下改进代码的技术。

简单设计：认为设计部门应该在编码前完成一次，这只能建立在需求不会改变或者所有改变都可以预见的情况下。它必须能够通过所有测试程序，不包含任何重复代码，清楚地表达所有意图，并且具有尽可能少的类和方法。

结对编程：一个人写程序，另一个人坐着看，大大降低了沟通成本，提高了工作效率。至少有两个人熟悉代码，并且可以随时对代码进行审查，并可以消除不必要的差异。更好的沟通。

XP总结

XP核心价值观：简单；沟通;反馈;勇气;尊重;

XP 生命周期：用户故事、两周冲刺、结对编程、严格测试、小型发布。

XP 核心实践：完整的团队；策划游戏；小版本发布；共有所有权；编码标准；可持续速度；隐喻；持续集成；测试驱动开发；重构；

Scrum

Scrum源自美式橄榄球，每个队员都具有很强的进攻和防守能力。团队成员具有高度的自主权，比赛过程中密切沟通、配合，以高度的灵活性解决各种问题。

注：以下所有解释都将按照 Scrum 方法论进行解释。

Scrum 核心概念

透明度（）：在软件开发过程中保持各种环境的高度可见性。

检查（）：定期检查，总结经验，找出需要改进的地方。

Adapt（）：如果检查发现过程的一个或多个方面不符合验收标准，最终产品不合格，则必须进行调整，并且必须加快调整工作，以减少进一步的偏差。

Scrum团队组成

产品负责人

职责：获取市场信息，确定产品返还给企业，并在产品开发项目中及时反映市场需求。此外，PO是对产品开发项目拥有决策权的人。重新安排产品开发项目的优先顺序需要由PO统一，所有成员必须尊重PO的决定。

优先考虑产品开发项目的内容；

确保开发团队所做工作的价值；

确保开发团队对所要开发的产品内容有一定程度的了解；

Scrum（教练）

清晰地传达愿景。

提供食物和水。

消除团队成员的障碍，例如频繁、毫无意义的会议。

开发团队

自组织团队：没有人会告诉开发团队如何将产品待办事项转化为潜在可发布的功能，并且 Scrum 无法干扰他们决定要做的事情。

跨职能：团队拥有创造产品增量所需的所有技能。无论他们从事什么工作，他们都是开发人员。头衔不被认可，不包含测试、业务、分析等特定领域的团队，大家统称为成员。

团队规模：建议3-9人，5-9人最合适。

Scrum开发流程

1. PO从市场或客户处获取相关产品信息。

2. PO单独或与团队一起整理收集到的需求，以用户故事的形式整理需求。

3. 根据用户故事整理出的需求，对需求进行优先级排序，形成待开发产品清单（ ），并确定本次发布计划需要完成的工作内容。

4、PO、开发团队、SM等相关方共同召开冲刺计划会议。这次会议将持续4到8个小时。 PO 向开发团队介绍产品待办事项列表，并确保开发团队对这些工作达成共识。

5. 开发团队在 计划会议上选择一些用户故事，细化为任务作为本次 的目标，并形成 ( )。

6. 每轮冲刺()持续约2至4周。在()开始时，开发团队成员按照自己的意愿接收到他们想要做的任务。

7. 每天早上举行15分钟的每日站会（Daily Scrum）。每个团队成员将回答三个问题。昨天完成了什么？今天你打算做什么任务？你遇到过哪些障碍？

8. 本次冲刺完成后，将召开冲刺评审会议（ ），会议持续 2 至 4 小时。主要目的是向相关方展示已完成的产品功能并获取反馈。同时可以讨论和规划下一次迭代要做什么。

9. 召开冲刺评审会议（ ），持续 2 至 4 小时。总结哪些进展顺利需要维护，哪些需要改进，以便在下一个冲刺中进行改进。

10.本次迭代结束。

Scrum 活动或会议

短跑（）

冲刺是一个时间盒，持续约 2 到 4 周。

每个冲刺包括冲刺计划会议、每日站立会议、冲刺回顾会议和冲刺回顾会议。

冲刺计划会议 ( )

持续4到8小时，确定本次冲刺需要交付哪些产品功能以及如何实现目标。

PO 向团队介绍优先的产品开发项目，确保开发团队了解问题，并创建足够详细的计划以确保它们能够完成。

本次冲刺需要完成的未开发项目数量由开发团队自行决定，SM和PO都不能干预。开发团队有责任决定如何完成工作，而 PO 则有责任决定做什么。

开发团队根据完成的定义分为更小的单元，每个工作单元花费的时间不超过一天。 PO 可以留下来回答问题并澄清一些误解。

每日例会

持续 15 分钟会带来透明度、信任和更好的表现。

自上次每日站会以来取得了哪些成果？从现在到下一次每日站会，您计划完成什么？遇到了哪些障碍？

冲刺评审会议 ( )

持续2到4小时，展示本次冲刺完成的产品功能，并获得客户反馈和PO验收。

PO和团队也可以根据本次完成的产品功能做出相应的调整，并讨论剩余的产品开发项目（本次未完成或下一阶段将完成的产品开发项目），以及计划在下一步完成的工作。

冲刺回顾 ( )

持续时间不应超过3小时。总结哪些地方做得好、需要维护，哪些地方需要改进，以便在下一个冲刺中进行改进。

Scrum 工件

拟开发产品( )

包括业务功能和非业务功能（涉及技术、架构和工程实践等）、改进点和缺陷修复等。

产品开发项目需要不断改变，以确保优先级最合理、最有竞争力、最有价值。

Scrum 不考虑在要开发的产品内容上花费的工作时间。它只关心剩余工作和日期这两个变量。

冲刺要开发的项目 ( )

它是从要开发的产品的用户故事分解而来的一系列任务项。

会有一个实现本次冲刺目标的计划，将要开发的产品的特征点放入本次冲刺的固定周期中。

会因为两个方面而发生变化：首先，随着对需求的更好理解，一些新的任务可能需要添加到 中。其次，将缺陷添加为新任务，将其视为承诺的提交任务中未完成的工作。

通过持续跟踪冲刺中的剩余工作，开发团队可以管理自己的进度。

增量

一个冲刺完成后所有产品积压项目的总和，以及之前所有冲刺产生的增量值的总和。这些总数必须满足完成的定义并在每个冲刺结束时交付价值。

Scrum总结

Scrum 价值观； Scrum 原则；

Scrum团队由PO、SM和开发团队组成。

Scrum 开发流程。

Scrum 活动或会议包括冲刺计划会议、每次站立会议、冲刺审查会议和冲刺回顾。

Scrum 工件：产品积压、冲刺积压、增量。