认识达内从这里开始

一般情况下，软件开发项目都是按照既有的软件框架和编程语言来实现的，很少有同一个软件是用不同编程语言来写的。今天，我们就一起来了解一下，软件开发都应该如何操作。

Scrum不是我变得敏捷所需要的所有东西?也许是，但不大可能，因为没有哪一个框架是任何复杂的组织精益敏捷转型的答案，尤其是当超出IT部门实现整个组织业务敏捷性的时候。

不过，还是有些教条主义者和框架销售人员声称，Scrum将解决团队层面的所有问题，或者，他们的大规模框架适合组织的扩展需求。虽然能获得收益，但真正的转型收益可以让你的组织绩效比竞争者高出200倍，那就需要一种基于务实的不可知敏捷理念的方法，而且要针对团队和整个组织进行真正的定制。

那么，为什么会那样?先，让我们看下教条的通用方法如何妨碍组织的精益敏捷转型。主要的原因是它没有识别或处理你的组织的独特性。即使在同一个行业中，组织也有自己独特的历史、文化、挑战和目标。

组织完全实现特定的框架是给自己帮倒忙，那只是因为他们被某个教练或框架销售人员说服了，认为在其他地方有效的东西，如Spotify模型、Scrum、SAFe、LeSS或其他后者正在推销的东西，对他们自己也完全适用。

他们花时间真正地了解你们的历史、文化、挑战和目标了吗?雅虎和谷歌都有搜索引擎和信息聚合业务，但他们是两个大相径庭的组织。而且，即使是在同一个组织里，小组和部门可能有完全不同的需求。可能小部件部门应该使用看板，而垫圈部门就需要混合使用Scrum和XP。

其次，教条的通用方法无法实现健康、不受约束的精益敏捷演进，无法同时在团队和组织层面成熟。例如，一个典型的命令控制型企业开始时可能只做好了采用像SAFe这样的高度结构化大规模框架的准备;不过，它可能会发展到一个点，此时，一个结构化远不如前者的模型如Scrum@Scale或Spotify模型会更合适。在这种情况下，组织需要意识到这种更为轻量级的方法，并协助过渡到适合他们的方法。

此外，教条的、通用方法压制了创新、学习，违背敏捷原则“团队定时总结如何提高效率, 并相应地优化和调整其行为”;教条的方法会限制团队和组织“相应地调整其行为”的能力。可惜，团队的自然演变和成熟可以看作是违反一贯做法或框架指南，会被教条的教练扼杀在萌芽状态，他会强迫团队按照他奉为“圣经”的著作来实施敏捷。坚持认为这才是“SAFe工厂”，而“我们只能按照一贯做法从事”，其他任何东西都是“Scrum-Butting”，这阻碍了任何发展，极其不利于团队和组织。

教条的以框架为中心的方法还会破坏团队和组织的独立性，为了确保正确地使用了框架，团队和组织会依赖他们的框架教练。任何偏离都会被视为失败，他们会去找框架教练回顾框架，帮助他们回归正轨。这会滋生货物崇拜心态，团队或组织会把遵循框架指南视为敏捷，而很少或不了解框架背后的精益敏捷价值和原则。

损失的还有基本的事实，那就是，精益敏捷是一种理念，而不是一个具体的框架，它主要是关于创建一种赋权文化。敏捷宣言的一条是“个体和交互胜过过程和工具”，这绝非偶然。

现在，我们已经知道为什么教条的通用方法是精益敏捷转型的反模式，而且根本不是敏捷。接下来，我们将看下不可知敏捷方法能为我们做什么。

我们将通过介绍不可知敏捷原则在促进和加速组织转型及精益敏捷演进方面的重要作用来说明。注意，本文包含我自己对这些原则的解释和评论。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。