簡單描述 SCRUM ~

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

SCRUM,這幾年最夯的開發方法論。

它比較像是團隊版的 GTD (Getting Things Done)時間/工作管理。因為是 Team Work 性質,所以還需要再佐以 Review Meeting (Daily/Weekly) 來檢視與回顧團隊成員的產出。

主要有兩個關鍵字須充分理解:

  • Backlog (訂貨):大訂貨 (product backlog)是由多個小訂貨 (sprint backlog)所組成;每一個小訂貨被視為是可被計量的工作事項 (work item)。
  • Sprint (衝刺):等同於現今所有實務開發均認同的 Iteration (循環,或稱迭代)。這是最重要的成敗關鍵,也是實踐過程中最難以克服的。 (一個 iteration 要涵蓋整個開發步驟,但又要能適時地量化一個工作目標,這不容易。)

特別再強調!SCRUM 只是一種做事的方法,它可能可以調和專案的 時程/規模/成本 三個因子,讓專案目標比較有機會在特定的期限內達成。

但是,SCRUM 與軟體品質完全是兩回事。許多開發人員以為導入 SCRUM/相關工具就能把軟體品質做好,那是不可能的。

軟體品質仍取決於對軟體設計的技能/技術的掌握程度。諸如對需求的分析/收納整理;系統結構的應變設計;實作技術的應用 ...等。

[軟體開發] 敏捷式的平行開發流程模型

前些時候,我們團隊所輔導 (並主導其中的核心開發)某家頗具知名規模的商務網站,該公司經營者總覺得他們原來的開發產出速度緩慢,希望能借重我們在實務開發上的經驗,而能改善開發製程,加速開發上的產出。

我發現到 (應該也可說是意料中事),即使是擁有10幾個以上開發人員的大型網站系統開發,其所謂的系統分析/設計的開發模式仍是採以最典型的 Client/Server 方式。Client 端(也就是 Web 端)主要採以畫面為主的需求分析;Server 端則以資料庫的資料模型為設計核心。

簡單的說,這類開發模式是屬於「資料導向 (data-oritented)」,直覺且簡單,系統規模小且營運需求並不常變動,這樣是行得通的,而且在系統開發的初期會是相當快速的;但當營運規模大得經常會要求系統快速配合商務運作,「資料導向」的開發模式卻往往耗在所謂的「共用性整合」議題上太多等待時間了,那種有著「剪不斷、理還亂」的感覺,不僅讓人苦惱,也是引起紛爭的主要來源。

其實原因也很單純,「資料導向」實際上早已悖離了軟體開發的第一個最基本原則:「封裝 (encapsulation)」。過早揭露資料與邏輯的細節,而使得系統的複雜度提升。

所以,該如何改善開發製程呢?當然就要懂得如何遵守「封裝」的設計原則,而採以 MVC (Model-View-Control)的架構則會是遵循封裝原則的第一個必要手段。

不過要釐清這裡所謂的「MVC」,可不是 Java Struts 或 ASP.NET 的 MVC 框架;系統廠商所提出的 MVC 框架,那是針對 Web 瀏覽器與伺服端如何控管 WebPage 狀態,是關於如何於 Stateless (無狀態)的 UI 設計議題所提出的解決方案 (solution domain)。

而關於企業層級 (enterprise)系統的 MVC 架構,則是回歸到問題領域 (problem domain)上,如何在呈現 (presentation)與業務邏輯 (business logic)兩個層級間,能有效隔離兩者的耦合性 (coupling)。

基於上述的開發原則,我們對開發流程的調整,其實就是在 client (Web UI)與 Server (Model)之間,規劃了控制層 (control layer),藉以隔離中介 Client/Server 的直接耦合;Web UI 團隊與 Model 團隊係以平行分工開發 (parallel development),各自依據其職掌-Web UI 專注畫面呈現與動態技術的實作;Model 專注於系統功能的實現 (realization)。兩者均只與控制層所設計的規格 (也可稱之為功能介面)溝通,所以誰不需等待另一方的產出,如此也就不用初期就耗在所謂共用性議題的等待上。

再者依照敏捷 (agile)的開發精神,整個開發產出係採以 I&I 漸增與漸進 (Iterative & Increment),期待作持續性的整合 (continuous integration,以版本控制系統如 Git 作為整合的儲庫)。最好是每日就作整合,最遲不要超過一個星期。

關於敏捷式的平行開發流程 (agile parallel development process),我們利用 Eriksson-Penker Business Extensions 語法 (俗稱火箭圖)所規劃的開發流程總覽 (overview)如下圖1。然後關於 Web UI、Control、Business Model 這三個層塊,再各自以 UML 活動圖 (activity diagram)來表述它們細部的開發活動,參考下圖 2~3。

敏捷式開發流程模型-Overview
(點擊圖片鏈接看原圖)圖1、敏捷式平行開發流程模型-Overview

