摘要:本文闡述了筆者對研發(fā)過程管理的認識,并對新的需求模塊開發(fā)工作提出了自己的流程方法.
管理,顧名思義,管的是人,理的是事.研發(fā)過程管理的目的是以較好的方式組織工程師,以較快的速度和較高的質(zhì)量完成產(chǎn)品.但實際的過程中往往呈現(xiàn)出一些"混沌"的現(xiàn)象,由于工作流程的不清晰,一方面導(dǎo)致員工對完成某件事情沒有明確的流程,而另一方面,這種不清晰,也導(dǎo)致了資源的爭奪、步驟的忽略、事項的遺忘等等.其結(jié)果,看上去工作熱熱鬧鬧,實際上混亂無序.如果沒有合適的流程與制度,這種管理上的混亂,也隨著人員的增多如滾雪球般增大.
筆者認為,不論哪種管理方法、思想,具體落實的時候,都是制定一系列的工作流程與制度.只不過好的管理,其流程能夠提高工作的效率和有序性,好的制度能夠使員工的生產(chǎn)率更高.
套用一句偉人名言,實踐是檢測流程好壞的唯一標準.要讓流程能夠發(fā)揮作用,必須定義明確,具有良好的可操作性,凡是可以用流程規(guī)范的地方,都應(yīng)制定相應(yīng)的流程.這種例子也多不盛舉,最明顯的例子是工業(yè)生產(chǎn)的制作工序,第一道工序是什么,第二道工序是什么,每一道工序要達到什么標準,規(guī)定得非常明確.可想而知,如果其中某道工序規(guī)定模糊,那么不同的人的操作結(jié)果可能各不相同,最終導(dǎo)致產(chǎn)品的缺陷.又如法律法規(guī),美國的法律規(guī)定總統(tǒng)任期內(nèi)無法執(zhí)政,由副總統(tǒng)接任,如果總統(tǒng)、副總統(tǒng)都不在了,那么就由下議院議長臨時代理,至選舉出新的總統(tǒng),下議院議長也不在了由參議院議長代理.如果他們?nèi)辉诘那闆r下,就只能軍管了,由國防部長代理.細致的流程,應(yīng)盡量考慮到過程中的種種可能性,并制定規(guī)范,這樣的流程最具有可操作性,當然在指定的時候,也要考慮效率的問題.同樣,如果實踐中發(fā)現(xiàn)某些流程存在問題,也應(yīng)該有修正制度,否則就容易陷入僵化的境地.
具體到軟件的研發(fā),要制定的流程就太多了,比如:新功能模塊的開發(fā)流程、風險問題的處理流程、大Bug的處理流程,小Bug的處理流程、資源沖突的處理流程(比如碼流儀)hh.
以新功能模塊的開發(fā)流程為例,業(yè)界也有許多理論:RUP、XP、瀑布、迭代、原型、敏捷方法hh.但對實踐來說,都比較粗,在具體的實施中,必須進行一定的修整.筆者在分析研究了XP方法后,針對實際情況,提出如下流程:
目的:
a. 提高代碼質(zhì)量,減少Bugs,降低后期維護量
b. 提高知識共享度與組員技能水平
c. 降低人員流動帶來的風險,如出差、調(diào)離、辭職
d. 形成必需文檔
e. 加強反饋與溝通
步驟:
1. 當新的需求來到的時候,開始本流程
需求:
2. 由Team Leader或者其授權(quán)者瀏覽、了解需求,做需求初步評價:
a) 如其中存在平臺性技術(shù)難點,則走預(yù)研攻關(guān)流程,不走本流程
b) 填寫需求評估文檔:可行性、大致進度、開發(fā)要求,要點
3. 負責人組織需求分析討論會議
a) 討論方式:全體、局部與微型會議(微型會議是指最相關(guān)的3人左右,做在座位上開會,推薦)
b) 安排一個開發(fā)者與一個審查者(負責人可為其中之一),要求審查者的經(jīng)驗、技能較高或者相當開發(fā)者
c) 如有必要,則拆分為較小的模塊,對每個小模塊進行后面的步驟
4. 開發(fā)者對需求做進一步深入了解,將其中抽象、不明的東西具體化,出需求草案,草案中可帶有疑問.
5. 審查者獨立審查需求草案
6. 審查者與開發(fā)者共同討論需求草案
a) 2人約個時間,開發(fā)者協(xié)助審查者審查
b) 指出其中需求不明之處
c) 討論其中的疑問,如不明確,則咨詢需求提出者
d) 盡量討論現(xiàn)場一次性確定疑問,以避免過程反復(fù)
7. 開發(fā)者根據(jù)審查結(jié)果修正草案,之后將正式需求發(fā)送給Team L