Scrum总结

一个轻量级的软件开发方法

Scrum是一个敏捷开发框架，是一个增量迭代的开发过程.。在这个框架整个开发周期由若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的长度2到4周。在每个Sprint中，Scrum的开发团队拿到一个排列好优先级的需求列表，我们称它为用户故事或者叫Sprint backlog， 所以我们先开发的是对客户具有较高价值的需求。  在每个迭代结束后，都会开发完成可交付的产品。
一个简单的框架

Scrum由三个角色，三种活动，3种交付物组成：

三个角色：

Product Owner

Scrum Master

Scrum Team

三种活动:

the sprint planning meeting

daily scrum meetings

sprint review meetings

3种产物:

the product backlog

the sprint backlog

a burndown chart
一个经历过时间考验的开发过程

Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。

之后，Scrum成为领先的敏捷开发方法之一，目前世界上有超过500家公司在使用Scrum。



Scrum的特点：

    * Scrum是一个敏捷的流程，可用于管控研发工作。
    * Scrum是现有设计流程的总结。
    * Scrum以团队为基础，是一种在需求求迅速变化情况下迭代地、增量地开发系统和产品的方法。
    * Scrum是一个控制由利益和需求冲突导致的混乱的流程。
    * Scrum是改善交流并最优化合作的方式。
    * Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
    * Scrum是最大化生产率的一种方法。
    * Scrum适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
    * Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。





      二 Scrum较传统开发模型的优点

      Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。


      下图是Scrum模型和传统模型的对比：
            
      


Scrum有3个角色： Product Owner, ScrumMaster, and Scrum Team.

Product Owner的职责：

    * 确定产品的功能。
    * 决定发布的日期和发布内容。
    * 为产品的profitability of the product (ROI)负责。
    * 根据市场价值确定功能优先级。
    * 在30天内调整功能和调整功能优先级。
    * 接受或拒绝接受开发团队的工作成果。

Product Owner参与Scrum planning。

ScrumMaster 作为team leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:

    * 保证团队资源完全可被利用并且全部是高产出的。
    * 保证各个角色及职责的良好协作。
    * 解决团队开发中的障碍。
    * 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
    * 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。

ScrumMaster 除了主持Daily Scrum meeting之外，还有三个主要职责：

   1.
      Scrummaster需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。Scrummaster需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。
      scrummaster还必须仔细考虑进展中的开放任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。
   2.
      该scrummaster需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和scrum team有关，其他的全是公司的问题需要管理层关注。
   3.
      最后但并非最不重要， scrummaster可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。Scrum Master 必须注意去确保团队资源完全可被利用并且全部是高产出的。

Scrum Team:

    * 具有不同特长的团队成员，人数控制在7个左右
    * 确定Sprint目标和具体说明的工作成果。
    * 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
    * 高度的自我管理能力。
    * 向Product Owner演示产品功能。



Scrum有三个仪式：Sprint规划会，Sprint评审会，Scrum每日站会
Sprint Planning Meeting（Sprint规划会）

根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司，客户就是市场，Product Owner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景，规划出今后一段时间产品发展的路线图，以及根据对投资回报的贡献确定的产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。

当为一个Sprint定义好足够多的Product Backlog，并且排列好优先级后Scrum就可以开始了，Sprint规划会是用来细化当前跌打得开发计划的。规划会开始的时候，Product Owner会和Scrum team一起评审版本，路线图，发布计划，及Product Backlog。Scrum Team会评审Product Backlog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况看有多少feature可以放在当前的Sprint中。Scrum Team按照优先级的高低来确定开发的先后是很重要的。

当Sprint backlog确定后，ScrumMaster带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。
Daily Scrum Meeting（每日站会）

一旦计划阶段结束，30天周期的Sprint就开始了。ScrumMaster需要组织团队成员每天开站会. 这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上，每个团队成员需要问3个问题：我昨天做了什么，今天做什么，遇到哪些障碍。谁都可以参加这个会议，但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观，用于发现任何新的依赖，定位项目成员的要求，实时的调整当天开发计划.
Sprint Review Meeting（Sprint评审会）

在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。 业务，市场，技术都要做相关的评审。有Product Owner来决定Product Backlog中的哪些功能已经开发完成 ，还要和Scrum Team及相关的利益相关者讨论下个Sprint中Product Backlog的优先级。下个Sprint的目标在这个时候被确定下来。

会议的下半部分，是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。

Sprint评审会结束后，新一轮的迭代又继续开始，迭代会一直继续，直到开发了足够多的功能去交付一个产品。



   燃尽图（Burn down Charts）

2    每日站会（Daily Scrum Meeting）

3    障碍（Impediments）

4    产品Backlog(Product Backlog)

5    产品Backlog项（Product Backlog Item）

6    产品backlog项的工作量（Product Backlog Item Effort）

7    产品燃尽图（Product Burn down Chart）

8    产品负责人的角色 （Product Owner Role）

9    发布（Release）

10   发布燃尽图 （Release Burn down Chart）

11   Scrum角色（Scrum Roles）

12   Scrum Master角色

13   Sprint

14   Sprint Backlog

15   Sprint燃尽图（Sprint Burn down Chart）

16   Sprint 目标

17   Sprint计划会议 （Sprint Planning Meeting）

