参与软件项目的人会说，软件开发与理解复杂性有关。
什么是复杂性？
复杂性很容易在高层次上定义，但是当人们要求精确定义时，人们会变得模糊。 让我们看看是否可以量化问题，然后再回来进行定义。
假设我们需要开发一个50,000行代码1 （方案A ）的项目，假设每天有10条代码生产线2 ，则该项目将需要5,000个工作日来开发。 即使我们很慷慨，并且假设每个开发人员每天有50条代码生产线，但该项目仍需要1000天的开发时间。
现在，使用该开发的代码，并让一个开发人员重新输入它（场景B ）。 开发人员每天可能至少可以编写1000行代码，而进入整个程序只需要大约50天的时间。
97.5％的项目是解决问题，而不是编写代码
在方案A中，我们不知道要编写哪几行代码，因此要花时间来确定：
- 实际要求是什么
- 如何将需求分解为高级设计
- 如何将高级设计转换为编程语言和库
- 代码缺陷在哪里
尽管我们95％的时间花在弄清楚要写哪几行代码上似乎是令人吃惊的，但稍作反思就会使我们确信情况确实如此。 我们错误地认为项目失败是因为没有足够的时间来编写代码，但是实际上，问题是我们不知道要编写什么代码行。
项目不会因为没有足够的时间来编写代码而失败
复杂性从何而来？
既然我们已经量化了花费在解决复杂性上的时间是多少，它来自哪里？ 复杂性来自团队资源，他们不了解如何解决他们面临的问题。 遇到问题时，团队必须考虑如何解决。
如果项目中有足够的时间来解决它，那么复杂性就不是问题。 当您需要解决问题并且没有预算时间时，复杂性就是一个问题。 项目之所以迟到，主要是因为两个原因：
- 时间不足
- 您没有使用正式的估算技术并低估了项目
- 您可以使用正式的估算，而主管人员则可以根据项目中要解决的问题来确定交货日期
- 了解为什么高级管理人员宣布的截止日期导致灾难
- 需求不足
- 您估计团队的技能水平有足够的时间来解决问题，但是您并没有所有要求
时间不足
很清楚为什么时间不足会导致项目失败，但是这里有一些具体的统计数据。
如果高管拒绝正式的商业估算：
由于业务原因而拒绝估算会导致生产率下降15％，质量下降21％
如果高管们要求的项目截止日期过于激进：
日程安排压力过大导致生产率下降16％，质量下降23％
需求不足
当您低估需求复杂性时，就会发生第二种情况。 定期启动仅收集一部分需求的项目。 项目开始后，会有一个疯狂的破折号来捕捉缺少的需求，即范围爬升（请参阅Shift Happens ）。
项目计划通常基于最初的一组需求，并且当您发现缺少需求时，不会对项目截止日期进行调整。
无法估计需求变更以计划进度导致生产力下降16％和质量下降22％
为什么我们低估了需求的复杂性
人类被低估了复杂性。 例如，假设客户说他们想要一辆汽车，我们都知道汽车是什么，对吗？
看以下汽车：
显然，这些汽车并不相同，建造它们所需的成本和时间也不相同。 抽象地，我们都了解汽车是什么，我们可以对此进行一般性讨论。 但是，当我们开始深入研究细节时，有许多问题需要回答，例如：
- 汽车需要走多快？
- 它需要坐几个人？
- 您想要哪种燃油经济性？
- 需要哪些安全功能？
在急于启动项目的过程中，我们跳过了需求流程，而许多问题都没有得到回答。 但是在某个时候，开发人员需要这些信息，以便他们可以解决他们的问题，并且需要收集需求。 项目经常会因为没有预算时间来收集足够的需求而导致时间用光。
技巧与复杂性
解决复杂问题所需的时间与团队的技能水平之间存在明显的权衡。 如果您从未见过问题，那么它很复杂，但是一旦您解决了问题，便总能看到解决方案。
就像这里显示的迷宫一样，第一次可能需要花费大量时间来找出解决方案。 之后，您将直接进入解决方案而没有死胡同。
当收集需求时，分析师对领域的了解越多，他们错过需求或需求不一致的可能性就越小。 这消除了需求不一致的可能性，并增加了捕获足够的需求以启动项目的可能性。
当开发人员具有该领域的经验时，他们将花费更少的时间将需求分解为高级设计。 当他们对所使用的语言和库有经验时，他们可以将高级设计转换为低级设计并更快地编写代码。
因此，成功的软件项目认识到复杂性等于团队要找出他们不是主题专家的任何东西所需要的时间。
- 对于分析师
- 这是关于了解主题并确保收集足够的一致要求
- 对于开发商
- 这是关于了解高级设计的主题，以及了解实现的语言和库
- 对于项目经理
- 这是关于了解团队的能力，并确保为他们安排足够的时间来解决所有问题
- 对于IT主管
- 这是为了了解任何给定的项目团队都需要足够的时间来解决问题，而不需要冒行政压力来任意缩短项目
参考文献
- 琼斯，雀跃。 评分和评估软件方法，实践和结果 。 2008。
翻译自: https://www.javacodegeeks.com/2016/08/avoid-underestimating-complexity.html
