Scrum的敏捷实践与总结
敏捷开发个人体会和分享报告
敏捷开发个人体会和分享报告敏捷开发是一种以迭代和增量的方式进行软件开发的方法，它注重团队合作、快速适应变化和持续交付价值。
在我与团队一起实践敏捷开发的过程中，我深刻体会到了以下几点。
首先，敏捷开发强调团队合作和协作。
在传统的瀑布模型中，开发团队往往被划分成不同的部门，每个部门都独立进行开发，沟通很少。
而在敏捷开发中，开发团队成员之间需要密切协作，共同制定计划、讨论问题、取得进展。
团队成员之间的沟通频繁而及时，能够更好地理解需求、快速解决问题，提高开发效率。
其次，敏捷开发强调快速适应变化。
在传统的开发模式中，需求一旦被确定，变更会很困难，导致项目进度拖延和投资浪费。
而敏捷开发鼓励在开发过程中不断调整和改变需求。
通过迭代开发和频繁的反馈，能够快速发现和修正问题，及时适应变化，提高开发质量和客户满意度。
再次，敏捷开发注重持续交付价值。
在传统的开发模式中，项目通常要等待所有功能开发完毕才进行交付，导致交付时间很长，客户不能及时获得产品价值。
而敏捷开发通过分而治之的方式，将开发分成多个小周期，每个周期都能交付可用的产品。
这样，客户能够及时获得产品的一部分价值，并提供反馈意见，使开发团队能够更早地发现和解决问题，提高产品的质量和用户满意度。
最后，敏捷开发能够增加团队的工作满足感和自主性。
在传统的开发模式中，开发人员往往只负责完成自己任务的工作，缺少对整个项目的责任感和参与感。
而在敏捷开发中，团队成员具有更多的自主权，能够参与决策和规划。
团队成员之间的不同角色和技能得到充分的发挥，各自的工作能力得到更好的培养和提升，提高了团队整体的工作满意度。
总的来说，敏捷开发是一种高效的软件开发方法，通过团队合作、快速适应变化和持续交付价值，能够提高开发效率、产品质量和客户满意度。
在实践过程中，我深刻体会到了敏捷开发的优势和价值，我相信在今后的工作中，我会继续运用敏捷开发的理念和方法，提高工作效率和质量。
Scrum敏捷开发实践(1)
如何估算时间： 玩poker game（扑克游戏）这个方法估算出来的工作时间比
较准，参与扑克游戏的最好有专家和开发涉及到的人员（杜绝阿猫阿狗， 酱油男等参与）
扑克游戏玩法： （1）每个人发一些便条纸， 针对具体任务，每个人根据经验写出时
如何进行Scrum开发？
Scrum步骤二
product owner 对产品建议表进行筛选，做减法提炼最 核心的需求。在确定了需求后，这个时候由scrum master 进行输出prd (product requirement document) , 这里就和传统的瀑布流一样了，该有的文档都必须有了 ，必须由scrum master 和product owner 确定好需求， 包括业务逻辑，功能流程等。
Scrum
敏捷开发介绍 实用篇
scrum是有效管理未知因素和不断变化的产品需求，结束混乱，着重于如何驱动项目实 现最高的投资回报。
敏捷开发介绍
什么是敏捷开发？ 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一 步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
如何进行Scrum开发？
Scrum步骤四
好吧，经过大家纠结讨论了好久，终于把任务量化到具体 多少时间完成了！
恭喜！接下来，把n个任务按照开发的重要度，组合 成n个sprint( 冲刺），每次执行一个sprint.
每个sprint 都是独立的，一般先做主要功能，再到次要功 能，再到小功能，最后的sprint 一般是修复bugs。
敏捷测试实践心得体会
随着互联网和软件行业的快速发展，敏捷开发逐渐成为主流的开发模式。
敏捷测试作为敏捷开发的重要组成部分，其核心理念是以用户需求为导向，快速响应变化，提高软件质量。
在我国，敏捷测试也日益受到重视，本文将结合个人实践，谈谈敏捷测试的心得体会。
一、敏捷测试的核心价值观1. 用户至上：敏捷测试始终关注用户需求，确保软件满足用户期望，提高用户满意度。
2. 快速响应：敏捷测试强调快速迭代，及时发现问题，降低风险。
3. 透明沟通：敏捷测试要求团队成员之间保持良好的沟通，确保信息畅通。
4. 自我组织：敏捷测试鼓励团队成员自主组织工作，发挥团队潜能。
5. 不断学习：敏捷测试要求团队成员具备持续学习的能力，适应不断变化的技术和需求。
二、敏捷测试实践心得1. 理解敏捷理念：要成为一名优秀的敏捷测试人员，首先要深入理解敏捷理念，掌握敏捷开发的基本原则和方法。
在实际工作中，要时刻关注用户需求，以用户为中心，快速响应变化。
2. 搭建敏捷团队：敏捷测试的成功离不开一个高效的团队。
在搭建敏捷团队时，要注重团队成员的多样性，包括开发、测试、产品经理等角色，确保团队具备全面的能力。
3. 制定敏捷测试计划：敏捷测试计划应具备灵活性，能够根据项目需求的变化进行调整。
在制定测试计划时，要充分考虑测试范围、测试方法、测试周期等因素。
4. 采用自动化测试：自动化测试是敏捷测试的重要手段，可以提高测试效率，降低人力成本。
在实际工作中，要掌握自动化测试工具，如Selenium、JMeter等，提高测试覆盖率。
5. 关注质量：敏捷测试的核心目标是提高软件质量，确保软件满足用户需求。
在实际工作中，要关注测试过程中的质量，及时发现并解决缺陷。
6. 持续学习：敏捷测试技术不断更新，测试人员要具备持续学习的能力，跟上技术发展的步伐。
可以通过参加培训、阅读书籍、交流经验等方式，提高自己的专业素养。
7. 跨部门协作：敏捷测试需要与其他部门紧密协作，如开发、产品、运维等。
软件开发岗位实习报告的敏捷开发与Scrum方法
软件开发岗位实习报告的敏捷开发与Scrum方法1. 引言在软件开发行业中，敏捷开发和Scrum方法已经成为一种非常主流的开发模式。
在我的软件开发岗位实习中，我有幸参与了一项实施敏捷开发和Scrum方法的项目。
本报告将介绍我在实习过程中对敏捷开发和Scrum方法的了解和体验，并提供一些关于它们的实际应用的见解。
2. 敏捷开发简介敏捷开发是一种以迭代、增量和协作为核心的开发方法。
与传统的瀑布模型不同，敏捷开发注重灵活性和快速响应变化。
它强调团队成员的紧密合作、快速交付可用产品和对需求的灵活响应。
3. Scrum方法简介Scrum是一种广泛使用的敏捷开发方法之一。
它通过将开发过程划分为短期的迭代周期（Sprint），迭代周期通常为1到4周，使得团队可以更快地交付具有商业价值的软件。
Scrum通过一系列仪式、角色和工件来管理和协调团队的工作。
4. 实践经验在实习过程中，我发现敏捷开发和Scrum方法带来了一些显著的优势和效益。
4.1 灵活性和响应能力由于敏捷开发注重快速交付可用产品，团队能够更快地对需求变化做出响应。
通过每个迭代周期结束时的回顾会议，团队能够及时发现和纠正问题，提高产品质量和用户满意度。
4.2 高效的团队合作Scrum方法强调团队合作和自组织。
每个Scrum团队由三个角色组成：Scrum主管、产品负责人和开发团队。
每天的站立会议（daily stand-up）使得团队成员能够了解彼此的工作和问题，促进信息流通和问题解决。
4.3 可视化与透明度Scrum方法有一些重要的工件：产品待办清单（Product Backlog）、冲刺待办清单（Sprint Backlog）和燃尽图（Burndown Chart）。
这些工件使得工作进度和问题都能够被可视化。
燃尽图显示了团队的工作进展情况，而产品待办清单和冲刺待办清单则帮助团队在每个迭代周期中明确工作重点和目标。
5. 挑战和解决方案尽管敏捷开发和Scrum方法带来了许多优势，但也面临一些挑战。
Scrum学习和实践心得（原创整理）
Scrum学习和实践心得（原创整理）第一篇：Scrum学习和实践心得(原创整理)一、名词解释1.Scrun：Scrum在英语的意思是橄榄球里的争球。
Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。
虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.2.Sprint：橄榄球的术语，加速冲刺3.Backlog：backlog 挤压待配订货或是未完成订货（open orders）是指已收到客户的订单并且已经加以记录，不过产品尚未交货或是正在生产中。
a)booking和backlog的区别在哪里？b)booking和Backlog的区别是： Booking仅仅是订货，未知任何状态！4.Product backlog：产品订单5.Sprint Backlog：冲刺订单6.障碍Backlog：障碍订单二、完整的冲刺（Sprint）过程1、计划会议：⌝在每个Sprint开始之前召开Sprint计划会议，计划会议要有足够的时间，会议量般为4-8小时。
⌝参加人员有产品负责人、Scrum Master、Scrum团队和其他感兴趣的人。
⌝Product Owner从产品Backlog中挑选高优先级的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能。
⌝将任务分解成小的功能模块。
⌝团队成员详细讨论如何按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间2、每日例会⌝最好在每天早上开，时间一般控制在15分钟之内⌝条件允许的话，会议最好每天都在同一时间同一地点举行⌝谁都可以参加这个会议，但只有团队成员发言，其它人员只能旁听⌝所有出席者都应站立（有助于保持会议简短）⌝确定更新燃尽图⌝会议由Scrum Master主持，在会上每个团队成员需要问3个问题：[1]我昨天完成了哪些工作[2]我今天将要做什么[3]我遇到哪些障碍。
实习报告：软件开发中的敏捷开发与Scrum实践
实习报告：软件开发中的敏捷开发与Scrum实践一、引言近年来，随着信息技术的不断发展和软件行业的快速发展，软件开发的需求日益增加，同时开发周期也越来越短。
在这种情况下，传统的瀑布式开发模式逐渐暴露出了一些问题，例如开发过程缺乏灵活性、需求变更难以适应等。
针对这些问题，业界提出了敏捷开发方法，并引入了Scrum框架来进行项目管理。
本次实习报告将重点介绍敏捷开发与Scrum实践在软件开发中的应用。
二、敏捷开发概述敏捷开发是一种以人为本、迭代开发的软件开发方法。
相比于瀑布模型，敏捷开发更加注重灵活性和适应力，能够更好地满足需求的变更和客户的反馈。
在敏捷开发过程中，开发团队采用迭代的方式进行开发，每个迭代都会生成一个可用且具有价值的软件产品，并及时与客户进行沟通和反馈，从而更好地满足客户的需求。
三、Scrum框架介绍Scrum是一种敏捷开发的项目管理框架，相比于传统的项目管理方法，Scrum更加注重团队的自组织和迭代开发。
Scrum框架由三个角色、三个仪式和三个工件组成。
1. 角色（1）产品负责人（Product Owner）：负责定义产品需求，并对产品的优先级进行排序。
产品负责人需要与开发团队密切合作，确保开发团队始终了解客户的需求。
（2）Scrum团队（Scrum Team）：通常由开发人员、测试人员、UI设计师等多个角色组成，是项目的具体执行者。
Scrum团队必须具备自组织和跨职能的能力，能够在迭代周期内完成可用且具有价值的软件产品。
（3）Scrum主管（Scrum Master）：负责协助Scrum团队执行Scrum框架的方法和规则，解决团队在开发过程中遇到的问题。
Scrum主管需要具备良好的沟通和团队管理能力。
2. 仪式（1）Sprint计划会议（Sprint Planning Meeting）：在每个迭代开始之前召开的会议，产品负责人与Scrum团队一起确定本次迭代的目标和需求。
开发团队还需要将这些需求细分为可执行的任务，并估算任务的工作量。
软件工程中的敏捷开发方法实践与总结
软件工程中的敏捷开发方法实践与总结在当今快速变化的软件开发环境中，敏捷开发方法被广泛接受和应用。
敏捷开发方法强调灵活性、快速响应变化以及团队合作，这是传统瀑布式开发方法所缺乏的。
本文将介绍敏捷开发方法的基本原理和实践，并总结其在软件工程中的优势和限制。
敏捷开发方法的基本原理是通过迭代和增量的方式开发软件，使开发团队能够快速响应变化和客户需求的变更。
敏捷开发方法强调开发团队的合作、快速交付和持续改进。
在敏捷开发过程中，需求是不断变化的，因此团队必须具备灵活性和适应性以满足客户需求。
在敏捷开发方法中，有几种常见的实践方法。
其中之一是Scrum方法。
Scrum方法将开发过程分成一系列称为“冲刺”的时间段，通常为2至4周。
每个冲刺开始时，团队制定目标和计划，并在冲刺结束时回顾和改进。
Scrum方法强调团队的自组织和自我管理，通过每日的短暂会议和可视化的工作看板来促进团队合作。
另一个常见的实践方法是极限编程（XP）。
XP方法强调在开发过程中快速反馈和测试驱动开发。
团队成员通过频繁的集成和测试来确保软件的质量。
XP方法还鼓励开发人员进行持续的重构和简化代码，以提高代码的可维护性和可扩展性。
除了Scrum和XP，还有其他一些敏捷开发方法，比如看板方法、结对编程等。
这些方法都强调团队合作、快速迭代和持续改进，以适应变化的需求。
敏捷开发方法在软件工程中有许多优势。
首先，敏捷开发方法可以更快地交付软件。
通过迭代和增量的方式开发，团队能够在每个迭代中交付部分功能，满足客户的需求。
其次，敏捷开发方法可以快速适应变化。
由于需求的不断变化，敏捷开发方法可以及时响应变化，并在迭代中进行调整和改进。
此外，敏捷开发方法鼓励团队合作和沟通。
开发团队中的成员通过每日的短暂会议和可视化的工作看板来分享信息和解决问题，提高了团队的协作效率。
敏捷开发方法还强调客户的参与和反馈，确保软件的最终交付符合客户的期望。
然而，敏捷开发方法也存在一些限制。
软件研发中的敏捷开发与Scrum实践
软件研发中的敏捷开发与Scrum实践近年来，软件研发领域中的敏捷开发方法逐渐兴起并广泛应用，Scrum作为其中的一种敏捷开发框架，也受到了众多软件公司的青睐。
在这篇文章中，我们将探讨软件研发中的敏捷开发以及Scrum实践，并分析其优势和适用场景。
一、敏捷开发简介敏捷开发是软件开发中的一种迭代、逐步演进的方法。
与传统的瀑布模型相比，敏捷开发更加关注需求的变化和项目的可持续性。
敏捷开发注重团队协作、快速响应变化和持续交付价值，以提高软件开发的效率和质量。
敏捷开发的核心原则包括：迭代开发、需求变更、频繁交付、自组织团队和持续反馈。
通过这些原则，敏捷开发可以更好地适应变化和客户需求，提高开发效率和客户满意度。
二、Scrum实践Scrum是一种应用广泛的敏捷开发框架，它主要由三个角色、三个工件和五个仪式组成。
1. 三个角色Scrum中的三个角色是产品负责人、Scrum Master和开发团队。
他们各自承担不同的职责。
- 产品负责人（Product Owner）负责梳理需求、确定优先级、和开发团队协商。
他们是需求的代言人，需求变更的决策者。
- Scrum Master负责确保Scrum流程被正确实施，解决团队所面临的问题，促进团队的学习和成长。
- 开发团队由开发人员组成，负责具体的软件开发工作。
团队成员之间需要高度协作和沟通，以实现既定的目标。
2. 三个工件Scrum中的三个工件是产品背后的需求清单（Product Backlog）、迭代周期内的待办事项（Sprint Backlog）和增量（Increment）。
- 产品背后的需求清单是一个动态的需求列表，其中包含了所有的需求和优先级。
产品负责人负责维护该清单，并随时根据需求的变化进行调整。
- 迭代周期内的待办事项是每个迭代周期所需完成的任务列表。
开发团队根据自己的速度和能力，决定每个迭代周期需要完成的任务。
- 增量是每个迭代周期结束时所完成的产品部分，具有完整的功能和可用性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Story开发完成前，测试人员应该完成测试用例并 且抽取AT用例，提交给开发人员 Story转测试前，开发人员需要先执行AT，全部通 过以后可以宣布转测试 测试人员在接收到版本以后先执行AT用例，如果发 现有不通过或者是部分不通过，可以根据项目进度 选择Story打回或者是异常转测试
我们叫SDV测试 1、主要目的回归Story阶段的问题单 2、针对Story测试中的问题单集中区域进行重点测 试 3、根据开发给出的测试建议制定重点测试区域
◦ //首先应该知道项目组的真实的工作量，一般来说每一个人的每周的工作时长是40个小时但是 这个可不是真实的工作量，一般来说项目成员的每天的真正的工作时长只能是5个小时。这样我 们就能计算出项目组每周的真正的工作时长5*5*项目组成员数量（单独计算开发团队和测试团 队因为他们的工作的目标和产品都不相同），从上面我们可以看出一个叫做负荷指标的指标： =5/8=60%这样也可以算出我们项目组，真实的总的工作时长。当遇到低的负荷指标的时候， 需要找出原因。来提高效率。
人和交互重于过程和工具。 可以工作的软件重于求全责备的文档客户 合作重于合同谈判 随时应对变化重于循规蹈矩
成员彼此信任 人不求多，但求精干 开发人员具有技术权威性 拥有开放的工作环境，能自由沟通，两地团队基本 上不适合使用敏捷开发
1. 2.
1. 2. 3. 4. 5. 6. 7. 8.
需求澄清 估算、排定计划 开发人员认领需求 头脑风暴 每日站立会，更新计划，更新燃烧图 每日ICP，UT，自动化测试 Show Case story 转测试 设计验证测试 Sprint回顾会议
迭代周期其实是非常敏捷的 1、不建议超过6周 2、一般我们认为3周为宜 3、迭代周期是非常敏捷的甚至可以是一周 4、关键是如果确定了迭代周期以后不要随意的修 改，也尽力不要在迭代周期内进行需求变更
计划纸牌能够极大的提高估算的速度，一次估算中如果两个人的估算之间相差过大， 需要停下来澄清以后继续进行在重新估算，但是如果相差比较小，则可以采用加 权平均的办法。 估算的时候不由某一个人例如product master 来完成，应该由整个项目组共同 完成
一些思想和做法 让团队成员在总结的会议上展示自己的成果或者是 作品、可以运行的软件 出席该会议的有，Product Own、开发团队、 ScrumMaster，加上客户、项目管理者、高层、专 家、以及任何对此感兴趣的人 可以十分钟也可以一两个小时，
在白板上写出主要的指导原则 在白板上画出至少三页纸连起来的时间轴 在白板上写出“我们的成功经验是什么” 在白板上写出“有什么可以改进” 在白板上写出由“谁负责”，然后分成两个区域 “团队”“公司” 但是Sprint回顾的会议最好由中立的者主持 //这个我还没有理解是为什么 每一个演示完成以后可以建议大家鼓掌为其庆祝 另外在一个Sprint开始的时候就要确定在Sprint结束的时候要演示哪些东西，同时要避免在 演示的时候，有人强调理由，这些东西为什么没有完成，否则到了后期，这样的理由会泛滥 成灾，强调我们重视的是可交付的版本。 同时在会议中找到问题的所在是一个方面，重要的是我们要将问题分门别类，划分问题的 “责任田”，并在后面的项目执行的过程中，加以改善。
1、产品订单：（product backlog）这是项目所需要做的所有事情的高 层次的列表，需要有优先级列表的，以使项目一直关注与最重要的事情 上面 2、冲刺：（sprint）为了完成摸一个特定的目标的迭代，一般为两到四 周。 3、冲刺订单：（sprint backlog） 来自于product backlog中的最高优 先级的一部分的任务以及产生的附加的任务，每一个任务都应该有一个 明确的结束（done）的定义 4、产品负责人（product own）负责维护产品订单和优先级。 每一次sprint结束以后都应该又一次回顾，从团队的角度审视下那些做 得好，哪些还需要改进，而且每一次sprint结束后都应该重新调整产品 订单，重新做计划，然后在开始下一个计划。
站立会只能允许猪说话，鸡不能插嘴：只允许直接相关人说话，不能出现实质性的讨论，因 为这样会浪费时间 大家应该站立围成一个圈，但是不能围坐在一起，站立暗示大家会议很短，强迫大家注意力 集中 确保每一个Scrum团队都参加会议 每日Scrum站立会议是交流会议，不是报告会议 每日的站立会议应该控制在15分钟以内 不要把站立会议作为一天的开始，一般在10：00到10：30之间开始最合适 Scrum站立会议应该在同一时间，同一地点开始 在大家汇报完成后可以有ScrumMaster 带领大家讨论。 在站立会议结束以后Scrum Master需要更新燃烧图（Sprint Burndown Chart）
必须要为每一个细化的任务定义Done（结束）的标准 一般来说每一个任务应该控制在2~16个小时之间 对于细化的任务应该有开发人员如认领而不是分配。 如果估算的时候最高值和最低值之间相差一半以上的时候需要两个人沟通一下确 认为什么会产生如此大的差距 如果项目组成员很多的时候可以采用分组讨论的方式，这样大家的参与效率都会 很高。 乐观者赢：如果两个人的估算相差不大，则可以采用乐观者赢的方式ຫໍສະໝຸດ 每日TCP持续集成是非常必要的
◦ 注意这里集成的代码应该是已经宣布转测试的Story代码
UT，自动化的代价很大建议按照项目需求确定是否 需要
一个story开发进入一个可以展示的阶段的时候，可能还会有很多 Bug没有解决。可以召集项目干系人，PM，客户，PL，TE，其他 开发人员，向他们展示自己的作品。 好处： 1、通过show Case，可以及时的展示自己的工作产品是否符合需 求，以期及早的调整开发方向，避免在代码集成，甚至交付的时 候发现，工作产品偏离了预定的目标 2、通过show Case 2 show Case，让项目干系人给自己的作品提意见，更加完 善开发产品 3、通过show Case，可以让自己及时的发现自己开发过程中的一 些问题。
1、参与人
◦ Story相关的所有人员
2、时间
◦ 估算结束，所有相关人进行初步的分析以后，就可以进行。
3、要求
◦ 过程中产生的思想，所有人产生的思想不应该被否定。同时思 想应该迅速记录下来不管用什么方式，最终产生的决议迅速记 录到JRIA，或者其他敏捷管理工具中
Daily Scrum 站立会七个规则 大家应该站立围成一个圈，但是不能围坐在一起 而且来的最晚的人向大家报告工作进展的情况 所有成员汇报四个问题：1、上次立会后你做了什么；2、你负责 的部分还有多少没有完成；3、在下次立会前你要做什么；4、你 的开发被阻碍了么，如果没有更新工作量应该给出最新的估算 按照顺时针执行汇报，一般不能打断 每人汇报完成后有Scrum Master带领大家讨论 Scrum Master 宣布Daily Scrum结束 会后由Scrum Master/team Leader对每一个人反映的障碍进行 跟踪交流解决
第一指导原则：主题明确不能掺杂其他无关的话题，主要回答4个问题
◦ ◦ ◦ ◦ 上次立会后你做了什么，不要过分详细， 你负责的部分还有多少没有完成，需要多少的工作量和时间，给出最新的估算，如果使用了敏捷的跟 踪工具就可以省略这个步骤 在下次立会前你要做什么，给其他成员一个提示，可能中间有依赖关系 你的开发被阻碍了么，如果在这个时候讨论了技术细节，如果几句话的话就继续，如果全面的分析了 就需要打断
1、站立会变成讨论会 2、站立会汇报对象从整个团队变成PM 3、项目估算变成PM一个人的事情 4、过分轻视文档使得诸如数据库描述都会缺失 5、团队成员过于兴奋，作出超出自己能力的估算 6、sprint回顾会议变成批判会议 7、流程执行不彻底，最容易忽略的是Show Case，Story转 测试把关 8、…… 其他想起来再说
Scrum团队主要包含如下的角色，包括： Scrum Master 类似于项目经理 product own 类似于客户 Scrum tem 研发团队 5~9个人为最佳的团队构成人数
1、增量开发项目 2、需求变更非常频繁的项目 3、小型团队（建议10人以内） 4、一体化团队
1、大型项目的基线开发 2、大型团队（沟通代价会很大） 3、对质量要求极高的项目 4、不能短期交付一个可以工作的产品的项目 5、异地团队