所以，我不是开发者也不是项目经理，但我发现这篇文章非常有启发性。冒着问一个愚蠢的问题并得到RTFM或LMGTFY的风险，能否提供一些简单且实际的大型软件成功案例？我在医院工作，所以医疗相关的最好，但任何内容都可以。顺便说一句，我已经读过《凤凰项目》，它帮助我更好地理解了“敏捷”和DevOps的理念，但由于这不是我日常工作中的常规应用，所以很难保持新鲜感。我的目标是尝试在小项目中播种成功的理念，最终提出问题，让人们以类似的角度思考。
源讨论数万亿美元被投入，但大型软件项目仍在失败原帖 603 条评论 · 导入时统计把你的经验，加入这段讨论。
Unix 和 Linux 是你典型的例子。 Unix 是一项尝试将 Multics 这个过于模块化的操作系统，整合成一个更统一的整体的项目（书籍推荐：https://www.amazon.com/UNIX-History-Memoir-Brian-Kernighan/d... ）。 尽管 Multics 的模块化有一些好处（据说你可以在不重启的情况下卸载和更换 Multics 服务器的硬件，这在当时是闻所未闻的），但这也成了它的致命弱点。Multics 最终被认为过于复杂，难以使用。它无法跟上技术环境的变化。贝尔实验室在项目被搁置后得出的结论是，操作系统成本太高，设计起来太困难。他们告诉工程师们，没有人应该再从事操作系统的工作。 肯·汤普森（Ken Thompson）想要一个现代的操作系统，所以他无视了这些指示。他使用了一些 e…
完整原文我觉得很难定义成功或失败。谷歌搜索和 Facebook 是成功的，对吧？它们能够按需扩展，这很难做到。但它们的起步方式与政府机构或大型公司从头开始协调的方式非常不同。我不知道你是否了解这一点，但也许 healthcare.gov 是一个很好的例子……它以严重有缺陷而闻名，但在一段时间和巨大的压力之后，它得到了解决。
完整原文我听说 Direct File 非常成功。大约有 94% 的人报告称这是积极的体验。
完整原文这是一个高尚而雄心勃勃的目标。我觉得我有资格提供一些指导，不是因为我曾参与交付过巨大成功的项目，而是因为我以各种方式参与了许多失败的项目。你可以从这些经验中吸取你想要的教训： - 尽早定义“成功”。这通常并不意味着按时按预算完成。实际上，这仅仅是真正目标的开始。真正的成功应该在几个月或几年后才能确定，当软件和流程在生产环境中被使用之后。 - 注意康威定律（Conways Law）。如果你不重视它，后果将很严重。 - 注意关键人物的风险。这意味着如果只有一人了解所有情况，那么如果这个人离开或生病，就会有风险。团队中需要建立冗余，而不仅仅是硬件/架构中。 - 没有人关心防止火灾发生。他们只关心…
完整原文印度的UPI（数字支付）规模几乎达到了顶峰，而且它被普遍认为是一个成功案例：https://en.wikipedia.org/wiki/Unified_Payments_Interface
完整原文我认为你不应该专注于成功的大型项目。通常来说，所有大的成功都是众多尝试中的异常情况。它们只是运气好，而你无法复制运气。 我想稍微纠正一下你的方向。 DevOps是一个垃圾概念，它有好的初衷。但现在它只是行业中的一个作弊代码，用一个开发人员来填补三个职位的空缺，这个开发人员还要负责值班。从它那里值得借鉴的是：让人们关心整个流程是否正常运行。如果乔不关心鲍勃的问题，那就说明哪里出错了。要么是流程有问题，要么是人员有问题。 敏捷（Agile）现在是一个非常宽泛的术语。总的来说，它与制定大型前期计划并一次性实施相反。敏捷希望从小处着手，并根据需要逐步改进。这在行业中往往有效，但迭代的时间段存在一些问题，有些团队可以快速推进，而有些则不能…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。