如何实施敏捷开发

1、敏捷思想分享看板管理实例敏捷的核心敏捷就是一个团队持续不断的自我改进过程，直到那些优秀的品质成为大家的一种职业习惯一个自组织的团队。Scrum不是方法学，它是一个框架，也就是说Scrum不会告诉你到底该做些什么。Scrum的强大和痛苦之处就在于你不得不根据自己具体的情况对他进行调整。Scrum团队Product Owner(产品负责人产品负责人) 确定产品的功能，负责维护产品Backlog。 决定产品的发布日期和发布内容。 为产品的投资回报率(ROI)负责。 根据市场价值确定功能优先级。 在每个Sprint开始前调整功能和调整功能优先级。 在Sprint结束时接受或拒绝接受开发团队的工作成果。

2、Scrum MasterScrum Master 保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会Scrum Scrum 团队团队 Scrum团队的职责是在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的 功能增量 Scrum工件 Product Backlog产品backlog是一个产品或项目期望的、排列好优先级的功能列表。优先级由商业价值、风险、和必要性决定。产品负责人负责产品Backlog的

3、内容、可用性和优先级。 Sprint BacklogSprint Backlog 是团队承诺在当前Sprint完成的任务列表。Sprint Backlog中的任务是由产品Backlog选取的需求条目细化和分解而来，这些任务要确保将产品Backlog条目转化为潜在可交付的产品增量。 Sprint燃尽图（燃尽图（Sprint Burndown Chart） Sprint Burndown Chart 显示了Sprint中累积剩余的工作量。 发布燃尽图发布燃尽图在Scrum项目中，团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。 如何编写Product BacklogProd

4、uct BackLog是是Scrum的核心，也是一切的起源。的核心，也是一切的起源。 产品产品backlog由所由所有的功能特性，包括业务功能，提升点以及缺陷的修复等组成。这些有的功能特性，包括业务功能，提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。一个完整的内容也是将来产品版本发布的主要内容。一个完整的backlog是一个的是一个的蓝图，可以根据它来把产品开发成为我们期望的样子。蓝图，可以根据它来把产品开发成为我们期望的样子。 创建者创建者业务部门、客户方、产品营销部门等 负责人负责人Product Owner 优先顺序优先顺序按照能给用户带来最大理由的原则划分优先顺序

5、，由Product Owner决定。 估算估算团队初步进行估算，单位为“故事点” 可视化可视化需要能够让开发团队，利害相关人等相关的人能够很容易的看到它的内容、状态等。 停留在业务层次停留在业务层次要用业务术语描述目标如何准备Sprint计划在Sprint计划会议之前，要确保Product Backlog的井然有序。 Product Backlog一定要存在 只能有一个Backlog和一个Product Owner 所有重要的Backlog条目都已经根据重要性评过分 Product Owner应当理解每个故事的含义如何制定Sprint计划Sprint会议非常关键，应该是会议非常关键，应该是Sc

6、rum中最重要的活动。举办中最重要的活动。举办Sprint计划会议，是为了让团队获得足够的信息，能够在几计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰的工作，也是为了让产品负责人能对此有个星期内不受干扰的工作，也是为了让产品负责人能对此有充分的信心。充分的信心。Sprint计划会议会产生一些实实在在的成果： Sprint目标 团队成员名单 Sprint backlog 确定好的sprint 演示日期 确定好的时间地点，供举行每日scrum会议。为什么Product Owner一定要参加每个用户故事有三个变量，他们两两之间都存在强烈的相互依赖关系。ScopeEstimateImp

7、ortance范围和重要性有Product Owner设置。估算由团队设置，通过团队和产品负责人面对面的对话，这三个变量会逐步得到优化。如何让Product Owner参加 让Product Owner理解，为什么他的直接参与事关项目成败，希望他可以改变念头。 让Product Owner指定代理人 推迟Sprint的启动日期确定Sprint的长度Sprint演示日期是演示日期是Sprint会议的产物，他被确定下来以后，也会议的产物，他被确定下来以后，也就确定了就确定了Sprint的长度。的长度。那那Sprint应该多长才好？应该多长才好？ 短的Sprint：短反馈周期、更频繁的交付、更频繁的

8、客户反馈在错误方向上花的时间更少、学习和改进的速度更快 长的Sprint：团队可以有更多的时间充分准备、更多的时间解决发生的问题、不会接二连三的被Sprint的会议、演示等压得不堪重负。 Sprint的长度是妥协后的产物，经过总结经验最佳的Sprint长度是2-3周，这个长度让团队拥有足够的敏捷性，有让团队进入“流”的状态。决定Sprint要包含的故事 决定哪些故事需要在这个Sprint完成，是Sprint计划会议的一个主要活动。更具体的说，就是哪些故事需要从产品Backlog拷贝到Sprint backlog中。每个矩形代表一个故事，按重要性排序矩形的尺寸代表故事的大小蓝括号的高度代表团队的

