就是這個光： Scrum + Lean + XP

03/09 22:18~ 03/10 00:10

Teddy 凡致力軟體開發十餘年來，無不在追求一個『正確答案』：軟體到底要怎麼開發才會順？用 RUP (Rational Unified Process) 太沈重，用 XP (eXtreme Programming) 又太自由。話說 10 幾年前 RUP, XML 正當流行的時候，當時 Teddy 有一個 8人/年 （8 個人做了一年） 的專案，就是試著採用 RUP 的方式來進行。Teddy 和另外一位同事每天熬夜寫出十分詳細的分析設計文件，隔天立刻拿給 programmers 實做。由於設計文件寫得太詳細，所以實做上沒有遇到什麼大問題。大部分的工作只是寫寫 SQL，設計精美的 UI，以及實做控制流程。

這一年內公司停掉接專案的機會，全心投入所有人力開發這個系統。完成後產品還沒大賣，但資金卻已經花得差不多了，因此要找人增資。Teddy 跟著老闆東找西找，後來找到某上櫃軟體公司願意投資我們一筆資金。事後 Teddy 問這家公司負責評估的人，為什麼要投資我們。他說：『我沒有看過台灣的軟體公司把開發文件寫得這麼詳細的』。（路人甲：可能是他見識不廣？！）

這...原來不是對方認為我們軟體做的好，而是覺的我們開發文件寫得好，所以軟體功力應該不錯，值得投資。當時 Teddy 有一句話一直不敢說出口：『其實我們的文件已經和程式碼不同步了！』軟體做好後，陸陸續續依據客戶要求還是有一些改變。而之後的功能修改根本不可能還有那美國時間回頭去更新文件。

不知道鄉民們是否和 Teddy 一樣有著相同的疑問：大部分 OOAD 的書不都是教我們要寫很多不同的文件，而且越詳細越好。此外，還要保持文件與程式碼的一致性。實務上，台灣軟體公司大多是中小企業，客戶願意付出的費用通常不足以支付『完美開發團隊』的費用。所以，怎麼辦？

這個問題當年困惑了 Teddy 許久。後來，XP 變得很熱門，也引起了 Teddy 的注意。在一次偶然的機會中 Teddy 讀了Jack W. Reeves 所寫的 "What is Software Design?" 這篇文章，當場茅塞頓開。簡單的說，傳統上軟體設計（廣義的說所有的工程設計）產出物就是文件 (現在的一般作法就是寫 UML 文件)，而『寫程式』這件事算是低層次的『施工』，或是『生產』。基於此種想法，自然會要求軟體開發者要把『設計文件寫得很清楚』，這樣 programmers 就可以『按圖施工，保證成功』。更進一步，programmers 變成生產線的作業員，景氣好的時候可以多找一些人來加速生產，景氣不好就放無薪假。找 programmers 也變得很簡單，只要高中程度稍加訓練即可。更極端一點，分析文件寫好直接就可以產生程式碼，連 programmers 都不用了。傑克，真是太神奇了。

而 Reeves 在該文章說明，code (程式碼) 本身才是『軟體設計』的產出物，而不是文件。至於 compile, link 這些活動才是軟體生產活動，成本趨近於零 （IDE 上面按個按鈕就 OK?）。從這個角度來看，coding 或是 programming 便成為一種『設計活動』，而非『生產活動』。既然 code 是設計文件，而 coding 是設計活動，那麼傳統的文件重要性自然就大大降低了，而應該把焦點放在『如何寫好程式（等於如何做好設計）』上面。從 XP 的眾多活動中可以看出來這種 code-centric design (以程式碼為中心的設計) 的味道，每個 programmers 其實都是設計師。

剛接觸 XP 時，Teddy 簡直把 Kent Beck 當神一樣來崇拜，終於看到一種比較像是給人使用的軟體開發方法了。但是，實務上，XP 的採行還是遇到很多阻礙。一方面有些人覺的 XP 的主張太過極端（軟體領域的邪教？！），有些人則是誤解了 XP 的精神，加上大家對於改變總是怕怕的，因此在台灣實際實施的團隊應該不多。舉一個 XP 所提倡的活動 pair programming 來講，老闆一聽到兩個人一起寫程式，馬上想到成本增加一倍，不被罵死才怪。就算你跟老闆解釋：『這樣可以隨時做 code review，提高品質』，老闆可能會回你一句：『code review 是蝦米碗糕？』。另外，programmers 也不見得願意和別人一起寫程式，因為這樣會剝奪他 MSN 的時間....%!@#!~@

一方面，Teddy 覺的 XP 的很多 practices 很棒，例如 testing, continuous integration, pair programming, refactoring 等。另一方面，可能是 Teddy 沒把 XP 全部看懂，總覺的 XP 在 planning 這方面似乎太抽象了一點，真的要來規劃一整個專案時，還真不知道要如何著手。

一直到兩年前接觸到 Scrum，似乎可以用來填滿原本 XP 在 Teddy 心中懸缺那一塊空間。嗯，Scrum 的 Roles (Product Owner, Scrum Master, Team)，Activities (sprint planning, daily scrum, sprint, sprint review, retrospective)，Artifacts (stories, product backlog, sprint backlog, tasks, burndown chart)，加上 XP practices，真是太速配了。難道這組搭配就是 Teddy 多年來尋尋覓覓的『正確答案』嗎？

很接近了，但是還差那麼一丁點。在某些情況下，Scrum 並不太合適。例如，假設你工作的團隊是要維護某個產品，每天可能都會有客戶回報關於這個產品的 bugs，而你必須要儘快處理。在這種情況下，sprint 長度就算是訂成一週，都嫌太長。如果訂成一天，又可能連一個 story 都無法做完。前幾天看了 Lean 的書籍，裡面提到了 Kanban (看板) ，似乎可以填補這個空缺。就是這個光，Teddy 現在覺的這一套組合產品 Scrum + Lean + XP (ㄟ，其實都是 agile methods) 滿有潛力成為 Teddy 心目中的『正確答案』。不過目前還沒有機會去嘗試 Kanban，所以暫時沒有任何實際的經驗可以報告。


友藏內心獨白：別再找了，根本沒有什麼『正確答案』，只有『適合或不適合的答案』。