敏捷开发 敏捷个人_我认为“敏捷”的发展方向是第1部分：您是否需要敏捷方法？...

敏捷开发 敏捷个人

我上周在Agile 2019上发表了讲话。 我既度过了愉快的时光，又心碎了。 美好的时光是与人见面并重新建立联系。 令人心动的认识是我们的行业正面临着巨大的麻烦。 这是我的想法，我认为“敏捷”行业的发展方向。

我看到的“敏捷”问题

这是我上周看到的问题的摘要：

• 太多的人认为“敏捷”将解决所有问题。 只要团队做到这一点，“敏捷”就是万灵药。
• 太多的人认为团队是“敏捷”的。 他们没有意识到管理是问题和解决方案的必要组成部分。
• 我遇到的太多人了-在会议之外确实是这样-想“答案”并想要食谱。
• 太多的人没有读过一本书，一篇博客文章，什么也没有。 他们拿起单词。 他们不知道这些词是什么意思。 例如，他们不知道“敏捷”是一个形容词，而不是一个名词。

人们想要这些都没错。 我希望有一个解决方案。 如果仅团队需要“敏捷”，我们可以解决后期和问题缠身的项目/产品中的大多数问题。

我会喜欢很多东西的食谱。 我很乐意为我的写作提供捷径，而不必阅读所有为准备写作而读的书。

所有这些都表明，太多的人认为敏捷方法是项目方法。 人们没有意识到敏捷方法是一种文化变革。

文化需要管理层的参与。 我认为，如果管理人员先改变，那么整个组织将发现他们自己的敏捷方法。 我们可以创建具有更好文化的组织，而不是我们看到的所有扩展性的废话，从而带来更好的结果。

您是否需要敏捷方法？

敏捷不是灵丹妙药 。 对于敏捷工作，没有通用的方法，我将Scrum包括在内。 让我们讨论为什么。

您的产品开发需要多少更改？

我遇到的许多想“安装敏捷”或“使用敏捷”的人都不知道这意味着什么。 他们没有考虑他们必要的变化率。

我可能会使用VUCA或Cynefin或Stacey Complexity曲线。 向人们/团队询问他们所解决的问题的类型时，我取得了更好的结果。 如果他们解决了完全确定性的问题（有一个正确的答案），那么它们将位于此连续体的左侧。 他们不需要敏捷的方法。

我们大多数人都在中间。 我们需要反复尝试一些想法和实验，以便在合理的时间内找到合理的解决方案。

一直在右侧遇到问题的人们需要进行大量的实验，以便他们可以对问题进行递归来理解它，并在中间进行更多的尝试。 他们需要创建小型，可以安全通过的实验。

经过合理数量的实验的敏捷方法最适合中间的问题和右侧的问题。 最左侧问题的人不需要敏捷方法。

关于为什么Scrum不是通用答案：Scrum对于并置的团队或重叠4小时之内的团队非常有用，因此他们可以进行协作。 这对于一次只处理一个和一个项目/产品的团队也非常有用， 并且可以预测一些中断或支持。 如果您的团队没有落入这些界限，Scrum将会非常痛苦，您可能会停止使用它。 更糟糕的是，您可能会认为所有敏捷方法都不适用于您的团队。

（我将在下一篇有关管理的文章中讨论实验时间。）

“敏捷”不是银弹

敏捷方法并不是这个问题的答案有麻烦交付团队。 是的，团队级别的敏捷方法会有所帮助。 这可能对团队有帮助：

• 查看瓶颈（工作卡在哪里）
• 查看其在制品（正在进行中）
• 创建较小的工作块（以某种方式限制在制品）
• 看到团队的技术卓越

也许更多。 敏捷方法可帮助团队了解他们在做什么和没有做什么。 （ 创建成功的敏捷项目是关于如何帮助团队选择和使用适用于他们的敏捷方法的信息。）

而且，我与许多Scrum Master交谈，他们说他们的团队成员是单独工作的。 没有配对，蜂拥或围攻 。 他们的“团队”是个人。

这些人还说，每个团队成员还有其他工作，而且这些工作不会进入团队董事会。

这些人中的大多数人都在小瀑布中工作 ，努力地完成每个“冲刺”的工作。 我用引号引起来，因为这些人中的大多数人都没有阅读《 Scrum指南》。 他们使用的话。 他们不知道这些词是什么意思。

我不会讨论人们滥用Scrum单词的所有方式或他们如何滥用Scrum意图的所有方式。 我之前讨论过我对认证的担心。

我将在下一篇文章中讨论管理的必要作用。 当我完成这些帖子时，我将链接到整个系列。

翻译自: https://www.javacodegeeks.com/2019/08/agile-approach.html

敏捷开发 敏捷个人