开发组开发流程及注意事项

这是我的方法论,在所谓敏捷之前,先教会团队如何走路,如果按照一个正常的软件开发流程来做事。

=======================

1,开发过程中注意要遵守以下流程,没有任何例外。负责feature的开发人员应该从接手任务第一天开始,每天更新project status report。

开始阶段:风险评估,技术难点研究,通过邮件或者会议,确定需求分析;
设计阶段:研究设计文档,小组设计评审,具体任务分派,截止时间确认;
编码阶段有:Daily Project status report, 每日代码审查;
收尾阶段应该有:Group code review;需求文档校验;测试计划及结果;项目总结。

2,如果任务比较复杂,问题比较棘手,自己研究了半天时间没有很好的解决方案。请马上联系我或者咨询组里其他同事;如果组内同事也解决不了,再求助Onshore team。先发邮件说明问题,紧急任务马上搭建会议保证及时沟通。

3,项目流程方面,如果需要有例外情况,比如不写什么文档,不做测试不评审,请事先通知我或者项目负责人。

4,在开始阶段对最后整体实现效果有大致理解,可以预估技术难点所在,并且实现进行研究和求助。对于项目可能有的需求变化有一定的预估和计划。在项目开始阶段或者空闲阶段应该研究技术难点。

5,允许犯错,但是要确保同样错误不要再次出现,从问题中吸取经验教训。

6,每天的工作都应该有结果产出,代码或者是文档。学习应该有文档总结,项目应该有流程设计文档/代码/测试文档,项目进度有每日进度报告。每行代码在checkin之后的当天时间, 都应该有两个人review通过。

7,代码review原则:不要在下午三点半以后还checkin代码(可以留到第二天上午),如果有例外,应该通知reviewer留出审查时间。

代码应该直观易懂,不要额外解释,不用过多注释说明。代码格式应该符合English正常语法格式,或者遵照以前onshore同事代码样式。每行代码必须能解释清楚,根据哪个需求来的。对于Peer review和Group review中发现的问题,必须逐条回复(改或不修改),确保没有遗漏,Group review需要填写正式review结果文档。

8,在你写代码之前,确保自己已经:a)了解所使用技术的大致用法。b)读过这项技术的大体教程或者代码实例,可以用最简单的能体现设计意图的代码完成大部分功能点。c)以前没有遇到的新项目的设计方案,确保设计方案与我沟通过,由我负责技术决策。

请避免以下情况发生
1) 将就完成,马马虎虎,不求甚解。– 在写代码之前问问自己,真的清楚知道在为什么需求编写什么模块的代码么?
2) 需求不清楚,也不与onshore沟通澄清,在任务不清楚的时候就开始动手编码。
3) 没有设计讨论,自己觉得没有问题,直接开发。有问题,不做优先级和风险评估,先开发了再说。
4) 代码不是每天checkin,累积三五天;需要checkin的时候,一次加入大量代码修改。或者checkin以后不作代码评审。不注释,命名不规范,不关注静态分析或者调试中出现的异常log信息。
5) 代码写完了,就认为是项目完成了,没有设计评估没有文档没有测试。
6) 只有最后阶段才说明有问题,在开始时不考虑如何技术实现或者觉得不会有问题,不做风险评估。
7) “我觉得没问题,但是也没有检查代码和需求。”“代码为什么好用?不知道;出问题的root cause?不知道”“这段代码干什么用?别人就这么写,我不知道,没研究过”“这个技术上肯定实现不了,没法做”

发表评论