敏捷宣言有四行。 本文重点介绍最后一个：

　　响应计划变更

　　—敏捷宣言

　　防止过多的计划。

　　计划软件项目很困难。 我们每个人都想知道他们会成功就启动项目，但是我们如何确定呢？

　　客户是否真的想要此产品或功能？ 我们可以在需要的时候生产产品吗？ 如果计划合理，我们可以预见产品中是否存在技术复杂性？ 我们完成交易时市场会发生变化吗？

　　一些企业尝试在开始一个项目之前回答所有这些问题，所以他们不会将开发时间浪费在注定要失败的项目上。

　　但是许多企业未能意识到要进行多少计划取决于项目：

　　· 您的开发团队可以多快发布一些内容并获得客户的反馈？

　　· 您从客户和产品中获得了多少现有反馈？

　　· 如果您发布不良产品，将会有多大损害？

　　· 发布后，您如何衡量客户参与度？

　　尽管每个项目都进行了上述更改，但许多公司仍对每个项目遵循相同的计划模式。 这意味着不可避免地有些项目计划太多，而另一些项目则不够。

　　为什么计划有时是一件坏事？

　　· 计划延迟了MVP的交付，市场可能会继续发展-您可能会错过窗口，竞争对手的产品可能会在交付之前抢占您的市场份额（延迟上市时间）。

　　· 规划可能会浪费时间讨论在实际实施时可能不相关的事情。

　　· 规划会延迟来自真实用户的真实反馈，这比猜测他们想要的东西重要得多。 （提前发布，经常发布）

　　· 计划可以引起沉没成本谬误。 您花在制定计划上的时间越多，说服企业更改或放弃计划就越困难。

　　· 规划使业务分散了数据驱动力。 数据驱动的决策涉及交付功能，然后检查数据是否参与。 用户是否按预期使用此功能？ 他们喜欢吗？ 他们在要求令人惊讶的事情吗？ 如果您的决策过程与项目前的计划密切相关，那么用于项目中期分析的资源将更少。

　　一些计划仍然不错：

　　· 市场研究仍然是一个好主意。 如果您不检查竞争对手的产品，则可能会打造出并非唯一但已经落后的产品。 就是说，许多企业已经开发出落后于市场的产品，但最终仍会保持领先地位。因此请注意，您的计划不会消除您的创新。

　　· 有时，最好勾勒出您要构建的系统的轮廓，并充实组件。 但是，在启动项目的过程中，开发团队通常可以自己完成此操作。 此外，这有过度设计的危险，而不是试图尽快使MVP失效的危险。 考虑12-18个月的项目时，容易想到您需要额外的组件和抽象层，而这正是我们在敏捷交付中应避免的思维方式。

　　· 您业务中的某些部分可能需要排队，例如准备市场发布，广告活动。 这将在很大程度上取决于您的业务类型。 我的建议是尽可能地使这些部门脱钩，以便软件开发可以敏捷，并且您不会在项目开始之前就开始同意时间表和截止日期。一旦项目开始，就使用基于数据的预测（而不是直觉）。 项目已经开始，您有关于速度和范围的硬数据。 执行实验：假设项目出错了，只要您认为需要花费4倍的时间，甚至中途放弃，这将如何迫使其余业务发生变化？ 通常，您可以采取一些措施来保护业务，而不是在多年的路线图和联合交付中将部门捆绑在一起（这不可避免地会失败）。

　　另请参阅本文，以了解关于为什么某些项目不适合敏捷的替代观点：敏捷宣言的批判性观点

　　拥抱不确定性和变化

　　如果您要少做计划，则必须拥抱不确定性和变化。 这意味着您对今天的项目的任何想法明天都可能完全错误。 可以说，即使您做了很多计划，这仍然适用。

　　实际上，拥抱不确定性意味着：

　　· 您的公司应该准备非常迅速地改变方向。 如果某人在项目的中间有一个更好的主意，那么企业应该能够立即适应并改变以实现。 不要仅仅因为项目开始后就拥有了好主意而忽略了好主意！ 您是否曾经想过"等一下，如果我们只是……"会更简单吗？ 这些认识不应引起下沉的感觉，"哦，不，这个项目浪费时间"。 而是"我有个好主意，下一步我们可以做什么！"

　　· 您的公司应该准备完全取消/放弃项目。 您的企业是否曾经取消过项目？ 还是当每个人都知道自己在浪费时间时才继续进行项目？ 如果您是敏捷的人，则应该谦虚，不要指望客户想要什么，无论您建造什么，都可能浪费时间。 每当您收到反馈时，这都是有价值的信息-现在该信息业务将如何处理？ 像以前一样继续，还是改变？ 真正敏捷的公司应该尽快发布MVP，然后立即问：MVP成功了吗？ 我们还有更好的工作要做吗？ 我们应该取消这个项目吗？ 您做的计划越少，建立MVP的速度就越快，则取消项目时浪费的钱就越少。

　　· 您的企业将需要对产品使用情况的数据收集进行投资，以便在MVP交付后，您可以分析客户使用情况，以确定下一步要在项目中做什么以及是否取消它。 文化转变是从前期计划到中期项目数据分析。