18   Sprint评审会议（Sprint Review Meeting）

19   Sprint任务（Sprint Task）

20   团队（Team）

21   团队成员（Team Member）

22   速率（Velocity）



　在这风起云涌的年代，最为人们津津乐道的国内互联网三巨头无疑是腾讯、百度和阿里巴巴，比较凑巧，鄙人曾在其中两家的研发部门任职。因为已离开Tencent，所以现在可以站在另一个角度冷静思考，梳理回忆当年的所见所感，让众人一睹Tencent研发的峥嵘。

　　Tencent的产业布局主要在IM即时通讯、互联网增值业务、网络游戏、无线应用、网络媒体、电子商务和广告业务，QQ注册用户超过7亿、活跃用户超过3亿，依托QQ、Qzone、游戏等平台优势，单一产品月收入过千万的比比皆是，像会员、Qzone、宠物、QQShow等，盈利能力超乎想像的强，年Revenue达38亿、市值超150亿美金，称其为吸金机器一点不为过，所以股价一直坚挺，在其他科技股纷纷低迷，却被证券市场成熟的香港投资人持续追捧，这都说明大众非常看好Tencent的业务前景和盈利能力。

说完商业表现再说研发背后，Tencent现有员工约4K，其中约一半为研发，研发岗位主要有产品经理、项目经理、开发工程师、UI工程师、测试工程师、运维工程师以及项目管理工程师、SQA和CMO等，开发语言和工具以C++、PHP、Linux和MySQL为主。现有服务器超1W台，其中 QQ同时在线约4KW，Qzone同时在线约500W，ITIL可用性指标超99.9%，以其中约300人的事业部门为例，同时研发/运营100个以上子产品，每月发布30个以上版本。

　　回想起来，对Tencent研发影响深远的有两家公司，一家是Google，它影响的是Tencent的研发文化；另一家是ThoughtWorks，它影响的是Tencent的研发管理。至于Tencent是如何引入并发扬，且听后续慢慢道来。

　　Google是互联网的传奇，其独特的开放和创新风格，奠定了它的世界级霸主地位。研究Google的人士都知道Google员工管理的十大黄金定律——

　　（1）组织委员会严把招聘关

　　（2）满足员工的所有需要

　　（3）拉近员工距离

　　（4）使合作简单协调

　　（5）身体力行，使用自己的产品

　　（6）鼓励创新

　　（7）尽可能统一意见

　　（8）不作恶

　　（9）数据决定决策

　　（10）有效地沟通交流

　　事实证明这是管理知识型员工的最佳方式。当年Tencent CTO Tony曾带队赴美国Google总部，亲身感受Google的文化魅力，回来后大加褒奖，立志效仿引进。在鄙人看来，Tencent吸纳了Google 文化的精髓主要有四点：宽松文化、创新文化、体验文化和精英文化。

　　一、宽松文化：

　　Google公司的办公环境是很多IT白领向往的天堂，员工可以带宠物、穿溜冰鞋上班，酒吧间、健身房、按摩房一应俱全，办公大楼之间提供滑轮车通行，初来乍到的很多人可能会有错觉，真不知道是不是进错了地方。

　　Tencent的办公环境也堪称一流，虽然自己的35层写字楼在建，现在还租用着飞亚达约八层楼和华强若干层，但在环境装修和硬件设施上丝毫不吝啬，包括桌球厅、休闲吧、阅览室，并入驻咖啡厅，办公座位装扮非常个性化，有大幅的海报、卡通玩具、绿色植物，甚至直接在办公区中间摆上沙发和液晶电视，供看比赛、听音乐或中午玩PSP。晚上八点提供免费晚餐，加班晚了不用担心，全天固定40多路大巴通往城市各处。行政秘书MM人数所占的比例是我经历的公司中最多的，每个BU都有办公室建制，她们为员工提供了很多后勤保障并营造氛围激励士气。

　　当然这是表象，让员工感受宽松与否的除了办公环境外还包括工作压力，在Tencent要想表现绩效、获得肯定并非容易，KPI 是把双刃剑，每季度的强制正态分布让不少人无奈，因为晋级的条件是必须连续两次拿A或S。另外少数中层干部“技而优则仕”，表现出来“管事不管人”，谈工作多、谈个人少，对人的内心关怀比较淡漠。

　　二、创新文化：

　　Google鼓励员工动用20%的时间用于自主研究，然后从员工创意中挑选Top20采纳应用，给与经费和资源转化成产品，像Google的桌面搜索、Orkut等产品都来源于当初员工的创新想法。

　　Tencent也非常鼓励创新，认为创新是互联网技术的灵魂，并写入了企业文化里。在组织架构上，Tencent设立有创新中心，专门实验互联网上的新生事物和形态，作为新产品初创期的孵化器，成熟后再移交给业务部门运营壮大。在创新渠道上，Tencent每年举办创新大赛，由一线员工提出众多构想，然后相互PK给与重奖。当然现在Tencent暂时还做不到腾出20%的时间出来让员工自主发挥，因为产品的压力持续存在着。

　　三、体验文化：

　　Google深信用户体验的好坏决定了产品对用户的粘性，因为同类型的产品实在太多，用户迁移转换的成本极低，所以如果自己用着都不爽，就更别说让用户来用了。

