敏捷项目管理的终极介绍

简要

您负责提供贵公司最新和最伟大的计划，这将永远改变“Widgets International”的面貌。 这是一个软件项目，它将吸引和吸引您的客户，让您的同事的生活更轻松，并使公司获得数百万美元的收入。 有很多期待，热情，兴奋和期待。 您需要尽快完成它，这样您的企业才能开始获得收益。 公司未来的成功取决于你。 所有的目光都集中在你身上。 你不能失败。

起初，你在想，“太棒了，我已经准备好迎接挑战了。 让我们把这件事做好！” 你停顿片刻，退后一步，对自己说：“好吧，那我们怎么做呢？” 您开始与您的同事和同行交谈。 您花时间寻找最佳实践软件开发和项目管理技术，但选项和方法是无数的。 有很多首字母缩略词和方法。 著名的上升到顶部。 怀疑蔓延。我们应该使用哪一个？ 如何保证成功？ 如果我做出错误的决定怎么办？

在管理软件项目时，有无数意见支持的选项组合令人兴奋。 房间角落里传来的声音在低语：“试试这个方法”； 其他人大喊：“这是唯一的方法”； 其余的只是呜咽，“根本不要管理它，继续它。” 实际上，所有这些声音都说了一些实话。 但重要的是找出适合您的需求、您的团队、您的业务和您的客户的方法。

设置场景

曾经有一段时间，软件项目管理完全属于三个阵营之一。 有一些繁重的框架可以让你决定如何执行和交付，同时提供一个结构来维持控制和治理。 有像瀑布这样的规定性顺序方法，迫使您计划冗长的项目，理解并满足您的所有需求，设计和签署复杂的系统，编写大量代码，然后进行测试（所有这些都在您的客户第一次看到它之前）时间）。 最后，较少规范但迭代的软件开发生命周期 (SDLC) 鼓励快速原型设计或更大的系统以增量步骤设计、构建和交付，每个构建在另一个之上。

敏捷软件开发和敏捷项目管理源于瀑布的不足和软件交付迭代方法的好处。 他们可以追溯到 1950 年代、70 年代的思想领导力、90 年代的成熟以及 00 年代的采用。 2001 年，一群从业者和专家创建了敏捷宣言，旨在定义 4 种价值观和 12 条指导原则，旨在体现敏捷软件开发的精神并鼓励其发展。 它肯定已经进化了。

现在，简单地调用敏捷并不是特别有用。 这个词，即使在软件环境中，对不同的人或组织也有不同的含义。 有许多方面、定义、实现和解释。 每个拥抱敏捷的机构都倾向于尝试给它自己的定义。

可以这么说，敏捷软件开发和项目管理是一组相关的行为、框架、技术和概念，它们从根本上支持尽可能早且尽可能频繁地交付正确的工作软件。

我之前提到过，应用于软件开发或项目管理的敏捷可以是不同的东西。 简而言之，敏捷软件开发负责在照常业务 (BAU) 或项目环境中开发出色的软件。 另一方面，敏捷项目管理负责交付复杂项目（包括但不限于软件）所需的治理和控制。

有许多可用的敏捷软件开发方法，例如 Scrum、看板、XP 和精益软件开发。 但正如橄榄球比赛不仅仅是 Scrum 一样，敏捷也是如此。 孤立地看，这些敏捷范式并没有解决复杂项目所需的项目管理的整个生命周期，例如治理、资源、财务、显式风险管理和许多其他重要的项目管理概念。 对于这些，您可能需要考虑 PMI 敏捷或 PRINCE2 敏捷——将其视为“治理敏捷”。

为什么我们需要敏捷？

很久以前，我们在这片土地上漫游以收集食物和住所以求生存。 它们是简单的需求，但非常灵活。 一段时间后，国家和经济体在工业革命的支持下发展壮大。 这就是管控的诞生和敏捷性的丧失。 现在我们处于信息时代或革命，企业雇佣知识工作者。 知识工作者是您、您的合作伙伴以及您的同事和同行，他们努力为客户、商业、社会、经济和世界问题创造出色的解决方案。 知识工作者将分析、知识、推理、理解、专业知识和技能应用于通常定义松散且不断变化的需求。 这些企业和工人需要旧工业时代流程和程序无法满足的方法和技术。 敏捷支持交互。

几乎没有一个软件项目可以自信地从一开始就开始并了解它所需要的一切，以便在不改变的情况下交付有价值的工作软件。 变革为项目的成功带来机遇和风险。 不受管理的机会可能意味着一家伟大的公司和一家很棒的公司之间的区别。 不受管理的风险意味着灾难和毁灭。 敏捷管理变革。

