敏捷开发实践培训教程课件.ppt

《敏捷开发实践培训教程课件.ppt》由会员分享，可在线阅读，更多相关《敏捷开发实践培训教程课件.ppt（32页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、产品敏捷开发实践产品敏捷开发实践培训教程培训教程（20102010年年0101月）月）& 引言u 什么是敏捷 ？u 什么是SCRUM ?u 极限编程(XP)的12个核心实践& 术语表& 敏捷能带给我们什么？& 敏捷开发实施标准& 敏捷开发的案例分析& 总结n 敏捷开发敏捷开发（agile development）：敏捷开发是一种以人为核心人为核心、迭代迭代、循序渐进循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。敏捷方法强调以人为本以人为本，专注于交付对客户有价值的软件软件。在高度协作高度协作的开环境中，使用迭代式的方式迭

2、代式的方式进行增量开发增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善n 开发流程开发流程n 敏捷宣言敏捷宣言 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观： 个体与交互个体与交互 重于 过程和工具过程和工具可用的软件可用的软件 重于 完备的文档完备的文档客户协作客户协作 重于 合同谈判合同谈判响应变化响应变化 重于 遵循计划遵循计划 在每对比对中，后者并非全无价值，但我们更看重前者更看重前者短周期开发，提供及早的、具体的、持续的反馈。增量开发。迅速地提出总体计划，并在项目生命周期中不断演化。灵活安排功能地实现，以对变化的业务需求作

3、出反应。使用由程序员和测试人员编写的自动化测试来监控开发进度，支持系统演化，并尽早发现缺陷。通过口头沟通、测试和源代码来交流系统的结构和意图。渐进式的设计过程贯穿整个系统生命周期。依赖于能力普通但能积极参与的程序员之间的紧密协作各种实践兼顾项目成员的短期直觉和项目的长期利益。n敏捷开发特点敏捷开发特点引言引言什么是什么是SCRUM（一）（一） Scrum Scrum是一个迭代性迭代性、增量性增量性的敏捷流程敏捷流程，适用于任何的产品开发以及工作管理，其中包含了风险控制风险控制，解决最优先需求解决最优先需求，团队高效协作团队高效协作等各种思想。 在每个迭代结束后，Scrum都会产生一套可以交付的

4、功能性产品。Scrum是一个“检查并适应检查并适应”的框架:在三个角色三个角色（产品负责人产品负责人/Scrum MasterScrum Master/团队团队）、三种仪式三种仪式（SprintSprint计划计划/SprintSprint回顾回顾/每日例会每日例会）和三种制品三种制品（产品产品BacklogBacklog/Sprint BacklogSprint Backlog/燃尽图燃尽图）的基础上，你可以根据公司或者项目的情况，因地制宜引入任何有利于缩短开发周期、提高产品质量的实践n Scrum过程过程n Scrum的的“3个三个三”n Scrum定义定义引言引言什么是什么是SCRUM（

5、二）（二）团队目标团队目标重于岗位职责团队工作团队工作优于独立作战高效沟通高效沟通强于标准化的文档高能动性的、自组织高能动性的、自组织的团队胜于角色划分清晰的流水线务实务实的解决问题的方法好于经典理论快速实践，快速反馈，持快速实践，快速反馈，持续优化续优化n 什么样的项目适合什么样的项目适合SCRUMn Scrum精神精神SCRUM的项目通常会有一些共性：1. 项目的需求多变。2. 项目周期较长（通常大于3次迭代）3. 项目分期开发，迭代增量。n 适用症：适用症：重量级流程导致的软件开发环节复杂面向任务、面向职责的开发模式导致的各司其职、流程环节衔接不畅，项目进度的掌控困难以上两条导致的项目/

6、产品开发周期过长n 原理：原理：目标驱动，在统一的软件交付目标下组织团队 依靠团队的智慧做项目评估、计划乃至设计、开发、测试抓住最基本的项目开发属性：周期 + 质量1. 1. 完整团队完整团队 XP项目的所有参与者（开发、客户、测试等）一起工作在一个开放的场所中。2. 2. 计划游戏计划游戏 计划是持续的、循序渐进的。 每2周一次，根据成本和商务价值来选择要实现的特性。3. 3. 客户测试客户测试 客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。4. 4. 简单设计简单设计 团队保持设计恰好和当前的系统功能相匹配，尽可能简单。5. 5. 结对编程结对编程 开发是由两个程序员、并排

