敏捷不适合所有人

有人再次问我有关他们敏捷过渡的自我评估。 这让我开始思考过渡到敏捷的问题。 我认为敏捷在任何情况下都不适合每个人。

有人声称敏捷已经“跨越了鸿沟”。 当然，许多人都知道敏捷。 许多人都知道跨职能团队的工作量是递增的，提供了征求反馈的功能。 那是在团队层面。

您已经看到了我对一般敏捷团队的总体印象，并且以防万一您不记得了，这又是。

约翰娜的通用敏捷图片

因此，当我说“敏捷不适合所有人”时，我是什么意思？

问题是敏捷不仅限于团队。 团队安装敏捷后，团队就会遇到系统性管理问题。 管理层必须愿意改变。 程序管理必须愿意改变。 人力资源必须乐于改变。 金融必须愿意改变。 好大 我们正在谈论改变组织的文化。

您不必在第一天就改变文化。 但是您最终必须进行更改。 从团队开始是一个好的开始。 如果团队无法进行持续集成和足够小的故事以进行为期两周的迭代，那么敏捷就不适合他们。 当我说两周的迭代时，我的意思是在两周后发布。

任何人都可以过渡到敏捷。 这需要工作和决心。 我看到了以下阻碍人们过渡到敏捷的问题：

1. 敏捷要求您开始管理项目组合 。 哦，也许不是一开始，但最终还是会的。 您不能在项目上执行多任务并成功。 您是否愿意说是的，您现在将提交一些项目，而不是现在提交一些项目？ 而且，您将继续练习，以确保您的团队不会超载？ 而且，您不会像棋子那样移动人吗？
2. 如果您想加入更多的团队，这并不像将一个团队的工作成倍增加那么简单。 那会让你肿。 我已经有几篇关于程序管理的文章，您可以期待更多的文章。
3. 敏捷需要开放的文化。 您愿意在各个层面上给予和接受反馈吗？
4. 敏捷邀请团队认可和奖励。 您是否愿意至少讨论如何进行团队评估，认可和奖励？ 您是否愿意讨论如何拥有不会自动将人们转移到传统管理领域的职业阶梯？ 您是否愿意重新考虑什么是管理以及您需要多少？ 您是否愿意考虑如何将现在称为“管理”的内容转移到普通人的工作中？
5. 敏捷需要透明。 您愿意对谁做出哪些决定保持透明吗？ 您是否愿意对管理决策的界限保持透明？
6. 敏捷不容易采用每年一次的预算。 它邀请增加的资金。 但是，财务部门不了解增量资金。 当我们创建软件时，利用软件进行资本化仍然很困难。 金融更喜欢里程碑。 我们如何帮助金融公司实现大写？ 对于软件即服务，这是一个更简单的问题-您决定何时发布足够大写的字母。 对于非SaaS产品，要困难得多。 你愿意尝试吗？ 金融愿意尝试吗？

您现在能看到敏捷不仅是生命周期，而是组织的巨大文化转变？ 对于项目团队来说，这是许多生命周期中的一个，但是对于组织而言，生命周期远不止于此。

如果您无法保持向敏捷的过渡，则不应感到羞耻或担心。 你不是一个人。 您可以做的就是阅读“ 管理它”！ 您的《现代实用程序项目管理指南》 ，并重新阅读了生命周期一章和附录。 生命周期有很多选择。 而且，借助您对时间框的了解，将功能划分为小故事，对故事进行排名，创建跨职能团队，将测试集成到迭代中，您将拥有出色的RUP或分阶段交付生命周期。

我并不是说敏捷是针对精英的。 离得很远。 我说的是敏捷是针对想要并且能够管理其所需的文化变革的人们的。 而且，如果您尝试执行我们建议的许多技术和项目管理实践，那么您会变得更好。

但是敏捷是目标吗？ 还是为客户交付产品的项目想要您的目标？

敏捷是一种手段。 这不是唯一的工具。 选择适合您文化的车辆。

我全力以赴。 对我来说，那才是最重要的。 如果您需要敏捷评估，那么您就可以选择错误的树。 您需要查看今年是否比去年更有效。

参考：《 敏捷产品并不适合所有人》来自JCG合作伙伴 Johanna Rothman，在《 产品开发管理》博客中。

翻译自: https://www.javacodegeeks.com/2012/12/agile-is-not-for-everyone-2.html