摘要:本文阐述了笔者对研发过程管理的认识,并对新的需求模块开发工作提出了自己的流程方法.
管理,顾名思义,管的是人,理的是事.研发过程管理的目的是以较好的方式组织工程师,以较快的速度和较高的质量完成产品.但实际的过程中往往呈现出一些"混沌"的现象,由于工作流程的不清晰,一方面导致员工对完成某件事情没有明确的流程,而另一方面,这种不清晰,也导致了资源的争夺、步骤的忽略、事项的遗忘等等.其结果,看上去工作热热闹闹,实际上混乱无序.如果没有合适的流程与制度,这种管理上的混乱,也随着人员的增多如滚雪球般增大.
笔者认为,不论哪种管理方法、思想,具体落实的时候,都是制定一系列的工作流程与制度.只不过好的管理,其流程能够提高工作的效率和有序性,好的制度能够使员工的生产率更高.
套用一句伟人名言,实践是检测流程好坏的唯一标准.要让流程能够发挥作用,必须定义明确,具有良好的可操作性,凡是可以用流程规范的地方,都应制定相应的流程.这种例子也多不盛举,最明显的例子是工业生产的制作工序,第一道工序是什么,第二道工序是什么,每一道工序要达到什么标准,规定得非常明确.可想而知,如果其中某道工序规定模糊,那么不同的人的操作结果可能各不相同,最终导致产品的缺陷.又如法律法规,美国的法律规定总统任期内无法执政,由副总统接任,如果总统、副总统都不在了,那么就由下议院议长临时代理,至选举出新的总统,下议院议长也不在了由参议院议长代理.如果他们全不在的情况下,就只能军管了,由国防部长代理.细致的流程,应尽量考虑到过程中的种种可能性,并制定规范,这样的流程最具有可操作性,当然在指定的时候,也要考虑效率的问题.同样,如果实践中发现某些流程存在问题,也应该有修正制度,否则就容易陷入僵化的境地.
具体到软件的研发,要制定的流程就太多了,比如:新功能模块的开发流程、风险问题的处理流程、大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) 讨论其中的疑问,如不