采用敏捷可以让您响应不断变化的或新的需求。 它使开发团队成为专家，并在参与、信任和知情的业务支持下做出决策。 它使您能够向客户提供他们真正想要的东西。 最终，它使您和您的组织能够控制交付高质量、有价值的软件，从而满足客户的需求和期望，同时尽早获得投资回报。 敏捷创造价值。

采用敏捷是有代价的。 它不是免费的。 转变为软件交付的敏捷方法可能是一条艰难的道路。 但是，如果您将敏捷哲学内化，谨慎行事，以正确的态度与正确的团队合作，分解事情，使其可实现和现实，并响应反馈，您将获得回报。 敏捷强调协作。

以下列出了您可以期待的一些好处：

• 上市速度
• 较早的创收
• 定期交付实际价值
• 保护您的投资
• 数据，数据，数据
• 更好的产品质量
• 可管理的期望
• 更高的客户满意度
• 更高绩效的团队
• 提高进度可见性
• 可预测性、透明度和信心
• 可控风险

成功不是最终的，失败也不是致命的：重要的是继续前进的勇气。

温斯顿丘吉尔可能从未真正说过这句话，但我认为这是对敏捷的一个很好的总结。 我们知道敏捷是大多数项目的最佳选择。 它鼓励您为成功而奋斗，但我们始终在迭代并不断发展。 敏捷会鼓励你失败，但尽早失败并继续前进。 有勇气继续并根据客户提供的洞察力构建正确的解决方案是带来回报的原因。

要记住的是，您可以根据自己的需求定制敏捷。 使用适合您业务的方法和治理。 无论你从哪里开始，都要忠于所用方法的内容、背景和精神——保持原样。 如果您刚刚开始，请学习. 如果您已经这样做了一段时间，请理解。 如果你变得很棒，请申请。 最后，如果您的业务和项目复杂且相互依赖，请治理. 随着时间的推移，您和您的团队将找出最适合您的业务的方法。

可行性

所以现在你在想，“好吧，我明白了。 我该如何开始？ 我从哪里开始？” 好吧，有了所有美好的事物，我们从头开始。 使用敏捷，就是问自己“我想提供什么商业价值？” 毕竟，这就是我们开展项目以产生商业价值的原因。 为了确定该项目是否值得进行以获得商业价值，您需要了解它是否可行。

想象

您的项目是否预计会增加收入、进入新市场、获得更多客户、提高客户认知度或让您发现的特定问题变得更轻松？ 考虑到这一点，您可以陈述您的“愿景”。

• 你的愿景可能来自不同的来源——你自己的大胆创业来解决一个常见问题、业务管理策略、你的 CEO 的宠物项目、特定的产品团队，甚至你的客户的需求。
• 试着从你自己的鞋子中退后一步，“看看”你的新产品或服务在你的客户手中的未来会是什么样子。
• 让您的利益相关者——CEO、产品人员和客户参与进来。 讨论它，不要孤立地尝试。 挑战假设并验证论点。
• 写下来，保持简短。 专注于商业价值。
• 完善它，直到你们都同意该愿景与每个人产生共鸣，并符合说明您前进方向的共同解释。
• 你的愿景，如果有效的话，很少改变。 你如何到达那里肯定会。

人们不会买你做什么，或者你怎么做。 他们购买“为什么”你这样做。 这就是在您的企业和客户之间建立情感联系的原因。 愿景将有助于说明这一点。

可行吗？

可行性至少有几个方面。 通常，您会想了解您对企业和客户更美好未来的愿景在技术上是否可行，并且对您的企业来说是否可行。

• 如果您的愿景是在一小时内到达世界任何地方，您可能会遇到技术可行性问题。 由于科学、物理和技术还没有完全赶上这个梦想，你的技术解决方案可能在理论上不可行。 此外，如果您的解决方案是新的，这将远远超出最小可行产品 (MVP) 的想法。

• 要测试您的产品的技术可行性，请考虑在 Discovery 原型项目中进一步探索它，或者在项目的早期阶段运行一个峰值。 通过考虑您所考虑的解决方案的规模或复杂性，您将知道使用哪种方法。

  “我的团队在理解技术可行性方面获得的一些最佳知识来自执行峰值。 通常，最简单的解决方案会胜出！”

