完成和撤消
Scrum.org是Ken Schwaber 和 David Starr 编写。
2012 年 1 月
交付一个完成的递增是至关重要对成功的使用敏捷软件开发。 通过使用具体示例和理论示例，作者演示了“已完成”感知和实际“已完成”之前的差异，并演示了它如何影响醒目的成功。 使用这些示例，作者继续演示了工具和策略，这些工具和策略可以帮助团队开始定义对他们有意义的已完成的操作，还继续演示了帮助团队传达依赖项、状态和“已完成”的意义的方法。
应用于
应用程序生命周期管理；Team Foundation Server
本文内容中：
介绍
“ Anna 的公司的透明度丢失”
出现哪些人为的想法
实际进行的操作
课程
Nanomedtronics AZ 的技术债务
出现哪些人为的想法
实际进行的操作
课程
技术债务与多个团队进行放大操作
在 A Datum Corporation 发布计划
出现哪些人为的想法
实际进行的操作
课程
获取完成的大型缩放技术
Scrums 的 Scrum
持续集成
结束语
scrum 是一个迭代、增量敏捷的框架。 团队使用它可以快速提供增量“执行”，或可能可用的软件函数每次迭代或 Sprint。
“完成”是一个简单不过通常会误译的单词。 对我而言，这意味着结束和已完成。 执行意味着没有可执行的。 定义执行是简单的；但是，提供已完成的增量保留 Scrum 和灵活性的基础知识和更逃避的要求之一。
灵活性需要完成传输，可用软件每个冲刺 (sprint) 的现成的增量。还有大多数 Scrum 和敏捷团队生成部分完成，未完成递增。在 Scrum 团队询问产品积压工作要求在冲刺 (sprint) 中不完全完成的原因时，团队成员通常答复“我们没有时间。”
从 Scrum 初期起，此文档解决与通过真实的案例研究的示例完成增量相关的问题。涉及已更改的名称和位置，但我确定个体将识别自身及其繁琐的工作。在本文中，除非另有规定，否则所有冲刺 (sprint) 均每月进行一次迭代。
“ Anna 的公司的透明度丢失”
安娜需要自动设置属性标题更改的她的部门的收货。 她为在大多数的生成的和要管理的气体管道工作北美中的公司。 她的部门进行了处理，并向它通过的土地的所有者支付了权利金。 接收的标题信息安娜的部门是打印输出或属性更改页面。 音量变得过大，因此，安娜想要自动化换行符和特权付款进程。
我们的开发团队建议我们使用 Scrum 为 Anna 生成特权系统。 这确保每个月对可用的软件片段进行检查。 她还具有每月以改变主意有关我们的团队接下来会执行。
在第三个冲刺之前，我们具有来自省之一的源并与旧的数据集成。 我们使用简单的 SQL 解决方案来说明。 因为大多数她的人员的产品积压工作是来自此省份，安娜高兴。
她希望我们了解她的人员 SQL，所以它们可立即开始使用开发团队提供的软件。
她意味着她想使用？ 确保她未解释已完成与 Sprint 已完成的软件！
我们告诉安娜这种情况尽可能小心。 她是铅色的。“尚未完成是什么意思？ 我已经了解了第一个增量和第二个增量，现在，我要开始使用它。 部署并了解我们 SQL，因此我们可以使用它。”
我们开始感到不安。 我们告诉安娜是，它已完成。 但是，它不是进行的该类型。 这样做是为了显示给她，但是在软件可以使用之前问题始终需要解决方法：
数组传入的记录未能处理。 我们需要功能来存储和管理他们，而不是丢弃。
除了文档外，将传入记录的字段显示用于使用。 与他们我们应该采取什么？
现有数据库中的字段包含指针或类似参考信息的信息。 这遍及数据库。
在我们正在运行传入源和查询数据库时，该系统已崩溃了多次。 在这些系统崩溃期间它类似于损坏数据。
安娜询问我们在我们会使其自己的类型执行之前需要它应该是多长，可用的执行。 我们估计另外两个冲刺 (sprint) 需要使用递增可用。 她告诉我们延续和获取已准备好地她的部门的使用。 她随后“需要” 第二天早晨碰到她。
第二天早晨，安娜（她的老板）和开发部主管都在此处。 他们对我未显示吹捧的透明度感到失望。 他们认为我应该处理这些未解决的问题，而不是指示将其作为 Bug 记录。 因为向每个人提供的燃尽报表反映出的进度不正确，所以它们受到打扰。
在会议后，我们的前进顺序是：
进行调查并更正四个 bug。
完成和部署前三个增量，使得 Anna 的部门可以开始使用它。
改进我们的工程技术并自动测试，因此我们已完成的定义与 Anna 的定义相同（通过业务立即可用）。
更改我们记录缺陷的方法，使得该要求将不被视为完成，除非它们是固定的。
我们被告知这个将是一个好的学习机会，因此我们全部学习了我们的课程。
出现哪些人为的想法
当我们开发系统的基线计划时，它表示利益干系人和 Anna 将发生。 开发团队报告了查找的进度，就像该发布已步入正轨，并且人们信任该报表。
开发团队实际认为通过显示工作如计划中描述的那样继续进行，他们正在执行正确操作。
实际进行的操作
速度是一个“开发团队”每次“冲刺”时的效率的测量和历史记录。 速度用来测量每个“冲刺”，并用与建立效率模式。
我们的开发团队需要将每个冲刺 (sprint) 保持在 8 个已完成工时单位的持续速度以满足计划。 在其他威胁降低我们的速度低于 8 时，我们尚未完成这些项中的所有工作。
我们发送效果不错的功能，但是不够完整使用或基于。 我们打算稍后改进。 在我们返回未做完的评估时，它添加另一个工作的 14 个单位。
无论初始标题源有多困难，我们将整个计划重做了一遍，反映大概 20 个月的安排。 安娜的部门每两月左右发布递增，启用新的源。 当系统启动后上线二十二个月时，新的自动换行符大大减少了整个手动工作。
课程
真正的透明度要求查看“递增”的每个人必须看到和理解到相同的事情。 “递增”的透明式检查本应允许 Anna 管理风险并获得可预见性。 但是，因为递增不透明，她不能进行有效规划。
在项目开始时，安娜建立发布目标。 在冲刺 (sprint) 1后，通过检查哪些她认为是可用的递增估计进度目标。 她做出了有关如何的决定在冲刺 Sprint 2 中执行基于增量进度目标。 如果她认为我们的进度不够，则可能已经取消该项目了。
在冲刺 3 结束时，安娜认为总值的 3/10 执行，这显然不正确。
遗憾的是，我们仅为了演示才对每个“递增”做了足够的事。 未完成工作使递增可用于安娜的部门和不透明的检查。
检查递增时的不透明就像用一块湿的冷洗碗布盖在温箱上。 在应冷却时，调温器没有正确认识实际室温，并没有正确启动供暖系统。
没有透明递增，利益干系人没有正确的了解实际发生了什么，并可能错误地采用没有意义的操作。
简而言之，无需完全透明，团队的能力可以有效的检查和调整丢失。
Nanomedtronics AZ 的技术债务
在软件视为已完成之前，技术债务是必须完成的延迟工作。 技术债务采用多种形式例如弱模式、代码复制和未经测试的功能。 以下示例演示技术债务的原因和影响，就像项目过程中未完成工作。
Nanomedtronics AZ 是一家小型软件创业公司。 他们有一个在性命攸关的产品的新版本上工作的 Scrum 团队；纳米机器人使用的软件可以清除遭受高血压的患者的动脉阻塞。
出现哪些人为的想法
当团队启动时，它们分配了带有选定产品积压工作项转换为一个月的冲刺 (sprint) 中完成的（没有更多的工作保留、可用、可能交付）内容。开发团队具有将要求完全开发到已完成递增的所有技能。
在 Scrum 团队已启动第一个冲刺时，它们看到在 10 个月必须完成的工作的 80 个单位。 因此，开发团队尽职地选择了每个冲刺 (sprint) 的 8 个工作单位。 他们推断，如果每个冲刺 (sprint) 仅拉取 8 个单位，则公司应该规定在 10 个月内完成。
开发团队在每个冲击末尾的显示了可用递增。 由所有向外外观，运行 Scrum，并 Nanomedtronics AZ 按计划按部就班发送其产品。
实际进行的操作
将在开发团队之外无法确定所提供的每个增量实际上包括一些不良的实现、非关键的 bug、重复的逻辑和通常杂乱的代码。 此外，增量未完全测试，因为开发团队在冲刺 (sprint) 中因急需时间而停止测试。 开发团队承诺满足该计划，并且剪切质量通常一直停留在进程上。
团队工作繁琐，并超过 10 个月都在生成其产品。 该客户是高兴和准备实现和使用该软件。 但是，开发团队累积的未完成工作已达 48 个单位，如下图所示，已成为新技术债务。
.png "已完成工作和未完成工作")
在 Nanomedtronics AZ 的团队不考虑所有活动，并且完成工作确实需要已完成的实现。 以下包括团队无法考虑的内容，并未涵盖所有信息。 具有可能包括的更多内容。
分析
设计
依赖项分析
性能测试
稳定性测试
重构
免疫响应测试
集成使用任何其他团队的工作来处理产品
集成测试任何其他团队的工作，因此递增所有团队的全部基值
发行说明
售出产品的六个区域性的国际化
用户验收测试
回归测试
代码检查
必须完成上述操作来创建完全，集成，增量在 Sprint 之前。 但是，大多数开发团队未全部完成上述工作。 每个冲刺 (sprint) 他们都会留下某些“撤销”工作。 这将某些不良设计、重复代码、过于复杂的逻辑、未经测试的功能或其他不完整的形式创建增量， 这是团队使用软件创建技术债务的方法。
Nanomedtronics AZ 了解到其产品包括将其交付给客户所需的所有功能，还包括许多缺陷并且缺乏将该产品推向市场所需的包装和修整工作。 开发团队不慎创建了需要另外 6 个月才能完成的其他工作的积压工作，假定已不正确的速度为每个冲刺 8 个单位。
等待 6 个月可以提供产品给公司领导者不可接受，并且该产品附带有未完成的工作，仅剩余 3 个月后。 潜在的丢失不仅仅是在发布该产品时延迟 3 个月，还是放缓添加新功能的能力，就像开发团队现在必须在将来的冲刺中与技术债务争斗。
课程
技术债务遮盖 true 进度和复盖对于体验主义的决定所需的透明度是由产品所有者和利益干系人。 技术债务将支付，用于在设计时花费的更正方法。丢失问题，或者由于后传递或以及质量差。
在大多数情况下，在释放他们时至少未完成工作的 50% 剩余在产品中因此，未完成工作变得制度化为持续的责任。 技术债务快速会导致产品脆弱和可能最终强制与投资在复盖软件或放弃产品的负业务决定。
技术债务与多个团队进行放大操作
开发团队只有必须在冲刺 (sprint) 中仔细选择其能做多少工作。 开发团队根据经验了解工作量。 但是，团队必须使用与自动生成和回归测试的现代工程实践进行任何操作。 如果这些未使用，则手动工作的第四或第五个冲刺可能会使团队不知所措。
考虑三个程序员和两个 QA 专家的开发组。 每天程序员检查代码到源代码系统。 它正被测试和检测 bug 并提供正确的程序员。 时间发生在检查检测和报告的代码和缺点之间。 与此同时，其他程序员可能会签入错误的代码顶部的代码。 修复初始问题所需的工作量现在更大。 如果开发团队具有连续生成和测试的工具，则该将该错误已被立即检测出来。人们可以对其进行调查、修复，然后继续。 这样可以避免额外工作和浪费。
许多组织使用多个 scrum 团队以生成软件。 在发生这种情况时，在部分中描述上面的技术债务问题变成极大地放大。 签入错误的代码顶部的机会明显变更大。 修复软件的增长脆弱性的成本在工作增进时呈指数增长。
在 A Datum Corporation 发布计划
我最近与另一家公司合作，我称其为 A Datum Corporation（A 数据公司），一家基础架构软件公司。 主要产品线雇用超过 800 位开发人员，包括 250 个程序员。开发基础结构部分已自动和手动部分。 测试通常将代码延迟几天。 缺陷代码中程序员检查和检测到和已报告之间的时间通常为 10 天或更多。
若要最小化许多程序员的复杂性，每个开发团队在自己代码分支工作。 开发管理人员帮助组织产品积压工作以减少依赖项。如果每个开发团队每天将其代码合并到主代码行，则潜在的返工量会降到最低。
但是，管理层认为这样花费的时间太多。 管理层决定每三个冲刺 (sprint) 都会将所有代码分支合并到根。 集成测试将发现任何缺陷，然后将其修复。候选发布在每个第三个月月底之前就绪。
出现哪些人为的想法
下图显示计划的发布计划和循环。
.png "计划的发布计划和周期")
假定的原始计划：
9 冲刺 (sprint)
3 个候选发布然后是完整发布
800 人员开发组织
实际进行的操作
当此组织到达发布日期时，在九月后冲刺 (sprint)，产品未准备好发布。 第六个候选发布版本有超过 5,000 个缺陷和要求完成的 2,000 产品积压工作。 我们希望如何这个是。 我们看到候选发布每个第三个月。 在我们调查时，我们发现已经从每个开发团队的代码分支中演示。 尚未发生任何集成。 尚未发生任何集成测试。
若要维护对于发布日期所需的速度，开发团队延迟所有集成工作，从而创建大量技术债务。 结果是来自计划的发布日期的八个月名单。 单词“候选发布版本”没有意义。
下图显示实际项目以及对于稳定性必须的时间。
.png "实际项目和稳定所需的时间")
候选发布版本具有从每个团队代码分支的部分工作功能。 发布前，需要五个月的“稳定”期。 比起其他更延迟交付的一个极为麻烦的缺陷是“性能低”。此问题记录在第一个冲刺 (Sprint) 中。
课程
处理相同软件的不同团队最终将合并其工作。 集成软件以确保有效减少集成的风险和频繁出现。
正在等待合并多个团队的工作吸引为允许延迟合并的成本。 但是，延迟的最终开销由涉及团队的人数和必须是集成的分支数量阐述。
获取完成的大型缩放技术
通过多个团队来达到“完成”状态比较困难。 涉及的许多复杂。 依赖项在团队和代码分支之间存在。 虽然花费了缩放的这种复杂，当同步的团队在节奏一起发送时，就可以达成并提供极大的值。
在多个团队一起工作时，我找到有用的某些技术。
Scrums 的 Scrum
在许多 Scrum 团队正在从事同一项目时，它们需要技术来协调它们的工作。 我推荐“Scrum 的 Scrum”，这是日常事件，在各团队的日常 Scrum 后立即进行。 有人技术从每个团队提供。 每个团队委托描述了其团队工作。 其后，他或她描述下一天的工作计划。 根据此信息，委托尝试确定所有必需的返工，任何即将到来的依赖关系以及可能需要重新计划的任何工作。
Scrums 的 Scrum 对很多组织都很有用。 但这，这样远远不够。 因为问题所需而不是已知，依赖项和重做也可能不会成功地标识。 意料之外的依赖项导致返工和失败的测试。 某些团队花费工作和修改依赖项的 50% 个以上每个 Sprint。
持续集成
Extreme Programming (XP) 需要持续集成和对团队的工作进行集成测试。 为何不扩展此以所有的团队？ 是否有两个团队或五十个团队，要求团队生成一个集成，集成测试的增量在每个冲刺 (sprint) 的末尾。 为此，团队必须经常对其工作进行集成。 因为任何未集成的工作可能包含未解析的依赖项，因此持续集成是最好的解决方案。
所有工作的持续集成类似于学习生产技术。 在学习生产线中，许多方法使用于评估产品的质量在整个生产进程中。 当偏差或质量发生问题时，暂停生产线。 持续集成和集成测试提供软件产品开发的相同技术。
由于难度较大，我建议各团队和团队成员在连续生成失败或测试失败的情况下停止编码。 所有延续任务的工作可能会生成在错误的顶部，导致错误的波纹效果。 如果使用了持续集成，则团队在一起紧密工作避免集成失败。 提高其工作习性，减少浪费并递增质量。
采用 scrum 的大多数组织并不会以所有工程技术和生成已完成递增的工具开始。必须启动和继续处理实现完成递增的严格程序。 小于五十人的团队可以快速达到在冲刺 (sprint) 过程中完成增量的状态。 拥有超过 500 个开发人员的组织通常需要几年才能到达那个点。
取消“递增”造成了浪费并阻止了团队达到真正的灵活性。 未完成工作的实际成本远远多于递增中缺乏的特性或功能。 成本包括必要重新计划和的返工浪费，在增量正确未完成时，以及花费较低的可预见性和更高的风险。
许多组织想要从灵活性中获益，并使用 scrum 获得这些益处。 交付一个完成的递增是至关重要对成功的使用敏捷软件开发。 团队应从它们的意义的定义开始执行，在特意然后展开该定义。 只有这时它们才可以实现真正的灵活性。