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、调整：团队定期的反思、回顾、总结经验。项目结束时，才进行总结的话，在于总结经验不能立刻对组织或项目带来实际上的帮助。相反随时进行总结，团队成员们会认识到问题，并推动自己的行为来解决问题。
项目章程：就能了解项目之所以重要的原因、团队的前进方向以及项目的目标。帮助团队学习如何一起工作，怎样围绕项目协作。团队至少还需要项目愿景和目标。为什么要做这个项目？谁会从中受益？如何受益？达到哪些条件才意味着项目完成？我们将怎样合作？
团队章程：团队价值观，可持续的开发速度和核心工作时间；工作协议，时间盒、完整性和工作过程限制；基本规则，会议发言规定；团队规范，对待会议时间。
项目就是干已确定的工作和不确定的工作。传统的软件开发模型，瀑布模型是将所有工作都认为是不变的，识别变化延迟到最后的测试或用户使用阶段才发现，反馈周期很长，极大的增加了返工或变更成本。从而可以看到传统软件开发的官僚化，速度慢，庞大的问题。
敏捷通过短周期迭代，尽可能早的交付可用的迭代来快速响应和适应变更。
极限编程是肯特贝克1996年提出的。
简单：从最简单的入手，在通过不断重构来达到最好的效果。
沟通：鼓励经常性的口头交流与反馈。
反馈：系统的反馈（测试单元）、客户的反馈、小组的反馈。同时在编程中的乐观主义是危险的，而及时反馈则是解决它的问题。
勇气：只为今天的需求而编码，不要考虑明天。这是为了避免陷入设计泥潭而在其他问题上花费太多不必须要的精力，进而知道什么时候该丢弃现有的代码。
尊重：团队成员之间体现在每个人保证提交的如何改变不会导致编译无法通过，或者导致现有测试用例失败。坚持追求高质量，坚持通过重构的手段来为手头上的工作找到最好的解决涉及方案。
在XP中，轻量级的需求被叫做用户故事，通常用于发布和冲刺计划中。
典型冲刺有2周的时间：
1、在这冲刺期间开发人员会以结对编程的方式编写代码；
2、所有开发好的软件都会进行严格的而频繁的测试；
3、在获得客户认可之后，才会小规模的发布；
备注：探针是一种技术方法，是为了减少风险，并且探针会在整个发布中使用到。例如在学习新技术、评估、验收标准定义以及通过产品了解用户行为的流程中应用。
完整的团队：客户、开发人员、测试等都在一个场所下工作。
规划游戏：需求分析都是通过规划游戏完成的。这个过程分为三个阶段：探测，分解需求；计划，制定和发布计划；调整，根据实际情况调整计划。
小型发布：非常短的周期内以递增的方式发布新版本。体现了敏捷的特性。统一软件开发过程强调冲刺开发。
共同所有权：全部代码强调所有人都要负责，某个人的代码出现BUG，另一个人可以修复。并且执行严格的代码控制。
编码标准：如果没有统一的编码标准，代码共同所有权就无从谈起了。
可持续的速度：强调以恒定的速率进行工作，不强调加班。
隐喻：在沟通中常用比喻的方式，加速理解。
持续集成：及早的爆率并消除隐患，由于重构、集体代码所有权的引入，从而减少问题的痛苦。
测试驱动开发：越没有空写测试程序，代码的效率和质量就越差，花在找BUG，解决BUG的时间就越长。
重构：是一种对代码进行改进，而不影响功能实现的技术。
简单设计：认为设计部应该在编码之前一次性完成，那样只能建立在需求不会改变的或者可以预见所有的变化的基础上。并且要能够通过所有测试程序，没有包括任何重复的代码，清晰的表达带来所有意图，尽可能少的类和方法。
结对编程：一个人写程序，另一个人坐在一边看，大大的降低了沟通成本，提高了工作之类，代码至少有2个人熟悉，并且代码总是能评审过，还能够消除无谓分歧、更好的沟通。
XP核心价值观：简单；沟通；反馈；勇气；尊重；
XP生命周期：用户故事、2周冲刺、结对编程、严格测试、小规模发布。
XP核心实践：完整的团队；规划游戏；小型发布；共同所有权；编码标准；可持续的速度；隐喻；持续集成；测试驱动开发；重构；
Scrum来源于美式橄榄球，每个团队成员都具备很强的进攻和防范能力。团队成员具有高度自主权，在比赛中进行紧密的沟通合作，以高度弹性解决各种问题。
备注：接下来的所有讲解将按照Scrum的方法论进行讲解。
透明性（Transparency）：软件开发过程中各个环境保持高度的可见性。
检验（Inspection）：定期的检查并总结经验，发现改进地方。
适应（Adaptation）：如果检查发现过程中有一个或多个方面不满足验收标准，并且最终产品是不合格的，那么就要进行调整，调整工作必须加快实施，以减少进一步的偏差。
产品负责人（Product Owner）
职责：从市场获得信息，确定该产品对于企业的回报，并且及时将市场需求反映在产品待开发项中。并且PO对产品待开发项具有决策权的人，重新排列产品待开发项优先级需要得到PO的统一，所有成员都要尊重PO的决定。
对产品待开发项的内容进行优先级排序；
确保开发团队所执行工作的价值；
确保开发团队对产品待开发项内容达到一定程度的理解；
Scrum Master（教练）
清晰的传达愿景。
提供食物和水。
清除团队成员的障碍，如频繁的开无意义的会议。
开发团队（Team）
自组织的团队：没有人会告诉开发团队如何把产品待开发项列表变成潜在的可发布的功能，自己决定做什么Scrum Master也不能干预。
跨职能：团队拥有创造产品增量所需要是全部技能。无论承担什么工作都是开发者，不认可头衔，以及不包括测试、业务、分析等特定领域的团队，每个人统称都是成员。
团队规模：建议3-9人，5-9人最适合。
Scrum的开发流程
1、PO从市场或客户方获取相关的产品信息。
2、PO一个人或与团队共同梳理收集回来的需求，并采用用户故事的方式对需求进行梳理。
3、根据使用用户故事梳理出来的需求，排列需求优先级，形成产品待开发列表（Product Backlog），并确定此次要发布计划要完成的工作内容。
4、PO、开发团队、SM等涉及的相关方，共同召开冲刺规划会议。这个会议会持续4~8小时。PO向开发团队介绍产品待开发项列表，确保与开发团队对这些工作取得共同的理解
5、开发团队在冲刺规划会议上挑选出一些用户故事并细化成任务作为本次冲刺的目标，并形成冲刺待办列表（Sprint Backlog）。
6、每一轮冲刺（Sprint）持续时间约2~4周。冲刺（Sprint）开始时，开发团队成员根据意愿领取自己想要做的任务。
7、每天早上会花15分钟召开每日站会（Daily Scrum Meeting），每个团队成员会回答三个问题，昨天完成了什么？今天准备做什么任务？遇到什么障碍？
8、在本轮冲刺完成后，会召开冲刺评审会议（Sprint Review Meeting），会持续2~4小时。主要是向相关方演示本次完成的产品功能，并获得反馈。同时，可以讨论并计划下一个迭代要做的事情。
9、召开冲刺回顾会议（Sprint Retrospective），持续时间2~4小时。总结哪些做的好的地方需要保持，需要改进的地方有哪些，以便在下一个冲刺中进行改进。
10、本轮迭代结束。
冲刺（Sprint）
一个冲刺就是一个时间盒，时间大约是2~4周。
每个冲刺中包括了冲刺计划会议、每日站会、冲刺评审会议和冲刺回顾会议。
冲刺规划会议（Sprint Planning Meeting）
持续4~8小时，确定在这个冲刺中需要交付哪些产品功能，以及如何达成目标。
PO向团队介绍排好优先级的产品待开发项，确保开发团队对事项的理解，创建足够详细的计划来确保其能够完成。
本轮冲刺要完成的待开发项数量的多少由开发团队自行决定去评估和决定，SM或PO都不能干预。决定如何完成工作是开发团队的职责，决定做什么则是PO的职责。
开发团队按照完成的定义分解更小的单元，每个工作单元不超过一天。PO可以继续留下来回答问题以及澄清一些误解。
每日立会（Daily Scrum Meeting）
持续15分钟，可以带来透明性、信任和更好的绩效。
上一个每日立会到现在完成了什么？从现在到下一个每日立会，计划完成什么？遇到了什么障碍？
冲刺评审会议（Sprint Review Meeting）
持续2~4小时，演示此次冲刺完成的产品功能，并获得客户的反馈与PO的验收。
PO和团队还可以根本此次完成的产品功能做对应的调整，并讨论剩余的产品待开发项（此次未完成或下一个阶段做的产品开发项），以及下一步计划完成的工作。
冲刺回顾（Sprint Retrospective）
持续时间不超过3小时，总结哪些做的好的地方需要保持，需要改进的地方有哪些，以便在下一个冲刺中进行改进。
产品待开发项（Product Backlog）
包括业务功能和非业务功能（技术、架构和工程实践相关等），提升点及缺陷修复等。
产品待开发项是需要持续改变的，以确保优先级是最合理、最具有竞争力、最有价值的。
Scrum不考虑已经花在产品待开发项内容上的工作时间，只关心剩余工作和日期这两个变量。
冲刺待开发项（Sprint Backlog）
是从产品待开发项的用户故事分解而来的一系列任务项。
会伴随有一个计划以实现本轮冲刺的目标，并且产品待开发项的功能点被放到冲刺的固定周期中。
冲刺待开发项会因为两个方面而变化：一是对需求有更好的理解，可能需要增加一些新的任务到冲刺待开发项中。二是缺陷作为新的任务加进来，这个都作为承诺提交任务中未完成的工作。
通过冲刺中不断追踪剩余的工作，开发团队可以管理自己的进度。
增量
在一个冲刺完成之后的所有产品待办事项的综合，以及之前所有冲刺产生的增量价值的总和。这些总量在每个冲刺即将结束的时候必须满足完成的定义，并且能够带来价值。
Scrum价值观；Scrum原则；
Scrum团队组成由PO、SM、开发团队。
Scrum的开发流程。
Scrum活动或会议有冲刺规划会议、每次站会、冲刺评审会议、冲刺回顾会。
Scrum工件：产品代办列表、冲刺代办列表、增量。
关注微信