软件开发作为一种价值领域的研究

 

免责声明

本文是我对软件开发本质的个人看法。这并不是要成为科学论文，因此，许多陈述是故意加粗和直接的，以使文章简短。我尽力根据自己的观察和可用的资料来介绍软件开发的性质，但是我不是商业理论家、科学哲学家也不是社会学家，所以我可能是完全错误的。另外，这可能不适用于所有类型的软件（例如嵌入式软件），但我认为至少涵盖了业务应用程序开发过程。此外，本文不可避免地是从开发人员的角度编写的，尽管我也希望了解其他的角度。

 “我们真正的发现来自混乱，来自去一个看起来错误、愚蠢和愚蠢的地方。” ― Chuck Palahniuk

致谢

我要感谢杰拉德·加西亚先生提供的所有宝贵意见。

一切始于需求

根据Wikipedia所说，“需要是生物健康生活所必需的。[……]在需要的情况下，缺乏会导致明显的不良后果：功能障碍或死亡[…]，需要安全、稳定和健康的生活[…]”。就软件开发而言，共有三种主要的共生生物（也称为利益相关者）共存并从一种已开发的解决方案中受益，我将其定义为软件和任何其他支持工件（文档、过程、策略等）。这些生物是：

• 客户——一个实体或多个实体，其需求驱动解决方案的开发，并从部署中受益。
• 业务——从提供解决方案中受益的一个或多个实体（所有者，股东，管理层等）；
• 开发人员——受益于构建解决方案的一个或多个实体（程序员，架构师，分析师，质量工程师等）。

可以有更多的生物，例如“操作”，但为简单起见，我将保留三个。

这三种生物中的每一种都有其自己的一套需求，这些需求应由公司提供的解决方案来满足。

图1.利益相关者的需求。

对于客户而言，解决方案必须满足的最重要需求是：

• 效用性——表示解决方案解决特定客户的问题的能力。如果是软件，则可以将效用分解为所提供的功能、便利性、性能、可靠性等。
• 灵活性——表示解决方案适应客户面临的新挑战的能力。通常可以表示为更改请求的准备时间和响应时间
• 可负担性——一般可表示为实现正投资回报的需要

对于企业而言，解决方案必须满足的最重要需求是：

• 利润——以维持业务所需的财务利益衡量
• 可预测性——表示公司内部和外部环境的稳定性
• 增长——防止停滞和衰退

对于开发人员而言，解决方案必须满足的最重要需求是：

• 收入——支持开发人员的生活和福祉（对应于Maslow层次结构的两个最低级别）
• 自治——可以转化为对环境进行控制的需求（对应于马斯洛(Maslow)层次结构的第二层）
• 精通——涉及技巧的提高（对应于马斯洛(Maslow)等级的两个最高级别）和执行优质的工作
• 目的——意味着需要更高的含义，所付出努力的合理性以及对未来的改善

所有这些需求都必须通过软件解决方案才能在某种程度上满足这种共生的需求。无法满足某些需求会导致无法满足其他需求，从而导致潜在的多米诺骨牌效应并终止共生。

没有需求是一个岛

需求以这样一种方式相关连：当一个需求得到满足时，满足另一个需求的潜在能力就会增强。另一方面，不能满足一个需求会导致潜在的无法满足另一个需求。关系的一个例子是更高的灵活性，这可以增加利润，因为可以将更多功能出售给客户。

下图显示了此概念，其中椭圆表示需求，线表示关系，箭头表示（潜在）正或负放大的方向（假定所有其他因素不变）。

图2.需求之间的关系（有关说明，请参见附录）

如前所述，放大可能是负的。在这种情况下，无法满足一个需求会导致无法满足其他需求。下面的示例图（是图2的派生图）显示了低质量的代码无法满足灵活性的需求。这会对整个集合沿关系线传播产生波纹效应。负面影响由灰色的强度表示（更多的灰色等于更多的影响），并且该过程分为红色垂直线标记的阶段，因为影响需要时间来传播，从而损失了其价值。

图3.未满足的需求及其后果（图2中图的可能扩展之一）

