小步迭代快速进化的事物_无迭代开发–最新的新事物

最新推荐文章于 2024-05-29 19:26:03 发布

danpu1174

最新推荐文章于 2024-05-29 19:26:03 发布

阅读量294

点赞数

文章标签：大数据 python 人工智能 java 编程语言

原文链接：https://www.javacodegeeks.com/2011/11/iterationless-development-latest-new.html

版权

小步迭代快速进化的事物

由于精益启动运动，无迭代开发和持续部署已成为软件开发方法中的新事物。显然，到目前为止，这种情况已经到了“硅谷有风险投资公司，除非他们采用精益创业方法，否则它们甚至都不会为公司提供资金”。

尽管我们大多数人都不是在Web 2.0社交媒体初创公司或类似的公司中工作，但切勿大肆宣传并了解我们可以从这些想法中学到什么，这一点很重要。到目前为止，我对Eerationless Development所见过的最全面的描述之一是Erik Huddleston的演讲（很好，但很时髦），它解释了建立在线社交社区的Dachis Group如何进行开发。开发团队的积压工作会及时进行更新，其中包括客户业务需求（定义为最低功能），来自运营的反馈（来自分析和Devops回顾结果的数据）以及最低限度的技术架构。

使用看板WIP限制和队列来管理工作。开发人员为每个更改创建测试或预先修复。每次检入都将启动自动测试和静态分析检查，以进行复杂性和代码重复，作为持续集成的一部分。如果通过了这些步骤，则更改将被提升到测试环境，然后必须对代码进行体系结构审查（他们使用Atlassian的Crucible在线代码审查工具来进行此检查）。

一旦检查了所有相关的变更集，代码变更就被部署到阶段以供产品管理进行验收测试和审查，然后再推广到生产中。所有生产变更（代码变更集，环境变更和数据库迁移集）都打包到Chef食谱中，并逐步在线上推出。这是一种纪律严明，结构合理的方法，在很大程度上取决于自动化和良好的工具集。

死于时间拳击

无迭代开发之所以与众不同，显然是因为它没有时间限制–而不是以冲刺或尖峰的形式进行组织，而是以连续的流程进行工作。根据哈德斯顿（Huddleston）的说法，无迭代看板是“可保留的”，并且“比人工时间拳击更有生产力”。

在另一篇博客文章中，他谈到了迭代的终结。尽管他同意迭代有好处-为团队提供一个固定且一致的例程，但强制功能可促使工作完成（任何事情都不能像截止日期那样集中精力），并且可以使团队与其他人保持同步的业务–哈德斯顿（Huddleston）断言，在时间范围内工作是不自然且不必要的。时间框定义的人为的和任意的边界迫使人们在解决方案上做出折衷，并迫使他们偷工减料，以便赶上最后期限。

我同意时间框是任意的，但不超过工作日或工作周，一个月或一个财务季度的时间；企业遵循的所有周期。在业务中，我们始终在为最后期限而努力，无论是硬性，真实性还是软性和任意性。这就是工作的完成方式。如果我们在时间范围内工作或没有时间范围，这都不会改变。

在无迭代看板中，满足定期时间期限要求的压力已被恒定的压力所取代，这种压力要求尽可能快地交付工作，以满足各个任务的期限要求。在很长一段时间内，在短时间内快速循环对于团队来说已经足够困难了。持续的，中断驱动的开发，尤其是对优化周期时间的专注，就更加困难了。拨盘设置为开，并保持该状态。看板使这一过程变得简单，为团队以及客户和管理层提供了持续可视化进行中的工作，识别瓶颈和延误以及减少浪费的工具，从而最大程度地提高了效率。记住这是制造过程模型。对战术优化和快速反馈循环的强调，以及对消除浪费的“近视关注”就是这样-目光短浅且难以维持。

有了时间框，至少有内置的同步点，团队有机会进行审查和重置，以便人们可以反思自己所做的事情，寻找改进的方法，展望下一步需要做的事情，以及然后以最佳速度重新建立起来。这不是浪费。上下骑自行车很重要，对于防止人们精疲力尽，并使他们有机会思考和提高自己的工作水平至关重要。

以相同的战术，短视方式来管理风险。一次处理一个问题的团队最终一次要管理一个风险，这很大程度上取决于自动化测试和代码审查等流内控制。这很好，但对于许多环境而言还不够好：安全性和可靠性风险需要以更全面，系统的方式进行管理。即使整合来自Ops的反馈，也不足以发现和预防严重的问题。在敏捷时间框内工作已经在为提高速度和效率而牺牲技术风险。专注于消除浪费和加快周期时间的无迭代开发和持续部署将这些权衡进一步推向了危险区域。

哈德斯顿（Huddleston）对于“盒装”也很重要-在一个时间盒内将不同的工作分批处理-因为这会干扰简单的优先级划分并引入不必要的延迟。但是一起有意义的批处理工作可能是降低风险和成本的有用方法。举一个简单的例子。团队正在研究功能1a。完成后，他们继续进行功能1b，然后是功能1c。所有这些工作都需要更改代码的相同部分，进行相同或相似的测试和审查，并对操作产生相似的影响。通过将这些工作分批处理，您可能会更慢地交付它，但是通过一次而不是3次交付，可以减少浪费并最大程度地降低风险。

无迭代开发很有道理……

使用看板作为控制结构的无迭代开发是应对过度压力和不确定性的有效方法，例如在早期启动阶段或消防支持团队中。它基于客户和运营的不断反馈，对于快速创新和实验原型非常有用-在这种情况下，对业务和客户的速度和响应能力至关重要，这比最小化技术和运营风险更为重要。它正式化了大多数成功的Web初创公司的工作方式–提出一个很酷的主意，尽快构建原型，然后将其发布出来，并在您用光现金之前找出客户的实际需求。但这不是解决软件开发问题的万能解决方案。

所有软件开发方法都是折衷方案–不完善的风险和不确定性管理尝试。顺序或串行开发方法尝试先指定并修复解决方案空间，然后再管理此固定范围。具有时间限制的迭代开发可通过将业务需求分解为细微的具体问题并定期提供可行的解决方案来帮助团队应对不确定性。而且，当问题尚不清楚且尚无确定方向时，无迭代的连续流程可让团队快速测试想法和替代方案。

没有一个正确的答案。您采用哪种方法取决于您的优先事项和情况，以及今天需要解决的问题和风险。

参考：无 迭代开发-我们的JCG合作伙伴 Jim Bird在“ Building Real Software”博客上发布的最新新事物。

相关文章：