　　在Tencent也是如此，从产品人员、设计人员到各级经理都非常在意交互体验和设计，而对原型PK最多的也是这里，细到每个流程、每个按钮、每个图标甚至每个文字。主要体现在：

　　（1）用户体验小组，邀请客服人员和客户代表对产品现场反馈，几乎每个事业部都有。

　　（2）用户体验室，装有“眼动仪”以分析志愿者眼球的转动是否符合界面引导的初衷，以及长时间停留的区块。

　　（3）用户体验平台，陈列所有产品供员工随时反馈，并提供月度、季度积分排名。

　　（4）产品内部公测，每个重大产品发布之前都会发起，因为公司员工中不少就是QQ产品的忠实玩家。

　　（5）灰度放量发布，当不确定市场反应或用户真实需求的时候，先让部分用户灰度使用，收集体验反馈并修改完善后再放量发布。

　　四、精英文化：

　　Google对员工的素质能力要求很高，据说招聘时需要6个人以上集体把关面试，另外在Google博士尤其受欢迎，比例也很高。

　　Tencent的面试也很严格，T3（骨干级）以上至少要过4关，并经副总裁和CTO面试认可。除了社招以外，Tencent 也非常重视校园招聘，每年都组织到各地高校宣讲，“在一个好玩的地方实现自己的梦想”的校园招聘口号让人印象深刻。另外近年Tencent也加大了吸引高级人才的力度，T5（资深专家级）不断涌现。

　　培训也是Tencent对待员工职业发展的一项制度，培训区分新人培训、管理培训和职业培训，对管理干部有潜龙、飞龙和EMBA体系，尤其让鄙人难忘和受益的是一些精品课程，比如“六顶思考帽”、“高效能人士的七个习惯”、“带人带心的领导艺术”等等。

　　从上述的比较中大家可以看到很多Google文化在Tencent的烙印，这也说明这是一家善于学习、开放包容的企业。就像 Tencent推出的众多产品一样，虽然刚开始可能是后来者，但只要放手去做马上可以像模像样，甚至超越、打垮先来者，这也是Tencent真正可怕的地方。

　　ThoughtWorks公司是一家全球IT咨询公司，它可能不像Google那么响亮，但有一个名字我们技术人员不可能不知道—— Martin Fowler，堪称软件开发领域教父级的人物，他精通OO分析、架构设计和软件工程，立著颇多，像《UML精粹》、《重构》、《分析模式》、《企业应用架构模式》等不少获得Jolt大奖的著作都出自他的手笔，而他正是ThoughtWorks公司的首席科学家，同时也是敏捷联盟的17个始创人之一、以及敏捷宣言的起草人之一。至2008年，ThoughtWorks公司已连续举办了三届敏捷中国大会。

　　那么Tencent和ThoughtWorks两个不同类型的公司又是如何结下渊源的呢，话要从2006年说起，那时 Tencent规模已经开始膨胀，开发模式急需规范和标准化，到底走IPD（集成产品开发）还是Agile（敏捷）的开发路线，公司管理层也在为拿不定主意而犯愁，之后研发管理部开始与ThoughtWorks公司接触，逐渐将敏捷产品开发引入进来，并正式命名为TAPD（Tencent Agile Product Development）。

　　接触是从一次3天15W的培训开始的，ThoughtWorks派来了一个4人讲师团队，三天的课程让人印象深刻，由此也诞生了Tencent 日后推行敏捷的第一批种子。后来一想，这次培训本身就是敏捷的一次真实案例，成员临时抽调，有来自北京，也有来自西安；课程设置应我们临时要求即时调整，五天压缩成三天；讲解过程大量应用白纸、小纸条、图钉和白板等简单工具；关注学员的心情曲线等。这是一个拥抱变化的团队，从他们身上折射出沟通、简单、反馈和勇气的敏捷价值观。

　　简言之，Tencent的TAPD是吸收了XP+SCRUM+FDD三者特点的并行迭代开发模式，涉及范畴包括敏捷项目管理和敏捷软件开发。

　　一、敏捷项目管理：

　　（1）Iteration

　　软件开发模型经历了从瀑布到螺旋再到敏捷的过程，迭代不是敏捷独有的创造，无论在RUP还是在MSF中迭代都是其核心特性之一。而在Tencent特别强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。

　　Release（发布）可理解成当实现的产品Feature累积到一定用户价值时的正式发布，它是比Iteration更大的概念；Iteration（迭代）是在固定时间内开发Feature的过程，Release一般包括多次Iteration。

　　（2）TimeBox

　　TimeBox（时间箱）反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，在Tencent一般一至两周时间居多。

　　（3）Planning Game

　　对敏捷的一种常见误解是不要计划，其实在敏捷的体系中不仅强调计划，甚至区分Release计划、Iteration计划和 Task计划等多种不同粒度、不同时长的计划。Planning Game突出的是让用户代表参与，由用户代表评估UserStory/Feature的优先级，开发人员评估任务的开发时间，由用户代表+项目经理+核心成员三方共同排序、组合，确定本次迭代计划需要实现的Feature List。在Tencent用户代表就是产品经理。

　　（4）IterationPlanningMeeting