低质量通常归因于难以理解和修改的代码。这会影响灵活性，因为公司无法快速响应不断变化的客户需求。灵活性会影响利润、可预测性和增长，因为产品可能会落后于竞争，预算和时间表会超支，适应新市场或产生产品衍生产品的能力也会降低。较低的利润会影响可负担性，因为公司与价格竞争的能力降低了。随着新功能，优化或其他改进的延迟，它也会影响效用。它还影响收入因为预算紧张可能会迫使公司寻求廉价的劳动力或削减现有收益。较低的利润会影响自治，因为当预算趋紧时，控制机制也会趋紧。最后，当培训机会减少且工作节奏变得比质量更重要时，它会影响精通。较低的可预测性会影响收入，从某种意义上说，公司倾向于削减开发成本以增加财务缓冲。它还会影响自治，因为自然的管理反应是提高计划、报告和会计准确性。较低的增长或停滞影响精通。当没有计划增长时，短期的权宜之计将更为可取。最后，更低的效用和增长影响目的，因为开发人员会感觉不到他们正在为将来构建有用的东西。

由于为清楚起见已省略了一些关系，因此实际上简化了所给出的示例。在实际情况下，反馈会沿着所有方向传播（请参见图2），直到采取纠正措施或公司陷入困境为止。

下面的另一个简化示例显示了缺乏业务愿景如何影响增长需求，以及这种负面影响如何沿关系线传播。我会将这个过程的证明留给读者作为练习（使用附录中的表格）。

图4.另一个未满足的需求及其后果（图2中图的可能扩展之一）

从需求到价值

在软件开发的上下文中，让我们将价值定义为满足需求的任何事物（介于价值的道德定义和效用的经济定义之间）。某种事物（工件、事件、过程、物质对象等）满足需求越好，它表示的价值就越高。

可以在软件上下文中满足当前需求的最常见值概括如下（列表并不详尽，许多值通常满足多个需求）：

• 对于效用——软件功能、操作速度、可用性、低故障率、低缺陷率、用户培训与业务流程保持一致
• 对于灵活性——随时准备接受变更请求、开发速度、沟通质量
• 对于可负担性——负担得起的许可价格、稳定的定价、灵活的定价
• 对于利润——原始货币价值、利润稳定性、客户保留率
• 对于可预测性——透明的开发流程、员工保留率、客户保留率、成本稳定性、准备接受变更请求、开发速度
• 对于增长——客户群增长、产品组合增长
• 对于收入——原货币价值、支付的规律性、好处
• 对于自主权——透明的日程安排、工作时间灵活性、信任
• 对于精通——培训、质量鉴赏、计划自由
• 对于目的——与个人价值观保持一致、客户的赞赏、业务的赞赏

成功的共生目标是为所有三种生物创造尽可能多的价值，同时在所有需求之间保持最佳平衡。

软件开发作为研究活动

为了找到最能满足利益相关者需求的价值，软件开发团队必须积极搜索并评估所有可能的解决方案。随着需求的变化，目标不断变化。因此，软件开发类似于应用科学研究，其中探索未知事物会产生新的东西（否则将重用现有的软件）。尽管两个社区使用的词汇是不同的，但是软件开发过程的各个阶段可以映射到科学研究的各个阶段。

图5.软件开发与科学研究过程阶段。

软件解决方案开发和科学研究的阶段在以下方面彼此相似：

• 投标或功能请求是对客户需求的初步观察，等同于科学研究中观察的解释（我们实际看到的）
• 需求/业务分析，即问题界定阶段，等同于正确地提出所观察到的问题的正确问题的表述
• 设计+实现阶段等效于假设提议，并做出有关如何满足客户需求以及带来何种后果的预测。这是心智建设和心智实验的快速迭代，它使用启发式方法探索了可能解决方案的多维空间。当人们观察设计和代码（在不同抽象层上基本相同）如何趋于迅速相互验证并相互影响，直到最终认为工作完成时，这种相似性就清晰可见。
• 最后，部署是一项验证假设和预测的实验，大多数情况下以软件形式表示。技术和功能假设得到验证，新的变更请求得到制定。

