gipi的學習筆記-經營管理、數據思考、終身學習

（http://traderassist.com/team-partners/what-i-bring-to-the-table-alex-pressl/）

趁著夜深人靜時來寫這篇有點生硬的文章，近來常聽到有些朋友在談Scrum這個軟體開發方法，Scrum的開發流程與規範比起CMMI這個怪物來看，似乎精簡很多，規範也少很多，對文件的要求似乎也沒那麼多，也沒有那麼講求需求收集、分析、設計後才寫程式這樣的規則，台灣有愈來愈多的團隊選用Scrum這樣的開發方法，我曾問過一些使用Scrum的朋友，為什麼選擇Scrum？不問還好，一問之下讓我覺得挺擔心的，因為很多人選擇Scrum是因為不用想太多，不用寫太多文件，也沒有那麼多的規定，所以選擇Scrum，我覺得以程序簡不簡單來選擇開發方法是很危險的，正確的選擇方式還是要講求合適性。

複雜或簡單，不是選擇開發方法的標準
我想這邊我為CMMI平反一下，CMMI真的開始複雜是在LV3以上，LV2以下都還算非常簡單，另外，Scrum也不是不用寫文件，如果文件是開發的必要交付項目，你還是要排入Story中，當你被要求做的事情愈來愈多，Product owner就會在每個Sprint中排入許多非coding的工作，這時候你還是要寫文件，還是要開規格，還是要做測試，還是要做交付，你做的工作不見得會比走CMMI的團隊更少，所以千萬不要將Scrum跟CMMI兩者用「複雜程度」做區分，當然了也不會是你選擇開發方法的標準。

個人喜好，也不是選擇的標準
有人宣揚Scrum的好，我問他為什麼？他告知我Scrum很方便，只要Sprint訂出來，Story/Task清楚，再來PG就可以自己任領自己想要做的工作，而不用等待PM來分派工作，每個人擁有更多的自主權，做多少績效都算是自己的，這對身為PG的他來說是非常好的誘因，但他可能沒想過團隊成員的素質參差，程式品質與開發工時的管制問題很大；有些主管喜歡CMMI，覺得CMMI導入後程序相對有結構性，連工作報表、程式品質都可被管理與監控，有助於他的管理，但他可能沒想到建置一套完整的CMMI管理規範與實際執行時要花費多少人力，依據個人洗好來選擇，是挺危險的一件事情。

合適才是唯一依規
Scrum不見得簡單，CMMI也不見得相對複雜，Scrum很合適於用在需要快速交付部分成果給Sponsor的團隊，因為每個Sprint都會交付一部分Sponsor希望看到的結果，不用等到整個系統開發完才交付；CMMI適合用在較大型的開發團隊，因為有較嚴謹的規範與流程驗證機制，可以確保這個大團隊中大家的產出都是可交付給下手的，也有流程確保被驗證，但這都不是絕對的分野，若說要在團隊中導入開發方法，建議可以參考以下順序：

1.先了解你的團隊狀況、系統特性、工具等：你的團隊是否足夠成熟？團隊成員的能力是否相近？系統的需求是否明確？sponor的要求是什麼？是否有足夠的工具協助流程執行？
2.挑選其中一種開發方法：從1.的分析結果當中挑選出較接近的開發方法，可能是Scrum、XP、CMMI、RUP…
3.調整到合適的流程：如果你選中了CMMI，但你不想在專案規劃時還要寫PEP，也不想做需求追溯，那你可以依循CMMI的精神，但不要全盤照抄，因為每家通過CMMI認證的公司，他們的流程都不太一樣；而若你選擇的Scrum，但Sponsor希望可以將文件做完整，那也可以在開發時將文件當成必要的交付物，將流程調整到最合於現況，而非只懂依循
4.持續優化：專案管理有持續精進的作法，開發方法也有持續優化的必要，一個流程不是訂了就不能改變了，而是該隨著專案特性、sponsor的要求、團隊成員的成熟度、工具的完備度等來調整我們的開發流程，沒有流程是危險的，但有流程而不懂優化是迂腐的，流程本身一定要持續的被優化才行。

其實現在很多公司談開發方法都是混搭，也就是部分的Scrum+部分的CMMI，純的Scrum或者純CMMI不見得合適於每個團隊，所以流程的合適性是必須要被嚴謹看待的，唯有當開發流程導入的好處大於壞處時，這個流程才算是合適的，導入開發流程可以局部局部來，不必要一次到位，但唯一準則就是「合適」，唯一的要求就是「優化」。

游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。