PDF打破大型版本发布的习惯
敏捷开发能让你的团队更高效吗？
DAMON POOLE，ACCUREV
跟上快速变化的步伐可能是一项艰巨的任务。 正当你终于让你的软件与新技术协同工作以满足昨天的需求时，更新的技术又被引入，或者新的商业趋势出现来打乱局面。 无论你的新挑战是 Web 服务、SOA（面向服务的架构）、ESB（企业服务总线）、AJAX、Linux、《萨班斯-奥克斯利法案》、分布式开发、外包还是竞争压力，都越来越需要开发方法来缩短开发周期时间、更快地响应用户需求并同时提高质量。
一种应对这一挑战的新兴方法是称为敏捷软件开发的方法论，其共同主题是将传统的开发过程（最终只有一个可交付成果）分解为一系列小的迭代，每个迭代都是完整过程的缩影，并且每个迭代都产生可工作的软件。
采用敏捷方法论会带来自身的一系列挑战。 它主要由早期采用者和小型本地化团队使用，工具支持很少，而且尽管可以分阶段采用，但要获得敏捷开发的全部好处，需要对项目生命周期的所有阶段进行全面更改。 此外，敏捷实际上是一个庞大且不断增长的方法论家族，包括极限编程、Scrum、精益软件开发、Crystal 方法论、特征驱动开发以及许多其他方法。 虽然有广泛的选择是好事，但这确实使采用过程复杂化。 敏捷还挑战了许多关于软件开发生命周期的基本和长期存在的传统观念。 这使得难以达到启动敏捷项目所需的临界规模。
敏捷的关键：短迭代
人们普遍认为，敏捷开发的好处是更快地产生价值、成熟度和反馈；允许早期反馈为需求提供信息，从而生产出更好的产品；并提高业务灵活性。 我认为这些好处都源于一个单一的敏捷开发实践，即短迭代，而所有其他实践都是促成因素。 因此，我将重点关注短迭代。
发布之间的时间间隔因组织和项目而异，但根据 Forrester Research 报告“软件配置管理范围的扩大”（2005 年 7 月），大多数迭代仍然在三个月或更长时间的范围内。 无论你的开发过程如何，都很可能可以从敏捷开发中受益。 在许多方面，你现在所做的事情无疑与敏捷实践的短迭代重叠，无论你是否意识到这一点。 如果你每年进行一到两次大型版本发布，你可能不会认为自己正在进行短迭代。 但是请稍等，你在发布周期接近尾声时生成的所有那些候选版本呢？ 当然，你可能只在外部发布了其中几个，即使如此，它们也是 beta 版，而不是“真正的”版本。 那么你在大型版本发布后所做的三个计划外的后续版本呢？ 补丁呢？ 针对特定客户的定制版本？ QA 构建？ 演示构建？
如果你的客户是内部客户，你可能会每周甚至每天发布一到两次。 然而，在你开始声称自己是敏捷之前，请意识到频繁发布本身并不等同于敏捷开发。
你可能会将所有那些计划外的和多个候选版本视为例外情况，或者视为阻碍生产高质量软件的障碍。 然而，另一种看待它的方式是，变化是生活中不可避免的事实，最好拥抱变化，而不是试图减少变化。 这正是敏捷的全部意义所在，它包括一些工具，可以将感觉像是高速失控、处处充满危险的局面转变为定期安排的从海岸到海岸的喷气式飞机航班。
通过使用短迭代，你能够更快地获得客户反馈。 如果你不一次性发布一个主要新功能，而是将其分解为逻辑块（假设可以为特定功能做到这一点），你可以更快地找出哪些块正在将该功能引向正确的方向，哪些没有，并根据需要调整你的计划。
假设一个新功能的完美实现有 12 个子组件。 当然，你无法预先知道什么是完美的实现。 使用传统方法，你会在一年内实现第一个版本，其中包含 12 个子组件。 结果发现，其中六个正是需要的，而六个完全错误（即使那是要求的）。 因此，一年后，你发布了第二个版本，现在你已经得到了 12 个组件中的 9 个是正确的……依此类推。
使用短迭代，你可以每月发布一个组件，每月获得一次反馈，而不是每年一次。 使用这种更紧密的反馈循环，从逻辑上讲，你应该比在年度计划中更快地收敛到正确的解决方案。
频繁发布和质量
频繁发布的想法往往与低质量联系在一起。 很容易理解这种推理思路，但这是一种对敏捷开发的误解。
如果你采用非敏捷流程，只是简单地提高发布频率，你肯定会在质量上受到打击。 此外，如果你的测试阶段对于一个版本来说是三个月，那么将它缩短到一周以便你可以每月发布的想法是非常可怕的。 但这两种情况都不是实际发生的。 没有人会采用现有的流程，然后简单地开始每月发布，并且三个月的测试不会缩减到仅仅一周的测试。
如果你每年发布一个版本，并改为每月发布计划，那么真正发生的是你将单个版本中涉及的许多任务重新分配到 12 个较小的版本中。 每个任务——编写规范、进行设计、编写代码、编写自动化测试等——对于特定的更改仍然需要相同的时间量。 不同之处在于，这些任务现在发生在为期一个月的时间内，而不是发生在为期一年的期间的某个时候。 例外情况是需要超过一个月才能完成的更改。 在这种情况下，你有三个选择：暂时使用足够大的迭代来适应更改，找到一种方法将任务分解为更小的块，使其适合一个月的迭代，或者单独进行更改，并在发生更改时将其添加到正在进行的任何迭代中。
有些任务，例如执行完整的系统构建或打包软件以进行发布，与版本中的更改量无关。 最大的挑战是减少固定开销，其中通常包括测试，以便更改与开销的比率保持在可接受的高水平。
关键路径分析
要进行短迭代，所有事情都需要调整以适应更短的周期时间。 迭代实际上只是发布之间的时间。 这实际上比听起来容易。 关键是确定从小开发任务（例如，次要错误修复）从启动到最终产品的关键路径时间，然后确定所涉及的时间量。 你可能会对结果感到惊讶。
让我们考虑一个略有不同的练习。 在代码的高影响区域中，客户停机热修复的关键路径时间是多少？ 你的公司可能对此情况有特殊的流程，一旦问题达到此状态，无疑会获得最高优先级和所需的所有资源。 因此，除了与生成热修复所需的子任务直接相关的时间外，关键路径上不会有对其他问题的依赖，也不会等待某人从休假回来，或者任何其他延迟。 由于这涉及到代码的高影响区域，因此它应该获得你的组织必须提供的最高级别的审查：多次代码审查、回归测试、手动测试、添加新测试、压力测试等。
这种类型的热修复通常需要四到八个小时，最坏的情况是 24 小时。 由于时间对于此问题至关重要，因此测试仅限于为常规版本完成的测试的子集。 例如，首先仅完成特定于平台的测试或数据完整性测试； 然后在交付后完成全套测试，这可能需要另一天。 如果大多数组织真的必须这样做，他们可以在两天或更短的时间内完成包含少量更改的高质量版本。
刚刚描述的关键路径练习表明，与单个小更改相关的实际开销最多为两天。 由于大多数开销要么与完全自动化测试有关，要么与逐步完成手动测试计划有关，并且只需要运行一次，为什么这么多组织认为与将产品交付出去相关的开销要大得多——有时对于一年的发布周期来说高达三个月？
这可以归结为两个简单的答案：打破长迭代的习惯很困难，而长迭代隐藏了根本问题。 更糟糕的是，这两个问题往往会相互加强。 隐藏的问题有助于保持周期时间长，而长周期时间有助于保持问题隐藏。
由于每个人都“知道”对软件的主要版本进行发布质量认证需要很长时间，因此你当然希望尽可能多地添加内容。 这种愿望必须与以下事实相平衡：如果你花费太长时间才能发布下一个版本，你可能会落后于竞争对手或错失机会。 随着计划的发布日期临近又过去，你会感到紧张，因为时间太长了，而且你将要打破你所做的所有承诺，因此你会寻找捷径。 最终，版本发布了，但它存在一些问题，并且必须修补几次才能稳定下来。 每个人都记得这一点，你发誓下次你不会走任何捷径，从而加强了缩短流程会降低质量的信念。
长迭代隐藏问题
一方面，生成高质量的版本需要两天的开销。 另一方面，需要三个月。 这两个说法怎么可能都是真的？ 这就是“隐藏问题”的概念的由来。 隐藏问题的许多变体都源于一个根本原因：关于流程问题的反馈在周期后期才出现——为时已晚，无法采取预防措施，因此必须采取治疗措施。 请记住这句老话：“预防胜于治疗。”
假设你为某个版本计划了 100 个工作项。 当然，系统测试在周期接近尾声时进行，因为你知道它会很痛苦，而且你不想多次经历这个过程。 因此，你可能会预先完成所有更改的所有规范和设计，或者你可能会分批完成。 也许你然后继续进行所有编码和测试，或者你可能会在规范和设计批次完成后开始编码。
无论确切的流程如何，在系统测试开始之前，你都不会开始获得关于需求、规范、设计和编码质量的信息。 现在你可能会发现需求收集做得非常差，因为测试人员无法理解事情应该如何工作。 相反，如果你将版本分解为 10 次迭代，你会在第一次迭代后发现这一点，纠正它，结果问题的影响将减少 10 倍。 相反，你现在必须花费比计划更多的时间，因为需要对 100 个工作项中的许多或大多数进行返工，不仅在编码中，而且在重新审视需求、规范和设计，以及重写测试计划和自动化测试方面。
与在周期后期检测到的流程问题相关的延迟在每个版本中都会发生，这就是为什么为最后阶段保留如此多时间的原因。 花费这么长时间的不是版本的质量认证——这仍然只需要两天。 而是使版本达到可以通过两天考验的过程，没有任何问题，这才是花费这么长时间的原因。
功能蔓延
一年很长。 在此期间，向版本添加更多工作项的压力越来越大。 毕竟，在 100 个工作项中再增加一两个工作项又算什么呢？ 当然，在这一年中会有时间将它们安排进去！
我们很快就会忘记我们的头号敌人：功能蔓延。 不知不觉中，你已经被诱惑向计划添加额外的 30 个工作项，并且代码冻结日期即将到来。 不知何故，你最终完成了所有这些小的新项目，但你仍然没有完成原始计划中的一些必备项目。 但没关系； 你仍然有三个月的测试时间，所以你至少可以在那时完成其中一些项目。 你希望有一个高质量的版本，并且尽可能准时。 因此，尽管这可能很痛苦，但你还是从计划中削减了一些必备项目，并在主版本发布后立即创建了一个新的后续版本。
功能蔓延似乎是发布之间时间的函数。 你添加的功能越多，完成版本所需的时间就越长，你就有更多的机会发生功能蔓延。 版本中的大量功能，加上后期发现流程问题所需的额外更改，以及功能蔓延，共同造成了另外两个问题：代码变更和根本原因分析的难度增加。
一旦系统测试开始，就会有巨大的压力来修复问题并赶上截止日期。 许多人正在对相互依赖的系统进行许多更改。 正如依赖于模块 B 的模块 A 开始与对模块 B 进行的上一组更改一起工作时，对 B 的下一组更改随之而来，现在 A 不再工作。 此外，对 A 的一组更改破坏了 C，依此类推。 由于变化如此之多，因此需要很长时间才能进行根本原因分析，以找出如何解决问题和进行修复。 有时似乎每解决一个问题，就会出现两个新问题。
开始使用敏捷开发
做出改变和采用新实践是很困难的。 任何需要全面更改的事情通常都会遇到很多阻力，或者只有在情况如此绝望以至于改变它“不可能让事情变得更糟”时才会完成。
我建议通过一系列小的流程改进逐步采用敏捷开发。 无需从一个全新的项目开始，也无需对现有项目进行全面更改。 组织正在使用什么流程并不重要，它可以从今天开始走上敏捷开发的道路，并以感觉舒适的速度采用尽可能多的敏捷开发。 两个良好的起点是首先编写测试和工作项排序（也称为积压工作）。
首先编写测试。 编写测试需要对某事物应该如何工作有扎实的理解，以便你可以验证它是否正常工作以及它是否正常失败（除其他外）。 测试和需求密切相关。 如果你无法编写测试，这是一个很好的早期警告，表明你的需求存在问题，在这种情况下，任何人都不太可能编写测试应该检查的代码。 由于编写测试应该比编写代码花费更少的精力，因此最好首先编写测试，作为任何需求问题的早期预警系统，并减少因这些问题而必须重写代码的机会。
工作项排序。 工作项排序，在 Scrum 敏捷方法论中也称为积压工作，只是从你的市场的角度将未完成的工作项按优先级从高到低排列在一个列表中。 这种做法可以大大简化项目计划，使你专注于目标市场，并有助于防止功能蔓延。 如果在迭代工作开始后为当前迭代提出了一个新的工作项，那么只有当它的优先级高于计划用于当前迭代但尚未开始的工作项时，才会考虑将其用于当前迭代。
敏捷在技术采用生命周期中的位置
尽管敏捷开发肯定有热度并且势头越来越强劲，但今天实际上并没有多少人真正使用它。 它仍然给人一种处于 Geoffrey Moore 技术采用生命周期的“早期采用者”甚至“创新者”阶段的感觉。 由于没有多少人使用敏捷开发，因此很难在你现有的网络中找到可以依靠的人来帮助你采用它。 为了获得好处，你必须接受成为早期采用者所涉及的风险，并承诺领导你的第一个敏捷项目走向成功。
软件行业存在的首要原因是人们从根本上相信他们会为自动化带来的生产力提升付费。 然而，许多敏捷开发的倡导者建议使用墙上的 3x5 卡片来跟踪项目任务，卡片在墙上的位置表明其状态。 不幸的是，这使得难以利用现代技术来编辑、搜索、分类、重组、报告、跟踪、管理、分发、复制、共享、远程访问以及使用项目信息进行备份。 反过来，这使得团队成员难以在不同的办公室、在家中或在旅行时工作。
诉诸原始工具的原因部分是对软件流程工具本质上是官僚主义的这种感觉的反应。 这在某种程度上是事实，大多数软件工具旨在适应传统开发实践的框架，并且尚未适应超出表面变化的范围以应对敏捷开发的挑战就证明了这一点。
例如，要采用工作项排序的实践，你无疑需要求助于使用 Excel，进行一些自己的工具来支持它，等待该功能在你选择的项目管理或问题跟踪工具中可用，或者咬紧牙关迁移到少数几个新的敏捷项目管理工具之一，例如 RallyDev 或 VersionOne。
将敏捷扩展到小型本地化团队之外
阻碍敏捷开发成为主流采用的最大挑战是将其扩展到小型和本地化团队之外。 在许多敏捷方法论中，拥有小型本地化团队要么是明确的要求，要么是潜在的假设。 这与对自动化的不重视和有限的工具结合在一起，意味着更大和/或分布式的团队将需要尝试调整敏捷方法论以在其环境中工作，或者等待其他人完成开辟这些道路。
DAMON POOLE 是 AccuRev Inc. 的首席技术官兼创始人 (http://www.accurev.com)，这是一家应用程序生命周期管理 (ALM) 软件公司，致力于开发软件配置管理 (SCM) 工具，专注于改进全球团队的并行和分布式开发，以保持敏捷性和竞争力。 Poole 在 Fidelity Investments 和开放软件基金会等公司管理小型和大型开发项目的 15 年中，开发了 SCM 最佳实践，他在开放软件基金会领导了大规模多供应商集成项目的 SCM 工具开发工作。 Poole 于 1987 年在佛蒙特大学获得计算机科学学士学位。
敏捷资源
要了解有关敏捷开发的更多信息，请查阅以下资源
敏捷联盟； http://www.agilealliance.org。 这是开始搜索有关敏捷开发的更多信息的绝佳起点。
极限编程释义，第 2 版，Kent Beck 著（Addison-Wesley Professional，2004 年）。 这是关于敏捷开发的开创性书籍。 无论你是否同意 3x5 卡片的想法，这都是一本简短易读的书，非常值得付出努力。
丰田之道，Jeffrey K. Liker 著（McGraw-Hill，2003 年）。 由丰田生产系统开创的精益生产是敏捷思维的关键影响因素之一。 在这本引人入胜的书中，Liker 不仅描述了丰田的精益方法论，还解释了它如何只是丰田生产高质量产品并在异常短的时间内完成的总方法的一个方面。
精益软件开发，Mary Poppendieck 和 Tom Poppendieck 著（McGraw-Hill，2003 年）。 这些人在将精益生产的经验教训应用于软件开发方面做得非常出色。 阅读这本书是我的转折点。
敏捷项目管理与 Scrum，Ken Schwaber 著（Microsoft Press，2004 年）。 作为为数不多的关于敏捷的“经验教训”书籍之一，它大量依赖案例研究来说明 Scrum 原则在各种场景中的应用。 无论你对哪种敏捷方法论感兴趣，这都是一本值得一读的好书。
最初发表于 Queue 第 4 卷，第 8 期——
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑非加密哈希函数的评估标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。 许多标准都适用于出于各种安全需求而设计的加密哈希，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。 虽然针对真实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。 直观地看，技术领导者普遍接受良好的开发者体验可以实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改善 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了有力的论据。 本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。 在其追求快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略某些它面临的永恒问题的经过验证的解决方案。 用例于 1986 年首次引入，后来得到普及，是这些经过验证的解决方案之一。
© 保留所有权利。