敏捷开发流程(自己总结)
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论，它强调团队合作、快速响应变化和持续交付价值。
在敏捷开发过程中，有以下8个主要步骤。
1. 需求收集与分析在敏捷开发中，需求是一个动态的过程，不断地收集、分析和细化。
团队与客户紧密合作，明确项目的愿景和目标，并将其转化为用户故事或需求项。
通过不断的讨论和反馈，团队可以更好地理解客户需求，并将其转化为可执行的任务。
2. 规划与估算在敏捷开发中，规划是一个迭代的过程。
团队根据客户需求和项目目标，制定短期的开发计划，确定每个迭代的工作范围和目标。
同时，团队也需要对工作量进行估算，以便更好地安排资源和时间。
3. 设计与开发在敏捷开发中，设计和开发是并行进行的。
团队利用迭代周期进行软件设计和编码，采用简单而优雅的解决方案。
团队成员经常进行代码审查和知识分享，以确保代码的质量和可维护性。
4. 测试与验证在敏捷开发中，测试是一个持续且重要的过程。
团队进行单元测试、集成测试和系统测试，以确保软件的质量和功能完整性。
同时，团队也需要与客户进行验证，确保软件满足客户的需求和预期。
5. 交付与部署在敏捷开发中，交付和部署是一个可重复且自动化的过程。
团队使用持续集成和持续交付的工具和方法，将软件快速交付给客户。
同时，团队也需要确保软件能够顺利地部署和运行。
6. 反馈与优化敏捷开发强调不断地学习和改进。
团队与客户保持密切的沟通，收集用户反馈和需求变更。
团队通过迭代回顾和持续改进的方式，优化软件的功能和性能。
7. 沟通与协作在敏捷开发中，沟通和协作是非常重要的。
团队成员之间需要密切合作，共同解决问题和完成任务。
团队与客户之间也需要建立良好的沟通渠道，保持及时的反馈和信息共享。
8. 迭代与持续交付敏捷开发是一个持续迭代的过程。
团队通过多次迭代的方式，逐步完善软件，持续交付价值。
团队通过反馈和学习，不断优化和改进软件的质量和功能。
总结敏捷开发是一种灵活、高效的软件开发方法论。
敏捷测试流程
敏捷测试流程敏捷测试是一种在敏捷开发环境下进行的软件测试方法，它强调及时反馈、快速响应和持续改进。
在敏捷测试中，测试团队需要与开发团队紧密合作，以确保软件质量和用户体验。
下面将介绍敏捷测试的流程及其关键步骤。
1. 确定测试范围。
在进行敏捷测试之前，首先需要确定测试的范围。
这包括确定要测试的功能模块、需求和用户故事。
测试团队需要与产品所有者和开发团队进行充分沟通，确保对测试范围有清晰的了解。
2. 制定测试计划。
制定测试计划是敏捷测试流程中的关键步骤。
在制定测试计划时，测试团队需要考虑测试资源、时间安排、测试工具的选择以及测试策略的制定。
测试计划需要与开发团队的迭代计划相一致，以确保测试工作能够与开发工作同步进行。
3. 编写测试用例。
编写测试用例是敏捷测试流程中的重要环节。
测试用例需要覆盖用户故事的各个方面，包括正面测试、边界测试和异常情况测试。
测试用例需要清晰、详细，并且易于理解和执行。
4. 进行测试执行。
在测试执行阶段，测试团队需要按照测试计划和测试用例进行测试。
测试团队需要及时发现并报告软件中的缺陷，并与开发团队进行有效的沟通，以便缺陷能够及时修复。
5. 进行回归测试。
在软件发生变更时，需要进行回归测试以确保修改后的软件没有引入新的缺陷。
回归测试需要覆盖修改的功能模块，并且需要在较短的时间内完成，以确保软件质量和发布进度。
6. 进行验收测试。
在软件开发的最后阶段，需要进行验收测试以确保软件满足用户的需求和期望。
验收测试需要与产品所有者和最终用户紧密合作，以确保软件的质量和用户体验。
7. 进行持续改进。
在敏捷测试流程中，持续改进是非常重要的环节。
测试团队需要及时总结经验教训，发现并解决测试过程中的问题，并不断优化测试方法和流程，以提高测试效率和软件质量。
总结。
敏捷测试流程是一种灵活、高效的软件测试方法，它强调快速响应和持续改进。
在敏捷测试流程中，测试团队需要与开发团队紧密合作，制定测试计划、编写测试用例、进行测试执行、回归测试和验收测试，并不断进行持续改进。
敏捷开发具体流程
敏捷开发具体流程嗨，朋友！你要是想知道敏捷开发是个啥流程，那你可算找对人了。
我就像一个在敏捷开发战场上摸爬滚打多年的战士，今天就把这其中的门道给你好好唠唠。
咱先得有个产品愿景啊。
这就好比咱们要盖一座大楼，那得先有个大楼建成之后的美好蓝图在心里。
比如说我们团队要开发一个全新的手机APP，那这个APP最终要达成啥样的功能，要给用户啥样的体验，这就是产品愿景。
老板或者产品负责人就像那个领航员，“嘿，大家听着啊，咱们这个APP得是那种用户一打开就觉得超酷，操作特别简单又功能强大的东西。
”团队成员们听了，眼睛里就开始冒星星，充满了期待。
接下来就是创建产品待办事项列表。
这就像是给大楼准备建筑材料的清单。
产品负责人会和各个相关的人员，像开发人员、测试人员、市场人员等坐在一起。
开发人员可能会说：“哎，要实现这个功能，后端得有这样那样的接口。
”测试人员也会插一句：“那这个功能得有明确的测试标准才行。
”市场人员则想着：“这功能得符合用户需求，还得能吸引用户眼球呢。
”大家七嘴八舌地讨论，把所有要做的事情都列出来，从大的功能模块到小的细节优化，都在这个清单里。
有了这个清单，就到了冲刺计划会议。
这时候就像一场紧张又刺激的战前部署。
团队成员们聚在一起，看着产品待办事项列表，就像看着一堆宝藏等着去挖掘。
大家开始挑选在这个冲刺周期里要完成的任务。
开发人员会根据自己的能力和经验，说：“我觉得我这个周期能搞定这个功能模块和那个小优化。
”测试人员也不含糊：“那我这边就负责把这些新功能的测试给包了。
”这就像在战场上，每个士兵都认领自己的任务一样。
然后呢，开发过程就开始啦。
开发人员就像一群勤劳的小蜜蜂，嗡嗡嗡地开始干活。
他们会把大的任务分解成一个个小的任务，就像把一块大蛋糕切成小块一样。
在这个过程中，每天都会有个简短的站会。
大家站成一圈，就像一群朋友在聊天。
开发人员会说：“我昨天完成了这个小功能的一半，今天打算把它彻底搞定，不过可能会遇到点小麻烦，需要和数据库那边再对接一下。
敏捷开发流程的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中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
敏捷开发方法学习与实践指南
敏捷开发方法学习与实践指南第一章：敏捷开发方法简介1.1 敏捷开发的概念和目标敏捷开发是一种以快速迭代和灵活性为基础的软件开发方法，旨在提高团队效率和客户满意度。
1.2 敏捷开发的优势和适用场景敏捷开发可以帮助团队更好地应对需求变化和市场竞争，适用于复杂、动态和高风险的项目。
第二章：敏捷开发方法的实施步骤2.1 项目准备阶段明确项目目标和范围，确定敏捷开发团队成员，制定项目计划和迭代周期。
2.2 需求管理与分析与客户密切合作，收集和整理需求，制定用户故事，优先级排序和计划发布。
2.3 迭代开发与管理每个迭代周期内，团队完成需求开发、单元测试和集成测试，持续交付可工作软件。
2.4 持续集成与交付团队借助自动化工具和流程，实现软件的频繁集成和交付，及时反馈项目进展和质量问题。
2.5 风险管理与质量保证敏捷开发注重风险管理和质量保证，通过持续集成、自动化测试和代码审查等方式降低项目风险和提高软件质量。
2.6 客户反馈与持续改进在每个迭代周期结束后，团队与客户进行回顾会议，总结经验教训，及时调整和改进工作方式。
第三章：敏捷开发方法的关键实践3.1 Scrum框架介绍Scrum框架的核心概念和实施步骤，包括产品负责人、Scrum团队和Sprint Planning等。
3.2 Extreme Programming (XP)介绍XP在敏捷开发中的应用，包括测试驱动开发（TDD）、持续集成和重构等。
3.3 Kanban方法介绍Kanban方法的原理和实施步骤，通过可视化管理工作流程和限制工作进程来提高团队效率。
3.4 DevOps实践介绍DevOps的核心原则和实施步骤，包括自动化部署、持续集成和持续交付等。
3.5 用户故事和敏捷统计介绍用户故事的编写和管理方法，以及如何使用敏捷统计工具追踪项目进展和团队绩效。
第四章：敏捷开发方法的实践案例分析4.1 互联网项目开发案例分析以某个互联网公司的产品开发为例，详细介绍其采用敏捷开发方法的实践过程、挑战和成果。
敏捷开发方法教程
敏捷开发方法教程敏捷开发（Agile Development）是一种以人为核心、快速迭代、灵活应变的软件开发方法。
它强调团队协作、持续交付和快速反馈，可帮助开发团队更好地应对需求的变化，提高项目的成功率。
本教程将介绍敏捷开发的基本原则、常用方法和最佳实践，帮助读者全面了解敏捷开发的精髓。
一、敏捷开发简介敏捷开发起源于1990年代的极限编程（Extreme Programming）方法，在过去几十年中不断演化和发展。
与传统的瀑布模型相比，敏捷开发注重快速迭代和用户参与，能够更好地应对需求变化和项目风险。
二、敏捷开发原则敏捷开发遵循以下核心原则：1. 个体和互动高于流程和工具：注重团队协作和沟通，激发创造力和创新。
2. 可以工作的软件高于详尽的文档：通过快速迭代交付价值，提供及时的产品演示和用户反馈。
3. 客户合作高于合同谈判：与客户积极合作，灵活应对需求变化和优先级调整。
4. 响应变化高于遵循计划：在需求变化时调整方向，保持高度灵活性和可调整性。
三、敏捷开发方法敏捷开发有多种方法和框架，下面介绍几种常用的方法：1. 极限编程（Extreme Programming，简称XP）：强调团队合作、持续集成和测试驱动开发（TDD）等实践，推崇简单和高质量的设计。
2. Scrum：通过定义角色、仪式和工件等，实现实时掌控项目进度和风险。
将项目拆分为若干个迭代周期（Sprint），每个迭代周期都可以交付部分功能。
3. 敏捷建模（Agile Modeling）：强调可视化和简化的建模技术，帮助团队更好地理解问题和需求。
4. 结对编程（Pair Programming）：两位开发者合作完成一个编码任务，提高代码质量和团队协作效率。
四、敏捷开发实践实践是敏捷开发成功的关键，以下是几个重要的实践建议：1. 迭代开发：将开发工作划分为若干个迭代周期，每个迭代都能交付可工作的软件。
每次迭代结束后，团队根据反馈进行优化和调整。
敏捷开发流程
敏捷开发模型厂[1.需求5■测试] 2■计划| ] 一，―,迭代（3-4周）、/ 〔I循环迭代发布使用条件：需求和范围难以事先确定，或者在开发过程中存在较多变更的项目1.首先确定项目未完项中，哪些应该最优先在下一次迭代中交付。
每一个迭代看作是完整的项目生命周期，看作整个项目的子项目。
敏捷开发的特点：1.适应性：适应项目的变更2.面向资源：资源固定不变，根据资源调整计划和需求3.增量性：随着对需求理解的深入，在迭代中定义增量改进，循序渐进的完成项目。
范围（需求）发动变动时，时间和成本也会相应变动；成本变动时，范围和时间也会相应变动时间变动时，范围和成本也会相应变动范围管理敏捷模式下，项目的需求是不断开发、逐渐清晰的过程；项目初期只能定义总体上的需求，具体的需求设计在各个迭代中依次展开定义范围就是把这些逐渐清晰的需求定义到相应的迭代中，并确定做且只做的工作;时间管理定制时间计划时，排列工作优先级，估算资源，估算工作时间，控制进度。
敏捷开发的迭代时间固定不变，因此需要制定工作优先级排序，以确定可完成和未完成 的工作，并在迭代的开始确定未完成工作哪些应该最优先在下一个迭代中交付。
成本管理在资源固定不变的条件下，在不同的迭代中，工作包的优先级以及需求的优先级影响 各个迭代中工作的进度。
为了确保各个迭代能够在规定的时间内交付范围内的工作，根 据迭代中需求或者工作包的优先级，调整、重组和优化资源就是敏捷开发中成本管理的 关键，也是项目成本管理中控制成本的的一部分。
信鼻工作时闾 确定未完成工作包开发制定变更谜度计划择列工作优先畿 估算资源敏捷开发循序渐进的特征使得在不同时期不同迭代中可以分别引入项目所需的角色，某 一迭代中存在的角色在迭代结束后可以退场。
例如：项目初期的迭代中需要UI 设计， 而在项目后期的迭代中，释放UI 设计的资源，引入UAT 测试人员。
项目中所有的资 源成本需要在项目的开始阶段估算完毕，在项目的各个迭代中进行分配调整。
敏捷开发迭代流程及其核心价值
敏捷开发迭代流程及其核心价值敏捷开发的迭代流程包括需求分析、规划、设计、开发、测试和发布等多个阶段，每个阶段都包含多个迭代周期。
在每个迭代周期内，团队会根据客户需求和项目目标制定具体的任务和计划，并在周期结束时进行评审和反馈，然后根据反馈结果对下一个迭代周期进行调整和优化。
通过不断迭代的方式，团队能够及时发现和解决问题，逐步改进产品，最终实现客户需求的满足。
下面将详细介绍敏捷开发的迭代流程及其核心价值。
1. 需求分析阶段需求分析是敏捷开发的第一个阶段，团队需要通过与客户沟通和讨论，了解客户的需求和期望，然后将需求转化为可执行的任务和计划。
在这个阶段，客户需求的准确理解和表达是非常重要的，团队需要通过不断的沟通和协作来确保需求理解的一致性。
同时，团队还需要根据客户需求的优先级制定任务计划，并确保任务的可执行性和时间可控性。
在这个阶段，团队往往会制定一个需求规格说明书或者用户故事地图，将客户需求清晰地表达出来，并作为后续迭代周期的指导。
在需求分析阶段，团队迭代的核心价值在于及时理解和满足客户需求，通过不断的迭代和优化，确保产品能够满足客户的期望，并且减少因需求变更而产生的成本和风险。
通过迭代周期的持续交付，团队能够更好地适应客户需求的变化，提高产品的交付速度和灵活性。
2. 规划阶段规划阶段是敏捷开发的第二个阶段，团队需要根据需求分析的结果制定具体的任务计划和迭代周期，确保任务的合理分配和时间的可控性。
在这个阶段，团队需要对任务的复杂度和风险进行评估，并制定相应的开发策略和计划。
同时，团队还需要根据客户需求的优先级，确定产品功能的发布顺序和时间表，保证产品能够按时交付和满足客户需求。
在规划阶段，团队迭代的核心价值在于制定合理的任务计划和时间表，确保团队能够按时交付高质量的产品。
通过不断的迭代和优化，团队能够及时发现和解决规划中的问题，确保产品开发的可控性和效率性。
3. 设计阶段设计阶段是敏捷开发的第三个阶段，团队需要根据规划结果制定具体的产品设计方案和技术实施方案，确保产品的功能和性能能够满足客户需求和期望。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
敏捷开发的相关简介敏捷定义Scrum是一个轻量级的软件开发方法Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。
在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。
在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。
Scrum的开发团队总是先开发的是对客户具有较高价值的需求。
在每个Sprint 中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。
Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。
在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。
敏捷的原则个体与交互胜过过程与工具可以工作的软件胜过面面俱到的文档客户协作胜过合同谈判响应变化胜过遵循计划这四句价值观用语句表达就是：自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件。
胜过与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求。
《敏捷宣言》12条原则1.最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。
2.欢迎需求变化，甚至在开发后期。
敏捷过程控制、利用变化帮助客户取得竞争优势。
3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。
4.在整个项目中业务人员和开发人员必须每天在一起工作。
5.以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作。
6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。
7.可用的软件是进展的主要度量指标。
8.敏捷过程提倡可持续发展。
发起人、开发者和用户应始终保持稳定的步调。
9.简化——使必要的工作最小化的艺术——是关键。
10.持续关注技术上的精益求精和良好的设计以增强敏捷性。
11.最好的架构、需求和设计产生于自我组织的团队。
12.团队定期地对运作如何更加有效进行反思，并相应地调整、校正自己的行为。
敏捷的角色1产品负责人产品负责人（Product Owner）的职责如下：•确定产品的功能。
•决定发布的日期和发布内容。
•为产品的ROI负责。
•根据市场价值确定功能优先级。
•每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。
•接受或拒绝接受开发团队的工作成果。
2 ScrumMaster作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。
他必须:•保证团队资源完全可被利用并且全部是高产出的。
•保证各个角色及职责的良好协作。
•解决团队开发中的障碍。
•做为团队和外部的接口，屏蔽外界对团队成员的干扰。
•保证开发过程按计划进行，组织Daily Scrum, Sprint Review and Sprint Planning meetings。
3 Team负责产品的开发•一般情况人数在5-9个左右•团队要跨职能（包括开发人员、测试人员、用户界面设计师等）•团队成员需要全职。
（有些情况例外，比如数据库管理员）•在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
•高度的自组织能力。
•向Product Owner演示产品功能。
•团队成员构成在sprint内不允许变化。
•团队整体向产品开发负责。
敏捷工件1、Product Backlog有优先级的故事列表，并估算故事点产品订单：产品订单（Product Backlog）是整个项目的概要文档，它包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。
产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并作出预估。
预估值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个冲刺的最高优先等级条目的预估会非常精确。
产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。
而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品适用性、实用性和竞争性。
2、Sprint Backlog当前Sprint要完成的任务列表，并估算工时• 团队成员自己挑选任务，而不是指派任务• 对每一个任务，每天要更新剩余的工作量估算• 每个团队成员都可以修改Sprint backlog，增加、删除或者修改任务冲刺订单：冲刺订单是大大细化了的文档，用来界定工作或任务，定义团队在 Story 中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。
冲刺订单在冲刺规划会议中形成，其包含的不会被分派，而是由团队成员签名认领他们喜爱的任务。
任务被分解为以小时为单位，没有任务可以超过 16 个小时。
如果一个任务超过 16 个小时，那么它就应该被进一步分解。
每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其内容。
3、发布燃尽图直观反应当前发布剩余的工作量，以Sprint周期数和故事点数为单位。
燃尽图（Burndown Chart）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显示当前冲刺中随时间变化而变化的剩余工作量（可以是未完成的任务数目，或在冲刺订单上未完成的订单项的数目）。
剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。
我们可以借助它设想在增加或减少发布功能后项目的情况，我们可能缩短开发时间，或延长开发期限以获得更多功能。
它可以展示项目实际进度与计划之间的矛盾。
4、Sprint燃尽图Sprint燃尽图直观的反映了Sprint过程中，剩余的工作量情况，Y轴表示剩余的工作，X轴表示Sprint的时间。
随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。
Sprint过程1、Sprint计划会议•团队从产品backlog中挑选他们承诺完成的条目。
（做什么）•创建Sprint Backlog （怎么做）•标识具体的任务并为任务做估算•由团队协作完成，而不是ScrumMaster•考虑了高层设计2、Scrum每日站会团队每天进行15分钟的检验和适应的会议称为Scrum每日站会。
每日站会上，每个团队成员需要汇报以下三个问题：•从上次会议到现在完成了哪些工作。
•下次会议前准备完成什么。
•工作中遇到了哪些障碍。
汇报的对象是团队，不是任何一位领导（PO,SM,团队负责人）。
汇报的重点在于提出问题，进而解决。
每日站会不是进度汇报会议，这个会议是为将产品backlog条目转化成为增量的人（团队）召开的。
团队承诺实现Sprint目标和完成产品Backlog条目。
每日站会是检验朝向Sprint目标的进程，如果有必要进行后续会议对Sprint中的下一步工作进行调整，目的在在于增加团队实现目标的可能性。
这是Scrum经验过程中的重要检验和适应的会议。
3、Sprint评审会议Sprint评审会议用来演示在这个Sprint中开发的产品功能给Product Owner.Produc Owner会组织这阶段的会议并且邀请相关的干系人参加。
•团队展示Sprint中完成的功能•一般是通过现场演示的方式展现功能和架构•不要太正式•不需要PPT•一般控制在2个小时•团队成员都要参加•可以邀请所有人参加4、Sprint回顾会议Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。
•团队的定期自我检视，发现什么是好的，什么是不好的。
•一般控制在15-30分钟•每个Sprint都要做•全体参加• Scrum Master•产品负责人•团队•可能的客户或其它干系人开发流程敏捷的开发流程1首先组建scrum团队（5-9人）2 确定团队成员职责（scrummaster,po,team）3需求设计分析，列出product backlog,格式如下:ID NAME IMP EST HOW TO DEMO NOTES注意事项：DEEPDetailed appropriately(粗细适中)：指将当前优先级高的功能模块尽量细化，而相对优先级较低的功能模块，只需要知道大体功能点既可。
Estinnated(估算过的)：对每个功能点进行估算。
Emergent(涌现的)：功能模块随着开发的推移是变化的，因此每次迭代完成都要重新调整。
Prioritized(排好优先级的)：将功能模块根据商业价值进行排序。
产品功能模块的优先级最好用（10，20，30计算），方便需求变更，附加功能插入。
4 sprint planning-想要什么以及为什么？5 选择部分product backlog（优先级）作为当前sprint的sprintbacklog，并创建sprint面板。
6 sprint准备会，确定每个人做什么以及怎么做（最好是，自己选择）？确定此次sprint的“可交付物”（也就是完成这次迭代要达到的效果）。
并且确定当前sprint哪些功能是必须实现的（must），哪些是应该做的，但若没时间就算了（should），哪些是不太需要，但有更好（could）。
7 sprint开发开始，创建sprint的任务版和sprint backlog的燃尽图，并确保每日更新，每日晨会。
Sprint任务版:Sprint backlog to do doing done燃尽图：在迭代开发过程中，会发生需求的变更或者功能点的添加，但只要对本次迭代影响不是特别大，就不要对本次迭代发生变更。
（记录迭代中的变更）8 迭代完成后需要完成文档工作：1）上一次sprint开发的product backlog。
2）当前sprint开发的product backlog。
3）变更报告增加和减少product backlog。
4）燃尽图报告。
9 sprint评审会确定可交付产品10 sprint回顾会议：回顾看板：Good could be better impraement返回3（将变更添加到product backlog，或者删除一部分）直到所有product backlog被迭代完成。