SCRUM的局限性

当我们在不断加深我们对SCRUM的理解、并用之改进日常工作和生活的同时，我们却发现了SCRUM在指导研发工作、特别是复杂的软件研发时存在很大的局限性：即SCRUM涵盖了软件开发生命周期中的构建阶段，却匮乏对团队的初始创建阶段、项目启动、软件即将发布以及维护软件阶段的指导价值。

 

我们是要否定SCRUM吗？ 不！在我们设想放弃之前，我们还需开放性的问问自己，SCRUM真的没有对构建初期、发布阶段的工作产生任何作用吗？我找到了答案，无论你是否认同，我希望在这里分享，SCRUM的方法的确没有对这些阶段的研发有何指导，可是我们聪明的大脑非常愿意寻找修复这个缺陷，在所有方法论理没有制定的、涵盖的部分，我们的大脑延伸了SCRUM方法，尤其是敏捷4句宣言。这就可以解释为什么大家在“没法可依”的情况下，仍然默契地、毫无顾虑地在软件完整生命周期的各个阶段坚守“SCRUM“的职责和SCRUM的原则。

 

当你发现你的团队同样有了勇气、智慧去批判地继承权威的理论的时候，无论他们对与错，你都要赞许他们追寻真理的愿望。而我非常愿意和团队的“明白人”探讨和贡献给IBM敏捷领导力团队我们各种尝试后的经验和心得。也正是因为我不怕被人耻笑，勇敢的挑战了Ken Schwaber 的SCRUM方法，后来我才能加入IBM的敏捷领导团队，成为2010年的IBM SCRUM Fellow。在往后的一年半时间里，我参与到了IBM敏捷方法论DAD、分布式敏捷的挑战以及Agile at Scale的研发中。

 

在我记忆里，这些方法的诞生都源自于我们对敏捷、SCRUM和其他核心的敏捷方法在复杂环境中的思考和怀疑中产生。这些方法我视为瑰宝，因为它们的诞生让我感动的的非方法本身的成功带来的喜悦；更多的，是因为它们见证了宝贵的一段历史。我们的领导团队因为有开放心态，得以充分理解和接受新思想；直到山穷水尽疑无路之时，我们仍不放弃真理，因此经历了诸多痛苦与挣扎；在这之后我们的思想又经历了再接受、再批判、再接受，直到改良落定的心路历程。