關於這點，雖然 takeshi也只是新手PM，有很多東東要學習，但是仍有一些個人的想法可以跟各位朋友們分享(沒看過豬走路，也吃過豬肉ㄚ)，takeshi認為至少可以從三點來判斷軟體專案的素質，那就是專案管理、整體設計和自動化支援程度！
takeshi雖然嘴巴上講了粉多次，但還沒把它們好好地寫下來過，為了可以讓takeshi自己可以好好整理這些概念，takeshi就這三個概唸作出發，畫出了以下心智圖，心智圖檔案在這裡
由心智圖可看出，這三個概念其實是由很多子概念組成的，這每個子概念至少都可以多讀個好幾本書說>"<， takeshi也不是全都懂，或是全使用過，不過察覺是智慧的開端，takeshi"儘量"就每個概唸作簡單的介紹，並附上相關連結，讓有興趣的朋友們去深入瞭解~
但礙於要提及的東東粉多，所以takeshi打算拆成多個文章來介紹它們，這次就先從專案管理說起，其他的部分就請各位朋友們耐心期待一下嚕~
專案管理
說到專案管理，是每個人都掛在嘴上的東東，它的定義是指「一個暫時性(temporary)的組織與努力付出，在一段事先確認的時間內，運用事先決定的資源，以產出一個獨特的(unique)且可以事先定義的產品、服務或結果。」，就此定義來說，每個人多少都有專案管理的經驗了，只是範圍和目的的不同罷了，買房子是一種專案管理，結婚也是一種專案管理，甚至生小孩也是一個偉大的專案管理工作ㄚ！當然我們這邊主要是針對 軟體開發 作討論啦 :p
方法論
定義為「在軟體工程與專案管理中，方法學通常是指一系列編撰好的建議方法，有時還包括訓練材料、正規教育性程序、工作表和圖像工具。與其被稱為方法學，這些概念比較適合叫作方法」；雖然以工程角度來看，軟體開發是一項非常年輕的學門，但已有許多專家學者提出了非常多的方法論，來解決軟體開發中各項活動所遇到的各種問題。takeshi只就常見的 瀑布式開發 和近年非常容易聽到的 疊代式開發 作介紹~
瀑布式開發
定義為「開發被認為是按照需求分析，設計，實現，測試 (確認)， 集成，和維護堅定地順暢地進行」，其實也就是依循著系統開發生命週期(SDLC, System LifeCycle)的順序，一步一步的往下走；其定義背後其實有一種假設，那就是使用者需求變動很少，所以該模型假設因需求變動而回到上一步驟的頻率很低，而且每次回到上一步的風險是很大的，例如在測試階段使用者發現系統效能不符合預期，故要求改善，然而因系統架構已然定型，故最後為了要克服系統效能不彰的缺陷，必須冒著更改架構的高風險來達成。
然而在實務上takeshi接觸到的專案，幾乎都是以此概念在進行的，即使是他們表面上打著疊代式開發的招牌...
疊代式開發
定義為「整個開發工作被組織為一系列的短小的、固定長度（通常兩到四週）的小項目，被稱為一系列的疊代。每一次疊代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次疊代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的疊代」；在以上這麼冗長的定義來看，takeshi覺得最重要的概念是提早把風險暴露出來，在每一個疊代要被release之前，一定要讓系統的終端使用者確認和使用，讓他們越早把問題和需求變更反饋給開發團隊，調整的功夫就越小；takeshi認為這是疊代式開發最具有價值的環節之一，然而在上一節提到，許多表面上打著疊代式開發招牌的團隊，通常是開發的確切了多個疊代，但往往卻在最後系統上線之前的UAT(User Acceptance Test)，才讓終端使用者上測試環境測試，導致在最後一刻爆出許多問題需要處理，在此時花費的成本是最大的...
以下秀出一個defect在系統不同的生命週期所要花費的成本比較圖 (美元計)，供大家參考
參考網站在這裡
敏捷式開發方法 (Agile Software Development)
敏捷式開發方法是近年來相當火紅的軟體開發概念，他的中心思想是Lean Software Development(精益軟體開發思想，takeshi不太想用中文講它啦...)，源自於日本豐田汽車公司的製造概念Lean Manufacturing(同時他們也是Just In Time的創造者)，其重點就是要組織全面消除浪費；而在軟體開發領域來說，軟體的交付對於客戶公司的管理階層來說，其實是一種端對端的概念，也就是說「我付了一筆錢，等一段時間，就有一個軟體自動化系統可以使用」，而Lean就是針對這端到端之間的所有流程，都要把浪費降到最低；而所謂的浪費是指「任何不能為客戶增加價值的行為即是浪費」；敏捷式開發即是把其思想當作核心，演變出了相對應的方法論，來幫助軟體專案流程。
此外，敏捷式開發方法也被稱為是「低儀式性」的，就是它跟傳統的開發方法比較起來，在系統開發週期中的每個階段所要求的產出文件，要少了很多，一般的敏捷式開發方法通常到專案結束的產出只有 需求文件(user stories)、自動化測試程式和滿足客戶需求的可運行系統。通常少於20人的團隊較適合敏捷式開發，不過takeshi認為還是要看當下環境怎麼去做配合啦。
現今的敏捷式開發方法，可謂是百家爭鳴，就takeshi的理解，目前的主流可分為三個部分...
指導管理階層如何使用敏捷式管理。
- eXtreme Programing (XP)
指導如何把開發團隊跟維運團隊緊密結合。
以上列出的這三個不論是要稱它們為框架、方法論或概念也好，反正它們就是分別從不同的角度 管理、開發和維運來切入，幫助其中參與之相關角色來採用敏捷式開發。takeshi對這三個東東雖然寫得少，但它們是粉重要的ㄛ，只是這三個東東可以寫得粉長，而網路上已經有很多優秀的資源可供參考了，takeshi有機會再跟大家討論唄~
關於敏捷式開發有一個非常重要的觀念是大家不可不知的，那就是一定要採用 TDD(Test Driven Development) ！(自動化、可回歸的測試程式貫穿整個單元、整合、系統測試)因為當測試程式的涵蓋率夠高的時候，它會形成一張品質的安全網，成為整個專案的重要基石，敏捷式開發之中提到的每個疊代都要release可用的系統、不停重構、提早暴露風險，etc，都是建構在自動化測試之上的ㄛ！通常這時候就會有人問說，到底測試程式要寫多少才足夠呢？Martin Fowler的回答是「至少要跟專案程式碼差不多多吧！」
Rational Unified Process (RUP)
目前由IBM公司在維護和推廣此方法論，RUP也是疊代式開發的一種類型，但它跟敏捷式開發比較起來，就好像是在光譜的兩個極端(也就是高儀式性)，它要求在其定義的管理活動的每個階段，都需要產出或修改相關文件，所以相關人員需花費許多時間來作維護。所以RUP通常適合多於20人以上的大型專案。撇開專案文件的要求不說，takeshi是相當喜歡此方法論的概念^^
Agile Unified Process (AUP)
剛剛提到Agile Software Development和RUP就像是兩個極端對立的世界，而Scott Amber提出了敏捷化(agilize)的RUP版本 AUP，它介於Agile和RUP之間，既顧及了在RUP規範中要求的必要文件產出，在其他部分則是採用了Agile的活動，如TDD、AMDD (Agile Modeling Driven Development)、Agile Change Management和DataBase Refactoring等，使得開發團隊又多了一個新的選擇；以takeshi的看法，在台灣面向客戶的專案，採用Agile可能執行面有困難(公司內部的專案可行性可能比較高)，因為通常客戶還是會要求要有專案相關文件(需求文件、設計文件、測試計畫、佈署計畫，etc)，而RUP是太重量級了，所以AUP可能不失為是個好的選擇ㄛ~
裁切(Tailor)
takeshi要提醒一下，這世上所有的軟體開發方法論，都要求使用者在使用時，要配合當下環境作適度的裁切，而不是一味的照單全收，到最後通常會落得消化不良的下場ㄛ
風險
以上takeshi所提到的軟體開發的方法論，其主要用意都是一樣的，就是如何規避風險，來產出user滿意且品質良好的軟體系統，只是採取的工具與方法不同罷了(有些是強調文件的完整性，有些是強調產出隨時可運行的系統)；所以我們也要來瞭解一下這些"風險"到底有哪些呢？takeshi曾經上過的OO-226課程，把風險作了以下五種分類
- 政治風險
- 需求風險
- 資源風險
- 技術風險
- 技能風險
所以專案團隊在選擇開發方法論的時候，要考量此方法論是不是真的能解決或降低當下環境的風險，確定了方法論後，再依需求對方法論作裁切動作，試著run兩、三個疊代，再慢慢的調整方法論的細節，到整個方法論跟開發團隊非常契合為止~
專案管理 與 整體設計和自動化支援程度 的關係
從專案管理開始，決定採用哪種開發方法論，間接指定了採取哪一種 整體設計概念 和 自動化工具的支援程度；而決定了以上兩者，在專案實際開始執行時，又會回過頭來影響的專案管理的部分，而良性的影響，會漸漸成為良性循環，反之亦然。
takeshi在台灣實務上的經驗是，為數不少的清況下，專案成員不知道自己的專案是在run哪種方法論 或是把覆往式run成瀑布式 亦或是 壓根沒聽過上述提到的東東...，但takeshi認為這是影響專案優劣的重要起點，不可不慎ㄚ...
沒有留言:
張貼留言