2011-06
1 案例描述
团队建设过程中暴露了很多问题,有问题不能只想着如何规避,而是要直面问题的本质,想办法解
决,成功者找方法,失败者找借口。
2 案例分析
u 文档设计:避免在文档完成后发现整篇文档跑题
如何才能及早的引导文档与用例设计走向我们所希望看到的方向。
文档、用例先把思路列举出来并组内抄送,比如计划下周写某功能的用例,那么在周五时就把大至的思路列举出来,周五例会时大家评一下,然后再按照思路往下写,这样可避免出现大量工作返工。
在一评的时候查漏补缺,二评基本上就是审查了,评审时要积极充分讨论,不能做没有结果的事。
u 版本跟踪:避免同一事件同一时间段多次打断开发的思路
1、首先与开发确认需求、BUG完成时间;
2、达到完成时间时主动询问版本;
3、未到达完成时间,可以挑大家都较放松的时间询问版本进度,但一定要注意次数的控制,一天不超过两次,并且尽可能保持沟通顺畅;
4、对于控制不住的版本要暴露出来,尽量避免跨组直接与开发LTM反馈;
5、对于非常重要的项目,单个功能点成为瓶颈时可以灵活操作,毕竟搞定项目才是最重要的;
另外,版本需要在//172.16.162.92/root/04-release按照项目进行备份。
u 关于"同一问题同一人问多次"的解决思路
1、对于不懂的知识点,读需求、网络上先自己确认,有的自己解决;
2、需求及网络未能找到的组内小范围讨论;
3、小范围不能解决的,视紧急程度做如下操作:
a、紧急的组内铺开讨论;(组内包括系统应用组)
b、不紧急的问题,记下该事务,每日晚会整体讨论(晚会就很有必要召开了);
4、组内不能解决的问题,可以扩大范围寻求解决方案;(录音笔可以比较高效的派上用场了)
u 对外提供版本:确定对外版本的负责人及进度控制
1、每个项目指定对外版本接口人负责监督工作;
2、版本接口人必须把版本机编译的或临时版本整理出一整套可用版本,对外发布版本时使用最新修改或是稳定可用的,视风险及讨论后再定;
3、版本跟踪人必须对开发人员提供的每个临时版本、版本机编译的版本有备份,附上功能修改记录;
4、整体版本必须在1至1.5小时给出,单个功能点需要在对外承诺的时限内给出,可用的临时版本、版本机编译版本均可。
u 关于早会与晚会:进度跟踪
1、定于每天上午9:20召开5分钟的早会,主要用于分配任务;
2、非加班日晚上6:15--6:45,加班日6:30--7:00召开晚会,主要用于跟踪当天工作内容,每个人4分钟左右的讲话,1分钟点评。
3、另外每个项目使用到的资源信息也整理出来,包括MT、MCU、HDU及电视机等。
u 日报、学习及评审:强制要求写学习总结
1、对于学习任务,按照学习时长不同准备5-15分钟的学习汇报,包括但不限于总后项目学习、
新的业务学习与新的知识点学习;
2、参与重要项目评审的责任人除提供评审记录外还需要提供评审简报,内容简洁但要包含所有重要事件,关于此项工作后续不断优化调整
3、每日提交日报,工作内容项描述:
Ø 内容:......
Ø 结论:......
Ø 分析:......
4、单项功能测试,完毕后尝试依据测试结果给出建议及小结
u 所有项目BUG数据入库:便于项目BUG统计
目前在BUG库中创建了一个新的项目,用于提交新的较小的项目产生的BUG。需要注意的是在每
个BUG标题前注明项目名称信息,方便查阅。
u 版本发布:减少版本维护成本
尝试使用增量的方式处理发布版本,首先在//172.16.162.92/root/04-release上创建项目文件夹。
1、 从版本机上取一整套版本作为基线;
2、 新建readme文件,用于记录修改的功能点,日期及责任人;
3、 版本机上出现新版本是及时验证并在//172.16.162.92/root/04-release使用最新版本上翻盖当前版本,保证04-release上为最新的经过验证的一整套版本,这样就方便随时提供给外部。
u 定时沟通:提高沟通效率
尝试开发与测试之间定时沟通,比如以1小时为单位计算,每小时最后10分钟大家集中沟通交流,
避免开发与测试之间无休止的相互干扰工作。
u 交付件:避免漏提文档
1、 评审记录,重要功能进度报告;
2、 项目可测性分析、测试思路;
3、 项目测试报告;
4、 需求总结表,每周由周例会主持人check;
5、 项目BUG列表,由项目负责人发布;
u 环境整理
针对每个项目统一分配设备资源,搭建环境前进行规划,项目完毕后整理还原设备,保持环境整洁。
3 解决结果
希望通过一些措施,可以对团队建设起到一些引导作用,特定环境下做事情可有依据。