参考地址
http://developer.51cto.com/art/200907/136850.htm
角色
一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆起什么名字呢？”，鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样？”，“我不这么认为”，猪说, “我全身投入，而你只是参与而已”
猪是全身投入项目和Scrum过程的人，有三种角色：产品负责人（Product Owner）、ScrumMaster、团队（Team）。
| 角色 | 职责 |
| ProductOwner | 确定产品的功能 决定发布的日期和发布内容 为产品的profitability of the product (ROI)负责 根据市场价值确定功能优先级 在30天内调整功能和调整功能优先级 接受或拒绝接受开发团队的工作成果 |
| ScrumMaster | 排除产品开发和产品负责人之间的障碍，确保产品负责人流程推动开发工作 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标 激发创造力和放权，从而改善开发团队的环境 千方百计实践和工具，确保每个功能增量都具备潜在可交付行 向各方确保团队工作进展实时更新并高度可视 |
| Scrum Team | 具有不同特长的团队成员，人数控制在7个左右 确定Sprint目标和具体说明的工作成果 在项目向导范围内有权利做任何事情已确保达到Sprint的目标 高度的自我管理能力 向Product Owner演示产品功能 |
鸡角色并不是实际Scrum流程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使用户和利益相关者参与到过程中的实践。参与每一个评审和计划，并提供反馈对于这些人来说是非常重要的，管理者就属于鸡。
基本流程
在知道Scrum的主要角色后，我们看看下图中的过程图：它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。
术语
Backlog
Product Backlog
在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。
Sprint Backlog
Sprint Backlog 是Sprint规划会上产出的一个工作成果.当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum team和Product Owner 协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。
会议
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 Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。Sprint评审会结束后，新一轮的迭代又继续开始（中间最好修整半天或者隔个周末），迭代会一直继续，直到开发了足够多的功能去交付一个产品。
燃尽图
概念
燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量吗”的时候，第一反应就是它。
燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。
图中左侧460是迭代开始的第一天，所有故事的未完成时间相加为460天，而在最右侧则表明在第17天，所有故事的剩余时间相加变为0，也就是所有故事都完成了。
为什么总和会递减呢？因为每个组员每天都要汇报一件事情：当前正在做的故事，还剩余几天，如果昨天剩余3天，今天剩余2天，那么就为燃烧图贡献了1天的进度。
由于可能出现“昨天剩余3天，又工作了一天后本以为会只剩下2天，结果感觉可能还要3天（甚至变成5天了！）”这种情况，所以燃尽图常常有一些起伏。
燃尽图的“指纹”
图中的燃尽图尽管有一些起伏，依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大，常见的情况包括：
先鼓起后落下
原因是计划会以常常漏掉一些事情，所以开工后不但不燃尽，还发现了很多新的任务。
先完美燃烧，然后突然停止燃烧
一种很常见的情况，如果任务划分太粗，比如长达10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的时候，哎呀，好像搞不定了”。
先缓慢燃烧，然后到快燃尽的时候剩下一堆没完成的任务，被推迟到下个迭代
之前提到过敏捷开发的MoSCoW方法，有些故事是次要的“可以不做的”，所以这种燃烧图也很常见；但是常常有团队没有使用MoSCoW方法，只是被动地发现有些故事没有完成。
Scrum和xp的区别
参考地址：http://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
Scrum和xp是敏捷开发中两个重要的方法，他们相似度很大。如果你的团队用了其中一个方法，你可能还分不清楚你到底是在一个Scrum团队还是xp团队。他们的区别很小，但是很重要：
1. 迭代周期不通，scrum一般是两到四周，xp一般是一或者两周。
2. 迭代是否允许修改，在xp中如果一个user story还没有实现，则可以考虑用另外的需求将其替换。替换的原则是时间量相等。而scrum使不允许的，一旦scrum planning会议开完，任何需求都是不允许改变的，由scrum master把关，避免开发团队受到干扰。
3. XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
4. Scrum不规定工程师如何去做，XP就规定了。比如TDD，测试驱动，自动化测试，重构等。XP这些很好，但是却有个误区：“你是自管理的，我相信你，但是你必须去做TDD,重构。。。”
在管理模式上启用Scrum，而在实践中，创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)
敏捷开发中对进度的把握
参考地址：
http://developer.51cto.com/art/200906/130031.htm
在敏捷开发方式中，先由用户和设计人员粗略估计各个功能模块的相对规模和难度，给出一定的分值。分值不代表具体人月，起相对比较的作用。例如有查询、显示、修改三个模块，如果实现显示模块的工作量是10分，那么查询模块可能是15分，而修改为20分。
下一步，选择一个工作量估分最低的模块，例如这里是显示模块，然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询，显示内容等等。假设这轮估算得出此模块需要10人天，从而得出单位分值对应的人天为1；那么，整个项目就需要45人天。
这个估算建立在对项目的初步了解上，主要依赖项目经理的经验。有偏差？没关系。接下来通过迭代来求精。先来实现显示模块，如果事实上花费了12人天，那么根据比例关系，剩余内容的估算大约就是42人天。
当然，比例关系也不是一成不变的。随着模块的逐个完成，项目经理对项目的认识也在加深，他可以再调整剩余模块的相对分值。
在实际操作中，项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分，再选择分值最小的模块开始开发。统计总工作量时，按比例累加其他模块的工作量，并加一定的调整系数，因为模块的复杂度不是线性增长的。每次迭代开发完成后，逐步降低调整系数。通常4~5次迭代后，可以将调整系数归零。
在上面的例子中，第一次估算的初步结果是45人天，因为完全是凭经验，因此要给较大的调整系数，比如说0.4，因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见，项目经理上报的工作量为70人天。
第二次估算，剩余内容的初步估算为42，调整系数下降为0.3，因此给出估算区间为30到50人天之间。依此类推，通过不断迭代，对剩余工作量的估算将越来越精确。
在每天的例会上，开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间，敏捷方式只关心这项任务还需要多少时间去完成，直到归零，然后再来统计实际的工作时间。
在每天例会中，项目经理需要注意时间曲线保持水平的成员，他是不是遇到瓶颈了，是否需求帮助？也要留意时间曲线下降幅度过大的成员，他发现了什么好的办法，有没有低估需求？这样，项目经理会更面向结果，只要按计划保证质量完成任务就行，成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容，第一是因繁琐而失真。其次，一旦上级发现某人工作时间不够（即便他完成了任务），忍不住会派新任务，从而造成越干活越多，反过来打击程序员的积极性。
敏捷估算的关键之处，是把成员能力这个变量的估算，交给最合适的人去做，即程序员本人。然后通过比较历次迭代时的预估和实际时间，给出校正系数，以避免程序员过于保守或过于乐观。这肯定不是绝对准确的，但效果往往比项目经理自己拍脑袋估算，然后强行指定deadline 要好得多。
我的问题：
1. 如何加入新功能。
2. 敏捷开发迭代中途加入新的任务，加班，项目延期？是否需要重新评估，是否需要修改burndown chart？
3. 敏捷开发发现时间估算错误，或者以前的任务实现方法行不通，如何办？
4. 做产品订单的时候是否需要细化，评估出完成的时间，因为这个需求是可能变化的。
5. 任务的粒度大小？
6. 不同专项的人如何预估时间？
7. 进度和质量如何保证，因为task是团队成员自己估算的，两者有冲突？