如何更好实施敏捷

如何更好实施敏捷2016-02-02 infoq Dan Mezick众所周知，敏捷运动并没有产生那种完全可行的革命性结果。如果现行的方案可行的话，那么最起码现在，成千上万的组织早就已经达到一种自立、持续、独立的敏捷状态。

很显然，事实并非如此。

故事里总是充满了各种典型的失败模式。一开始好像还进行得不错的组织，最终还是再次沦为了瀑布流的实践方式。组织聘请教练并花费数百万美元就是为了在其所衡量的标准下仅仅得到25%到30%的改善！

大规模软件开发是一项非常艰巨的任务。敏捷的思维方式、相关原则、模式和实践都能起到极大的辅助作用。问题是如何实现这一目标。很明显的是，极少人（如果有人的话）知道如何连续地提供长效且持续的大规模敏捷实施的方案。到底该怎么做？谁又知道怎么做呢？作为一个咨询和指导社区，我们没有向客户和更广阔的世界兑现敏捷的承诺。这糟透了。

通常，敏捷实践都是通过授权的方式实现的。规定的实践并不关心人们的需求、人们的想法以及人们的感受。死板的规定会减少人们的参与度，并且导致那些睿智又极富创造力的员工开始“退出”并且不再参与。

通常，我们使用以下模式来实现敏捷方法，并且常常是在一个小型团队进行了小型试验测试以后：

当权者说我们正在“迈向敏捷”。

当权者说我们会使用一些特殊的实践，如Scrum、看板或者其他的敏捷实践、方法或框架。坏消息是这不是可以讨价还价的。

当权者基于他或者她所从事过的规定实践为经验选择了一个教练。通常，都是熟悉Scrum技能的教练。这名教练被强加给下属，就像那些规定的敏捷实践一样。

由于经历了可控性、包容度和归属感都较低的经验，员工都自发的不再参与了。他们已经意识到这个新游戏是十分模糊的，并且明确规定是必须要参加的。敏捷实施不是一个令人享受的游戏，因为这个游戏本身并没有被明确的定义，并且还没有机会选择退出。

在典型的敏捷实施方案里参与的方式并不是通过邀请而更像是一种授权或者规定。这里有一个针对那些失败的敏捷实施方案的秘方。回想一下那个关于开放式敏捷实施的设想，授权会降低用户参与度，但是邀请和可选择的参与却可以增加参与度。再回想一下另一个关于技术的设想，用户参与是可以快速而持久的进行敏捷实施的基本要素。

那些软件程序的开发者通常都有以下特性，特别是跟普通人比起来：

高智商

性格内向的倾向

包含以下心理的自我形象

我是被雇来解决问题的

我很聪明并且富有创造性

我是因为有技术专长才被雇来的

授权式的敏捷实施一般都倾向于遭到那些聪明的工作问题解决者的排斥。其中一个原因是，这些人真的很喜欢解决问题，包括那些“流程问题”，比如“在我们公司该如何实现敏捷。”现在，既然他们大部分人都是比较内向的，如果我们不询问他们的想法，那么真正可怕的事情就会发生了：他们也不会告诉我们。

通常，那些负责该工作并且解决问题的人都会有一些有用的观点或想法。但是不向他们求助相反还颁布一个规定的授权，我们将错失得到帮助的机会，并且还会制造出相当大的潜在怨恨隐患。这是一个双重的负面结果。我们渴望得到那个最好的想法，我们也渴望得到一个参与的机会。