如何向专注于瀑布的人们展示敏捷项目[关闭]

我们的团队被要求在项目计划中代表我们的开发工作。没有人会对我们的工作感到不满意，也没有人质疑我们的交付能力，我们只是参加了IT牛呼唤项目计划。麻烦的是我们是一个敏捷的团队，还没有考虑正式的项目计划来考虑我们的工作。

虽然我们对下一步的工作有一个大致的了解，但在计划迭代之前，我们尚不确定100％。到目前为止，我们的团队基本上是在真空中运作的，不需要向外部各方介绍我们的方法或指标。我们遵循极限编程中所倡导的大多数实践。

我们每季度举行一次计划会议，以大致了解我们将要开展的季度的故事。就是说，我们的故事记录在3x5卡上，并且仅在将要使用它们的迭代开始时进行估算。经过估算，我们将故事记录在Team Foundation Sever中。在迭代过程中，我们将代码附加到故事并在完成后将故事标记为完成。根据这些数据，我们可以生成燃尽图和速度图。最重要的是，我们知道一次迭代的平均速度，可以防止我们咬下去而无法咀嚼。

我不想改变我们的开发方式，而是希望在报告中介绍我们的开发活动，只有熟悉瀑布的人才能理解。在肯特·麦当劳（Kent McDonald）的《敏捷项目计划的外观》中，他很好地阐明了敏捷项目计划和瀑布式项目计划之间的区别。他指定了消耗性子弹的区别：

• 敏捷项目计划基于功能
• 敏捷项目计划被组织为迭代
• 敏捷项目计划的详细程度取决于时间范围
• 团队拥有一个敏捷项目计划

能够解释差异很棒，但是如何最好地呈现数据呢？

给他们看半醒的敏捷宣言。

通过与瀑布方法进行比较，它肯定会告诉您敏捷系统的含义：

个人和流程和工具之间的互动
，我们拥有强制性的流程和工具来控制这些人（我们更喜欢“资源”一词）的互动方式

只要全面记录
了软件，就可以使用全面说明文件中的软件

当然，在严格的合同范围之内，并且通过严格的变更控制，客户可以通过合同谈判进行合作

只要制定
了详细的计划以应对变更，就可以按照计划对变更做出响应，并且可以严格遵循

我不得不这样做一次。团队想要执行敏捷，客户想要（并理解敏捷），外部的第三方（称为“审核员”）想要查看瀑布报告。

我们可以说谎的一个重要原因是因为第三党实际上并不在乎，他们只是想选中复选框。如果客户满意而团队满意，那么“审计员”几乎不会回头查看我们提供给他们的报告，然后再检查最后的复选框。

如果第三方很重要并且实际上关心您正在使用瀑布，则不要这样做。如果审计师知道您正在敏捷，并且只是没有更新他们的文书工作来支持您-那么您可以撒谎。

你是做什么？ 烈，但善意的谎言。

• 重新定义功能，并按要求“必须具有功能”。
• 您的工作是在迭代中进行，迭代通常需要花费X周的时间，瀑布计划喜欢在Weeks中通常看到的事物，因此没什么大问题。您可以将每次迭代的结束标记为里程碑。里程碑是瀑布。迭代往往具有主题（或关联的Epic），因此您可以将主题/史诗标题粘贴到里程碑上（例如21/11具有GUI完整）。
• 计算您的速度（从燃尽图/上升图表），并计算出一个故事点平均代表多少时间（至少以您当前的速度），这将为您提供任务持续时间。通常是荒谬的，但在一定程度上将是有意义的。
• 您的计划具有不同的详细程度，具体取决于时间范围-瀑布基本上相同。瀑布计划可能会有所不同，具体取决于受众。

• 团队拥有一个敏捷计划。瀑布图由项目经理拥有。事实证明，您已经有一个项目经理，他们可能正在做此翻译。他们应拥有此翻译文档的所有权，并保护团队免受可能因其而落在他们身上的漏洞的影响。敏捷或瀑布项目经理的职责是保护团队免受干扰，阻止他们分心。

• 当然，您实际上并不知道下一次迭代要做什么，但是您确实知道自己在做什么。您对此有一种感觉，之后的迭代过程更加粗糙。（我听说过这叫做迭代雷达）。说谎，说你愿意。当您对不在迭代雷达上的故事卡撒谎时，只需将其放在某个地方即可。希望您不必提交太多有关项目计划的更新，否则他们会注意到您没有按照您的意愿做。

基本上这是一种痛苦。翻译将需要很多时间。如果您需要执行很多操作，请使其自动化。

要问的第一个问题是企业实际上想要什么？一些企业非常高兴看到敏捷冲刺被表示/分解为甘特图。对于真正了解冲刺并且可能定期更改的任何人来说，这可能毫无意义，但对于要求它的人来说却是熟悉的。然后与甘特图一起显示燃尽等。

我们已经经历过类似的事情，最终（如果敏捷正在运行）它将自行出售（如果不可行，那么您为什么要这样做？）。人们开始理解“努力”，并且某个团队能够在2周的冲刺中“消耗” 40个努力点，并且平均而言，估计这些努力点实际上是非常好的。一旦他们看到了给他们带来的好处，他们就会将流程出售给您。但主要要点是，您永远无法将其强加给某人，因为他们会反击。