我读了哲学家伯特兰·罗素 (Bertrand Russell) 的《生活的十诫》，它让我迅速联想到软件项目得以生存的 10 条诫命。
软件项目往往急于采取行动，尝试尽可能快（且便宜）地创建软件，这将导致软件开发团队同意不可能实现的计划，并错过必要的步骤。
然而，在考虑如何为成功创造环境之前，首要考虑的应该是避免灾难，不是吗？
我见过的许多项目从一开始就很糟糕（没有许可证、工作站或互联网连接），并且从那里就走上了下坡路。
我们要把软件项目看成是一个 12 回合的战斗，我们需要避免在第一轮被淘汰，要给自己一个继续战斗的机会。
软件项目中，常见的一个景象是过度地简化软件需求，并低估所需的时间。这样做的后果是，团队对项目过于自信，并为此制定可能仅会花费一半实际时间的计划。
这是一个项目糟糕的开始方式，但它的的确确正在发生。
所有计划都是错误的，只有有些是有用的。一份计划有助于开始我们的工作，但它并不是创建软件需要多长时间的准确指南。
那些被低估的计划将鼓励领导做出愚蠢的决定，让项目按照原始计划交付。
创建软件是困难的，这就是开发人员成本高昂的原因。如果这很容易，每个人都会做，那就永远不会有项目延迟。
所以，并不是软件项目延迟了，而是它们被低估了。在软件开发中，方法才是障碍。发现需求、修改设计、变更软件是创建正确软件的路径。
软件开发中的一切都不像看起来那么简单。
用户是不知道软件应该如何工作的，只有当你向他们展示他们所有要求的内容，也就是实际运行的软件时，他们通常才会告诉你它不应该具有的表现。
从业务需求开始
软件项目的目的是创建对业务有帮助的软件，而不是要创建适合开发计划的软件，也不是要创建适合所选技术的软件，而我们往往会走偏。
创建的软件应该帮助用户和业务工作。业务用户是业务运作方式的专家，开发团队需要业务专家来说明软件应该如何工作，技术专家（开发团队）需要与业务专家一起来设计软件。
纯粹由技术驱动的解决方案往往最终难以使用，它们以开发人员猜测的方式工作。
当开发人员来决定软件应该如何工作，并且没有阐明需求时，他们就会做出一些假设。而这些假设是开发人员创建的错误，最终在用户验证时才会被发现。
所以，要澄清所有的这种假设，因为假设很可能意味着一个错误，而且会导致建立在它之上的所有内容都会被更改。
总之，要首先从业务需求开始，而不是技术解决方案，要避免无端假设。
忽略噪音，作长远考虑
通常情况下，项目中的每个人都希望尽快开始行动来创建软件，他们希望尽可能快地开发和完成软件，并采取可能的每一条捷径。
这样的项目将尝试增加更多的开发人员进来，以使开发过程能够越来越快。
这是在头痛医脚，治标不治本，没有针对根本原因。我们看到的症状是项目有所延迟，但原因是什么呢？要知道，今天短视的解决方案，就是明天的长期问题。
快速创建软件是创建低质量代码、错误和技术债务的秘诀。开始的看起来很快，然后技术债务出现，会减慢一切，问题就会出现。
你走得越快，你制造的混乱就越多，它不是创建高质量软件所需的环境。
软件开发是一个失败者的游戏，创造最少问题的开发团队将会成功。如果你避免犯错，那么你就会稳步前进。
好的软件开发团队拒绝走捷径，不要恐慌，要长远考虑，以质量为目标。
软件开发中的最佳决策具有长期利益而非即时利益。
永远不要在没有签署需求的情况下开发
控制需求并就需求的工作方式达成一致至关重要。
必须有需求才能开发，项目需要纪律来只关注那些需要的东西。
这需要业务领导的指导，让用户只包括必须有的需求。需求越多，项目花费的时间就越长，软件也就越复杂。
如果用户没有被告知采用这种方法，他们就会像糖果店里的孩子一样，开始寻求让他们的生活更轻松（但需要更长的时间来创建）的功能。
如果需求发生变化，计划就必须改变。
额外的需求意味着更多的工作，项目计划将需要适应这些额外的工作。开发团队需要避免在项目计划不做出改变的情况加添加需求。
这对开发团队来说是一个双赢的局面，他们会错过最后期限并指责延迟交付。项目不晚，还有更多要求。
质量才是创建软件的捷径
软件开发被误解了，质量才是将代码投入生产的最快方式。非开发人员会认为，尽可能快地创建软件，走捷径并尽可能多地补充开发人员是创建软件的最快方式。
质量才是发展的捷径，质量意味着复杂性、技术债务、错误的降低，以及良好的变更管理。
软件开发就像一场马拉松，它应该始终朝着目标平稳前进。
质量很关键，很重要，因为软件开发中经常会出错，计划会出错，设计会变化，代码会发现错误，软件会出现问题，各种事都会出错。
质量需要建立标准，并使用代码审查、自动化规则来确保这些规则被执行。要知道，修复技术债务的最佳时机，是在把它放进代码之前。
保持环境同步——仅在开发环境中进行更改
开发中，有一件重要的事，就是保持环境同步，要尽可能多地在非生产环境中发现问题。
在非生产环境中发现问题是让人不爽的，你需要浪费几个小时或几天的时间，但可以冷静地解决它们。
在生产环境发现问题则令人恐慌，往往意味着紧急会议、夜间或周末加班工作，而参与解决问题的人越多，往往更难解决问题。
在开发环境中发现问题，仅仅意味着该过程正在运行。
如果你的环境不能同步，就需要在与生产环境不同的环境上进行测试，而投产将是你第一次在生产配置上测试代码，也导致第一次发现错误是在生产上。
将知识保存在文档中，而不是保存在人或本地机器中
标准、流程和文档为复杂的软件创建过程带来了秩序。
如果您不创建秩序，那么您将变得混乱，开发团队也将失去对项目的控制。
流程和文档会带来秩序，项目中的每个人都因而知道他们应该做什么，以及什么时候应该做。
良好的开发人员文档意味着开发人员可以离开项目，但仍然是每个人都知道该怎么做。
避免灾难——没有信任，一切都结束了
避免愚蠢和灾难比尝试创建出色的软件更容易做到，要确保您避免灾难并留在游戏之中。
如果你能避免问题、灾难和其它可怕的事情，那么开发团队就会稳步前进。而只要您继续前进，您就会越来越接近创建所需软件的目标。
软件项目中可能出错的事情终将在某个时候出错，无论您采取什么步骤，您都无法避免所有的问题。
你无法避免技术灾难，但它们不应该让你措手不及——什么！
你没看错，我告诉你要避免灾难，然后说这是不可能的。您需要确保采用最佳实践，以便在出现问题时能够快速恢复。
就像 Azure 服务器的工作方式一样，它们知道阻止服务器崩溃是不可能的，因此它们恢复得如此之快，以致于没有人会注意到。
在软件项目中，您应该把所有东西放在源代码控制和 DevOps 中，以便您可以在数小时内恢复环境。
您还应该能够在数小时内修复该代码并将其部署到生产环境中。
如果开发团队遇到越来越多的问题，尤其是生产问题，那么信心就会流失，信任就会丧失。
如果对开发团队失去信心，就像他们处在失控之中，那么业务将停止倾听他们的意见，项目最终将陷入停顿。
把所有能够自动化的事情都自动化
任何超过 3 个月的软件项目都应该使用 DevOps 和自动化部署。手动部署很无聊，容易出错，并且会失去创造软件的乐趣。
熟练的软件开发者不应该去做那些可以通过写些代码或做些配置就能让DevOps来做的事情。
将部署自动化并建立快速的反馈，如果部署总是很困难，就无法经常进行。
