请记住Mishkin Berteig这个名字，也许在不远的将来他会成为敏捷运动的一位重量级人物。两个星期前我与同事Helena参访了这位年仅34岁的敏捷专家。在采访中他讲的一些观点是到目前为止我听到过的对敏捷方法最直观、最清晰的解释。采访的内容将会经过Helena的精心整理之后发表在杂志上。但其中有一些东西却是我迫不及待地想写出来的。

    在采访中我让Mishkin举出三个最佳的敏捷实践，他说这个不好回答，对于不同的组织会有不同的答案。不过一般来说，测试驱动，快速迭代是立竿见影的两个最佳实践。而如果说到意义最深远的一个最佳实践，那应该是所谓的“建立自组织型团队”。所谓自组织型团队，在Mishkin看来，是一种新出现的组织形式。与传统的、用指令和权力组织起来的团队不同，自组织团队是由一群志向和理念接近，为了共同的目标走到一起来的人主动结成的团队。以下是Mishkin Berteig的采访记录片断：

***********************************

记者: 有人说敏捷方法是反管理（anti-management），您是如何看待这一观点的？
Mishkin: 首先，管理目的是帮助组织顺利地完成工作。我们有很多不同的管理风格，最常见的是命令和控制型的管理方式。这种方式是建立在军事化管理的基础上，由领导者发布一些教条化的命令。他们做好详细的指令，然后让别人服从这些命令，最后人们也就只是按照这些指令进行工作而已。但是，这显然不是最好的管理方式。在一些情况下，这种强硬的军事化管理固然凑效。但是，这并不是放之四海而皆准的灵丹妙药。在软件行业以及其他更具创造性的行业里，让每一个参与项目的人都具有一定的管理职能非常重要。同样，在敏捷开发中，自我管理和自我组织的团队也是非常重要的。这种团队强调的是每个成员的自发性，而这与传统意义上的管理是不同的。这也是为什么有些人说敏捷方法是反管理（anti-management）的原因所在。实际上，管理还有另外一个目的，那就是为团队服务。管理必须为团队提供支持，管理必须设法为团队清扫障碍，以便团队能够迅速成长，充满创造力，并最终开发出优秀的产品。实际上，在美国和加拿大，很多公司都是如我刚才所描述的一样，他们不喜欢命令式的管理。有意思的是，人们往往觉得权力这个东西很好，但实际上并非如此。因为当你对别人发号施令时，别人往往不听你的。不管是什么命令，人毕竟不是机器，他们有自己的思想和想法。一旦你发现你的命令没有被执行，那种挫折感是很折磨人的。在敏捷团队中，情况就完全不一样。例如，团队成员提出他们可能需要更换一台速度更快的服务器，或者他们需要更换办公室里的桌椅。不管是哪种情况，他们总是需要一个人来办这件事情。这时，管理者说，这件事我可以帮忙。我出一个预算，然后把这个预算交给团队里的另一个人来购置这些东西。这样的结果对管理者来说应该是更加令人满意的，因为管理者自己也在做一些有意义的事情。这正是敏捷方法给他们所带来的好处之一。

记者：请您说说在敏捷方法中最有效的三种实践方式？
Mishkin：这个很难说，因为在不同的组织，情况会稍微不同。不过，对于一些规模较小的公司来说。要开发软件，最重要的可能是测试驱动开发（test driven development）和迭代式开发（iterative delivery）。在项目初期，这两种实践是最简单也是最重要的。但是，从长远来看，还有一个实践显得更为重要，那就是自组织的团队。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。所以，我觉得敏捷方法中最重要的三种实践是测试驱动开发、迭代式开发和自组织团队。

记者: 在您提到的三个实践中，自组织团队（self-organizing team）给我留下特别深刻的印象，那么自组织团队与一般意义上的团队有何区别？它又有何内在特点？
Mishkin: 首先，一个团队和一群人是有本质区别的。一群人是指一帮在一起工作的人，他们彼此之间并没有太多的沟通，他们也并不视彼此为一体。很多时候，我们误把一群人当作一个团队，但实际上它并不是一个真正意义上的团队。在软件行业中，人们往往说自己是一个团队。在他们看来，只要有一个项目，有一两个设计师、构架师、开发人员和测试人员，就能构成一个团队。实际上，它并不是一个团队，因为这些人没有形成共同的工作理念和文化，而是各自在做各自的工作。所以，自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。其次，团队的形成必须经历几个时期。在团队建立初期，成员都很兴奋，大家相互之间了解也很容易。但是，过了一段时间后，问题就会出现了——团队成员的性格各不相同。张三想做这个，李四也想做这个，那到底该由谁来做呢？团队面临的问题就是设法协调好两者之间的矛盾。在经历了初期的一些磨合之后，团队成员就会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人都知道上午九点来上班。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效率非常高。然而，要形成这样融洽的高效团队，也需要付出时间和精力。管理者需要为团队成员提供培训，团队成员也必须不断改进工作。当进入最后一个阶段时，你就拥有了一个真正的团队。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。但是，如何让团队成员朝着目标一起努力是团队自身需要解决的问题。团队成员自愿分担不同的工作任务，而不是等别人来告诉他们怎么做。团队成员们会自己说，我想学习新知识，我可以来做这部分工作。这样，原来做测试的人员也开始学会编程了，做数据分析的人员也可以试着做商务上的工作，而开发人员或许也会发现自己具有设计方面的才能。这是一个自组织团队的内在特点。管理者从来不会说，你是一个优秀的测试人员，你来做这项工作吧。相反，测试人员会自己说他喜欢做这项工作。此外，自组织团队还会告诉管理者它能完成多少工作量。管理者不会说这是你的工作任务，你必须完成它。相反，团队成员自己说这些工作我们可以完成。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。