　　· 产品所有者和设计师将需要与开发团队更紧密地合作。 在瀑布式世界中，您可能有一个设计/产品团队来创建设计文档，这些文档可能会在技术领导者的陪同下进行反复尝试，以设计出可行且有用的内容。 在敏捷世界中，发布MVP后，您的开发团队可能需要设计师在转向新方向后非常快地设计新功能。 一些公司通过拥有跨职能的团队并将产品所有者和设计师嵌入团队内部来完全拥抱这一点。

　　接受您将运送原型和技术债务

　　制作快速，易受攻击的MVP产品的危险在于，其中可能包含快捷键，低质量的代码和技术欠债。 对于开发团队之外的人来说，很难理解有漏洞的MVP可能是一种一次性解决方案，并且可能需要进行一些重写才能长期安全和稳定。

　　通常应故意和战术上承担技术债务，以便更快地释放给客户。 例如，如果您有机会放弃该项目并删除所有代码，则可能不值得花时间将其完善后再发布。

　　停止按文档发出订单

　　向开发团队内部传递信息的最有效方法是面对面的交谈。 —敏捷原则

　　有时，预先计划会导致将设计文档"全部"扔给开发团队。 这是一种极其缓慢且效率低下的通信方式。 您是否曾经通过电子邮件引用文档而对文档注释中或更糟的内容进行了长期辩论？ （几天甚至几周？）

　　最糟糕的辩论是所涉及的两方根本不了解另一方的思维方式，并且似乎在谈论完全不同的波长—例如，一个人想要一个较低的要求，而另一个人则认为该项目是 浪费时间。 通过在流程的早期和项目期间定期进行合作来阻止这种情况的发生：

　　在整个项目中，业务人员和开发人员必须每天一起工作。 —敏捷原则

　　通过面对面的讨论，通常可以更快地解决这些讨论，同时建立人际关系通常是成功项目的基础。

　　通常，开发团队需要知道的不是开始在设计文档中找到的项目，并且在项目中间需要回答的问题通常过于具体，无法在文档中回答，因此文档是 在开始时过于投机，在整个项目中过于模糊/过时。

　　更好的方法是召开面对面的会议以启动项目，然后在项目本身进行频繁的会议。 响应变化，不遵循计划！

　　从一开始就让开发人员参与进来，激励他们

　　围绕有积极性的人建立项目。

　　最佳的体系结构，要求和设计来自自组织团队。

　　—敏捷原则

　　激励开发团队的一种简单方法是：给他们一大堆设计文档，然后说"构建此文档。 12个月后见。"

　　成功的开发团队不会像外包的"编写此代码"团队那样工作，而是要竞标未来的全能大师。 成功的开发团队通常从一开始就参与项目计划，他们会感到对整个项目的所有权感，而不仅仅是代码。 项目开始时的开发应该与探索需求，技术风险以及找出客户是否想要您的产品有关。

　　不要猜测项目何时完成

　　项目开始是猜测何时完成的最坏时间。 为什么？ 因为那是您最不了解的时候！ 您没有数据。

　　例外：如果您的团队已经完成了多个先前的项目，并且这些项目足够相似，那么有时您可以使用该数据进行一些预先的预测。 关键是（a）以数据为依据，不要（b）给出一个日期范围而不是一个日期（c）该日期范围应足够宽，以使项目中的数据缩小而不是扩大

　　不用猜测，您应该使用数据来计算几次冲刺（约4-6周）后的投影范围，然后应该定期更新投影。 如果您使用的是项目管理工具，那么通常可以自动进行。

　　注意：您必须注意项目的积压范围。 如果待办事项的增长速度快于完成工作的速度，那么您将无法在项目结束时进行计划。

　　如果您看到结束日期越来越远，那么这是个停止，分析项目并讨论原因的好时机。 你的速度下降了吗？ 您承担过多的技术债务吗？ 您的范围在增加吗？ 是否添加了太多功能？

　　对于企业而言，可预测性通常比速度更重要。

　　警告：每家公司都不一样

　　软件领域极为广泛且正在发展。 并非所有公司和项目都应使用相同的做法。 例如，一家资金有限的新创公司可能会更多地专注于在产品用尽之前快速尝试不同的产品。 一个成熟的公司可能会更专注于保留现有客户，并且可能更不愿意推出低质量或实验性的代码。

　　一些公司，尤其是那些构建大型企业软件的公司，可能会限制于他们从客户那里获得反馈的速度。 如果客户需要2年的时间才能使用您的软件，那么很难获得快速的反馈！ 在这种情况下，获得客户的"赞助人"以在整个项目中进行合作，或者组织远程用户测试/演示会议是很有用的，在这些会议中，您可以要求客户在软件还在开发中时使用它。

　　业务不应简单地从他人那里复制敏捷实践。 相反，他们应该尝试理解创建敏捷宣言的原因，以便可以将其与自己的业务联系起来并进行相应的调整。 明智地决定要做多少计划由您决定！