　　IterationPlanningMeeting就是Planning Game实现的管理形式，通过会议沟通达成。

　　（5）Stand-up Meeting

　　团队成员围成一圈，逐个说明3个问题：昨天做了什么，今天计划做什么，有没有困难并计划如何解决。对Team而言这是检查进度、快速调整非常有效的形式，在Tencent这已经成为大家每天早上的固定习惯。

　　（6）ShowCase

　　提交测试前由开发人员演示实现的功能，产品经理到场Review是否符合当初的设想，避免接近发布时才反馈。

　　（7）Retrospect

　　每个迭代结束后，项目经理组织或轮流组织所有Team成员共同回顾本次迭代的得与失，整理Well/LessWell，因为敏捷的团队是自我反省、持续调整的团队。

　　二、敏捷软件开发：

　　（1）Story Card/Story Wall/Feature List

　　StoryCard是XP中推荐的需求定义方法，要求符合Invest和Moscow原则；StoryWall则用于跟踪 StoryCard的变化状态，而FeatureList是Tencent一直沿用的需求表达形式，在Tencent的TAPD工具中已经实现了类似 ThoughtWorks 的Mingle的StoryCard管理功能，对于需求跟踪而言这是不错的方法，一目了然。

　　（2）Refactoring

　　相信我们都听过这句话：好的代码不是设计出来的，而是重构出来的。

　　（3）TDD

　　“测试驱动开发”在Tencent执行地并不太好，Tencent的产品以Web形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。相反自动化测试在Tencent比较盛行，因为有测试部门专门的自动化测试Team在推动，而且链接的是正式生产环境，可以即时反映产品当前的状态。

　　（4）Pair Programming

　　理论上结对编程可以提高代码的质量，而且并不会降低开发效率，但Tencent的业务繁忙，资源上不允许两人结对。

　　（5）CI

　　持续集成可以降低发布前集成阶段的难度与成本，Tencent的自动化构建系统推行的比较早，覆盖了大多数产品，而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。

　　（6）灰度发布

　　灰度发布是Tencent的又一创新，它将产品试用扩大到海量用户一端，在小范围及时吸取用户反馈，分析用户行为和喜好，持续修正自己产品的功能体验。

　　当然开发方法和流程确定了还远远不够，更难的是如何将它推动落地。首先Tencent组织开发了承载敏捷思想的TAPD项目管理工具，它类似 ThoughtWorks的Mingle；然后推出了敏捷能力模型，类似CMM成熟度模型一样对Team评级加以引导；同时还推出了敏捷指数排行榜形成竞争，营造你追我赶的声势氛围。

　　文章写到这里行将结束，最后我们分析Tencent为什么选择Google和ThoughtWorks，其实是由互联网行业本身的特点决定的，互联网的生存法则就是大鱼吃小鱼、快鱼吃慢鱼，谁转身的快、谁拥抱变化、谁更关注用户，谁才可以笑到最后。阿里巴巴董事局马云说过：今天很残酷，明天更残酷，后天很美好，但绝大多数人都死在明天晚上，却见不到后天的太阳















    * Scrum坚持如下敏捷开发原则：保持简单、接受变化、不断迭代、不断的反馈和改善、 协作和减少浪费
    * Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。
    * Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。Scrum一词来源于橄榄球运动，指“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。”
    * Scrum这一过程是迅速、有适应性、自组织的，它代表了从顺序开发过程以来的重大变化。
      Scrum的迭代过程被称为“快跑”，时间为2-4个礼拜。
    * Scrum团队一般由5-10人组成，Scrum团队不仅仅是一个程序员队伍，它还应该包括其他一些角色，如产品经理、设计人员和测试人员等
    * Scrum包含三类角色: Scrum Master， Product Owner， Scrum Team
    * 相对于传统的开发模式来讲，agile也好，scrum框架也好，都是现在软件开发中用于应对快速变化的市场和需求快速反应的一种变通
    * Scrum是一个非常轻量级的流程。简单讲是先建立一个产品"订单"(backlog)，做一个短期“冲刺”(sprint)计划，执行这个计划，每天开会讨论计划中的问题和进展，计划完成后演示工作成果，再对该阶段的工作做回顾、反思，接着不断重复以上流程。



[敏捷精灵日记]


    * 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划 分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下 落。

    * 瀑布模型有以下特点：

   1. 为项目提供了按阶段划分的检查点。
   2. 当前一阶段完成后，您只需要去关注后续阶段。
   3. 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，其主要问题在于：
   4. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
   5. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

    * 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

    * 在做大的变革之前，积极听取其他成员的意见，努力理解其他成员的观点；获得团队主要成员的支持，是保证变革成功的重要一环。

    * 软件开发根本就没有什么灵丹妙药可言。虽然敏捷编程技术可以很快开发出优秀的应用软件，但不是说这项技术适合每个项目。在实施敏捷之前，一定对现有项目做好分析，要对症下药。

    * 在Scrum开发模式下，为每个Sprint起一个名字，不但可以增加团队软件开发的乐趣，提高大家的参与程度，还可以记录下Scrum Team当时的心情



敏捷精灵日记】

· Scrum注重的是管理和组织实践，XP关注的是编程实践，可以分别解决不同领域的问题。可以组合使用，互相补充。

