簡言之,後端管理的主要目的,就是為了建構一個確保前端順利運作、使錯誤減到最低的開發環境。這樣的環境可由以下這些條件構成。
版本管理
許多人可能都經歷過這樣的情形:在產品開發過程中會產生各種版本,而且這些版本不僅出現在最終產品,也會在各種中間型、模組型、子系統型產品中不斷出現;測試人員明明測了C系統的0.112版,程式人員卻去修改D系統的0.121版,結果大家雞同鴨講、越改越糟。
此外,即使彼此溝通的版本正確,也不代表修改正確。因為修改第100行的程式碼之後,可能影響第50行的程式碼運作;或是修正後的獨立元件A卻導致元件B的運作錯誤。而且,當系統越龐大、分工越細、開發小組數目越多時,這種版本亂象愈發惡化。
事實上,「版本混亂」可說是所有開發者最頭痛的問題,所以它是建構完美開發環境所必須解決的一大問題。解決這個問題只有兩種方法:一是非常地細心,二是利用自動化版本管理工具。你可以要求每位開發成員都「非常非常細心」,也可以藉助工具;何者比較可行,高下立見。
多點分工管理
由於系統運作環境日趨多元、專案計畫也趨複雜,軟體分工的情況十分常見,因此目前軟體專案大多由不同小組合作完成,所以完善的分工管理也是建構完美開發環境的要件之一。
除了同一地點的小組分工外,目前還有一個趨勢是「多點分散式分工」,就是切割一個專案成好幾部分,分別交給不同小組,在不同地點同時進行開發,最後予以整合。這種分工法的優點是可以培養不同專長的開發小組,避免double efforts,失去分工意義,同時也可以節省總開發成本。
「多點分工」的情形已經越來越普遍,如果再加上前述版本混亂的問題,可能會讓管理者一個頭兩個大。唯一的解決方法就是建立一套考量到所有細節的「標準作業規範」,然後嚴格要求所有成員都切實遵循,沒有通融空間。或是利用工具將「標準作業規範」定型為所有開發成員的「工作環境」,而且是處於自動執行的模式,如此一來,大家就會在潛移默化下自然而然的遵循了。
瑕疵追蹤管理
軟體開發過程中一定會出現各種小錯誤、bug及許多無解的問題等,這些東西通稱為瑕疵。我們無法要求瑕疵永遠不發生,而是應該做到追蹤管理瑕疵,使它不至於影響開發過程與結果。
追蹤瑕疵要從發現源頭開始。一般而言,瑕疵的「回報」可能來自各個地方,包括經程式人員發現、測試發現、客戶發現、最終使用者發現等。瑕疵從發現到最後修改完畢,可能透過許多工具或各種程序。
例如,客戶打電話抱怨一個程式問題,客服人員在「口頭」上瞭解與接收問題後,將狀況寫成一張「便條紙」交給客服經理,客服經理再用「文書軟體」把它整理成「文件」,Email給專案經理,專案經理用「試算表軟體」填好一份試算表再交給分析人員…..。以此類推,結果最終是完全變質。
這就是用不同平台(紙張與電腦)與不同工具(文書、郵件與試算表)處理同一件事的情形。它會造成兩個現象:一是很容易在轉換過程中出錯,因而製造出新的問題;二是這個過程根本無法有系統地加以追蹤與管理。這些都不合乎標準作業。
正確的方法應該是讓「瑕疵追蹤管理」成為貫穿開發流程的環節之一,而且它應該與開發工作處於相同平台,並且可以自動比對與驗證產品。例如,當客服人員接收一個問題後,就應該進入上述系統,跟著開發流程一起走,才能進行追蹤與管理。
安全管理
在軟體開發過程中,每個階段都會製造各種類型的產出物(包括文件、程式碼、執行檔、報告等),這些產出物有不同層級的保密或安全顧慮,所以需要嚴密的管理。
安全管理分成內部層級管理與外部層級管理兩種。內部管理主要針對不同成員與不同資料的存取權限進行規範與管理,此處應該留意二件事:一是設定正確的修改與唯讀屬性,防止資料破壞;二是妥善管理不同專案之間的資料存取,避免機密漏洞。
外部管理則分成二種,第一種是與協力廠商、供應商或委外開發者的存取管理,這些廠商需要讀取你的檔案,也會製造各種產出物,所以當然要管理存取權限。第二種則是與客戶之間的存取管理,其中資料保密尤其重要;客戶對關於他的資料都會要求保密,特別是牽涉到智慧財產權時,對保密的要求更高。所以專案管理人員在開發過程中必須設計一套能令客戶信任放心的作法。
建立自動化的開發環境
後端管理與前端「生產」工作不同,後端管理存在目的主要是要解決問題,尤其面對五花八門的「人為問題」。所以最好的方法,應該是讓後端管理達到最大可能的「自動化」,使他們隨著前端工作的進展「自動執行」,為前端工作提供一個完美的開發環境。
1.Balinda 於 2003/12/08 16:12 回應
專案管理的成功方程式Effort = (Team) (Tools) (Complexity) Process
在 程序-- 採用往復式流程法(Iteration )
是否會造成OOD在某一個Iteration中考慮不夠周到 ?