【IT168 专稿】    在本次敏捷中国2009大会上，来自阿尔卡特-朗讯的何勉与大家探讨了如何在复杂产品和组织中成功实施敏捷开发方法，同时保持产品质量和开发节奏的持续提高，最终获得商业上的成功。而他对敏捷开发中的个人与团队，以及团队、组织要为敏捷做出哪些改变和努力等方面的的独到见解，同样给人启发。

    2003年，何勉和他的团队从TDD开始敏捷开发之旅，是上海贝尔最早的敏捷开发实践者和推动者，从今年年初，阿尔卡特-朗讯开始全面的大规模引入敏捷软件开发方法。作为团队负责人，何勉在设计开发、项目及团队管理方面有着丰富的经验。

    当被问到谁适合敏捷，哪些特质适合敏捷时，何勉认为：大部分人都适合在敏捷团队中工作，但并不是每一个人都适合在敏捷团队中工作。根据敏捷开发特有的文化，那些具有面向结果、信任透明、尊重合作等特质的人会更加适合敏捷。但是，我们不能因为一小部分人不适合敏捷开发，就对敏捷有所怀疑。正如《从优秀到卓越》一书中所说：我们让适合的人上车，让不适合的人下车。在这种时候，我们必须做出一些牺牲，即使这个人非常优秀。

    那么，成功的敏捷团队为何成功？失败的敏捷团队因何失败呢？在何勉看来，成功的敏捷团队首先要有一个领导式的人物，把团队带上敏捷之路；其次必须要了解自己也理解敏捷。了解自己是真正知道自己想要的是什么，理解敏捷是真正理解敏捷的价值和原则，而不是仅仅照搬或局限在敏捷实践，就号称我们敏捷了。而失败的敏捷团队归咎一点还是对敏捷价值和原则的违背，所谓学到了形而没有学到神。因此，要想成功，必须真正拥抱敏捷背后的理念。

    敏捷实践中最富争议的一个问题是关于敏捷团队的绩效考评。和那些“激进”人士的观点一致，何勉也认为敏捷团队中不应该有绩效考核。团队成员之间技术层次的差距应该通过设置技术等级来实现，而技术等级不应由绩效来决定，而应该基于其实际技术水平由专家委员会来决定。因为在敏捷开发中，我们假定每一个成员都愿意为组织付出，这是敏捷的价值观基础。事实上，在上世纪5、60年代，不管是德鲁克还是盖宁，都提到绩效考评或者设置绩效标准对团队的伤害。

    如果没有绩效考评，敏捷岂不成为共产主义大锅饭吗？如果团队中有人不付出怎么办？何勉认为，在敏捷团队中把成员假定成什么样的人，他就真的会变成这样的人。而敏捷的规则也会产生一定的社会压力，在实施中避免这种情况的发生。正如前面所说，“让适合的人上车，让不适合的人下车”，敏捷团队会自然产生一个这样的“挤出”效应。通过技术等级的评定，而不是个人绩效考评，敏捷希望创造一种工程师的文化，创造一种对技术卓越的尊重，同时避免不必要的恶性竞争。

    在何勉眼中，敏捷简单又不简单。因为简单并不意味着容易。就好像跑马拉松，说起来很简单，只需跑上40多公里。但跑马拉松其实是一个很艰苦的过程，需要更多的坚持和勇气。敏捷亦同！