今天拜飛機了沒? – 談敏捷開發中的貨物崇拜

18ybvedkdg508jpg

如果世世代代都住在一個被大洋環繞的小島上的村落,靠著採集和捕魚為生,村子中最先進的科技是獨木舟,當有天突然看到飛機飛過頭頂時,心裏的OS是什麼呢?

在二次世界大戰時,美日兩國為了爭奪太平洋的制海權和制空權,紛紛在汪汪大洋中、既偏遠又與世隔絕的島嶼駐軍。當軍隊開到時,島上的村民眼看著海上的超級大箱子(軍艦)靠岸,大鳥(飛機)從從頭頂飛嘯而過,還有神仙(士兵)從大箱子和大鳥走出來,下巴都掉到合不起來。

如果換成我的話一定覺得神仙降臨來處罰世人,世界末日要到了!幸好這群神仙不但沒有處罰世人,還賞了不少寶物給村民,如生病時吃了就痊癒的仙丹、會變出食物的盒子等等。當世界大戰打的如火如荼時,這是村民世代以來過的最好的日子,根本就是身在天堂啊。

可惜好景不長,幾年後世界大戰結束了,這些島嶼的戰略價值消失,軍隊慢慢撤出。村民眼看著神仙們走光,剩下來的寶物也越來越少,心中越來越著急,怎麼辦呢?這時就有聰明的村民說了,一定是神仙覺得我們不虔誠,只要我們表現出敬意,神仙就會回來賞賜我們寶物的!

數十年後,當人類學家到達這島嶼上,發現村民用樹木打造出飛機、刻出步槍、在身上畫USA,模仿當時駐軍做的事情,還在期待有一天神仙回來帶給他們寶物。人類學家把認為模仿表像(木頭飛機)就能帶來實質利益(藥品食物)的行為稱作貨物崇拜


聽起來很天真、感覺只會發生在荒島的貨物崇拜行為,其實經常發生在身邊的對話。

基本句型是:『只要』做一個行為,『就會』得到你要的結果。企業組織內這種句型不少,根本就是萬用句型。

「要怎麼樣賺錢?」
『只要毛利抓3%,我們就會比紅海更紅哦。』

「要怎麼樣創新?」
『只要讓每個人有20% Time,我們就可以跟孤狗一樣金頭腦哦。』

「要怎麼樣讓大家表現更好?」
『只要有績效考核加上KPI,我們就會比政府更有效率哦。』

「要怎麼樣更了解市場?」
『只要用Big Data,我們就可以做出外星科技哦。』

「要怎麼樣更快做出產品?」
『只要敏捷和Scrum,我們就會比非死不可死更快哦。』

遇到這種句型,可以先檢視一下因果關係是否正確,如毛利3%是結果、還是原因?如果可以賺4%不賺嗎?

就算有因果關係,也可能過度簡化,把複雜的動態系統關係簡化成線性關係。孤狗創新除了20% Time,還可能有辦公室設計、特地挑選有創意的人、升遷方式等等。

回到跑敏捷的團隊,相信也多少聽過類似的話。

「要怎麼樣做好產品?」
『只要我們用使用者故事(User Story)寫需求,顧客就會愛死我們的產品哦。』

「要怎麼樣進步?」
『只要我們每個禮拜都開自省會議Retrospective,我們就會天天向上哦。』


敏捷 Agile 最重要是自我察覺,要怎麼知道有沒有貨物崇拜作祟呢?

Stefan Wolpers 有整理一份敏捷貨物崇拜清單The Cargo Cult Agile Checklist),經作者同意後翻譯成中文如下,一起看看我們飛機拜的多虔誠 XD。

敏捷貨物崇拜清單(簡稱拜飛機清單)

我們一起來看看一些組織內常見的拜飛機儀式。本清單假設組織使用Scrum,但其他的敏捷方法一般也是適用。如果符合組織的情況,請回答“是”。(備註:組織越大可能越不適用本清單。)

  1. 沒有溝通(產品的)願景和策略
  2. 產品藍圖和發佈日期在一年前就由CTO規劃好了
  3. 組織內沒有人跟顧客對談
  4. CTO和利害關係人堅持所有的改動都要經由他們批准
  5. 因為保密資安等理由,禁止使用實體的看板或告示
  6. 利害關係人直接跟CTO對談,跳過Product Owner
  7. 由利害關係人來決定交付產品增量,而不是Product Owner
  8. 專案/產品只有在完成時才交付,而不是增量式的交付
  9. 避免利害關係人直接跟開發團隊對談
  10. Product Backlog是由一個產品委員會決定的
  11. 就算對功能的價值有所懷疑,但還是硬上了(為了年終獎金…)
  12. 業務為了成交,答應客戶增加目前不存在的功能,而Product Owner不知情
  13. 就算是不重要的問題,也有固定的進度表和期限
  14. 負責產品管理的角色沒有取得商業智能(BI)資訊的權限,沒有充足的資訊和數據幫助決定
  15. 利害關係人使用需求文件來和產品與工程部門溝通
  16. Product Owner大部分的時間都在撰寫和管理使用者故事(User Stories)
  17. 在Sprint開始後不久Sprint Backlog就變了
  18. 專門成立一個開發團隊來修Bugs和處理小的需求
  19. 利害關係人沒有參加過Scrum活動(例如Sprint Planning和Sprint Review)
  20. 主要是用『速率(Velocity)符合當初的承諾』來當指標評估Scrum是否成功
  21. 開發人員沒有參與創造使用者故事
  22. 同時處理的專案數量和工作會改變開發團隊的人數跟組成方式
  23. 在Daily Stand up中團隊成員對ScrumMaster報告
  24. 定期舉行自省會議(Retrospectives),但沒有改變隨之發生
  25. 開發團隊並不是跨功能(Cross Functional),而要靠其他團隊或部門才能完成工作