7、坐在一起在同一台机器上进行的。6. 6. 测试驱动开发测试驱动开发 编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环7.7. 重构重构 随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。8. 8. 持续集成持续集成 团队总是使系统完整地被集成。一个人Check in后，其它所有人责任代码集成。9. 9. 集体代码所有权集体代码所有权 任何结对的程序员都可以在任何时候改进任何代码。10. 10. 编码标准编码标准 系统中所有的代码看起来就好像是被单独一人编写的。11. 11. 隐喻隐喻 是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业

8、术语,开始要先明确双方使用的隐喻，避免歧异。12. 12. 可持续的速度可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。 引言引言极限编程极限编程(XP)的的12个核心实践个核心实践极限编程极限编程(XP)是敏捷方法中最著名的一个，它是由一系列简单却互相依赖的实践实践组成，能帮软件团队养成良好的习惯。& 引言& 术语表& 敏捷能带给我们什么？u 敏捷在公司产品开发中的定位u 敏捷能解决的具体问题u 敏捷的应用范围&敏捷开发实施标准& 敏捷开发的案例分析& 总结 术语术语解释解释1.1.SprintSprint

9、一次迭代过程,通常是30天.这个过程是不可被打断的,不能增加额外的需求,确保迭代结束时能够获得预期的可交付成果2.2.ProductProductbacklogbacklog一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级，Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求3.3.Sprint backlogSprint backlog一次迭代的特性列表,或者说工作列表.展示本次迭代的工作单元,源自产品特性列表，即素材（User Story）列表。4.4.Sprint taskSprint task是对素材（User Story）进行细分

10、，在四到六小时内能完成的工作单元(即可独立分配的功能),由队员主动认领。Task包括优先级，数字越高优先级越高。5.5.Sprint Burndown Sprint Burndown ChartChart一次跌代的燃尽图，显示单次迭代过程的进度情况6.6.sprint planning sprint planning meetingmeeting单次迭代的计划会议,由Team与Product Owner之间商讨sprint目标集,决定哪些素材会被放进来.并对素材的任务进行分解，确定优先级,这个会议被限制在四个小时之内.7.7.Daily Scrum Daily Scrum meetingmee

11、ting每日站会,开发团队成员召开，一般为15分钟。每个开发成员需要向开发项目经理汇报三个项目：今天完成了什么？是否遇到了障碍？即将要做什么？通过该会议，团队成员可以相互了解项目进度。8.8.Sprint review Sprint review meetingmeetingSprint评审会,在Sprint结束的时候召开. 最多不超过4个小时.前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner. Product Owner会组织这阶段的会议并且邀请相关的利益相关者(业务、市场、技术)参加相关的评审。由Product Owner来决定Product Backlo

12、g中的哪些功能已经开发完成。9.9.Sprint Sprint retrospective retrospective meetingmeeting在sprint末期,评审会议之后召开.Team与开发项目经理共同讨论这次sprint中哪些地方做得比较好,哪些地方需要在下次sprint中进一步提高.会议时间被限制在三个小时之内& 引言& 术语表& 敏捷能带给我们什么u 敏捷在公司产品开发中的定位u 敏捷解决的具体问题u 敏捷的应用范围& 敏捷开发实施标准& 敏捷开发的案例分析& 总结为什么为什么要引入？要引入？要达到要达到的目标的目标敏捷开敏捷开发方法发方法如何引如何引入？入？132解决产品开发

13、的问题解决产品开发的问题：由于公司有些产品的需求总是在不断的变化，很多时侯产品全部开发完了才发现这不是客户想要的东西，这样就大大浪费了开发资源，并导致产品开发周期无限延长，我们需要找到一种应对需求不断变化的产品开发流程，敏捷开发能解决这一问题敏捷开发能解决这一问题。SCRUM框架框架+XP实践：实践：管理的框架上是采用的SCRUM，指导如何编码实现上就采用了一些XP的实践。同时在实践的过程中也引入了精益、消除浪费的思想。应用范围：应用范围：主要应用在一些需求经常发生变更的高复杂度/高风险的产品开发提升最终的产品价值提升最终的产品价值：敏捷能够灵活安排功能实现，以对变化的业务需求作出反应，这样就