· 一条可以实行的实践原则，会比长篇大论的理论有用许多，没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践，必须通过XP或其他方法来补充

· 使用XP，可以使开发人员成为更好的Developer， 但Scrum方法能够迫使那些效率低的developer变得更有效率。

· Nokia的Scrum标准

1. Scrum 团队必须要有产品负责人，而且团队都清楚这个人是谁。
2. 产品负责人必须要有产品的Backlog，其中包括团队对它进行的估算。
3. 团队必须要有燃尽图，而且要了解他们自己的生产率。
4. 在一个Sprint中，外人不能干涉团队的工作。

· scrum虽然强调文档、流程和管理的轻量化，但并不是意味着没有控制，没有计划，只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整，从而达到提前交付

· ScrumMaster与传统项目经理相比，必须从从传统的控制者转变为引导者。

· scrum中，对任务细分和时间估计，需要整个开发小组和Product Owner的参与。

· Sprint计划会议议程

上午(2 Hours)

1)充实并讲解Product Backlog[Product Owner] (50 Minutes)
2)重新调整Product Backlog条目优先级[Product Owner] (10 Minutes)

休息(10 Minutes)

3)设定Sprint目标[Scrum Team] (10 Minutes)
4)选择Product Backlog条目，组成Sprint Backlog[Scrum Team] (40 Minutes)

下午(3-4 Hours)

1) 分成两个小组，进行任务细分， 定义"DONE"，给出任务估算. (60 Minutes)
2) 小组间互相评审，解决争议(20 Minutes)

休息(15 Minutes)

3) 关键路径分析(20 Minutes)
4) 制定资源计划(20 Minutes)
5) 任务领取(20 Minutes)
6) 风险分析(20 Minutes)
7) 其他事情(10 Minutes)



敏捷精灵日记】

    *

      Scrum 团队强调自我管理，自我引导，这其实是管理的最高境界，如果团队里面的每个人都能够时刻关注公司的或者部门的business，那么整个公司的利益自然会最大化，但是现实往往不是这样的。那么设立Scrum master时，是不是可以让每个人在每个sprint里都有这样的机会来带领团队，并感受这种business的view呢？实际操作中这个是不是有难度呢？起码在我们现在团队中还不是轮换Scrum Master的，没准以后我们可以试试！
    * 让Daily Scrum会议保持紧凑有效的指导原则：
          o 第一指导原则：主题明确，不能参杂其他无关的话题。
          o 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
          o 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。
          o 第四指导原则：确保整个团队都要参加每日Scrum会议。
          o 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议
          o 第六指导原则：每日Scrum站立会议应该控制在15分钟之内。
          o 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
          o 第八指导原则：Scrum站立会议要在每日同一时间同一地点举行
    * Scrum Master要及时解决Daily Scrum上提出的阻碍。这一点非常关键，Scrum Master必须要做到，否则会影响每个成员反应障碍的积极性。
    * 利用burn down chart来跟踪细分任务的完成情况，可以在项目进程的任何时间点都能够看到项目进展状况，而不是每周或者项目完成之后，从而保证了开发进度处于可控制的状态。



敏捷精灵日记]

    * 管理中的愤怒和羞辱是会传染的.如果高级经理喜欢骂人,低级管理者也会这样做。
    * 如果经理使用辱骂的方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
    * 作为一个经理，宁讲错话，不讲假话。假话一旦揭穿，底层员工从此再也无法信任上层经理





[敏捷精灵日记]

    * Sprint0---"兵不厌诈（the Big Con）"

因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊

    * Sprint1---"越狱记（Breakout）

经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第二个Sprint取得重大突破（breakout）

    * Sprint2---"虎口余生（Hours to doom day）"

这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的工作就无法进行，将是非常关键的一次攻坚战。

    * Sprint3---"大结局(The Big End)"

这次计划会议，作为Scrum Master，自己因为有事没有参加，汗！但大家认为阶段性工作基本差不多可以做完了，起了个结局的名字。



[敏捷精灵日记]

    * 采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。
    * 在 “冲刺”和“冲刺”之间，留几天缓冲时间很重要。团队需要一段时间做一下调整，赶一些非sprint计划中的事情。这段时间是一个很好的用来解决一些技术 或者工具问题的机会。你会发现你慢一下后，会变得更有效率。这就是为什么叫“sprint”的一个理由，你不可能无休止的冲刺。
    * 没有规矩，不成方圆。由团队共同制定出来的Scrum团队规则，可以更好的保证Scrum的顺利实施。

[Scrum团队规则]

1. 每日站立例会迟到，罚款￥5.
2. 对于每个，未及时更新任务状态和剩余工作量，整个Team留三次免罚机会，以后再有人违反，则罚款￥5.
3. 对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款￥5.
4. 进行任务细分时，每个任务估算最大不能超过18小时(三天)
5. 在Sprint计划会议上, 认领了一项任务的人，可以对该任务估算做出不超过50%的调整
6. 对于复杂任务的估算和分解，采用“DELPHI”方法
7. 每个人都可以添加新的product backlog条目, 但必须标示为 'Not Reviewed'， 以方便Product Owner审议.
8. 为提高Sprint回顾会议的效率，在Sprint回顾会议之前,每一个人应该给出“我们做得好的地方、需要改进的地方”
10. 在Sprint计划会议上, 我们应该预留10%的估算时间作为缓冲，以应对突发事件
11。 在Sprint计划会议上, 我们应该进行关键路径、风险、外部依赖的分析
12. 对于Review，发出review的人必须给出截止日期，参与Review的人，必须在截止日期前给出答复。