• 要考虑的第二种可行性是您、您的团队或您的企业是否具有使其发挥作用的技能和动力。 举个例子，如果你很擅长在家里为你的孩子做生日蛋糕，那就太好了。 但是，如果您想将其转变为向世界销售最好的蛋糕的企业，您需要了解您是否可以使其规模化、处理业务和生产、管理分销和履行以及照顾客户服务。
• 从长远来看，这种愿景可能是可以实现的。 但就目前而言，可能不会。 因此，缩小规模，从小处着眼，取一小块看起来很现实的东西，并专注于实现尽可能小的愿望。 如果这设法吸引并取悦您的客户，让他们回来更多并告诉他们的朋友，然后使用您的客户反馈作为您的指南和指南针从那里扩大规模。
• 此外，您需要知道您的项目在预算和时间框架方面是否可行。 您的企业能否负担得起这个项目？ 时间表是否可以实现？ 时间和金钱是敏捷项目中固定的三个约束中的两个。 我们的目标是在给定的固定时间和给定的固定预算内交付。
• 产品的质量是指您的客户使用的最终产品以及您的团队用来交付出色、强大和可靠软件的工程实践。 质量也是我们不会改变的东西。 另一方面，质量标准可以改变。 如果您不打算制造法拉利，则该产品可能没有高质量的感知。 如果您不制造太空火箭，那么在生产方面达到的公差可能要高得多。 尽早设定适当的基调和期望。

所以现在你已经确认你的梦想不仅仅是巧克力幻想，开始测试你的假设并向人们证明这项努力是值得投资的。

理由

现在，根据你的情况，称义将以不同的形式出现。 但本质上，您想证明该项目将满足客户成功标准，有成功的机会，将提供价值，并且是负担得起的。

• 根据您的客户需求陈述您的假设，然后验证它们。 精益创业为识别和证明客户需要您的产品并将创造价值提供了很好的指导。

• 编写、测试和验证您的商业计划。 现在这看起来不像你的银行或你的商业和金融专业告诉你生产的那些。 不要使用它们——在墨水干之前它们就会过时。 相反，请查看商业模式画布。 这本质上是一个简短的商业计划，让您专注于您的价值主张、客户、收入和成本。 使用它来验证您是否有可以运作的业务。

  “我曾经忽略了这个建议，并花了很长时间编写一份冗长的传统 50 页商业计划。 它让我无处可去。 我所做的所有假设都是没有根据的，我所做的所有预测都无法验证。 这是一次痛苦而昂贵的经历，教会我再也不要这样做了。”

• 如果您从事成熟的业务，并且在复杂环境中交付项目组合，那么财务建模可能是必要的。 如果必须，请仅在您证明了上述内容后才执行此操作。
• 一旦你建立了你的 MVP，就有可能创建一个更传统的商业计划——例如，如果你必须在公司的竞争项目和资源组合中寻求资金或选择。 但这将是一个基于上述工具并由上述工具提供信息的商业计划。 也会轻一些。
• 在任何情况下，将这些工具用作活生生的、会呼吸的人工制品。 将它们用作您的指南和领头羊。 它们从来都不是静态的。 随着您的项目或业务的发展，参考并修改它们。

一旦你有你的理由并且你所有的利益相关者都在船上，你就会着火了。

可行性阶段通常在项目的生命周期中执行一次。 您可能会发现您重新审视了项目的愿景和可行性，尤其是在您的数据、客户、市场或业务表明如此的情况下。 至少，它们将成为您的指路明灯。

引发

惊人的。 决定已经做出，项目获得了绿灯，您可以开始构建了。 嗯，差不多。 我知道你在想，“来吧，真的吗？ 如果我们现在不这样做，我们永远不会这样做。 让我们在路上看到这个节目！” 但请考虑这一点——如果不是尽早交付价值，并且经常在此过程中取悦您的客户，那么敏捷就毫无意义。 花一些时间找出交付项目的最佳方式是成功的最佳基础。

团队

在体育运动中，通过思考您最喜欢的团队游戏，您将能够识别出使团队能够发挥作用的关键角色。 传统上，你会找到一名经理、一名队长和球队的其他成员。 除此之外，您还可以找到教练、理疗师、营养师和各种支持人员。 但如果我们看看橄榄球比赛，就会发现球队中的球队：组成 scrum 的球员。 这个包由指定的球员组成，他们的工作是赢回球并继续比赛。 当 scrum 进行时，双方的球员在没有领导的情况下作为一个单一的单位尽可能协作、沟通和高效地工作，以使球重新获得控制权。 正是橄榄球比赛激发了 Jeff Sutherland 将他的软件开发方法论命名为“Scrum”。

