分类： IT职场
2011-05-10 10:32:47
1. 人员素质
a) 首先要说的是人员的基本素质。一个人不是科班出身，或者在计算机领域就没有开发经验，或者说反应略微有些迟钝又不愿意去努力改进的，这些人可能不适合做程序开发，我觉得大可不必招进来，我在这方面的原则是宁缺毋滥。
b) 每个团队最重要的就是人，人的基本水平就决定了这个团队的水平，团队到达一定规模后单靠增加人员数目并不能加快开发速度，反而会有所下降，因为这会牵扯一部分人的精力去培训新人，降低了这些人（通常是团队的骨干）的focus time.
2. 明确的目标
a) 产品人员要明确需求，并负责使开发人员明白需求。不要不给文档说就这么做吧，再就是自己还没想清楚就先做吧，拿开发当小白鼠，这会浪费时间，也会使开发人员有挫败感。
b) 每个开发人员也得有自己的目标，每天都有自己的todo list, 使开发有条不紊。开发最烦的就是被打断，特别是很多低效的会议，下面我会在Focus time里说。
c) 有些目标最好量化。比如有个PM给开发的任务是代码优化，什么是代码优化？我改到何时算完成任务？无法考评。最好能把目标量化，比如代码优化-目标是error tracker中异常数降低到每秒3个。还有类似加了XXX功能提高保留率。原先retention是多少，要提高到什么程度？这些都是可以量化的。
3. 经常交付
a) 任务分解。一般一个大的项目可以分成很多步骤或者子项目来完成，一有完成（测试通过，至少跑完unitest）就发邮件通知其他相关人员。使每个模块都是一个可降级的服务。同时也让开发人员感到项目的确是可控的，而且有足够的成就感。
4. 渗透式交流
a) 密集交流，一般一个项目的相关人员坐在一起，当A和B交流的时候，C(项目相关人员)也有可能听到，C可以立即参与讨论。这样就能提高效率。
b) 避免低效会议。如果真到了要组织一次大型会议的时候，就要列好计划，要讨论的议题，规定好session，避免漫无目的讨论。
5. 工具
a) 工具是用来提高生产力的，一个好的工具能节省大量的开发时间。当一个问题需要重复劳动来解决的时候，就需要做成一个工具了。工具要简单易用，不要过度设计，假如真的需要提供给第三方使用，那就得认真设计了。
b) 不要重复发明轮子。有一些开发辅助工具已经存在的了，而且是经过很长时间的考验的，这就不需要自己来开发了，拿来用就行了。
6. Focus Time
a) 在<小团队的敏捷开发方法>中提了两个问题：
1. 是否团队所有成员都知道他们最重要的两件优先任务？
2. 是否所有成员每天有2个小时不被打扰来做这些工作？
我们团队规定每天上午10-12点是Focus time， 在这期间禁止开会，软件演示等干扰性行为。
b) 不要动不动就找人：我们找个会议室碰一下吧。能用1-2句话讲完的事，为什么非要拉到会议室谈上1-2个小时？一个开发人员思路被打断后，往往需要20分钟回到原先的思路，假如一天被这样打断3-4次，他们宁可选择停止思考，因为他们总觉得被打断是常事了。
个人的一些粗浅看法，有的是目前在应用的了，有的做得还不够好。有问题请回复邮件交流。
