您如何向“敏捷”团队说明他们仍然需要计划编写的软件？

这一周的工作中，我又变得敏捷了。经历了标准的敏捷，TDD，共享所有权，临时开发方法，从未计划过一张卡片上的几个用户故事，口头上嚼了一个第三方集成广告恶心的技术，却从未真正做过思考或应尽的努力，并将所有生产代码与过去几个月来遇到的第一个测试在体系结构上耦合起来，我们到达了发布周期的结尾，并且发现我们一直在开发的主要外部可见功能太慢而无法使用，越野车，迷宫般变得复杂而完全不灵活。

在此过程中，“尖刺”完成了，但从未记录下来，也没有生产出任何单一的建筑设计（没有FS，所以，如果您不知道自己在开发什么，该如何计划或研究它？ ？）-项目是成对进行的，每个人一次只专注于一个用户故事，结果是不可避免的。

为了解决这个问题，我放弃了雷达，去了（可怕的）瀑布，进行了计划，编码，基本上并没有放弃这一对，并尝试了我一个人尽可能多的工作-专注于坚实的体系结构和规范，而不是单元测试。一切确定后，我们将在以后发布。该代码现在更好，并且实际上完全可用，灵活且快速。某些人似乎真的很讨厌我这样做，并且竭尽全力破坏我的努力（可能是无意识地），因为这违背了敏捷的神圣过程。

因此，作为开发人员，您如何向团队解释计划他们的工作并非“不敏捷”，您如何使计划适合敏捷过程？（我不是在谈论IPM；我是在谈论坐着一个问题，并草拟一个端到端设计，该设计说出应该如何充分详细地解决问题，以便从事该问题的任何人都知道他们应该使用的架构和模式，以及新代码应集成到​​现有代码中的位置）

我认为（而且我可能会一头雾水）所有项目都应该有一些经典的瀑布：初始分析和规范阶段至关重要。您必须知道自己在做什么，并且必须书面形式。以书面形式获得需求既困难又耗时，并且容易做得不好。这就是为什么这么多人跳过它的原因-任何借口都会这样做：“哦，我们做敏捷，所以我们不需要这样做。” 从前，在敏捷之前，这是“哦，我真的很聪明，知道如何解决这个问题，所以我们不需要这样做。” 单词有所变化，但歌曲基本相同。

当然，这很困难：您必须知道您要做什么-规范是开发人员和客户可以传达预期意图的方式。

一旦知道要做什么，就可以勾勒出一个架构。这是“正确了解大局”部分。这里没有神奇的解决方案，没有正确的方法，也没有任何方法可以帮助您。架构是解决方案的综合，它们来自部分受启发的天才和部分来之不易的知识。

在每个步骤中，都会有迭代：发现错误或丢失的内容，然后修复它们。那是调试。它只是在编写任何代码之前完成的。

有些人认为这些步骤很无聊，或者不需要。实际上，这两个步骤对于解决任何问题都是最重要的-弄错这些错误，随后的所有操作都会出错。这些步骤就像建筑物的地基：弄错它们，您将获得比萨斜塔。

一旦有了WHAT（这是您的规范）和HOW（这是体系结构-这是一个高级设计），便有了任务。通常很多。

随意分解任务，然后按需要分配它们。使用您喜欢的或适合您的每周方法。并完成这些任务，了解您的前进方向和需要完成的任务。

一路上会出现错误的痕迹，错误，规范和体系结构发现的问题。这会引起类似的提示：“那么所有的计划都是浪费时间。” 这也是公牛。这只是意味着您以后需要处理的问题较少。当您发现高级初期的东西有问题时，请修复它们。

（这是一个附带的问题：为了满足昂贵，困难甚至不可行的规范，我一遍又一遍地看到了很大的诱惑。正确的回答是问：“我的实现被破坏了，还是规范是否被破坏？”，因为如果可以通过更改规范快速而廉价地解决问题，那么这就是您应该做的事情。有时这可以与客户一起使用，有时却不能。但是您不知道是否不要问。）

最后-您必须测试。您可以使用TDD或其他任何您喜欢的方法，但这不能保证最后您按照您说的去做。它有帮助，但不能保证。因此，您需要进行最终测试。这就是为什么诸如验证和确认之类的东西在大多数项目管理方法中仍然是大项目的原因-是软件开发还是推土机。

简介：您需要所有无聊的前期工作。使用诸如敏捷之类的东西作为交付手段，但是您不能消除过时的思维，指定和架构设计。

[您是否真的希望通过在现场安置1000名工人并告诉他们组成团队来完成一些工作来建造一座25层的建筑？没有计划。无需结构计算。没有建筑物的外观设计或构想。而且只知道这是一家酒店。不-没这么认为。]

我仍然感到惊讶的是，许多人认为TDD意味着首先编写单元测试。不，这意味着在编写代码之前需要编写测试。该测试实际上可以是单元测试，集成测试，端到端测试以及性能测试（当然，您可能不会在经过测试的代码之前编写性能测试，但这并不意味着您根本不应该编写它）。从用户故事的完成定义中应该可以看到所需的测试类型。如果用户故事的接受条件之一说该功能应在500毫秒内为50个并发用户提供结果，则在您进行性能测试以证明该接受条件得到满足之前，不能认为用户故事已完成。进行自动测试后，您可以在添加其他功能时每天检查它是否通过。

