BJUG
敏捷软件开发方法理论与实战
敏捷软件开发方法理论与实战
https://www.doczj.com/doc/7e14313002.html,/ mailto:morningspace@https://www.doczj.com/doc/7e14313002.html,
https://www.doczj.com/doc/7e14313002.html,/
BJUG
敏捷软件开发方法理论与实战
议 题
? ? ? ? 敏捷方法概述 极限编程简介 敏捷实践案例 敏捷游戏
https://www.doczj.com/doc/7e14313002.html,/
BJUG
敏捷软件开发方法理论与实战
敏捷方法概述
https://www.doczj.com/doc/7e14313002.html,/
BJUG
敏捷软件开发方法理论与实战
开场白
军事历史就是一个在装备和灵活性的相对优势之间来回摇摆 的钟摆。
—— 卡尔·冯·克劳塞维茨《战争论》
– – – –
盔甲骑士 vs. 布衣士兵 盔甲骑士 vs. 轻骑兵 坦克 vs. 轻骑兵 坦克 vs. 反坦克导弹
在IT领域，我们正好都在从装备统治一切的时代走出来。现 在我们正进入一个唯有灵活性才是至关重要的时代。
—— Tom DeMarco《规划极限编程》序
– 工程方法 vs. 没有方法 – 工程方法 vs. 敏捷方法
https://www.doczj.com/doc/7e14313002.html,/
BJUG
敏捷软件开发方法理论与实战
工程方法 Engineering Methodology
? 借鉴了工程领域的实践，有着严格而详尽的规定，强调 项目的可控性 ? 官僚繁琐，要做太多的事情从而延缓开发进程 ? 从泰勒主义，到精益制造
https://www.doczj.com/doc/7e14313002.html,/
https://www.doczj.com/doc/7e14313002.html, 个人管理－使用Scrum来敏捷自己 每个人都有自己的生活和自己的职业或事业，如果把经营个人成长作为一个项目来看，那么在这个个人管理项目中，我们每个人都是这个项目的管理者和执行者。 Scrum敏捷开发方法 如果你是一名开发人员，那么现在还不知道Scrum方法，那么你就out了。Scrum是一种现在普遍流行并且很好的一种基于管理为主的敏捷项目开发方法。我之前blog中全面概要的介绍了一下Scrum方法，如果你不熟悉的而又想了解下面内容，请你最好去去仔细看看我这篇文章《流程－从IT方法论来谈Scrum》，因为下面我将描述我们如何基于Scrum方法来进行个人管理项目的执行。 价值观 在Agile Software Development with Scrum一书中指出，Scrum的核心价值观是：承诺、专注、公开、敬重和勇气，它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则，这些价值观对个人管理依然非常有效。 1. 承诺（Commitment）：我们是否经常暗下决心，一定要戒掉游戏，一定要完成这 个任务，但是最后是不是仍旧还存在脑子里。如果你有这种现象，那么你需要做的就是自己对自己承诺，自己相信自己，如果自己都不能相信自己，那么谁又能相信你呢？ 2. 专注（Focus）：要事第一，对一件事情投入100％去做好 3. 公开（Openness）：有人说，能力就像怀孕一样，时间久了才能看出来，你个人 的学习、个人的Open都需要公开的表达才能让别人知道 4. 敬重（Respect）：三人行必有我师，空杯心态，尊重每一个人，向不同的学习
Scrum敏捷软件开发过程 目录 ?什么是敏捷软件开发？ ?敏捷方法的项目计划 ?敏捷项目管理和传统项目管理 ?为什么使用敏捷？ ?Scrum概述 ?Scrum的角色 ?Scrum实践和工作产品 ?敏捷开发中的估计方法 ?测试驱动开发 ?Scrum应用 ?支持工具和模版 ?一些常见的误解 敏捷开发方法 什么是敏捷软件开发? ?敏捷软件开发是软件项目的一个概念框架. ?有许多建立在敏捷概念上的方法，如Scrum和Extreme Programming(XP). ?与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）?最大限度地降低短期固定时间的迭代式软件的开发风险. 敏捷宣言（2001年） ?人和交互胜过过程和工具. ?Individuals and interactions over processes and tools ?可以工作的软件胜过完备的文档. ?Working software over comprehensive documents ?客户协作胜过合同谈判. ?Customer collaboration over contract negotiation ?随时应对变化胜过遵循计划. ?Responding to change over following a plan 敏捷过程的限制 ?敏捷软件开发过程包含过程、原则、工具，和最重要的-人 ?因此：诚信是基础 ?没有过程能够对诚信进行有效地约束，诚信与否是有效实施敏捷过程的最大限制
Product constantly Scope frozen new PBL items to next Sprint Backlog 使用敏捷方法的项目计划 “Sprintful” of top - priority PBL to the next Sprint Sprint More accurate estimates as man hours 8 Short term planning (commitment by May be 5 2 1 3 8 5 8 ∑32 Long term planning (best guess at the moment): Initial Size Estimates As Story Points Velocity 8 SP/Sprint 4 Sprints T arget Sprint for each PBL item set, feasible implementation Order. 敏捷项目管理和传统项目管理 ? 传统项目管理： ? 事先对整个项目进行估计、计划、分析 ? 反对变更; 变更需要重新估计、重新规划 ? 严密的合同来减少风险, 如果改变需求要走 CR 流程. ? 项目作为一个“黑盒子”，对客户与供应商的可视性差. ? 产品化和测试阶段是分离的. ? 文档和计划驱动的方法. ? 软件交付时间晚, 意识到风险的时间晚. ? 敏捷项目管理: ? 对整个项目做一个粗略的估计,每一次迭代都有详细的计划. ? 鼓励变化, 客户价值驱动开发. ? 信任和赋予权力;合约使变更变得简单，增加价值. ? 客户和开发人员之间是紧密的连续的合作关系 ? 每次迭代都产生可交付的软件 ? 专注于交付软件. ? 第一次迭代就可交付能工作的版本，风险发现的早. 为什么采用敏捷? –预期的收益 ? 采用敏捷方法得当的话，可以： ? 更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 . ? 快速交付, 每次迭代都能交付可运行的软件. ? 最高风险和最高优先级的需求，最优先进行开发. ? 改善应对变更能力, 减少大量的重计划. ? 改善项目沟通. ? 更好的客户参与, 避免错误的假设. ? 总之: ? 提高了生产率; 减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明
敏捷项目管理 公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]
拥抱变化、快速响应、平等协作、持续改进 -- PMI-ACP敏捷项目管理与创新之道 文/银联培训中心主管于兆鹏 随着首届世界互联网大会召开，“互联网变革”又一次撞击了人们的眼球。人类历史上曾经发生过许多次伟大的变革，但从来没有一场变革像“互联网变革”一样能触及全球70亿个个体。 不仅仅是互联网让我们在变！ 随着中国经济的转型和新生代消费群体的崛起，中国乃至世界的社会经济模式正经历着： ----以生产为核心到以需求为核心的转变 ----以商户为核心到以用户为核心的转变 ----以产品功能为核心到产品体验和个性为核心的转变 中国正在进行着由卖方市场到买方市场的重大社会变革，中国经济也因此将由原来的粗放型经济形式转变为集约型经济形式，由原来的世界工厂转变为未来的创新基地。 在这样的时代背景下，变革参与者需要深谙互联网“开放、平等、协作、分享”的精髓，通过互联网、移动互联网等各种工具，使得传统企业的业务具备透明度更强、参与度更高、协作性更好、中间成本更低。一句话，正如彼得德鲁克所指出的：“互联网消灭一切基于信息不对称的商业模式”。 在新的商业模式下，作为项目经理的我们需要关注：
----如何拥抱变化，抛弃传统模式封闭的弊端，以极限迭代引领客户需求和市场变化； ----如何简化流程，最大化客户收益，始终关注组织和客户的核心价值点； ----如何将客户拉进团队，让客户之声成为打造制胜产品的真正利器； ----如何最大化激发团队潜能和创新力量，摆脱传统管理模式带给人性的束缚和禁锢； ----如何将持续改进纳入到团队每天、每小时、每分钟的工作循环，使改进这一词汇不再成为原来项目经理的口头禅，而是每个团队成员心中的戴明环； 对于我们而言，尽情享受“这场变革”的同时，正确把握社会的发展方向，才能使之继续造福于全社会。 ? 一、为什么需要敏捷 长期以来，受传统项目管理思维的影响，项目计划往往需要很完备才有能开工的理由。我们往往因为不清楚WBS（工作分解结构）应该分解到何种程度而苦恼，或在一开始就试图将项目的方方面面都考虑得很周全，这在项目真实场景中是不可能的。 许多项目报告，尤其是在项目早期阶段显得过于乐观。因为让一个项目经理接受他们的进度会落后于时间表是一件非常困难的事情。在项目分析阶段，想知道总共有多少分析量是不可能的。那这样问题就来了，你既然不知道总量，又如何知道现在的工作能按部就班完成呢
Copyright ? 2010 https://www.doczj.com/doc/7e14313002.html, 专业的敏捷开发社区 Scrum 中文网 Scrum介绍 Scrum中文网 https://www.doczj.com/doc/7e14313002.html, 版权说明：本文部分资料及图片翻译自Pete Deemer 的Introduction to Scrum for Managers and Executives 以及Mike Cohn 的An Introduction to Scrum.
专业的敏捷开发社区 Scrum 中文网 许多企业面临的问题与挑战 ? 产品投放市场的时间太慢 ? 项目失败的比例高的离谱 ? 投资回报低，经常失败 ? 对变化与变更的响应，难度大且成本高 ? 客户体验及客户为导向很差 ? 软件质量不过关 ? 生产力需要大幅提高 ? 员工士气，动力及责任感很低 ? 需要普遍的微观管理 ? 人员流失率特别高 ......
专业的敏捷开发社区 Scrum 中文网 越来越多的企业开始使用Scrum 解决这些问题 ?Google ?IBM ?Nokia ?Siemens ?Philips ?Accenture ?Sun ?UbisoB ?Bleum ?SAP ? Microsoft ? Infosys ? Oracle ? Wipro ? Motorola ? Yahoo! ? Schneider ? Agilent ? Irdeto ? Double Click ? Autodesk ? Tencent ? Plenware ? Trendmicro ? Moody ’s ? StarCite
专业的敏捷开发社区 Scrum 中文网 哪些类型的项目已经在使用Scrum ?大型企业级软件项目 ?商业软件产品 ?消费者软件项目/大型网站 ?美国FDA批准的应用于X射线和MRI的软件 ?高可靠性系统（99.9999％以上） ?财务支付系统 ?智能家居项目 ?战斗机项目 ?大型数据库应用 ?嵌入式电信系统 ?手机项目 ?CMMI5级的组织 ?多地点同步开发 ?支撑和维护项目 ?非软件项目 ? ……
敏捷开发简介 2009-04-21 17:46:34.0 来源:https://www.doczj.com/doc/7e14313002.html, 关键词：Scrum精益开发敏捷开发 在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。 敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。 敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周 期持续的时间一般较短，通常为一到六周。 2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使 用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化 和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。 4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候 集成，有些项目则每天都在这么做。 5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给 人。 简史 许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。 20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Soft ware Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。 20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生
Scrum培训认证 背景介绍: 什么是Scrum? 什么是Scrum Alliance(Scrum联盟)的Scrum认证体系? Scrum联盟认证CST讲师风采 Scrum认证证书 如何获得Scrum认证？ 新的CSP认证成长路径变化 如何获得CSP认证Scrum Education Units (SEUs)进行个人发展和成长？ 你们的课程能否提供PMI的PDU及敏捷ACP认证所需的学习小时？ 什么是Scrum ？ Scrum是一个实现了敏捷思维的框架，帮助团队快速前进和学习，是一种把事情搞定的敏捷方法，Scrum常常与其他敏捷框架结合起来使用。全球70%以上的组织选择了Scrum进行敏捷软件开发和敏捷项目管理。 什么是Scrum联盟认证体系？ Scrum Alliance总部位于美国，是一个为Scrum和敏捷实践者提供教育、资源和支持的组织。深入一步，你会发现Scrum联盟是观念和变革运动的一部分。Scrum联盟提供主张、社区参与、研究、人际网络和关注组织变革，这些变革正在改变着全球的工作方式。Scrum 是一个非盈利组织，由全球超过50万认证者组成，驱使我们的不是商业，也不是什么财务盈亏；我们的动力正是来自于全球社区的成员，以及寻求实现真正工作与生活平衡的每个人。Scrum认证由国际Scrum联盟（https://www.doczj.com/doc/7e14313002.html,）制定和维护，针对个人职业发展的敏捷认证体系，Scrum认证证书由Scrum联盟官方统一颁发和维护。其中基础级认证面向Scrum的三个角色：ScrumMaster、Product Owner和交付团队。UPerform敏捷学院是中国领先的Scrum认证及敏捷培训授权服务机构。 关于CSM及CSPO认证: 自2018年起，最新Scrum认证体系更新如下：
实例详解敏捷测试 第一部分：敏捷软件开发简介 敏捷软件开发（Agile Software Development）初起于九十年代中期。最早是为了与传统的瀑布软件开发模式（waterfall model）相比较，所以当时的方法叫做轻量级方法（Lightweight methods）。二十世纪初，17 位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。 敏捷联盟在成立之初总结了四条基本的价值原则： 1.人员交流重于过程与工具（Individuals and interactions over processes and tools） 2.软件产品重于长篇大论（Working software over comprehensive documentation） 3.客户协作重于合同谈判（Customer collaboration over contract negotiation） 4.随机应变重于循规蹈矩（Responding to change over following a plan） 基于这四点原则，敏捷软件开发有着自己独特的流程（参见图1）。 图 1. 敏捷软件开发流程 整个过程中夹杂了很多在敏捷开发前己经出现的软件开发方法，包括极限编程（Extreme Programming,1996）、Scrum（1986）、特征驱动开发（Feature Driven Development），测试驱动开发（Test Driven Development）等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。 例如，Scrum 主要着重于项目管理，团队中的项目经理（Scrum master）需要在每个客户需求到来的时候制定Sprint 的周期，定义每个Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的Sprint。
Scrum指南 Scrum的权威指南: 游戏规则 2013年7月由Ken Schwaber和Jeff Sutherland开发并维护
目录 Scrum指南的目的 (3) Scrum的定义 (3) Scrum理论 (3) 透明性 (3) 检视 (4) 调整 (4) Scrum团队 (4) 产品负责人 (4) 开发团队 (5) Scrum Master (5) Scrum事件 (6) Sprint (7) Sprint计划会议 (8) 每日Scrum站会 (9) Sprint评审会议 (9) Sprint回顾会议 (10) Scrum工件 (11) 产品待办列表 (11) Sprint待办列表 (12) 增量 (12) 工件的透明性 (12) “完成”的定义 (13) 结束语 (13) 致谢 (13) 人们 (14) 历史 (14) 翻译 (14) ?2014 https://www.doczj.com/doc/7e14313002.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Scrum指南的目的 Scrum是用于开发和支持复杂产品的框架。这份指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。Ken Schwaber和Jeff Sutherland创造了Scrum，Scrum指南也由他们撰写提供。他们是Scrum指南的后盾。 Scrum的定义 Scrum: Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。 Scrum是： ?轻量级的 ?容易理解的 ?难以精通的 自上世纪90年代初期以来，Scrum就已经应用于管理复杂产品的开发。Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效（relative efficacy）显现出来，以便进行改进。 Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。 Scrum的规则把事件、角色和工件组织在一起，管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。 实施Scrum的方案根据情况不同而不同，在这里不作介绍。 Scrum理论 Scrum基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法来优化可预测性和管理风险。 透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。 透明性 流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。 例如： ?2014 https://www.doczj.com/doc/7e14313002.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
敏捷与SCRUM 笔试题 姓名： 一、选择题 1.团队成员在执行相关禅道任务的时候，发现需求不明确，应该找谁？ ____C_____ A、ScrumMaster B、部门经理 C、ProcuctOwner D、团队其他成员 2. 团队成员在执行相关禅道任务的时候，发现需要申请一台测试机，应该找谁？___A______ A、ScrumMaster B、部门经理 C、ProcuctOwner D、团队其他成员 3. 团队成员在工作中，对自己的职业规划和技术能力提升产生困惑，应该找谁？ ______B___ A、ScrumMaster B、部门经理 C、ProcuctOwner D、团队其他成员 4.以下哪些角色不是SCRUM框架中定义的角色_________D_________ A、ScrumMaster B、部门经理 C、ProductOwner D、架构师 5. SCRUM框架下，测试工作应该由谁来完成？______D___________ A、ScrumMaster B、测试部门 C、开发人员 D、团队 6. SCRUM框架下，那个角色对团队的开发效率负责？__________A_______ A、ScrumMaster
B、部门经理 C、ProcuctOwner D、团队 7. SCRUM框架下，那个角色对软件的交付负责？__________D _______ A、ScrumMaster B、部门经理 C、ProcuctOwner D、团队 8. SCRUM框架下，那个角色对软件商业价值负责？________C_________ A、ScrumMaster B、部门经理 C、ProcuctOwner D、团队 二、问答题 1．PO创建需求的INVEST原则是什么？ 独立性（Independent）—要尽可能的让一个用户故事独立于其他的用户故事。 可协商性（Negotiable）—一个用户故事的内容要是可以协商的，用户故事不是合同。 有价值（Valuable）—每个故事必须对客户具有价值（无论是用户还是购买方）。 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。 短小（Small）—一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。 2．PO做需求变更的步骤是什么？ 1. 与客户一起，约定变更管理的流程. 最好在合同中约定，至少也要在启动会上约定。 2. 提出变更申请应该按照约定的流程通过由负责人提交给项目经理。 3. 项目经理收到需求变更申请，先了解前因后果和客户的目标，然后优先从系统外解决，如 果不行的话再进行变更工作量的评估和影响的分析，进行审批。 4. 审评过程中销售人员起到很重要的作用，因为销售要给出变更所需费用的来源，并要给出 承诺，否则变更没办法继续。 5. 其他审批人则根据自己的角色和职责进行审批即可。 6. 审批结束，进入执行环节，对绝大多数的变更，都可以不用马上执行变更动作，可以几个 变更作为一批一起执行，一方面可以降低频繁变更对项目工作的影响，另一方面对一些客户一时兴起变过来过不久又变回去的变更可以起到拦截作用。
1什么是SCRUM 一个轻量级的软件开发方法 Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程.。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。 一个简单的开发框架 图表 1 一个简单的开发框架 Scrum由三个角色，六个时间箱，四个工件组成： 三个角色： 1. 产品负责人（Product Owner） 2. Scrum Master 3. Scrum团队 六个时间箱: 1. Sprint 2. 发布计划会议（Release Planning Meeting） 3. Sprint计划会议（Sprint Planning Meeting）
4. 每日站会（Daily Scrum Meeting） 5. Sprint评审会议（Sprint Review Meeting） 6. Sprint回顾会议（Sprint Retrospective Meeting） 四个工件 1. 产品Backlog（Product Backlog） 2. 发布燃尽图（Release Burndown Chart） 3. SprintBacklog（Sprint Backlog） 4. Sprint燃尽图（Sprint Burndown Chart） 一个经历过时间考验的开发过程 Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。之后，Scrum成为领先的敏捷开发方法之一，目前世界上有超过500家公司在使用Scrum。 2Scrum三个角色及其职责介绍 每个Scrum团队包括3个角色：产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。产品负责人 产品负责人的职责： 确定产品的功能，负责维护产品Backlog。 决定产品的发布日期和发布内容。 为产品的投资回报率(ROI)负责。 根据市场价值确定功能优先级。 在每个Sprint开始前调整功能和调整功能优先级。 在Sprint结束时接受或拒绝接受开发团队的工作成果。 产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。 为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人
在SCRUM方法中将项目的利益相关者分成两大类：Pigs角色与chickens 角色，pigs即为项目组的实际参与人员，chickens为项目组的外部人员，包括经理、最终用户等等。Pigs在scrum中细分为三个角色：Scrum master、Product owner、Team，这三个对等地位的角色构成一个平衡的铁三角推动整个项目的进展。 Scrum master不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他在项目组承担了如下的细分角色：（1）会议主持人 他负责主持四个主要的会议：策划会议、每日站立会议、迭代评审会议、迭代回顾会议。 （2）牧羊犬 他负责屏蔽项目组外部的干扰。 （3）雷锋 他给product owner、team提供帮助，帮助product owner 确定需求、排定优先级，帮助team做估算、分解任务、完成任务。（4）外交官 当项目组外部有人不理解项目组的工作时，他负责去解释说明，负责对外发布项目组的信息。
（5）教练 他指导项目组的成员按照SCRUM的原则、方法做事情，当出现偏差时，他去纠正，可以说他是精神教父、他也是警察（QA）。如果有项目组的成员不熟悉SCRUM的方法，他要去提供相关的培训。 （6）清道夫 他负责排除在项目进展中遇到的各种障碍，如果他没有能力 或资源他可以协调项目组的其他成员一起来排除障碍。 SCRUM master.并非固定的由一个人承担，可以在一个团队中，有能力的、熟悉SCRUM的成员都可以担当SCRUM master。 Product owner是产品的负责人，或者讲是需求的负责人，他在项目组承担了如下细分角色： （1）领域专家 他是需求方面的专家，熟悉需求。他知道客户、最终用户、以及其他利益相关者对项目的真正需求是是什么。他负责编写用户需求、维护用户需求。 （2）需求决策人
定制化项目管理框架：敏捷/Scrum/Kanban 导读：Scrum、Kanban、精益开发、Lean Startup、DSDM、FDD—这就是字母汤。这些在项目管理中又是如何建设的呢,其中有没有拿来就可用的或者要定制化自己的方案。 关键词：目管理框架技术债务敏捷Scrum Kanba 【TechTarget中国原创】Scrum、Kanban、精益开发、Lean Startup、DSDM、FDD—这就是字母汤。这些在项目管理中又是如何建设的呢？这其中有没有贵公司拿来就可用的？抑或你需要定制化出自己的方案？ 不要陷进品牌和商标里面。要盯住贵公司的目标不放。要想取得长期成功，目标需要具备有可能最好的质量，这样产品才可以愉悦客户，同时还能让技术债务保持在可管理的水平上。 怎样才能知道你的团队何时是敏捷的？我推荐Elisabeth Hendrickson的敏捷酸性测试（Agile Acid Test）：敏捷团队以可持续的节奏带来持续价值的同时适应业务的变更需求。此处的关键是“可持续的节奏。”我们必须每两周、每一周、每天多次地交付生产就绪的代码，我们不需要疯狂工作和实现每一个新功能都要花越来越长的时间。 自然地，我们转向已有流程寻找答案。Scrum和Kanban均提供项目管理框架。不仅仅是软件团队，整个组织内部都在采用精益开发。极限编程（XP）提供了核心开发实践，这适合于任何项目管理框架。有的公司则想出自己的方式去开发产品，但仍然通过了“敏捷酸性测试。”
提出合适的问题 “敏捷”并不意味着“跑得更快。”正如前面所述，向敏捷的成功转变需要预先有巨大的时间、学习及训练上的投入，但这些投入从长期来看也会带来巨大的回报。 通过让你的软件组织的每个人一起提出好问题来开启你的敏捷之旅，最大的问题是什么，是不是清除这个障碍你的团队就会前进一大步？这有可能是技能的缺失、软硬件基础设施的不足，项目不能按期交付，交付的产品不符合客户需求等任何潜在的问题。识别出你最大的障碍，战役就算是打完了一半了。每次迭代都至少回顾一次是最有价值的敏捷实践。 一旦识别出最大的障碍，考虑进行小型实验让这个问题变小一点，或者规避此问题一段时间。选择小规模实验可以得到快速反馈，供下一次迭代进行调整。比方说，你的最大问题是每天都有好几次编译失败。你可以试着用彩灯在团队所在区域来显示持续建造进程的状态。 在你下一次回顾的时候，看看那个最大的障碍是不是变小了一点。如果没有，考虑尝试另一种小型试验方法。你也许会发现真正的问题出在别处。或者也许你的试验把障碍规模削减了25%，使得它不再成为你最大的障碍。这种情况下，你就得转移到现在的最大障碍然后重复这一过程。 用替代方案教育自己 现在，你已经专注通过尝试小型试验、检查和适配来削除自己的最大障碍。你仍然需要一些框架来管理你的产品开发和项目进程。你还需要核心开发实践来保持技术债务在一个可管理的水平上。哪一种敏捷“风味”最适合你的情况呢？ 在评估不同敏捷实践、过程、框架及工具时，敏捷宣言及其原则是你最好的
S C R U M敏捷开发基础及失败成功案例分析 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998
什么是敏捷开发方法什么是SCRUM 有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。 那么，敏捷这个词到底由何而来呢在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方法）。在2001年，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷，并发布了敏捷开发者宣言。 敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。 敏捷开发方法是这些轻量级方法的总称，它旗下有很多具体的开发过程和方法。主要的有：极限编程（XP）、特征驱动软件开发（FDD）、SCRUM开发方法等等。SCRUM开发方法是由Jeff Sutherland在1993年创立，Jeff也是制定敏捷宣言的17位专家之一。SCRUM借用了橄榄球运动中的术语——一个团队拿球向前冲。 严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个什么样的开发框架呢简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。 ·角色（Role）：产品主管（Procuct Owner），他负责项目的商业价值；SCRUM师傅（ScrumMaster），他负责团队的运转和生产；以及自组织的团队。 ·会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。
“燃尽图”--保持项目可视性 “燃尽图解释与表示方法” 燃尽图，在Wiki上面没有单独的解释，只有在Scrum上面对其有基本的解释，燃尽图 燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。 A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule. 我找寻了几张燃尽图，比较具有代表性意义： 手工燃尽图 详尽“燃尽图”
中国原创的说法：燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。 燃尽图有多种表示方法与意义，每一个公司，每一个项目可能都不同，公司可以根据需要定制自己燃尽图，甚至进行特别的修饰与修改，但无论如何表示与修改，燃尽图具有一个共同的特点：就是可视性 “为什么需要燃尽图”? 上面展示的燃尽图的表示方法与意义，我们可以看到很多公司在实行敏捷过程都使用了这个燃尽图，显然这个燃尽图有它存在的合理与意义，在讨论这个意义之前，我们需要回答几个问题: 1.“燃尽图”到底谁会关注？ 2.“燃尽图”需要谁去填写？ 3.“燃尽图”应该如何填写？ 上面这三个问题留给读者先去思考，随着后面章节讲述，上面三个问题会得一解决，读者可以带着以上三个看这篇文章，希望在读完文章之后，读者会自己答复以上三个问题。 “燃尽图”展示了一种新的管理工作报告，他向管理者与利益相关展示了目前产品BackLog完成情况与整体进度，管理层与利益相关者可以很容易地通过燃尽图了解实时的进度以及细节，管理层更能够实时把握产品的进度并做出正确的决策，并且预计风险，同时随时调整计划。 传统的项目报告一般是固定，系统的，向管理者展示了项目的进展，完成百分比，以及遇到的问题，需要解决与补救的方法，而实际上在开发过程当中，又会有不断的需求加进来，这种传统的项目报告无法应对这种需求，导致往往项目执行者将项目的失败都归咎于需求的增加与变化，并且责备管理层不能做出正确决策。