本人不是什麼Scrum講師
所以只談實際發生的事情
而那些高大上的東西
就交給專門的講師們
總體言之
Scrum是一種軟體專案的開發體制
被歸類為敏捷開發方法的一員
如果你要告訴一個阿嬤(或你老闆)
什麼東西是Scrum
那其實從反向去思考比較快
為什麼Scrum和其它敏捷方法誕生了?
我們知道很多解決方案的誕生
是源自於舊的解決方案不完美
如果原來解決方案是好的
那就不需要新的解決方案了
反之新的解決方案如果被如火如荼的討論
代表舊方案有瑕疵
瑕疵越大
反彈力道也會越大越火
所以你老闆如果覺得舊方案很好
那就不要多費唇舌和他提新方案
把時間拿去打電動
做做副業更好
通常你老闆願意試著耐心聽你講新方案
代表他遇見麻煩了
想找個天兵天將來解決
在敏捷方法出現前
就已經有很多軟體系統被寫出來了
他們有些用起來很好
有的用起來很爛
有些第一版很好 第二版就死了
有些第一版很爛 第二版成功了
更多的是胎死腹中 你永遠都不知道它的存在
在工業革命時
人類發現了比動物能更具效率和可靠的能量運用方式
使得原先手工生產的產品良率和產能大幅提升
於是很多工廠管理學便因此而生
討論如何在相同的投入下得到越大的輸出
而軟體工程相較於工業革命晚了超過100年
所以初期的軟體專案沿用舊的工廠管理方法
是再自然也不過了
比如說要蓋一間房子
先找設計師畫設計圖
房子幾層,多少隔間
電力系統,排水系統
耐震係數,建築容積
相關法律文件申請
然後開始發包建築公司施工
採購原物料,水泥,磚頭,鋼筋
施工現場則有工頭負責監工
有負責綁鋼筋的工人
有負責灌水泥的工人
有負責砌牆的工人
有負責開堆高機的工人
每間房子大致流程都大同小異
這讓批量化的大基建成為可能
預算和金融槓桿風險全部都可以在事前得知
所以傳統的軟體開發到達一定規模
也類似這些傳統產業的分層架構
只是職務名稱可能不同
有業務,有產品經理,有專案經理
有技術長,有技術人員
這些其實就是投資者,經營者,經理,工頭,工人
這樣的分層架構
它的特徵在於任務的派發是從上而下
我們稱之為傳統的瀑布型開發模型
雖然工業革命不過兩百年
但人類的政治體制已經發展了上千年了
這套瀑布型開發模型很多地方可以套用舊有的政治學理論
自然就受到廣大的管理階層的喜愛
剩下的工作就是讓軟體開發像鎖螺絲一樣容易
讓我們到特力屋,買下軟體積木
然後請廉價工人組裝起來吧
鎖螺絲的時間幾百萬上下
但遺憾的
瀑布型管理要能推行無誤必須建立在幾個前提上
1. 投資者需要能準確的預測未來和市場
2. 設計者的設計方案必須準確無誤
3. 工人要能無障礙的理解設計方案
具備這些條件只有一個,那就是全知全能的耶和華上帝
但人不是神,很明顯會犯錯,而且會大大的犯錯
投資者真能準確預測市場,那就去買股票期貨債券黃金
還投資什麼實業呢?那是人類才會做的事
但事實上如果你對市場有超過50%的預測能力,就可以幹掉巴菲特
那下面做事的人更不用提,有這種能力還給你打工嗎?
有些很神的專案管理師和工程師
似乎可以一次性的把產品做好做對
那是因為他們做過很多爛掉的東西
浪費了很多投資人的錢或工程師的肝換來的經驗
做出來的東西與預期不符
推到重做的比比皆是
每次推倒都能做得比前一次好
最後得到我們手上用的軟體
貴!!!
昂貴!!!
雖然最我們拿到想要的東西
但顯然可以用更少的成本得到我們想要的
所以管理者們就這樣想
是不是可以根據前面的失敗
定下一些規定
讓失敗不會重蹈覆轍
於是專案又失敗了
然後定下更多規定
不斷重複到所有人被這些規定壓垮為止
這顯然是哪裡出了問題了
所以敏捷方法應運而生
他告訴老闆們,採用我這套方法可以避免上面的問題
第一
你要接受人不是神會犯錯
第二
人的的肉體和精神能力有限
在靠核子動力活動的完美AI機器人出現前
你還是得靠這些不完美的人類做事
所以糾錯機制和以人為本的軟體開發方式應運而生
迭代機制取代瀑布型方法
讓錯誤可以被提早發現,提早治療
減少一錯再錯成本
讓韭菜們可以自主性參與專案
而非一刀切的專制體制
韭菜雖是韭菜 倒底也是工程師
可以彌補上層的思慮不周
但你要提供機制讓他能夠幫助你
也就是要引入某些民主制度
重點是: "你要提供機制讓他能夠幫助你"
一台波音飛機失事前
下面的維修工人早幾年前就知道哪裡有問題了
但在公司體制下他是不可能見到有決策權的人
就算見到了 提了也不會聽
外行的有決策權 但內行的沒有
在各行業比比皆是
所以必須把權力放出來
讓內行的人去決定
便是敏捷的一大重點
上面鋪陳那麼多
看官們看見問題了嗎?
放權這件事在管理階層眼中簡直要他老命
你要他承認他外行也不可能
把權力放出來,讓內行的人去決定
這件事物理上正確但政治不正確
本文提Scrum在台灣軟體業推行的難度
首先台灣其實並沒有從製造業升級
以鴻海為首的大製造業比比皆是
手上有資金的人思維仍舊老舊
如同戰功彪炳的開國功臣
你比老子打下更多土地再來和我談
推行Scrum和一些敏捷方法
從根本上會衝擊公司的管理和政治架構
所以你需要的不是Scrum,而是辛亥革命
直接蹦掉老闆當新地主快一點
當然這是開玩笑的
阻力大也得推看看 不然怎麼騙錢(誤)
所以有些地方必須玩半套而沒半法全套
比如說故事點數,站立會議
因為這些沒有碰觸到某些人的核心利益
又"看似"可以更好管理工人
不違反傳統瀑布型管理架構
以故事點數來說
我聽說有公司不成文規定不能超過13點(比方說)
因為這樣會打到分析人員
代表他分析不到位,使用者樣例沒有切分的更小
可是有的使用者樣例本身就超過100點
甚至傷筋動骨1000點都不夠用
可那還是13點怎辦?
政治能力的培養永遠不嫌晚
能閃則閃
拆東牆補西牆
比如說原本的一點的任務報13點
讓接到此故事的工程師能少賠一點
閃不掉的,又不補其它好康的給你時
工程師就得用下班時間來補囉
不然KPI很難看
人家13點一小時做完
你要做那麼多天
你知道人事部門只看報表做事嗎?
原本是發現問題的好機制
結果變成劣幣驅逐良幣的好機制
為什麼呢?因為問題會找人
難解的問題會自然流向強力工程師那
PM只管解目前難題,他不會管公平性問題
久而久之,爽的人會很爽
不爽的人會更不爽
所以我現在一聽到有某某公司在run Scrum
隨便觀察幾個關鍵地方就知道會不會成功了
根本無需深入團隊
體制直接決定成敗
因為你只是口頭上說Scrum
和某人喊全民脫貧不是一樣的東西嗎?
又回到老問題
張嘴就來 口說就有
從今日到永永遠遠
唯有上帝耶和華
昔在今在永在神
所以謙卑才是能不能成功的要素