听起来您的接受标准未正确定义，因此您无法测试性能。将应用程序部署到实际环境中并在高负载下使用后，仍然可能会出现性能下降的情况，但始终可以将其视为需求失败（如果未定义需求，则开发人员在处理需求时就不会考虑它）代码）或开发团队（针对定义的要求的测试不足）。

另一个有趣的事情是，您团队中的开发人员正在关注单个用户的故事。敏捷与沟通有关，因此开发人员应传达用户故事的要求以及它如何影响应用程序的其余部分-协作是必须的。测试也应涵盖这一点，因此，如果一个开发人员破坏了另一用户故事所需的功能，则它应该在自动化测试中可见。如果您仍然认为这还不够或不起作用，可以在整个团队合作并讨论应用程序体系结构的基础上引入体系结构会议。通常每周召开一次这样的会议就足够了。

瀑布过程中的许多事情都被通讯和自动测试所取代。没有人说您不能编写任何高级文档或设计！您可以和许多团队为此使用Wiki。

[我们的产品]使用速度太慢，越野车，变得复杂而完全不灵活。

这与敏捷无关，这表明程序员没有正确地完成工作。

敏捷的一个基本想法是，团队可以完全控制流程。这意味着他们必须就计划，文档，测试的数量以及如何处理重构达成一致。所有这些功能都很强大，但同时也伴随着责任，这可能是您的团队失败的地方。他们接受了自由，却忽略了责任。

最后，这只是解释代码质量并试图就增加和保持这种质量的方法达成一致的问题。确实适用常规编程实践。

专家提示：使用“完成的定义”来强制执行此操作。确保每个人都同意它，并将它对所有人可见。将其用作确定故事是否完成的严格看门人。甚至还可以将非功能性需求（例如性能）添加到该列表中。

是的 你的队友是白痴。您的项目因为敏捷而糟透了。感觉好多了？好吧，继续前进。：P

我认为，如果您较少关注资本M方法论的名称，而更多地关注您编写的软件为何如此缓慢且存在错误的原因，则您和您的团队将能够更有效地就问题出在哪里进行沟通。根本不要使用敏捷或瀑布。他们显然在您的办公室里情绪沉重。

敏捷有时会起作用。这次对您的团队没有用。有人会说那是因为您在敏捷方面做错了。毕竟，敏捷是可行的，因此，如果您做对了，那就行了，对吗？随你。

听起来好像没有人不同意失败，但是如果您责怪方法论，那么您将不会赢得朋友，影响他人或在下次做得更好。这可能与实际出了什么问题无关。

相反，应集中精力找出最直接的故障原因，并与团队合作以确保不再发生故障。这将需要人员技能。

说到人际交往能力，您不会感到惊讶的是，您的团队不喜欢您通过完成所有工作并比他们做得更好来使他们看起来很糟糕。通过“秘密行动”，您可能已经破坏了一些关系，您现在必须重新建立关系才能成为团队的有效成员。

我认为看待这种情况的最佳方法是考虑整个团队的长期总产出。这次您可能节省了一周时间，但是从长远来看，通过组建一支更好的团队，您可能会做得更好。

我将所有这些告诉您，但是我想您可能已经很了解其中的大部分内容，并且如果您与这种情况不太接近，可以向其他人解释这些内容。

如果您想在讨论中加些引人入胜的话，艾森豪威尔的话很不错：

“计划什么都不是；计划就是一切。”

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

他的意思是，您应该期望更改自己的计划，因此不要在计划中投入太多价值，但与此同时，计划过程将以一种至关重要的方式敏锐地集中精力。您必须先制定计划，然后才能对其进行测试和完善。

+1这是我最近阅读的关于企业敏捷性的最好描述。

每个与敏捷相处的人都指出，这从来都不是这个意思，但是一旦每个人都掌握了指标，这就是您从一个对产品质量没有热情并且痴迷于此的团队得到的东西。首先要测试覆盖率，或者要满足他们每周可交付的截止日期，而不管他们是否将其他任何人都拖入了困境，因为这就是每周达到管理层水平的全部条件。

除了改组之外，我从未见过这样的解决方案。如果您是一家中级公司，没有什么特别的东西可以吸引真正的热情人士，那么除非下一任管理层有时改变方法，否则即使这样也无法解决。

敏捷似乎只在组织中工作得很好，尽管需要额外的，未经认证的工作，但开发团队仍在乎他们是否在乎以制作出优质的产品。实际上，他们必须足够小心才能在自己的时间上做到最好，为改进而战（并愿意花很多额外的时间来重做某些TDD情况下的测试）

您显然在乎运送优质产品，他们显然在乎执行一系列脚本化的动作并获得报酬，以不断清理他们制造的混乱情况。

无论敏捷与否，我都会在其他地方寻找刺激性较小的工作。

