適用的專案 

剛剛瞭解Scrum的朋友，經常會有這樣的疑問：到底什麼樣的專案適合使用Scrum呢？我們也一直在探討。首先，我們來看一下關於過程的定義。過程控制通常有兩種形式，一種是預定義過程，另一種則是經驗性過程。

預定義過程

• 每一項工作都可以被完全理解
• 給予合理的輸入定義，每次便可以得到相同的輸出
• 過程啟動後，允許執行直到結束，每次執行產生相同的結果

預定義過程的示例比如：生產混凝土的過程，只要原料配比確定，加入的順序以及攪拌動作、攪拌時間確定，那麼產出的結果將完全一樣。 傳統的瀑布開發模式是基於預定義過程來設計的。

經驗性過程

• 過程是不能夠完全預定義好
• 結果是不可預知的
• 生產過程是不可重複的
• 通過不斷的檢查和調整使得過程能夠產出我們需要的結果

經驗性過程的示例比如：一場足球賽，我們不可能規定好每個人的動作，我們也不能預測比賽的結果，我們只能通過激勵，通過不斷檢視和調整團隊，讓他們發揮到更好的水平，以達成戰勝對手的目標。 Scrum是一個經驗性過程，它的核心是在專案的整個過程中提供給專案的參與者以及干係人高度的透明性，基於透明性來進行不斷的檢查和調整，通過不斷的檢查和調整持續的優化過程和產出結果，提升團隊交付能力，以此達到按時交付高質量的，客戶真正需要的產品。

適合管理複雜的專案

基於上述的對比，顯而易見的是管理這種複雜的專案，我們不可能在一開始把整個的過程預先定義好，專案的結果如何，我們也很難再一開始就完全預知，專案存在很多的不確定性，整個專案過程也是不可能重複進行的。所以，管理這樣的專案需要使用Scrum這樣的經驗性的過程來達到更好的效果。

一點經驗

關於迭代計劃會議

在Scrum敏捷開發中，迭代計劃會議是專案開始之前很重要的一個會議，它決定了專案能否順利的執行下去。而且，在迭代計劃會議上，PO、架構師、開發小組成員要對Product Backlog中的需求進行細化分解，分解成最小的任務，最好是彼此沒有依賴（期望值，一般這個很難實現）。任務越小，完成每一個任務花費的時間也就會越少。在分解任務時，需要小組成員給該任務評估開發時間，即用多長時間能夠完成該任務（Story）。

開發中的溝通問題

在開發中，組員之間、組員與ScrumMaster之間、以及組員與客戶之間的溝通是相當重要的，如果在開發中，遇到什麼不確定的需求或者問題，要及時的與ScrumMaster反應，以免做一些無用之功，時間對於Scrum成員來說是很寶貴的。ScrumMaster應該確保每個成員每天的有效工作時間，為每一個成員排除一切阻礙他們開發的困難，及時發現，及時溝通，及時解決。

結語

最後，說一點別的東西。就目前軟體開發的現狀來說，需求的變更是很平常的事情，初期客戶由於不瞭解自己具體所要的系統，而描述的不清楚，但隨著開發的進行，隨著溝通的增多，客戶會越來越清楚想要開發的系統，因此在開發中經常會變更需求。 對於變更需求，傳統的開發方式已經很難應對這種情況了。而敏捷開發就是應對這種需求變更最好的方式，以最小的核心需求進行開發，同時每一個迭代之後，都會以最新的需求作為目標，因此每一個迭代都會與客戶的目標很接近，最終會完美的交付客戶需求的系統。這就是敏捷開發的魅力所在，以最小的代價，完成最偉大的作品。