驯服混乱

从本质上说，研究是一个创造性的过程，它本质上是不可预测的，并且不能保证成功（因为永远不能保证有好的想法）。由于软件开发与应用科学研究非常相似（或大胆地说，实际上是），因此不确定性是软件开发的整个过程和每个阶段固有的。

投标或功能请求通常是一个开放式问题，仅在考虑此阶段拥有的信息量的情况下才能回答。具有讽刺意味的是，通常在这个阶段，当项目只是一个“猜测”时，范围和成本是固定的。此阶段的持续时间和影响无法预测，并且会受到参与方数量、地理位置、沟通效率、业务策略、经济状况等的强烈影响。

需求/业务分析本质上是迭代的，因为一个循环直到满足某个接受阈值为止，这通常只是参与者的集体“直觉”（有时称为最小可行产品）。无论花费多少时间进行分析，需求完整性始终是一个开放的问题。此阶段的持续时间（迭代次数）和影响在很大程度上取决于所涉及的各方，地理位置、天气、领域专家的可用性、通信效率、工具的可用性或专家的能力（碰巧，客户指定能力最弱的一方作为领域专家）。

设计+实现的持续时间和结果取决于需求的质量、沟通、技能，现有代码和设计的质量以及参与人员的能力。这个阶段需要高度的创造力、责任心和开放性，并且受到与上一个阶段相同的问题的影响。

部署阶段持续时间和结果的不可预测性主要来自无法强制客户采用的速度，但是沟通也产生了很大的影响。

生产线谬误

许多公司误以为基于软件的解决方案的构建就像汽车的批量生产。问题是汽车的生产是制造许多已知事物（车身、发动机、车轮等）的实例，这些事物在功能和材料方面都有一定的可变性。通常可以很好地理解和解决该问题，可以很好地掌握方法并可以从外部实现标准。因此，许多经理犯了一个错误，即将定义明确的过程应用于软件开发最终将导致成功。他们认为，由一群精打细算的生产线工人严格遵守当前流行的流程（例如SCRUM）将带来成功。

鉴于以前所说的话，这是一个谬论，因为任何程序都不能替代人民的智慧、知识、经验和奉献精神。而且，不合适的过程会抑制所有这些必需的质量，从而导致比根本没有过程更糟糕的结果。转化为研究领域，这意味着即使经过最复杂的过程，也没有任何普通的乔斯能够替代一个爱因斯坦，因为“一台机器可以完成五十个普通人的工作，但没有一台机器可以完成爱因斯坦的工作。一个非凡的人 ”，可以将软件工厂的生产线想象成一台机器本身。另一方面，如果找到聪明、知识渊博、经验丰富且敬业的人并向他们提出目标，他们通常会提出一个合理的最小流程，使他们在没有太多监督的情况下到达那里。

全力以赴

与应用科学研究类似的软件开发是一种尽力而为的过程，其时间和结果无法预测。可以使用降低风险的技术（现成的组件、设计模式、最佳实践、质量执行、项目审查程序、短迭代、保险、竞价等），但是无法消除固有的不确定性。这表明适用于科学研究和软件开发的管理策略应相似，并以聘用合适的人员为基础，提供适当的手段并管理风险。

PS提防虚假值

如果不仔细地进行操作，从价值的角度进行软件开发可能会带来一些危险的后果，因为有些价值在企业采用时被证明是错误的，最终是致命的。

礼貌通常是在公司行为准则中明确表述的一种价值观，被理解为对他人的态度和行为礼貌。礼貌在社会上具有重要价值，因为它通过防止不受控制的侵略性爆炸来促进社会稳定。问题是企业和社会在不同的现实中运作。对于一个社会而言，稳定比效率更为重要，因为（至少在当代世界中）社会并不存在于自然选择的达尔文式世界中。另一方面，公司生活在充满竞争的自然选择竞争世界中，即“自由市场”。在这样的世界里，有效率比有礼貌更为重要。一个健康的公司应该永远赞美关于礼貌共识的建设性论点，首先导致创造性的解决方案，最后导致熟练的无能。

