Sept. 20 17:11~18:37
Teddy覺得馬蓋先充分反映出敏捷精神啊 XD。
***
在9月13日第一次的「C.C. Agile 每月聚會」中，來了兩位很特別的朋友。一位是在公司中擔任QA的鄉民甲，另外一位是Teddy的學弟，今年剛剛博班畢業正在準備找工作當中，在此以學弟甲稱之。算起來Teddy和鄉民甲還有一點點淵源，因為他說「我們是Certified ScrumMaster課程的同學」。啊，真是不好意思，Teddy記性太差，都忘了…Orz。但是，這不是重點，重點是，鄉民甲的公司是通過CMMI Level 3認證的公司。這就有趣了，Teddy很好奇為什麼鄉民甲會跑來參加Agile社群聚會。
Teddy：你們公司既然是實施CMMI，怎麼你會來參加這個敏捷社群的聚會呢？
鄉民甲：因為我們公司的案子種類很多，對於規模比較大的政府包案，我們都是採用CMMI。但是有些公司內部專案，就不一定合適使用CMMI。所以我在思考在這種公司內部專案中，導入Scrum的可行性。
Teddy：請問一下，你們公司執行CMMI的成效如何？
鄉民甲：我覺得成效很好。
Teddy：可是我之前遇到好幾個不同的朋友（軟體背景），他們都對CMMI給予「負評」。像是花費太多的時間與人力在製作「文件」上面。
鄉民甲：我們公司有採用一些自動化的工具，可以自動產生很多CMMI所需要的佐證資料。
Teddy：這樣啊，這麼神奇 
鄉民甲：開發人員會對CMMI有負面的看法，可能是他們只看到自己的案子。而我所負責的工作，必須要看到全公司的所有案子，看得比較全面性，所以我會覺得導入CMMI之後，專案變得比較有制度。
Teddy：那請問導入CMMI的顧問，有教你們如何開發軟體嗎？例如，如何做軟體設計、如何做review等等。
鄉民甲：導入的顧問是不管這些的，他們負責告訴我們，要通過CMMI認證，需要做到那些事情，以及需要哪些佐證資料來證明你做到了這些事情。
鄉民甲：例如，以code review來說，CMMI在評鑑的時候，需要看到我們有做code review的佐證資料，但導入CMMI的顧問並沒有教我們怎麼做code review，只是告訴我們這件事（code review）是要做的，而且要留下佐證資料。
Teddy：這樣啊。那如果假設程式中有100個bug，你們做了code review之後，只發現了1個bug，這樣也可以嗎？
鄉民甲：沒錯，我們目前遇到的情況是，CMMI評鑑的過程，只管我們在做code review的時候，有沒有留下佐證資料，不會去看實際上code review真正是否有把該找出的問題給找出來。導入的顧問也不可能懂那麼多細節啊。
無論如何，總算是讓Teddy遇到一位對於導入CMMI有著這麼正面評價的鄉民。
***
後來Teddy跟學弟甲聊到開發流程的這個問題。學弟甲的技術能力很強，在學校念書的時候，也幫忙做了很多專案，尤其是負責過國科會WiMAX整合型計畫，負責「整合」的那個人…之一，所以關於開發流程也頗有見解。
Teddy：你對開發流程有何看法？
學弟甲：其實我對流程的看法很簡單，別盲從，要適地、適情況調整合適的流程就可以。
學弟甲：我自己做專案的經驗，沒有一個流程是不需要調整就100%完美的。
Teddy：非常同意。我最早做專案的時候，當時只知道waterfall流程，也是傻傻地用了幾年。後來才知道waterfall流程對於需求變更的反應比較差，但是至少它讓我非常清楚的知道每一個開發階段要做什麼事情。後來改用RUP，也是在試了一年之後才慢慢體會use case driven，architecture centric的意思。在後來改用Scrum之後，其實我是在Scrum的框架，混用RUP與XP的若干工程做法（Scrum本來就只是一個框架，沒有規範工程作法，所以混搭也是很正常的）。
***
前一陣子Teddy讀了《Lean from the Trenches: Managing Large-Scale Projects with Kanban》這本書，書中的做法基本上也是混用了Kanban、Scrum、XP。作者在書中有一段話Teddy覺得滿有意思的：
Using Kanban to Discover Scrum
This seems to be a general pattern: I see many Kanban teams that gradually discover (or sometimes rediscover) the value of many of the Scrum practices. In fact, sometimes Kanban teams start doing Kanban because they didn’t like Scrum and then later discover that Scrum was actually pretty good and their problems has been exposed by Scrum, not caused by it. Their real problem was that they had been doing Scrum too much “by the book” instead of inspecting and adapting it to their context.
***
Teddy還是那句老話：「Scrum 本身不能幫你解決問題，但是可以幫你把問題暴露出來」。不管是哪種流程，只要能夠有一個良好的機制，可以把專案與團隊所遭遇的問題給凸顯出來，並且提供一個可以持續改善的機制，這樣這個流程就已經是很不錯的流程了。重點在於團隊成員與組織是否有決心、毅力、專業能力，去把所遭遇的問題給逐一解決。只要有機會，每一種流程都可以嘗試去了解一下。
也許有一天當大家都不特別去談論流程，卻又可以把專案做得非常成功的時候，那就是找到「流程銀子彈」的時候…XD。至少在目前，以Teddy個人的經驗，覺得敏捷方法中的Scrum + Lean ( + Kanban) + XP 混著一起用，似乎是比較合宜的方式（請參考「就是這個光：Scrum + Lean + XP」）。
***
友藏內心獨白：不是不報，是時候未到啊 
Teddy記性不好+1
回覆刪除