對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/14 8:43:18
| ALM專題系列之四 開發角色轉變：團隊的功勞與工匠的苦勞 |
| 應用軟體生命週期依流程而搭配專業分工，將以往集一身於大成的開發工作，區分為分析人員、架構人員、開發人員、測試人員與管理人員等。專業分工不僅是配套措施而已，企業在軟體工程化的經驗中，發現專業分工的不足、權責不明，是導致軟體品質低落的因素之一。《人月神話》（經濟新潮社）一書作者Frederick Brooks提到，軟體開發團隊應如同一個外科手術小組，明確定義專業分工的角色與職掌，點明角色與分工的意義。 但我們更應瞭解到，人員與角色的區別。以企業中現行的狀況，無論是一對一或多對一的配置，只要每個角色的業務能準確地執行，縱使一個人負責多個角色仍不至於影響軟體品質，也就是應用軟體生命週期所要達成的目標。舉例而言，一位有歷練與認知的開發人員，當他實施測試工作時，應公正地驗證程式效能，不必然非區分不可，特別是中小企業中，無法負擔大型開發團隊的人事成本，而且敏捷式開發方法也未強制規定角色的配置。然而，分工卻帶來職業生涯上的衝擊。 許多開發人員經歷大學教育與資訊工作的歷練，磨練出撰寫複雜程式的能力，但這個角色的工作因為印度與大陸的崛起，受到就業競爭的挑戰。企業常將例行性、低技術性的程式撰寫工作，委託印度或大陸完成，甚至整個專案均透過外包，而營運中心僅需配置專案經理，供整合與驗收而已。摒除工具自動化，為專業分工的開發角色帶來的職業衝擊，敏捷開發方法更因為一人身兼多種角色的工作，而必須同時瞭解架構、測試、管理等，不僅只是程式撰寫的業務而已。 以下我們將針對應用軟體生命週期主要的角色：分析、架構、開發、測試、管理等，簡述其工作內容，以及其面對變革的職業衝擊。 分析人員釐清客戶需求 分析人員（Analysts）的主要工作負責確認客戶需求，並將需求以文字敘述在文件上，交由架構設計人員規畫軟體規格，簡單地說，分析人員是客戶與架構人員之間的橋樑，以及需求與規格之間的關鍵。過去這個角色的工作由專案經理或業務人員擔任，常由於缺乏技術背景，而造成傳達需求時的落差。此外，現行的許多專案都無法避免劇烈的需求變動，在訊息傳遞失真的狀況下，只會讓錯誤不斷地放大。 目前已可仰賴需求管理工具（Change Management）控管變更的歷史過程，系統並自動化地衍生版本別以分類文件，包括軟體程式碼或模型的連動部分，甚至當客戶取消變更的需求時，系統也可回溯至更動前的版本，減少人力處理與變化的影響。 分析人員在專業分工中所面對的挑戰，在於將客戶對需求的非技術式描述，精確而簡單扼要地表達在文件上。分析人員不一定具備實作的能力，但應熟稔程式開發技術的最新發展，以及各行業的領域知識。由於此工作需要累積經驗，所以不受工具發展的衝擊，也不因新人崛起而取代。 架構人員主導開發方向 架構人員（Architects）主要工作是針對分析師所寫的需求文件，規畫出對應的軟體設計規格（Specification）。為了清楚表達這些規格，架構師可能需要與客戶討論需求概念、與專案經理討論設計議題、與開發人員討論軟體結構特性，以及程式所採用的技術、外觀與風格等，並將規畫以文字寫成規格書，同時也必須撰寫架構設計圖。 同樣地，塑模工具的進展，除了支援統一塑模語言（Unified Modeling Language，UML），協助開發人員採用視覺化的圖形描述軟體的架構設計，也發展出自動化地進階模型處理，例如模型轉換Web Services程式碼等。工具通常已具備正向工程（forward-engineering）與逆向工程（reverse-engineering），前者在寫程式前先畫出UML圖，後者則由已存在的程式碼產生UML圖。相對而言，UML所繪出的模型圖與流程比較，更適合用於專業人員間的溝通，以彌補業務流程的不嚴謹的文件溝通，並且已成為軟體開發塑模標準之一。 架構人員所面對的挑戰，在於將概念上需求具體化為軟體結構模型，此能力仰賴工作經驗中所啟發的專業直覺，塑模工具自動化的發展，僅是取代人工繪製模型圖的低技術工作，無法取代其角色的價值。正如Martin Fowler所描述的，「好的設計師了解系統哪些部分容易受到需求影響而不斷修改，而能把系統中不變與易變的兩個部分隔開，因而控制需求上的變動。」 開發人員專注於實現技術 開發人員（Developers）所負責的工作，在於依規格書或架構設計圖，以程式碼實作出對應的功能或元件，並撰寫說明文件。由於目前程式語言逐漸統一為.NET與Java兩種，開發工具高度自動化，使得入行的門檻低，因而培養眾多的開發人員。 開發工具的發展，不但可由模型轉換程式碼、語法標準檢查、重構等自動化，甚至發生如「SQL Injection」等邏輯錯誤所造成的安全性問題，工具也可自動驗證，降低人工開發的疏失。 此外，開發人員面對的職業生涯衝擊，是所有角色中最高的，除了因為技術標準化，以及工具自動化的影響，使得入行門檻低，工作價值被工具所取代，為數眾多的開發人員也正稀釋其薪資水準。 測試人員扛起品質責任 測試人員（Testers）主要負責確保軟體的正確性、完整性與品質等三種要求。測試流程包括處理程式中的缺陷（Defect）測試與臭蟲（Bug），兩者不同點在於，測試是為驗證缺陷的存在，而偵錯則是找出並修正這些缺陷。 軟體測試過程也歸類為驗證與確認（Verification and Validation，V&V）。其過程可區分為5種：單元測試、整合測試、確認測試、系統測試、驗收測試。除了前兩者通常由開發人員負責完成外，其餘便由專屬的測試人員負責。開發人員與測試人員負責不同的測試過程，並非因為專業分工的要求，而是本質上的不同。開發人員所負責的單元測試主要是為驗證其程式功能在正常運作時的問題，而測試人員則驗證程式在非正常運作下的問題，例如高負載或突然拔掉電源插座。 敏捷式開發極重視自動化測試，工具的輔助也有助於偵察程式設計錯誤。由於現今企業應用系統因網路環境而日益複雜，測試人員面對的挑戰在於複雜系統所產生的突顯（Emerge）錯誤。處理程式或系統錯誤，其實測試人員必須具備通才的本領，包括豐富的程式碼撰寫經驗與對臭蟲的敏感度，有如一位犯罪現場偵查員般，抽絲剝繭找尋開發人員無心犯下的錯誤，甚至是細心設下的陷阱等（例如程式後門），測試人員都要早在使用者發覺前，率先發出警訊。測試人員仰賴每次測試所累積的知識，以至於無法輕易取代。 專案管理人員為團隊的精神領袖 管理師（Managers），一般也稱為專案管理師（Project Manager），本身不參與技術細節，但負責專案的進度、任務分配與團隊成員間溝通/協調/仲裁等，以及掌控風險、成本、時程、產出物等，並撰寫專案計畫書（Project Plan）。 目前專案管理工具可用汗牛充棟來形容，但僅侷限於非技術性文件，與軟體專案產生的技術文件，如需求說明、模型圖、程式碼等，兩者缺乏共通的管理工具。 管理人員的重要性在於帶動各成員的工作熱誠，以免落入例行性或瑣碎的事務，降低工作效率。乍看之下，此角色所需的技能與軟體開發無直接關連，但技術背景的管理人員可憑經驗，瞭解開發時的瓶頸與解決方向，而不至於讓問題懸而未決。此外，由於軟體開發為創意工作，所以會因為個人習慣所影響，因而形成某些特殊的團隊文化，管理人員除了兼顧個人與團隊的差異，也必須避免抹煞創意，這是其無法取代的原因。 客戶需求是開發角色共通的目標 應用軟體生命週期雖講求專業分工，但在循序漸進的過程中，客戶需求一直是共通的目標，無論哪一個角色，只要在其工作中融入領域知識（Domain Know-How），便不至於淪落為供應苦勞的工匠，其工作成效也能展現在主管的評量表。文⊙張瑞隆 |