敏捷为使高管保持清醒的问题提供了真实有效的答案：“如何在瞬息万变的世界中保持成功？” 这种方法论已经征服了市场，证明它是创建和交付软件的最佳方法之一。 面向所有人的敏捷实践是针对从业者的，在本书中，您将学习整个组织（从产品经理和开发人员到营销人员和高管）如何采用“灵活”的方法。
Matt LeMay简单而没有语地解释了什么是敏捷，并提供了具体有效的步骤，使任何团队都可以尽可能高效地实现其任务。 您会发现许多适合于任何类型和规模的组织的示例-从初创企业到大型企业，这些示例使您可以在各种活动领域中实施敏捷方法。
深入敏捷实践：“哇！”
当我担任产品经理时，我手头有许多现成的敏捷实践和框架可供团队使用。 这些框架仅与软件开发团队的需求相关，并且已经过成千上万的专家在实践中进行了测试，其中许多人以无障碍文献和博客文章的形式友好地分享了他们的经验。
但是，当我开始担任顾问时，我无法立即理解如何针对新团队的完全不同的目标使用这些方法。 我们的工作结果-经过几个月的长期磋商后获得的分析报告，以及有关客户形象形成的研讨会-与软件产品存在显着差异，因为我们不再拥有明确客观的方法来验证这些结果的性能。 此外，在我们的角色中，与开发团队中的角色相比，所有边界都被清除了，因为我们现在都做了一件共同的事情，没有躲在“视觉设计师”或“前端开发人员”的头衔之下。
陷入程序混乱之中，我们试图应对一组提供非技术性结果的团队所遇到的标准问题。 随着我们的工作，这些结果的主题会不可避免地扩大，尤其是当我们从中间状态（草图）切换为完整的文档和演示文稿时。 对于我们来说，每个结果的以客户为中心的目的有时仍然不清楚，因此，在这种情况下，我们扩大了研究范围，以免“遗漏”任何东西。 尽管我们喜欢一起工作，但我们并不总是了解谁负责，负责什么，何时负责以及为什么负责。
值得注意的是，“法定”敏捷方法并不总是完全适合我们团队的结构或结果，但是，我们知道基本的敏捷原则可以使我们保持正确的方向。 因此，我们开始问自己构成本书基础的问题：我们如何清楚地了解客户的需求？ 我们能否通过及时的合作消除一切工作上的误解？ 我们是否确保在工作流程中引入新信息不会转变为材料的完整处理？
我们开始在计划和回顾性会议上定期提出这些问题，并更改工作流程以反映我们的想法和答案。 经过大约一年的试验，我们将我们的方法转变为WHPI实践（读作“呜呼！”或“为什么，如何，原型，迭代”）。 表中给出了WHPI的四个步骤。 6.3。 首先，您要共同决定将结果放在第一位的原因，预期的影响以及客户将获得的价值。 然后，您决定如何提供此值，最终结果如何。 最后，您在有限的时间内委托一个团队成员创建一个原型，以反映您要为客户创建的体验，然后迭代该原型并检查它是否能够实现第一步中设定的目标。
我们发现，WHPI是一种功能强大的敏捷工具，可以嵌入到任何团队中，无论他们的任务和目标如何。 以下是每个WHPI步骤的简要说明，以及作为团队一部分实施和使用这些方法的一些技巧。
步骤1：为什么
在此步骤中，我们收集了几个关键项目参与者（2-4），并快速讨论了一组项目目标或结果。 如果可能，我们会聚集在单个物理（或虚拟）空间中，并计算出工作过程中记录在贴纸上的所有想法。 这些会议通常持续15到30分钟。 尽管对于这样的重要会议而言，这些时间框架似乎很艰难且不便，但它们反映了一个重要的事实：如果您无法在15-30分钟内确定主要目标，则需要获得更多信息才能继续进行。 在此阶段数次，我们意识到有必要进行基础研究以确认我们的假设或向客户提出一些澄清的问题。 在创建了单个初始的“为什么”目标集之后，我们将它们放在了关注的中心，以便它们指导其余的工作过程。
例如，当我们在开会后制定分析报告时，经常在贴纸上写下三个主要的“为什么”：
- 向高级管理层传达对项目驱动力的理解。
- 提醒与会人员重要的见解。
- 在未参加会议的员工中引起兴趣。
请注意，这些要点都没有直接表明我们将如何实现目标-稍后再介绍！
步骤2：如何
确定了项目目标之后，我们继续进行确定如何实现目标的艰巨任务。 我们通常将此步骤称为“工具定义”，也就是说，当我们知道我们将要做什么时，我们需要考虑工具和方法。 我建议与同一位会议参与者从“为什么”转到“如何”。 通常，定义一个“方式”时，您会理解为什么团队中至少一个“为什么”的主要目标实际上是高管层的“如何”步骤。
在上一节中，我们确定了以下“原因”：“引起未参加会议的员工的兴趣。” 在使用此方法之前，我们定义了一个类似的目标，如下所示：“向参与者解释语言和框架，以便他们可以与同事共享信息。” 但是，当我们开始将“为什么”与“如何”分开之后，我们意识到我们错过了两个关键问题：为什么人们与同事共同承担这些任务很重要，以及如何简化实现目标的过程？ 语言和框架是人们真正需要的吗？ 正如我们在本书中所讨论的那样，对客户及其需求的优先关注通常有助于减少我们的预期工作量，或者了解预期的结果与我们计划实现的目标明显不同。
鉴于上一节的“为什么”，我们可以确定以下“如何”指导工作流程：
- 创建一个简短的两页分析报告，以易于理解和分发。
- 用参与者难忘的名言向高级管理层传达对推动力的理解。
- 使用会议照片来提醒参与者深刻的时刻。
- 促进积极的成果并限制细节的数量，以保持成果的重点并引起广泛的关注。
如您所见，“如何”提供了一项行动计划或一项计划，以创建实现预期目标的所有必要条件。 此步骤确定了结果的形式，直接解决了“为什么”的问题，并提供了清晰而可移动的界限，以防止失去对所需结果的控制。 这样清晰的计划可以使您委派任务以更快地获得结果，而不管您在后续步骤中使用哪种方法。
步骤3：原型
通过定义“为什么”和“如何”，我们准备创建一个有时间限制的原型。 “原型”一词在不同的上下文中可能意味着很多东西。 在此方法的上下文中，我们定义如下原型：
- 原型不是模型或计划文件。 它以与所需结果或结果相同的格式创建。 例如，带有幻灯片的演示文稿的“原型”就是带有幻灯片的演示文稿。 印刷手册的“原型”是印刷手册。
- 在有限的预定时间段内创建原型。 （作为时间装箱的一部分创建。）
换句话说，我们以批准的方法和工具（“方式”），以与期望结果相同的格式和相同的时间框架“创造条件，以实现最大数量的项目目标（“为什么”）。 对于小型项目（例如海报），初始原型可能看起来像完成的结果。 对于大型项目（例如四十页的报告），初始原型可以是将20个整页对折，装订在一起并手工填充（带有编号的页面，标题，简要结果和图像放置位置）。
正如我们在第3章中讨论的那样，我们的目标是通过创建我们自己的“工作软件”版本来尽可能接近客户的体验。 在模型和计划文档中看起来不错的事情在演示，报告和会议中均不起作用。 使用原型方法验证初始结果有助于我们深入了解客户的经验，减少改进的次数并更详细地分析初始假设。
通常，我们指定一名团队成员负责创建主要原型。 通常，这变成了空闲时间的问题：谁能在接下来的几天里预留几个小时进行首次尝试？ 我们发现，两个小时的工作是创建原型的标准限制，这使您可以创建一个与项目目标进行比较的基础，并为开发和迭代留出了空间。
步骤4：迭代
在创建了第一个有时间限制的原型之后，原始的参与者团队（或团队的一部分）被组装起来以分析原型并讨论下一个迭代。 我们的第一次讨论是以加号/建议号格式进行的，团队中的每个成员都讨论成功的方面以及需要改进的元素。 （我们在回顾中使用了完全相同的格式，因此我们很快又返回了。）我们逐渐将这种格式重新制作为所谓的“保护，排除，改善”讨论。 展示原型后，参与者可以分享三种类型的评论：
- 下一个迭代应该保留什么，因为它与所有“为什么”最一致。
- 可以从后续迭代中排除的内容，因为它并不对应所有的“为什么”。
- 在下一个迭代中应该改进的地方，因为它仍然可以帮助实现必要的“为什么”。
这种方法与传统的加/要价格式之间的主要区别是公开讨论了以下迭代中需要排除的内容。 发现最成功的迭代更改发生在排除（而不是添加）之后，即使在最大的项目中，我们也开始使用这种方法。 讨论过程中开放的“例外”使参与者可以跟踪可以删除的方面，从而提供更准确，更有针对性的结果。 使所有三种类型的审核与先前达成的“为什么”保持一致，我们解决了所有潜在的冲突，避免了尴尬的时刻，并使项目朝着正确的方向发展。
收集反馈后，其中一个团队成员将这些评论转换为另一个原型限时迭代。 在某些情况下，这会导致对最后一个原型的完整修订（例如，对演示文稿的修订）。 在其他情况下，这导致基于旧原型创建新的原型（例如，基于手写原型的Word结果报告）。 这些连续的迭代回合可以由创建初始原型的人员或任何其他团队成员控制。 到第二或第三次迭代时，原型通常由承担主要责任的人展示改进的产品。 此外，通过第二次或第三次迭代，原型看起来几乎完整，可以进行最终修订。
»这本书的更多信息可以
在出版商的网站上找到»
目录»
摘录小贩优惠券可享受25％的折扣-
敏捷支付纸质版本的书后，就会通过电子邮件发送电子书。