记者: 那么管理者在自组织团队中担任的是一个什么样的角色？
Mishkin:在自组织团队中，管理者最重要的角色应该是一个服务者的角色。我认为，对于一个领导者来说，服务者是最好的角色。要当好一个服务者，需要具备特定的才能，因为并不是每一个人都可以当好一个为团队服务的领导者。有些人喜欢发号施令，而不想给团队成员提供服务。有些人服务很到位，却缺乏领导的权威。所以，要将服务与领导这两个角色很好地结合起来需要一定的能力。第一，管理者需要具备绝对的真诚与可信。一个为团队服务的优秀的领导者不能向团队隐瞒任何事情。管理者必须询问团队成员的问题，并给与他们充分、彻底的解答。不管出现问题还是好消息，管理者都要告诉团队成员。实际上，要真正做到心胸坦荡对很多人来说并不容易。此外，管理者还需要足够的勇气。因为团队可能需要你来解决一些难题，而解决这些困难可能会威胁到组织中其他人员的利益。所以，管理者必须有足够的勇气来承担这份责任，告诉大家说你可以为团队出面解决这个难题。最后，管理者还需具备远见卓识，他必须对团队目标具有非常清楚的认识，并带领团队实现目标，而在这一过程中，管理者不能强迫团队做任何事情。

*************************************

    去年gigix被ThoughtWorks给招了进去，按他自己的话说，“过上了幸福生活”。他跟我多次讨论过ThoughtWorks的文化和理念。有一次他提到，TW的CEO Roy Singham是个马克思主义者，在他的带领下，TW的主旨根本就不是赚钱，而是把最优秀的developers凝聚到一起来做事情。我知道很多人看到这里会冷笑一声，打心里不相信这种事情，做公司哪有不想赚钱的？但是再仔细想想，你就会觉出不俗之处。一个CEO敢于对全公司员工讲这样的话，就意味着对员工作出了一个心理上的承诺，这个承诺的分量是很重的，如果将来Roy的行为违背了这样的原则，那么他自己肯定会遭到惩罚。因此，这是一个有勇气的、比较真诚的承诺。

    这样一个为公司上下所认同的理念，很自然地会使TW团队区别于其他公司的团队。作为结果，这家名义上不以赚钱为主要目标的公司，就全球范围来说非常赚钱；作为一家以企业应用开发为主业（也就是我们通常说的“接单做项目”）的公司，TW并没有像大部分同类公司一样陷入毫无生气的苦役之中，而是显得非常有活力，非常具有创造力，在为世界各地的客户提供良好服务的同时，还能够不断开发出一些非常出色的开发类产品。奥秘何在呢？我一直对此想不清楚。跟Mishkin谈过以后，我的答案清晰了一点：TW的团队自组织程度非常高，是典型的高度自组织型团队。

    推而广之，很多优秀的技术企业，其团队都具有比较高的自组织程度，团队里洋溢着主动向上的气氛，对于技术创新充满热情，能够开发出非常优秀的技术产品。不过，很多企业在发展到一定程度的时候，开始强调管理。这虽然没错，但是究竟往哪个方向来改善管理呢？是要建立自组织型团队呢？还是建立一个命令式的团队？在一些管理不善的团队里，领导者对程序员的散漫和自由主义深恶痛绝，往往祭出严格的管理条款来加以限制，但很少听说有效的，最后往往是使情况更加恶化，这是为什么？为什么反而在一些从条文上看去松松垮垮，制度上存在不少漏洞（比如考勤制度、报销制度）的团队里，我们却能看到“团结紧张，严肃活泼”的工作气氛？“自组织型团队”为我们提供了一个很好的视角。

发表于 @ 2006年08月17日 09:56:00|评论(loading...)|编辑