从敏捷部署成功案例中学到的5个教训

敏捷开发——就像许多其他重大事业一样——在纸面上看起来是一个很棒的想法，但实际上却难以执行。

出现这种挑战的部分原因是敏捷，正如它的许多支持方法所执行的那样，似乎需要“全力以赴”的努力。事实上,敏捷宣言的四个核心信念下面列出的似乎需要对公司的开发团队、资源和流程进行全面改造:

可以理解的是，考虑到他们的严格要求，敏捷实现失败．但正如人们常说的，有志者事竟成。保护你的敏捷部署不受负面结果的影响，可以通过向那些在你之前的公司学习来实现——包括下面介绍的五家公司:

不要不必要地忽视敏捷的前景

许多使用传统瀑布式开发的公司很快就放弃了采用敏捷的可能性——不是因为他们看不到它的好处，而是因为他们认为它会与公司已经采用的其他认证和结构相冲突。

(有些人认为敏捷过程与公司内部更线性的过程和结构相矛盾，从而产生了向敏捷方法发展的阻力。)

最常被引用的冲突来源之一是能力成熟度模型集成(CMMI)，它基于对可重复过程和文件证据的关注。然而,随着这是技术提供商CollabNet发布的一个案例研究证明了在这两种方法之间找到共同点是可能的。

在大型CMMI ML-3金融机构的情况下，CollabNet分享:

该公司聘请了敏捷和CMMI顾问来寻找可行的解决方案。举行了广泛的磋商和研讨会，涉及整个组织的团队成员。我们开发了一个最初的流程，捕捉了敏捷的核心要素，并与公司的一般工作实践相适应。”

最终，正如在企业案例研究中所期望的那样，该机构继续采用CollabNet的技术来自动化与他们的新流程相关的许多文档需求。

然而，这里的教训并不是正确的技术提供商使敏捷实现成为可能(尽管它肯定没有坏处)。相反，通常的约定，如“敏捷和CMMI不能一起工作”，在相关各方有足够的动力时，往往是不成立的。

为必要的专职人员腾出资源

Tantus Technologies, Inc.的Scott Granieri分享了他公司的一位联邦客户是如何在2011年进行敏捷部署的。尽管Granieri指出了这种转变带来的许多挑战，包括克服瀑布式开发的悠久历史，客户评估的CMMI ML-3状态，以及阻止雇用新人员的预算限制scrum联盟白皮书在美国，内部组织问题构成了最大的障碍之一。

(敏捷推出过程依赖于5个关键因素。核心是文化契合度——敏捷对组织文化的适合性——和资源需求。)

Granieri将客户的工作描述为“支持超过23个系统和80多个团队成员，执行操作和维护工作以及投影增强。”因此，可以理解的是，释放出能够完全致力于敏捷的员工几乎是不可能的。

Granieri说:

矩阵式的团队环境并不能最佳地与敏捷模型保持一致，并且在实现敏捷的全部好处方面给我们带来了障碍。当人们进出团队时，团队凝聚力会受到影响，需要更多的指导，团队速度不会很快提高，速度本身也变得更不可预测。”

更复杂的是，Granieri的客户项目中没有一个团队成员对敏捷或敏捷方法有广泛的了解。一旦Granieri和客户确定了一个商业智能试点项目，并且有一个经理愿意接受学习新的开发流程的挑战，并投资于执行Scrum流程所需的培训，最终成功就来了。

回顾他的经历，Granieri给出了以下建议:“在可能的情况下，我们强烈建议将团队专门用于敏捷开发。如果您不能让员工投入工作，我们建议您寻找其他解决方案。替代的解决方案可能包括让尽可能多的sprint团队成员投入工作(如果不能全部投入工作的话)。”

Granieri的经验和建议指出了一个关于敏捷开发的真理:三心二意的努力只会产生三心二意的结果(或者更糟)。如果你的公司无法腾出必要的资源——这里指的是人力资源，尽管员工的可用性并不是唯一需要的资源——那么最好将敏捷的推出推迟到晚些时候。

