管理,顾名思义,管的是人,理的是事.研发过程管理的目的是以较好的方式组织工程师,以较快的速度和较高的质量完成产品.但实际的过程中往往呈现出一些"混沌"的现象,由于工作流程的不清晰,一方面导致员工对完成某件事情没有明确的流程,而另一方面,这种不清晰,也导致了资源的争夺、步骤的忽略、事项的遗忘等等.其结果,看上去工作热热闹闹,实际上混乱无序.如果没有合适的流程与制度,这种管理上的混乱,也随着人员的增多如滚雪球般增大.

笔者认为,不论哪种管理方法、思想,具体落实的时候,都是制定一系列的工作流程与制度.只不过好的管理,其流程能够提高工作的效率和有序性,好的制度能够使员工的生产率更高.

套用一句伟人名言,实践是检测流程好坏的唯一标准.要让流程能够发挥作用,必须定义明确,具有良好的可操作性,凡是可以用流程规范的地方,都应制定相应的流程.这种例子也多不盛举,最明显的例子是工业生产的制作工序,第一道工序是什么,第二道工序是什么,每一道工序要达到什么标准,规定得非常明确.可想而知,如果其中某道工序规定模糊,那么不同的人的操作结果可能各不相同,最终导致产品的缺陷.又如法律法规,美国的法律规定总统任期内无法执政,由副总统接任,如果总统、副总统都不在了,那么就由下议院议长临时代理,至选举出新的总统,下议院议长也不在了由参议院议长代理.如果他们全不在的情况下,就只能军管了,由国防部长代理.细致的流程,应尽量考虑到过程中的种种可能性,并制定规范,这样的流程最具有可操作性,当然在指定的时候,也要考虑效率的问题.同样,如果实践中发现某些流程存在问题,也应该有修正制度,否则就容易陷入僵化的境地.

具体到软件的研发,要制定的流程就太多了,比如:新功能模块的开发流程、风险问题的处理流程、大Bug的处理流程,小Bug的处理流程、资源冲突的处理流程(比如码流仪)hh.

以新功能模块的开发流程为例,业界也有许多理论:RUP、XP、瀑布、迭代、原型、敏捷方法hh.但对实践来说,都比较粗,在具体的实施中,必须进行一定的修整.笔者在分析研究了XP方法后,针对实际情况,提出如下流程:

目的:

a. 提高代码质量,减少Bugs,降低后期维护量

b. 提高知识共享度与组员技能水平

c. 降低人员流动带来的风险,如出差、调离、辞职

d. 形成必需文档

e. 加强反馈与沟通

步骤:

1. 当新的需求来到的时候,开始本流程

需求:

2. 由Team Leader或者其授权者浏览、了解需求,做需求初步评价:

a) 如其中存在平台性技术难点,则走预研攻关流程,不走本流程

b) 填写需求评估文档:可行性、大致进度、开发要求,要点

3. 负责人组织需求分析讨论会议

a) 讨论方式:全体、局部与微型会议(微型会议是指最相关的3人左右,做在座位上开会,推荐)

b) 安排一个开发者与一个审查者(负责人可为其中之一),要求审查者的经验、技能较高或者相当开发者

c) 如有必要,则拆分为较小的模块,对每个小模块进行后面的步骤

4. 开发者对需求做进一步深入了解,将其中抽象、不明的东西具体化,出需求草案,草案中可带有疑问.

5. 审查者独立审查需求草案

6. 审查者与开发者共同讨论需求草案

a) 2人约个时间,开发者协助审查者审查

b) 指出其中需求不明之处

c) 讨论其中的疑问,如不明确,则咨询需求提出者

d) 尽量讨论现场一次性确定疑问,以避免过程反复

7. 开发者根据审查结果修正草案,之后将正式需求发送给Team Leader及其他组员

设计构思:

8. 开发者初步构思模块最核心部分的设计方案,如:数据结构、重要算法、模式架构、流程步骤等,中途做一些可供讨论的草稿、草案等,主要反映设计思想即可.

9. 开发者给审查者讲解设计思想,审查者当场审核开发者的设计构思,共同讨论,理清疑问,形成一致观点.

实现&测试

10. 开发者做出模块的主要公共接口

11. 审查者审查接口,与开发者共同确认之

12. 开发者编写公共接口空代码(带有接口含义注释,要求编译通过)

13. 开发者与审查者并行进行:

a) 开发者:

i. 进行模块开发,要求速度,代码质量可以稍低,比如冗长的函数,但要求命名规范,最高等级编译无非法警告

ii. 开发完成后自审代码

b) 审查者

i. 根据需求与接口做单元测试用例或者集成测试用例或者两者都做

14. 开发者使用测试用例检验模块,要求全部通过 (如时间较急,此时可做草稿发布)

审核

15. 开发者给审查者讲解代码含义

16. 审查者独立对代码做规范、代码结构与程序逻辑审查:

a) 可以书面记录,或者提口头意见,建议书面简单记录一下,怕忘记

b) 审查中,也可以做一些范例性的修改,但是不能全部代工

c) 审完后,给讲述开发者提出修改意见

d) 如果是c++的,并且之前的草案没有建模,则开发者这时候建模

e) 开发者此时仍有给审查者解释代码的义务,审查者需要将代码全部看懂

17. 审查者给开发者讲述或者两者讨论代码的问题,边讲开发者现场边改或者边记录

18. 开发者进行重构代码、建模、修正逻辑错误

19. 开发者自审代码

20. 开发者给审查者讲解修改之处

21. 两者并行进行:

a) 开发者通过全部测试用例

b) 审查者在审查,发现问题立刻现场指出修正

22. 发布该模块的正式版本,接口说明,使用指南

补充说明:

1. 该过程中如果在下面的步骤中出现了上面步骤的问题,应该返回到上面的步骤再执行

2. 如果出现分歧,以审查者意见为准,或者咨询负责人意见