9、估算生产率右侧的Sprint Blog是ProductBlog的一个快照，是团队在这个Sprint中承诺要完成的故事决定Sprint包含哪些故事Product Owner如何对Sprint放哪些故事产生影响调整优先级缩小范围拆分用户故事决定Sprint包含哪些故事团队决定怎么样把哪些故事放到sprint里面 本能反应本能反应Sprint会议上通过协商决定将哪些用户故事纳入到这个Sprint计划中，如果Sprint的时间不长，小团队根据直觉根据直觉进行估算可能收到很好的效果。 生产率计算生产率计算这种技术包括两步：1、得出估算生成率 2、计算在不超出估算生成率的情况下可以加入多少故事。前提是团队

10、已经完成了几个Sprint,并且会以相同的方式来进行下一个sprint。明确用户故事内容 最糟糕的事情莫过于在Sprint演示会上，团队自豪的演示一个新特性，但是Product Owner说 “这不是我想要的东西”。怎样才能让Product Owner和团队对故事有同样的理解呢？完整的填充Sprint Backlog的字段可以是避免这种事情的最简单的办法。例1：用户故事时间估算字段的重要性例2：用户故事如何演示字段的重要性用户故事拆分 将用户故事拆分成更小的故事将用户故事拆分成更小的故事用户故事不应该太长，也不应该太短。太短或太长故事点的故事会增加管理成本。力求将每个故事的大小控制在2-8个人

11、-天 将用户故事拆分为任务将用户故事拆分为任务使得Sprint计划更接近真实情况方便管理最开始的Sprint Backlog首日每次例会之后几天之后的Sprint Backlog燃尽图如何发挥作用如何用燃尽图跟踪如何用燃尽图跟踪状态Sprint 演示演示是说在一个演示是说在一个Sprint 结束以后，进行结束以后，进行Sprint 评审。出席此评审。出席此会议的有利害关系人和对项目感兴趣的人。会议目的只是会议的有利害关系人和对项目感兴趣的人。会议目的只是对所做工作结果的展示，并听取反馈对所做工作结果的展示，并听取反馈 。 Sprint演示的目的：演示的目的： 演示可以让利益相关者虽然不直接参与

12、Sprint，但可以获得第一手关于你们这个团队最新进展的印象。 演示可以让客户或者Product Owner对你们所做的工作提供最直接的反馈。 演示是一个很好的机会，可以让团队庆祝他们在过去的Sprint中所取得的成就。看到可以工作的软件，可以真正鼓舞团队的士气 。如何进行Sprint演示要确保与会的所有人明白该Sprint的目标。不要花太多时间准备演示，集中精力演示可以实际工作的代码。节奏要快，不要追求好看。把精力集中在演示的快节奏上。让演示关注于业务层次，不要管技术细节。先从主要的功能演示。如何可能的话让观众自己试一下。Sprint回顾 Sprint回顾是Scrum中第二重要的事件，因为这

13、是团队做改进的最佳时机。 总结在上一个Sprint中的得失，找到改善与提高的办法，从而让下一个Sprint走得更好 如果没有回顾，你就会发现团队在不断重犯同样的错误。如何进行Sprint回顾 根据要讨论的内容范围，设定时间为1-3小时。 参与者:Product Owner、Scrum Master、整个团队 Sprint回顾不一定非得以会议的方式进行。 制定专门的“秘书”记录 我们会轮流发言，说出这个sprint中哪些可以做的更好，哪些需要在下个Sprint中改变 对估算生成率和实际生成率进行比较。如果差异比较大需要分析原因 结束之前Scrum Master进行总结，得出下个sprint需要改

14、进的地方。敏捷概述：（DSDM开发方法）精艺与敏捷精艺与敏捷是两组用友高度兼容的价值观和原则，都阐述了如何成功的进行产品开发，scrum、XP和看板都是经这些原则应用到实践的三种具体的方法。Srpint规划会议（Scrum）、结对编程（XP）、和限定在制品（看板）三种有相当部分的重复，例如：都建议使用真实的任务版将当前工作以可视化方式展现。敏捷宣言个体和互动胜过流程和工具可以工作的软件胜过详尽的文档客户合作胜过合同谈判响应变化胜过遵循变化建议原则 我们最重要的目标，是通过持续不断的尽早交付有价值的软件，使客户满意。 欣然面对需求变化，及时在开发后期也一样。为了客户的竞争优势，要通过敏捷过程掌控变化 经常交付可工作的软件，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，每一天都不例外 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支持，辅以信任，从而达成目标 不论团队内外，传递信息效果最好、效率最高的方式是面对面的沟通。 可用的软件是进度的首要度量标准。 敏捷过程倡导的可持续发展。责任人、开发人员和用户都能提供维持其步调的稳定延续 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。 简洁为本，它是激励减少不必要的工作量的艺术。 最好的架构、需求和设计，出自自己组织团队。 团队定期反思，如何能够提高成效，并以此调整自身的