如果您全神贯注于敏捷，那么仍有很多地方仍在使用其他方法。例如，几乎任何关于投标或合同的东西。

我倾向于使用一种混合动力。总体计划是瀑布，但是执行中有敏捷性。

我的猜测是，如果情况如您所说的那样糟糕，则您的团队并没有真正使用敏捷，而是只是懒惰或无纪律。敏捷不是要进行计划，而是要变得灵活，敏捷。

我们的一些员工也遇到同样的问题。

基本上，“直到写完为止，我才知道”是我的最爱。因此，我们采取了相反的方式，我们与客户一起定义了带有签核点的可交付成果。最后一个是“现在编写执行X的代码”。

如果我们在与“执行有趣而有趣的代码”相同的可交付冲刺中具有“编写设计/测试/计划等”功能，则第一部分永远不会发生...

但是，如果我放置“直到您说出要构建的内容并且客户端已签名，否则您就无法做任何有趣的代码”，然后

• 首先，您会感到不满，然后流下了眼泪，我不得不做大量的空白工作和额外的努力...
• 然后当您问他们“那么过程如何”时，您就会得到认可，最好尝试纸上的第一个版本
• 那么您就拥有了开发人员可以看到的测试用例，并且可以准确地指出“所做的意味着”的期望。
• 那么客户签下开发项目的拒绝率就会降低80％...
• 另外，您会看到所有开发人员四处走动，拿着设计文件并在设计上互相交谈……他们开始真正地得到它。
• 然后，您将弄清楚如何将项目计划分解为几小块，并从中进行一个过程。

当客户随后从计划中更改时，就会出现敏捷部分，您可以在2周的周期内进行调整，而不必在裤子的座位上坐下来并进行调整。

在我们的案例中，“前期大设计”分为9个阶段（实际生产发布），平均每个阶段有5个子阶段。设计人员和开发人员保持同步，设计人员比开发人员领先1-3个阶段...太远了，开发中的发现破坏了太多的设计，过于紧密和微不足道，以至于使设计成本达到原先的水平。在开发中已经实施了“立于不败之地”。每个子阶段有2-4个Sprint，可供1个开发人员使用。

在较小的项目中，我们只是让相同的开发人员先进行设计>签核>发票>开发>签核>发票...循环进行。

测试命名问题

该测试有很多方面，形式上大约有7个测试类别，每个测试类别都有子部分...稍后的部分之一是“编写自动化单元测试”。

纯粹因为开发人员了解“测试”在此上下文中的含义，让他们“测试优先开发”是一个坏名字，他们将测试视为针对针对接口的测试编写了实际的代码。如果根本不完全是...您可以在编写代码时做到这一点，但是它确实“在开始编写代码之前就根据用例和用户故事验证了设计” ...正确地完成了此操作将删除许多内容通常在开发过程中发现的问题，而其价格仍然便宜得多。

敏捷的关键要素之一是持续改进的想法，以及整个团队都拥有该项目的想法。因此，正确的方法是与团队一起审查问题，并让团队决定如何纠正问题。

一个团队成员一个人走，放弃所有敏捷原则，以自己的方式做事，可能会导致少量代码工作良好，但并不能真正以积极的方式推进整个项目。

使他们工作的一种方法可能是制作一个涵盖您所有sprint待办事项的T-Map。

每个团队都有一个线程，每个冲刺都是一个时期。所有这些都联系在一起（这就是您的团队似乎倒台的地方）。将其固定在某个地方，并吸引磁铁代表配对/子团队。他们甚至可以“比赛”。但是每个人都知道他们和其他团队的位置。如果有的话，就把依赖关系放在这里。

这里的重点是您传达整个过程，但也将其分解为冲刺。即使只有第一个冲刺被放置在那里，而其他时期是空白的，这也应该是完成项目的绝佳路线图。

您有两个问题：需求的形状不足和体系结构不佳。

要求

您既需要总体最终目标，又需要有关实现目标的详细路线图。

在瀑布式世界中，最终目标是功能规格，而达到目标的路线图是项目计划。

在敏捷世界中，一种方法是在史诗般的用户故事中捕获它。然后，路线图就是充实史诗细节的详细用户故事。

我从未对这个故事感到完全满意，因为这部史诗般的故事从未捕捉到足够的肉来传达完整的想法。因此，我倾向于使用一个高级系统需求文档以及一个或两个史诗般的用户故事。之后，路线图就是详细的用户案例。

拥有系统需求文档的好处是，可以提取许多用户案例的接受标准。

可以将高级系统需求文档看作是营销可以用来将产品销售给精通技术的客户的“明细表”。

建筑

“工作表”为您提供的一件事是，它为您正在设计的系统设置了边界。这样一来，您就可以尽早就要使用的体系结构做出明智的决策。

如果您的团队很早就有这样的文档，那么您以后就不必再为重新构建系统而苦恼了。

实际上，您遇到的第三个问题是沟通不畅。沟通是一条双向的街道（或多人之间的双向）。但是，这只是人类的失败，并且（有时）需要超人类的努力才能做到正确。