Scrum敏捷开发笔记
1. 极限编程（XP）、Scrum、精益软件开发、动态系统开发方法（DSDM）、特征驱动开发、水晶开发（Crystal Clear）
2. 敏捷开发注重沟通，对需求、变更积极
3. 个体和交互重于过程和工具，可工作的软件重于面面俱到的文档，客户合作重于合同谈判、响应变化重于遵循计划
4. Scrum是一个增量、迭代的开发过程。整个开发过程分成若干个小的迭代周期，每一个小的迭代周期成为Sprint，每个Sprint的长度建议为2-4周。Scrum中，用Backlog来管理产品或项目的需求，产品Backlog是一个按照商业价值排序的需求列表，列表条目的体现通常为用户故事。在每个Spring中，从Backlog中挑选对用户具有较高价值的需求。Spring挑选的需求将经过Spring计划会议上的分析、讨论和估算得到一个Spring 的计划列表，成为Sprint Backlog。在每个迭代周期，团队交付一个产品增量。
5. Scrum术语解释
Sprint：原意为冲刺，Scrum指Sprint为一个迭代周期，即一个交付周期一般2-3周为宜，特别是互联网项目
Backlog：待办列表，既等待认领或者开发的任务列表
Product Backlog：产品待办列表，指产品的需求列表
User Story：用户故事，指一条需求，也就是一个功能点
Story Point：衡量用户故事的工作量大小的计量单位。一般为天/小时
Product Owner：产品负责人，简称PO。就是产品经理，即需求提出方，需求决定着。
Sprint Task：实现一条需求需要做的一个技术任务
6. 贯穿Scrum的三种角色
Product Owner（OP，产品经理）、Scrum Master（项目经理）、Scrum Team（开发团队）
7. Scrum过程中的四种会议
Sprint Planning Meeting（Sprint计划会议）
Daily Scrum Meeting（每日站会）
Sprint Review Meeting（Sprint的评审会议，演示）
Sprint Retrospective Meeting（Sprint回顾会议）
8. Scrum健康状态显示的两个工具
Backlog（待办列表）：Sprint Backlog（Sprint的需求列表）和Product Backlog（产品的需求列表）
Burn-down chart（燃尽图、进度图）：Sprint燃尽图和发布燃尽图（releaseburn-down chart）
9. Sprint Planning Meeting（计划会议，需求会议）
在每个Sprint前召开，一般为2-3小时。就是团队确认和沟通的过程。
会议上主要解决两个问题：1.决定在Sprint中完成哪些工作？ 2.决定如何完成这些工作，需要多长时间？
会议内容：
1. 分析和评估产品Backlog
2. 确定Sprint目标
3. 决定如何达到Sprint目标（设计）
4. 根据产品Backlog条目创建Sprint Backlog
5. 为Sprint Backlog每个条目做预估，用小时算。
会议注意事项：
A． 需求整理
1. Scrum的理念是解放产品经理写复杂的详细的prd文档，当然一些业务场景的原型图还是需要的。
2. Backlog要简单明了，没必要写详细的描述文字，开发过程中要注意实时沟通。
3. 召开Planning Meeting之前产品经理整理好需求列表，及其排好一个大概优先级。需求由产品负责人负责。
B． 任务拆分
1. Backlog要停留在业务需求层面上
2. 把用户story拆分成合理的需求，产品经理要提前做好拆分的功课。
3. 超过5天或者10天以上的任务要拆成小需求，降低估算难度。
4. 任务的开发时间由team决定。
C． 估算时间
1. 永远不要站在牺牲内部质量的基础上。
2. 估算方式可以用Scrum纸牌，所有人一起出牌，求平均，单位最好是小时。
3. 尊重每一个选择，当差距过大时，问清楚原因，但不要指责。
4. 估算时间的时候每个人都没有发言和干预权，有干活的人一起评估。
一旦确定Sprint的周期后，如果由紧急的任务加进来，根据优先级，将低优先级的需求下降，或者将时间长的任务拆分或化解。
10. Daily Meeting。每日立会，就像每日工作报告。由Scrum Master（项目经理）组织，由每个团队成员轮流回答三个问题
昨天我做了什么？今天我计划做什么？我遇到了哪些问题？
注意事项：
1. 不可以干预，只说与这三个问题有关的内容。由需要讨论的内容，记录下来稍后讨论。
2. Scrum Master 和 ProductOwner必须要参加
3. 团队成员互相交流，不是向Scrum Master报告
4. 一个自组织的团队有一个非常明显的每天的节奏：Daily Scrum之前非常安静，每日站会之后有一段活跃的讨论，到午饭之前慢慢安静下来。午饭之后会有另一个阶段的活跃讨论，当下班前慢慢的安静下来。这就是一个自组织团队的脉冲。如果你能感受到这个节奏，说明这个团队是健康的，每日立会起到了效果。
意义所在：
1. 团队商量决定谁来做什么，为当天排一个计划。
2. 每日立会是团队面对面沟通和团队自组织的体现
3. 团队沟通状态，了解现状，发现障碍。
4. 每日立会是Scrum过程进行每天的检查和调整的环节。团队回顾昨天的工作，做调整，持续的改进。
5. Scrum的理论基础是保持过程的透明性让参与过程的所有人了解真实状况
6. 同时可以更新Sprint Backlog和Sprint燃尽图
11. Sprint Demo Meeting/SprintReview Meeting
全体参加，还可以找公司的得利益者和很多外援，旁听的人越多越好。阐述Sprint的目标，大概描述一下，在开始之前。不要做花里胡哨的演讲，演示可以工作的实际代码。注意力放在我做了什么，而不是我怎么做的。Demo这一定是开发者，要给所有人展示和show的机会，不要越俎代庖。尽量1小时解决，控制在2小时内。
一定要做Demo Meeting，一定要有时间概念。
意义：
1. 促使Team真正的完成工作（如果工作没有真正完成，Demo时自己就会过意不去）。
2. 增加开发人员的快感，使之得到大家的认同感。
3. 同时让其他工作人员了解到你的成果。
4. 有助于提高开发者的工作积极性，都会想做更多的东西，以至于下次Demo时有更多的东西。
5. 同时可以让同伴增加沟通和了解，同时可以锻炼程序员的口才能力。
注意事项：
1. 当细节太多的时候，不要演示一大堆琐碎的Bug修复h额微不足道的特性。
2. 想办法让“无法演示的东西”变得可以演示，这是一个show的机会。
12. Sprint Retrospective Meeting（Sprint回顾会议）
目的是回顾一下团队在流程人际关系和工具方面做的如何，团队意识出哪些做得好，哪些做的不好，并找出潜在的改进事项，为将来的改进制定计划。
团队的定期自我检视，什么是好的，什么是不好的。
每个Sprint都要做
每个人都要参加
开始的时候轮流发言，而不是主动发言。
记录问题，总结，并讨论改进的方法，放在回顾看板上
每人三个磁铁，将最重要的2-3个需求，成为下一轮的产品需求
13. Scrum会议执行的五种价值观
1. 承诺——愿意对目标做出承诺
2. 专注——把你的心思和能力都用到你承诺的工作上去
3. 开放——Scrum把项目中的一切开放给所有人看
4. 尊重——每个人都有他独特的背景和经验
5. 勇气——有勇气做出承诺，履行承诺，接受别人的尊重
14. Product Owner职责
1. 确定产品的功能。
2. 决定发布的日期和发布内容。
3. 为产品的profitability of the product负责。
4. 根据市场价值确定功能优先级。
5. 每个Sprint，根据需要调整功能和优先级。（每个Sprint前调整）
6. 接受或拒绝开发团队的工作成果。
7. 产品负责人是管理产品待办事项（Product Bakclog）的唯一负责人。
8. 任何人都不得要求开发团队按照另一套需求开展工作，开发团队也不允许听从任何其他人的指令。
PO的品质：
1. 确保对Product Backlog的每个条目都达到一定程度的理解
2. 任何时候都在，随时沟通需求
3. 懂业务，逻辑清晰
4. 善于沟通
5. 果断，提供需求边界
6. 得到授权
7. 全能型产品经理
8. 一个Team只有一个产品经理
9. PO当然也可以由自己的需求团队
15. Scrum Master 的职责：
1. 保证团队资源完全可被利用并且全部是高产出的。
2. 作为团队和外部的接口，屏蔽外界对团队成员的干扰。
3. 保证开发过程按计划进行，组织Daily Scrum，Sprint Review and Sprint Planning Meeting，推动Scrum活动。
4. 保证各个角色及职责的良好协作。
5. 解决团队开发中的障碍。
6. 对团队产出的最大化负责人。
7. 发起能提升Scrum团队生产力的变革。
Scrum Master的品质：
1. Scrum Master 是Scrum团队中的服务式领导。
2. Scrum Master是Scrum教练，非常熟练运用Scrum。
3. 一个敢于向老板等人说NO的人，保证开发tean不受打扰。
4. 负责，最大化的对团队产出负责。
5. 谦逊、协作、投入、有影响力。
6. 始终贯穿One Team，One Dream
16. Scrum Team
1. 一般情况下人数在5-9人左右。
2. 团队要跨职能（包括开发人员、测试人员、用户界面设计师等）。
3. 团队成员需要全职。（有些情况例外，例如数据库管理员）。
4. 在项目向导范围内有权利做任何事情以确保达到Spring的目标。
5. 高度的自我组织能力。
6. 向Product Owner演示产品功能。
7. 团队成员构成在Sprint 内不允许变化。
8. Scrum不认可开发团队成员的头衔，无论承担哪种工作，他们都是开发者。此规则无一例。
17. Sprint Backlog示例
| Task |
Owner |
Planning hours |
Status |
| 开发图片上传后台程序 |
小华 |
8h |
Done |
18. Scrum的工具
1. JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
2. Leankit使用一个基于云基础的whiteboard来称述组织流程。每一个图卡代表工作项目，并且提供状态更新选项。团队使用Leankit就可以看到工作负载分布，也能导出历史数据。
3. Rally Platform for AgileLifecycle Management这是一个基于云技术的敏捷生命周期管理平台，在无数个团队里扩展使用，带有自定义界面、还能够自定义显示面板的功能，以达到自动化控制各种开发流程。
4. Trello的目标是提供简洁清晰的团队协作工具。在Trello里面，有三个最基本的元素：Board、List和Card
5. 国内由禅道等。
19. Scrum 实施过程中的注意事项
1. 如果在每个迭代中，我们对“完成”的要求比较低，那将会造成我们会有很多遗留的完成外工作。完成外工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为积累了太多的完成外工作而无法发布，以至于我们还需要一个额外的Sprint来使它稳定。
2. 开发团队在每个Sprint交付产品功能增量。这个增量是可用的，所以产品负责人可以选择立刻发布它。每个增加都附加于之前的所有增量并经过充分测试,以此保证所有增量都能工作。
3. Sprint的长度越长，我们需要预测的就越多，复杂度会提高、风险也会增加，所以Sprint的长度最好不要超过4周。越来越多的团队使用2周的Sprint，很多市场变化快、竞争激烈的领域，比如互联网和移动互联网开发团队也会使用1周的迭代。
4. 无休止的Sprint开发的同时，切勿忽略了团队的培养和培训方面的工作。
5. Scrum 的四个特点：迭代开发、增量交付、高优先级的需求驱动、自组织团队
20. 敏捷开发并不完全是反文档的，敏捷团队要确定哪些知识需要显性化，既文档化，哪些知识保持隐形即可，这样可以节省文档化的工作量。