[敏捷精灵日记]

1．持续集成最大的优点是可以避免传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

    * 访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码（以及以前的版本）。
    * 支持自动化创建脚本，使 创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
    * 测试完全自动化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运行一套完整的系统测试。
    * 提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
    * 提倡开发人员频繁的提交（check in）修改过的代码。


2．项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。



课程首页
[报告] [上一个] [下一个]
63%

Scrum
Intro c
Role c
Meeting c
glossary c
ByQQ c
Addenda c
Scrum和XP实践 c
Scrum对应列表 c
敏捷精灵日志
intro1 c
intro2 c
intro3 c
intro4 c
intro5 c
intro6 c
intro7 c
intro8 c
intro9 c
intro10 c
intro11 n
intro12 n
intro13 n
intro14 n
intro15 n
intro16 n
intro17 n
intro18 n
intro19 n
intro20 n
intro21 n
scrumExcelTemp c
.


[敏捷精灵日记]

    * TDD 以可验证的方式迫使开发人员将质量内建在思维中, 长期的测试先行将历练开发人员思维的质量，而事后的单元测试只是惶恐的跟随者.
    * 重构不是一种构建软件的工具，不是一种设计软件的模式，也不是一个软件开发过程中的环节，正确理解重构的人应该把重构看成一种书写代码的方式或习惯，重构时时刻刻有可能发生。
    * 软件构建学问中总有一些理论上很美好，但是一使用就可能面目全非，比如传统的瀑布模型。敏捷里很多被称之为思想的东西，恰恰没有太高深的理论，但都是一 些实践的艺术，强调动手做而不是用理论论证。TDD就是这样一种东西，单纯去研究它的理论，分析它的优点和缺点没有任何意义，因为它本身就是一个很单纯的东西，再对其抽象也得不出象“相对论”那样深厚的理论。更多的实践会给出正确的答案的。
    * 结对编程不是一种形式化的组合，在实际的XP小组中，结对的双方应该是根据需要不断变换的，对的结成应该是自发的，应该保证双方都是对这部分工作感兴趣的人，而不是强行指定。
    * 结对编程不是结队编程，是2个人，不是更多


    * 就象Scrum一样，并不是所有的team都有能力实行XP，也不是所有的项目都适合实行XP，要看实际情况而定。
    * xp中，多数实践方法是互相加强甚至是互相保证的，不能单单拿出某一个实践来单独实施，譬如结对编程，缺乏TDD/重构/简单递增设计的实践的有效补充，效果可能会大打折扣。



敏捷精灵日记]


    * 对Prodcut Backlog中的用户故事做估算时，如果某项太大太空难以确切估算，及时对它细化。
    * 使用计划纸牌可以极高的提高估算速度。一次估算中，如果任何两个人的估算值相差过大，一定要停下来澄清后，再重新估算。
    * 给团队配置两倍的人，并不能得到两倍的生产力的。人越多，交流的成本越大，效率就越低。如果希望靠增加人员来提高软件团队的生产力，无疑是南辕北辙







    * 精益软件开发的七大原则：

         1. 消除浪费(eleminate waste)
         2. 强化学习，鼓励改进(Focus on learning)
         3. “注重质量”build quality in
         4. “推迟承诺”defer commitment.
         5. “尽快交付”deliver fast
         6. “尊重员工” respect people
         7. 优化整体 optimize the whole



    * 准时化开发 = 持续集成 + 迭代开发 + 多次交付。
    * 零库存 = TDD + 每次迭代都给出可以发布的版本。









    * 拥抱变化（Embrace the change）

