敏捷开发绩效管理之十：阿米巴经营之软件团队经营什么（中）
这是敏捷开发绩效管理的第十篇。（栏目总目录）
经营技术
经营技术是说，不要只是把做产品/项目的过程当作完成任务或提升自己能力的过程，而是要当作为企业积累技术的过程。
这听起来很容易，但做起来有难度，比如这几个问题：
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
每人可以为10个博主投票，所以如果看到其他常去拜访的博主，也请投上一票！
敏捷开发绩效管理之十：阿米巴经营之软件团队经营什么（中）相关推荐
- 敏捷开发绩效管理之九：阿米巴经营之软件团队经营什么（上）
这是敏捷开发绩效管理的第九篇.(栏目总目录) 若正在为长期没有得到职务提升而感到困惑,下面的内容可能会有所帮助.因为越向上的职位越不像一个打工者,而是像一个企业的经营者. 何为经营 对一个开发团队而言 ...
- 敏捷开发绩效管理系列之八：阿米巴经营之序言
这是敏捷开发绩效管理的第八篇.(栏目总目录) 每次敏捷开发培训课上,最备受关注的问题可以说是团队管理和绩效管理. "敏捷开发注重团队合作""敏捷开发不考核个人" ...
- 敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效）...
这是敏捷开发绩效管理的第四篇.(之一,之二,之三,之四,之五,之六,之七) 最近在看德鲁克的书,发现其中很明确地写着"企业的绩效只存在于外部,而企业内部只有成本"的概念和说法,下面 ...
- 敏捷开发绩效管理之六：敏捷开发生产率（中）（功能点分析，FPA，简化的功能点）...
这是敏捷开发绩效管理的第六篇.(之一,之二,之三,之四,之五,之六,之七) 直接估天数或用故事点估天数,都很"程序员".如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统 ...
- 敏捷开发绩效管理之七：敏捷开发生产率（下）（简化功能点分析，NESMA，两级简化）...
这是敏捷开发绩效管理的第七篇.(之一,之二,之三,之四,之五,之六,之七) 续前文-- 功能点估算 第一级简化 上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够. 谁能在刚拿出2页 ...
- 敏捷开发绩效管理之五：敏捷开发生产率（上）（故事点估算）
这是敏捷开发绩效管理的第五篇.(之一,之二,之三,之四,之五,之六,之七) 度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容. ...
- 敏捷开发绩效管理之三：个体动力之源——同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）...
这是敏捷开发绩效管理的第三篇.(之一,之二,之三,之四,之五,之六,之七) 如果有10个程序员,笔者相信至少有9个是勤奋的.但是如果有一个10人的程序员团队,其中1个人不是勤奋的,而且仍然拿到与其他人 ...
- 敏捷开发绩效管理之二：用中医理论管理团队及其绩效（绩效考核，团队管理，自组织团队）...
这是敏捷开发绩效管理的第二篇.(之一,之二,之三,之四,之五,之六,之七) 团队管理是个由来已久的话题,各式各样的管理理论和方法层出不穷.笔者因为工作原因在过去16年里与100多家企业的团队或团队领导 ...
- 敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效）
这是敏捷开发绩效管理的第四篇.(之一,之二,之三,之四,之五,之六,之七) 最近在看德鲁克的书,发现其中很明确地写着"企业的绩效只存在于外部,而企业内部只有成本"的概念和说法,下面 ...
最新文章
- 面试被问到秒杀系统，这个点你一定得答到！
- 你现在还在使用刷脸支付吗？不，刷手支付已来！！！不侵犯隐私、秒速支付...
- dvwa_xss_储存型
- 跟我一起学.NetCore之路由的最佳实现
- 新炬首架梁铭图：从70万字SRE神作提炼出7千字精华与君共勉
- java枚举类型转换为Struts2的select的数据
- record.php play.php,record.php
- 单因素方差分析graphpad_【SPSS】单因素方差分析（比较均值gt;单因素ANOVA）
- 揭晓AI算力池化的五大场景
- 程序员面试被问到“三次握手，四次挥手”怎么办？
- 荐书丨被Dubbo虐过吗，反击开始！——《深入理解Apache Dubbo与实战》
- protobuf根据DebugString字串反解pb对象(及基于此的简单配置实现)
- 供给、需求、有效供给、有效需求
- 程序员的数学【线性代数高级】
- 迈达斯GTS-NX网格模型(FPN)导入Flac3D 6.0
- Openharmony之repo manifest XML文件格式介绍
- 豆制品加工黄浆水污水处理设备工艺特色
- 基于QT4的智能温度采集控制系统
- OA系统中 流程审批数据库的设计
- SQLT(SQLTXPLAIN)