考虑所有相关利益相关者的需求

仅仅释放必要的人员并不足以保证敏捷部署的成功。早在最初的规划过程中，就必须在每一步中注意保护所有相关利益攸关方的需求。

在英国的ProjectSmart博客上，IT顾问Adam Alami说道分享了一个敏捷推出的例子按照大多数标准，这被认为是成功的。谈到团队成员给予的积极反馈，Alami分享道:

“参与者发现，使用Scrum流程使他们更加紧密，使他们了解彼此的思维过程，并有助于建立团队精神。他们认为这种方法促进了知识共享。大多数与会者还认为这个过程非常有活力和活力。这个过程激励了整个团队，所有团队成员都觉得自己有发言权。”

然而，与此同时，Alami发现干系人由于无法看到项目的大局而感到不满，并且缺乏集中的文档和沟通的方式使他们感到好像缺少关键知识。

认识到这些需求——既关注好的方面，也关注坏的方面——使公司能够在怨恨情绪增长之前解决问题。例如，在Alami的案例中，修改敏捷框架来解决全局问题或创建内部Intranet作为一个知识仓库和透明、包容的交流平台，可以帮助涉众对敏捷过程有更积极的看法。

(使用内部团队，所有利益相关者都可以集中托管重要的文档、知识，并与项目中的其他团队成员进行沟通。这确保了所有人都能访问关键信息。)

从阿拉米的例子中学习。不要等到问题出现。不断地征求涉众的反馈，并以一种支持他们的需求的方式对其采取行动。

从错误中吸取教训

Railinc坦率地承认他们的第一次敏捷尝试失败了；不是因为方法本身的弱点，而是因为他们选择了错误的试点项目。

“我们已经尝试过将敏捷软件开发方法应用到我们的一个技术项目中，但失败了一次。虽然客户确实雷竞技rat更喜欢我们，但事实证明我们选错了项目。我们没有足够的基础设施来支持它。我们的开发团队也太过臃肿。这样的例子不胜枚举。这是不对的。”

Railinc没有被吓倒，他再次重复了这个过程——这一次，带着合适的项目和合适的人。事实上，他们的第二次敏捷推广的成功带来了一个意想不到的积极结果:它给了他们在将项目完全推向市场之前扼杀项目所需的洞察力。

Railinc的例子给我们上了双重课。首先，有一条显而易见的格言:如果一开始你没有成功，你应该不断地尝试。然而，更有趣的是，不仅要从实现错误中学习，还要从新流程生成的数据和洞察力中学习。

敏捷的推出可以成功，但仍然会产生数据，表明所涉及的项目将是失败的。尽管这些认识可能令人沮丧，但要学会庆祝，在这个阶段发现失败对你的公司来说，比在漫长的瀑布开发周期结束时发现即将到来的厄运要小得多。

不要害怕改变你的方法

尽管敏捷开发需要大量的投资，但要小心沉没成本谬论，它会阻止公司根据需要改变方向。

以西门子医疗服务公司为例由Bennet Vallet在InfoQ网站上描述．尽管西门子最初使用Scrum/XP方法推出了敏捷，但几年后，他们发现，从他们的相对故事点和速度图中得出的指标并不能很好地支持他们管理发布开发的能力。

为了提高结果的可预测性和发布预测的准确性，西门子将他们的方法修改为看板方法——在整个过程中全力以赴。Vallet表示:

“我们采用了大爆炸的方法来实施，基于这样的信念，为了达到这种规模的结果;我们需要在所有团队以及企业项目管理层面全面部署看板。”

在推出看板的第一年之后，西门子将公司横跨三大洲的40多个团队全部迁移到新方法。Vallet承认西门子过去在Scrum方法上的失败直接促成了公司看板推广的成功，这证明了一个重要的教训:回到起点，改变你的方法，以一种适合你公司的方式前进总是可以的。

现在，我们想听听你们的经验教训。根据你自己的经验，你会在这个列表中添加什么?在下面留言分享你的经历。