规划动力——重构软件开发中的计划流程
对于许多工程师而言，计划代表着与我们热爱的软件构建工作的对立面。我们热衷于探索新问题、研究和设计解决方案、并交付我们引以为豪的代码。但一个僵化或不切实际的计划，就像一桶冷水，将我们从纯粹的工程梦想中浇醒，投入到充斥着令人头痛的甘特图、每周检查、不可预见的障碍和错过截止日期的残酷世界中。
计划和估算确实很难。毕竟，每个项目和功能都代表着你从未构建过的东西，而软件开发固有的复杂性意味着总会有意外——不是你生日时想要的那种惊喜。这就是为什么敏捷等迭代式软件开发方法专注于持续地、以小增量的方式交付工作，以便团队能够适应意外情况。
然而，即使是分成小块进行计划也有其挑战。我们都经历过因为一张原定一小时的工单花了一整周完成而导致的冲刺“爆炸”。那么，为什么不干脆停止估算呢？在 Twitter 上流行的 #NoEstimates 运动对计划和估算提出了激进的观点，建议工程师们与其花时间计算需求文档中的每一项期望功能，不如直接挑选最高优先级的项目，将其分解为组成部分，并尽快交付。
鉴于计划被许多人认为充满问题、过时且会引发冷汗，有些人可能认为是时候将正式计划送入历史了。但是，如果我们能够将计划重新构想为一个生成性的过程，而非限制性的过程呢？
焦点的转变
我认为计划背负了坏名声。它们已与截止日期压力、武断的僵化和不惜一切代价的执行画上了等号。太多时候，它们仅仅是一层薄薄的饰面，掩盖了我们工作中不完美且在某种程度上不可知的现实。但如果我们承认计划无法消除不确定性，我们就能利用其真正的潜力。
最佳状态下的计划，并非关乎无休止的截止日期和僵化的绩效指导方针。它们是关于创造动力的。 它们为新产品和功能注入活力，并使团队围绕一个共同目标保持一致。当以这种思路来制定时，它们能让“我们现在何处”与“我们想去何方”之间的距离显得更容易跨越。
想象一下预订假期时体验到的可能性和兴奋感。你会因为规划开车去机场而兴奋吗？制定分秒不差的行程表能带来平静和放松的感觉吗？可能不会。你可能会发现，专注于更大的图景——你要去哪里，你要做什么——要愉快得多。牢记你的计划可能会改变——你无法预测徒步旅行是否会因雨取消，或者水上乐园是否会关闭——你已经准备好去适应。
同样，如果我们放弃计划包含所有答案的想法，我们就能承认计划的剧烈变化并不意味着我们失败了。这只是意味着找到另一条前进的道路。用赫拉克利特的话来哲学化地表述：变化是生命中唯一的不变。
此外，接受计划可以并且将会改变，可能带来更好的结果。延续我们的假期类比，想象一下你发现了一条未曾计划参观的、令人叹为观止的徒步小径。改变你的计划可能会带来旅途中最好的一天。现在，想象一下你通过早期用户测试发现，你的解决方案在仅仅几周的工作后就满足了客户的需求，而不是你预估的几个月。修订你的计划将使你能够自由地为用户解决其他问题，而不是花时间给现有解决方案添加多余的功能和装饰。
为思考而计划
计划是启动思考的绝佳方式。
我们作为软件工程师所创造的产品、功能和应用程序需要一些严肃的思考——而计划是启动思考的绝佳方式。
在2014年芝加哥大学的一次演讲中，该校写作项目前著名主任拉里·麦克埃纳尼建议，在复杂领域工作的人不应该试图在脑中解决整个问题然后实施解决方案。相反，他们应该首先把想法写下来。他说，写作过程使我们能够充分表达和精炼我们的想法和提出的解决方案。当它们在纸面上具体化时，我们可以继续反思和迭代。
计划，就像写作一样，会产生有形的成果物。 例如，你可以为代码库中所有非微不足道的增补（如新功能、架构和功能变更）创建设计文档。设计文档是一种结构化模板，它允许你规划解决手头问题的方法，同时也为未来的工程师提供一份解释系统某部分为何以某种方式构建的资源。它促使你在编写代码之前，预先提出并回答关键问题：这个新功能做什么，它在系统中的位置在哪里？它需要什么上下文，它应该与相邻组件有什么契约？你瞄准的规模是多大？
这些书面成果物——你的计划——可以采取多种形式。你可以为新技术功能的技术方向创建一个简短的想法文档，或者为你新的旗舰产品撰写一份愿景声明，勾勒出你希望构建的功能。你可以制作一份遵循正式结构的设计文档。形式不如其功能重要：详细阐述你的想法、生成一份记录以征求反馈，并使你的计划能够随着时间演变。而它们确实应该演变。
更快地失败
没有完美的计划。你最初的架构可能存在未预见的缺陷，或者在规模化摄取数据时可能遇到意外的性能瓶颈。也许你公司的另一个团队正在努力解决同一个问题，而你们联合力量协作解决一个方案会更好。
分享你的计划可以让你梳理出那些未知因素，并更快地识别和解决问题。通过创建一个计划文档并征求你的团队、项目相关方和关键资深工程师的意见，你正在向新的想法和观点敞开自己，并邀请他人找出你计划中的漏洞。这可能会让人感到不适，但实际上这很棒——它让你有机会在投入时间和精力编写代码之前修补你的计划。
随着每一层反馈，你的计划将变得更加严密，你也会增加对你方案的认同度。你可以在实施变更成本高昂之前做出更改，最终的功能将更适合其目的。考虑一下另一种情况：如果你不征求反馈，你可能只在代码审查时才发现一个弱点——例如，某些边缘情况下的安全漏洞——此时你将不得不回到起点并重写该功能。你将错过一个快速且低阻力失败的绝佳机会。与瀑布时代那些僵化的蓝图截然相反，你的计划可以成为敏捷开发的工具，而不是障碍。
为推进而计划
当我们将计划理解为创造动力的工具时，它们能提供方向感。
当我们将计划理解为创造动力的工具，而不是一套僵化且有时令人窒息的参数时，它们可以提供方向感，并使我们在共同目标上保持一致。敏捷的核心是协作和持续迭代，计划也可以如此。我们不需要为了开始协作而编写代码；我们可以通过撰写文字和绘制图表来澄清我们的愿景，并在构建过程中不断完善它。
下次你开始规划一个新功能、架构或重构时，写一份设计文档或愿景声明，看看它如何帮助锐化你的想法。与你的同事分享以获得他们的反馈。修补合作者慷慨指出的漏洞，并不断朝着你愿景中最清晰版本迈进。让它成为一个不断演变的计划的燃料，推动你的团队前进。