项目经理如何打造高效的技术团队?
下面七点是给广大项目经理的建议,让你打造出高效的技术团队。其实人性化管理是其中的精髓,比技术更深远。
1:使用分布式的版本管理系统
如果你觉得不需要使用版本管理系统,那我们沟通会有代沟,如果你是 CVS、SVN 的粉丝,或者由于某种原因没有使用过分布式版本
管理系统,比如 git,那强烈建议你去看一下“why git is better than x”。
2:一键式发布
这里发布的目标位置,既可以是开发机,做本地测试;也可以是测试机,为 QA 准备好捉虫游戏的森林;还可以是生产环境(或者 beta
环境),供用户直接访问。
如深度 xp 一键恢复系统一样,一键式发布需要自动完成很多工作:代码自动化测试(开发阶段),打包压缩,编译(测试阶段),数
据同步(外网)。也许还有很多工作要加入进来,但核心是是否能通过一个脚本的执行就全部完成所有流程,这点至关重要。如果中间
多出几个环境,那将来一定会引入发布的灾难。
3:TDD / BDD 请对你自己写的代码负责
不要为了 TDD/BDD 而 TDD/BDD,只要能及时获得自己写的代码运行情况的反馈就行,也无需一次把 test case 都覆盖全。对于没有
任何单元测试的代码,将来想引入单位测试,将举步维艰!如果,你认为测试完全是 QA 的事情,那你就花大笔的钱去招聘一个规模庞
大的 QA 集团吧,期望他们能让你偷懒。
4:使用靠谱的 bug 记录工具
人脑的潜力虽然无限,但大脑皮层只会对进入缓存区的数据做高效的反应。记忆再好的开发,也可能被各种牛魔鬼怪折磨的忘记了昨日
的痛(曾经产生的 bug)。所以,从团队第一次提测,就应该使用靠谱的 bug 记录工作。所谓好记性不如烂笔头就是这个道理。
那一个靠谱的 bug 记录工具应该要记录这些数据:
bug 复现的整个操作流程
产品需求中的正常情况
出现 bug 后,变成为什么情况
谁将负责修复这个 bug
bug 最后修复没有
至于怎么修复的 bug,是重新设计还是漏提交了代码,我觉得无关紧要。如果一个 bug 修复的经验值得分享,可以单独做一次团队的
技术分享,而这往往是由于对现有产品的(技术或者其他的)信息获取不够导致的。
5:尽快修复 bug
1 / 2