在规划软件项目方面失败(和获胜)
当谈到在宏观层面上计划软件项目时，有两个极端--试图预先计划所有事情，或者接受不可能做到这一点而根本不去计划任何事情。虽然大多数团队会发现自己处于这两者之间的某个位置，但更详细地观察他们仍然是值得的。
从历史上看，在一个以瀑布为基础的世界里，过度规划被广泛使用。这种方法背后的想法是预先对项目的整体进行非常详细的计划，将计划投射到一个时间表上，然后执行它。实践过度计划的团队会写出详细的规范，描述项目的各个方面。然后，他们会将规范分解成一些积压的小任务，以某种方式估计积压的任务，并推断项目将需要多长时间；最终会得出这样的声明：我们可以在67周内构建出587页长的规范中所描述的社交网络先行者，总共将花费134百万英镑。欧元&34；。
正如我们现在都知道的，这几乎从来没有像计划的那样奏效，错过了最后期限，预算超支--无数的例子都表明了这一点。
这种方法的相反之处是，只做很少的前期计划，或者根本不做任何前期计划，然后就这样逃之夭夭。虽然这消除了开发团队(特别是设计师和工程师)的很大压力，但其他利益相关者在项目进展的可预测性和洞察力方面有合法需求的人却被冷落了。营销团队将不知道何时在当地动物园预订广告牌，产品专家也无法与一群样本大象建立用户测试会议，因为他们不知道他们何时能够测试哪些功能，或者是否会有一套连贯的功能，甚至在任何时候作为一个单元都是有意义的。
实际上，没有一个团队(至少我见过🤞)严格执行这两个极端中的任何一个。幸运的是，经典的瀑布模型现在已经成为过去，让一个团队毫无计划地逃跑的缺点非常明显，以至于任何人都有足够的勇气(或天真)去尝试它。事实上，按照敏捷流程迭代开发产品(不管这个术语对任何特定团队来说可能是什么意思)现在是一种被广泛接受的技术。这样，迭代的范围、复杂性和风险就大大减少了(通常被称为冲刺--我认为这是一个可怕的术语，但这本身就是一篇博客文章)，变得更容易管理了。(我认为这是一个可怕的术语，但这本身就是一篇博客文章)。这是一种被广泛接受的技术，因此它的范围和复杂性和风险都大大减少了(通常被称为Sprint-34；这个术语，我认为这是一个可怕的术语，但这本身就是一篇博客文章)。然后，所有的计划都是基于对相对较小的任务的估计(例如使用故事点)，以及基于这些估计的生产力度量(团队的速度)。
然而，在现实中，采用敏捷、迭代的过程(无论是Scrum、团队自己的解释还是完全不同的东西)都不会神奇地解决所有上述问题。团队仍将面临预算超支，即使考虑到两周迭代的短时间范围，也不能给出可靠的估计。意想不到的和计划外的-因为复杂性和挑战只有在任务开始后才会被发现，许多任务将意外地跨越多个印记，即使在启动MVP之前，已经完成的功能也必须定期进行删除和更改。
将计划从使用经典瀑布方法的宏观层次转移到迭代的微观层次之后，该层次也是问题转移到的地方。
在迭代的微观层面上进行计划意味着确定范围、捆绑和评估具体的、可操作的工作单元。这些单元有数不清的名称，它们取决于所使用的特定过程或工具，但在现实中，无论您将它们称为问题、(用户)故事还是待办事项，无论您是否将它们组织成具有多层子任务和/或总体史诗的树-它们是一个或几个团队成员可以处理并完成的任务，理想情况下是在相对较短的时间内(比如最多几天)。任务包定义了迭代的范围，这也是我们在微观层面重新规划的。
Basecamp是一家自力更生的公司，创建了一个非常成功的项目管理SaaS，同名公司Basecamp背后的团队有一句非常受欢迎的话：
Basecamp在他们的畅销书“返工”中更详细地解释了这个想法。这句话很棒，但也被广泛误解了。它的意思是，任何超出相当小的范围的事情本质上都是不可计划的，任何人制定的任何计划，本质上都只不过是一种猜测。正如上面解释的那样，在宏观层面上这是非常正确的，因为范围和复杂性太大了，任何人都无法完全掌握。然而，引用并不意味着，当范围有限时，您永远不能准备和预先评估任何工作--这是在迭代的微观级别上的事实。
然而，许多项目团队以计划是猜测为借口，根本拒绝做任何彻底的前期分析或任务准备。即使团队在开始工作之前花费时间准备工作，这种准备往往只是表面上的，留下了很多不确定性和风险，只有在任务工作开始之后才能发现。理解任何任务的全面性和多愁善感，当然需要积极地工作，并且实际上需要完成这项任务。然而，分析任务以发现隐藏的复杂性、依赖性和影响是很有可能的-不仅从工程角度，而且从其他利益相关者的角度，如设计、产品、营销等。
透彻地分析和准备任务将有助于理解任务的范围，确定需要在之前或不适当地完成的相关工作，或相互权衡替代实施方案以及对照其他优先事项。所有这些都减少了与任务相关的不确定性，即使你不能完全消除所有不确定性，但消除很大一部分或大部分不确定性会显著提高估计的可靠性，并最大限度地减少计划外工作，而这些工作通常是在工作开始后才会遇到不可预见的复杂情况时才需要做的。
要做好微观层面的规划，必须做好周密的准备工作。我将介绍四个关键技术，它们是有效准备任务所必需的，而且SIMPLABS已经成功地实践了多年。
首先，让我们来看看产品团队通常开展的工作是从哪里开始的。在大多数情况下，或多或少只有两个来源-由产品团队定义的特性故事和由工程团队驱动的技术更改(如分解)。理想情况下，这两种工作都等同于任务，尽管在许多情况下纯技术工作并非如此。因为这项工作无论如何都会发生，不把它表示为单独的任务是一个很大的错误，并导致正在发生的工作的一部分并不是所有的利益相关者都能看到的，因为随之而来的是所有负面的序列。
因此，让我们假设项目中发生的所有工作都等同地表示为任务。尽管如此，在许多情况下，利益相关者只会定义他们自己的任务，而不会从彼此那里获得太多信息。然后，每个涉众都会推动在特定迭代中计划他们的任务。不过，这不是有效的协作方式，通常也不符合项目成功的最佳利益。一个成功的项目需要考虑到所有利益相关者的个人观点和优先事项。毕竟，既不是只关注功能而放弃产品的长期可维护性和可扩展性等技术方面，也不是重构代码以实现完美，而只是交付得太少太晚，都不会导致业务的成功。
成功的团队公开而直接地沟通，并密切合作。虽然这可能听起来像是一个显而易见的声明，但实际上往往有很多需要改进的地方。许多团队在利益相关者之间筑起一堵墙，而他们实际上都必须协作-从产品专家到工程和设计，但也包括营销、财务和其他潜在的领域。这种合作始于就应该以什么顺序和深度做什么工作达成一致。通过消除不必要的复杂性或防止团队速度的长期下降，有一个适当的协作过程使整个开发过程更加有效。
例如，在许多情况下，将会有不同的方式来实现产品专家想要添加的特定功能，并且相关开发复杂性的级别会有很大的不同。通常，从产品的角度来看，选择这些替代方案中的哪一个并不重要，及早发现可以为设计师和工程师节省大量的时间和精力。在其他情况下，工程团队可能会看到特定重构的必要性，但可能会有营销团队必须履行的相互冲突的承诺，这证明将重构推迟到以后的迭代是合理的。在其他情况下，从用户的角度来看，重构可能对产品有很大的积极影响，这将导致所有利益相关者对该承诺的支持。只有通过沟通和协作才能发现所有这些情况，不仅是在进行工作时，而且在确定范围和计划工作时也是如此。再说一次，尽管这看起来很明显，但许多团队都在为不开放的后果而苦苦挣扎。
在我们的项目中，我们利用迭代领导角色。迭代负责人负责识别、确定范围和准备在特定迭代中计划发生的所有工作。他们将从所有涉众那里收集输入，为每个请求准备适当的任务(下面详细介绍什么是适当的任务)，确定任务的优先顺序，并在开始迭代之前将结果呈现给产品团队。当然，迭代负责人不可能拥有每个涉众拥有的关于其领域的所有详细知识，而且他们也不应该拥有-他们将联系各自的专家，将人们聚集在一起，并确保进行沟通。
迭代领导角色并不固定于产品团队的特定成员，而是设置为整个团队的轮换角色-每隔一次迭代，该角色就会转移到一个新的团队成员，这样每个产品或营销专家、设计师或工程师都会定期担任该角色。在整个团队中轮换角色是一种很好的方式，可以确保人们理解和欣赏每个利益相关者的观点，而不是只停留在他们自己的观点上。这种欣赏不仅有益于团队精神，还能极大地改善我们经验中的协作。我们甚至根本不与项目经理一起工作，而是依赖于迭代领导角色。事实上，我们认为项目经理这个角色--至少在它的经典形象中，是一个领导产品团队的人--是一种组织反模式，通常只有在团队核心真正失灵的情况下才是必要的。
如上所述，许多团队将准备和维护一个广泛的Backlog，其中填满了任何人曾经提出过的或期望最终需要特定项目的所有任务。这似乎是一个好主意，为了更完整地理解项目的整体，在迭代过程中，唯一重要的工作是团队当前正在做什么，以及正在为下一次迭代做什么准备和计划。其他的一切都可以安全地忽略，因为我们完全不知道将来会以什么方式来处理某个特定的任务，或者它是否会被完全忽略。每个人都看到过有大量积压的项目，这似乎意味着还有很多工作需要完成，而每个人都知道，90%的任务可能永远不会被承担，而75%的任务已经过时了(这些都是虚构的数字，只有我的个人经验✌️支持)。
积极地保持积压工作通常只是浪费时间。这不仅适用于功能任务，也适用于错误报告--过去六个月没有解决的错误不太可能在接下来的六个月内得到解决。同时，它也不太可能与任何人真正相关，因此不太可能完全解决(除非它是作为底层功能更改的结果自动解决的)。
一旦从项目涉众处获得工作资源，就需要很好地理解它并确定其范围。为了全面了解任务的整体情况，防止团队在工作开始后遇到不可预见的问题，这是至关重要的一步。当然，不可能总是完全避免以后可能出现的所有问题，但是越早发现和解决的问题越多，完成每项任务就越顺利。
首先，必须满足一项任务的所有前提条件，然后才能进行工作。这可能包括设计准备就绪或用户测试已经进行和分析。这也可能意味着已经与外部提供商签署了合同，或者已经预订了营销活动。与前提条件同样重要的是任务的后果，这些后果可以是技术性的，但也与功能或设计有关-可能是技术上的改变
一些团队正在采用全面的RFC流程来确定和定义工作的范围，就像这样。在RFC过程中，有人或一群人会写一份文件，相对详细地解释预期的变化，然后要求所有受影响的利益相关者(或实际上是任何人)提供反馈，直到达成共识，RFC准备好实施为止。虽然这可能会带来可能并不总是合理的手续和流程开销，但这通常是一个很好的方法，可以确保上述几点得到解决。通常，RFC过程可能越适合任务主题越广、团队规模越大的情况。对于较小的团队，直接在各自的工具中协作编辑任务可能就足够了。
正确准备任务的最后一步是将前面步骤中获得的所有信息写到所选的工具中。如上所述，什么工具无关紧要-好的任务共享一些独立于任何特定工具的共同特征：
它们描述了要做什么，以及为什么可能伴随着屏幕截图、模型/草图或其他有助于理解预期结果的视觉效果；添加任务历史摘要也是有益的，包括以前在确定任务范围的过程中排除的相关更改或替代方法，并提供这些决定的原因。
如果任务描述了错误，则它们包括再现步骤；理想情况下，这些步骤是用屏幕记录或其他媒体可视化的。
它们列出了为完成任务而必须采取的具体步骤(参见上面的范围界定和分析)。
它们包括任务所需的所有必要材料；这可以是可视资产、指向第三方库或API的在线文档的链接或涉及问题的外部方的联系详细信息等。
他们提到了任何需要回答的未决问题，或者已经确定但无法预先解决的风险，这些风险可能会阻碍任务的完成。
它们是一个离散的工作单元；任务应该只包含相关的要求，理想情况下不能超过几天的工作量--大的任务通常可以被分解成多个较小的任务，甚至可能允许工作同时进行。
一项准备充分的任务将使产品团队中任何在各自领域都是专家的成员都能够承担并完成任务。然而，任务不仅是为将要处理任务的团队成员编写的，也是为对项目感兴趣并需要随时知道正在进行什么的任何其他涉众编写的-无论是在任务被积极计划或正在工作的时候，还是稍后试图理解为什么要做一些事情的时候，当时的意图和考虑是什么等等，都是为他们编写的，这些人都对项目感兴趣，需要随时知道正在进行的事情--无论是在任务被积极计划或正在进行的时候，还是在以后试图理解为什么要做一些事情的时候，以及当时的意图和考虑因素等等。
团队之所以不成功，是因为他们采用了特定的流程(甚至有可能让自己获得认证)，或者采用了最新最棒的项目管理工具。成功主要是通过相对简单的值来实现的：
在任务开始工作之前，在任务级别识别和解决尽可能多的不确定性并发现尽可能多的隐藏复杂性。
在计划和执行迭代时忽略所有已知不相关的工作。
彻底地完成所有这些都需要一点额外的时间(迭代领导每周很容易被占用几天时间，除此之外，每个主题的预期专家都会投入他们的意见)。然而，由于效率的大大提高，以及确定性和可计划性的提高，这段时间得到了成倍的回报。
我们已经将这篇文章中介绍的所有价值观和技巧更详细地写在了我们的手册中，并欢迎每个人改编这些模式，并与我们分享他们的经验和反馈。
