软件项目的铁三角模型:软件质量与快速开发的矛盾 - Richard

21-06-13 banq

在“铁三角”模型中,有 3 个约束条件:
  1. 资源Resource:有多少人投入
  2. 范围Scope:需要完成多少工作
  3. 时间Time:完成工作的时间

它们形成了一个三角形,三角形的面积代表质量。
如果您曾经听过人们谈论“遗留代码”、“技术债务”等,那么您现在可能已经发现这个模型在起作用!质量和速度的关系没那么简单!不是简单认为:质量越高,速度越快,这是一种二分法的极端概念,高质量不代表高效高速,如果我们在短期内牺牲质量,就会损害速度?
平衡质量和速度并非易事 如果我们花大量时间寻求质量,一切都需要更长的时间,我们会失去速度;但是如果我们不主动尝试保持高质量,那么复杂性就会接管,一切又需要更长的时间,我们又失去速度。
同时,我们正在企业中构建软件。这意味着时间和金钱很重要!软件进展缓慢对企业来说是毁灭性的,显然需要紧急解决!
添加资源既昂贵又困难;此外,我们知道布鲁克斯的定律:“在一个迟到的项目中增加更多的人会使其晚一些”——所以这可能不是一个选择。
大多数企业自以为自己“掌握”“需求”,因此将范围缩小排除在质量与速度之间。。。这就造成复杂性的原因!
当然,对于短期的速度提升,我们可以在质量上偷工减料……但这会很快导致更多的复杂性、错误、返工和其他坏事,这会损害速度。
 
如果事情变得非常糟糕,最可能的答案是“重新编写”……让我们重新开始,不要犯同样的错误……这次我们将真正专注于质量!所以新项目开始了,每个人都非常乐观。让我们引入尽可能多的质量工具!单元测试、集成测试、TDD、BDD、没有空值的外来新语言……当然还有行业标准,Pull Requests - 一切为了质量!
需要明确的是,其中许多都是提高质量的好工具,一个能够及早快速检测问题的良好测试套件非常有价值。你可能应该确保你有很好的测试!但问题是,拥有所有这些东西会让你慢下来......
如果你进展缓慢,在一个时间和金钱都很重要的企业中,那是行不通的……如果你进展缓慢,管理者必须参与,不参与是不负责任的。我们又回到了质量与速度的较量——你需要走得更快……

显然,我们需要在不损害速度的情况下尽可能提高质量,同时在不损害质量的情况下尽可能提高速度。
 
这意味着批判性地看待每个工具,并诚实地了解它带来的好处以及这些好处的成本。一些工具——例如自动化测试——非常强大,但非常昂贵,所以也许我们会谨慎使用它们(想想“测试金字塔”)
 

Pull Requests拉取请求
最无法通过平衡测试的工具是 Pull Requests拉取请求。这有很多原因,即“物理定律”的东西,同时又是 PR 设计的内在因素,因此是不可避免的。
拉取请求的“作用机制”是让多人看到每个更改,以捕获并解决Bug。
拉取请求客观地产生很多额外开销:

  • - 增加中断和上下文切换
  • - 引入阻塞、瓶颈、争用和等待
  • - 增加在制品和批量大小
  • - 延迟缺陷检测并增加返工

这些都是导致损害速度的最明显的问题。拉取请求被提升为帮助提升质量的工具。但是,拉取请求会损害速度。当速度受损时,团队会面临时间压力。当有时间压力时,人们更可能匆忙,质量受到损害。
Pull Requests 的好处是:多个人在做同一件事——协作。然而,Pull Requests 是一种非常间接的协作形式!如果您重视 Pull Requests 的好处,您可能想看看有没有其他其他协作机制!
 

将“范围”作为常量的问题
传统观点是:铁三角中范围(需要完成多少工作)几乎总是更像是一个常数,是团队的上文,而不是团队可以对其产生任何影响的变量,是一个前提假设,但是挑战这个假设为我带来了巨大的突破。
到目前为止,我看到的最常见的对付"范围"方法是团队有一组“ticket票”,并且一次只做一些,或者更有可能同时做几张票。它们被视为原子,无论是“完成”还是“未完成”,而游戏就是尽可能多地“做”。
计划通常是通过“估计”每个原子票需要多长时间来完成的,可能是抽象的形式,例如故事点,但票的内容同样被视为固定的。
问题在于,这种“估计”是建立在理论之上的,然后再受制于往往残酷的现实世界。有时会出现不可预见的问题,这意味着完成一项任务需要更长的时间。
我们还需要注意帕金森定律——“工作会扩大,以填补完成它的可用时间”——这意味着虽然有时事情会比预期的要长得多,但事情花费的时间却少得多。 . 这是一个偏态分布!
让我们也了解一下 侯世达(Hofstadter)定律:“做事所花费的时间总是比你预期的要长,即使你的预期中考虑了侯世达定律。” 如果您希望添加“缓冲区”可以拯救您,对不起...

 
范围作为变量

那么,我们如何才能可靠地交付进展?会有很多解决方案,但以下是对我有用的方法...
- 不要以完成为目标,以更好为目标
 不要问多长时间,设定固定时间预算并寻找最佳花费方式
也就是说,使用“范围”作为变量,
您可以向需要看到可预测进展的企业承诺,您将分享自上次以来取得的进展的确切时间。你可以对事情的进展完全透明,如果遇到问题,你可以一起做出选择。
现在不再是“尝试做很多工作”,而是“尝试从固定的工作量中做出最大的改变”。这意味着使用帕累托(80:20 规则),并寻找最具影响力的改进!
在实践中会发生的情况是,一开始,您将能够做出重大改进,然后会出现收益递减的情况。这时问题应该是“我们下一步应该改进什么”?
在每个固定的时间周期内,您决定要改进什么,并尝试做出最大的改进。有时它会很顺利,有时不会那么顺利。您可以从中吸取教训,并将反馈包含在下次的决策中。
能够快速改变方向......我们有一个词.:敏捷
 

总结
所以,总结一下: - 质量与速度是一场失败的游戏

  • - 不要玩!
  • - 平衡是关键
  • - 关键,寻找成本/收益
  • - 请记住,在业务中,时间和金钱很重要(!),并且往往会在冲突中获胜
  • - 进展很重要
  • - 专注于稳定改进,尽早交付



 

1