速度-率先进入市场,快速创新和进行快速廉价的实验-对于初创企业和许多高科技公司而言至关重要。 这就是精益启动思想和持续部署的来源。这就是为什么许多公司都遵循敏捷开发,快速,灵活地设计和交付软件,结合反馈并响应变化的原因。
但是,当软件以及开发软件的公司成长时会发生什么? 在企业一级重要的是什么? 对于企业而言,速度还不够。 您必须在速度,成本和质量之间取得平衡。 以及稳定性和可靠性。 和安全性。 以及长期的可维护性和可持续性。 而且,您必须与公司以及客户和合作伙伴的所有其他系统和程序集成。
上周,在西雅图的Construx Software 高管峰会上,一群聪明的人进行了大规模的软件开发管理,共同探讨了所有这些问题。 显而易见的是,对于大多数公司而言,最重要的因素不是速度,生产力或效率,尽管每个人当然都在尽其所能削减成本并消除浪费。 它不是灵活性,它试图跟上太多变化。 人们最关注的是他们的客户和赞助商的要求,即可预测性–在业务需要时交付工作软件,成为其他业务,客户和合作伙伴的可靠且值得信赖的供应商。
企业敏捷发展与可预测性
史蒂夫·麦康奈尔(Steve McConnell)关于敏捷项目评估的主题演讲拉开了序幕。 许多大型公司之所以采用敏捷方法,是因为他们听说过这些方法行之有效。 但是他们并没有立即使用敏捷,因为出于与较小公司相同的原因,他们没有使用敏捷 。
大型公司正在采用敏捷方法和基于计划的混合方法/瀑布方法,这些方法结合了前期范围定义,估算和计划,并在敏捷时间范围内逐步交付了项目。 这与发现和灵活性无关,在您进行过程中定义和设计内容–问题太大,涉及太多的人,业务的太多部分,需要满足的依赖和约束太多。 紧急设计和产品迭代定义不适用于此处。
企业级敏捷开发与速度或“早期交付价值”无关。 这是关于降低风险和不确定性。 越来越多的控制和可见性。 使用故事点和速度并发布“烧伤”报告和工作软件的证据,以早日确信项目进度以及何时完成工作。
关键是要做好足够的前期工作,以便您可以对业务做出长期承诺–至少至少从高层了解业务需求,并首先进行估算和计划。 然后,您可以按照敏捷方法来逐步交付可用的软件,并在即将出现的变化中进行处理。正如麦康奈尔所说, 这与 “ 响应计划而做出的响应 ” 无关 。 它的计划包括应对变化的能力。
通过持续交付少量的工作软件,并使用速度来校准实际项目数据中的估算值,以这种方式工作的团队将能够更快地缩小“ 不确定性锥 ”的范围,他们将Swift了解其交付和交付能力。评估质量的估计,比采用完全顺序瀑布方法的团队快两倍。
仍然有机会应对变化并重新确定优先级。 但这更多是关于增量工作而不是迭代工作。
看板和可预测性
企业开发经理也正在考虑看板和精益开发来管理浪费并保持重点。 但是这里的价值也在于提高可预测性,以通过发现和消除延迟和瓶颈来平滑工作并减少可变性。 这与优化和及时计划无关。
正如David Anderson在与看板提供更好的可预测性,业务敏捷性和良好治理的主题演讲中所解释的那样,高级管理人员关心生产力,成本和质量-但他们最关心的是可预测性。 优秀的软件开发经理的目标是能够使客户保证其组织可以实际满足。
为此,您可以让团队专注于软件开发业务,并尝试排除其他所有问题:消除延迟和空闲时间,减少管理开销,不做最终会被扔掉的工作,最大程度地减少浪费在多方面的时间-任务和上下文切换,并且在完成已经承诺的工作之前不要开始工作。 安德森说,经理喜欢开始新的工作,因为“开始给您的客户一种温暖舒适的感觉” –直到他们发现您对他们撒谎了,因为“我们正在努力”并不意味着该工作实际上已经完成,或者将要完成。 这包括修复错误–您不只是立即修复错误,因为您应该修复发现的错误,这是因为所涉及的工作量较小,而且比以后尝试再修复时更可预测。
团队可以使用看板动态地优先安排和控制摆在他们面前的工作,以平衡支持和维护要求与具有不同服务级别的开发工作和固定日期承诺,并限制进行中的工作(WIP)以缩短交付周期并提高吞吐量,遵循约束理论。 这使您可以在微观水平上控制可变性并提高可预测性。 但是,您还可以使用实际的吞吐量数据和“ 累积流”报告在项目级别进行前瞻性计划,并了解团队可以完成多少工作以及何时完成。
对我而言,有趣的是,无论规模大小,不同的组织(无论规模大小)如何以完全不同的方式使用相同的思想和方法,无论它们专注于快速迭代并响应快速变化,还是管理大型程序以实现成功。可预测的结果。
参考: 可预测性–您可以在Building Real Software博客上与我们的JCG合作伙伴 Jim Bird 保持承诺 。
翻译自: https://www.javacodegeeks.com/2012/11/predictability-making-promises-you-can-keep.html