如何将敏捷项目呈现给关注瀑布的人

Question

我们的团队被要求在项目计划中代表我们的开发工作。没有人对我们的工作不满意，也没有人质疑我们的交付能力，我们只是参与了IT行业对项目计划的呼吁。问题是我们是一个敏捷的团队，还没有从正式的项目计划的角度来考虑我们的工作。

虽然我们对下一步的工作有一个大致的了解，但在计划迭代之前，我们还不能百分之百肯定。到目前为止，我们的团队在很大程度上是在真空中运作的，并没有被要求向外部方介绍我们的方法或度量标准。我们遵循极限编程中支持的大多数实践。

我们每季度召开一次计划会议，对我们将要进行的四分之一的故事有一个大致的了解。也就是说，我们的故事被记录在3x5卡上，并且只在迭代开始时对它们进行估计。经过估计，我们在团队基金会Sever中记录了这个故事。在迭代过程中，我们将代码附加到故事中，并在完成后将故事标记为已完成。根据这些数据，我们能够生成烧录和速度图。最重要的是，我们知道迭代的平均速度，这样我们就不会咬得太多了。

我并不是想改变我们开发的方式，而是想在一份只熟悉瀑布的人会理解的报告中介绍我们的开发活动。在敏捷项目计划是什么样的？中，Kent McDonald很好地展示了敏捷项目计划和瀑布项目计划之间的区别。他指出了可消耗子弹的不同之处：

• 敏捷项目计划是基于特性的。
• 敏捷项目计划被组织成迭代
• 敏捷项目计划根据时间框架有不同的细节级别
• 敏捷项目计划由团队拥有

能够解释差异是很好的，但是如何最好地展示数据呢？

Answer 1

给他们看半精练敏捷宣言。

通过将敏捷系统与瀑布方法进行比较，它明确地告诉了您敏捷系统的全部内容：

过程和工具的个人和交互--当然，我们有强制性的流程和工具来控制这些人(我们更喜欢“资源”这个术语)如何将工作软件与综合文档进行交互，只要该软件是在严格的合同范围内全面记录客户协作，而不是合同协商，当然，在严格的合同范围内，如果有详细的计划来响应更改，那么就需要严格的更改控制来响应计划，并且严格遵循该计划。

Answer 2

我不得不这么做，一次。团队想要做敏捷，客户想要(并且理解敏捷)，外部第三方(称他们为“审计师”)，想看瀑布报告。

我们之所以能撒谎的一个重要原因是因为第三方其实并不在意，他们只是想选中复选框。如果客户很高兴，团队也很高兴，那么“审计师”很难回头查看我们给他们的报告，然后再检查最后的盒子。

不要这样做，如果第三方的问题，并真正关心你是使用瀑布。如果审计师知道你是敏捷的，只是没有更新他们的文件来支持你--那么你可以撒谎。

你的工作是什么?撒谎，但是善意的谎言。

• 将“特性”改为“必须有功能”。
• 你的工作是迭代，迭代通常要超过X周，瀑布计划喜欢在几周内看到事情，所以没有什么大问题。您可以将每个迭代的结束标记为一个里程碑。里程碑是瀑布。迭代往往有一个主题(或相关的史诗)，所以您可以将主题/史诗标题放在里程碑上(例如。21/11完成GUI。)
• 计算你的速度(从你的刻录/向上图表)，并计算出一个故事点平均代表的时间(至少以你当前的速度)，这将给你任务的持续时间。通常是不准确的，但它们在某种程度上是有意义的。
• 你的计划有不同程度的细节取决于时间框架-基本上相同的瀑布。可能的不同瀑布计划有不同的细节取决于观众。
• 敏捷计划由团队拥有。瀑布计划由项目经理拥有。你已经有了一个项目经理，他们可能正在做这个翻译。他们应该拥有这份翻译后的文件，并保护球队不受可能因为这件事而倾盆而下的攻击。敏捷或瀑布项目经理的工作就是保护团队不受干扰，从而阻止他们工作。
• 当然，您并不知道下一次迭代要做什么，但您确实大致知道自己在做什么。您已经对它有了一种感觉，而且之后的迭代也会变得更加粗糙。(我听说这叫迭代雷达)。撒谎然后说你知道。当你埋怨没有出现在迭代雷达上的故事卡时，把它放进某个地方就行了。希望你不必提交太多关于项目计划的更新，否则他们会注意到你没有做你说过的事情。

基本上这是一种痛苦。翻译将是许多小时的工作。如果你必须经常这样做，那就自动化它。

Answer 3

首先要问的问题是，企业到底想要什么？一些企业非常高兴看到敏捷冲刺被表示/分解成甘特图。对于任何真正理解短跑的人来说，这可能是没有意义的，而且可能会有规律的变化，但对于那些要求冲刺的人来说，这是很熟悉的。然后连同甘特图，呈现燃尽，等等。

我们也经历过类似的事情，最终(如果敏捷成功的话)它会出售自己(如果没有，你为什么要这么做？)人们开始理解“努力”，一个特定的团队能够在两周的冲刺中“烧毁”40个努力点，并且在估计这些努力点方面实际上相当不错。一旦他们看到了给他们带来的好处，他们就会把这个过程卖给你剩下的生意。但最重要的是，你永远不能，永远不要强迫别人，因为他们只会反击。