Scrum简述
核心点：
- 把组织拆分成小规模的、跨职能的自组织团队
- 把工作拆分成一系列小而具体的交付物，按优先级排序，估算相对工作量
- 把时间拆分成固定大小的短迭代，在每个迭代结束时对基本可以交付的代码进行演示
- 每个迭代结束后进行回顾进行过程优化
相较于靠一个庞大的团队，花大量的时间造成一个庞然大物，Scrum倾向于用小团队在短时间内做出小块的东西，在有规律的集成中组装出全貌
核心要素
核心思想：1. 小规模跨职能团队 2. 单一产品backlog列表 3. 小步发布 4. 价值驱动 5. 产品思维
人员组织：1. 产品负责人 2. Scrum Master 3. DevOps团队
四类会议：1. Sprint迭代会议 2. 每日站会 3. 演示会议 4. 回顾会议
常用工具：1. 计划扑克 2. 索引卡 3. 燃尽图 4. 任务板
产品backlog
产品backlog是Scrum的核心，也是一切的起源，产品backlog也被称为用户故事，backlog中一般包括这样一些字段：
- ID：统一标识符
- Name：简短的、描述性的故事名
- Importance：产品负责人估出一个数值，指出这个故事有多重要，分数越高越重要
- Initial estimate：团队的初步估算，与其他故事相比，完成（经过测试验证、可以交付的完整实现）该故事所需要的工作量，最小的单位是故事点，一般大致相当于一个“理想人天”
- How to demo：大略描述这个故事应该如何在sprint演示上进行示范（先这样做，然后那样做，就应该得到...的结果）
- Note：相关信息、解释说明和对其他资料的引用
在编写产品backlog时应该尽量避免出现技术故事，如：重构DAO层、升级Jira等，产品backlog应当专注于业务层次（价值驱动 + 产品导向），技术故事可以转化为技术描述可以放在Notes中，或者努力找到一种方式把技术故事变成可以衡量业务价值的普通故事，实在不行就放入的专门的列表并用“投入程度”和“预估生产率”与产品负责人协商（升级Jira可以提高投入程度进而在下下个迭代可以用更高的生成率）
注意，只有产品负责人可以评估重要性，同时只有开发团队可以估算故事点，这在Sprint迭代会议和安排下迭代的产品backlog时会排上大用场
Sprint迭代会议
在Sprint迭代会议开始前，产品负责需要提前准备好足够的产品backlog，并为每个产品backlog划分好重要性以及范围，在迭代会议期间，开发团队会按照重要性的顺序从高到底对于每个产品backlog通过计划扑克的方式（每个人同时给出预估值，避免盲从）预估对应的故事点，直到选中产品backlog的故事点达到下一个Sprint预估可以完成故事点为止，有只有开发团队可以预估故事点，因此产品负责人值可以通过修改重要性、修改作用范围以及拆分产品backlog的方式去间接地影响下一个Sprint需要做完成的产品backlog，从而达成重要性、范围以及预估故事点三要素之间的协调
Sprint迭代会议的大致流程如下：
- 确定迭代目标与演示时间
- 使用计划扑克估算一些高优先级的用户故事的故事点
- 定义或者理解用户故事的How to demo以及Definition of Done
- 估算下个迭代的生产力（估算生产力/总故事点数 = 可用人天 * 投入程度）并选择总故事点数在生产力内的产品backlog放入sprint backlog
- 为每日例会安排时间地点
- 如果时间允许，将用户故事拆分成为任务（用户故事和任务的区别在于，用户故事是产品负责人感兴趣的以及能够带来价值的产品，而任务是完成对应用户故事的一个个步骤，比如：编写测试、实现Dao层等具体的设计、开发、测试步骤）
针对上述过程，可以使用索引卡记录故事并平铺才桌上，从而在讨论的时候可以让大家都参与进来，并发地编辑多个故事并轻松地重新划分故事的优先级
Sprint过程
任务板
使用一面很大的白墙或者白板作为任务版，然后给这个任务版划分一下各个阶段，主要包括：Not Checked Out，Cheecked Out，Done以及一张燃尽图
在Sprint开始的时候，把所有的任务Backlog通过贴纸的方式贴在Not Checked Out中，然后随着Sprint的开始逐渐移动任务Backlog贴纸到不同的阶段并更新燃尽图直到Sprint结束
当然这里任务版也可以通过如Jira等看板工具代替，但是实体的任务板往往更实用
燃尽图
燃尽图主要用来跟踪任务进度，其横坐标为日期，纵坐标为剩余故事点，纵坐标的终点和横坐标的终点的连线就是预期进度，如果曲线比预期进度低那说明进度比较快，可以考虑增加Backlog，反之则说明进度比较慢，需要进行提速
每日站会
每日站会就是每天在同一个地方同一个时间进行少于15分钟的站会，一般都是在每日站会的时候更新任务板以及燃尽图，每个人一边描述昨天已经做过的事情和当天要做的事情，一边移动任务板上对应的便利贴
同时在每日站会上，也可以对于用户故事进行分解成为任务（如果在迭代会议中没有来来得及的话），不过要注意时间不要超过15分钟
在结束了每日站会后，由Scrum Master算出剩余工作的时间估算之和，在sprint燃尽图上画一个点
演示会议
在每次迭代会议结束之后，一定要进行演示会议，将发布的新功能展示给用户看，通过演示会议会迫使团队真正完成一下工作，进行发布，如果没有演示，我们往往会得到一些99%完成的工作，有了演示之后，可能我们完成的事情会变少，但是它们是真正完成的！
sprint演示检查列表
- 明确阐述sprint目标
- 集中精力演示可以实际工作的代码
- 让演示专注于业务层次，不要管技术细节
- 可能的话，让观众尝试一下产品
回顾会议
Scrum中第二重要的会议（最重要的是sprint计划会议）就是回顾会议，这是做改进的最佳时机
一般回顾会议步骤如下：
- Scrum Master向大家展示sprint backlog，在团队的帮助下对sprint做总结，包括重要事件和决策
- 每个人轮流发言，认为什么是好的，什么可以做的更好，什么需要发生改变
- 对预估生产率和实际生产率进行比较，如果差异比较大就需要分析原因
- Scrum Master进行总结并得出下个迭代需要改进的地方
一般会将大家的想法分为三列：
- Good：如果可以重做同一个sprint，哪些做法可以保留
- Could have done bette：如果可以重做同一个sprint，哪些做法需要改进
- Improvement：将来如何改进的具体想法
最后会选择重点要进行的5项过程改进，不要一次改进太多，会得不偿失
Sprint间休整
在Sprint和Sprint之间一定要给出一定的时间去让团队进行休息，一般最佳实践是将上一个迭代的结束日（演示会议与回顾会议）放在周四，而下一个迭代的开始日（sprint计划会议）放在下周一，另外将周五作为“实验日”，在“实验日”中开发人员基本上可以做任何他想做的事情，比如学习最新的工具和API，开发自己喜欢的项目等
参考
- 《走出硝烟的精益敏捷》
