敏捷软件开发实践-Team Management

介绍：

对于敏捷开发团队来说，团队管理也是必不可少的，我带领的团队分2部分，1个是开发团队，一个是测试团队。开发团队，我大体上比较放心，因为毕竟已经运行1年多了，文档充足，而且技术方面也有很多资料或者现成代码可以参考，测试团队是刚组建没多久的，因为原来测试团队放在onshore那边，但是现在他们测试团队解散了，所以我们这边就组建了一个测试团队。这里共享下我管理团队的一些经验。

实现方式：

其实我也不是一个专职的团队管理者，因为我是一个纯粹做技术的人，我甚至连PMP都没有。我曾经做过专栏，我做过云计算顾问，我是公司架构组的成员，但是做管理，我实在缺乏经验，尽管如此，我已经在公司担任3年Leader了并且大大小小接手过4-5个项目组，所以虽然谈不上经验分享，至少还是能说点体会吧。因为我们的团队是我们公司最优秀的团队（证据是我们的团队前面有个@标识，看过士兵突击都知道老A吧，差不多这个意思） ，所以团队的配置极高，一半以上的人都是高级工程师。

(1)一般高级工程师多数有个特点，就是想得比做的多，写文档/邮件时间比写代码多。我们团队也不例外，因为毕竟在我眼里，高级工程师更多的要做宏观的设计，而不是简单的编码工作。但是活总要做的，那么如何让大家都有积极性去做他们的assignment呢？这是对我的第一个挑战。 我的做法是：尽量安排一些有挑战的活给他们，因为做程序员的人多数比较”傲“，如果他觉得某个活对他的能力几乎没有提升，那么它就可能没有足够的积极性去做这个活，我也不例外~. 所以和聪明人打交道的方式，就是要挑战他。 比如，虽然说我们很多需求都是美国那边的客户给的，但是很多需求，如果你只是实现它，或者是很优雅的实现它，或者是不仅实现它，还要考虑到今后的可重用性和可维护性，那么这个实现成本就完全不一样了。所以，对于高级工程师，你尽量放点变态的需求给他，这样他就有做好这事情的动力了。

(2)中级工程师就不一样，他们因为经验不是很丰富，很多功能也许对他们来说不是很熟悉，所以他们很难做到直接秒杀手上的活，但是在认真的态度下，他们在规定时间内完成手上的活也是没有问题的。所以对于他们来说，鼓励他们，给足他们信心是最重要的。因为任何人，包括我自己，都是从初级，中级，高级工程师一步一步走过来的，所以他们的有着无比强大的潜力。每个人都很有潜力，如何去引导这股潜力，就是你manager要做的事情。对于我来说，首先要尽可能的相信他们能力，绝对说某个任务某某某绝对完不成这种话。其次，千万不要包办代替，有些任务，也许我亲自出手2小时，但是别人做要2天，就算这样，我也不能出手，因为我一旦帮他们，就会让他们产生依赖感，反正搞不定有人帮忙，这样对于他们的成长是不利的。我一直相信一个真理： 其实，在研究一个难题时候，越是接近终点，你的技术提升越大，就像过河的兵一样，越迈进王城，你战斗力越强，而你彻底征服它的时候，你收获的是整个过程，是整个知识体系而不是一个孤立的知识，换句话说你收到的不是几个卒，而是一个有建制的军队。我自己也是这样的，记得我6年前刚大学毕业（其实我已经学生时代实习过几年了） ，我有个习惯，就是有问题绝对不轻易问别人，哪怕这个问题我要研究上几个星期，也不放松，后来慢慢的，我对自己的个人解决问题能力十分自信，因为以前研究问题很慢很慢，后来经常这方面锻炼，就变得一个fast solutioner，以至于到现在我一直和我团队人吹嘘：只要给我一个调试器，我能解决几乎所有问题。当然这夸张了，但是至少对于个人成长是非常有好处的。我记得我大学毕业第一年，我就直接从初级工程师变高级工程师级别了，当时还很自豪

。现在我也吧这些经验共享给团队的成员。我们团队有个人，2年前刚和我在另外一个项目组合作时候，他还是初级水平，我一直在用正确的经验影响着他，他也变得非常擅长独立思考和解决问题，尤其喜欢做R&D的活，现在，他工作3年不到，水平也是准高级工程师的水准了。

上面讲到的是如何差异化对待团队成员，下面还有一个话题是，对于团队，一定要有时刻knowledge share,code review,summary等提升团队能力的制度。

一般来说，大家都不太愿意看别人的代码，因为读别人的代码总比读自己的代码要吃力很多，但是作为一个程序员来说，读别人的代码的意识和能力是必须有的，因为很多时候，不要重复发明轮子，你更多的时间都是在学习，研究，重用别人的代码，比如开源框架，或者比如遗留的项目代码，或者接管另外一个人手上的活等等。一定要硬着头皮去读代码，因为读代码不像读小说，他是二次构造的过程，一个程序高手，类似架构师一样，当读代码时候，可以很不经意的在纸上画画逻辑，结构。甚至还能看出对方写代码的缺陷，这样对于自身素质来说也是提升。

Code Review也是很重要的，因为很多问题都是在Code Review中被暴露的。

Knowledge Share也是一个成熟团队的标志，我们沿用了eBay的做法，在eBay经常有技术沙龙，大家都去共享下一些最近的研究成果，因为一个人的时间精力有限，不可能各个方面都去涉猎，而共享知识技术可以最快的让大家的水平都提升，从而走的是”精英路线“ ，我非常喜欢走精英路线，因为一小股精兵强将比一批老弱病残要给力的多。我们团队每个星期都会有一些knowledge share，多数还是和项目相关的，比如某些非常棘手的Bug Fixing，比如某些功能的实现，或者也可以聊一些最新技术等等，我们团队水平提升很快，我本来和团队说的，现在我们团队有5个高级工程师，我希望1年后大家都是高级工程师以上水平。这也是我期待的。

总结：

(1)对于高级工程师,多安排写有挑战的任务来激发热情

(2)对于非高级工程师，多给鼓励，信心并且方法方面正确引导。

(3)Code Review, Knowledge Share是构建成熟，积极向上团队的必不可少的实践。