十四、Sprint
增量开发主要是一块接着一块地构建一个系统
迭代开发是指逐渐完善地构建一个系统
每个Sprint应递交可工作的软件
敏捷方法强调可工作的软件，是因为下面三个主要原因：、
可工作软件鼓励反馈——能够看到或触摸到产品不仅能使用户给出更好的反馈，而且他们还更有可能答应当场就提供反馈的要求
可工作软件帮助团队衡量他们的进度——完成一部分工作，会使剩余的工作量明晰起来
可工作软件允许产品在需要时尽早发布——满足或接近发布，是Sprint的特点
1、“潜在可交付”的含义
不仅符合用户故事的满足条件，还要符合项目具体的完成定义（编码、测试、代码检入、格式良好、可集成和具备自动化测试）
2、识别“潜在可交付”的指导方针
1）潜在可交付意味着测试过
集成测试、性能测试、可用性测试等
2）潜在可交付并不意味着系统功能的完整
代码结构良好，彻底被测试过，PO和团队同意后，产品就可以带着它发布而不需要考虑完整功能特性的缺失
3）潜在可交付意味着集成已做好
在多个团队的项目中，团队必须在“已完成”的定义标准中包含集成开发代码流
每个Sprint提交一些有价值的东西
在很早就产生某些东西可以让用户实际看到，以便知道我们距离目标有多近
不是所有的产品都包含对终端用户可见的功能
提交有价值的东西，可以尽早获得反馈和确保团队不会误解项目进度
在当前Sprint为下个Sprint做准备
1、台球短跑
台球短跑指的是团队刚完成一个Sprint，还没准备开始下一个，下个Sprint又开始启动，毫无准备
在任何一个Sprint中应有10%的团队可用时间用于准备下一个Sprint
2、只在一个Sprint中塞入能完成的东西
如果某个用户故事或产品Backlog中的其他事项明显无法在一个Sprint内完成，那么不应该将其放入Sprint
产品Backlog中的事项被放入一个Sprint后，需要了解的细节数量就是必需的最低数量，这些细节数量可以使该事项放入该Sprint中，从产品Backlog变成可运行和测试过的功能特性
每个Sprint始终保持协作
Scrum项目的特点就是跨职能团队一起工作，而不是将工作从一个组交接给另一个组
1、避免特定活动的Sprint
特定活动的Sprint拥有同样特定活动的团队的缺点：太多的交接工作和缺少作为整个团队的责任心
1）进度风险增加
2）花太长时间完成从想法到可运行、测试过的功能特性
3）这并没有真正解决交迭工作的问题
2、用完成-完成的关系取代完成-开始的关系
用户需求的讨论和编码实现可以交迭，编码和测试活动也可以交迭
3、用户体验设计的交迭
UED是一项前端活动，通常从评估当前工作实践和用户需求开始，以用户界面设计的创建结束
在Sprint中，团队有两个目标：完成在当前Sprint计划的工作以及准备下一个Sprint
4、全盘思考，增量工作
在一个有重大UED的应用中，PO需要在对Backlog区分优先级的同时，解决那些未处理的UED问题
PO和UED整体考虑系统，确定他们在哪些地方最需要获得新的知识，这些地方成为下个Sprint UED工作的重点
这样做的好处是——不会浪费时间、同时完成可用性测试、设计人员会得到及时的反馈
熟练和富有经验的设计人员总是在做全盘考量但迭代实现的解决方案
5、系统架构和数据库设计
保持时间箱定期性和严格性
固定Sprint长度的好处：
1）团队受益于定期的节奏
2）Sprint计划变得容易
3）发布计划变得容易
4）这正是理查德费曼做的——在每个Sprint开始时选择该Sprint的长度是一种精力的浪费，先试验两个长度，决定后坚持
周五开始Sprint，可以做Sprint的评审、回顾和计划，放在周一会导致我们比平时更恐惧周一
1、绝不要延长Sprint
Sprint要按时结束，不要在到达计划的结束日期时，还在决定你还要多增加几天来完成工作
如果团队决定延长一个Sprint，那么他们学到的是错过截止日期是可以的
严格保持Sprint时间箱能强化持续推动项目前进的想法
严格执行Sprint的截止日期意味着团队偶尔也需要在Sprint中丢下一些已计划完成的工作
只要有任何迹象说明不是所有计划工作都能完成，PO就要与团队其他人碰头讨论如何做
不要改变目标
只要是初期，使用Scrum应对Sprint变化的强硬路线，即不许改变任何任务
Scrum不允许变化进入Sprint而乐于异常终止并启动一个新Sprint，这种方法提高了变化在成本和频率方面的可见性，只有最重要的变化才能证明异常终止是正当的
真正的焦点是确保我们总是在做最重要的工作
1、放弃改变团队目标的习惯
1）稍后再缓和强硬立场
必须让团队外面的人认识到改变团队目标带来的成本
客户真正需要的是可预测性，大部分不紧急的缺陷不用立即修复
获得反馈，学习和适应
每个Sprint可看作是一种最有价值的、潜在可交付的、集体受益的试验
迭代和增量开发指的是产生反馈，从中学习，之后调整我们正在构建的东西和我们的构建方式，Sprint为团队提供了相应的机制
