复杂性偶然与本质

如今,很难找到不遵循敏捷的团队或组织,但是构建软件却变得不容易,项目缺少进度,预算超支并且也存在缺陷。

为什么构建软件如此困难?

如果您向任何工程师提出这个问题,那么90%以上的人会说要求,但这是全部事实吗?

让我们尝试分解软件结构。 每个功能都有2个重要的组件,可决定功能是否成功。

  • 基本并发症(ec)
  • 意外并发症(ac)

我们将做一些功能编程复习。

特征= f(基本并发症)+ f(偶然并发症)

本质上的复杂性来自领域,例如,如果您正在为医疗行业构建软件,那么它很复杂。 偶然的复杂性是工程师,过程和管理人员为构建功能而增加的复杂性。

由于域的原因,很难减少基本的复杂性,但是在某种程度上,可以通过使用良好的分解技术来减少复杂性。 分解是一项艰苦的技能,来自一些失败项目的实验。

偶然的并发症可以控制,但不是线性函数,偶然的并发症在系统的每个部分都不相同,并且随着时间的推移变得越来越复杂。 这也提供了有关我们作为工程师或产品团队所做的糟糕工作的反馈。
复杂性有多种形式,例如团队间的沟通,了解不足,难以重用某些功能,将程序扩展到新功能,管理问题等。

现在我们知道意外并发症是指数的,因此让我们再次编写公式。

特征= f(基本并发症)+ f(偶然并发症*未知)

现在将变得很清楚,为什么某件事花费的时间比估计或猜测要长很多倍。 产品负责人还可以通过标记功能重要性的假设来增加意外复杂性。

该怎么办?
如果我们需要某种可预测性或交付一致性,那么我们必须不断努力以减少意外的复杂性。 让我们看看保持这种状态的方法。

  • 使用高级语言。
  • 通过开发而不是构建软件来进行增量开发。
  • 良好购买与构建决策。
  • 统一编程环境。
  • 突袭原型以完善需求。
  • 听设计压力。
  • 测试驱动的开发。
  • 停止“摆脱困境”的心态。
  • 减少交付过程中的“ 外科手术努力”

弗雷德里克·布鲁克斯(Frederic Brooks)非常有见地的报价,无论是客户还是工程师,都必须学习要问,期望和承诺的内容,否则,唯一的选择就是系统损坏。

“承诺在两分钟内完成的煎蛋卷似乎进展顺利。 但是,如果在两分钟内仍未设置,则客户有两个选择-等待还是生吃。 软件客户有相同的选择。 厨师还有另一种选择。 他可以调高热量。 结果常常是煎蛋饼什么也做不了,要烧掉,一部分烧掉。
― 小弗雷德里克·布鲁克斯(Frederick P. Brooks Jr.),

神话般的月刊:软件工程随笔

必须为每个产品所有者,项目经理和工程师阅读Brooks先生撰写的Mythical-Man-Month

如果您喜欢该职位,那么可以在Twitter上关注我

翻译自: https://www.javacodegeeks.com/2019/11/complexity-accidental-vs-essential.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值