看到本篇的標題「Scrum 不會幫你解決問題」鄉民們可以會想：「那我還學個屁啊」。嗯嗯...先不要急著轉台，看完之後再說。
***
昨天是舉辦「Scrum 軟體開發工具與方法—系列講座 (五)」的日子，Teddy 一早 10 點鐘就先到北科大找指導教授聊天，一直聊到下午 2 點講座快開始之前才「趕」到會場（因為舉辦講座的場地與指導教授的研究室在同一棟大樓）。
昨天 Teddy 分享的題目是「使用Java與C/C++之跨平台軟體開發」，由於 Teddy 第一次分享這個主題，時間拿捏的不是很好（介紹 Teddy 坎坷身世的那一張投影片講太久了...Orz），最後還是有幾張投影片沒有講到。感謝主辦單位給 Teddy 的這機會練習（參加人員內心獨白：那我們不全成了白老鼠...XD）。
活動結束之後有幾位鄉民跟 Teddy 討論幾個問題，其中有兩位鄉民問 Teddy 的兩個問題讓 Teddy 印象最為深刻。
***
鄉民甲：我有一個系統以前是用 VB 開發的，現在要用 C# 改寫，而且要考慮系統擴充性的問題，有沒有什麼書可以看了之後可以解決我的問題。
Teddy 內心獨白：這和今天的主題或是 Scrum 好像沒有什麼關係耶。（這句話當然是放在心裡沒講出來...XD）
Teddy：可以請你把你的問題講得具體一點嗎？
鄉民甲：目前這個系統只有我一個人負責，我開發軟體有 10 幾年的經驗了，但是以前都沒有使用 OO（物件導向）的經驗，現在要把原本 VB 的程式用 C# 改寫。我設計了很多物件，但是可能是因為 OO 觀念不熟，再加上改寫的過程中還要考慮新的功能還有系統架構的問題，所以改寫得很不順利。
Teddy：你有看過 Teddy 的部落格嗎？（利用機會推銷一下）
鄉民甲：沒有。
Teddy：那建議你回去先看一下 Teddy 的部落格。
鄉民甲：!@#!$%@!#.....
Teddy：聽起來你的問題應該不是一本書可以解決的，比較像是物件導向分析設計與程式開發的問題。如果公司內部沒有具備這樣能力的人可以幫忙，也許你們應該找外面的顧問來協助。
Teddy：又或者是你可以考慮到坊間的補習班去上課，這樣比起自學會比較快。
鄉民甲：!@#%@!#!@S!@#。
***
鄉民乙：在 Scrum 中是誰負責定義需求？
Teddy：Product Owner。
鄉民乙：這個 Product Owner 是業務，PM（專案經理）還是....
鄉民乙：!@#$!@#=......
Teddy：請問你了解 Scrum 的運作模式嗎？
鄉民乙：大概有看過。
鄉民乙：那如果你的客戶很不講理，經常更改需求，Scrum 有什麼方法可以解決的嗎？
Teddy：（把 sprint planning meeting 和 sprint demo 以及客戶應該要密切參與專案的觀念快速講過一遍 ）
鄉民乙：可是客戶就是很不講理啊，假設今天在 sprint planning meeting 剛剛談好也估完的 stories，客戶隔天還是要改變那怎麼辦？
鄉民乙：可是客戶就是很不講理啊，假設今天在 sprint planning meeting 剛剛談好也估完的 stories，客戶隔天還是要改變那怎麼辦？
Teddy：請問改變的理由是什麼？
鄉民乙：沒有理由啊，就是他爽。
Teddy 內心獨白：啊現在是什麼情況...
其實此時 Teddy 已經快沒力了，從早上 10 點到下午 4 點，Teddy 連續講了6小時的話，已經有點神智不清了。好里加在，此時有位想要找 Teddy 當「家教」的朋友（在2011年4月 MaoYang 所舉辦的 Scrum 分享活動中所認識的一位很有趣的鄉民）跳出來幫 Teddy 解危：
朋友：我幫 Teddy 回答一下，Teddy 曾經講過一句「至理名言」...
Teddy：真的嗎？那一句，我趕快拿筆記下來...XD。
朋友：你自己講過的話還要自己記下來喔...XD。
Teddy：因為我講過的嘉言名錄太多了，多到自己都忘了...XD。
言歸正傳...
朋友：就是「Scrum 本身不能幫你解決問題，但是可以幫你把問題暴露出來」。很多軟體開發所遭遇到的問題，其實專案團隊或是客戶都知道，但苦無沒有一個好的機制或是框架可以讓大家一起開誠布公的正視、溝通、討論、與改善這些問題。至於問題暴露出來以後要如何解決，就要靠團隊的努力（不然這些搞軟體工程方法和 agile practices 的人不是沒飯吃了）。
對對對，Teddy 都忘了曾經講過這句話：「Scrum 本身不能幫你解決問題，但是可以幫你把問題暴露出來」。「沒有銀子彈（No Silver Bullet）」這句話鄉民們應該都知道，軟體開發不可能因為有了 Scrum 的出現所有問題就迎刃而解。就好像戰爭一樣，如果無法一舉殲滅敵人，就只能想辦法各個擊破。
回到鄉民乙的問題，Teddy 不認識鄉民乙的客戶，無法得知為何該客戶會因為一個「爽」字就要修改需求（難道鄉民乙的客戶叫做史地芬周...XD）。有可能是因為該客戶之前所經手的軟體專案都不順利，所以對於軟體開發團隊抱持著不信任的態度。也有可能是客戶太忙，沒時間，或是沒人教他要如何思考與確定需求。所以導入 Scrum 還是要團隊依據自己的現況因地制宜的判斷與解決問題。鄉民乙可以思考先提昇團隊所開發出軟體的品質，讓客戶感受到團隊的產出物（軟體或文件）品質變好，時程也沒有像之前延誤的那麼嚴重，也許慢慢地客戶的態度也會跟著改變。
話說回來，如果隨便把 Scrum 看一下軟體開發的問題就都解決了，那 Teddy 不就不用混了，可以改行賣雞排或是最近流行的滷味。難道要吧 Certified ScrumMaster 的證書貼在滷味攤前面嗎...Orz。
***
友藏內心獨白：演講費是不是要分 100 塊給幫 Teddy 回答問題的朋友。
當時有在案發現場
回覆刪除給鄉民甲建議 如果需要自學的話
可以上台大資訊系的資訊訓練班
便宜課程又扎實~
希望你能看到
作者已經移除這則留言。
回覆刪除踢館者 殺無赦
回覆刪除To win:
回覆刪除參加學校的訓練課程應該也是不錯打選擇，沒想到台大資訊系有開資訊訓練班，謝謝分享。
我認為 Scrum 還是有解決「爽」問題的方法。客戶不斷追加及變更需求，造成開發團隊痛苦的原因，我認為在於驗收日期與合約金額不變的情況下，客戶多要、要得更完整更精確，對客戶而言都是有利的，因此以客戶立場來說，就是傾向於會這麼做。而對開發團隊來說，不想接受追加及變更也是正常的。
回覆刪除在 Scrum 中，客戶可以要求要做這做那，但不能要求何時完工，或者說不能要求完工日期不能改變。客戶必須接受開發團隊所估算，在下一個 sprint 中所估算可完成的成果。客戶能做的，只有修改需求順序，將重要的排前以求擠進目前 sprint，不重要的排後，不一定做得到。
在這種情況下，客戶若為了爽而變更需求，開發團隊的負擔並沒有加重，只不過目前的 sprint 所能交付的客戶價值變少了，客戶一定覺得虧到，於是就不會單單為了爽而要求變更需求。
因此，在 Agile 擁抱變更的原則之下，開發團隊並不會因此負擔加重，因此可以做到擁抱變更。變更所導致的時間成本增加，是由客戶自己承擔，因此客戶只會選擇做最重要的功能，變更最重要的需求。
不過，Scrum 有一個先天的缺點，就是 planning 隔天，客戶還是想改，而且會影響 sprint 成果的話，Scrum 只丟下一句話: 下個 sprint 再說。但是要求目前 sprint 一定要達成承諾，但所有人都知道，正在做的事不是客戶要的東西，那只是浪費所有人的時間。
因此我比較喜歡 kanban 模式，不必估算，隨時可以調整要做的重要項目。
不知道這個意見是否又太長了!@#$!#
To Chris Torng:
回覆刪除嗯，我是覺得並不是要求客戶說你不能要求何時完工，或者是要求完工日期不能改變。反而是傾向於說讓客戶了解這些東西何時可以完工，以及為何沒有辦法改變完工日期。(這是在玩換句話說嗎？XD)
Scrum我並不覺得他是一種拿來限制客戶乖乖的不要亂的手段。而是把客戶拉攏過來的一種方式，讓客戶信任你，以及了解你，所以他不會亂你的方法。
好吧，上面的確是有一個理想好客戶的情況，不講理的客戶也非常的多。不過我是覺得，遇到這種客戶，大概沒有任何一種軟體開發流程可以解決。Scrum能協助你的也只有很快的讓你知道遇到了一個爛客戶 XD，我也不確定這樣是否有幫助。
Scrum <--- 一直提這個名詞提到我也覺得好像他就真的只是一個名詞，沒有靈魂了。
我覺得最重要的還是改變與進步，然後他讓這件事情可以發生的更自然。
如果客戶每次都到了Sprint Planning才想到要變更需求，那麼要處理的重點應該是如何讓客戶可以在Sprint Planning就把需求想好。另外，如果真的所有人都知道正在做的東西都不是客戶想要的，做下去也是浪費時間。Scrum應該也沒有說那就要硬著頭皮做完，因為這是客戶要讓團隊使用Scrum流程的代價。我記得也有放棄這個Sprint，重新開一個Sprint Planning的選項。
我想很多情況國外的專家都有遇過也有提出可行的方法，如果目前的處理方法所有人都覺得不好，專家的書中也沒提到，又沒有專家可以詢問，那麼我覺得團隊就應該想辦法去創造出一個可行的方案。
我喜歡老動畫裡面"中華一番"所說的，陽泉酒家的傳統就是顛覆傳統，我自己認為Scrum也是如此，他對團隊來說應該是要一個可以自我成長與進化的方法才是。