敏捷的軟體開發流程(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

對新奇的事物都很有興趣, 喜歡簡單的東西, 過簡單的生活.

在〈敏捷的軟體開發流程(CMMI)〉中有 9 則留言

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

    回覆

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

    回覆

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

    回覆

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

    回覆

發表迴響

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料。