敏捷开发绩效管理之十：阿米巴经营之软件团队经营什么（中）

这是敏捷开发绩效管理的第十篇。 ### 经营技术 经营技术是说，**不要只是把做产品/项目的过程当作完成任务或提升自己能力的过程，而是要当作为企业积累技术的过程。** 这听起来很容易，但做起来有难度，比如这几个问题： 1. 团队是否有一个可复用的技术库？（DLL，类，函数，各种层面的） 2. 团队是否有一个机制令得这些库被充分利用？（一个可度量指标就是代码行/功能点，越低越充分） …… 一般而言若不进行有效管理，20人团队的代码冗余率可能在95%左右，也就是95%左右的代码是多余的。在2004年的一次技术改造中，一个19万行，13人×9年的产品，被改造为1.3万行，1人×1.5年的相同产品（更关键的是缺陷少了，这次改造的直接动因就是原来产品的缺陷众多而且隐藏很深）。 这并不是个例：这家公司是纳斯达克上市的上千人的电信软件公司，其开发和管理强于一般的中小公司，后者的技术水平可能更差。但由于普遍而言人们使用别人代码的比例很低（我们常常感觉到用过别人的东西，但若自己数数，又会发现不过就几百行代码而已），所以人数越多可压缩的比例越高；再加上由于多数人连自己的复用做的也不好，所以在未完善管理的情况下，对代码进行大规模压缩的潜力一般都接近在2×人数倍以上。 注意这个例子中，较少的代码不但有更高的生产率，质量也随之提高，甚至更加明显。 类似这种规模和周期的软件及团队，都应该刻意地在开始就不要只以完成当前任务为唯一目标，而开始架构和积累整个技术架构。 “若刚开始的时候老板不给充分的时间怎么办？”一则我从来没有见过老板指着我们的可复用库说：“不要编写这个，直接给我垒代码”；二则及时被给予足够的时间，多数团队也没有形成这样的可复用库；三则可复用库的生效速度是很快的，若前三个月投入复用的时间还没有赚回来，那么多半做错了……考虑到这些，多数时候缺少对技术的经营，其实是我们软件人员自己的问题。 ### 经营过程 过程就是人们做事的方法，说大一些，就是“企业文化”。 文化是很容易被谈论又很容易被忽视的东西。很多底层的程序员能看到远在天边的企业文化，但却看不清楚自己面前的编码文化。 在2001年的一个团队里边（就是我第一次感受松结对编程与139团队的那个团队），刚开始只有5个人，人们不需要专业的测试人员而仰赖高手帮助新手查看代码和自己自主测试来保障质量；一年以后，当团队扩张到25个人的时候，这个传统仍然存在——此时我们的专业测试人员只有2个，而且只负责整体测试。 这是因为在团队成立的开始，团队尝试建立起一种以高质量为荣的团队文化，所有制造大量的缺陷程序员（包括刚开始时的我本人），都会同时受到鄙视和帮助，人们可以选择接受两者，或者只接受前者。结果是接受帮助的人逐渐摆脱了被鄙视的局面，他们继承了这种传统，进而帮助后来的新人。 可以被经营的过程有很多，有很多完全无需领导授权即可进行，另一些需要在进行一定程度后说服领导进行下一步的支持。这些过程包括： 1. 代码审查 2. 开放的办公室空间 3. 白板和经常的讨论会 4. 基于白板的简单设计（比如预想陈述） 5. 看板 6. 松结对编程 7. 1-3-9团队 …… ## 谁来经营 “如果老板能让我放手管理，我也可以经营好我们的团队。可是……”这是常常听到的一句话。 实际上，老板一般都是“放手”管理的。多数团队的领导者（尤其项目经理）与自己团队相处的时间，超过再上一级的100倍。若这些时间——其实应该说是精力——被充分用来经营团队，而不是简单地执行传声筒和工头的角色，本文所说的经营完全可以实现。 **本人正在参加CSDN博客之星评选，如果您经常来本博客阅读或曾经下载《火星人敏捷开发手册》，欢迎投票（需要登录）：** [http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) **每人可以为10个博主投票，所以如果看到其他常去拜访的博主，也请投上一票！**