• Scrum 并不是敏捷剧本中唯一的软件开发方法。 但它最能描述敏捷概念和团队工作、激励个人、建立信任关系、自组织、仆人式领导、沟通、透明度和协作的行为。
• 您的团队将主要由您所处的环境组成。您可能有开发人员可供您使用。 有些人、没有人或全部人可能在不同程度上熟悉敏捷。 您可能想聘请新团队或与第三方合作。
• 其他角色也将是必需的，但我们稍后会讨论这些角色。
• 有人说，如果你组建了你的开发团队，那么你就选择了你的技术。 根据您将团队从何处聚集在一起，他们将具有特定的技能组合。 因此，请仔细考虑您如何组建您的开发团队，以及您是否需要在您的旅程到达这一点之前进行技术评估。
• 这将我们带到了跨职能团队。 当团队一起工作时，当个人投入以完成工作而不管他们的头衔如何时，他们的工作效果最好。 尝试建立一个自给自足的团队和承担多个角色的个人。
• 建立一个环境、文化和关系中心——一个团队可以交付、不受约束或限制的地方。 为团队提供有效和高效的工具、人员、资源和空间。
• 保持团队规模不超过七八个人。 如果您需要更多开发人员，请将团队拆分为多个新团队。 然后，每个团队可能负责给定的职能领域。 如果您在多个地点有多个团队，请考虑举行 Scrum of Scrums。 如果在复杂环境中这些问题很多，请使用敏捷项目管理。
• 确保团队、业务、利益相关者甚至客户可以相互访问。 确保他们进行沟通和协作，并消除任何阻碍进展的东西。 日常沟通是治疗项目病痛的最好方法。 当人们说话时，他们会做事。

可以通过多种方式组建团队来交付软件。

项目简介

在可行性步骤中，您找出了您的项目的“原因”，并建立了与您的创业公司一起前进的信心，或者获得了继续进行的支持。 项目简介是将“为什么”与“什么”、“何时”和“谁”结合在一起的活文档。 它是“活的”，因为随着你的进步，你的知识、理解和道路可能会发生变化。 把这份文件写完就离开，再也不回来，只是把你的想法寄托在一个时间点上。 在敏捷世界中，您的时间点参考可能会在早期每周甚至每天都发生变化，因此保持最新很重要。

• Jonathan Rasmusson 在他的《敏捷武士》一书中将其称为“初始甲板”，这是封装和维护项目简介的一个很好的工具。 在这里，您会找到很好的建议，以确保对您的项目感兴趣、受其影响或参与的每个人都在同一页面上。
• 交付项目的最大敌人是对项目是什么以及要满足哪些“要求”有一个不清楚、不一致或只是完全不同的理解。 如果即使是一个重要的利益相关者对你正在做的事情有不同的理解或看法，后果可能是巨大的。
• 一个好的项目简介可以传达：
  1. 利益相关者和团队成员之间达成共识的共同期望。
  2. 对项目的理解，各方的理解一致。
  3. 目标、愿景、目的、范围和项目背景。
• 您将从可行性中收集到很多有用的信息。 项目简介将帮助您定义和找到搜索问题的答案。 它将把利益相关者、你存在的理由、高层次的范围、风险、目标解决方案、预算、时间表、期望和优先事项汇集在一起​​。

有一次，一位同事在走廊里拦住了我，问我在哪里可以获得项目的项目简介。 我打趣道：“我们不需要简报，我们很敏捷”。 他看起来很困惑，好像他在质疑我的理智或权威。 他这样做是对的。

在你继续之前，确保你让每个人都在同一个页面上，讨论它，提出困难的问题，然后把它钉在人们可以停下来、阅读、评论和帮助修改它的地方。

文化和工作方式

您了解您的业务运作方式及其文化，以及它喜欢完成工作的方式。 就其本质而言，敏捷可能会挑战您的企业多年来培养的一些工作方式。 不要期望敏捷会被实施，并且每个人都会从一开始就热情地采用它。 有些人可能会感到困惑，只带着恐惧和恐惧看待它。 有些人可能会公开拒绝参与其中。 这些是您必须克服的挑战和看法。 但是在你早期，不要到处挥动敏捷棒殴打任何不听它的人。 这不会建立信任、采用或参与。

我曾经喜欢挥动众所周知的大棒，这为我赢得了很多负面新闻。 我把它转过来，但不是在先遭受相当大的痛苦之前。

当您踏上收养之路时，请谨慎、尊重和同情。 如果您从事的是陈旧的传统业务，那么这可能不是让整个业务保持一致的最佳方法。 从小处着手，逐步赢得尊重和认可。 仅从您的团队开始。 一旦您开始以比以往更好的质量交付更快的软件，人们就会开始注意到并愿意来玩您的游戏。 当他们这样做时，给他们球，带他们出去喝杯咖啡，然后让他们轻松进入你的新世界。 帮助他们。

