谈谈团队文化
今年团队来了几个新人,新人初入职场,除了专业技能的学习,职场基本素养的培养也很重要。但是很多时候,我们忽视了这一点。职业素养一方面需要自己领悟总结,一方面优秀的团队文化也有很重要的引导作用。这也是今天为什么谈谈我们的团队文化的一个出发点。
一个有执行力、高效的团队,团队成员间一般都存在某种默契,这种默契就是团队文化。有了团队文化,才能凝聚一群志同道合的同学一起工作,有了一群志同道合的同学我们的工作效率才会非常高。
往往这种默契一般都靠心领神会,说了反而矫情。对于这种可说可不说的东西,我倾向还是说一说,因为沟通就是信息同步,保证大家在一个频道上交流,减少信息传递损耗。
公司文化是团队文化的基石,公司在各个层面推进敏捷转型,所以敏捷肯定是我们团队文化的一部分,这包括敏捷纪律、任务看板、持续集成看板、代码评审纪律、计划会、每日例会、展示会、反思会,每周分享会等等,这一块就不多说。
除此以外,我们的团队文化还应该包含如下行为准则:
开放公开
- 日常开发公开;
- 故障定位公开;
- 代码全体所有;
- 技术共享;
- 文档随手归档svn文档库;
- 积极主动分享;
有效沟通
- 用数据说话。代码评审时,先提供你的自测结果日志数据,而不是仅仅的一句“自测通过”;讨论故障时,先提供你采集的故障信息数据;讨论方案时,先提供支持你方案的数据;讨论问题时,先提供相关的背景数据,比如邮件、文档;
- 保持简单。Don't make me think。测试接口要有使用帮助,不要让用户思考;打印信息要简练,不要干扰用户,软件界面要傻瓜,避免歧义困扰用户;
- 邮件沟通。要做到标题清晰,不乱改邮件标题,不破坏mail thread,邮件正文信息充分,讨论时不要带有个人情绪;
- 开发需求讨论。先讨论原始需求,再讨论解决方案;避免把某个解决方案作为需求来讨论;
- 集体讨论时,善于运用头脑风暴、SMART、鱼骨图、思维脑图等工具;
- 用户故事清晰。用AIS结构描述,每个用户故事给出验收用例和完成定义;
- 邮件要有响应,比如询问的问题要有答复;指派的任务要有进展汇报。邮件不能到你这里,就“石沉大海”,烂在自己的手里;
- Review Board代码评审的意见要及时处理,不管是否合理,都需要认真对待并一一回复。不能敷衍了事,伤害团队代码评审的积极性;
- 任务按重要性和紧急度划分成4类,分类处理。一般原则,重要紧急的任务用马上处理,并日报汇报跟踪;紧急不重要的任务马上处理;重要不紧急的任务作为高优先级任务放入敏捷backlog list;不重要不紧急的任务作为低优先级任务放入敏捷backlog list。
- 阻塞一天的问题,需在每日例会上发出求助;如得不到反馈,逐步升级;
- 做事要有始有终,要有输出,要闭环,要善于运用PDCA工作法;
- 注重承诺是职业的基石,这对任何职业都是如此,软件开发也不例外。注重承诺,赢取客户的信任是职场成功的第一步。
- 迭代领取的敏捷任务是一种承诺,承诺在展示会前要完成;
- 开发某个功能是一种承诺,承诺保证这个软件功能的内部质量和外部质量;
- 答应的deadline是一种承诺,承诺全力以赴完成;
- 如果无法完成,要勇敢的说不,不要盲目承诺,破坏我们的信任基础。
-- EOF --