敏捷反模式是什么？

什么是反模式？这是一种你认为会改善事情的模式，但实际上却适得其反，这让事情变得更糟。有时这是可见的，有时则不是。下面是我观察到的反模式列表。

待办事项列表

在Scrum中，待办事项列表的目的是给出一个关于项目或产品需要完成哪些工作的概念，从而使其变为现实。从总体上讲，这是产品负责人的粗粮愿景。当团队得到backlog时，他们会分解需求并确定需要涉及的内容。

未被定义的backlog有多种形式。其中一种形式是产品负责人太忙，导致无法在高层次上定义他们想要的东西。因此他们只定义了即时的Sprint或两个Sprint的工作价值。这意味着团队不了解长期目标，只知道眼前的目标。这种形式并没有赋予团队对任务的所有权。

另一种形式是，产品待办事项列表变成了产品负责人自己完成细分的任务列表。同样，这也剥夺了团队的所有权。此外，这也意味着任务之间可能没有连贯性，给开发人员提供的上下文很少。

产品待办事项列表不会产生工作组件。衡量敏捷项目的最佳方法是在每个间隔（Sprint）结束时需要运行成果，并为生产做好准备。这样，SDLC中的每个人都在努力尽早完成工作。开发人员开发工作实例：无论原始程度如何，测试人员都可以测试该原始实例（附带说明）。在整个文档完成后，最终总会有一些可交付的成果。

即使产品积压工作需要相同的技能，也不会按优先顺序排列或在多个流中按优先顺序排列，即，积压工作中的项目分配给个人，而不是团队。这再次从团队和个人那里取得了开发的所有权，尤其是如果要决定执行任务的方式而不是制定出来的话。

最后，也是我已经说明过的一点， 在团队有机会分解任务并了解涉及的内容之前，将任务分配给个人。

规  划

在Scrum中，有两个计划会议：Sprint计划1和Sprint计划2。 Sprint计划1是与产品负责人一起检查backlog，并决定团队在Sprint中接受哪些故事或任务。这为团队提供了背景信息，这样他们就可以了解产品负责人的愿景，并能首先考虑一个任务需要花费多长时间。这让每个人都与产品负责人的愿景保持一致。

在第二次Sprint计划会议中，团队将深入研究故事并进行细节设计。粒度任务确定后，就会获得Sprint卡片。它还有助于确保团队中的每个人都了解正在发生的事情的细节。它允许团队成员为任务做出贡献，即使他们没有直接参与到任务中。这也使团队在执行任务时具有主人翁意识。

反模式存在于管理层或团队认为他们知道自己在做什么，并决定他们不需要计划会议或只需要最小计划时。这可能是为了节省时间、减少会议等。实际上，这种情况非常罕见，而最终的结果是是团队成员不知道在这一Sprint期间发生了什么。时间会浪费在解释这种情况上面，有时情况需要的解释不止一次，因为一个团队成员可能会问另一个成员同样的问题。

每日站立

每天的站立是为了显示每天的工作进度。这会涉及三个问题： 我做了什么？我该怎么做？是什么阻碍了我？

当会议变成了状态会议时，反模式就发生了。新闻一发布，谈话就偏离了工作的进展。这可能导致一种反模式，也就是站立时间过长，我就曾经参加过一个多小时的站立会议。站立目的是通过站立让人们感到不舒服，所以会议很短（不超过15分钟）。如果站立会议时间超过15分钟，人们就不会听了。

另一种反模式是向产品所有者或经理提供状态更新。这是团队会议，也就是说，这是为了让团队知道你在做什么，并在需要时向你提供帮助的机会。

还有一种反模式讨论的是既没有记录在板上也没有记录在任务管理软件中的任务。很明显，团队中所有成员的所有任务都应该被如实记录。

没有展示

展示窗口是向利益相关者展示工作增量的地方，它还可以作为一个迷你切换会话。如果没有展示，那么就有了跳过工作增量需求的“机会”。

回  顾

回顾的目的是回顾在上一个Sprint中所做的事情， 并查看有没有可以改进的地方。要注意的是，这个改进必须是 可测量的。

团队刚开始时的一个常见反模式是，他们没有形成系统、有逻辑的回顾体系，导致无法得出有价值的反思成果。团队可能会取缔这一流程或者延长回顾的时间来解决这个问题，这一措施一旦被采纳，团队就真正错过了找出改进方法的机会。

另一个反模式是更改团队进行回顾的频率。团队并没有进行固定长度的冲刺（例如，可能正在执行看板），而倾向于把回顾推迟到开发阶段结束。那么回顾就可能是几个月后的事了。在这几个月中，会发生很多事情，如果没有短周期的回顾，团队就会错过很多改进的机会。

最后，不设置任何可衡量的任务也是一种反模式，一个好的指导方针是 制定SMART目标。

• 具体的
• 可衡量的
• 约定
• 现实
• 基于时间

指挥与控制

