您的位置:知识库 » 项目管理

打造高效的技术团队,我会关注的7个点

作者: jinpu  发布时间: 2011-06-24 22:21  阅读: 3227 次  推荐: 1   原文链接   [收藏]  

  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

  我的开发经验告诉我,一个bug越晚修复,被修复的可能性越小,将来产生危害的可能性越大。试想,你刚提测或者发布的代码,出现的bug,往往你能最快得到解决它需求的时间,而时间在项目管理上是非常重要的。反之,如果积累了很多bug,且有一定时间了,那修复它就需要对所有相关的系统进行了解,这将花费大量你可以用来度假,娱乐的美好时光。所以,从团队一开始就贯彻这点,可以释放成员修复bug的压力。

  6:给团队成员一个安静的环境

  最近很多同学告诉我,白天基本上没有什么效率,总是受到各种骚扰。我们做一个假设:假如A同学进入最佳状态需要30分钟,那么如果他比较惨,在30分钟间隔内,他总是被打断,那么他一天都无法最高效的工作。又或者同学B google查询一个技术问,花费2分钟可以解决,但问同学A只要20秒钟(好吧,同学A表达很清晰)。这样同学B节省了100秒钟,而同学A至少损失了30分钟。

  从这个假设,我们不难发现,如果能避免团队成员受到外来信息的骚扰,他就有可能更加高效的工作,从而写出更好的产品。而常识告诉我们,人不可能一直高效的工作,所以,我们应该利用好无法集中精力的时间去进行一些沟通。但分出这个界限显然十分困难,所以我觉得不妨这样:规定每天的安静时间段,在这个时间段,其他人都不能来打扰这位同学,而在非安静时间段,可以随意访问,从而让这位同学形成一个新的生物钟(人体的自我调节能力是非常强悍的)。

  7:给员工最好的工具

  做同样一件事情,如果使用工具A,消耗的时间为5分钟,而使用工具B,消耗的时间为1分钟,那我一定给员工提供B工具,即使B工具的价格是A工具的5倍。因为,假如人在连续高效工作中的抵抗干扰时间为1分钟,那么意味着B工具能保证高效工作的时间连续,而A将可能分散了用户精力,导致需要更多的时间才进入最佳状态。事实上,之所以要更好的cpu,更大的内存,更好的编译器,更好的编辑器,多显示器,都是让程序员尽快能回到核心业务上来,而在等待上花费更少的时间。

  同时,别忘了,一把好的椅子也是维持更长高效工作时间的保证,所以,别吝啬,给员工更好的椅子吧,他们会感到你的温怀。

1
0

项目管理热门文章

    项目管理最新文章

      最新新闻

        热门新闻