与您的团队一起，既然他们知道项目是关于什么的，并且您的敏捷采用计划已达成一致，那么让团队决定他们希望如何作为一个团队行事和运作。

• 指导您的团队确定您认为适合您的集体需求的敏捷概念、技术、行为和框架。
• 接受团队成员的请求，了解他们必须满足哪些要求才能帮助他们尽其所能。 其中一些请求，您将能够立即解决。 其他人，您可能需要获得预算或外部帮助。 尽你所能去实现它。
• 这些是您成为真正的仆人式领导者的第一步。
• 考虑针对您的团队选择采用的概念和技术组织一些适当的培训。 这是确保您的所有团队成员，甚至是利益相关者，都在同一页面上并获得相同信息的最佳方式。 与可以根据您的需求定制产品的供应商组织合作。
• 要谨慎。 在研讨会上学习如何成为敏捷之后，没有人会成为敏捷忍者。 你的路会很长。 “成为”这个词非常明确。 只有当你真正拥抱敏捷时，你才会看到它的价值。 它应该让你兴奋。 如果它让你兴奋，那么也让其他人兴奋。
• 现在您的团队已经就概念和技术达成一致，实现了他们的愿望，并且正在接受敏捷培训，请将您的团队的注意力转移到他们自己以及他们对您、业务和彼此的期望上。
• 定义团队内部和团队内部的一些工作方式 (WoW) 有助于建立信任、关系和期望。 魔兽世界没有战争与和平。 它应该简短而中肯，在七到十个重点句子之间。 这些句子清楚地说明了人们如何一起行动、交流、协作、支持、交付和执行。 它还应该说明团队对业务的期望。

• 敏捷既是一种思维方式，也是指导原则和概念。 它可以帮助您在行为、思考、谈判、互动、沟通、执行和改进的方式上发展。 它依赖于有动力的个人相互支持以实现共同目标，作为一个整体。 有一句非洲谚语：

到现在为止，你的团队应该非常兴奋、充满活力和动力。 现在，通过您积压的用户故事进一步吸引他们。

积压

毫无疑问，您的项目中存在不确定性。 您不可能在客户生命的早期就确切知道如何为客户构建合适的产品。 你不能若有所思地凝视水晶球并预测未来。

“待办事项”或“产品待办事项”是您的需求所在。 敏捷倾向于编写能够抓住“需求”本质的简短、精练的陈述。 待办事项只是一长串条目，每个条目定义一个单独的、离散的“需求”作为用户故事。 从现在开始，我们将使用用户故事这个词，而不是“需求”。 你可能会问“为什么？” 这是个好问题。 对于似乎永远存在的情况，说明客户在软件项目中所需的功能或方面一直被称为需求。 这个词有一个在敏捷中没有价值的解释。 牛津词典将其定义为：

需要或想要的东西。 或者，一件强制性的事情； 一个必要条件。

不幸的是，如果我们开始定义我们的解决方案应该是什么，并声明事情是“强制性的”，我们最终会遇到麻烦。 说所有这些用户故事都是强制性的太容易了。 如果我们采取这种观点，我们就会冒着超出计划和超出预算的风险来尝试交付给定范围的所有内容。 可以说，对于这个产品来说，这些故事是解决方案可行所必需的，我们只是想避免对那个特定词的解释。

• 始终从角色的角度写故事。 角色代表解决方案的用户或利益相关者。 在开始积压之前开发这些角色是个好主意。
• 在这个阶段，只写简短的陈述，基本上建议在适当的时候就用户故事进行更深入的对话。
• 真实的人会根据他们为实现目标而需要完成的任务来思考。 从角色的角度和他们需要完成的内容来写你的故事。
• 你不需要写完整的待办事项——只要写尽可能多的东西，你的客户将需要你的产品是可行的。
• 您会在产品的生命周期中发现用户故事会发生变化，或多或少变得重要，或者可以完全删除。 经常发布、获得反馈和评估优先级将告知这种行为。
• 不要孤立地写故事。 让您的团队、利益相关者甚至您的客户参与进来。 故事可以在项目的生命周期中随时更新，但应避免在开发工作开始后对其进行更改。
• 你的一些故事可能被认为是“史诗”。 这些是涵盖很多内容的大型故事，并且将在接近交付时间时分解为较小的故事。
• 考虑使用 INVEST 模型，这是一个用于验证良好用户故事质量的清单。
• 任何人都可以在待办事项中添加故事。 它应该放置在底部，或专门创建的“停车场”中。 这个添加的故事可以作为与团队和业务讨论的提示。 如果业务和团队支持它，则可以对其进行估计和优先排序
• 您还可以考虑系统中风险最大的部分。 如果您有一个复杂、新或技术未知的用户故事或功能，请将这些优先放在您的待办事项列表的顶部。 这样，您就不会在首次发布前几周尝试交付产品中具有挑战性和关键的部分。

