敏捷开发团队管理系列之一出发点与支撑点

bamboosister 2012-09-29

之前的各个系列中,已经涉及了很多团队管理相关的内容,比如松结对编程系列中提到过大型团队分拆为微观开发团队的管理,产品管理系列中提到过ProductOwner团队的管理,敏捷开发绩效管理系列中提到过“用中医理论管理团队”,敏捷开发般若敏捷系列中提到过借助“无我、无人、无众生”的概念凝聚不同团队的目标于一处,等等。

本系列会专门从团队管理的角度,一方面将曾经提到过的内容加以贯穿,另一方面则会提及之外的一些未提及的内容,比如产品团队与开发团队的互动,测试团队与开发团队的关系与工作方式,等等,以供专门从事团队管理的读者借鉴。

出发点:结果导向

敏捷开发团队的外在行为是“结果导向”,而内在支撑则是“团队工作”(TeamWork)。

所谓结果导向,就是直指结果,而不拘泥于形式。

可以被拘泥的“形式”各式各样,比如方式、方法、流程、文档、部门、分工、职责……都是形式。这些形式本来是设立来帮助实现更好的结果的,但是如果拘泥于此,则可能起到反作用。

如果仔细审视敏捷宣言中右侧的内容,就会发现他们都属于形式,而非结果:

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

这些形式曾经保证了众多早期军工、航天、航空项目的成功,但若在任何行业任何项目——比如敏捷开发出现时的互联网行业——拘泥于此,就可能导致失败。

可怕的是,左侧的4条,也是形式而非结果。所以对敏捷宣言的正确理解是:在现今的多数行业中,如果以结果导向为出发点,则左侧的形式胜过右侧的形式。

支撑点:团队工作

为什么说团队工作利于结果导向的实现?

有一个兄弟射雁的例子可以说明:三个兄弟看着大雁飞过,一个说要射下来烤着吃,一个说要炖着吃,另外一个则要炒着吃,三人争执不下,大雁都飞走了。

比如有一个Bug,人们不去分析怎样改正怎样预防,而是讨论是谁的责任;比如有一个任务,人们不去分析怎样做最快,而是讨论应该谁做;比如有一个变更,人们不去分析变更前后甲乙方是否有利,而是讨论应该哪些部门走怎样的流程;比如有一个产品,人们不去分析怎样做才能成功,而是讨论成功后应该怎样考核……就很难直指结果,而陷入部门和个人的纷争之中。

这里倒不是说后者不需要考虑,而是说出发点问题。如果思考问题的第一念头是“我”“我们”“他”“他们”,那么团队协作就建立不起来,敏捷开发也做不好。

ref:http://blog.csdn.net/cheny_com/article/details/7063139

相关推荐