對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/14 8:43:51
| ALM專題系列之五 「人」是應用軟體生命週期的關鍵 |
| 對企業而言，採用敏捷式開發方法是實現應用軟體生命週期的方式之一，在反覆淬煉的過程中，逐漸增強軟體品質，但不是用於確保軟體品質。此外，企業莫因為軟體開發工程化，而將人員比擬為另一種形式的工具，相對的，人員依舊是企業的重要資產，與創意來源。 「銀彈」無法解決所有的問題 過去，企業面對天才型或英雄型工程師的職業衝擊，現在將他們歸入流程之下，等於瓦解他們自主的能力，猶如要求一個身經百戰的士兵繳械，情何以堪。然而，人員、流程、工具等三者整合缺一不可，否則應用軟體生命週期形同具文。一些組織避免使用流程，代之以個人英雄主義和他們開發組的天才發揮；另一些團隊過於強調流程，試圖透過給團隊過多的過程來保證成功。之所以企業會有如此大的差異，在於聽信組織變革的神話，以及高估流程變更的能力，與低估其阻力。Frederick Brooks在其著名的《No Silver Bullets》一文中提到，沒有單一的方法論（無論是技術上或管理上），能將現有的軟體開發生產率提高一個數量級。我們知道，單一的解決方案不能解決任何問題，實際上，最終的成功必須包括所有的因素－－在人員（組織）和專案之間取得平衡，不能偏廢。 人治與法治之間的平衡：彈性的流程與以人為主 以法約束人的行為，這是軟體工程化強調流程的出發點，以及必然的趨勢。然而，臺灣本地人情事故管理特性使然，往往注重口頭命令與告誡治理業務，也就是人治。敏捷式開發流程既注重流程（法治），又兼具以人為本（人治）等，兩方都未偏廢。雖然敏捷開發方法不盡然適用所有中小型企業的開發團隊，但其優點是，僅規範原則、保有最大彈性，企業可以適其商業流程、人員習慣、組織特性、應用技術與工具等，逐步調整。 管理的反樣式（Anti-pattern）：人員的互動更勝於流程與工具 敏捷式方法面對3個重要的問題：程序不是很清楚、仰賴自動化工具、以及不重視系統結構，而重視快速滿足客戶需求。雖然軟體品質可以在漸進過程中逐步強化，但開發人員必須具備充足的經驗，以避免在變動過程中迷失方向，成為管理黑洞。 許多軟體團隊的管理者，因循舊式的管理習慣，或因應客戶要求進度，但無法及時交付特定版本的軟體，採用文件敷衍了事，因而過於注重文件化，而非實質的產出物，也就是軟體。敏捷式開發方法注重軟體實質的品質改進，將文件交由工具自動產生。也因此，其採用稱為Martin文件第一法則（Martin’s First Law of Documentation），以防止設計師落入例行性的文書作業： 「除非對文件有立即且重大的需求，否則不產出文件。」 我們曾遇到一個案例，也就是委託者與受委託者達成採用美軍498的軟體專案標準（Mil-498），結案後客戶收到的產出物，卻是塞滿6大箱A3紙箱的各式文件。這些文件其實意義不大，因為很難光從文件回推原設計者的架構，而且仔細閱讀這些文件更是耗時費力的工作。 軟體可以在漸進式的變動中改進品質，但人員可能因為頻繁的變動帶來開發壓力，而造成工作效率低落，因此，敏捷式開發很重視人員的經驗與素質，包括其承受工作壓力的特質。許多敏捷式開發方法下的軟體，是每日建構小型版本，而每周建構大型版本，並在2~3個月結案，交付產品。因為歷程過短，許多階段中衍生的開發經驗無法吸引沉澱，便被迫進入另一個階段，甚至另一個專案。多數時間，開發人員重複運用舊經驗，而沒有時間吸取新經驗，週而復始會造成工作效率不彰。由於軟體設計很講求創意與靈感。我們在採訪使用者經驗的過程中，歸納出共通的認同，均表示敏捷式開發流程的前提是成員對軟體設計有極高的熱誠，甚至超過薪資的回饋。 團隊成員把不斷變動的系統的發展藍圖記在腦海，沒有任何其他方式比面對面的互動更快速、更有效地傳達這些發展藍圖。 敏捷軟體開發宣言第一條便表明：個人及互動勝於流程與工具，「人」方是成功最重要的因素。如果團隊中沒有優秀的成員，就算有好的流程也無法防止專案失敗；但劣質的流程卻也能讓優秀的成員變得毫無效率。良好的合作、溝通與互動比寫程式天份更為重要，程度一般但溝通良好的軟體工程師所組成的團隊，會比一群沒有團隊互動的天才型開發人員更有可能獲致成功。也因此，建構團隊比建構環境更為重要。許多團隊和管理者犯了先建構環境的錯誤，以為團隊就能自動地凝聚成形；相反地，要先創建團隊，再讓團隊根據其需要構建出開發環境。 高品質的軟體：可維護性、延展性、效率、可用性 對企業內部而言，軟體品質是團隊共通的責任。對企業外部而言，軟體必須反應對客戶需求的特性，綜合以上兩點，軟體至少應具備以下幾種特性，才可稱為具有品質的軟體：可維護性（Maintainability）、延展性（Scalability）、效率（Efficiency）、可用性（Usability）。 軟體的聖杯之路：開發時程競賽與異質性整合 Sommerville提到軟體工程正面臨重要挑戰，主要有三種： 1. 傳統的挑戰： 企業面對Legacy System，避免使用極高的成本進行軟體的維護與更新，並且仍然能夠持續提供重要的商業服務。 2. 異質性整合挑戰： SOA企業在資訊系統的發展，久而久之包括各種不同的電腦與對應的支援系統，企業所面臨的挑戰是抉擇適當的技術，並開發軟體有足夠的彈性處理這些異質系統。 3. 開發時程的挑戰： 由於商業活動要求快速回應，造成企業面對軟體品質與開發時程間競賽，而難以兼顧的兩難局面。如何在不降低軟體品質下，以更短的時間開發完成。 另一個重大挑戰則涵蓋以上三種情況，也就是突顯的系統特性。以往各個分離的單一系統，其特性單純且容易描述，當各個子系統整合成大型系統時，由於系統間交互作用，其效應便是所謂的突顯（Emerge）性質。這些特性並不受企業歡迎，因為難以預測，而且會因為系統複雜程度成等比級數成長，難以掌控。軟體開發過程中，通常到後期的上線測試才會出現問題，其成因可能因為新舊系統或異質平臺整合，或在多層次架構設計上，因為不周延而拖累其他系統。 人才是流程的關鍵與企業重要的資產 產品交貨順利與否的關鍵在於人，不是流程。碩網資訊協理葉爾瞻引用Martin Fowler的形容：「方法論者和恐怖份子間的差異是什麼？答案是，至少恐怖份子可以談判。」我們在訪談中歸納出，高度熱誠的開發人員才是成功的秘訣。敏捷式開發並不注重形式化的儀式與專案文件，而是讓工程師在技術實作過程中盡情發揮能力。 在應用軟體生命週期解決方案中，總結地說：人是關鍵，但優秀人才仰賴發掘，而不是培養，這也是工具自動化後無法取代的趨勢。文⊙張瑞隆 藍領與白領的差異 在大陸，資訊領域常區分為三類人才：第一類是資訊技術、管理與領域知識等兼具的「軟件金領」；第二類是系統分析與設計的「軟件白領」，相當於我們所稱的軟體工程師；第三種是熟練撰寫程式碼（彼岸稱為編程）的「軟件藍領」（又稱為基礎程序員或技術工人）。在大陸，許多資訊人員停留在相當於藍領階段，印度也在這個領域有充沛的人力資源。鼎新電腦顧問周忠信認為，專業分工與工具自動化對開發角色的衝擊，將造成開發人員重新界定生涯規畫。 但這些階級區別並非絕對，鼎新電腦的作法是將適合的角色放在適當的職位，或透過潛力開發與教育訓練的方式，協助職員瞭解能力。程式撰寫人員雖然可能面對工具自動化的衝擊，但因為工具僅能產生主要程式碼，具備技術與領域知識的程式設計師仍能保有優勢。 |