敏捷开发日常跟进系列之1-6
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤
1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；
2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；
3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；
4、需求梳理：然后产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；
5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等，
6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；
7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。
8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
敏捷开发方法教程
敏捷开发方法教程敏捷开发（Agile Development）是一种以人为核心、快速迭代、灵活应变的软件开发方法。
它强调团队协作、持续交付和快速反馈，可帮助开发团队更好地应对需求的变化，提高项目的成功率。
本教程将介绍敏捷开发的基本原则、常用方法和最佳实践，帮助读者全面了解敏捷开发的精髓。
一、敏捷开发简介敏捷开发起源于1990年代的极限编程（Extreme Programming）方法，在过去几十年中不断演化和发展。
与传统的瀑布模型相比，敏捷开发注重快速迭代和用户参与，能够更好地应对需求变化和项目风险。
二、敏捷开发原则敏捷开发遵循以下核心原则：1. 个体和互动高于流程和工具：注重团队协作和沟通，激发创造力和创新。
2. 可以工作的软件高于详尽的文档：通过快速迭代交付价值，提供及时的产品演示和用户反馈。
3. 客户合作高于合同谈判：与客户积极合作，灵活应对需求变化和优先级调整。
4. 响应变化高于遵循计划：在需求变化时调整方向，保持高度灵活性和可调整性。
三、敏捷开发方法敏捷开发有多种方法和框架，下面介绍几种常用的方法：1. 极限编程（Extreme Programming，简称XP）：强调团队合作、持续集成和测试驱动开发（TDD）等实践，推崇简单和高质量的设计。
2. Scrum：通过定义角色、仪式和工件等，实现实时掌控项目进度和风险。
将项目拆分为若干个迭代周期（Sprint），每个迭代周期都可以交付部分功能。
3. 敏捷建模（Agile Modeling）：强调可视化和简化的建模技术，帮助团队更好地理解问题和需求。
4. 结对编程（Pair Programming）：两位开发者合作完成一个编码任务，提高代码质量和团队协作效率。
四、敏捷开发实践实践是敏捷开发成功的关键，以下是几个重要的实践建议：1. 迭代开发：将开发工作划分为若干个迭代周期，每个迭代都能交付可工作的软件。
每次迭代结束后，团队根据反馈进行优化和调整。
敏捷开发的管理办法
**敏捷开发的管理办法**敏捷开发是一种以迭代、增量和协作为核心的软件开发方法。
它强调快速响应变化、持续交付价值和团队自组织等原则。
为了有效地实施敏捷开发，需要采取一些管理办法来提高团队的协作效率和项目的成功率。
以下是一些敏捷开发的管理办法，包括明确目标、制定优先级、迭代规划、持续反馈、团队自组织、跨功能合作、持续改进和适应变化。
一、明确目标在敏捷开发中，明确目标非常重要。
团队成员应该清楚地了解项目的愿景和目标，并将其转化为可执行的任务和需求。
明确的目标有助于团队集中精力、协调行动，并提高工作效率。
二、制定优先级在敏捷开发中，团队应该根据项目的价值和风险，制定任务和需求的优先级。
通过设定优先级，团队可以集中精力解决最重要的问题和需求，并在每个迭代中交付高价值的功能和成果。
三、迭代规划敏捷开发通过迭代的方式进行工作。
团队应该进行迭代规划，即在每个迭代开始时确定要完成的任务和需求。
迭代规划需要考虑项目目标、优先级和资源等因素，并制定相应的计划和时间表。
四、持续反馈敏捷开发强调持续反馈和学习。
团队应该与利益相关者保持密切的沟通和反馈，及时了解需求变化和用户反馈，并据此做出调整和改进。
持续反馈有助于提高产品质量、满足用户需求，并增加团队对项目的理解和参与度。
五、团队自组织在敏捷开发中，团队应该具备自组织和自主决策的能力。
团队成员应该共同决定任务分配、工作流程和问题解决方法等。
团队自组织有助于激发成员的创造力、承担责任和合作精神。
六、跨功能合作敏捷开发强调跨功能合作。
团队成员应该具备不同领域的技能和知识，并互相协作，以实现项目的成功。
跨功能合作可以促进知识共享和团队的全面发展，提高工作效率和质量。
七、持续改进敏捷开发是一个持续学习和改进的过程。
团队应该不断反思和评估自己的工作方式和结果，并寻找改进的机会。
这可以通过定期的回顾会议、团队讨论、客户反馈等方式来实现。
持续改进有助于提高团队的协作能力、产品质量和项目交付效率。
敏捷开发scrum的步骤
敏捷开发scrum的步骤
Scrum是一种敏捷开发方法论，适用于团队协作开发软件和其他复杂产品。
以下是Scrum的基本步骤：
1. 产品待办清单（Product Backlog）：根据项目需求，列出所有需要完成的任务，这些任务按照优先级排序，并且进行明确的描述。
2. 冲刺计划会议（Sprint Planning Meeting）：团队在冲刺期开始前，通过讨论和评估来确定下一个冲刺要完成哪些工作，并将这些工作分配给各个团队成员。
3. 冲刺（Sprint）：一个冲刺通常持续两周到一个月（具体时间由团队决定），在这个时间内，团队集中精力完成之前确定的工作。
4. 每日站立会议（Daily Scrum Meeting）：每天团队成员在15分钟内互相汇报工作进展情况、遇到的问题和解决方案，以确保所有人都知道项目的状态。
5. 冲刺回顾会议（Sprint Review Meeting）：在冲刺结束后，团队成员要进行回顾，检查他们所完成的工作是否达到了预期目标并探讨如何改善。
6. 冲刺回顾和改进计划（Sprint Retrospective and Improvement Plan）：团队评估过去的冲刺，找出改进的方法，并且创建下一个冲刺计划的待办清单。
以上就是Scrum流程的基本步骤，每个步骤都有具体的执行规
则和时间要求，团队需要按照这些规则和要求进行协作和沟通，以确保项目能够按时完成并达到预期效果。
敏捷开发迭代流程及其核心价值
敏捷开发迭代流程及其核心价值敏捷开发的迭代流程包括需求分析、规划、设计、开发、测试和发布等多个阶段，每个阶段都包含多个迭代周期。
在每个迭代周期内，团队会根据客户需求和项目目标制定具体的任务和计划，并在周期结束时进行评审和反馈，然后根据反馈结果对下一个迭代周期进行调整和优化。
通过不断迭代的方式，团队能够及时发现和解决问题，逐步改进产品，最终实现客户需求的满足。
下面将详细介绍敏捷开发的迭代流程及其核心价值。
1. 需求分析阶段需求分析是敏捷开发的第一个阶段，团队需要通过与客户沟通和讨论，了解客户的需求和期望，然后将需求转化为可执行的任务和计划。
在这个阶段，客户需求的准确理解和表达是非常重要的，团队需要通过不断的沟通和协作来确保需求理解的一致性。
同时，团队还需要根据客户需求的优先级制定任务计划，并确保任务的可执行性和时间可控性。
在这个阶段，团队往往会制定一个需求规格说明书或者用户故事地图，将客户需求清晰地表达出来，并作为后续迭代周期的指导。
在需求分析阶段，团队迭代的核心价值在于及时理解和满足客户需求，通过不断的迭代和优化，确保产品能够满足客户的期望，并且减少因需求变更而产生的成本和风险。
通过迭代周期的持续交付，团队能够更好地适应客户需求的变化，提高产品的交付速度和灵活性。
2. 规划阶段规划阶段是敏捷开发的第二个阶段，团队需要根据需求分析的结果制定具体的任务计划和迭代周期，确保任务的合理分配和时间的可控性。
在这个阶段，团队需要对任务的复杂度和风险进行评估，并制定相应的开发策略和计划。
同时，团队还需要根据客户需求的优先级，确定产品功能的发布顺序和时间表，保证产品能够按时交付和满足客户需求。
在规划阶段，团队迭代的核心价值在于制定合理的任务计划和时间表，确保团队能够按时交付高质量的产品。
通过不断的迭代和优化，团队能够及时发现和解决规划中的问题，确保产品开发的可控性和效率性。
3. 设计阶段设计阶段是敏捷开发的第三个阶段，团队需要根据规划结果制定具体的产品设计方案和技术实施方案，确保产品的功能和性能能够满足客户需求和期望。
PMP培训精讲之敏捷开发流程管理三要素
PMP培训精讲之敏捷开发流程管理三要素敏捷开发流程是一种以迭代、自组织和持续交付为基础的项目管理方法。
在敏捷开发流程中，有三个关键要素，分别是团队合作、产品待办事项和冲刺。
第一个要素是团队合作。
在敏捷开发流程中，团队合作是至关重要的。
团队成员之间需要紧密合作，互相协作，共同努力完成项目目标。
团队成员之间应该有高度的沟通和协调能力，能够有效地交流信息和解决问题。
此外，团队成员还应该具备自我组织和自我管理的能力，能够主动地分配任务和解决困难。
团队合作是敏捷开发流程成功的基石。
第二个要素是产品待办事项。
在敏捷开发流程中，产品待办事项是一个核心概念。
产品待办事项是由产品负责人和团队成员共同确定的，详细描述了项目的需求和目标。
产品待办事项是项目中需要完成的工作项的集合，包括功能需求、技术任务、缺陷修复等。
产品待办事项应该按照优先级进行排序，并且可以根据实际情况进行调整。
通过不断地迭代和优化产品待办事项，团队能够更好地满足客户需求。
第三个要素是冲刺。
冲刺是敏捷开发流程的基本单位，通常为一个短期的时间段，一般为1到4周。
每个冲刺都有一个明确的目标和一组产品待办事项。
团队成员根据冲刺目标和产品待办事项制定计划，并在冲刺周期内完成工作。
在冲刺过程中，团队成员应该进行日常的站立会议，及时沟通项目进展和问题，并根据实际情况进行调整。
冲刺的周期性使得团队能够在较短时间内快速交付具有商业价值的成果。
综上所述，团队合作、产品待办事项和冲刺是敏捷开发流程管理的三个关键要素。
通过团队合作，团队成员能够高效协作，共同努力完成项目目标；通过产品待办事项，团队能够清晰地了解项目需求和目标，并根据实际情况进行调整；通过冲刺，团队能够在短期内快速交付具有商业价值的成果。
这些要素的有效管理能够帮助团队实现敏捷开发流程中的高效、灵活和持续交付的目标。
敏捷开发标准
敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。
它强调团队合作、客户需求和适应变化，通过持续交付小而实用的功能，快速验证和满足客户需求，并灵活应对变化。
敏捷开发标准通常包括以下几个关键要素：1. 价值观：敏捷开发强调团队合作、快速交付、持续改进和适应变化。
这些价值观贯穿整个开发过程，指导团队成员的行为和决策。
2. 原则和方法：敏捷开发基于一系列原则和方法，包括快速交付、小而实用的功能、频繁交付可工作的软件、持续改进、关注客户需求和灵活应对变化等。
这些原则和方法为团队提供了明确的指导，确保开发过程的敏捷性和有效性。
3. 迭代式开发：敏捷开发采用迭代式开发模式，将软件项目分解为一系列小型、迭代式的工作单元。
这些工作单元通常称为“冲刺”或“迭代”，每个迭代都专注于完成一部分功能，并尽早验证和满足客户需求。
4. 沟通与协作：敏捷开发强调沟通与协作，鼓励团队成员之间建立开放、透明和信任的关系。
通过定期的面对面交流、简报和评审，确保信息的及时传递和问题的及时解决。
5. 反馈驱动：敏捷开发强调持续反馈的重要性，通过收集客户、团队成员和其他利益相关者的反馈，不断改进和优化软件产品。
这些反馈用于指导开发过程中的决策和调整，以确保交付高质量的产品。
6. 技术选择：敏捷开发不强调特定的技术或工具，团队可以根据项目需求和技术环境选择适合的技术栈。
然而，技术选择应该能够支持敏捷开发的价值观、原则和方法，并具备可扩展性和灵活性。
总的来说，敏捷开发标准提供了一套适用于软件开发的方法和框架，旨在提高软件开发的效率和产品质量。
它强调团队合作、客户需求和适应变化，通过持续交付小而实用的功能，快速验证和满足客户需求，并灵活应对变化。
这些标准有助于建立高效、协作的软件开发环境，提高客户满意度和降低项目风险。
敏捷开发的12条原则
敏捷开发的12条原则敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论，它强调团队协作、反馈机制和不断学习的理念。
为了更好地理解和应用敏捷开发，以下是敏捷开发的12条原则。
原则一：最重要的是满足客户需求，通过早期且持续的交付可行产品来获得客户的反馈并作出相应调整。
客户的满意度是成功的关键。
原则二：要频繁地进行交付。
通过将开发过程划分为多个短期的迭代周期，每个周期都会生成一个可运行的软件版本，有助于团队及时发现问题并进行修正。
原则三：以面对面的沟通为主。
通过直接交流和面对面的会议，而不是仅仅通过文档进行沟通，可以更好地理解需求和解决问题。
原则四：团队成员之间要保持密切合作。
通过组建稳定的开发团队，每个成员都能充分发挥自己的优势，提高工作效率和协同能力。
原则五：激发项目团队的动力和信任。
给予团队成员更多的自主权和责任感，鼓励他们提出优化方案和解决问题，以实现项目的成功。
原则六：追求技术卓越和良好的设计。
通过适当地应用技术手段和工具，能够提高软件的稳定性、可扩展性和可维护性。
原则七：注意可持续发展。
要在一个可持续的开发速度和进展方向之间取得平衡，避免过度投入或过度延期，以确保项目的健康发展。
原则八：保持简单和持续改进。
通过尽量简化开发过程和减少不必要的工作量，能够更高效地开展工作并保持团队的积极性。
原则九：注重团队反馈和自我调整。
通过及时收集团队成员和客户的反馈意见，进行项目的调整和优化，以便更好地满足需求和改善产品。
原则十：灵活应对变化。
要接受需求的变更和不确定性，并通过迅速调整和适应来应对变化，以保持项目的进展和质量。
原则十一：倡导自主组织和自我管理。
给予团队成员更多的决策自由和责任感，能够提高工作效率和积极性。
原则十二：关注可视化和透明度。
通过适当的可视化工具和技术手段，可以使工作进展和问题得以及时跟踪和解决，提高项目的透明度和沟通效率。
总之，敏捷开发的12条原则以客户满意、持续交付、个体和团队协作、不断反思和改进等为核心，使软件开发更加高效、灵活和贴近用户需求。
敏捷开发的实战经验总结
敏捷开发的实战经验总结敏捷开发是一种以迭代、增量的方式快速开发软件的方法论。
它强调团队合作、客户参与、迭代开发和快速反馈。
在实战中，敏捷开发经验总结如下：一、明确需求和目标敏捷开发强调客户和团队的合作，因此，在开始开发之前，团队必须与客户充分沟通，并明确需求和目标。
这样可以避免后期的变动和返工，提高开发效率。
二、迭代开发敏捷开发强调快速交付可用的软件，而不是一次性交付完整的产品。
因此，团队应该将开发任务分解为小的迭代周期，每个周期都要有可用的软件可供客户测试和反馈。
这样可以快速响应客户需求，减少开发风险。
三、持续集成和测试敏捷开发要求开发团队进行持续集成和测试。
每个开发者都要定期提交代码，并进行自动化测试。
这样可以及早发现和解决问题，保证软件质量和稳定性。
四、跨功能团队合作敏捷开发要求跨功能团队的合作。
开发、测试、运维等团队成员应该密切合作，共同完成项目。
这样可以提高效率和质量，确保软件按时交付。
五、灵活应对变化敏捷开发强调适应变化。
在开发过程中，客户需求可能会变化，团队应该灵活调整计划和开发方向。
这样可以及时满足客户需求，提高客户满意度。
六、持续改进敏捷开发要求团队进行持续改进。
团队应该定期回顾迭代过程，并找出问题和改进点。
这样可以不断提高团队的开发能力和效率。
七、注重团队沟通和反馈敏捷开发强调团队沟通和反馈。
团队成员应该定期进行沟通会议，共享开发进展和遇到的问题。
客户也应该参与其中，提供反馈和建议。
这样可以确保团队在正确的开发轨道上，并及时解决问题。
总结起来，敏捷开发需要团队有良好的沟通和协作能力，注重迭代和持续改进。
同时，灵活应对变化，持续集成和测试也是敏捷开发的关键要素。
通过以上实战经验的总结和应用，可以提高团队的开发效率和软件质量，达到客户的满意度。
敏捷开发流程详解
敏捷开发流程详解敏捷开发流程详解敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。
它强调团队合作、客户需求和适应变化。
敏捷开发流程包括许多不同的方法和框架，例如Scrum、极限编程（XP）和精益开发（Lean Development）等。
本篇文章将详细介绍敏捷开发的核心原则、方法和实践。
一、敏捷开发的核心原则1.以人为本：敏捷开发强调人的重要性，包括开发人员、测试人员、产品负责人和客户。
它认为只有当人们能够有效地协作和沟通时，才能实现最大的效益。
2.可持续的开发：敏捷开发追求可持续的开发速度，保持长期稳定的工作节奏。
这需要避免突击和过度工作，以保持团队成员的积极性和效率。
3.适应变化：敏捷开发能够灵活地适应需求变化，因为客户和业务环境的变化是不可避免的。
敏捷团队应该能够快速响应这些变化，以满足客户需求。
4.快速反馈：敏捷开发通过频繁的反馈循环来优化开发过程。
团队成员应该能够及时获得反馈，以便对产品进行持续改进。
5.质量保证：敏捷开发注重质量保证，通过持续测试和代码审查来确保软件质量。
团队成员应该对代码质量负责，并采用自动化工具来提高效率。
二、敏捷开发方法1.Scrum：Scrum是一种流行的敏捷开发框架，它采用迭代式开发方法，将大型项目分解为小的可交付成果。
Scrum团队由产品负责人、开发人员、测试人员和利益相关者组成，他们共同协作完成产品目标。
2.极限编程（XP）：XP是一种以实践为基础的敏捷开发方法，它强调高效率和高质量的软件开发。
XP的核心原则包括简单性、沟通、反馈、勇气和尊重。
XP实践包括测试驱动开发（TDD）、持续集成（CI）和重构等。
3.精益开发（Lean Development）：精益开发是一种旨在消除浪费和提高生产率的开发方法。
它强调价值流分析、持续改进和客户需求，以最小化成本和最大化价值为目标。
精益开发框架包括价值流映射、5S管理、看板管理等。
4.Kanban：Kanban是一种可视化工作流管理方法，它通过可视化板和卡片来跟踪工作进度。
敏捷开发流程与方法
详细描述
06
CHAPTER
敏捷开发的未来展望
数字化转型
随着云计算、大数据和人工智能等技术的发展，敏捷开发将更加注重数字化转型，以满足企业快速响应市场变化的需求。
持续集成与持续交付（CI/CD）
敏捷开发将进一步强化持续集成和持续交付的能力，实现更快速、更可靠的应用程序开发和部署。
微服务和容器化
Kanban是一种可视化工作流的方法，通过看板展示工作进度，帮助团队更好地管理任务和优先级。
Extreme Programming
Extreme Programming是一种完整的敏捷开发方法，强调编程实践和团队文化的改变，以提高软件质量。
04
CHAPTER
敏捷开发的常见方法
01
02
03
04
简介
02
CHAPTER
敏捷开发的核心流程
部署与发布
将开发成果部署到生产环境，进行发布。
评审与反馈
在每个迭代周期结束时，进行评审和反馈，对不符合预期的成果进行调整。
开发与集成
进行编码、测试和集成工作，确保每个迭代周期的成果符合预期。
需求分析
明确项目需求，对需求进行细化，确保团队对需求的理解一致。
迭代计划
原则与实践
DSDM注重业务价值、风险管理和快速反馈，实践包括时间盒迭代、业务人员参与等。
优势
DSDM能够快速响应变更，降低风险并提高业务价值交付。
05
CHAPTER
敏捷开发的挑战与解决方案
VS
在敏捷开发中，需求变更是一个常见的问题，如果处理不当，可能会对项目造成负面影响。
详细描述
为了应对需求变更，敏捷团队需要采取一些策略，如灵活的项目计划、及时调整需求、加强与客户的沟通等。此外，团队可以采用一些工具和技术来管理需求变更，如敏捷需求管理工具、版本控制工具等。通过这些措施，敏捷团队可以更好地应对需求变更，确保项目的顺利进行。
软件开发中的敏捷开发方法使用方法
软件开发中的敏捷开发方法使用方法敏捷开发是一种迭代增量的软件开发方法，旨在通过灵活、敏捷的方式进行项目开发。
它强调团队合作、快速响应变化和交付具备高价值的软件产品。
在敏捷开发中，团队以一种自组织的方式工作，通过短周期的迭代和反馈循环来不断改进和调整项目。
敏捷开发方法的使用方法可以总结为以下几个步骤：1.明确项目需求：在使用敏捷开发方法之前，首先需要明确项目的需求和目标。
这可以通过与客户或利益相关者进行需求讨论和用户故事编写来实现。
用户故事是敏捷开发中的一种需求描述方式，它描述了用户的期望和需求。
明确项目需求将为后续的开发工作奠定基础。
2.构建产品Backlog：产品Backlog是一个包含待开发功能的有序列表，其优先级根据其价值和需求的重要性进行排序。
团队可以根据项目需求和目标，将功能划分为不同的用户故事，并为每个用户故事分配一个相对估算的工作量。
3.迭代规划会议：迭代规划会议是敏捷开发中的一个重要环节，其目的是确定每个迭代的目标和计划。
团队成员根据产品Backlog中的优先级和工作量，共同确定下一个迭代所要完成的用户故事和开发任务。
在会议结束时，团队应该对迭代的目标和计划有一个清晰的认识。
4.迭代开发：迭代开发是敏捷开发的核心活动之一。
在每个迭代中，团队根据迭代规划会议的计划，将用户故事转化为可交付的软件功能。
团队成员之间应该密切合作，共同解决问题和挑战。
每个迭代的最终目标是交付一个可用的、可测试的软件增量。
5.迭代演示和回顾：在每个迭代结束时，团队应该进行迭代演示和回顾。
迭代演示是将已完成的软件功能展示给客户或利益相关者，以获得他们的反馈和意见。
迭代回顾是团队自我评估的过程，团队成员可以根据过去的迭代经验，找出改进的机会和方法。
6.持续集成和测试：敏捷开发强调持续集成和测试的重要性。
团队应该将持续集成和测试纳入开发过程中，以确保代码质量和软件功能的稳定性。
通过频繁的集成和测试，团队可以及早发现和解决潜在的问题，提高软件的可靠性和可维护性。
敏捷开发方法论
敏捷开发方法论敏捷开发是一种以实效为导向的软件开发方法论，旨在通过快速、灵活、协作的方式开发高质量的软件产品。
敏捷开发强调团队合作、寻求变化、持续交付和客户参与，以提高开发过程的效率和产品的质量。
本文将介绍敏捷开发的核心原则、基本流程和常用的敏捷开发方法。
敏捷开发的核心原则敏捷开发有一系列核心原则，其中包括：1. 个体和互动高于流程和工具：敏捷开发注重团队成员之间的沟通和协作，认为人与人之间的交流比流程和工具更重要。
2. 可以工作的软件高于详尽的文档：敏捷开发注重快速交付可用的软件，而不是过多地关注文档编写和规范。
3. 客户合作高于合同谈判：敏捷开发鼓励与客户的紧密合作，以适应变化的需求，并及时调整开发方向。
4. 响应变化高于遵循计划：敏捷开发意味着灵活适应变化的需求，而不是顽固地坚持原定计划。
敏捷开发的基本流程敏捷开发的基本流程通常包括以下几个阶段：1. 需求收集和分析：与客户密切合作，明确软件的需求和期望，将其整理成用户故事或需求清单。
2. 任务规划和分配：将需求转化为可执行的任务，并结合团队成员的技能和资源进行任务的规划和分配。
3. 迭代开发：采用短期迭代的方式进行开发，每个迭代周期通常为两到四周。
开发团队根据优先级和复杂度进行任务的分解和安排。
4. 迭代评审和反馈：每个迭代结束时，团队与客户和利益相关者进行评审，收集反馈并作出相应调整。
5. 总结和改进：通过团队内部的总结会议和回顾活动，不断改进开发过程和团队效能。
常用的敏捷开发方法敏捷开发有多种常用的方法和框架，例如：1. Scrum：Scrum是一种流行的敏捷开发框架，强调团队的自组织和高效沟通。
Scrum将开发分解为固定长度的迭代周期，每个迭代周期称为一个“Sprint”。
2. XP（极限编程）：XP是一种注重迭代开发、测试驱动和持续集成的敏捷开发方法。
XP侧重于高效的开发实践和代码质量。
3. Kanban：Kanban是一种通过最大化可视化和限制工作流量来管理任务和进度的方法。
敏捷开发要点
敏捷开发要点
以下是 6 条关于敏捷开发要点：
1. 小步快跑重要不？那简直太重要啦！就像跑步一样，每次跨一小步，速度反而更快。
咱就说开发的时候，别一下子搞个大目标吓到自己，而是分成一个个小模块，逐个击破。
比如我们做一个软件，先搞定登录界面，再去完善其他功能，这样不是轻松多啦？
2. 用户反馈得重视吧？那必须的呀！用户就像是你的导师，告诉你哪里好哪里不好。
团队成员小张就碰到过，因为没重视用户反馈吃了大亏。
所以呀，要时刻倾听用户的声音，根据他们的意见及时调整，才能让产品更好呀！
3. 频繁沟通牛不牛？超牛的好不好！这就好比大家一起划船，得时刻交流方向才行。
团队里大家要是都闷头干，不沟通还不乱套啦？比如小王和小李，时常分享各自的进展和问题，工作进展得多顺利呀！
4. 快速迭代厉害不？那可是相当厉害呀！就像手机系统不断更新一样，让产品始终保持活力。
我们做项目也是呀，不能一个版本就完事，要不断改进。
就像那回我们的产品上线后，发现一些小瑕疵，赶紧迭代解决，这才赢得更多用户喜欢呀！
5. 保持灵活性神不神？太神啦！就像跳舞一样，要能根据音乐随时变换动作。
开发过程中遇到新情况是常有的事，这时就得灵活应变。
记得有一次客户突然改需求，我们团队立刻调整计划，才没出大乱子呀！
6. 团队协作酷不酷？那简直酷毙啦！这就好像打篮球，每个人都有自己的位置和作用。
要是有人不配合，这球还怎么打？我们团队就是大家相互支持、协作，项目推进得又快又好，牛吧！我的观点就是，敏捷开发就得在这些要点上下功夫，这样才能做出成功的产品呀！。
敏捷开发流程
敏捷开发流程敏捷开发流程是一种以迭代开发主要侧重于软件交付频率、质量和可扩展性核心精神的流程。
它强调在明确的框架内实施设计活动，而不是仅仅由一个计划驱动，它倡导快速反馈的测试、重新设计和调整。
敏捷流程的第一步是分析。
它需要团队收集必要的信息，以确定需要建立的软件及其特性。
一旦分析完成，确定的项目经理或团队领导就可以制定基本的计划和架构。
这个计划应该指定项目的目标，阐明团队工作流程以及选择要使用的软件开发工具和平台。
第二步是设计。
在设计过程中，开发者要研究软件的架构，要决定软件输出格式和视觉形象，要研究软件的功能模块，要考虑软件的安全性和可扩展性问题。
实现是第三步。
实现阶段要求程序员根据设计阶段制定的细节进行软件代码开发，调整及测试。
实现过程要求程序员注重质量，使软件代码更加完整、更加可靠，以及更加稳定。
第四步是测试和质量控制。
在测试过程中，测试人员根据分析和设计中制定的测试策略对软件进行测试。
测试阶段是确保软件质量和稳定性的关键步骤。
第五步是部署和发布软件的步骤。
部署软件时，需要将协调测试，建立稳定的服务器，实施对软件的备份和恢复及系统维护，以及采取一系列安全措施，以确保软件的稳定运行。
第六步是监控和维护。
监控和维护是保证软件正常运行的最后一步，它要求团队定期监控软件性能，以及收集客户反馈，并能够及时研究问题，并做出相应的调整。
迭代、快速反馈和双重测试是敏捷开发软件的核心，其中快速反馈是帮助开发人员及时知晓软件质量和性能的关键步骤，双重测试则提供了一套完整可靠的测试流程，确保软件质量和安全性。
另外，部署和维护也是应用敏捷开发的必要步骤，它可以为软件持续发展提供基础环境。
总之，敏捷开发流程是一种集迭代、快速反馈、双重测试和安全部署、监控和维护于一体的软件开发流程。
它主要用于保证软件交付频率、质量和可扩展性，为后续软件进一步发展提供基础环境。
敏捷知识点总结归纳
敏捷知识点总结归纳敏捷开发是一种灵活的软件开发方法，它注重迅速响应变化、持续交付高质量的软件。
敏捷方法提倡小团队协作、及时反馈和快速迭代，以满足客户不断变化的需求。
下面将对敏捷开发的核心知识点进行总结和归纳。
敏捷宣言和敏捷原则敏捷宣言是敏捷开发的基本指导原则，包括价值个体和交互、响应变化和软件可运行。
而敏捷原则则是指导敏捷团队的决策和行动的基本原则，包括客户满意度、团队合作、面对面沟通等。
敏捷项目管理敏捷项目管理是一种以价值交付为导向的项目管理方法，强调持续交付、适应变化、减少WIP、增加透明度和团队协作。
敏捷项目管理方法包括Scrum、Kanban、XP等。
ScrumScrum 是一种轻量级的敏捷框架，它包括产品待办清单、冲刺计划会、每日站会、冲刺评审会和冲刺回顾会等多个仪式。
Scrum 中的核心角色包括产品负责人、Scrum Master 和开发团队。
KanbanKanban 是一种敏捷工作流管理方法，它强调限制WIP、可视化工作流、管理流量和流动、持续改进和适应等。
Kanban 的核心概念包括看板、WIP 限制、流量管理和服务水平协议等。
极限编程（XP）极限编程是一种敏捷软件开发方法，它包括持续集成、测试驱动开发、双人编程、结对编程、用户故事等实践。
XP 通过团队协作、快速迭代、高质量代码和持续反馈，实现高效开发和高质量软件的交付。
敏捷团队建设敏捷团队建设是一种以团队合作、自组织、学习和成长为核心的团队建设方法。
敏捷团队应该具备自组织能力、开放沟通和透明度、创新和持续学习、快速适应变化等特点。
持续集成和持续交付持续集成和持续交付是一种敏捷软件开发实践，强调频繁集成、自动化测试、持续集成和持续交付。
持续集成和持续交付可以帮助团队及时发现和解决问题、减少集成成本、提高交付速度和质量。
敏捷需求管理敏捷需求管理是一种以客户价值、快速反馈和持续改进为导向的需求管理方法。
敏捷需求管理强调用户故事、优先级和价值、迭代开发和快速反馈，使团队能够及时满足客户不断变化的需求。
Scrum敏捷开发流程的介绍
Scrum敏捷开发流程的介绍Scrum是一种敏捷开发流程，是一种在软件开发中普遍使用的方法论。
Scrum流程的目标是通过增强团队的激情、创造力和自发性，从而改善软件开发的效率和质量。
本文将详细介绍Scrum 流程。
一、Scrum概述Scrum可以看作是一种轻量级框架，可以帮助开发团队高效工作。
它主要包括三个角色：产品负责人、开发团队和Scrum Master。
产品负责人负责管理产品需求，开发团队负责开发和交付软件，Scrum Master负责协调各方面工作，监督流程。
Scrum流程包括三个阶段：Sprint计划、Sprint执行和Sprint回顾。
具体的流程如下：1. Sprint计划Sprint计划阶段主要是确定下一个迭代周期要完成哪些任务，以及如何完成这些任务。
产品负责人会列出需求列表，并根据需求优先级进行排序。
开发团队会根据需求列表制定Sprint目标，并确定完成Sprint所需的任务。
任务列表包括任务的描述、工作量估算和责任人。
2. Sprint执行Sprint执行阶段是开发团队执行任务的阶段。
每天开发团队会进行日常站会，讨论当天要完成的工作和可能遇到的问题。
开发团队会根据任务列表完成对应的任务，并进行代码评审、单元测试等工作。
如果完成任务，开发团队会将任务标记为“完成”。
3. Sprint回顾Sprint回顾阶段是开发团队评估所完成的任务，确定下一个迭代周期需要做出哪些改变。
开发团队会讨论哪些任务没有完成，以及未完成的原因。
这些原因可能是技术问题、需求变更或者其他因素。
二、Scrum流程的优缺点Scrum流程的优点：1. 提高开发团队工作效率Scrum的强调在于快速地交付可用的产品，从而保证团队的工作效果。
2. 提高成员工作积极性在Sprint执行阶段，开发团队在站会上交流意见，相互协作，这种方式极大地激发了开发团队的积极性。
3. 高度透明和协作Scrum流程把所有需求和任务都放在一个任务列表中，所有人都可以看到，这样可以大大提高协作效率。
敏捷开发流程(自己总结)
敏捷开发流程(自己总结).doc敏捷开发流程（自己总结）引言敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。
在快速变化的市场和技术环境中，敏捷开发能够帮助团队迅速响应变化，提供高质量的软件产品。
本文将总结敏捷开发流程的关键步骤和实践。
敏捷开发的核心原则个体和互动高于流程和工具，敏捷开发强调团队成员之间的沟通和协作。
可工作的软件高于详尽的文档，敏捷开发注重提供持续交付的可工作软件。
客户合作高于合同谈判，敏捷开发倡导与客户紧密合作，以满足客户需求。
响应变化高于遵循计划，敏捷开发鼓励团队在开发过程中灵活应对变化。
敏捷开发流程的关键步骤1. 产品愿景和目标设定在项目开始之初，明确产品愿景和目标，确保团队成员对项目有清晰的认识。
2. 产品待办事项列表（Product Backlog）创建产品待办事项列表，列出所有潜在的功能和需求，并根据优先级排序。
3. 冲刺计划（Sprint Planning）每个开发周期（冲刺）开始时，团队选择产品待办事项列表中的项，确定冲刺目标。
4. 每日站立会议（Daily Stand-up）团队成员每天进行简短的站立会议，分享进度、计划和遇到的障碍。
5. 任务分配和执行根据冲刺计划，团队成员分配任务并开始执行，确保任务按时完成。
6. 冲刺评审（Sprint Review）在每个冲刺结束时，团队展示冲刺成果，收集利益相关者的反馈。
7. 冲刺回顾（Sprint Retrospective）团队回顾冲刺过程，识别改进点，制定行动计划以优化下一个冲刺。
敏捷开发的关键实践持续集成频繁地将代码变更集成到主分支，确保代码的稳定性和可维护性。
测试驱动开发（TDD）先编写测试用例，再编写功能代码，确保代码质量和功能正确性。
代码重构不断改进代码结构，提高代码质量和开发效率。
版本控制使用版本控制系统管理代码变更，支持团队协作和历史追踪。
用户故事和验收测试使用用户故事来描述功能需求，编写验收测试来验证功能实现。
敏捷开发--工作流程的梳理
敏捷开发--⼯作流程的梳理2019年08⽉09⽇，上海受台风利奇马的影响，晚间狂风⼤⾬。
临下班，合作渠道WB在微信群⾥报告线上⽣产事故问题：赶快扒⽇志看记录，⽇志显⽰⼀切正常，看不出bug在哪⾥，WB声称并未接收到我⽅CI的回调请求。
晚七点多，肚⼦已经饿了，给WB说，看⽇志CI没啥问题，先撤了。
在出公司⼤楼经过⼀个拐⾓的时候，隐隐感觉这情形代码⾥的配置项会不会有问题，⼼⾥很是忐忑，冒⾬⼜折回。
重新打开电脑，再捋⼀遍代码的时候，bug像⼀道⼔⾸直刺⼼头：卧槽，这个路径竟然还是测试环境的路径！项⽬组是公司敏捷开发团队，每周五都会有⽣产版本发布，赶快给负责版本控制的同事打招呼，等⼀下，搭个顺风车。
在确定了配置路径有问题之后：亟待明确的是服务间调⽤是⾛内⽹还是⾛外⽹，要不要NG转发，⾛不⾛esb，是不是要申请通信权限。
简单描述⼀下WB的该次请求：WB请求CI的NG--------》NG转发到CI的Mule服务----------》Mule服务调⽤Gateway----------》Gateway转发⾄应⽤微服务Application ---------》Application服务响应之后执⾏异步回调Mule服务---------》Mule服务请求WB接⼝地址。
中间涉及的防⽕墙和权限就暂且忽略，⽬前的问题点是：Application服务响应之后执⾏异步回调Mule服务，这个Mule服务内部接⼝地址规范是什么，会负责系统维护的同事⼀番确认后，决定⾛内⽹Mulef5，这个时间点负责维护配置中⼼的同事已经下班了，当务之急硬编码的⽅法先上了。
九点多回到家，觉得有必要复盘⼀下为什么会遗留这种bug，2018年11⽉份进⼊CI公司的敏捷开发团队。
刚⼊司时对敏捷开发基本不了解，后来才发现这是⼀种近乎流⽔线的开发模式。
作为开发可以说是⼀个不停机的多线程，从⼀个合作业务开发要介⼊需求沟通、⽹络申请、防⽕墙权限申请、配置维护、数据维护、多环境测试联调、线上⽀持。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
敏捷开发日常跟进系列之一：燃尽图（上）这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。
日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。
在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。
燃尽图燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量吗”的时候，第一反应就是它。
燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。
图中左侧460是迭代开始的第一天，所有故事的未完成时间相加为460天，而在最右侧则表明在第17天，所有故事的剩余时间相加变为0，也就是所有故事都完成了。
为什么总和会递减呢？因为每个组员每天都要汇报一件事情：当前正在做的故事，还剩余几天，如果昨天剩余3天，今天剩余2天，那么就为燃烧图贡献了1天的进度。
由于可能出现“昨天剩余3天，又工作了一天后本以为会只剩下2天，结果感觉可能还要3天（甚至变成5天了！）”这种情况，所以燃尽图常常有一些起伏。
燃尽图的“指纹”图中的燃尽图尽管有一些起伏，依然是属于比较完美的燃尽图。
实际上每个团队完成迭代的过程差别很大，常见的情况包括：先鼓起后落下原因是计划会以常常漏掉一些事情，所以开工后不但不燃尽，还发现了很多新的任务。
先完美燃烧，然后突然停止燃烧一种很常见的情况，如果任务划分太粗，比如长达10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的时候，哎呀，好像搞不定了”。
先缓慢燃烧，然后到快燃尽的时候剩下一堆没完成的任务，被推迟到下个迭代之前提到过敏捷开发的MoSCoW方法，有些故事是次要的“可以不做的”，所以这种燃烧图也很常见；但是常常有团队没有使用MoSCoW方法，只是被动地发现有些故事没有完成。
……为了改进这些不完美，有些团队设置了一些度量项来改进燃尽图的结果，比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……其实不用因为燃尽图的不完美而伤脑筋，在般若敏捷的“无住”中曾经提到，这些方法都非我们的目的，而只是一个中间的工具，因此为了完成我们的最终目的，这些工具和方法都可以灵活变通，而不要追求工具和度量数据本身的完美。
但是，迭代的最终目的到底是什么呢？有哪些“灵活变通”可以应用在燃尽图中呢？且待下回分解。
敏捷开发日常跟进系列之二：燃尽图（中）迭代及燃尽图的目标燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？1. 按产品经理的要求，交付计划会中计划的用户故事2. 尽量完成1之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。
为什么燃尽图不能直接地达成这个目标？潜在的问题包括：1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。
2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。
3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。
只从燃尽图的形态看，是无法提前识别这三者的，也就因此带来了很多的风险，到迭代的末尾让人大吃一惊。
怎么办呢？“阶梯燃尽图”之前听过这个方法，但是刚才在网络上没有找到图片。
方法就是在每个故事完成的时候才把整个故事突然剪掉，从而形成阶梯状。
阶梯状燃烧图的缺点也很明显：刚开始的时候很难看到有燃尽，甚至那些向上拱起的弧形也被掩盖了，日后回顾时，一些细节也很难记起来。
所以一种解决方案，是把普通燃尽图和阶梯燃尽图混合使用，就是同时画两条线。
“跟进图”跟进图是一些大型团队的创造，由于团队巨大，所以不能指望在迭代的最后用2小时评审完所有工作，所以常常是做完一个评审一个，这就要给每个工作分配一个“跟进人”，他隶属产品部门，没事就盯着“跟进图”看看有没有自己关心的工作做完了。
在为一家游戏公司提供咨询的时候，他们一款产品的团队人数高达88人（另一个甚至到了200人），墙上就用手绘制了一幅巨大的跟进图，每天更新动态，甚至直接在纸上画上小图标，每月画满了，就重新打印一张。
下面这张，是火星人中的跟进图。
图中绿色粗线，就是传统的燃尽图；每当一个故事完成，就会有一个蓝色的标记及完成故事的名字，从而提醒跟进人进行现场预评审；如果长期没有故事完成，燃烧图却还在燃烧，就肯定出现了之前说过的问题了。
右下部分还有一个暗红色的细线，是“溢出时间”，就是超出预期的工作的时间，表明这段时间出现了新的任务；新任务出现的太早不好，因为一般在迭代前期都先完成最重要的故事，不应该引入新任务；但在后期随着最重要的故事完成、评审、因不满意而返工，团队会倾向于把最重要的任务更好地完成，而非草草地把所有故事都凑合完成，在产品研发中，这往往是更能提升产品价值的。
一家叫做广联达的公司在实践中把溢出时间作为负数倒着画，称为“基线下沉”，就是说要去的地方不是0了，而是那个负数，是一个类似目的的很好的实践。
我试了一下也不错，就是图表会变高，显示起来不方便，所以还是改了回来。
这样的跟进图看起来已经很强大了，但是还有一些问题没有解决：1. 有哪些故事正在做，还没有做，已经开工了但没完成……？2. 最后剩下了哪些故事没完成？3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）4. 如果有跟进人，谁负责跟进哪个？有些问题需要后面的故事板（看板）解决，有些则需要一个叫做“跟进表”的东西，之后我们说完故事板再回来详细说明。
敏捷开发日常跟进系列之三：故事板，看板故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。
但是在敏捷开发里边提到这两样东西，可以认为大致相同。
故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。
故事板的用法要解决的问题故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：1. 有哪些故事正在做，还没有做，已经开工了但没完成……？故事板的三列正好解决问题。
2. 最后剩下了哪些故事没完成？最左边剩下的就是。
3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）这个复杂一些，下面讲。
同时开工很多故事，很容易造成思绪散乱、最后全部完不成的情况，确切说瀑布模型就是同时开工所有故事的典范。
为了防止这一点，如果是手工做的故事板，，那么注意中间一个“正在做的”列一点要窄一些，这样当里边的故事挤不下的时候，就是一个危险的很多故事都在开工的信号。
还有一种做法，是每个人只准放一个故事在中间，做完一个，才能再做一个。
这个严格坚持有难度，因为经常遇到被卡住的情况，但是作为一种思路和精神应该尽量坚持。
4. 如果有跟进人，谁负责跟进哪个？可以在卡片上写上当前负责人、跟进人的名字。
通常的做法有很多种，比如每个人用自己颜色的即时贴，可以比较容易地看出每个人有多少个故事，分别处于什么状态。
不过，这样就需要在“尚未开始的”里边提前分配人员了，不太利于后期的互动和互相关注；当然还可以在开始的时候重新用有颜色的即时贴重新抄一个，看大家的习惯了。
介质尽管有很多故事板/看板工具，使用纸质方法仍然是一个很好的选择，原因就是作为“迭代中的任务”这种东西，其生存期很短，基本上2个月后价值为0，人们也就用纸片来对付了。
不过如果想在未来做几件事情，那么及早采用电子故事板/看板还是有必要的，这些事情包括：1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等2. 大型团队，分布式团队3. 希望留下历史数据作为以后估算的参考值和参考故事下面这个是免费工具火星人中的故事板，做了两个案例来说明一下情况。
上面这个图是不好的情况，开发中的故事一大堆，没几个完成的，很容易造成最后所有故事都差一点。
下面这个要好的多，每个人只开工了1个（每种底色是一个人，案例中只有cheny和yock 两个人），剩下的要末完全做完了，要么一点没做，即使到期末不能全部完成，也不会把太多时间卡在半截的故事上。
2012-03-07补充：昨天下午仔细调整了美术效果，现在的故事板外观如下：更多敏捷开发日常跟进系列之四：跟进表这是敏捷开发日常跟进系列的第四篇。
（栏目目录）跟进表是大型敏捷团队的一种实践。
在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。
跟进表以上面的网络游戏团队为例，说明一下跟进表上的信息：1. 哪些故事完成了在故事板中也能表达，但缺少结构性。
故事板中的故事都是平等的，较难显示大小、父子包含关系等。
2. 谁在跟进案例中这个人一般是策划人员，故事的创建者和验收者。
3. 谁在开发案例中这个一般是若干个开发人员、脚本、美术的群体，也可能只有其中一个工种。
4. 某个任务大概可能在何时开始、结束。
在故事板、燃尽图上均无法表达。
5. 哪些故事被搁置了可能遇到了困难，也可能有其他原因，甚至可能做了一半干别的被忙忘了。
……实例这是一个在“火星人”研发中已经完成的迭代的跟进表案例。
实例一我们先看看这个迭代的燃尽图（看不清楚请右键-图片另存为后观看）：对于跟进图的5个作用，上面这个已经扩展了的燃尽图只能完成第一个，就是“哪些故事完成了”，而一般的燃尽图连这个作用也没有。
为了完成另外四个目标，就需要下面的跟进表。
先看左边的蓝框，里边是所有迭代中的故事（Sprint Backlog），为什么要显示成这个树状结构呢？因为如果是小团队，只有10～20个故事，那么人们即使从只有3个字的故事名称比如“新界面”上，大家也能记住和理解说的是什么意思。
但是如果故事多了，就比较困难，会导致故事的名字不得不很长，比如“计划会-讲解故事-的新界面”，而这样表达看似还行，但由于没有清晰的父子包含关系，多了也乱。
所以蓝框中以父子关系的方式表达，对于大型产品的研发更清晰一些。
蓝框右边两列是负责人（对应跟进人，案例中的策划人员）和当前负责人（开发人员），由于我们的团队小，不存在两个部门，所以没有设置跟进人，所以也就没有“负责人”。