敏捷开发
# 1. 概述
随着软件开发技术的不断发展，现在出现了很多种不同的开发模式，其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案，那么什么是敏捷开发呢？
# 1.1 四种开发模式
# 1.1.1 瀑布式开发
瀑布式开发是一种老旧的，正在过时的计算机软件开发方法，最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况
瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型，是一种比较老的计算机软件开发模式， 也是典型的预见性的开发模式。
在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等， 瀑布式开发最早强调系统开发应有完整的周期，且 必须完整地经历每个周期内的每个开发阶段，井系统化地考量分析所涉及的技术、时间与资源投入等。
# 1.1.1.1 优点
有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率
# 1.1.1.2 缺点
- 开发过程一般不能逆转，否则代价太大；
- 实际的项目开发很难严格按该模型进行；
- 客户往往很难清楚地给出所有的需求，而该模型却要求如此。
- 软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
# 1.1.1.3 使用场景
- 用户的需求非常清楚全面，且在开发过程中没有或很少变化
- 开发人员对软件的应用领域很熟悉
- 用户的使用环境非常稳定
- 开发工作对用户参与的要求很低
# 1.1.2 螺旋模型
螺旋模型由巴利·玻姆(Barry Boehm)于1988年提岀，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失，这种模型比较适合开发复杂的大型软件。
螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型，每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。
在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务，螺旋模型的若干个阶段是沿着螺线方式进行的。
在每个螺旋周期内按四个象限，分为四个工作步。
- 第一，制定计划：确定软件目标，选定实施方案，明确项目开发的限制条件；
- 第二，风险分析：分析所选方案，识别风险，通过原型消除风险；
- 第三，开发实施：实施软件开发；
- 第四，客户评估：评价开发工作，提出修正建议，建立下一个周期的计划。
# 1.1.2.1 优点
实质上相当于在瀑布模型的每个阶段开始前引入风险分析，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；由于引入风险分析等活动，测试活动的确定性增强了；螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视
# 1.1.2.2 缺点
主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟
# 1.1.3 迭代式开发
迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率
在迭代开发中，整个开发工作被组织为一系列的短小的，固定的长度(如3周)的小项目，被称为一系列的迭代，每一次迭代都包括了定义、需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或者业务逻辑的开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代
# 1.1.3.1 优点
与传统的瀑布模型相比较，迭代过程具有以下优点
- 降低了在一个增量上的开发风险，如果某个迭代完成后的软件不符合客户要求，那么损失只是这一个开发有误的迭代的花费
- 降低了产品无法按照既定进度进入市场的风险，通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙
- 加快了整个开发工作的进度，因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
- 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的，因此，迭代过程这种模式使适应需求的变化会更容易些。
# 1.1.3.2 缺点
对产品人员的节奏把控能力（定每周目标，需求优先级剖析，以及临时需求的处理）有较高要求，不然容易陷入每周发版日加班加死的节奏
- 初期产品用户规模小，性能并不是主要瓶颈
- 团队里面没有优秀的架构师，优化力不从心。
- 后端架构优化是个慢活，它不像产品功能层面的迭代那样可以快速被感知，对于强产品驱动而非强技术驱动的公司来说，不够重视。
- 后端架构优化更是个细活，它也不像产品功能一样有很明显的“产出”，对于不懂技术的领导或者以KPI为导向的公司文化来说，员工去优化后端的意愿并不强烈。
- 产品交付进度压力比较大，没有时间去思考架构的优化，精力都在聚焦怎么实现功能上面
# 1.1.4 敏捷开发
敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法，在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征
简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本，然后在后续的生产周期内，按照新需求不断迭代升级，完善产品
# 1.1.4.1 优点
敏捷确实使得项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品，敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。
# 1.1.4.2 缺点
但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。
# 1.2 开发模式对比
| / | 瀑布模式 | 迭代模式 | 螺旋模式 | 敏捷开发 |
|---|---|---|---|---|
| 开发效率 | 底 | 中 | 中 | 高 |
| 文档要求 | 高 | 高 | 高 | 底 |
| 风险控制 | 底 | 中 | 中 | 高 |
| 应对需求变化 | 底 | 中 | 中 | 高 |
# 2. 敏捷开发
敏捷是世界上使用最广泛，最受认可的软件开发框架之一，大多数组织已经以某种形式采用了它，但是在采用计划的成熟度方面还有很长的路要走
敏捷软件开发是基于敏捷宣言定义的价值观《敏捷软件开发宣言》和原则《敏捷软件的十二条原则》的一系列方法和实践的总称。
自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案，换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力，这就叫做敏捷开发。
# 2.1 敏捷宣言
在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件，这份文件基本上代表了不同敏捷方法论的共同点。
当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。
参与者们分享了互相竞争的几种方式：极限编程（XP）；透明化；自适应软件开发（ASD）；特征驱动开发（FDD）；动态系统开发方法（DSDM），所有这些方式都是“轻量版”的框架，因为这些方法使用更少，更简单的规则来适应快速变化的环境，不少与会者都觉得“轻量”这个术语非常适用。
经过为期三天的讨论，他们在价值观和原则层面上达成共识，选择了 Agile 一词并为其赋予了特殊的意义，制定并发布了软件行业历史上最为重要的文件之一：敏捷宣言。
参会者将自己命名为“敏捷联盟（ The Agile Alliance ）”，**希望能够帮助软件行业中的其他人以新的、更敏捷的方式思考软件开发、方法和组织。**而“敏捷宣言”则被展示在一个网站上（ https://agilemanifesto.org/ ） ，到目前已被翻译成了60多种语言，并作为一种信仰被推广至全球以及非软件行业。
# 2.1.1 敏捷宣言解读
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：
个体和互动 高于 流程和工具；（个体与交互：团队各个成员的能力与团队间的沟通）
工作的软件 高于 详尽的文档；(以结果为导向）
客户合作 高于 合同谈判；（注重客户参与）
响应变化 高于 遵循计划；( 敏捷 要求有开放的工作环境，确保团队及时高效地进行沟通）
也就是说，尽管右项有价值，我们更重视左项的价值。
# 2.1.2 敏捷宣言价值观
# 2.1.2.1 个体和互动高于流程和工具
项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。
虽然，过程和工具都是好东西，但是它们有时也会成为障碍，面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多，当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。
# 2.1.2.2 工作的软件高于详尽的文档
可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件(而不是文档)为客户传递了高价值
一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的，但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的，敏捷通过寻求“刚好足够”的文档来避免这种情况，其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。
# 2.1.2.3 客户合作高于合同谈判
这对价值观的核心是越接近你的客户越好。
客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误，在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的，定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。
# 2.1.2.4 响应变化高于遵循计划
任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。
即使底层的技术也在快速变化，新的途径和可能性在不断的被打开，对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。
# 2.2 敏捷准则
除了敏捷宣言之外，还有12条准则的支持文件，为敏捷宣言提供了更多的扩充细节
# 2.2.1 目的：是客户满意
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
敏捷团队可以很快将可用软件交付到客户手中，并且是开放式地快速更新，给客户带来优先级最高地价值
# 2.2.2 态度：欢迎需求变更
欢迎对需求提出变更——即使是在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势
传统项目管理中地一个原则是设法去影响和控制会导致变化地因素，敏捷项目管理预期到需求会发生变化，并在实际过程中欢迎拥抱这些变化，即使这些变化发生在项目后期，迅速应对和适应变化能给客户带来显著地竞争优势，从而应对新的机遇。
# 2.2.3 关注：客户需求的软件
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
不同的敏捷方法论采用不同的迭代周期，但都是相对较短的，关键是能快速把可用的软件交付到客户手上并能利用软件获得有意义的回报，较短的迭代周期为团队提供架构并强化团队持续关注客户的价值。
# 2.2.4 合作：打破隔阂
项目过程中，业务人员与开发人员必须在一起工作
敏捷项目管理，让业务人员和开发人员彼此靠近，并时常让他们在同一个地方一起工作，通过这样的方式让业务人员和开发人员之间没有隔阂，是因为业务人员和开发人员的共同目标就是通过可用的软件向客户传递价值。
# 2.2.5 核心：团队成员
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
传统项目管理，常对员工进行微观管理，不仅告诉他们要做什么，还告诉他们如何做，无意间形成自上而下的管理方式，敏捷项目建立了一支强有力的团队并积极避免微观管理，要求一个自律的团队，自发告知开发人员做什么，提供相关资源，给予鼓励，相信团队能够完成任务。
# 2.2.6 沟通：面对面
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
非正式口头的沟通在敏捷项目管理中远比正式的书面沟通更普遍，其想法是两个人坐在一起为一个解决方案努力会比他们用邮件来来往往或交换文件更有效率，面对面沟通是敏捷项目管理的精髓，这种沟通是公开的，任何团队成员都可以自由参与对话。
# 2.2.7 标准：可工作的软件
可用的软件是衡量进度的主要指标
计划和文档可能是有用的，但是当最根本的目标发生变化时，它们就可能失去应有的价值，传统项目往往极其纠结的是，项目的不断更新使得文档成为一种负担，真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的。
# 2.2.8 倡导：可持续开发
敏捷过程提倡可持续的开发，项目方、开发人员和用户应该能够保持恒久稳定的进展速度
可持续开发的焦点是在团队身上，他们会努力保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工，理想的目标是保持一种可持续的速度，使团队成员不会感到过度的压力和筋疲力尽，而是能够保持在一个理想的强度下工作。
# 2.2.9 追求：技术卓越和技术良好
对技术的精益求精以及对设计的不断完善将提升敏捷性
设计的越完善，维护起来就越简单，即使遇到变化，稳定和优质的项目会比劣质的项目更加允许团队快速应对变化
# 2.2.10 根本：简洁
要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术
这个被所有的敏捷方法所拥护，尤其使精益方法，关键点对客户价值保持关注和毫无犹豫的削减不增加价值的活动，保持简单不只是一种愿望，它使最基本的原则。
# 2.2.11 团队：自组织
最佳的架构、需求和设计出自自我组织的团队
自我组织是敏捷团队的核心元素之一，当一个团队是自我组织型的时候，说明该团队自己去决定工作如何分配及谁去做某个特定的工作，而不是人力资源部门或管理层来决定，不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的
# 2.2.12 调整：定期反思
团队要定期反省如何能够做到更有效，并相应的调整团队的行为
敏捷项目中最可预见的事情就是变更，传统项目里当项目或阶段完成时开会总结是最常见的做法，而敏捷试着通过更频繁的回顾来完成这项工作，在一个回顾活动中，团队查看各迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法，每日站立会议即每天简单碰头15分钟是另一项协调团队努力方向、团队自我评定和自我调整的重要方式。
# 2.3 敏捷优缺点
敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价值，减少麻烦，敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作，需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。
# 2.3.1 优点
# 2.3.1.1 更快交付价值
敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。
# 2.3.2.2 更低的风险
敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。
这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险，即使这个项目失败了，这个失败的代价相对来说小一些。
# 2.3.2.3 拥抱变化
因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力，而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。
# 2.3.2.4 更好的质量
敏捷提倡高频率的交付有价值的产品
每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准等等，同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。
# 2.3.2.5 持续改进
敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。
这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会，另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。
# 2.3.2.6 更高的客户满意度
敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。
# 2.3.2.6 更高的团队满意度
敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍，重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理，更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；
团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作，通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，"A happy employee is a productive employee"，不是吗？
# 2.3.2.7 更大的灵活性
敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等，另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等，还有，验收标准，都可以根据实际情况进行调整。
# 2.3.3 缺点
尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的，因此，了解敏捷的不足显得特别重要，知道这点后，你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。
# 2.3.3.1 很难进行准确的资源规划
由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。
# 2.3.3.2 很难准确的定义“轻量的“或必要的文档
敏捷倡导的是用工作的软件即文档**（核心是代码即文档）**。
整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的，因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）
# 2.3.3.3 很难把握整体产品的一致性
增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点
因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体
# 2.3.3.4 很难预测有限的终点
敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向，此外，这意味着项目没有限定的终点，因为从来没有一个明确的 "最终的产品"样子。
# 2.3.3.5 很难有效地进行度量
由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看，而 "边走边看 "的特性意味着你不能在项目开始时设置很多KPI，这种长期的游戏使得衡量进度变得相对困难。
# 2.4 为什么敏捷越来越流行
# 2.4.1 利益相关者
敏捷开发保证了项目中所有利益相关者的利益，不论是客户、项目管理、开发团队或测试小组。
每个人对项目都有清晰的可见性，这是成功的关键点所在，敏捷开发原则上鼓励用户积极地参与，不论是产品开发，或是团体协同的方方面面。这对关键利益相关者提供了非常好的可见性，包括项目的进度或是产品本身，最终这有利于保证产品预期的效果。
# 2.4.2 高效的团队
Aglie团队是自发组织的，这意味着他们有权利和责任去审核生产所有者直接干预的工作。
这与大多数non-agile项目不同，项目管理者有责任给团队分配任务，或者甚至是团队成员，这给予团队一种自主感，提高团队士气，最终增加生产率。
# 2.4.3 市场速度
由于传播速度快，我们能更快地响应市场，因此有更高收入
这一切增加客户满意度的关键因素是敏捷应用开发。
# 2.4.4 质量
在项目中梦寐以求的代名词是质量。
不像传统的瀑布模型，等到开发完成才开始测试，可是在敏捷开发中，我们随着需求的准备便开始进行测试。因此，测试集成贯穿整个开发周期，使得工作产品像开发一样去定期检查。这允许工作所有者有必要时做出适当调整，以及及早的给产品团队检查出任何质量问题。
# 2.4.5 有趣
实践敏捷最好的一点就是它很有趣
整个团队都积极的参与，使得整个工作空间和氛围均因为这种积极参与和互相之间的协作配合而变得更有意思。有很多有趣的方式比如用计划扑克牌游戏和卡片来评估任务，采用生动新颖的任务面板来讨论工作的进展， 用全新的方式来管控例会以及许多敏捷项目中其他更有趣的东西。据我的经验，这是对每一个人都能受益的方法。
# 2.5 为什么国内敏捷很难实施
自然是因为很多公司尝试过，然后失败了，便觉得敏捷项目管理不行
关于为什么会失败，国外资深敏捷教练在深入调查后在《Scrum在亚洲难以实行》一文中总结了四点原因
- 不一样的教育方式：人们习惯于遵循体制，与敏捷思想中的“自我组织”、“自我管理”相违背
- 性格普遍偏内向，很难像西方人一样在大众场合下发言
- 组织内犯错很大程度是不被允许的，与敏捷思想中“快速试错”理念背道而驰
- 外包泛滥，所有的行为都倾向于节约成本
这四点刚好切中了要害，精确地概括了敏捷在亚洲难以落地的主要原因
# 2.5.1 勤于苦干，懒于思考
在国内，绝大部分公司都还没有认识到软件开发是一项知识性工作，普遍对软件开发的理解还很肤浅，以为可以通过加人、加班来加快软件开发的进度，更悲催的是，很多员工自己也没有认识到这一点，每当问到为什么项目进度落后的时候，他们的反应总是抱怨“人手不够”，而提出的解决方案就是“加班”，这种意图使用蛮力来达到目标的行为，恰恰体现出了国内不少软件开发人员的一大特点——“勤于苦干，懒于思考”
# 2.5.2 崇尚技术，轻视方法
在国内，如果要形容一个程序员很牛，必然是说他懂得多少尖端技术，会哪些语言，参与了哪些项目……如果你跟人讲你了解敏捷开发的理念，精通哪些方法论，知道什么流程应该如何改进，不出意外你得到的反馈就是：“那些都是虚的，你懂哪些实实在在的技术？”或者引用Linus Torvalds的名言：“Talk is cheap，show me the code。”
这就尴尬了，在国内很多程序员眼里，技术的地位已经被无限拔高，甚至成了一种社会地位的衡量标准：你懂的技术多=你是牛人=你讲的话就是对的；这个技术你都不懂=你不如我=你讲的话我为什么要听？又或者成了一种解决问题的万能钥匙：这个版本的产品质量不好，是因为现在这个技术已经过时了，下个版本我们换种新技术。 遇到什么问题都归因于技术，总是寻求换新技术以期望能解决问题，而不是真真正正踏踏实实去解决眼前的工作方法问题，已经成为国内程序员群体中一个普遍存在的现象
# 2.5.3 急功近利，肆意浪费
我们都知道无论是敏捷开发还是精益创业里面都强调的一个原则是：通过不断地快速试错来做正确的事情。精益创业里提出的最小化可行产品（MVP，minimum viable product）就是这一点的充分体现——通过开发最小化可行产品，以最低的成本来达到快速试错的目的，找到一条正确的道路，最终做出符合用户期望的产品。
然而在国内这几年的创业浪潮中，一批批的创业公司出现，又一批批地死掉。仔细分析这些“昙花一现”的公司就会发现，它们的模式都很相似：一个点子加PPT就能拉来投资，然后招几个培训班速成的开发人员，按照需求说明书做出产品，然后继续拉风投，继续招人……直到哪天融不到钱了，资金链断裂，就作鸟兽散。CEO拍拍屁股走人，也没有任何损失，继续去开下一家公司。对他们来说，做一款产品几乎没有任何成本，失败也就失败了，根本不需要什么MVP试错，直接用产品试错好了。
在这种环境下，不会有人关注什么产品质量和效率，反正做出的东西能够继续忽悠投资人就行。换言之，融到钱才是最重要的，至于我这个产品质量如何？是不是可行的？如果不行会浪费多少资源？都不是问题。甚至有人曾经问我：“连生存都不能保证了谁还去管什么质量和效率？”我到现在都觉得他问得好有道理，竟无言以对，似乎我反而成了那个问他们“何不食肉糜”的人。
# 2.6 敏捷开发方法
现在很多的企业都在选择一种敏捷开发应用程序的方式，提高企业数字化转型的效率，敏捷开发是一种方法的集合，那么主流的敏捷开发方式有哪些呢，其中最主流的敏捷开发方法有SCRUM以及XP
# 2.6.1 SCRUM
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理，是团队合作开发产品的一种方式，而需求在开发过程中会快速变化。
使用Scrum进行产品开发时，会分成几小块，每块都基于先前创建的块，一次只制造一小块产品就可以鼓励创造力，并使团队能够响应反馈和变更，从而准确而准确地构建所需的产品，与XP不同，Scrum方法包括管理和开发过程。
# 2.6.2 XP（极限编程）
XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。
它提倡在较短的开发周期中频繁地“发布”，每个发布都伴随着几次迭代， 当产品发布具有足够的功能以满足用户需求时，团队将终止迭代周期并发布软件。
极限编程的其他元素包括：结对编程，持续集成，仅添加特定版本所需的功能。
用户编写故事，可以帮助团队估计构建发布和定义验收测试的时间， XP团队的一部分用户在构建软件时增加了详细要求。 这使需求随着用户和开发人员定义产品的外观而发展
# 2.6.3 区别
| \ | XP | Scrum |
|---|---|---|
| 迭代周期 | 1-2周 | 2-4周 |
| 是否允许修改需求 | 在一个需要没有实现的时候可以使用其他的需求将其替换，但是实现的时间是要相等的 | Scrum是不允许这样做的，一旦迭代开工会完毕，不允许有改变，并有Scrum Master严格把关 |
| 需求是否严格按照优先级实现 | 是 | 不用 |
| 是否采用严格的工程方法，保证进度或者质量 | 非常严格 | 要求开发者自觉 |
# 3. SCRUM
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
# 3.1 Scrum概览
Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”，在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。
不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。
在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。
在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)，产品负责人会逐一挑选最高优先级的部分进行讲解，团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和，一旦迭代开始，这些任务将不会发生大的变化。
在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈，当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。
# 3.1.2 理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。
经验主义主张知识源于经验, 以及基于已知的东西做决定，Scrum 采用迭代、增量的方法来优化可预见性并控制风险，Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。
# 3.1.2.1 透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明，管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容，也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
# 3.1.2.2 检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差，在确定检验频率时，需要考虑到检验会引起所有过程发生变化，当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题，幸运的是，软件开发并不会出现这种情况，另一个因素就是检验工作成果人员的技能水平和积极性。
# 3.1.2.3 适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整，调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：
- 每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；
- Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；
- Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
# 3.2 三个角色
# 3.2.1 产品负责人（Product Owner）
Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果
# 3.2.1.1 职责
- 与客户沟通、确定客户正在意图、产品交付日期等
- 与团队沟通、共同确定需求
- 考虑团队的研发实力
# 3.2.1.2 人选
- 部门经理、产品经理、策划人员等都可能做产品负责人。
- 产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。
- 大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。
# 3.2.2 流程管理员（Scrum Master）
Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协助解决非技术问题。
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发
# 3.2.2.1 职责
- 负责整个Scrum流程在项目中顺利实施和进行
- 没有行政权力
- 不帮团队做决定、但是可以提出建议
# 3.2.2.2 人选
- Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。
- 一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。
- 另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。
# 3.2.3 开发团队（Scrum Team）
Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标
# 3.2.3.1 职责
- 负责整个Scrum流程在项目中顺利实施和进行和自组织的开发团队
- 一般5~10人
- 跨职能团队（业务分析师、程序员、测试人员、架构师、数据库设计师）
# 3.3 三个工件
# 3.3.1 产品待办列表（Product Backlog）
产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。
产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变 动的唯一来源，产品负责人负责管理产品待办列表的内容、可用性和排序。
- 功能、缺陷、增强等都可以是待开发项。
- 一般以条目化的方式描述。
- 客户和用户必须能够理解。
- 描述怎样使用而非怎样制造。
- 整体上从客户价值优先级排序。
- 总工作量一般需要0.5～10人天。
- 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。
# 3.3.2 Sprint待办列表（Sprint Backlog）
冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务
Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划，Sprint 待办列表是开发团队对于下一个产品增量所需的那 些功能以 及交付那些功能到"完成"的增量中所需工作的预测
- 在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。
- 在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。
# 3.3.3 增量
产品增量是在Sprint内开发团队交付的所有产品待办列表条目的综合，增量必须是符合团队定义的"完成的定义"（Definition of Done）
# 3.4 五个事件
# 3.4.1 Sprint
也翻译做冲刺，是Scrum的核心，也是一个容器
Sprint是一个时间盒（固定的开始和结束时间），下一个Sprint会紧随上一个Sprint，在这之间没有停顿。Sprint由Sprint计划、每日例会、Sprint执行、Sprint评审及Sprint回顾组成。
# 3.4.2 Sprint计划
一个Sprint中准备做的所有工作是在Sprint计划会议中完成的。
这份计划是整个团队（产品负责人、Scrum Master和开发团队）共同完成的
# 3.4.2.1 目的
Sprint计划最主要完成两件事情：
- 在这个Sprint中要完成什么产品待办列表条目？（What）
- 如何完成这些条目？（How）
# 3.4.2.2 流程
- 迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
- 产品负责人逐条讲解最重要的产品功能。
- 开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。
- 产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。
# 3.4.3 每日站会
开发团队15分钟同步进度并每日调整的一个事件
在每日站会上，每个团队成员回答以下三个问题（基本的，可以根据情况增加新问题）
- 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
- 今天，我为帮助开发团队达成 Sprint 目标准备做什么?
- 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?
# 3.4.3.1 流程
- 队员认领任务（或由组长协商分发），独立或与别人一起完成任务。
- 团队内部利用每日立会来沟通进度。
- 开发团队利用燃尽图来展示整体进度。
- 如无特殊原因，迭代期内无变更。
# 3.4.4 Sprint评审
在Sprint快结束时，Scrum团队在一起检视所交付的产品增量，并调整产品待办列表
Sprint评审不是Sprint演示、也不叫做Sprint demo，一定要包括收集反馈和调整的环节
# 3.4.4.1 流程
- 小组向产品负责人展示迭代工作结果。
- 产品负责人给出评价和反馈。
- 以用户故事是否能成功交付来评价任务完成情况。
# 3.4.5 Sprint回顾
Scrum团队检视和调整工作方法、流程，持续改进的事件
# 3.4.5.1 目的
Sprint回顾的主要目的是
- 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何
- 找出并加以排序做得好的和潜在需要改进的主要方面
- 制定改进 Scrum 团队工作方式的计划
# 3.4.5.2 流程
- 在每个迭代后召开简短的反思会。
- 总结哪些事情做的好，哪些事情做的不好。
- 制定改进计划。
# 3.4.6 产品待办列表梳理（Refinement）
即需求梳理会，每周Scrum团队在一起为下一个Sprint进行准备工作。
# 3.4.7 五个价值观
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
# 3.5 用户故事
用户故事：描述具体的需求的卡片，按
作为一个……，可以……，以便……样式和思路写成的用户需求，就是用户故事
这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素，要想写好用户故事，要改变那种面向功能而非客户需求的纯技术观念。
# 3.5.1 角色
切记不要总是写“作为一个用户”，而是要把用户区别对待，这样才能更好地理解他们使用什么功能，如何使用，为何使用。
# 3.5.2 功能
即用户能亲自执行的操作，应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。
# 3.5.3 价值
是完成操作后，客户所得到的好处，价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如“高效地……”“……可以节省话费”等。
# 3.6 敏捷日常跟进
# 3.6.1 看板
- 看板又叫任务版，对于Sprint进度的沟通，看板是一种简单而强大的方式，从形式上看，看板显示的是Sprint冲刺待开发项随时间的进展状态。
- 故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。
- 看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。
# 3.6.2 燃尽图
- 在Sprint执行的每一天，团队成员都要更新未完成任务的剩余工作量估算，我们可以创建一个表来是使数据可视化，就是燃尽图
- 根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。
# Scurm开发工具
上面我们说了Scurm框架的操作流程，下面我们看下支持Scurm开发框架的工具有哪些
# 白板
# 使用对象
5-10人左右的团队
# 知名度
非常知名，大家从小到大都是从黑板时代过来的，只是这里换成了白板
# 产品能力
白板是实施Scrum 最简单直接的方式，用于每天跟踪汇报，简明易懂。但是对Product Backlog支持明显不够，也没办法保留历史纪录，而历史记录对于回顾还是非常重要的，毕竟Scrum 的核心理念之一就是通过短期回顾,达到持续不断的改善。
# 优缺点
使用起来非常简单，对于少量的任务分配，团队人数比较少的时候是适用的，比较简单，但是如果团队人数比较多就不太合适了，并且没有跟踪体系以及反馈体系，不能够监控团队工作的整体情况，出现问题难以复盘。
# PingCode
官网：
https://pingcode.com/
# 适用对象
500人以下的中小型企业
# 知名度
由国内老牌SaaS 厂商Worktile 打造，成立于2012年，在2021年PingCode 在36氪企服点评发布的研发项目管理工具榜排名 TOP1，除此以外，PingCode 在国内多个领域出于领先地位，比如具有国内最先进的研发自动化管理引擎，在国内最早推出跨平台研发自动化管理产品等等。
# 产品能力
对比过国内的一些声称支持敏捷管理的产品，但很多并不如他们所宣称的那样支持标准的敏捷管理
而PingCode 一致认为国内最标准的敏捷开发管理工具，因为它在功能上不仅很好的支撑的敏捷管理，还很好的支持了研发全生命周期的管理：
- 支持Scrum、Kanban等多种敏捷方法，以及规模化敏捷（SAFe）的管理
- 七大子产品和应用市场支持产品研发全生命周期管理，比如目标管理、需求管理、产品路线图、版本管理、项目/任务管理、缺陷管理、测试管理、团队知识库、计划分配资源、可视化、效能度量等等
- 七大子产品：Goals 产研OKR目标管理、Agile 敏捷开发管理、Testhub 测试用例维护与计划执行、Plan 规划敏捷、 Wiki 团队知识库、Flow 研发自动化管理、Access 账号认证与安全管理；
- 应用市场：集成了研发中主流的工具，如Git、Jenkins、gitlab等等，实现了不同工具间的数据打通；能够在飞书、企微等平台使用；
# 优缺点
- 产品开箱即用，简单易上手，不需要像Jira 那样经过好几月的培训，以及专门的系统管理专家配置系统才可使用；
- 25人以下免费，收费版价格仅为国外产品Jira的30%-40%；
- 在国内提供专业的敏捷咨询服务，从而在实施和工具层面都能够帮助团队做好敏捷开发；
- 到2022年才支持瀑布开发模式的管理。
# 架构图
# VersionOne
官网:
https://www.collab.net/products/versionone
# 适用对象
国外中大型团队
# 知名度
VersionOne在2002年帮助推出了敏捷管理工具，并且在2020年发布的敏捷状态报告中是国外颇受欢迎的敏捷管理工具之一，它支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。
# 产品能力
VersionOne是基于Web的项目管理工具，测试人员,开发人员和其他利益相关者可以使用该版本来管理,跟踪和组织软件测试工作，它遵循并涵盖了敏捷方法论的整个生命周期。它支持从第一步作为产品待办事项到项目的最后一步, 即完成和交付。
比如，团队可以通过它
- 进行代办事项和可配置任务的产品计划；
- 发布计划中已计划和已完成任务的统计信息；
- 冲刺计划，允许将待办事项中的任务添加到不同类型的冲刺中；
- 与看板一起进行Sprint跟踪以管理项目中的任务；
- 包含有关每个任务和团队绩效的详细报告等
所有这些元素允许执行不同的敏捷方法，例如使用看板，大型Scrum（LeSS），DaD（纪律敏捷交付）以及混合方法（看板和Scrum的混合）
VersionOne的价格从每位用户每月29美元开始，也提供免费试用,此外，它仅在基于Web的平台上运行。
# 优缺点
- 支持多种敏捷开发方法
- 国内没有团队、代理商以及服务器，所以会存在一定程度的服务响应问题以及售后问题；
- 在销售工具的同时也提供专业的敏捷培训（仅限国外）
# Atlassian Jira
官网:
https://www.atlassian.com/software/jira
# 适用对象
2000人以上的中大型企业
# 知名度
Jira是全球范围内软件开发的先驱，该品牌于2002年由Atlassian公司在澳大利亚创立，最初是一个问题跟踪工具，此后逐渐发展为多任务的项目管理软件。
早年在国内还有较多用户，但自从2020年停售国内本地版后（一定意义上对国内用户禁售），越来越多的用户逐渐选择放弃使用，但这也丝毫不影响其产品能力。
# 产品能力
- Jira同样支持Scrum等多种敏捷项目管理；
- 同时，敏捷团队可以通过它跟踪QA活动，按优先级和严重程度对其进行分类，跟踪其进度和解决方案；
- 按团队，问题，任务等跟踪项目；
- 管理产品开发，审查开发阶段并分析进度，跟踪产品版本和发行；
- 分析有关项目，错误，问题，任务，团队绩效等的统计信息。
# 优缺点
- Atlassian公司为Jira提供了广泛的附加组件，例如时间跟踪，甘特图，项目管理应用程序集成等。
- 它拥有强大的社区和支持，例如，Confluence解决方案代表了一种类似Wiki的服务，其中包含有关如何使用Jira的文章。
- Jira是一种多功能工具，对于新手来说，它可能相当复杂。因此，你需要花费一些时间来学习如何使用它。
- 并且，Jira的价格一般小公司可能无法承受，因为Jira加一些插件的年购费用达到几十上百万是很稀松平常的事。
# 和其他的产品对比
跟其他产品的对比如如下
# PingCode进行Scurm开发
# 角色管理
可以在在产品-->后台管理-->用户管理中进行添加角色
在后台管理中打开用户管理中的角色管理添加执行Scrum的三个角色
# 添加角色
Scrum 框架下有3种常见角色：产品负责人（Product Owner）、流程管理员（Scrum Master） 团队成员（Scrum Team）
PingCode 能以自定义项目角色和权限的方式对成员进行分组和权限管理，比如配置不同角色不同的管理和查看项目、工作项类型等权限，项目成员亦可拥有多个角色
这里我们添加产品负责人、流程管理员、以及团队成员
添加完成后如下列表
# 创建敏捷项目
适用PingCode进行敏捷开发的第一步是创建一个敏捷项目，点击产品 --> 敏捷开发，添加一个敏捷项目
到了敏捷开发页面点击新建项目，在弹出添加项目详情中填写信息，这里我们选择scrum项目
完成后会出现如下项目界面，接着我们就可以完成后续的操作了
# 需求管理
按照Scrum的一般做法，迭代开始前，由产品负责人收集来自各方需要、期望和诉求，评定优先级，整理出产品 Backlog，通过会议评审形成 Sprint Backlog
PingCode是以史诗、特性、用户故事三级方式进行需求管理，可以通过自定义需求状态、补充各类属性字段，编写完整描述，上传相关产品文档等方式，形成完整的故事结构， 也可以利用「子工作项」进行复杂需求细化和拆解。
值得一提的是需求也可与用户反馈、研发任务、测试结果、Wiki的文档等工作项相关联，便于其它成员查找引用、追溯来源。
# 需求类型
pingcode将用户需求分为了史诗、特性、以及用户故事，来让我们需求进行管理
# 史诗
基于产品的长期战略方向而被提出，颗粒度级别最大，通常为可独立使用的一个产品模块；
# 特性
作为某个史诗的子需求（比史诗更具象）和若干个用户故事的集合，承上启下，需要多轮迭代才能完成交付；
# 用户故事
从用户的角度来描述用户渴望被满足的需求，颗粒度级别最小，且能在一个迭代中开发完成。
# 添加需求
我们可以在新建项目中添加需求
根据上面我们提到的需求类型进行添加，根据需求的颗粒度分为不同的需求类型，下面是我们顺风车的需求
# 配置需求
当添加需求后，可以打开需求对需求的详情进行配置，开始结束时间等进行配置
# 迭代
这是我们敏捷开发过程中用到的最核心的功能，也是支撑我们 Scrum 流程的灵魂
# 添加迭代
可以在
迭代选项卡中点击添加迭代来创建一个Sprint
在添加迭代中输入这次迭代的具体信息
# 加入用户故事
迭代需要将我们的添加的用户需求加入到我们的迭代中进行开发迭代，我们可以点击
迭代中的规划来进行迭代需求管理，将本次迭代需要完成的需求移入迭代，控制一个迭代周期在一至两周。
可以将我们的用户故事加入迭代，本次迭代主要完成上传，所以将上传移入迭代
# 查看迭代详情
添加迭代后可以看到迭代的详情以及跟踪本次
Sprint的迭代，并通过燃尽图来查看Scrum的实施情况
# 任务板
每一次迭代一般周期在一至二周，我们一般每天都会开始站立会，讲述昨天的任务完成情况以及今天的任务，我们可以通过任务板来进行描述
# 管理迭代
如果迭代需求添加已经完成就可以开始迭代了，可以点击
开始迭代来开始本地迭代
我们点击开始就可以开始本次迭代
# 跟踪迭代进度
迭代开始后，每日站立会议对迭代进行跟踪。各成员快速任务进度、今天的计划、遇到的困难等就成为常态，燃尽图在这里必不可少
我们从下图也能看出，PingCode迭代概览、燃尽图基本具备，在直观反映各成员工作状况、当前迭代进度的健康程度上并没有啥毛病。
并且还支持十多种报表
# 迭代评审
在迭代将要完成的时候需要进行迭代评审，检查本地迭代进度以及完成情况，可以根据情况调整迭代中的任务的优先级，优先完成优先级比较高的任务
# 完成迭代
我们可以根据任务的完成情况完成每一个任务，等到本地迭代结束的日志查看迭代的情况
我们发现还有一个工作项还未完成，我们可以根据需要将这个未完成的任务移入
待分配任务列表
# 迭代回顾
本地迭代完成后，需要对本地迭代进行回顾以及复盘，对没有完成的迭代将回到待办列表，等待根据优先级进行下一次迭代中进行分配，可以根据本地迭代中的优点进行发扬，缺点进行规避
# 版本管理
PingCode除了进行对项目进行管理还支持对版本管理并且可以关联迭代
# 添加版本
可以点击版本选项卡进行添加版本
# 版本规划
可以根据版本规划来管理版本发布，可以通过
规划工作项来管理任务，可以将下面任务添加到发布列表中
敏捷开发一般不直接添加任务，而是关联迭代来进行管理发布任务
# 关联迭代
一般敏捷开发适合迭代关联在一起的，一个迭代就是一个可以发布的小版本
点击关联迭代可以关联我们的添加的
Sprint
点击确定就可以的看到刚才添加的
Sprint
# 查看任务
可以点击发布范围来查看本次发布的一些需求
# 版本进度
我们可以点击进度条管理发布进度
我们点击进行中就将本次发布版本进入进行中的状态
点击确定
同样，如果本地迭代完成后我们发布完成了可以点击已发布
