敏捷教练的进退之道

　　最近，敏捷教练Morgan Ahlström在邮件列表“敏捷教练支持(Agile Coach Support)”上求助：有的客户声称想要更多地从敏捷中获益，但实际行为却与该目标背道而驰，如何面对这种窘况?

　　下面是他所描述的情况：

　　你是否受雇担任敏捷教练，结果做的事情名不副实?你是否偏离了任务方向?你是否在兢兢业业帮人实现敏捷，只因为自己拿了这份钱，即使对方根本不想改变?你是否得一面搞改革，一面服从潜规则?你是否要借助于其他什么头衔来推动大家走出泥潭?实际工作中你还有其他什么可行的方法?

　　D. André Dhondt的想法：

　　在我看来，改进和敏捷是两码事。我会专注于对方想要改善的地方，或者对方感觉难受的地方，把“敏捷”放在一边。我仍然要做沟通、互动，以人为本，但不会拘泥于敏捷这个术语。

　　Peter Green跟帖说：

　　每次有机会做教练，我们都指望能改变世界。经常落入的误区是：如果客户没把敏捷贯彻到底，就是我们的失职。不管怎么说，事情还得一步一步来，采取持续改善(Kaizen)的方式——不积跬步，无以至千里;不积小流，无以成江海。

　　团队和组织的改革，包括很多细致入微的工作，我们可以带动大家一起向着敏捷前进。其过程的漫长会令人沮丧，但缓慢的改变仍然是改变。

　　Tim Ottinger从历史眼光看待问题，同时提出警告：

　　我正在酝酿的一个口号：“形象工程”是“不断实现”的大敌。

　　按照一套框框来做事，并非早期XP和Scrum的要求，也不是达成它们的手段。它们改变了团队合作中一些深远的东西，它们来自对真正高质量软件开发的尝试。因为它们看起来真的很牛。XP是为了实现更多、更好、更快、更安全、更干净的一套深层次变革，而被大家所采用。我们正在悬崖边上，“敏捷”现在几乎成了拦路虎，而不是快车道。大家为了守规则而守规则，而不是从团结中获益。

　　稍后他又补充说：

　　我曾经面对的尴尬是，程序员和经理们就在那消磨时间，等着我什么时候走人，等着“敏捷”的风头什么时候过去。太可怕了。

　　另一方面，如果你真触动了少数几个人，那也算没白忙。如果能接近旧有套路的切入点，你就可能促成一些改变，并点亮星星之火。别搞混了，“挫折”与“失败”不能同日而语。

　　Lior Friedman的选择：

　　压力一旦增加时，人们通常会重拾旧的习惯。名义上采取哪种流程，并不重要，我只要做到让事情100%可见，确定让每个人明白团队正处在什么位置，以及接下来朝哪里走。任何一点能促成的进步，都会让我喜悦。

　　我也会实事求是地评估自己，如果对我的ROI投资回报率是正值的话，就继续在这个岗位上，基于现有条件，努力做到最好。

　　George Dinwiddie对务实精神有共鸣：

　　尽管我的工作大多是训练团队朝着“敏捷”过渡，最终目标却不是“达成敏捷”，而是帮助人们更有效率地开发软件和其他系统。

　　“帮助”是让对方得到好处，提供他们想要的，不是我想要的。如果我在这没有帮助，就是该离开的时候了。当然离开也会有其他原因。

　　Tim Ottinger充实了讨论内容，链接内容是他和Jeff Langr写的一篇文章，标题为“敏捷的误区(What Agile is Not)”。

　　查看英文原文：When to Cease Being an Agile Coach?

原文转自：http://www.kuqin.com/software-engineer/20110613/91900.html