Scrum 並不能夠幫助你寫出更好的程式碼,也不能夠保證你發想的軟體產品可以在市場上獲得成功,基本上在任何處理跟人有關的議題時,任何方法都不能夠保證可以收到什麼功效。而 Scrum 在軟體開發過程中可以提供的幫助是,如果你的團隊真的懂怎麼寫程式的話,起碼可以讓他們有多一些時間可以把程式寫出來。
如果要給 Scrum 這個字一個簡短的解釋,那就是「Stop Crazy, Restless but Unnecessary Meetings」,少開會沒事,沒事少開會。如果我們想要了解一把槌子,我們首先要了解的是這把槌子要拿來搥的是怎樣的釘子,如果我們想要了解一門方法,首要工作就是這門方法打算解決怎樣的問題。Scrum 所要解決的問題就是:在上班時間中,太多的會議造成工程師最後沒辦法把程式寫出來。
軟體開發團隊的工作,大抵上就是找一群人來,朝著同一個目標各自從自己的體內擠出一些東西來,也就是,工程師這行基本上跟一部顏射 A 片裡頭背景那群汁男優差不多,流…血流汗,最後產品上市你也不會露臉,人家只需要你有用的部位而已。
做這麼一份工作,需要的是一段時間專心,需要時間進入情境,中間若遇到任何打擾—有人跑來指導你不該這麼弄應該怎麼弄,或是這部片先不拍了所有人先去另外一個攝影棚—就得從頭來過,如果軟掉了,一定要重新花上一段時間才能硬起來。而當你在嘗試設計一個架構,或是在檢查一個很深的 bug 的時候,你卻經常被打斷,老闆要你聽他昨天晚上夢見的天才商業計畫,或是不斷追加規格,要求添加一個老闆心中覺得很簡單,但是工程規模其實是要將軟體整個重寫的功能,甚至是昨天告訴你要做的事情,今天告訴你應該先去做另外一件事。這樣要怎麼做事呢?
我們來看 Scrum 的流程。Scrum 將整個軟體開發週期,切分成許多較小的衝刺期(Sprint),意義就在於,在衝刺期內就不要再開會、不要再修改規格、不要再任意繼續添加新的商業規則到目前的成品中,先完成目前制定的目標再說。但是我們還是要追蹤目前進度啊?那也不該開會,只要每天開始上班的前幾分鐘大家各自簡短報告就好,而且要站著報告,因為必須是站著,大家才會想儘快結束。
在 Scrum 流程中設計了一個叫做 Scrum Master 的角色,是整個 Scrum 流程的主導人,負責規劃有哪些階段的衝刺期以及目標,每天早上的工作進度也是向他匯報。但 Scrum Master 最重要的工作不是這些,而是防止老闆或是公司其他管理階層人員經由會議等方式騷擾正在埋頭苦幹的工程師。老闆想知道進度,想改什麼功能,有什麼新需求想要有人評估,問 Scrum Master 就好,不要直接找工程師;Scrum Master 在一早取得團隊的基本情報後,接下來一整天就是以這些情報對老闆營造幸福的錯覺。當勇者在前方打仗的時候,Scum Master 要負責對後方亂源施展癱瘓魔法。
Scrum 自然不能保證專案可以獲得商業上的成功。我們試想以下兩種狀況:老闆有十個點子,但是只有其中一項可以成功,但是卻打算十個點子都想要做,結果所有人疲於奔命,但是最後一個點子都沒做出來,就把公司資金燒完了—說到這個,不久前林益世他老母居然真的把美金拿去燒,想燒錢,我可以開網路公司幫忙燒啊!
或,十個點子中,只選擇了其中一項,最後做出來上市,但賣得一踏糊塗。Scrum 可以幫助你走向後面這一種失敗,而雖然兩種狀況都是失敗,只少後面這種失敗稍微優雅點,而且好歹還是有一些實際的產出,後著跟前者比起來,至少還留下了一些可供憑弔的紀念品。
與其將 Scrum 當作是一門軟體工程方法,不如想像成是一種調整辦公室文化,阻止管理階層胡亂管理的反管理(Counter Management),管理眾人之事的人其實更需要被眾人管理。所以如果你是因為聽說 Scrum 這種方法不錯,於是首先在公司裡頭召開了 Scrum 方法導入籌備會議,挑選了幾個經理或是資深工程師擔任 Scrum Master,甚至是老闆自己跳下來當 Scrum Master,再定期召開 Scrum 方法導入考核會議…這樣做,絕對無法導入 Scrum。
事實上,狀況會變得更糟。你會發現老闆的餿主意一個都沒有少,原本的會議也一個都沒少,但是每天開始上班的時候卻又多了一個會議。
Scrum Master 在 Scrum 流程中及其重要,必須具備可以阻止老闆一切愚蠢行為的影響力,能夠讓老闆言聽計從:公司的原有成員都無法擔任 Scrum Master,因為他們都無法阻止老闆的干涉,必須要找公司外面的人。最適合擔任 Scrum Master 的人選莫過於老闆的小三,元配不一定有用,但是這也不太實際,畢竟小三不見得在同一個行業裡頭,所以,如果你想要導入 Scrum,你一定要以高薪聘請顧問不可。
顧問的武器就是以各種光環震攝老闆。一般常見的光環是證照,而既然我們希望這光環又熱又亮,想來這證照也就一定不可能便宜;再來就是要三不五時自然流露出些超凡脫俗鶴立雞群的人格特質,在冰冷的工程世界中卻富涵深厚的人文關懷,在討論記憶體配置問題的時候,卻可以聯想到濟慈與王爾德的詩,讓老闆情不自禁由衷信服。
而想要導入 Scrum 最好的方法,莫過於直接聘請不才小弟我擔任顧問,端出各種防止老闆干擾工程師的方法,從把老闆帶去信仰新興邪教,到拔指甲、挑腳筋以及更多更獵奇的手段,一應俱全;報酬方面,我也一定會向你索收喪盡天良的金額。
以上。
借轉貼至FB,謝謝
That’s so fucking cool!
已經轉貼至 FB 社團 CocoaHeads Kaohsiung
如果能把汁男的隱喻實在中肯,應該寫成軟體工程論文的
相信這個論述會被廣大的工程師所支持
ex:「專業的汁男,就算是對象不如人意,還是得想辦法硬起來上…」
我轉貼到 FB 去了 🙂
好讚的文,借我分享到FB ~
更了解了scrum的面向呢,借我轉FB
我要吐槽一下,scrum 強調的是自我管理的團隊,所以 scrum master 並不負責決定 sprint 要做哪些事情,每天的 daily meeting 更不是要跟 scrum master 報告。照這篇文章的說法 scrum master 變成傳統的 PM 角色了,而 scrum 裡面是沒有 PM 的。
所以只要強調自我管理的團隊這麼個強調一下,人家就真的會讓團隊自我管理?別鬧了。
由 Product Owner 決定做什麼(what),由 Team member 決定如何做及可以做多少(how&how much),這是 Scrum 所謂的團隊自我管理規則。而 Scrum Master 這個角色的目的就是要阻止一切破壞團隊自我管理機制的影響力啊 XD
不管是Project Manager也好,Team Laeder也罷,還是Scrum Master都行;重點還是在於一件事–不管機制多好,老闆或高階管理職那群人不徹底執行機制的話,還是一樣沒用不是嗎?
要談優秀,Projcet的實行方法多的是優秀的機制,防禦或反管理也不是一天兩天的事了
所以問題根本不在導入了什麼機制
而在於機制真的有被執行嗎?PM,LR,SM,真的能/敢反擊他的上層管理者嗎?
上層管理者真的能理解機制本身的機轉
轉身去忙他該忙的事而不是在那裡管些他不該管的嗎?
真的能在被防禦的時候說「好的我知道了,我們討論完後不可行就放棄」
而不是「我不管怎樣你們都一定要做到,這很重要」嗎?
這才是重點吧
請那些管理方面的人才快想些方法解決這個,我覺得能拿諾貝爾和平獎(應該沒誤吧?)