14、缩短了产品版本的发布周期，及时展现给客户，从而提升了最终的产品价值l 提倡短周期发布，这样任何延迟的范围都是有限的。提倡短周期发布，这样任何延迟的范围都是有限的。l 一个发布周期内，计划许多小任务以保证团队可以在该周期内一个发布周期内，计划许多小任务以保证团队可以在该周期内解决问题。解决问题。 提倡优先实现高优先级的功能。提倡优先实现高优先级的功能。l 最小发布必须是满足最大商业意义的，选择团队中面向业务的最小发布必须是满足最大商业意义的，选择团队中面向业务的成员来承担。成员来承担。l自动化测试，每次代码改动后运行，确保质量底线。自动化测试，每次代码改动后运行，确保质量底线。l保证系统处于可部

15、署状态，不允许出现问题的积累。保证系统处于可部署状态，不允许出现问题的积累。减少进度延迟减少进度延迟避免系统恶化避免系统恶化l 由于缩短了发布周期，因此极大减少变更带来的影响。由于缩短了发布周期，因此极大减少变更带来的影响。l 拥抱变化，利用重构解决变更带来的技术问题。拥抱变化，利用重构解决变更带来的技术问题。减小项目取消的代价减小项目取消的代价应对业务需求的频繁变更应对业务需求的频繁变更1234n特点特点l项目需求比较明确，后期改动较少l大型项目，技术参与人数很多l项目工期比较紧l开发人员水平有限 n 特点特点l项目需求经常发生变更l项目团队的人数不能太多l项目工期较为宽裕l高复杂度/高风险

16、的项目实施l开发人员可以参与决策n 适用项目适用项目l 公司产品：公司产品：需求不明确，开发周期较长l 内部内部IT项目：项目：功能持续、不断完善l 其它二次开发：其它二次开发：功能少、开发周期短n 适用项目适用项目l 外部项目：外部项目：需求明确、开发周期紧l 重要业务：重要业务：功能明确、重点保障类型类型 CMMCMM敏捷（敏捷（AgileAgile）不同点不同点更注重质量质量更注重生产效率生产效率强调过程过程的可观测性强调可观测性的结果（可运行的可运行的软件软件）注重管理和过程管理和过程（组织过程的有效性和过程的系统化改进）注重技术技术和效率效率注重组织组织注重个人个人提供了一个高度抽想

17、的框架，具广泛广泛的应用范围的应用范围，无所不包（Universal）有明确的适用范明确的适用范围围(适用于小组织，需求不定，有用户紧密参与的情况)强调应该作什么作什么强调怎么作怎么作相同点相同点都包含了一些软件工程的好的实践实践n CMM与敏捷比较与敏捷比较& 引言& 术语表& 敏捷能带给我们什么？& 敏捷开发实施u 团队建设u 工具选择u 产品开发实施过程& 敏捷开发的案例分析& 总结n 软件产品开发的三要素软件产品开发的三要素： 人（团队）人（团队） 产品开发团队的建设 工具工具管理工具的选择 过程管理过程管理对整个产品开发过程的有效管理过程管过程管理理工具工具人人开发项目经理开发项目经

18、理技术技术产品、内容产品、内容交互设计师UI设计师.拓展、营销拓展、营销开发工程师测试工程师拓展经理拓展经理n 职责职责 产品需求的提出 产品的推广 对客户负责产品经理产品经理营销经理营销经理n 职责职责产品的功能策划对最终产品功能负责n 职责职责产品功能的技术实现对技术成果负责产品经理：产品经理： 确定产品的功能,定义开发目标，需要实现的feature和优先级开发项目经理：开发项目经理：需求分析，项目任务分解，开发周期制定，主持会议，进度检查，问题协调解决项目成员：项目成员：开发人员：开发人员：设计，编码，编写测试用例，单元测试 测试人员：测试人员：编写产品周期版本测试方案、测试用例，集成测

19、试n 敏捷开发核心团队角色敏捷开发核心团队角色:.n 理想敏捷团队的要求：理想敏捷团队的要求： 项目人数较少项目人数较少。这有助于项目成员之间的彼此了解，也有助于开发项目经理了解每个人的状况。 项目成员乐于沟通乐于沟通。由于需求的不断变化，敏捷团队往往比其他的团队需要更多的沟通；而团队成员之间的交流和了解也有助于提高项目的开发效率（比如碰到新技术时，直面的请教要比摸索需要的时间短的多）。 项目成员有较强的凝聚力较强的凝聚力，能够在工作时间全身投入，在休息时间好好放松。就像字面理解sprint一样，要冲刺的时候，自然要精神集中；而要不断的冲刺，又要学会放松自己。 一支出色敏捷团队靠的不是技术，不