第一次开始使用敏捷或Scrum时，产品负责人或Scrum Master成为经理是很平常的事。发生这种情况时，旧的命令和控制习惯就会起作用。经理将任务分配给开发团队中的成员：任务是根据工作时间而不是根据故事点分解的。在这种情况下，经理从团队中拿走了任务的所有权。通过分配任务，甚至更糟的是，分解任务，经理保持了所有权，而开发团队只是引擎中的一颗齿轮。

由于团队不再被授权，这可能会导致失败。他们在解决方案中没有发言权，因此只能盲目地按要求进行工作。是的，Scrum Master的职责是保护团队免受这种事情的侵害，但是如果Scrum Master没有权力，而所有权力都在产品负责人手中，则该角色将变得毫无意义。

教  育

如果团队不了解Scrum或Agile所需的内容，而只看表面，那么必将失败。了解什么是Scrum，了解它的历史，了解它在其他行业中是如何实施的。例如，一切都始于丰田，研读丰田生产系统，阅读杰弗里·里克（Jeffrey Liker）撰写的《丰田之路》（The Toyota Way）。在彻底了解之后再决定如何去做。

完成的质量和定义

敏捷反模式往往是缺少“完成”的定义，或在开发过程中跳过质量检查。

质量检查可以采取这样的形式： 在开发完成之前不进行单元测试、代码审查等。这可能发生在几天或几周后，通常会因为时间的关系而略过。为什么这是个问题？通常情况下，当问题在开发之后被发现时，开发人员必须重新回到开发功能时的思维定势，这个过程需要时间。然后，他们必须再次执行并重新检查。

如果检查是开发过程中进行，就可以节省开发人员重新投入节奏所花费的时间。这样节省出的时间通常比最初的测试任务要短得多。最初会不习惯在工作时进行质量检查，因此操作上会降低生产率，但是从长远来看，尤其是习惯这一步骤后，在工作时进行质量检查实际上可以节省更多的时间。

另一个反模式是没有定义完成或接受标准。同样，由于时间限制，这一标准也被逐渐忽略。但由此引发的问题是，由于成果不完整，所以工作又回到了开发人员手中。为什么不完整？因为一般在这种情况下，开发人员并不知道他们必须迎合这种情况。定义完成或接受标准可以使开发人员对用户需求有一个了解，并可以进行可靠的检查以衡量其代码依据。

缺乏长远眼光

什么是缺乏长远眼光？就是 只关注当前问题而忽略了总体解决方案。

这里举一个例子。假设团队必须进行从开发到测试的部署。这是一项繁琐的工作，部署大约需要一天的时间，但并不复杂。

如果团队花了两天时间来自动化这一任务，那么一个小时内就可以完成部署。但是团队没有时间去自动化，需要立即部署。那么需要花费一天的时间从开发部署到测试。如果必须部署到预生产版本，需要花费一天的时间。

到目前为止，团队已经花了两天的时间。如果前提是任务自动化，则将花费两天零两个小时。

第三个阶段，团队要进行生产阶段的部署。如果继续使用手动部署，将额外需要一天的时间，总共三天。如果使用自动化任务，仅需要两天三小时，和手动部署相比，自动化部署会节省五个小时。

从长远来看，重复执行任务的次数越多（例如，将必须重新部署到所有环境中），节省的时间就越多。

我认为这个问题有点像贫困陷阱。例如，超市的价格比较便宜，但自己又没有汽车或公共交通工具。这就让人不得不在当地的便利店以高昂的价格购买视频杂货，最后妨碍了你去超市省钱。

在反模式中，就会陷入基于时间而非金钱的贫困陷阱中。

缺乏沟通

• 你是否有过这样的经历：你觉得自己被遗漏了一些其他人都知道的事情？有一些在饮水机或咖啡机旁产生的对话可能会影响到你，但你本人并不在场。
• 你是否遇到过这样的情况：别人告诉你“你应该知道”，但实际上这是你第一次听到？

这个反模式很重要。不当的沟通能够扼杀一个敏捷项目，尤其是当你因不了解某些东西而被斥责时。员工的士气会下降，工作效率也会下降。

你需要重新思考你的沟通方式。如果有人在饮水机旁讨论了什么问题，把其他人召集起来，重新讨论这个话题。

确保将来需要的所有内容都已详细记录在案，以便日后（例如六个月后）可以取用。确保文档采用易于搜索的格式，例如Wiki。

最后，做结对编程。这是让所有人都在同一页面上的一种好方法。你可能会觉得两个或更多的人在一台电脑上做一件事效率不高，但是对于交接工作来说，没有什么比一起完成工作更好的了。

没有营造一个安全的环境

最后一大堆的的反模式与环境不安全有关。我的意思不是说要照顾磨损的电源线（尽管这件事确实应该立马去做）。我的意思是要营造一个环境，让人们可以畅所欲言而不会被压制，并鼓励人们勇于提出与工作有关的异议。

如果你让那些持有不同意见的人闭嘴，那么他们可能就会这样做，然后，你就会失去最有价值的反馈。