一旦你有一个满足你需求的积压工作，你就可以估计其中的故事，按优先级排列它们，并制定一个发布计划。

高级估计和优先级

高级估算是调整积压工作的过程。 项目有多“大”，它带来了什么价值？ 优先排序是决定哪些故事对您最重要、产品的可行性以及客户的利益的过程。 我们希望尽早交付价值最高的物品，从而为企业带来最大价值，从客户那里获得反馈，并且不为小事出汗。 输出将是按优先级排序并适当调整大小的有序积压工作。

• 顶部的故事被认为是最有价值的。 我们希望尽早交付最有价值的物品。
• 大小和估算的技巧有很多，但在这一点上，您只想对故事的大小有一个良好的指示性感觉。
  • 使用 T 恤尺码、相对尺码、理想日子或故事点。
• 此时您也不会拥有所有可用信息，这没关系。 跟着它跑。
• 让您的业务利益相关者或产品经理参与（如果有的话），以及将做这项工作的团队。
• 我们希望那些将要设计、开发和测试工作的人来确定它的规模，因为最好的评估人员是专家。
• 团队可能会开始将故事分解成更小的部分。 如果发生这种情况，请编写更细化但离散的故事。
• 团队也可能开始对一些故事进行排名，因为自然有些东西必须在其他东西之前交付以支持技术或给定的用户旅程。
• 在你和团队之间，你也可能开始在积压工作中发现需要填补的漏洞。 只需用新故事填补这些漏洞，并酌情估计和确定优先级。
• 使用 MoSCoW 分析最容易执行优先级排序。 MoSCoW 是一种简单的技术，可帮助您确定哪些故事是产品成功的“必备”。
• 您可以在估算开始之前进行优先级排序。 但是，某些元素的大小也可能决定优先级和实际业务价值的决定。 因此，不要互相争论估计和优先级，但不要争吵！
• 没有两个故事可以像另一个故事一样重要。 排名 1 的故事比排名 2 的故事更重要或更有价值。
• 展示故事的重要性或价值的一个好方法是为其添加货币价值。 例如，如果认为故事 A 会带来 5000 美元的额外收入，而故事 B 可能会吸引 100 美元，那么故事 A 更有价值。 同样，如果故事 C 比故事 D 更能拯救企业，那么故事 C 更有价值。
• 一旦你确定了你的积压工作，你就会得到一个数字。 当我们进行发布计划时，这个数字将帮助我们了解我们的团队在给定的时间范围内可以交付多少。

请记住，您不需要事先了解所有用户故事。 另外，请记住，没有必要在客户看到您的产品之前交付您的所有故事。 You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

发布计划

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. 不要这样做。 Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

适应性规划

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

故事创作

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

短跑

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• 以小增量工作有很大的好处。 这意味着您只关注交付的近期未来，并且通过新的输入、反馈和学习，您可以在较短的迭代周期内响应变化。
• 在发布开始时，执行 sprint 0。这可以让团队、业务和您的项目发布做好准备，并为成功交付设定心态。 绘制出支持发布基础的基本技术框架和架构。 设置环境、帐户和工具。 执行尖峰以了解困难或未知的问题。 详细说明您的用户故事，为 sprint 1 做好准备。 Sprint 0 就是要做好准备。
• 在发布期间，不断完善积压工作。 随着您了解更多或学到新东西，您的优先级可能会改变，新的需求可能会出现，并且您之前认为是一个很棒的功能可能会被完全删除。
• 不要开始没有机会在 sprint 内完成的工作。 如果不能，将其分解成更小的块。 并且不要在之前开始的工作尚未完成时开始新的工作。 通过开始许多不能被认为是完整的事情，你不会创造任何价值。 此外，避免上下文切换。 这是开始一项任务，受到干扰，开始另一项任务的活动，最有问题的是，两者都没有完成。
• 在任何时候限制团队正在进行的工作量。 例如，如果您有 3 名开发人员和 1 名测试人员，您可以对开发人员和测试人员设置 WIP 限制。
• 在计划完成后，切勿在 sprint 中添加更多工作。 永远不要在中途停止冲刺。 例外情况是：
  • 如果你的表现比预期的要快，考虑从积压的顶部开始下一个故事，只要准备得当。
  • 如果 sprint 表现如此糟糕以至于无法完成。 这通常只发生在发生某种描述的灾难的情况下。
  • 如果由于业务需求的即时变化而不再支持 sprint 目标。