20、是流程，而是有良好素质的一支出色敏捷团队靠的不是技术，不是流程，而是有良好素质的团队成员。良好素质包括团队成员。良好素质包括进取心进取心、责任心责任心、良好的习惯良好的习惯、热情热情产品策划工具产品策划工具 产品策略管理平台产品策略管理平台版本管理工具版本管理工具.软件测试管理工具软件测试管理工具 VSS MercuryMercury敏捷开发管理平台敏捷开发管理平台 XplannerXplanner单元测试工具单元测试工具 JUNITJUNIT产品策略平台是一个公司内部针对所开展的项目进行的分目标用户的需求及产品设计成果的讨论平台全称为 Visual Source Safe 。它主要任务就是负

21、责项目文件（源码、文档）的管理质量管理工具集,用到其中的缺陷管理功能JUNIT是基于面向对象构建的java单元测试框架是一个基于Web的敏捷开发团队计划和跟踪工具技术技术产品、内容产品、内容拓展、营销拓展、营销产品讨论审核产品讨论审核产品策略管理平台产品策略管理平台客户客户产品决策团队产品决策团队产品经理产品经理(产品策划团队产品策划团队)拓展经理拓展经理(营销经理营销经理)敏捷开发管理平台敏捷开发管理平台开发项目经理开发项目经理(技术开发团队技术开发团队)SCRUM流程流程为客户作产品演示为客户作产品演示交付的产品交付的产品增量交付的产品增量交付的产品产品需求提出产品需求提出产品策划产品策划

22、需求调查需求调查演示反馈演示反馈产品开发流程图产品开发流程图开发需求策划阶段开发需求策划阶段12过程过程说明说明线上操作线上操作负责人负责人输出输出业务需求提交业务需求提交拓展经理与客户沟能进行需求调查获取需求在产品策略平台上提交需求营销经理(拓展经理 )产品策划产品策划产品经理带领产品策划团队（UI/UE设计师、交互设计师等）进行产品的策划在产品策略平台上提交产品策划稿产品经理(产品策划团队)产品策划稿产品讨论审批产品讨论审批由产品决策团队对产品策划稿进行讨论和审批在产品策略平台上进行讨论和审批产品决策团队1） 产品功能规格说明书2） 产品功能列表过程过程说明说明线上操作线上操作 负责人负责

23、人输出输出开发需求分解开发需求分解由产品经理负责组织召开需求分解会议（迭代计划会需求分解会议（迭代计划会1 1），与开发项目经理及开发团队成员一起对产品功能规格说明书中的功能进行评估，提出划分发行版本和Sprint计划的主要依据，同时制定出迭代周期的目标，以及迭代周期中需要实现的User Story在敏捷开发管理平台上登记迭代周期的Userstory产品经理产品经理会议纪要会议纪要开发任务分解开发任务分解由开发项目经理组织召开任务分解会议（迭代计划会任务分解会议（迭代计划会2 2），对已经选择的User Story进行任务分解，并确定每个任务的优先级，从而形成一次迭代周期的任务列表（Sprin

24、t Backlog）在敏捷开发管理平台上对迭代周期的Userstory进行任务分解开发开发项目项目经理经理会议纪要会议纪要技术开发阶段（一）技术开发阶段（一）过程过程说明说明线上操作线上操作负责人负责人输出输出迭代迭代周期周期执行执行每日每日站会站会由开发项目经理组织召开每日站会每日站会,每个工作日的开始，团队成员间进行工作进度的沟通和协调，会议时间不要超过15分钟。无开发项目经理会议纪要会议纪要设计设计开发项目经理带领开发团队对一次迭代周期内的任务进行设计，设计阶段的产出物包括设计文档（总体设计、数据表设计、接口设计）和测试用例文档上传相关设计文档到版本管理工具（VSS）总体设计文档总体设计

25、文档数据库设计文数据库设计文档档接口设计文档接口设计文档测试用例测试用例测试方案测试方案测试计划测试计划开发开发开发工程师根据设计文档进行功能性编码，编写自动化测试模块，并进行单元测试同步源码到到版本管理工具（VSS）源码源码集成测试集成测试由测试工程师根据测试用例对一次迭代周期内完成的功能性任务进行测试、开发工程师修改BUG在测试管理平台上登记缺陷。上传测试报告到VSS测试报告测试报告产品演示产品演示开发项目经理组织召开产品审查会议产品审查会议，根据团队这次Sprint所发布的版本，评审相关任务中的问题，检查是否已经达到产品预期目标产品经理会议纪要会议纪要迭代迭代回顾总结回顾总结由开发项目经

