Iteration | Kenmingの鮮思維

現代越形複雜資訊系統的開發，尤以要應付快速變動性的議題，幾乎所有的主流開發流程，包括 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 同學您好：

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

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

Best Regards.
Kenming.