• 如果您确实取消了冲刺，请优雅地进行，花时间重新集中精力，然后像其他任何冲刺一样开始新的冲刺。
• 在发布快要结束时，考虑一个最终的发布冲刺。 没有编写新功能，可以清理一些错误，并且可以为实际向客户发布产品的新版本做好准备。 这并不是说您不能同时进行增量客户发布——只是这是一种受控、可衡量和可持续的发布机制。
• 在发布结束时，您可能会考虑进行为期一周的冲刺。 在这个 sprint 中，你可能会与团队一起分解一些新想法或找出一些新技术。 这些都是有益于业务的伟大工具，它为团队提供了一些简报空间来思考和发挥创造力。 这不是为了偷懒，仍然会创造价值。 同样，每个人都需要休息。 在这个时候休假有助于在你释放中期时保持你的节奏和速度处于良好状态。

定义完成

定义“完成”的真正含义非常重要。 在您的项目生命周期中，“完成”有很多版本——故事、发布或整个项目“完成”意味着什么。 这一切都归结为您、您的团队和企业将认为完整的质量水平，以满足发货准备。

对于您的团队，“完成”故事的定义将类似于所有代码完整、经过同行评审、符合定义的验收标准、单元测试、UAT 并推送到您的代码存储库。 为了使故事能够从设计师传递到开发人员再到测试人员，“完成”的定义必须被链条中的下一个人接受。 您的产品负责人会期望这对他们意味着什么，以便将产品增量发布给您的客户。 在任何情况下，每个人都必须了解“完成”的含义，并成为确保其含义得到满足的责任方。 定义你对“完成”的定义，沟通它，就它达成一致，然后发展它。 完成了。

连续测量

如果你无法衡量它，你就无法管理它。 改进也是如此。 在敏捷项目中收集经验数据的需求几乎与血液循环一样重要！ 如果没有数据，您怎么知道需要管理、纠正或改进什么？ 好吧，简而言之，您将依赖直觉和未经证实的猜测，这些猜测在审查下很快就会分崩离析。 根据谁在进行审查，这可能是一个相当不舒服的地方。 因此，从你的项目一开始，确保你知道你将如何展示你的进步，以及其他人将通过什么标准来看待你的成功。

幸运的是，敏捷配备了有用的工具和技术。 要做的第一件事是回到敏捷宣言，在你最喜欢的文字处理器中输入以下文字，将它们放大到 96pt，打印，然后贴在墙上供所有人查看：

在交付软件方面，你最大的可证明的力量就是向工作的人展示它，做它应该做的事情。 这不仅会让您的客户满意，还会为您的团队赢得极大的尊重，并为在整个业务中得到更多采用而加油。

以下是一些其他工具：

• 每日站会：这个仪式有一些变化，但本质是让所有团队成员面对面交谈：保持简短，保持重点，保持轻松。 如果有任何事情需要详细讨论，请将其停在站立后需要的人之间进行更长时间的对话。 如果提出了障碍，请将它们像故事一样写下来，将它们添加到您的待办事项中，并尽快解决它们。 任何阻碍您的团队的事情都会减慢他们的进度，并且会在速度降低和软件不符合预期的情况下得到证明。
• 速度：是一种历史工具。 这有点像你收到的那些财务警告，说过去的表现并不能保证未来的表现。 但在敏捷的案例中，我们确实希望实现一个基本平稳的团队速度。 正是速度使我们能够预测未来的绩效和对我们计划的信心。 可能存在您无法控制的影响，这可能会降低给定 sprint 输出的故事点数。 如果发生这种情况，您可能会康复。 永远不要用速度作为击败你的团队的一根棍子； 它不会为你赢得任何好处。 可以肯定的是，前 2-4 个冲刺的速度会不稳定。 但是，在那个时间范围内的某个地方，您应该开始看到一致性和稳定性。 如果您的速度从一个极端波动到另一个极端，那么您就遇到了需要与您的团队一起解决的问题。
• 燃尽图：现在，这种衡量进度的方法很棘手。 出于这个原因，我没有提供链接以了解更多信息 - 您必须自己进行研究并同意作为一个适合您的团队和企业。 刺的原因是什么？ 好吧，没有一种资源可以讲述同样的故事！ 一致同意的一件事是，它将在一个 sprint 或一个版本中显示你在时间盒内的表现。 如果每天维护，它会显示您是否处于正轨或偏离轨道。 一些团队用它来表示还有多少价值需要创造，而其他团队则用它来显示还有多少工作需要完成。 前者是对成功和价值创造的庆祝，后者则不那么鼓舞人心和激励。
• 燃尽图：如果您必须显示工作完成率，请使用燃尽图。 但是使用燃尽图可以让您显示已经创造了多少价值，以及您计划在冲刺结束时创造多少价值。 对于团队来说，这是一种更具激励性的工具，既可以向企业展示已经完成的工作（如果事情进展不顺利的话，也可以展示很少的工作......）以及他们仍然关注的目标。 在任何情况下，使用图表来发现进度未按预期跟踪的地方，并寻找模式或偏差并掌握它们以尽快解决潜在问题。 每天更新它们以进行冲刺，并在冲刺结束时更新发布版本图表。
• 任务板：这些是展示所创造价值的绝佳视觉辐射器。 当每天或一天中的任何时候更新时，它们会立即显示正在取得的进展。 如果与看板结合使用，它们也是可视化系统中的流动和阻塞的绝佳工具。 如果您可以看到已经完成了大量开发，但测试效率不高，那么您可以看到问题正在发生并做出适当而迅速的响应。