无论是多么明智，多么正确的决定，也有可能在日后发生改 变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变 的是变化”。团队更要信任利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风 险，实现团队最大化利益，理解这是适应市场变化的必然行为。而在接受变化的同时，我们应该积极的向利益干系人（Stakeholder）和客户代表反映实 现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案 可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。

    *

      对一个项目开发来说，release (发布）拥抱变化。对于一个sprint/iteration，要拒绝变化。sprint计划前，product backlog都可以变化。
    * ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。
    * ScrumMaster使团队在Sprint过程中免受干预
    * 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标
    * 在影响Scrum正常实施的众多因素中，在sprint过程中加入新需求，大部分人都很难很难抵御这样的诱惑，是scrum的第一杀手。
    * 在一个Sprint执行过程中，如果遇到一些问题导致 Sprint的原始目标不能实现，此时需要及时地 调整目标。如果不愿意调整目标，任意延长sprint的时间，就严格违反了Sprint的Time-Box特性，以后大家再遇到问题时，会自然而然的想再 延长Sprint，那么Sprint快跑的意义也就不存在了。
    * 从另外一个角度讲，如果急于看到结果而压缩sprint的时间，可能得到一定的效果，但总体上会消耗的更多的资源，让团队疲惫不堪，造成生产力低下。






    * 正确衡量生产力的公式：生产力=已经完成的工作量 – 用于修正Bug的工作量 – 用于修正错误设计的工作量
    * 任何想在短期内迅速提高生产力的想法都是杀鸡取卵的自杀式行为。
    * 任何时候，工作超过40小时，都需要恢复期，无论你怎么调整；一周35-40小时可以这样安排：每天工作10小时，持续四天，然后休息三天。上述“压缩工作周”，不仅可以减少缺勤，在某些情况下，可以提高生产力10-70%
    * 每周四天工作制会比五天工作制效率更高。
    * 短期不超过3个礼拜的冲刺会临时提高生产力， 团队可以有策略的选择加班，可以完成最近的最后期限；加班后，生产力会有同等程度的降低，应该根据这个因素马上调整计划
    * 按照项目划分成跨功能的小团队；对于大的项目，利用’Scrum-Of-Scrums’把小团队联系在一起；制定关于创建团队、划分大团队、团队间人员流动的流程/规则
    * 混合团队会比单一团队效率更高
    * 好的管理人员会想办法鼓励团队去创新，会选择预留一定时间让团队去思考如何创新，而不会压榨员工的每一分钟。




传统的软件开发


各类大中小型企业所运用的传统软件构建方法，即是众人在很多变体，但其典型性是在开发初期制定详细的计划，计，并且一切详细资料都记录在案。任务已设计制定，并工具和Microsoft Project 项目管理软件。开发团队预计开发而得出的。当项目管理者(stakeholder)全面审核开发计划并团队成员完成他们所专长的部分工作，即刻转交给其他成工作都已完成，成品将会转交给产品质量控制部门，在这的全面检测。在整个流程中，所有相对于原始计划的分歧成品与原始设计保持一致。

此种模式有优点但也有不足之处。它的最大的优点是非常记录下来，按照计划实施，保持各项事务尽可能的有组织参与,人对于此种工作方式并不适合。

比如：此种方式要求所有的建议和想法都要在开发周期的可以被容入开发计划之中。但是众所周知，好的想法和建开发最启始阶段，在开发中期，有时可以在产品交付使用许变化的产生，那么将会遏制创新的产生。在使用“瀑布新将不是好的征兆，而是对整个产品开发产生的危机。

瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个
成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的最实际的证据。但是实
际上，在大多数情况下，没人会读这些100 页左右的详细规格要求资料。同样，如果有人读取
该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资
料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的
产生也就不足为奇了。

当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品
时，你可能会立刻产生20 种方法以使产品更加完美的灵感。但是遗憾的是，这些非常有价值的
想法通常会在产品开发的末期产生，这时创新是最困难和最具有分裂性的——换句话说，是做
正确抉择最昂贵的时刻。

人的预知未来的能力是有限的。比如，某场比赛的最终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能
力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (根特)图表的衰败
表现。

另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要
求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些指引我们对瀑布方式的另一思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。

一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是在产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并
将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和最起始的想法保持一致，
而不是开发团队在实践中不断发现可能性而使其尽善尽美。

许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是一个极其付有逻辑性的方式，所以第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发
挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利
地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的
结果越差！

Agile (敏捷) 开发和Scrum

Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况, 以便取得更好效果的信念上。Agile 强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。
Agile 注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile 注重快速
迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile 的时候，经常会有这样的公认——感觉非常像回到了开发启始的阶段，我们曾经”做过”。

Scrum 是众多快速发展的Agile 方式之一。Scrum 是在十多年前由Ken Schwaber 和Jeff
Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ,
Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE Medical, CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这
是非常重要的。Scrum 是简单的，强有力的，并立足于常识之中的。




Scrum 是迭代的，增量型的流程。
Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。
在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。
每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint 做好准备。

Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。



敏捷精灵日记]

   1. 无论一个测试人员有没有发现Bug，都不能说明他有没有好好工作。测试人员的职责更多的应该是‘保证质量’（quality assurance），而不是“控制质量”（quality control）。一个好的测试人员应该是在问题出现之前，防止其成为Bug。
   2. 对于一个敏捷团队而言，再单纯以测试人员发现的Bug数量，作为衡量其绩效的唯一标准，是非常没有意义的。
   3. 如果有一个核心测试集，能够覆盖用户如何使用一个产品的常用情形，会更有价值。对所有用户使用情形都做自动化测试是没有必要的。

在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。

产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。

开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。

ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的 ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时，ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。



如何启动Scrum

  Scrum 的第一步是产品所有者清晰地展示产品的未来景象（vision）。这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。这就是Product Backlog,它存在（并发展）于产品的整个生命周期（图示2）。Product Backlog 包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和已知的bugs（“判断并修复定单流程中的错误”）。


Product Backlog 是由产品所有者随时更新，以反映客户需求的变化，竞争对手的发布，新的想法和见识，出现的技术障碍等等。



在项目开发的任何时候，Product Backlog 是唯一具有权威性的“需要完成的所有任务”的概况。只可以存在唯一一个Product Backlog；这就意味着产品所有者需要在所有的工作范围中作出优先项的决策。






[敏捷精灵日记]

    * 为Sprint中任务给出明确的”DONE” 定义是非常重要的，但即使你遵循这个最佳实践，但最终仍然会有集成问题，会存在Bug, 以及晚期的需求变更。所以，在正式发布前，单独计划1-2个Sprint, 专门做Bug修复，是非常合理的，并不是“反Scrum”的模式。

Sprint 计划会议是保证整个Scrum顺利进行的重要一环之一！如何开好，非常关键！

Sprint 计划会议在每一Sprint 的启始阶段进行。在Sprint 计划会议的第一部分，产品所有者和Scrum 开发团队（在ScrumMaster 的协助下）共同评审Product Backlog，讨论Backlog 中各项目的目标和背景，并提供Scrum 开发团队深入了解产品所有者想法的机会。在会议的第二部分，Scrum 开发团队从Product Backlog 中挑选项目并承诺在Sprint 的末期完成任务，从ProductBacklog 的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序依次工作。这是Scrum 的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，他或她只知道开发团队负责的项目是由Product Backlog 中按顺序从上至下进行的——换而言之，是从他或她选择的最重要的项目开始。开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。


Sprint 计划会议通常会持续几个小时——开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完 成Sprint 相关工作的时间开始——换句话说，是团队成员平均的工作时间减去他们花费在检修bug 和其他必要的维护工作，参加各种会议，回复电子邮件，午休等的时间。大多数人会有4 到6 个小时每个工作日可以完成Sprint 相关的工作。（图示3）

当可利用时间确定下来，开发团队会从Product Backlog 的顶端第一项开始工作——换句话说，从产品所有者的最高优先权项开始——团队共同工作，将其分配为小块任务，并记录在SprintBacklog 中（图示4）。当任务确定后，团队成员可以自愿承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog 分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog 序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估算时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务（写在便签上）在Sprint 中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。



Scrum 的重要支柱之一是当Scrum 开发团队确认承诺任务后，产品所有者在此Sprint 期间不可以添加新的需求。这就意味着即使在Sprint 中途，产品所有者想要添加新要求，他或她在下一新的Sprint 开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该 Sprint；意味着开发团队停止一切工作，重新开始Sprint 计划会议等等。此种决断会产生很大的影响,除非在非常特别情况下，不会采用这种方式。

保证开发团队在Sprint 中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排 Product Backlog 中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint 中不可变更的，使其在决定从哪一项目开始工作更为细心。

作为回报，产品所有者也可以得到两个好处。首先，他或她有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum 开发团队将会做的很好。第二，产品所有者可以在下一Sprint 开始前，提出他或她希望的变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint 进行中提出任何变更，他或她只是需要等待一个Sprint 的完成时间或更短。不再僵持于是否变化——方向的变更，条件的变更，或只是简单的想法的变更——可能正式此原因，使得产品所有者成为Scrum 拥护者中最热衷的成员。



Scrum介绍系列5--- 每日站立例会（Daily standup meeting）


每当Sprint 开始, Scrum 开发团队将会实施另一个Scrum 的重要实践方法:每日（站立）例会。这是在每个工作日特定的时间举行的短小（15 分钟）的会议，Scrum 开发团队的每一成员都将参与；为了保证其短小精悍，与会成员都保持站立（因此为“站立会议”）。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。

一个接一个，每个团队成员只可以向其他人汇报三件事情：

    * 从上次会议之后完成了哪些工作，
    * 在下次会议之前准备完成哪些工作，
    * 在工作进行中存在哪些障碍。


ScrumMaster 将会把障碍内容记录下来，在会后协助团队成员铲除障碍。在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后进行。产品所有者，经理和项目管理者可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论——每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向产品所有者，经理或ScrumMaster 汇报。这个会议并没有标准形式，有些团队感觉邀请产品所有者参加并将其每日工作做一简要阐述，是对团队工作极其有意义的。

在会议结束后，开发团队成员将对其负责的Sprint Backlog 中的项目做剩余时间的更新。这些信息会记录在Sprint Burndown Chart 图表中（图示5）。它是用来显示每日直至开发团队完成全部任务的剩余工作量（以小时或天计算）。理想的情况下，抛物线轨道在Sprint 的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少（对于Scrum 来说这是不太相关的事项），而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint 末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。此图表也可以使用Excel 表格管理，许多团队认为在他们工作室的墙上用图纸标明更为简单和有效，并可以用笔随时更新；这个技术含量不高的做法比电子表格更快速，简易和更可见。
Scrum 的核心原则之一是Sprint 的周期不可以延长——其结束于指定的时间不论开发团队完成任务与否。如果开发团队未完成其Sprint 目标，他们将在Sprint 的末期声明他们没有完成预期的任务。这个方法创造了反馈循环的可视性，并强制开发团队在Sprint 预期估算时做出更好的判断，并确保可以按时完成任务不会失败。开发团队通常在前几个Sprint 时试图完成许多任务，但实际上并不可以达到Sprint 目标；然后他们可能会过度小心而挑选较少的任务，结果会提前完成；在第三或第四个Sprint 时，开发团队通常会了解自己的工作效率，他们会按时完成Sprint 的目标。鼓励开发团队在某一Sprint 中挑选一个周期（比如两周）并且不经常变化——固定的周期可以帮助开发团队了解他们的实际工作效率，并且可以帮助其达到工作的节奏性（此指团队的统一“心跳”）。


    在Sprint 结束后，将进行Sprint 评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10 分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