組織敏捷貨物崇拜虔誠度測試(簡稱拜飛機測試)

這是很有趣的活動,試試把清單列印出來,花個五分鐘讓團隊中的每個人作答,依照結果分析和評估一下目前的狀況。

平均0 – 2個是:太神奇了,可以跟我(作者)聯絡你們是怎麼辦到的嗎?
平均3 – 5個是:事情看起來是在對的方向發展
平均6 – 8個是:有可改善的空間,蠻多的
平均9 – 14個是:如果你們不是剛剛開始跑敏捷,也許可以考慮換個實行方式
平均15 – 20個是:試試重新開始導入敏捷吧,目前的安排在你們組織沒有用
平均21 – 25個是:要嘛是你們還沒開始跑敏捷,要嘛是在傳統的專案方式外包裝了敏捷的糖衣,良心建議:這沒有用的。

(譯者注:分數是有趣,而交流一下每個人那些問題回答“是”,有那些相同,那些不同,收穫會更大)

結論

敏捷沒有教戰手冊是套入後就可自動在你的組織運行順利的,你必須要找出屬於自己的敏捷方式,先嘗試用其他組織成功的方法。

如果這方法對你也有用,那太好了,就繼續用吧。如果沒用,就試試其他方法。更改甚至是取消標準的敏捷儀式是絕對沒問題的,只要能幫助你判斷在你的組織中什麼事情是有用的。如果你看到其他合適的實踐方式,也別遲疑,就依照組織的情況修改試用吧。

 

圖片來源:http://gizmodo.com/what-burning-man-has-in-common-with-a-south-pacific-car-1207361630

作者: Yves Lin

Trying being agile in the fun way. 喜歡并相信敏捷,期許能帶入一些不同的思維,能讓華語圈不只軟體產業,都可以更敏捷。

4 thoughts on “今天拜飛機了沒? – 談敏捷開發中的貨物崇拜”

  1. 非常感謝你的翻譯,收穫很多!!!
    有點好奇想請教一下,那 3 – 5 的「是」,應該是哪幾題比較恰當呢?
    像是 【18.專門成立一個開發團隊來修Bugs和處理小的需求】
    我見過有的團隊有,有的團隊沒有,到底是有比較好還是沒有比較好呢?

    喜歡

    1. 很高興這文章對您有幫助!

      我覺得只要是5個以下的“是”,不管是那些題都算是跑得蠻順利的團隊了。至於那些恰當,還是要看回團隊的Context,目前影響團隊最大的是什麼問題?目前解決什麼問題是花費最小而效益最大的?

      如果要我選最個人認為嚴重的幾個問題,我會選『24. 定期舉行自省會議(Retrospectives),但沒有改變隨之發生』和『2. 產品藍圖和發佈日期在一年前就由CTO規劃好了』。

      選24原因是只要能持續改善,就能逐漸解決問題,朝更好的方向前進。選2是因為敏捷如沒高層支持,路會比較艱辛,而在一年前就決定產品,是傳統專案的思維,要改變想法要機緣。其他的問題我覺得都只要做到24,都有機會解決的。

      關於『18.專門成立一個開發團隊來修Bugs和處理小的需求』。如果按照敏捷的定義,完美狀態是組成一個端到端,可以處理所有產品問題的團隊,來提高生產產品的彈性,所以全部的需求和修Bug都由一個團隊完成是比較理想的。

      由另一個團隊專門處理小的需求是一個有趣的問題,如果這些小需求有價值,為什麼不讓原本團隊處理呢?如果沒有價值或低價值,為什麼要另組成團隊處理呢?

      針對修Bug,如不談敏捷,純從人性來說,有人幫忙擦屁股(別人修)跟自己擦屁股(自己修),在施工時對產品的品質要求那個會比較高呢?

      不過還是要回頭看看Context,也許這不是目前最需要解決的問題呢。說了落落長,希望有回答到提問 =)

      喜歡

      1. 謝謝你的快速回應
        【由另一個團隊專門處理小的需求是一個有趣的問題,如果這些小需求有價值,為什麼不讓原本團隊處理呢?如果沒有價值或低價值,為什麼要另組成團隊處理呢?】
        上面這段真的一針見血!

        喜歡

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s