其他需要考虑的工具是敏捷挣值、周期时间和累积流程图 (CFD)。

保持这些措施、图表和其他工具可见，最好在墙上响亮而自豪，让所有人都能看到。 团队、利益相关者和其他相关方可以立即看到项目的状态。 它是透明的，是一种有价值的沟通工具。 如果您不能将这些工件放在墙上，请使用可共享和协作的工具，并确保那些想要访问的人拥有它。

连续的提高

在您的敏捷生活中，寻求识别和学习可以改进的地方。 在项目结束时并没有吸取和吸取教训。 这就像通过驾驶考试并在没有教练的情况下试探性地驾驶您的第一次驾驶。 你会知道什么是有效的，你应该做什么，但随着时间的推移，你会调整你的驾驶技能和能力，学习新技术。 你甚至会养成坏习惯。 寻找他们，了解他们，并找到改进的方法。

有很多机会可以确定什么不起作用并应用补救措施。 敏捷中内置的方法是回顾。 这是反思和调整的主要工具。 在每个 sprint 结束时，花时间与团队一起改进工作的完​​成方式、质量的交付方式、效率的最大化方式、浪费的最小化方式以及容量的增加方式。 当您确定改进措施时，不要试图立即解决所有问题。 确定影响最大并且可以在下一个 sprint 中实施的那些。 测量和观察。 如果它产生了预期的影响，就把它锁起来，把它写进你的工作方式和完成的定义中。 如果它不起作用，请再考虑一下。 任何没有被投入到即将到来的 sprint 中的经验教训都可以被搁置并在下一个 sprint 中优先考虑。

定制流程。 删除任何不起作用的东西。 消除障碍。 如果您允许，您作为敏捷团队的成熟度将是无限的。

超越敏捷项目管理

了解项目交付后会发生什么很重要。 支持和维护是确保项目在客户手中后保持性能的关键； 客户反馈可以考虑到未来的版本中； 并妥善处理客户问题。 项目是一项独特的、受时间限制的工作。 它交付的产品在项目团队解散后还有生命。 确保您能够在产品上线后支持该产品。

敏捷项目与更传统的方法共存。 平衡预算控制和利益相关者可见性的要求与敏捷的灵活性和响应性目标。

治理框架或敏捷治理模型与标准敏捷流程（例如 Scrum）结合使用。 它们以两种特定方式工作：

• 它们通过阐明在开发迭代（冲刺）之外发生的过程，为敏捷项目提供了一个包装。 这包括为成功完成项目启动和正确验证决策和计划提供明确的标准。
• 他们转移了标准敏捷过程特定部分的重点，并突出了需要治理或支持治理的特定原则和技术。

在当今瞬息万变的世界中，组织和企业热衷于采用更灵活的方法来交付项目，并希望变得更加敏捷。 然而，对于交付项目和计划的组织，并且已经存在现有的正式项目管理流程，许多敏捷方法的非正式性令人生畏，有时被认为风险太大。 这些以项目为中心的组织需要一种成熟的敏捷方法——项目交付概念中的敏捷——敏捷项目管理。

通过采用敏捷来学习和成长。 只做你的团队感到舒服的事情，确保听到他们的声音，并按照他们的要求采取行动。 鼓励您的团队在适当的时候采用新的和更有价值的技术。 与业务部门协商并鼓励他们了解成为敏捷组织意味着什么。

旅行愉快。