26、理组织召开迭代回顾会议迭代回顾会议，每个Sprint完成后，通过Sprint回顾发现问题和改进点，制定下个Sprint要引入的新的实践开发项目经理会议纪要会议纪要2技术开发阶段技术开发阶段 (二）二）接上页接上页3给客户演示产品阶段给客户演示产品阶段过程过程说明说明线上操作线上操作负责人负责人联系客户作产品联系客户作产品演示演示拓展经理与客户进行联系,约定时间进行产品演示营销经理(拓展经理 )问题回馈问题回馈拓展经理收集客户的反馈建议营销经理(拓展经理 ) 营销经理把每次与客户交流的反馈建议重新提高给产品经理 产品经理负责把这些建议进行功能化放入产品的功能列表以供下一次迭代选择进入下一次技术开

27、发阶段 项目切分原则：项目切分原则： 优先考虑底层的底层的、核心的核心的模块 优先考虑通用工具通用工具和框架框架的实现 先难后易先难后易的原则 任务开发时长最好在完整的开发周期内相关联的任务能够安排在相邻的开发周期4后续流程说明后续流程说明& 引言& 术语表& 敏捷能带给我们什么？& 敏捷开发实施& 敏捷开发的案例分析u 某部门敏捷实战案例u 实战案例分析与总结u 典型的失败案例u典型的成功案例& 总结阶段阶段实施细节实施细节实施实施ScrumScrumSprintSprint前前产品负责人（PM）收集整理产品需求，形成产品Backlog 产品Backlog按照统一格式定义，比较重要属性有：名

28、称、重要性、估算时间、简单描述、如何演示等，详细的需求细节可以在其他需求文档中定义 产品负责人可以通过任何渠道、方式获取和确认需求实施实施ScrumScrumSprintSprint产品负责人、Scrum Master和团队成员（包括QA）召开Sprint会议，Scrum Master主持会议 Sprint会议上详细沟通产品负责人选定的重要性高的产品Backlog细节，确保团队对需求的理解无误 团队就对需求的理解将Backlog拆分成任务，并给出每个Backlog的估算时间 产品负责人和团队根据Sprint内可用的人天和Backlog的时间估算，选定需要排入本次Sprint的Backlog S

29、crum Master和团队分派任务，制定Sprint计划 一个Sprint的周期是两周；一次Sprint会议时间大约一个下午 整理一面任务墙，将Sprint内的Backlog和任务按照未开始、进行中、已完成等状态进行归类；同时展示Sprint的燃尽图 Scrum Master每日早上固定时间组织团队的每日例会，确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的issue，并更新任务墙 任何需求变更都进行实时评估，超过规划人天的Backlog视情况进行拆分或者推迟其他重要性低的Backlog 任何完成的Backlog都需要演示给产品负责人和QA后才能提交测试实施实施ScrumScru

30、mSprintSprint后后Scrum Master召集、组织Sprint回顾会议 回顾会议以头脑风暴的方式Review Sprint过程和结果，发现和列举存在的问题 与会人员投票决定需要在下个Sprint中解决的1-3个问题， 探讨解决方案，确定实践方式实践实践参与角色参与角色目的目的/好处好处注意事项注意事项Backlog产品负责人以简单的、面向目标的方式描述需求愿景比需求细节更重要，团队需要知道为什么做而不光是做什么Sprint会议产品负责人Scrum Master团队集中沟通需求细节，用团队的智慧制定Sprint计划控制会议时间，安排茶歇时间，分支话题另行安排讨论，所有人都参与进来任

31、务墙Scrum Master团队使项目任务可视化任务单位以小于等于1天为宜每日例会Scrum Master团队更新进度，发现问题控制时间为10-15分钟，站立会议Backlog演示产品负责人QA团队成员检查产品是否达到需求要求和测试要求建议在QA测试环境进行n归纳用到的实践（一）归纳用到的实践（一）实践实践参与角色参与角色目的目的/好处好处注意事项注意事项Sprint回顾产品负责人Scrum Master团队总结经验教训，反馈到后面的Sprint，持续改进工作方法头脑风暴的方式，轻松的讨论氛围，每次选中小于5个的问题进行解决Tech Show团队团队技术交流短时间，高频率守门员团队为团队成员创

32、造安静的工作条件，增加对工作的focus程度团队成员轮流做守门员，逐渐培养每个人对问题的解决能力Double Check团队成员交叉检查项目制品是否达到要求关键制品如设计文档、核心代码、Release Notes等必须Double CheckChecklistScrum Master团队总结记录经验教训，作为后续项目的检查项解决问题后及时更新n 归纳用到的实践（二）归纳用到的实践（二）接上页n 未用到的实践未用到的实践接上页实践实践参与角色参与角色目的目的/好处好处注意事项注意事项单元测试团队成员采用测试优先的方式保证代码质量结对编程团队提高设计和代码质量，经验共享，加强合作任务纸牌团队Scr

33、um Master增加任务评估的客观性还没找到很好的方式促进开发和QA融合为统一的Scrum团队有些有价值的实践没有实施到很有意义的程度，执行不坚决深入持续的方法改进工作有待加强n 做的还不到位的方面做的还不到位的方面n 案例描述案例描述接上页n 失败分析失败分析一个离岸开发离岸开发的某创业型公司。虽然团队比较特殊（离岸开发团队），但这个失败案例却非常典型和普遍。“某一天，国外的PM突然发来几个链接，一看讲的是一个闻所未闻的词，就是Scrum了。好像就给了一两天的时间去看Scrum的介绍文档，然后就开Stand-up Meeting（站立会议）。”这个案例的团队是真真的在推行SCRUM。从表明

34、看，大家也是在按照SCRUM框架的方式工作：有相应划分的角色，有具体的分解任务，有会议，也有迭代（Sprint）。那又怎么会失败呢？显然，他们是在照搬照套了SCRUM的框架。他们是两个离岸的开发团队，因为地点、时区和语言的差异，很容易就会导致沟通和交流不畅，这时候再生硬的引入SCRUM，无异是火上浇油n 案例描述案例描述接上页n 成功分析成功分析“我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进， 从而趟出自己的一条路。如果这个Sprint我们回顾时觉得自己代码Review（审查）做的不好，下个Spri

35、nt就会引入新的代码Review机制。 这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进”。他们的具体做法如下：“其实我们一开始并没有把Scrum这个说法拿出来。就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。于是就有了一月一个项目的进 度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目）。然后为了管理，我 们开始开晨会。然后为了改进，我们开始开项目总结会，把Product review和Team retr

36、ospective放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。后来总结会上觉得质量不好，我们加入了单元测试和代码 Review机制。至于计划会议，一开始我们就采用的Scrum的方法。项目小，MS Project太难调。我们就更换了Scrum的Excel计划表，后来又换了Xplanner。无独有偶，这些成功案例的团队，就是通过这样的方式进行一步一步推进，把SCRUM成功的引入到了各自的项目中& 引言& 术语表& 敏捷能带给我们什么？& 敏捷开发实施& 敏捷开发的案例分析u 某部门敏捷实战案例u 实战案例分析与总结u 典型的失败案例u典型的成功案例& 总结 敏捷就是一个团队持续不

37、断的自我改进过程，直到那些优秀的品质成为大家的一种职业习惯一个自组织的团队。敏捷没有终点，我们一直在路上。 思想和精神只可意会不可言传。这些只可以在每天的工作和问题中去领悟、体会和沉淀。在学习敏捷方法的时候，我们 应该尽可能多和深入的学习，并融会贯通。在具体工作的时候，我们先要忘掉学到的条条框框。首先分析自己的上下文环境，找出最主要的矛盾，然后根据团队状 况，通过学到的经验和方法将这些问题进行平衡和解决。好了，忘掉一切招数，看看软件开发最原始最淳朴的目标-在资源一定的情况下，在资源一定的情况下，尽可能快地完成高质量尽可能快地完成高质量的软件开发的软件开发 我们的最高目标是，通过尽早和持续地交付

38、有价值的软件来满足客户。 欢迎对需求提出变更即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 项目过程中，业务人员与开发人员必须在一起工作。 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 可用的软件是衡量进度的主要指标。 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 对技术的精益求精以及对设计的不断完善将提升敏捷性。 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 最佳的架构、需求和设计出自于自组织的团队。 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 n 推荐参考书目：推荐参考书目： 硝烟中的SCRUM和XP、Scrum+Checklists中文版