scrum在我們的公司內終於落地了。我喜歡它。
爲了展示我們幾個月來的實踐，我覺得做一個ppt給大家看看。做的過程中，我想對比還是必要的吧，想起2003年我們曾經研究過的rup，2005年的cmmi等等。我想也許通過這樣的對比讓大家更加喜歡它。我決定弄些rup，cmmi之類的模型大圖來看。
首先是rup的階段圖：把整個開發過程分爲inception,elaboration,constrution,trnsition 四個階段，在這四個階段中需求，設計，實現，策劃書，發佈等在裏面佔有的份兒繪製出一個大白的波形出來。看上去真的優美。這是rup的標誌圖，提到rup，總是可以看到這一片美圖：）。看起來一目瞭然，可是有什麼實踐價值呢？這張圖到底是誰發明的呢?rational公司乾的，具體是說，我說不上。在公司面前，個人的力量是不會特別表明的，除非商業需要。
然後是bhom的螺旋圖：
很樸實的黑白圖，看起來像是數學上的某個曲線，或者是一個蝸牛的殼子。有點學術化，不如rup的大圖看起來有吸引力。不過也是複雜中透着細節，作者也花費了不少的精力吧。
再來一個瀑布，這個是軟件模型的老祖宗了。也是被罵的厲害的。它的作者是《Royce, Winston (1970), “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON 26 (August): 1–9. 》。爲什麼說被罵的厲害呢？因爲不管是rup，cmmi，還是某個宵小發明的一個新的軟件模型，都會先把瀑布罵一頓：“老了，不合時宜了，沒有考慮到xxx,失敗案例非常的多”等等。這個模型在軟件工程中的地位和C語言很有點類似——資格老，資源多，但是問題也多——看看近年來的新語言的發佈是不是在說，"恩，是的，C語言問題有很多，用了我的語言，你的問題就不必考慮了，因爲我解決了;你可以集中精力於自己的業務上，而不必考慮技術細節了"。不同的是，罵c語言的，同樣包含着尊重，而瀑布模型就沒有那麼舒服了。爲什麼呢。
我發現C語言的發明人裏奇還活着呢，還拿了圖靈獎。而Royce Winston於1995年與世長辭！罵就罵了，你還能跳出來咬我一口？
再來一個v字模型。這又是一個我無法找到owner的圖。我剛剛看到這張圖的時候，覺得醐醍灌頂：要知道作爲管理者，必須要知道瀑布模型的每個階段在何時結束，我必須從大家的反饋中得到這個信息，而不是從開發者自己的一廂情願出發。現在V模型讓我知道其實需求分析的結束和成功與否應該有“驗收測試”來決定，編碼的完成應該有單元測試決定。現在我就可以不但從開發者，而且從測試的角度來看是不是完成了。就是說，開發者說完了，測試者說完了，我纔會認爲，OK，下一步。V模型是有價值的，尤其是對不瞭解細節的管理者而言更加如此。
可是V型也有麻煩，有人提出X模型（欣慰，x模型是有主的）。引用：“Marick對V模型的最主要批評是V模型無法引導項目的全部過程。他認爲一個模型必須能處理開發的所有方面，包括交接，頻繁重複的集成，以及需求文檔的缺乏等等”。 可惜看起來X模型不如V模型直觀，文檔也比較少，所有其實影響不大。
好了，就這麼多了。有沒有發現，儘管圖形從黑白到花哨，從一維到兩維，從單線到有弧度，其實並無本質變化。只不過把需求，開發，測試，發佈這幾個環節變來變去？不好意思，我突然想起一個笑話：“春天來了，一羣大雁向北飛，一回排成S形，一會兒排成B型”。我並無惡意，但是這些模型其實並無創見，知道就行了。
相比於這些拉拉雜雜、幫助理解的、並無實用價值的圖形，我認爲只有貫徹整個軟件的生命週期，並且每天都要看的圖形更加有價值。而scrum的圖就只有一張，並且每天都要看，這就是burndown圖。我的一個同事提出了一個不敬的但是形象的說法，叫做爬行圖。還真的有點像。下面這張圖看起來好簡單。
我稍微做一個解釋，縱座標表示剩餘的小時，比如408小時是初始的團隊總估計時間，橫座標表示timeline，1-30表示一個sprint的30天。沿着日期的增長，剩餘的任務小時通常應該是不但的降低的。當然實際的情況是這張圖的曲線中間有些突起，這是正常的，可能是因爲臨時加入了任務，或者是估計的重新調整。在過去的兩個月來，我每天都要看它，並且我們的團隊成員在Daily meeting中也要看到它。這張圖讓我大致的知道，我們的進度是不是正常的。中間的每一個突起我都知道原因。這個過程配合我們的Daily meeting讓交流更加順暢，讓每個人知道我們現在的狀態，我們昨天完成了什麼，在圖形上是否有所貢獻（你的工作是否讓整個團隊的剩餘工作小時變得減少），下一步要做什麼。
這樣的圖是我們真正需要的。