敏捷管理，才是克服開發流程不確定性的關鍵

在軟體工程中，統一軟體開發流程（Rational Unified Process，RUP）、CMMI、敏捷開發（Agile）是三種重要的開發方法，其中的RUP被許多大型企業，如波音公司採用。日前，RUP管理哲學主筆，也是現任IBM全球Rational研發服務副總裁Walker Royce在IBM 2013開發者大會中，重新揭示專案管理者，在面對快速變動的人力、技術、客戶需求等挑戰下，如何以敏捷管理為方法，協助專案管理人迅速因應。

Q：敏捷管理和傳統專案管理的最大差別？
A：管理是一種動態的管理觀念。傳統上會認為，專案管理就是要預先確定好人力、產品功能、方向以及專案成本等，再一步步將資源靜態地分配到生產單位上。但是，這種作法已無法因應越來越快的產品釋出周期，以及越來越迅速的顧客反饋。因此，管理者必須改變思維，不要試圖在開發前期控制全局，而是要讓專案中的各個局部（人力、生產工具、以及成本等）都具有快速反應變化的能力，敏捷管理的思維與方法，正好適合用於因應這波快速變動的浪潮。

Q：敏捷管理應用在軟體開發上的主要特色？
A：敏捷管理能縮短開發周期，快速交付原型產品，並依顧客反饋作為下一階段開發的調整方針。管理者不須要在實作前就做出一個完美的產品規畫，而要讓這個規畫變成具備延展性，並能快速適應新的客戶需求。

此外，在每個階段中，專案管理者都應從整體來考量產品，將之視為一個明天就要上架的產品來對待。以產品測試為例，傳統開發方法都要求先做單元測試（Unit Testing），但從敏捷的觀點來說，整合測試（Integrated Testing）應先於單元測試施行，因為完成了整合測試後，更能看出哪些部分其實是不重要的，哪些部分是真正吸引人的功能，之後再依據必要的部份，做出小規模的，更密集的單元測試。

Q：是否只有軟體公司適合敏捷管理？一般公司的IT部門呢？
A：以軟體公司來說，開發團隊是以利潤導向（Profit Centered）為主，其開發成果是要賺錢的，顧客、市場的要求變動也會更加劇烈，更有迫切必要導入敏捷思維。而一般企業的IT部門，則是以成本導向（Cost Centered）運作：給定固定預算，去完成特定任務，因此情況會較為單純，不過，敏捷開發所具備的「迅速反應」的思維，能讓一般企業IT更迅速地將員工需求反映在產品中，避免開發出不必要的功能，造成企業在人力、物力上的浪費。

另外一提，雖說敏捷的觀念在開發界非常流行，在美國，仍然只有約25%的開發團隊真正落實敏捷管理並獲得良好成效，因此大家仍在試圖摸索更好的敏捷方法，與其相關輔助工具。

Q：臺灣許多中小企業IT部門只有2到3人，敏捷開發是否合用？
A：是的，事實上越小，越新創的團隊就越適合敏捷開發，因為可以免除跨團隊溝通的成本，更有機會縮短交付周期。反而是大型的、具傳統包袱的團隊，因為已習慣了傳統開發模式，而不願進行新的開發方法，此外，各部門人員間來回溝通的障礙，都會讓採用敏捷開發的成本大幅提高。

Q：美工、介面設計師是否應整合至敏捷團隊？
A：不是必須，而是非如此不可。因為敏捷開發的精髓之一，就是先解決產品中最困難、不穩定性最高，但也是最有價值的部分。而介面與美工設計正是如此。因為顧客對新功能通常能夠準確描述，然而介面設計、操作行為卻是必須要有成品出現，顧客才能調整需求的部分，因此，美工與介面設計師必須在早期的產品原型（Prototype）階段，就加入敏捷團隊，並且隨著團隊成員在不斷的修正周期中，逐步調整其設計。

Q：如何評估敏捷管理的成效？
A：敏捷的核心精神，就是迎接「改變」。因此一切成效評估都圍繞著「改變」進行，例如，產品功能設計每改動一次，要花多少時間、多少成本去達成？而在其中，機器參數的調校、組織內人力調動的速度、程式碼的架構是否具有延展性等等，都是評估敏捷成效的標準。

是否能夠掌握專案中的不確定性，就是敏捷管理成敗的關鍵之一。以開發成本來說，成本其實不是一個定值，而是更接近於機率分布的模型，其標準差決定了管理者是否能準確預估成本。隨著專案進度前進，標準差如果越來越小，代表不穩定性已在逐步收斂，收斂的速度，則能清楚顯示敏捷管理是否奏效。