Scrum捷径
——敏捷策略、工具与技巧
Scrum敏捷开发，已成为目前互联网行业最流行的开发方式。至于他有什么好的地方，如果在以前我可能会模模糊糊地懂一些，但是这本书给了我一个更清晰的脉络和经验技巧。
由于本书的结构采用章节加点的方式，所以我们就沿用原书采用部分和点的方式总结各部分的内容。
第一章scrum起步
捷径1、一句话概括scrum
Scrum是一个让我们关注与在最短时间内交付高质量商业价值的敏捷框架。敏捷的概念也是相对于传统的瀑布式阶段性开发来讲，敏捷式开发通过增量方式交付可运行且高质量的功能。
它的优点有减轻风险（可阶段性验收功能），可见、透明和意外状况更少（任务板及定期sprint评审），持续改进，产品列表可控可变化。
捷径2、脆弱的敏捷
Scrum有一个严格的规则和实践框架，要正确实施scrum就要严格遵循实现定义好的规则并在实践框架的指导下开展工作。
Scrum敏捷软件开发宣言
【个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划】
注意点：每个sprint周期需相同，sprint评估需团队共同进行。
捷径3、有创意的舒适
提升团队士气，关注团队和个人赞赏；
注意改善工作环境，确保协作和高效；
帮助团队建立身份认同和使命感（激发激情和参与感：开发人员参与前期用户故事讨论会）。
第二章态度和能力
捷径4、技艺高超的scrummaster
仆人式领导：无私、关爱团队和产品、公平如一对待团队、自信和谦逊、无时无刻不在。
捷径5、摇滚明星或演播室音乐师
态度高于能力，演播室音乐人比摇滚明星更合适团队。
摇滚明星：有魅力、有创意、个人主义较强，与团队无法紧密合作。
演播室音乐人：有创意，多才多艺，与他人紧密合作。
Scrum团队成员应包邮的价值观：开放、勇气、尊重、专注、承诺。应具有的态度特征：活力、共情（可依赖）、好奇（渴望扩展技能）、友善、尊重（尊重他人）。
捷径6、选择团队阵容
理想的团队人数控制在5-9个人大小。
开发人员配比，3个程序员：1个测试人员：0.5个“精深专家”。
解决专家问题，可鼓励开发人员培养T型技能——在某一专业领域拥有很深的造诣，在其他交广领域具备不一定很深的技能。
一个scrummaster可在多个成熟团队一起工作。同样每个团队中需要制定一定的日常规则，并张贴在醒目地方有助于提醒成员如何交流。
第三章规划和保护
捷径7、搭建scrum舞台
1、保全和维护成功的团队；
2、团队有独立的工作区间；
3、项目估算应与实际项目相结合；
4、保证公平的报酬和团队可持续的步伐开展工作；
5、进行指南性的试点项目运行。
捷径8、指定sprint计划并全力贯彻执行
产品负责人和测试专家能够确保足够的细节来确保项目完整性，然后通过团队开会初步细化产品列表；
每个sprint有一个贯穿始终的共同目标；
每个sprint建议时长为2-3周，可根据团队适当调整，一旦确定，便不要随意更改；
每个sprint的容量根据团队不应过度规划，举例一个团队两周sprint的一个全职开发人员的典型容量是9天*6小时/天=54小时（其中一天用户sprint的计划会、评审会和回顾会。）
Sprint计划会实际流程：
1、做什么？产品负责人逐条介绍产品列表中哪些条目的优先级最高并期望能在这个sprint完成。
2、怎么做？开发团队把PBI逐个分解成更细技术任务并针对每个任务估算时间。
任务定义
1、一个任务应该是满足某个PBI中可测试的一个小块，而且要包括满足任务“完成标准”（DOD）所需要的所有活动；
2、每个任务所需时间的开发时长不能长于8个小时；
3、每个任务只能有一个开发人员（或两个开发人员结对）完成，虽然可多个人同时做一个PBI；
4、为sprint评审准备任务，比如准备演示数据等。
捷径9、受累于障碍
障碍：任何阻碍开发人员完成他在sprint容量内所认领任务的事情。
类型：大型会议、病假、不成功的构建、开发工具问题、不可靠的供应商、产品列表未细化、产品负责人缺席或没有权限做重要决定、关注个人激励方案；
五步控制障碍：确认——诊断——去除——告知——学习（sprint回顾）；
障碍：延缓整个团队sprint进展；
阻碍：阻碍某个具体人物但不一定会延缓整个项目进度；
第四章需求的细化
捷径10、结构化故事
用户故事格式：作为一个。。。我想。。。这样我就可以。。。
用户故事切割成具体的任务举例：
“作为一个新的用户，我希望登录到XYZ网站这样我就可以享受它超酷的服务了”
任务1：开发用户名/密码功能（包括测试设计和自动化）；
任务2：开发电子邮件鉴权功能（包括测试设计和自动化）；
任务3：开发登录页功能（包括测试设计和自动化）；
捷径11、制定完成标准（DOD）
没有所谓的通用DOD，DOD适用于多个不同的的层面，任务、用户故事和交付都有其对应的DOD：
任务层面（以编程任务为例）
DOD在任务层面包括如下几条内容：
1、代码经过单元测试
2、代码经过同时检查，确保代码符合编程标准；
3、代码被递交到源码库，而且有清楚的递交说明以保证可追溯；
4、递交的代码没有破坏构建；
5、任务板也被更新，任务剩余时间为0.
用户故事层面
这个特定的故事包含两部分，第一部分指用户故事的需求描述是否足够详细准确，可以确保开发人员在最近一个sprint中着手开发工作（就绪标准）。第二部分是指用户故事是否已经可以用于产品交付（完成标准）。
就绪标准：
1、用户故事已经被估算过；
2、有一组清楚定义的验收标准；
3、用户故事在产品列表中的优先级已经确定；
4、有适当的且适用的扩展文档（有需要的话有模型和框架图）；
5、基于初始估算，这个用户故事可以轻松放入一个sprint。
完成标准
1、所有自动化功能验收测试证实新功能可以如期端到端工作。
2、所有回归测试证实新功能和其他功能的成功集成。
3、所有相关的构建/部署脚本都已经修改并且测试过。
4、最终的运行功能已经由产品负责人全部检查和接收。
5、所有的最终用户文档都已经写好并且被检查过。
6、如果需要，所有翻译和其他本地化工作都已经完成集成和检查。
7、开发团队已通过sprint评审会向所有干系人演示用户故事。
交付层面，完成要素如下：
1、和这个交付相关的所有代码都已经成功部署到产品服务器上；
2、交付通过所有产品级的冒烟测试，采用的是实际产品数据，而不只局限于测试数据；
3、客服和市场团队都已经接受新特性的培训。
4、产品负责人已经检查和接收最终的交付。
限制因素，反映需要符合规定的系统限制因素（非功能性需求），包括（举例）：
1、可伸缩性：规模必须能扩充到同支持20000个用户。
2、可移植性：任何使用的第三方技术都必须是跨平台的；
3、可维护性：所有模块保持清楚的模块化设计；
4、安全性：必须通过具体的安全渗透测试；
5、可扩展性：必须确保数据接入层可以和所有商用关系型数据库相连；
6、互操作性：必须能够实现套件中所有产品数据同步。
捷径12、渐进启示
核查和验证，演示目的是为了和团队再次确认他们承担的工作在交付时与所有人期望的一样。
演示的有效输出：问题、调整、笑着点赞。
实施渐进性sprint内演示，额可通过更频繁的检视，通过更快的反馈回路帮助消除额外的浪费，有助于持续部署和交付。
Sprint内的问题微调可以迁就和包容，但是大的变动旧的放入产品列表，留到下一个sprint处理。
第五章估算
捷径13、关于估算那些事儿
估算可以帮我们做出周全的决定和设定目标。
相对估算，通常用于产品列表层面。估算使用“比较”的原则，比“拆分”原则更快，也更准确。也就是说，团队并不是把需求拆分为一个个任务并估算任务的大小，而是对完成一个新需求所需的想对工作和以前估算过的需求进行比较。
例如估算爬楼，第一个最低设为10点，第二个大约为30点，第三个大约为20点，第四个大约为60点，那么根据第一个的时间估算出其他所有的时间。
软件相对估算
完成所有PBI所需确定的因素：复杂度、重复性和风险。
速率，指讲一个sprint中完成的所有PBI点数累加所得到的。为了得到准确的速率，至少需要5个sprint的数据。
捷径14、规划扑克细则
建议在初始产品列表确定以后安排第一次规划扑克会，只有在一大类PBI突然变大或者变小时，才需要重估。可以开会前几天把参考的PBI发给大家，然后校对自己每个人的标准。
扑克牌的点数为斐波那契数列：1,2,3,5,8,13,20,40,100
扑克游戏机制：
1、在团队要求澄清范围和预期收益之前，产品负责人描述优先级最高的PBI。对PBI描述和接收标准所做的任何修改都要逐步记录下来。
2、一旦可以开始估算，每个团队成员就挑一张自己觉得最接近这个pBl所需工作量的卡片，把印有数字的一面朝下。
3、每个人都选好自己的卡片之后，所有团队成员同时翻牌，亮出自己的卡片。
4、如果大家意见不一致，最高值和最低值的组员就做一个简短的辩论（最多几分钟），其他组员旁听。
5、根据辩论中分享出的新的信息，团队再回到第2步。
6、重复第2到第5步，直到对这个PBI基本达成一致。
7、给这个PBI分配一个值之后，用同样的方法讨论产品列表中下一个PBI，从第一步开始。
注意，ScrumMaster虽然作为主持人全程参与，但并不参与实际估算。要求每个人必须估算整个PBI的工作量，不仅仅是自己相关的那一块。同时还需要估算测试和部署的工作量。大事就用大数值的卡片。
无法达成一致：
1、有没有考虑到所有必须有的功能，而不仅仅是个人的专长？
2、对点数的观点是很坚决还是很温和？如果是后者，有没有可能改变估值？
3、有没有人在两个数值之间摇摆不定，如果有，是否愿意同意大多数人的意见？
规划扑克收益：
1、快速估算长期产品列表，不要求有详细规范和复杂依赖型分析；
2、能通过多样化职能专家提供更广的视野，确保估算不至于有太大或者太小的偏差。
3、能充分利用过去工作中获得的知识。
4、能让团队在传统枯燥任务中增加一些乐趣。
捷径15、转向相对估算
使用历史数据帮助找出已知工作量和斐波那契数列点值之间的对应关系，同时团队队员也比较熟悉和对于故事理解较一致。
如何创建历史数据和新的点数比例之间的对应关系：
1、识别，选择同一个团队最近工作的项目，采用用户故事的形式一条条记录到卡片上；
2、排序和分沓，将卡片上的故事工作量大小按顺序排列；
3、估算大小，将最左边的一沓卡片作为最小的用户故事，最右边的一沓卡片标识最大的用户故事；
4、进一步分类，确定几个参照基准；
5、最后过滤，过滤每沓卡片的代表，用于将来规划扑克会的参考故事。
注：可持续完善自己的参照基准库，每个项目结束后，都加入参照基准库，并逐渐丰富。
第六章质量
捷径16、scrum代码错误
在传统的瀑布式开发环境中，串行处理错误代码的简化流程：
Scrum对于问题的定义，指在sprint中发生的尚不满足标准的用户故事密切相连的问题，并不是PBI。
代码错误，指在用户故事已经完成并被产品负责人接受之后发现的错误，是一种PBI。
Scrum针对代码错误的原则：消除不必要的文档，立刻解决问题，不要半途而废。
解决代码错误的一些方法：
1、当前用户故事为开发目前优先级最高的任务，发现问题应立即解决。
2、开发正忙于其他问题时，测试记录问题并等开发空闲时及时提出。
3、发现几个不易察觉的问题，可以设置一个PBI作为小问题容器。
4、严重问题，可以建一个专门PBI，有产品负责人排优先级在下一个sprint中处理。
捷径17、我们仍然青睐测试人员
测试人员使用与开发互斥的解决问题的思维模式，即通过怀疑软件与开发的乐观态度相制衡。
在scrum中测试人员作为咨询师，设计师和探索者进行技能扩展。优秀的探索性测试人员特征：
1、是系统性的，会追寻利用异常情况及不一致片段。
2、会用识别问题的原则和机制来识别问题。
3、选择一个主题、角色或使命来确定测试焦点。
4、能控制好探索时间。
5、考虑专家或新手的不同做法。
6、和这一领域的专家一起探索。
7、参考相似应用或竞争对手应用。
捷径18、自动化王国
几个紧密交织的关键性自动化实践，包括持续集成（Continuous Integration）、测试自动化、构建/部署自动化以及相对较新的持续交付（Continuous Delivery）等概念。
CI：把工作频繁集成在一起，通常每天一次，每次集成用自动构建来验证，确保集成错误能被尽早检测出来。小洞不补，大洞吃苦。
测试自动化，可以将人解放出来做擅长的事，提供安全网，提供尽早和频繁的反馈，驱动编程的测试和实例也可以用很多用处和收益。分为单元测试，功能测试，集成测试和性能测试。
（单元测试，是最低层面的、独立的编程模块，通过测试驱动（TDD）开发来实现。
功能测试，即接收测试或用户故事测试，利用自动化测试某个用户故事整个端到端的功能。
集成测试，即系统测试，确保新功能在生态系统中正常工作的测试。
性能测试，即负载测试或压力测试，关于测量产品在压力下的表现，典型的是增加用户和提高处理数据量。）
第七章监控和指标
捷径19、有意义的指标
指标的种类：
善意指标——作为团队识别进展的信号，帮助团队检查和调整流程并不断提高；
恶意指标——用于微观管理个人业绩的僵化指标，用于打击人和抹杀士气。
有意义的指标：Sprint燃尽图、增强型交付燃尽图、sprint干扰、补救关注点。
Sprint燃尽图
生成方法（sprint每天结束时生成）：
1、sprint每一天将当天所有sprint列表任务的剩余时间之和标为一个点；
2、将每天的点和前一天的连起来。
Sprint燃尽图指标是scrum团队用来管理工作流和跟踪进度的日常标尺。
如果图形趋势落后于计划，可能有以下几点：
1、sprint列表加入了新的任务；
2、有些任务估算不正确；
3、团队成员安排了计划的休假；
4、有障碍影响了进度。
增强型交付燃尽图
生成方法（指标在每个sprint结束时生成）：
1、在每个sprint，标出下个交付的产品列表的所有条目（PBI）剩余点数之和。
2、根据第一步的数据点信息，画出趋势直线。
3、在每个sprint，标出项目开始之后新加到产品列表中的PBI点数之和（用Y轴的负值来表示）。
4、根据第三步的数据点信息，画出趋势直线。
说明点：两条线的交汇点大致表示出需要多少个sprint来完成交付。如果不相交，则需要提高进展或削减内容范围。
Sprint干扰
生成方法（每个sprint计划会上生成）：
1、每个sprint，标出任何一个团队开发人员花在任何非sprint列表任务上的时间总和；
2、基于第一步的数据点，画出一条趋势线。
说明点：统计以往花在sprint计划外任务的时间数据，帮助估计下个sprint潜在容量。
补救关注点
生成方法（每个sprint结束时生成）：
1、每个sprint，标出总速率（所有PBI的点数，包括新功能和修复代码错误）。
2、每个sprint，标出修复代码错误工作的点数。
3、基于第2步的数据点，画出一条趋势线，表明质量在改进，团队在总速率不变的情况下，花在错误修复上的时间在减少。
说明：通过测量每个sprint修复错误上所花工作量相比开发新功能需求工作量所占的比例来监视产品质量的波动。
捷径20、出色的站会
站会，是通过站立的形式进行团队每日会议，可提高团队活力感和简短高效。
会议内容：
1、我昨天有哪些进展？
2、我希望今天获取那些进展？
3、是否有任何障碍阻碍我的进展吗？
注意点：不要迟到，紧密圆圈型。
GIFTS：
Good Start（好的开始）——活力和紧迫感；
Improvement（改善）——暴露可以帮助我们改善的问题；
Focus（专注）——鼓励专注完成目标；
Team（团队）——不断沟通和帮助；
Status（状态）——工作进展和有趣的事情。
建议：多个团队协作、忽略Scrummaster、额外接触点（破坏者惩罚）。
捷径21、优化任务版
数字任务板和实体任务板共同使用。
任务板举例：
列可以用未开始、进行中、可验证和完成。每行代表sprint。任务计划外的内容也可用不同颜色便利贴记录在任务板上，然后生成燃尽图。
特别标注点：sprint目标、回顾会议的目标、定义和原则；大致的模型和客户评价。
第八章回顾会、审核会和风险
捷径22、sprint审核会的任务事项
会前准备：
基本演示数据、演示流程脚本、确保演示环境工作正常。
建议：跑题的问题会后有产品负责人和相关干系人单独召集进行讨论；将建议记录在白板上。
捷径23、不可或缺的回顾
回顾会准备工作以下领域需要关注：交流、流程、开发范围、质量、环境、技能。
交流改进：
1、修复产品负责人和开发团队之间脱节的交流。
2、避免开发团队和外部干系人之间不必要且负面的交流。
3、解决团队内的沟通问题，特别是由于过于依赖文档而非面对面的讨论所引起的问题。
流程改进：
1、升级软件、硬件和网络连接。
2、确认大家已经透彻理解和清除定义了scrum流程。
3、维护代码质量、源代码管理及部署流程相关的工作标准。
开发范围改进：
1、确保在sprint期间开发范围不会有大的变化。
2、保持所有用户故事和接收标准格式的一致性。
3、确保sprint计划会的范围不被错误定义的或者不过于含糊。
质量改进：
1、清楚定义和维护一致的完成标准。
2、不断改进测试时间以实现更成熟的测试自动化。
3、确保程序员对被测代码有主人翁感，而不是把它仍给测试人员或产品负责人。
环境改进：
1、保持协作工作环境不过于吵闹和不容易受干扰。
2、提供足够的空调和暖气，确保必要的舒适性。
3、保证有足够多的白板空间和其他促进合作的工具。
技能改进;
1、当需要新技术时，可以提供足够的培训。
2、为新团队成员提供入职培训。
3、需要时提供相关的专家咨询。
回顾会议形式：采用画圈法和冒泡法
捷径24、勇担风险，勇于犯错
大胆变革，大胆犯错——Facebook经常要求开发人员第一周就把代码部署到现场，可以给新手一种暗示：不可能马上就达到完美的境界，错误可能发生，但这没有什么大不了的。
第九章经理怎么管理
一个简单的一页总结产品概述，确保发起人能够自始至终将足够多的信息作为产品概况的输入。
首席ScrumMaster的核心职能：培训和辅导、挑战现有的行为、提供和维护工具、定义指标和善用指标、帮助建立实践社区、确保一致性、团队之间的协调。
首席ScrumMaster的附加职能：坚持推广scrum、发展scrum实施方式、公司范围内的教育、协调多个团队之间的完成定义、通过集体回顾会议来保证持续流程改进、上报阻碍。
ScrumMaster的核心职责：流程改进、管理障碍、外交、教导、管理变革、维护DOD、保持有效的沟通、更新文件、主持研讨会、主持scrum活动。
第十章更大的经验教训
Scrum方法教我们的不仅仅是软件开发的管理，通过透明、检查和适应找到合适的道路把团队和组织提升到更高的层次，它还教给我们学会自我审视，选择有自己特色的大胆尝试，积极响应变化不固步自封，和享受超出预期的美好。