附录

下表解释了第二章中定义的需求之间的关系。

需求关系	成功放大	失败放大
负担能力→增长	低廉或灵活的价格促进了市场份额的增长	高昂或僵化的价格阻碍了市场份额的增长。
可承受性→可预测性	低廉或灵活的价格使解决方案不受市场动荡的影响	高昂或僵化的价格使解决方案容易受到市场动荡的影响
自治→灵活性	高度的开发者自主权促进了创新的变革方式	开发人员自主权低下会阻碍创新方法的变革
自主→成长	高度的开发者自主权促进了产品的创新方法	开发人员自主权低下会阻碍产品的创新方法
自治→精通	高度的开发人员自主权可促进技能提升	开发人员自主权低，阻碍了技能的提高
自治→效用	高度的开发人员自主权可以培养出解决客户问题的创新方法	较低的开发人员自主权阻碍了解决客户问题的创新方法
灵活性→成长	改变的能力为成长提供了机会。	无法改变会浪费增长的机会。
灵活性→可预测性	变革能力使工作更加可预测	无法改变使努力难以预测
灵活性→利润	变革能力鼓励客户为变革付费	无法更改会阻止客户支付更改费用
灵活性→效用	变更能力允许与客户需求保持一致	无法更改会阻止与客户需求保持一致
成长→精通	扩张激励开发者自我完善	停滞不前会激励开发人员自我完善
成长→目的	扩展使开发人员有建立未来的感觉	停滞使开发人员失去了建设未来的感觉
收入→灵活性	高薪激励开发人员采取主动和长期思考	低工资激励开发人员采取任何超出最低限度的措施
收入→可预测性	高薪激励开发人员采取主动和长期思考	低工资激励开发人员采取任何超出最低限度的措施
收入→效用	高薪鼓励积极解决客户问题	低薪水阻碍了积极解决客户问题
精通→负担能力	高技能减少了开发时间	低技能会延长开发时间
精通→灵活性	高技能助力技术灵活的解决方案	低技能阻碍了技术上灵活的解决方案
精通→可预测性	高技能使开发更轻松	低技能使发展困难
精通→效用	高技能可以满足客户需求	低技能只允许当前可行。
可预测性→自治	稳定的公司更愿意信任开发人员	不稳定的公司更愿意控制开发人员
可预测性→增长	稳定的公司可以计划长期增长	不稳定的公司倾向于确保现有的市场地位
可预测性→收入	稳定的公司可以负担更高的薪水和福利	不稳定的公司节省薪水和福利
利润→可负担性	富公司可以与价格竞争	贫穷的公司无法与价格竞争
利润→自治	富裕的公司更愿意信任开发人员	贫穷的公司更愿意控制开发人员
利润→增长	富裕的公司可以计划长期增长	贫穷的公司努力确保现有的市场地位
利润→收入	富裕的公司可以支付更高的薪水和福利	贫穷的公司节省薪水和福利
利润→精通	富裕的公司可以负担得起培训并投资于质量	糟糕的公司节省了培训和质量
利润→效用	富公司有能力开发昂贵的功能	贫穷的公司没有能力开发昂贵的功能
目的→灵活性	欣赏会激发创造性的变革方法	缺乏欣赏会阻碍创新的变革方法
目的→成长	赞赏促进了产品的创新方法	缺乏欣赏会阻碍产品的创新方法
目的→精通	欣赏激励开发人员自我完善	缺乏欣赏会削弱开发人员的自我完善能力
目的→可预测性	欣赏促使人们遵守时间表	缺乏欣赏会阻碍人们遵守时间表
效用→可预测性	满足客户需求的解决方案具有强大的市场地位	无法满足客户需求的解决方案市场地位很弱
效用→利润	可以满足客户需求的解决方案可以出售更多	无法满足客户需求的解决方案必须便宜才能证明购买合理性
效用→目的	满足客户需求的解决方案使开发人员感到有用	无法满足客户需求的解决方案使开发人员失去了有用的感觉