l

2012年1月8日 星期日

Scrum 不會幫你解決問題

January 08 09:18~11:00


看到本篇的標題「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:就是 Product Owner。


鄉民乙:!@#$!@#=......


Teddy:請問你了解 Scrum 運作模式嗎?

鄉民乙:大概有看過。

鄉民乙:那如果你的客戶很不講理,經常更改需求,Scrum 有什麼方法可以解決的嗎?

Teddy:(把 sprint planning meeting 和 sprint demo 以及客戶應該要密切參與專案的觀念快速講過一遍 )


鄉民乙:可是客戶就是很不講理啊,假設今天在 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 回答問題的朋友。

6 則留言:

  1. 當時有在案發現場

    給鄉民甲建議 如果需要自學的話
    可以上台大資訊系的資訊訓練班
    便宜課程又扎實~
    希望你能看到

    回覆刪除
  2. 作者已經移除這則留言。

    回覆刪除
  3. To win:

    參加學校的訓練課程應該也是不錯打選擇,沒想到台大資訊系有開資訊訓練班,謝謝分享。

    回覆刪除
  4. 我認為 Scrum 還是有解決「爽」問題的方法。客戶不斷追加及變更需求,造成開發團隊痛苦的原因,我認為在於驗收日期與合約金額不變的情況下,客戶多要、要得更完整更精確,對客戶而言都是有利的,因此以客戶立場來說,就是傾向於會這麼做。而對開發團隊來說,不想接受追加及變更也是正常的。

    在 Scrum 中,客戶可以要求要做這做那,但不能要求何時完工,或者說不能要求完工日期不能改變。客戶必須接受開發團隊所估算,在下一個 sprint 中所估算可完成的成果。客戶能做的,只有修改需求順序,將重要的排前以求擠進目前 sprint,不重要的排後,不一定做得到。

    在這種情況下,客戶若為了爽而變更需求,開發團隊的負擔並沒有加重,只不過目前的 sprint 所能交付的客戶價值變少了,客戶一定覺得虧到,於是就不會單單為了爽而要求變更需求。

    因此,在 Agile 擁抱變更的原則之下,開發團隊並不會因此負擔加重,因此可以做到擁抱變更。變更所導致的時間成本增加,是由客戶自己承擔,因此客戶只會選擇做最重要的功能,變更最重要的需求。

    不過,Scrum 有一個先天的缺點,就是 planning 隔天,客戶還是想改,而且會影響 sprint 成果的話,Scrum 只丟下一句話: 下個 sprint 再說。但是要求目前 sprint 一定要達成承諾,但所有人都知道,正在做的事不是客戶要的東西,那只是浪費所有人的時間。

    因此我比較喜歡 kanban 模式,不必估算,隨時可以調整要做的重要項目。

    不知道這個意見是否又太長了!@#$!#

    回覆刪除
  5. To Chris Torng:

    嗯,我是覺得並不是要求客戶說你不能要求何時完工,或者是要求完工日期不能改變。反而是傾向於說讓客戶了解這些東西何時可以完工,以及為何沒有辦法改變完工日期。(這是在玩換句話說嗎?XD)

    Scrum我並不覺得他是一種拿來限制客戶乖乖的不要亂的手段。而是把客戶拉攏過來的一種方式,讓客戶信任你,以及了解你,所以他不會亂你的方法。

    好吧,上面的確是有一個理想好客戶的情況,不講理的客戶也非常的多。不過我是覺得,遇到這種客戶,大概沒有任何一種軟體開發流程可以解決。Scrum能協助你的也只有很快的讓你知道遇到了一個爛客戶 XD,我也不確定這樣是否有幫助。

    Scrum <--- 一直提這個名詞提到我也覺得好像他就真的只是一個名詞,沒有靈魂了。
    我覺得最重要的還是改變與進步,然後他讓這件事情可以發生的更自然。

    如果客戶每次都到了Sprint Planning才想到要變更需求,那麼要處理的重點應該是如何讓客戶可以在Sprint Planning就把需求想好。另外,如果真的所有人都知道正在做的東西都不是客戶想要的,做下去也是浪費時間。Scrum應該也沒有說那就要硬著頭皮做完,因為這是客戶要讓團隊使用Scrum流程的代價。我記得也有放棄這個Sprint,重新開一個Sprint Planning的選項。

    我想很多情況國外的專家都有遇過也有提出可行的方法,如果目前的處理方法所有人都覺得不好,專家的書中也沒提到,又沒有專家可以詢問,那麼我覺得團隊就應該想辦法去創造出一個可行的方案。

    我喜歡老動畫裡面"中華一番"所說的,陽泉酒家的傳統就是顛覆傳統,我自己認為Scrum也是如此,他對團隊來說應該是要一個可以自我成長與進化的方法才是。

    回覆刪除