shell中递减
当您将一个人添加到团队中时，这会带来短期的打击，因为团队的其余成员会放慢速度，以使新团队成员快速适应并适应与其他人一起工作，以确保他们适合并可以做出贡献。 还有长期费用。 更多的人意味着有更多需要彼此交谈的人（nx n-1 / 2），这意味着更多的误解，错误和方向错误以及交接失败的机会，更多的分歧和冲突的机会，更多的瓶颈点。
当您继续增加人员时，团队需要花费更多的时间来使每个新人快速入门，并需要更多的时间使团队中的每个人保持同步。 增加人员意味着团队的速度越来越慢，而人员成本和通讯成本以及管理费用却不断上升。 在某些时候会出现负回报–如果您增加人员，团队的绩效将下降，您要做的工作会更少，而不是更多。
任何一种做法的收益递减
但是，在项目中增加太多的人并不是减少软件开发回报的唯一情况。 如果您从事一个足够大的项目，或者如果您从事维护工作了足够长的时间，那么您到处都会发现收益递减的问题。
过于依赖任何工具或实践，在一个方向上用力推动，最终会导致收益递减。 这适用于：
- 手动功能和验收测试
- 测试自动化
- 任何单一测试技术
- 代码审查
- 静态分析错误查找工具
- 渗透测试和其他安全审查
在单元测试中实现100％的代码覆盖率就是一个很好的例子。 建立一个良好的自动化回归安全网很重要–在您对系统关键区域进行测试时，程序员会更有信心，并且可以更快地进行更多更改。
多少测试就足够了？ 在持续交付中 ，Jez Humble和David Farley将80％的覆盖率作为自动化单元测试，功能测试和验收测试的目标。 您可能会在许多领域降低覆盖率，而在核心领域获得更高覆盖率。 您需要足够的测试来捕获常见和重要的错误。 但除此之外，更多的测试变得更加难以编写，发现的问题也更少。
首先，单元测试只能发现很多问题。 史蒂夫·麦康奈尔（Steve McConnell）在《代码完成》中解释说，单元测试只能发现代码中15％到50％（平均30％）的缺陷。 与其编写更多的单元测试，不如将人们的时间花在其他方法上，例如探索性系统测试和代码审查 ， 压力测试或模糊 测试以发现各种错误。
重构对于随着时间的推移维护和改进代码的结构和可读性很重要。 它旨在作为一种支持实践–帮助使更改和修复更简单，更清晰，更安全。 当重构本身成为目的或变成强迫症时 ，它不仅增加了不必要的成本，因为程序员将时间浪费在琐碎的细节和样式问题上，而且还可能增加不必要的风险并在团队中造成冲突 。
确保重构以一种有规律的方式进行，并将重构的重点放在最需要它的区域上：频繁更改的代码，例程太大，难以阅读，过于复杂且容易出错 。 将您的大部分注意力放在重构（或必要时进行重写）上，此代码将为您带来最高的回报。
随着时间的流逝越来越少
随着时间的流逝，收益也逐渐减少。 使用相同的方式和使用相同的工具花费的时间越长，看到的收益就越少。 即使您逐渐依赖的核心实践也不会随着时间的流逝而回报，有时甚至会花费比其价值还高的成本。
又是新年的决心了–是时候在健身房注册并开始举重。 如果坚持相同的惯例几个月，您将开始看到良好的效果。 但是过了一会儿，您的身体就会习惯了工作-如果您继续以相同的方式做同样的事情，您的表现将达到平稳状态 ，您将停止看到收益。 您会感到无聊，然后停止上健身房，这将为像我这样的人留下更多的空间。 如果您坚持不懈，努力争取更多回报，您将过度训练并伤害自己。
使用相同工具，使用相同实践的软件团队也会发生相同的事情。 其中一些是由于惯性造成的。 团队，组织达到平衡点，他们想留在那里。 因为它很舒适，并且可以工作-至少他们理解。 而且，由于团队工作得越好，就越难变得更好–所有低垂的果实都被采摘了。 人们过去一直在为自己工作。 他们停止寻找既定惯例，不再寻找新想法。 能力和控制导致自满和接受。 他们没有尝试变得尽可能的好，而是选择足够的好。
这是在Scrum和其他带时间限制的方法中进行检查和调整的重点-要求团队定期重新评估他们在做什么，他们是如何做的，什么是好的，什么不是，应该做的或多或少地挑战着现状并找到前进的新方法。 但是，即使评估和改进的行为也会受到收益递减的影响。 如果您是在2周的时间范围内构建软件，并且已经进行了3、4或5年，那么您真的应该从这么多肤浅的评论中获得多少有意义的反馈？ 一段时间后，团队发现自己遇到了同样的问题和难题，并得出了相同的结果。 评论变成了不必要的空洞的仪式，又是浪费时间。
工具也会发生同样的事情。 例如，当您首次开始使用静态分析错误检查工具时，很可能会发现一些代码中不知道的有趣问题-甚至可能比您能解决的问题还要多。 但是，一旦您对此进行分类并修复了代码并使用了一段时间，该工具就会发现越来越少的问题，直到达到您要支付的保险费用为止–它再也找不到问题了，但是可能有一天。
在“ 安全软件开发是否已达到极限？ 威廉·杰克逊（William Jackson）辩称，从质量和安全的角度来看，所有SDLC最终都将达到收益递减的地步，微软和Oracle和其他大型商店的SDLC收益已在递减。 他们的软件不会变得更好-他们所能做的就是继续花费时间和金钱来保持现状。 敏捷方法（例如Scrum或XP）也会发生同样的事情–在某些时候，您已经从这种方式或工作中榨取了一切，团队的绩效将达到稳定。
您如何才能减少收益？
首先，了解并期望收益会随着时间而减少。 注意迹象，并将其纳入您的期望中—即使您坚持纪律并继续在工具上花费，您所花费的时间和金钱也会越来越少。 注意团队的速度达到平稳或下降的速度。
期望这种情况会发生，并准备进行更改，甚至迫使团队进行根本性的更改。 如果您使用的工具不再提供任何回报，请查找新工具，或者停止使用它们，然后看看会发生什么。
继续检查团队的工作方式，但是以不同的方式进行这些检查：减少检查频率，使检查更加集中于特定问题，让团队内部和外部的不同人员参与。 利用问题或错误来改变现状并挑战现状。 使用“ 根本原因分析”进行深入挖掘，挑战团队的思维和工作方式，寻找更好的东西。 不要满足于简单的答案或逐步的改进。
记住80/20规则。 您的大多数问题都将在少数几个常见原因的同一区域内发生。 您的大部分收益将来自一些举措。
更改团队的驾驶重点和关键指标，设置新的标准。 使用精益方法和精益思想来识别和消除瓶颈，延迟和低效率。 查看随着时间的推移添加的控件和测试，并检查是否仍然需要它们，或者找到可以组合，自动化或简化的步骤和检查。 专注于减少周期时间并消除浪费，直到您力所能及。 然后将重点转移到质量和消除错误上，或简化发行和部署流程，或将一些其他新的重点推动团队以有意义的方式进行改进。 并继续这样做并不断努力，直到看到团队变慢并且结果下降为止。 然后重新开始，并推动团队在另一个方面进行改进。 继续观察，不断变化，继续前进。
参考： JCG合作伙伴 Jim Bird在“ Building Real Software”博客上的 软件开发和维护回报减少 。
翻译自: https://www.javacodegeeks.com/2011/11/diminishing-returns-in-software.html
shell中递减
601
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
