敏捷意味着什么？

我们有一个项目，每个人都说我们将以敏捷的方式进行，但是我怀疑我们已经清楚地了解了什么是敏捷。

在以前的项目中，我们召开了计划会议，然后定义了产品积压日志，并在2至3周的冲刺中将工作分配给了开发人员。每天早晨，我们都会召开Scrum会议（每次似乎要进行1/2小时的时间），然后每个开发人员都继续进行。在sprint结束之前几乎没有人编写任何测试，并且未完成的工作被添加到下一个sprint。

开发人员几乎没有互相交谈，开发也没有涉及TDD。实际上，大多数开发人员在开始时就有一个规范，并且只是在为冲刺计划的2或3周内着手进行。与客户/利益相关者几乎没有任何沟通。

质量检查通常在几个月后才参与，到那时，我们发现缺少要求，这进一步增加了我们必须做的工作量。显然没有反馈回路。

所以我的问题是，我们哪里出错了，如何防止团队犯同样的错误。

根据定义，您所描述的不是敏捷 （敏捷宣言）， 而是每天状态会议的瀑布。敏捷意味着容易适应变化，如果没有与产品所有者以及客户之间的交互式反馈回路，那么正在发生什么变化？

敏捷是指通过与产品所有者/客户的不断沟通来实现快速故障。最好早早失败，少做些工作，少丢掉。而且您不会陷入“我们没有时间正确地做，因为我们花了很多时间做错了事情，即使它会导致失败，我们也需要继续走同样的道路” ”。

听起来您的管理正在执行“ SCRUM，但是...”，其中“ but”是他们丢弃所有他们不理解或不同意的SCRUM内容，并以与往常相同的偶然瀑布方式进行操作，但是加上新的闪亮流行词名称。

在SCRUM中，日常的站起来不是要向管理人员传递状态，而是要强制开发人员进行交互，因此您知道团队中的其他成员正在做什么，并且可以互相帮助，并且不会重复工作。如果每个人花费的时间超过45秒，则说明您做错了。对于团队来说，这是透明的，如果一个人要在几天之内给予相同的身份，而这本来应该是一天的工作，那么团队可以早日解决人员问题。

如果您在编写代码时没有测试彼此的代码，那么您也没有正确执行代码。测试应该嵌入到过程中，而不是事后思考。质量保证应包括在计划会议中，并估计测试需要多长时间。

如果您没有达到Sprint的承诺并延期进行，则说明操作不正确。如果您要投入过多的工作，那么Sprint就是关于承诺的事情，请停止这样做，如果您不能准确地致力于可交付成果，就无法引入任何可预测性或可重复性。

Jarrod提供了一个很好的答案（+1），我想在这一点上继续一点。

敏捷不仅仅是产品所有者（客户）与团队之间的快速失败和反馈。这是有关所有利益相关者之间的快速反馈。真正敏捷（这直接来自于manifesto）就是要意识到存在该过程仅是为了帮助开发人员交付更好的产品。高于流程的人员意味着一旦团队认识到您现有的流程不起作用，您就可以对其进行更改并使其生效。

“混乱但……”也是一个问题，但这种硬币有两面。如果您看一下宣言，您会发现这与团队和使工具/流程适合您有关。没有两个团队是相同的，因此每个团队的运作都会略有不同，这没关系。您当然可以采用整个Scrum方法论，并尝试将其贯彻到底，看看是否对您的团队有用。

另一种选择是，不要将其他过程推向团队，而是让每个人都遵循Scrum告诉您的操作，而是尝试敏捷方法：与团队进行沟通，看看您是否可以共同确定每个领域的问题和解决方案。然后逐步介绍工作方式的变化，以便解决问题。

可能要花一点时间，但是...

1. 您将首先解决最大的问题，这将对您的团队交付产品的能力产生最大的影响
2. 通过发现迫在眉睫的问题并参与解决方案的提出，您的团队成员将理解为什么某些做法很重要，而不会仅仅因为被告知要这样做而简单地做到了。

如果我们在Scrum和设计模式之间进行类比，那么我建议的工作方式将类似于编码为模式，在这种模式下，代码应尽可能简单，仅在需要时才收敛于设计模式。与仅选择一种设计模式并随之滚动（即盲目选择Scrum及其所有过程作为一个集合）相反，这有时会使代码比原本要复杂的多，难以维护。

要理解的关键是，敏捷不是要提出一种新的做事流程。这是关于不断变化和对现有流程/实践的不断调整。

如果团队（及其管理人员）真正想要“敏捷”，那么他们应该首先阅读并讨论《敏捷宣言》及其负责人。然后选择一种已经创建的敏捷方法（例如Scrum），对其进行一些培训，然后从此开始。我建议您在修改它之前仔细跟踪一段时间，但这只是我一个。

他们还应该深入研究工程实践，以支持所选的特定敏捷项目方法。