# 好的软件工程应该什么样？
在过去的一段时间，以SCRUM为代表的敏捷开发模式被视为软件工程终极奥义，但是近几年却又逐渐被放弃。这是因为敏捷开发模式存在固有弊病。我对此提出了一些新的设想。设想在敏捷开发的思想基础（如价值交付、强化沟通、推迟承诺等）上增加一些改进。以下是一则备忘录。
1. 非普适的组织结构。组织结构不应当照本宣科，应当按照实际团队情况决定。譬如，在缺少产品经理人选的情况下，取消产品经理职位并拆分责任，而不是硬要指定一个不够称职的产品经理。
2. 精确的计划、抵抗变化。对外敏捷，对内瀑布。一旦一个计划做出，就尽量避免需求规格等的修改。
3. 强调个人能力和效率工具。工程师的个人能力是决定效率的第一要素，效率工具是提高效率的重要手段。效率工具包括ci/cd、经过精心设计的在线api文档等。
4. 加强沟通。敏捷强调站会和工作透明，但忽视了看起来不那么透明的点对点沟通。应当也鼓励去中心化的点对点沟通，打击站会形式主义。实际上，甚至可以取消站会来换取更好的沟通氛围。
5. 需求梳理方面，创立严格的、稳定的、详细文档。需求文档如需求规格说明书等，必须比代码更严格、更稳定。
6. 减少迭代，仅在必要时发布，要求基线尽可能稳定。尽量避免发布携带缺陷的软件，这会导致灾难性的质量问题，并对未来的兼容提出挑战。
7. 宽松的工作氛围，舒适的工作环境。SM是团队中必须存在的角色，他应当尽可能地保护团队免遭任何不利因素的影响，无论是网速还是工作餐都做到舒适。
8. 允许任何成员在征得团队同意后施展创意，团队应当在风险不大的前提下尽可能支持创意。鼓励应用新技术，鼓励发挥个人创意，鼓励开发团队发展个人项目。
9. 尽量保持技术栈稳定，并在不得不破坏技术栈时重构仍在迭代的系统。大的技术栈改变（如开发框架从Spring换成Gin）应当触发所有仍在迭代的系统的立即重构，保证活跃项目的技术栈的统一。
10. 取消sprint，针对每个人设置开发周期。配合弹性工作制保障个人自由空间。开发进度依靠高效沟通和周密计划实现。
11. 广泛应用切面，组织强力的基础设施建设。在团队内部广泛应用面向切面编程，组织基础设施建设以统一服务架构、分离业务逻辑，本质上是解耦和复用。