閱讀全文 »

[軟體開發] Iteration 與 Release 的差異

現代越形複雜資訊系統的開發,尤以要應付快速變動性的議題,幾乎所有的主流開發流程,包括 UP (Unified Process), XP (eXtreme Programming), Agile 等不論重、輕量型的流程方法論,均一致強調反覆 (Iteration)漸增 (Incremental) 開發的必要性。 關於反覆式與傳統瀑布式 (WaterFall) 開發的比較說明,請參考先前我寫過的一篇:「從軟體架構師(Architect)的觀點來看軟體開發流程」。

I&I (Iteration and Incremental) 的開發模式,已逐漸成為軟體開發的最佳實務 (Best Practice)。 但是, I&I 開發模式的實踐與否,只有在軟體開發團隊的內部才知道;對於客戶單位,他們是不知道,也不可能瞭解委外軟體廠商,內部是運用什麼樣的開發模式。

所以,外包的委外軟體開發專案,若是使用 Iteartion 的開發模式,該如何計價收費? 或者,某大型公司的 IT 單位,規範了外包軟體廠商,必然要遵循該公司所制定的開發流程綱要。 這兩個可以說都是相當奇怪、卻也常見的問題與現象。

我先說明第二個那個怪現象‧‧‧

IT 單位規範外包廠商的開發模式,一點意義都沒有。 因為,客戶根本看不到委外廠商內部是如何開發的。 即使你強調希望委外單位能走 I&I 的模式,但是,他要掛羊頭賣狗肉,你也沒轍,因為,從最終產出 (Artifacts)來說,你根本無法知道委外單位是採取何種開發模式來完成的。 客戶單位只能要求說,委外單位要能在毎一個議定的階段時間,要能達成分次交付的產出甚或可以早些釋出 (release)、可以完整被執行的功能案例。

客戶單位所制定每一個該付交產出的階段時間,這個應該是稱之為 "Milestone (里程碑)",完成每一個階段的交付,也可以及早瞭解委外單位的釋出品質,或作為下一次交付的回饋 (Feedback):而若是要求儘早能看到可被執行的部分功能案例(或模組),這稱之為 "及早釋出(Early Release)"。

再回來討論第一個問題,採用 "Iteration" 開發模式該如何計價?

閱讀全文 »

關於軟體開發「需求獲取」的幾個問題來信回覆

近日有位來自大陸對岸,就讀軟體工程的同學 Email 來信問了我關於需求獲取的問題。 很難得,並不算是問我 How-to 的問題,而我也覺得他問的問題還挺有意思的,所以也把我個人對其的回覆公佈分享出來。

2009/3/24 cnlogn

王克明老師,您好。
  我是一個初學軟件工程的學生,正學到需求獲取。因為仰慕佛教的無遮大會的問答機制,又無意間撞到濛濛的秘密基地,發現了前輩(有緣分),於是冒昧請教。
  我知道需求信息來源,獲取方法/技術。那麼什麼是需求獲取策略?
  我知道需求三個層次分別是業務需求,用戶需求和功能需求(非功能需求)。那麼什麼是客戶需求?什麼是產品需求?
  為什麼把領域分析和業務建模放在需求獲取階段?此致
敬禮

2009-03-24

Cnlogn 同學您好:

  1. 與其說需求獲取的方法/技術 是一種策略(strategy),倒不如說是一種態度。 什麼態度呢? 因為知道不可能一次就能很明確地從使用者端得到正確詳細的需求,所以,需求分析師 (Requirement Analyst, RA)不會也不應該一開始就想要得到所謂正確的需求,而會是以漸增、漸進的方式 (Iteration and Incremental),從一個所謂的功能單位(例如 Use Case),逐步地從目標框架,往精確度要求。 所以這是一種目標導向的作法,先確立目標,再來往細節調整。
  2. 我覺得是不應該去硬背那個什麼三個層次的需求。應該是說,需求會透過多種不同的角度,理解與紀錄各個不同使用者角色的需求。 包括整體性的業務流程面、包括操作員 (Operator)對系統的局部功能要求、包括整體使用者對系統關於穩定、效能、彈性等非功能性的滿意度需求… 等等。 需求的面向 (View)是很多面的,RA 要能擅長透過多種不同的觀點來看待需求面。
  3. 我不會硬性定義所謂的領域分析與業務建模是放在需求獲取階段。 關於分析、設計、乃至實做測試等工作,會是快速跑過一整個循環 (Iteration),再取得回饋 (feedback)來持續修正調整的。 軟體工程把製程 (Process)固定下來的前提是需求穩定不變,問題是,軟體又不同於其它成熟產業領域的關鍵就在於,需求一直持續地變化。

我曾經寫過一篇:「從軟體架構師(Architect)的觀點來看軟體開發流程」,您可參考看看的。

Best Regards.
Kenming.

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal