敏捷的軟體開發流程(CMMI)

大公司都很喜歡推一堆流程, CMMI, Scrum, Agile .... 有一卡車的流程, 總而言之大多數就是多一堆的報表出來(當然有些流程例外), 來做 Check 的動作... 到底這些流程的精神在哪邊...

下面整理一下找到的連結, 還有 CMMI 推導者推行成功後受 ITHome 採訪的文章~ 可以參考看看 🙂

以下轉載自 上述 MS 敏捷的軟體開發流程這篇文章, 再做些簡單的編排. 雖然是 2003 年的文章, 但是是淺而易懂的好文章 🙂

敏捷的軟體開發流程 作者:林耀珍 2003 年 11 月

速度是企業競爭致勝的關鍵因素,軟體專案的最大挑戰在於一方面要應付變動中的需求,一方面要在緊縮的時程內完成專案,所以軟體團隊除了在技術上必須日益精進,更需要運用有效的開發流程,以確保團隊能夠發揮綜效。這正是 Agile Process (敏捷的軟體開發流程) 於近年來興起的主要原因,本文將介紹數種廣為接受的軟體開發流程,及其在運用上的建議。

Agile Process - 敏捷的開發流程

幾乎所有的軟體專案都會在起始階段面臨選擇開發流程的困難,一種是完備的開發流程,另一種是簡易輕便的流程。雖然我們了解採用完備的開發流程可以提高軟體的品質,但是因為欠缺人力、工具與時間,我們常會被迫採用簡化的流程,但事與願違,大部分的情況我們仍然難以在預算內及時完成專案。

Agile Process (敏捷的開發流程) 是一種軟體開發流程的泛稱,Agile Process 具有下列幾項共通的特性:

  1. 客戶與開發人員形成密切合作的團隊,因為客戶無法於初期定義完整的規格,而開發人員於開發過程中也常常無法知悉外在環境或業務的變動,所以需要兩者密切合作方能開發適用的軟體。
  2. 專案最終的目標是可執行的程式,因此所有的中間產品必須經過審慎評估,確認有助於最終目標,才需要製作中間產品。
  3. 採用 Iterative 與 Incremental 方式分階段進行,密集 review 是否符合需求。
  4. 流程可以簡單,但規劃與執行必須嚴謹。
  5. 強調團隊合作,賦予高度的責任,團隊有自主權得以因應變化做調整。

RUP 開發流程 - Rational Unify Process

RUP 為 IBM Rational 公司經過多年的研發與經驗所提出的軟體開發流程,其內容含蓋 Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment 等軟體開發生命週期的直接工作,與 Project Management, Change & Configuration Management,Environment support 等支援性工作。RUP 的內容非常豐富,不同的專案需要不同調整,IBM Rational 提供 RUP workbench 工具,方便調整 RUP,並公佈於 Web,方便專案成員遵循統一的流程規範進行工作。

RUP 的主要精神為:

  1. 專案進行採用 Iterative 程序分階段漸進地完成專案功能
  2. 廣泛使用 Visual Modeling 於商業需求分析、系統分析與系統設計
  3. 強調架構設計
  4. 對每項工作所需要的技術、工具、做法、範本、檢查項目均有詳細的定義,架構完備且具有可調整的彈性

因為 RUP 的流程規範與相關技術較複雜,所以導入時必須注意幾個因素:

  1. 主管的支持以確保足夠的資源投入
  2. 分階段導入
  3. 適當的訓練與密切的顧問咨詢
  4. 使用 Modeling 技術時需要考量 Coding 的實作環境
  5. 良好團隊的管理,以溝通、耐心與堅持解決變革的人性阻力

XP 開發流程 - eXtreme Programming

XP 亦稱為終極流程,是最輕量級的開發流程,其最主要的精神是『在客戶有系統需求時,給予及時滿意的可執行程式』,所以最適合需求快速變動的專案。XP 經過 6 年的實作與修改,已演化為精緻的開發流程,但仍不失其精簡的特性,它強調客戶所要的是 workable 的執行碼,所以把與撰寫程式無關的工作降至最低,並要求客戶與開發人員最好以 side-by-side 的方式一起工作。

XP 開發流程的基本步驟為:

  1. 開發人員隨時可以和客戶進行有效溝通,撰寫 user stories 以確認需求
  2. 簡易快速的系統設計,撰寫獨立的驗證程式以解決特殊困難的問題,找出演算法即可丟棄驗證程式
  3. 規劃多次小型階段的專案計劃,以最快速度完成每一階段的程式交付客戶,客戶負責 Acceptance tests
  4. Coding 前必須完成 Unit Test 與 Acceptance tests 程序,所有模組整合前都須經過 Unit Tests
  5. 開發人員必須快速回應 Bug 與需求變更
  6. 要求二人一組使用一台電腦設計程式,當一人 coding 時,另一人負責思考與設計
  7. 程式必須符合程式規範,並常做程式的重整 (Refactoring)。

XP 屬於較精簡的流程,於導入應注意幾件事情:

  1. 最好有顧問給予協助
  2. 持續的 Review
  3. 可適當調整流程,但不可失去其基本精神。

SCRUM 開發流程

SCRUM 開發流程是 Agile Process 的一種,以英式橄欖球爭球隊形 (Scrum) 為名,基本假設是『開發軟體就像開發新產品,無法一開始就能定義 Final Product 的規程,過程中需要研發、創意、嘗試錯誤,所以沒有一種固定的流程可以保證專案成功』。Scrum 將軟體開發團隊比擬成橄欖球隊,有明確的最高目標,熟悉開發流程中所需具備的最佳典範與技術,具有高度自主權,緊密地溝通合作,以高度彈性解決各種挑戰,碓保每天、每個階段都朝向目標有明確的推進,因此 SCRUM 非常適用於產品開發專案。

SCRUM 開發流程通常以 30 天為一個階段,由客戶提供新產品的需求規格開始,開發團隊與客戶於每一個階段開始時挑選該完成的規格部份,開發團隊必須盡力於 30 天後交付成果,團隊每天用 15 分鐘開會檢視每個成員的進度與計畫,了解所遭遇的困難並設法排除。

SCRUM 與傳統開發流程及專案管理差異較大,於導入時最好有顧問協助。

總結

Agile Process 的精神已經成為共識,但是沒有一種固定的流程可以重複使用在不同的專案上。而且不管是 RUP、XP、SCRUM、或其他的開發流程都允許相當大的彈性,我們必須按專案性質的不同,調整或混合出適合的開發流程,並允許團隊於進行中做必要的彈性修改,方能達成目標。

參考資料


關於 Tsung

對新奇的事物都很有興趣, 喜歡簡單的東西, 過簡單的生活.
本篇發表於 Document-Ebook。將永久鏈結加入書籤。

敏捷的軟體開發流程(CMMI) 有 9 則回應

  1. Terence 說道:

    其實在我自己的經驗裡,流程這個東西是到了最後不得用的。
    當專案本身複雜到了一個程度之後,光憑人腦實在會沒辦法隨時掌握專案的狀態與進度,
    勢必是需要一些輔助工具來協助專案經理瞭解專案的各個面向,
    所以我個人是認為,流程這東西能省則省,但是有些關卡是不能免得,否則會造成專案失控的風險。
    換句話說,如果只是為了流程而流程,那是真的勞民傷財了。
    個人淺見,僅供參考啦。

  2. Tsung 說道:

    嗯嗯, 感謝您的經驗分享, 我們公司現在就是在搞這流程, 剛開始推確實很煩哩 🙁

  3. ES 說道:

    我也蠻贊成不要一開始就先跳入"流程",可以先想想整個開發團隊和客戶最需要的是什麼,有哪些資訊需要清清楚楚溝通跟追蹤,要怎麼做才能讓整個專案under control.參考各種流程,發展適合自己團隊的作業方式,對症下藥,會比跟著大家過什麼認證都有用. 在我的經驗,輔助工具真的可以讓自我改善事半功倍喔. 有關輔助工具,以下的link可以參考參考:http://www.jroller.com/Turmalix/entry/how_does_collaboration_platforms_support

  4. Tsung 說道:

    嗯嗯, 感謝提供. Orz..

  5. younguo 說道:

    您好,無意中看到您的BLOG,覺得寫的很好,但有個問題想請教您,請問敏捷式開發是否適用於六標準差?該如何證明?

  6. Tsung 說道:

    適不適用似乎不是這樣子比較的, 兩者本身應用的範圍本來就不太一樣...
    如何證明? 如果您覺得有相關的話, 大概就只能實作證明吧? 🙂

  7. Ray 說道:

    hi 您好,您的文章寫的很棒耶 !! 不曉得是否可引用到我的部落格中?
    底下是我的部落格 http://www.wretch.cc/blog/nagagechou
    先謝謝你了 ^^

  8. Ray 說道:

    hi 您好,您的文章寫的很棒耶 !! 不曉得是否可引用到我的部落格中?
    底下是我的部落格 http://www.wretch.cc/blog/nagagechou
    先謝謝你了 ^^

  9. Tsung 說道:

    嗯嗯, 只要加上出處來源, 剩下的就請隨意囉~ 🙂

發表迴響