現代敏捷
[本字幕由 Titansoft 鈦坦字幕組提供]
[翻譯成員 Charles、Ivy、Sam、Xinya、Yenwen]
很感謝大家來到這裡
我真的很感謝 Stanly 了不起的付出
讓這次的議程順利進行
嗨 Stanly
還有所有的籌辦者、義工、贊助商
很感謝你們
這是我第一次來到新加坡
我很喜歡這裡，謝謝大家
我還有很多想吃的美食
我吃了叻沙，美味極了
還有辣椒蟹
但還有很多我沒能吃到
所以一定要再來
一切都是為了美食，對吧
好的，為什麼我今天會在這裡
我是來跟大家分享一些
我自己很喜歡的東西
在敏捷被稱為敏捷之前
我猜你們是這樣稱呼的
我就參與其中了
我們在 90 年代中期
稱之為輕量級軟體開發方法
今天會講很多敏捷是怎樣開始的
往什麼方向發展
我們現在看它往哪個方向走
我大部分時間都住在
舊金山的矽谷灣區
和那邊的公司有很多合作
很多國際型的公司
所以也會跟你們分享
很多那邊的事情
另外我想說我今天帶了很多
Modern Agile 的貼紙
如果你們想要
可以在演講結束時找我拿
好，我們開始吧
上禮拜我才去了義大利
我常出差
這條奇妙的小街上掛滿了雨傘
讓我想起當初是怎樣
開始使用敏捷這個名詞
是將許多輕量級開發方法總稱
(umbrella term) 為敏捷開發
那些不同於瀑布式的
輕量級開發方法
敏捷做為一種總稱已經很久了
敏捷不專指某種大家都聽過的流程，對吧
相信你們應該都看過這張圖
有時候人們對敏捷的了解就長這樣
但其實敏捷是很多工作模式的總稱
那為什麼我今天
要來講 Modern Agile 呢？
是因為我在很多公司和組織裡
看到真的非常過時的敏捷模式
就像這台又舊又重的筆電
這讓我有點難過
因為現在我們有更簡潔時尚
性能更強大、更堅固耐用
更新型的流程
好比 MacBook
遠遠好過舊型的筆電
和那些舊的流程
我想讓大家去感受和了解現代的風格
這位是 Dee Hock，VISA 的創辦人
了不起的商業思想家
創造了「渾序」 (Chaordic) 這個字
說你必須拋棄舊觀念才能接受新觀念
有很多人對我說，Josh
你在敏捷的實踐上比較先進
你讓我們知道那些聰明的公司
如何用所謂現代的方式做事
但是，你真的得從輔助輪開始
對吧
很多小孩是靠輔助輪開始學騎腳踏車的
而這也是學騎腳踏車的必經之路，對吧
裝好輔助輪後，就會騎了
到了拿掉輔助輪的那天
就變得可怕起來
幾年前，我和我最小的女兒在公園
看到了這位爸爸教女兒學習如何騎腳踏車
這是當時的情況
如你所見，爸爸陪在她旁邊
腳踏車裝著輔助輪
爸爸有點擔心
女兒努力學著騎
我們再看一次
這次輔助輪拿掉了
爸爸手上有工具，把輔助輪拆掉了
然後在旁邊幫著她騎
可以看到，基本上進展不大
對了我電腦的聲音有播出來嗎
我等下要用到聲音
有誰知道這是什麼嗎?
這叫滑步車
滑步車
HDMI 應該會輸出聲音啊
好吧沒關係
滑步車上面沒有踏板
對吧，沒有踏板
而且離地面很近
所以兩歲小孩也可以學
怎樣騎著滑步車到處跑
這太神了
我住在加州東灣那邊
很多家庭都有滑步車
我就想
為何不讓我最小的女兒試試看
我們沒有去買滑步車
因為家裡已經有腳踏車了
我就是調低腳踏車的座椅
然後叫她不要踩踏板
把腳放在踏板外面
學習保持平衡
經過了 24 小時
24 小時之後
驚人的事情發生了
我現在就放影片給你們看
有聽到聲音嗎？
其實沒聲音也可以
但有聲音更好
好吧沒有，用看的就好
她只要往前滑就好
我對她說
不要踩踏板，試著找到平衡
平衡感更好了
剛才的那位老爸
沒什麼進展
然後她想試著踩踏板
大概對保持平衡膩了
她找到平衡感了
有點樣子了，但還不行
然後我們回家
隔天早上再來
接著事情就發生了
她會騎了
只花了 24 小時她就
學會了如何騎腳踏車
我對這個結果還蠻開心的
為什麼要讓你們看
我的小孩學騎腳踏車?
因為最關鍵的轉變在於
這太常見了
很多人以為只能用一種方式來學習
如果要學敏捷，你就要從 sprint
站立會議、點數估算開始
照這樣做就對了
靠這些敏捷輔助輪
但還有更新的方式
更簡單，更輕鬆，更快的方式
更安全的方式
我發現滑步車非常安全
因為孩子學會了騎腳踏車
最重要的技能
也就是平衡
而不只是在輔助輪的協助下踩踏板
所以我今天用騎腳踏車這個比喻
讓你去思考
比起以前的做法
現在我們有更新，更好
更簡單的方式來變得敏捷
把腳踏車當一種比喻
我覺得某些舊東西要被送到養老院了
嗯，我會說養老院不是個太糟的地方
食物還不錯
每個禮拜四晚上還有待辦清單賓果可玩
嗯，真的，有些舊的慣例和流程
是該去養老院了
SprintCare 安養中心
我還真的做了一個廣告
但在這裡播會引起太多爭議了
放投影片就好
來看看現代敏捷是什麼
第一件事
就是讓人們棒透了
就是那個小愛心
讓人們棒透了是我們的首要目標
不管是開發產品還是提供服務
無論我們想做什麼
產品或是服務
我們要讓人們棒透了
棒透了是個，嗯，很強的字眼
是很難達到的事
你可以讓人覺得不錯或很好
但要讓人超棒不是件容易的事
所以這就是目標
挑戰性最高的目標
接下來，視安全為先決條件
越深入敏捷，就越能發現
是安全感讓人的表現更傑出
打個比方，如果你一直都
在用自動化測試，而且夠可靠的話
那這些自動化測試會讓你
有勇氣做出改變
幫你做持續部署
成為你的安全網
讓你更上一層樓
所以在軟體開發和團隊關係上
都要視安全為先決條件
客戶的資料安全嗎？
客戶可以很安心的去用你的系統嗎？
還是隨時會當機？
安全感太至關重要了
無論是哪種面向
你要如何改善？
你要怎麼進步？
怎麼確保你沒把時間
浪費在無關緊要的事情上？
所以你得盡可能的快速實驗和學習
我們要把需求當作...
其實很多需求只是猜測而已
先把需求當作猜測，然後說
我們需要實驗、先立個假設
然後再去驗證這是不是
人們需要或想要的
先了解人們的需求後再來開發
快速實驗和學習
最後是持續交付價值
這是 DevOps 的理念
但也可以用在任何工作上
前幾年我在寫
《 Refactoring to Patterns》
每當我草稿寫到差不多時
就會丟到網路上
讓大家下載 PDF 讀
持續地輸出價值
持續地讓價值傳出去
持續交付價值
這四大原則構成現代敏捷
就是這麼簡單
現代敏捷的概念是
不要拘泥於特定的儀式，而是在乎成果
我看到有些人在拍照
我的投影片會放到 SlideShare 上
上面已經有之前演講用的投影片了
大家可以拿到品質比較好的版本
成果大於儀式
我們太依賴敏捷儀式了
一定要遵守敏捷儀式
當你去上課時你會學到儀式
但不一定學會了敏捷的本質
就像你靠著輔助輪學會踩踏板
但沒學會平衡這件事
也就是敏捷的本質
讓我們看看在軟體領域外的例子
這位是 Massimo Bottura
米其林級的名廚
還是最高榮譽的米其林三星主廚
他的餐廳 Osteria Francescana
位於北義大利的摩德納
這家伙超棒的
是藝術家
可以做出像這樣的菜
[偽裝]
這位是他的二廚
Taka
某個晚上
他們在準備甜點檸檬塔
有一桌坐了兩位很重要的客人
要上兩份檸檬塔
很不小心的
Taka 把其中一個檸檬塔掉到料理台上
一半在盤子裡
一半在台子上
就這樣碎掉了
...噢喔...
Taka 身為專業大廚
又在米其林三星級餐廳工作
他快崩潰了，超氣自己
這時候
令人難以置信的事情發生了
接著，Massimo 走了過來...
Massimo 真是位了不起的藝術家，他說
我直接播影片給你們看
今天沒辦法播聲音
但用看的也可以知道發生什麼事
這是 Netflix 的影集
Massimo 上前
看著眼前碎掉的檸檬塔
然後說：Taka
這太美了！
我們...
我們可以創一道新菜！
當下他就跟 Taka 一起
創造了一道新菜
也成為
餐廳的招牌菜
叫做
「哎呀，我弄掉了檸檬塔」
製作過程像這樣
用灑的
因為這道甜點太受歡迎了
他們甚至用看起來像破掉的盤子裝
成品長這樣
好，讓我們用現代敏捷
的角度來分析這個例子
假設你在廚房
然後
檸檬塔就是摔壞了
你總得做些事情，試驗看看
Massimo 認為我們要
快速實驗快速學習
看這道新菜色會不會一炮而紅
他們當下就做了實驗
他們持續地交付價值
不是停下手上工作，叫大家等等
我們重新做一個檸檬塔
這樣會花太多時間了
肯定會激怒熟客
Massimo 靈機一動
想到要如何持續交付價值
幫 Massimo 工作感覺怎樣？
如果你是 Taka
摔壞了檸檬塔
你一定嚇壞了
這時候老闆來了
說，等等！
我看到美妙之處了
碎掉的檸檬塔
你覺得超棒的
特別是知道自己也幫忙創造出
餐廳最有代表性的菜色
當然是日後才出名的
但依舊了不起
吃到檸檬塔的人也很快樂
因為很美味
所以你讓人們棒透了
最後，這是個能安全工作的地方
在 Massimo 的廚房裡
犯錯是安全的
你不會被開除
不用去上教育課程
Massimo 也不會在檸檬塔的
工作區裝上保護墊
在他的餐廳
你可以不用擔心會犯錯
用現代敏捷的角度
來分析大概就是這樣
好讓我介紹一下 Industrial Logic
的創辦人和總裁
我們協助世界各地的公司
在軟體開發上做的更好
簡介一下我們的歷史
我在 80 年代後期就加入軟體業了
但大概快到 2000 年時才參與敏捷運動的發展
那時還沒有敏捷這個名字
那時候我們使用極限程式開發
(Extreme Programming)
1999 年的時候我參與了
一些早期的專案
在舊金山的新創公司
之後我開始做敏捷教練
服務於世界各地
之後花了一些時間寫書
書名為《Refactoring to Patterns》
還有投入在 IXP上
也就是 Industrial XP 的縮寫
主要是企業等級的敏捷導入
因此我們跟很多想要導入敏捷
的大企業合作
然後我們做線上學習軟體
給想自學敏捷開發技巧的人
像是測試驅動開發
如何寫使用者故事
到了 2012 至 13 年之間
我愛上了安全這個觀念
安全帶我們邁向卓越
我稱之為「Anzeneering」
Anzen 是日文「安全」的意思
安全也成為現代敏捷
的核心原則之一
讓我們很快的回到 2008 年
那年在 Agile2008 大會上
我講的題目是
我們如何改變工作流程
我們長年以來都是跑 sprint
或用我們的話來說走迭代
到 2008 年都是這樣做
但在 2008 那一年
David Anderson 的看板使用方式啟發了我們
我們發現
他打破了 sprint 的固定節奏
變成跟著工作流前進
我們的主要工作是
為客戶開發線上學習的軟體
但時不時的會有些小任務跑進來
那種小小的功能
小到一天就可以弄好了
所以我們想趕快搞定趕快發佈出去
檢討一下，然後重複
所以我們改用這種彈性的時間盒
我取名為「微發佈」
(Micro-releases)
也不見得都這麼微小
有時候也要一天兩天的時間
但在 08 年那個時候
我們稱為「微發佈」
我們不做估算了
不再使用固定時間盒
也就是 sprint
我們簡化很多事情
把注意力放在找到一種節奏
也就是找到重要的事情
然後交付出去
找出來，完成，然後交付
我會提這個是因為
當我跑了全世界，跟很多
進行敏捷開發的人談過話後
我往往會發現相同的模式
相同的問題
以下是其中之一
你在 sprint 開始前
做了一大堆估計
你很樂觀
覺得事情一定會很順利
但隨著一天一天過去
你開始不確定了
你覺得應該做得完吧
可能還過得去
但，很有可能，你知道的
會有些未知的問題
Sprint 過了一半
已經開始出現一些滿糟的問題了
嗯...沒那麼簡單了
壓力開始來了
到了最後四分之一的階段
情況真的不太妙
老是有問題跑出來
讓你無法履行你對這個 sprint 許下的承諾
你可能開始打算抄些捷徑了
有些測試就不寫了吧
本來打算要重構的地方就跳過吧
到了最後...我的老天爺
我們一定要做完
不然很沒面子
因為我們想要做完
我們已經承諾了
但產出的程式碼有點鳥
我們不斷地發現這些情況
你可以解釋成團隊的錯
因為他們不懂如何跑好 sprint
或是 sprint 本身的機制
容易導致這種問題
因為從不間斷地
每隔兩週或一週就有一個交期
看你是用哪種節奏
不管怎樣這問題就是一直發生
一直發生
老實說，你懂得
你做了什麼？
一開始你就高估了
所以事情沒照你的想法走
我們發現
事情不可能順利進行的
因為團隊並沒有真的理解敏捷的本質
也就是平衡
為了達到傑出所需要的平衡
也就是把工作做完，交付品質高
並以規律的節奏持續下去
而這個節奏的長度不非得是固定的
而比較像是看板著重的
流動的過程
如果這個小項目夠重要
那就做完它，然後往下走
這樣對我們輔導的客戶來說
更容易採用
我們還看到這種狀況
某個使用者故事在這個 sprint 開工了
沒做完
延續到下個 sprint，沒做完
延續到下個 sprint，沒做完
沒完沒了
這太常發生了
你其實在跑瀑布開發
是吧？
這背後的原因是
團隊沒有真的掌握到垂直切割的概念
垂直切割
足以運行的骨架
這是學習敏捷時最關鍵的地方
兩位我很尊敬的人
簽署了 2001 年的敏捷宣言
後來卻說
天呀！點數估算
我真後悔我發明了點數估算
還有產出速率快要害死敏捷了
緊盯著產出速率不放！
我最受歡迎的部落客文章是
〈停止使用點數估算〉
在所有我寫過的東西裡
這篇最多人讀
嗯...我打了一個比方說...
sprints、站立會議、點數估算
就像是敏捷世界裡的漢堡、薯條和可樂
請享用您的敏捷快樂餐！
你領到敏捷快樂餐後
基本上就開始跑起了sprint
開始算點數和產出速率
這只是通往...不是在...
這篇文章很長，解釋了很多
我們與其他團隊共同遇到的問題
甚至是我們自己訓練的團隊
和那些因為點數估計和產出效率
所導致的破事
Jeff Gothelf
《Lean UX》的作者
說：別再拘泥於可交付什麼了！
一直計較交付速率
我們在這次 sprint 裡
可以完成多少東西！
讓我們交付吧！交付吧！
交付吧！
他說，也許交付不是目標
也許真正的目標...是
產出的結果
終端用戶的體驗，是吧？
而不是完成了多少 story
不是燃盡圖看起來沒問題
而是你幫使用者做了什麼
你有讓使用者超棒嗎？
這才是重點
別再拘泥於...
忙著算數字了
用敏捷的計畫工具來算自己的工作
卻忽略了使用者需要什麼
長久以來
我們一直誤解完成的定義
對很多團隊來說
PO 接受就是完成了
就算 PO 接受了
那終端用戶有嗎？
PO 坐在辦公室裡
猜想著這東西會有多棒多棒
但是終端用戶在決定完成了沒
是使用者在決定要用還是不要用
接收還是退回
所以接不接受是看終端用戶
不是 PO
如果完成的定義對你而言
只是 PO 接受與否
這並不是真正的完成
敏捷的定義不是這樣的
不幸的是
很多人以為他們敏捷化了
因為他們有在跑 sprint
開站立會議和使用點數估算
很抱歉，你們沒有
你們只是在執行敏捷儀式
好的，現代敏捷
就在我開始構思現代敏捷時
這隻小狗狗來到了我家
旁邊是我家比較大的狗
麥克斯
跟這小朋友打招呼
我們幫他取了很多名字
最後叫他馬力
馬力慢慢地長大
我也做了些開放會議和現代敏捷的討論會
馬力又更大了一點
現代敏捷的定義也開始成形
我畫過華麗的文氏圖
寫了部落格
但還不是很成熟
馬力越來越大隻
我帶他們兩兄弟一起去上班
現代敏捷也更清楚了
就是這四個原則
現代敏捷是怎樣來的？
現代敏捷不只有我的想法而已
我觀察業界和客戶
執行敏捷專案
和受到很多大師的啟發
像是 Kathy Sierra
《Badass: Making Users Awesome》的作者
還有 Zappo 的 Tony Hsieh
Jurgen Appelo
寫了《Managing for Happiness》
其他像是持續部署的書
講快速實驗學習的書
《Lean Startup》
有人看過《Lean Startup》嗎？
很重要的書
還有《The Startup Owner's Manual》
Steve Blank 創造了
「離開建築物」這個說法
意思是去跟你的客戶談話
了解他們，不要用猜的
還有大量關於安全感的書
有安全感才能邁向卓越
敏捷軟體開發宣言
這是很重要的文件
就歷史意義上來說
說要發掘更優良的軟體開發方法
藉著親自並協助他人進行軟體開發
宣言問世後發生了這些事
首先
其他專業領域也開始採用敏捷
他們太喜歡敏捷了
也要用敏捷開發！
我們有客戶說
我們硬體軟體都做
我們也想用敏捷開發來做硬體
突然之間
已不只是發掘更優良的軟體開發方法
軟體以外的領域也適用
除此之外
我們也發現敏捷能夠現代化的地方
變成是說，我們是在
發掘更優良方法，以取得了不起的成果
不專指軟體，更中立
而且這也是我們追求的
我們想取得更多了不起的成果
我們要去發掘
挖掘是一種主動的過程
我們要發掘更好的方法
不斷發掘下去，也許
過了一年我們會有更好的方法
好我們現在再快速看一遍
讓人們棒透了
一個小故事
第二次世界大戰後，日本衰退了
火車系統太慢
他們必須要重新站起來
再次成為一個有競爭力的國家
他們要有更快的火車
來運送人和原物料
1955 年，日本說
我們要有更快的火車
他們跟工程師說
欸，要真的跑很快喔
工程師說：要多快？
飛快！
好吧，時速到...110 公里可以嗎？
不夠快
什麼？到底要多快？
嗯，時速 190 公里可以嗎？
這簡直難到登天
時速 190 公里！
軌道有彎度的話
會讓火車出軌的
離心力會把火車拋出去
這個計畫的負責人就問
為什麼會有彎道？
把它弄直！
我不管會發生什麼事
我們就是要建出高速火車
1964 年
東海道新幹線以時速 190 公里
的高速駛離了東京
Jack Welch 在 1990 年來到日本
他聽到這個故事
說我的老天
在 GE 奇異這麼大的公司
涉及各式各樣的產業
我們居然沒有這種
子彈列車似的思維
我們有明確的季度目標
但是我們絕對沒有子彈列車思維
來完成你根本不知道
如何做到的事情
不知道如何完成
遠遠超乎你目前的能力
如果你最後真的做到了
你也是在實驗過程中探索出作法的
他把子彈列車思維帶回奇異
跟每個部門說
從現在開始，你們都要具備這種思維
告訴我你的子彈列車要開往哪裡
另外一個跟棒透了有關的故事
站在右邊的是我女兒 Eva
學騎腳踏車那個
三月的時候
她問我能不能在生日派對上打水球戰
你們做過水球嗎?
不知道新加坡玩不玩這個
要先買氣球，然後裝水，再綁起來
真的是苦差事一件
我一想到就怕
因為之前讓她們打水球戰的時候
你至少得幫她們準備 100 個
以上的水球，不然不夠好玩
想到就怕
但我找到這個東西
是這樣使用的
一盒裡面有好幾條
所以最後我的戰果是
2 分鐘內裝好超過 100 個水球
其實你可以發現
這個工具是有瑕疵的
除了會漏水之外
你也不知道何時該關水
有個水球就爆掉了
但即使你知道瑕疵這麼多
這東西依舊太棒了
除了讓我這個工具人老爸
感覺棒透了
小朋友們也玩得很盡興
互相砸來砸去
連我也不放過
Cathy Sierra 說
要讓使用者棒透了
這才是真正的目標
而不是讓公司很棒
不是讓團隊很棒
也不是做一個很棒的產品
而是讓使用者用起來感覺超棒
能夠很棒地達成目標
這才是我們的目的
如果你做到這點
其他事情都會自己解決掉的
讓人們...使用者棒透了
然後他們就會告訴朋友
哇賽，這件事情我做得超好
像是我很擅長報稅喔
因為我都用 TurboTax
難不倒我的
你朋友聽到就會記下來
也許就會買來用了
Kathy Sierra 告訴我們
重心要放在讓使用者棒透了
Brad Smith 繼任 Scott Cook
成為 Intuit 的總裁
Brad Smith 說
原文很長我摘譯如下
大意是讓他想雇用的工程師
是那種
除了會寫程式之外，也熱衷於
觀察客戶，想去接觸客戶
確保客戶的使用體驗良好
好到他們會推薦這個產品
給朋友和家人
也就是「淨推薦分數」
(Net Promoter Score)
Intuit 有一項「喜愛指標」
用來測量他們為客戶帶來多少價值
我們真的有幫到客戶嗎？
客戶是主動地在使用產品嗎？
如果客戶不用
一定哪裡有問題
然後客戶就會去跟別人說
也就是打了淨推薦分數
「喜愛指標」
我的公司是做線上學習軟體的
但我們學到
不能只專注在使用者身上
如果只有使用者開心到了
是不是代表我們忽略了其他人？
會有人先來跟我們做評估軟體
再決定要不要買
我們還要面對買家
他們買回去卻沒人用，下場會很慘
會被說買回來的軟體放到生灰塵
採購眼光很差
所以我們要讓整個上下游
的人都覺得棒透了
所以，不是只讓使用者棒透了
是讓所有人都棒透了
視安全為先決條件
也就是我稍早提到的
Anzeneering
右邊是舊金山的金門大橋
施工時當局格外注重工安問題
那時為工程安全所做的
創舉之一是提供防毒面罩
在金門大橋之前的工程
所有的工人都直接吸入
清洗鋼材時產生的有害物質
他們為了金門大橋的工人
製作了專用的面罩
他們還在橋面下掛起安全網
所以當工人在築橋面時
他們不用怕會掉下去
其實曾有 19 個人
不小心跌入安全網裡
他們還組了一個社團叫「鬼門關前走一回」
(Halfway to Hell Club)
沒有安全網接住的話
這些人就會摔死了
安全網的存在至關重要
投影片左邊是我們為線上學習軟體
所寫的自動測試
我們為我們的軟體寫了
超過 2000 個
可靠性非常高的自動測試
自動運行，什麼都幫我們測
從最低階開始，高階
再到網站前端
甚至部署也測
看跑起來有無異常
我們在整個流程中
做了很多安全性上的努力
因為，在恐懼的文化下
在恐懼的文化下
再怎樣厲害的做法都幫不了你
你大可去學各式各樣的流程
但只要有恐懼的文化，就一定會遇到問題
一定要免除恐懼
Slack 讓我喜歡的一點在於
他們會寫 email 給我
說我們要退你錢
因為本月你購買的方案沒有用盡
他們真的退錢給我耶
你用過的軟體商有哪家像他們這樣？
他們只想從你身上賺到最多的錢
越多人訂閱越好
才不管訂閱的人到底有沒有在用
從那些人身上大撈一筆吧
Slack 不這樣做
他們會幫我留意
Slack 說：你只要付你有用的就好
我超愛這點，讓我覺得很有保障
Google 進行過一項
「亞里斯多德計畫」
今年公佈了研究結果
用了 2 年的時間
研究了 200 個團隊
想要找到在 Google 裡
表現較好的團隊的秘密是麼
他們一開始覺得應該是團隊裡
人的組合對了
或者表現好的團隊...
是那種下班後還會
一起出去玩的團隊
但他們的假設都錯了
有些表現傑出的團隊
從來沒在下班後一起出去玩
有些團隊的人才組合很不可思議
跟他們預期的都不一樣
最後他們發現的則是
心理上的安全感
心理上的安全感
讓團隊成員可以在其他人面前犯錯
可以以尊重的態度
各持己見，反對彼此
心理上的安全感是 Google
黃金團隊的第一要素
所以為了創造心理上的安全感
Charles Duhigg 也有在書裡寫到
(譯注：《Smarter Faster Better: The Secrets of Productivity in Life and Business》
根據 Charles Duhigg
Google 重新設計了要如何開會
Google 為了開會做了以下努力：
鼓勵每個人都發言與貢獻
如果你想創造心理上的安全感
鼓勵每個人都貢獻想法
傾聽彼此
認真地聽別人在說什麼
不要玩手機
為了證明你有在聽
重複別人的話，或給些評論
「我聽到 Roger 剛剛說
這樣這樣，對嗎？」
避免控制或打斷彼此
很基本的道理
但永遠都在發生
團隊裡面主導權比較強的人
永遠都是他在發言
或是一直打斷別人
別讓這種情況發生
最後，多點關心，好奇心
別動不動就批評他人
如果有人說了話讓你很在意
用關心和好奇的態度去回應
去了解，而不是開始生氣
以上這些就能幫人在會議中
得到心理上的安全感
但不一定全盤通用
我們有個底特律的團隊
最喜歡打斷彼此
這對他們來說再正常不過了
他們覺得這樣很好啊
那在這種情況下就沒問題
但一般來說
上述的方法都適用
從這些地方來開始創造安全感
當然還有很多可以做的
下次開會前
不妨想想這些原則
Google 的做法是列出
參加會議者的名單
有人發言時就打個勾
這樣很容易就能看出
是否每個人都有發到言
我曾去過一個研討會
在場只有我是軟體人
是講如何創造安全的文化的研討會
大家都拿著這張 SWA
「停止工作權」卡
就像是豐田生產方式
裡的「安燈」(Andon)
當你亮出這張卡
就可以停止工作
這些都是核電或電力產業的人
各種高度危險的產業
甚至有致命的可能
但是我覺得軟體業也是一樣危險
我們也做很多瘋狂的事情
也不太安全
所以我也做了這個卡片
發給我的工作夥伴
然後再給我們的客戶
逐漸地透過這些卡片
我們在危險時會停止工作
我今天也有帶
待會可以來找我拿
我們也立即採用了安全會議
(Tailboarding)
我們的看板上有一區
是讓大家在開始做東西前
聚在一起
很快的找出地雷可能在哪
比如說要做的東西
在 IE 和 Chrome 上操作起來要不一樣
那大家來討論一下
看要如何應付地雷
安全會議讓我們有機會...
做基本的安全分析
決定要怎樣處理地雷
但不要忘了
你的保護機制也可能害到你
十五世紀時
法國做出了最重的盔甲
重到如果法國士兵落馬後
他根本站不起來
所以英國很容易就擊敗法國了
靠著他們的輕量盔甲
你的保護機制
不管是差勁的單元測試
或是任何你用來保護自己的作為
可能也會害到你
所以要注意你使用的安全保護措施
快速實驗學習
Paul MacCready
二十世紀最偉大的工程師之一
他贏了人力飛機挑戰賽
在他那個年代
人力飛機是很重大的挑戰賽
獎金也很高
但十年以來
沒有人可以贏得這個挑戰
沒人成功地造出人力飛機
直到 Paul MacCready
出現了，說
問題就在我們不知道問題是什麼
我們甚至不知道問題是什麼
我們需要創造能快速實驗
快速學習的方法
因為其他挑戰者的方式是
先製造出差不多能以人力
飛行的飛機
然後以失敗收場，再回到製圖板前
花上三到五個月做新的原型機
再來試飛
回饋太慢了
Paul MacCready 說
我們要每幾個小時就收到回饋
不是好幾個月
他用各種輕量、簡單
的材料製造飛機
驗證他的假設後，快速的學習
然後在很短的時間內
我不確定是幾個月
造出神鷹號 (Gossamer Condor)
贏得挑戰賽
真是二十世紀時了不起的成績
全都是靠快速實驗和學習
當你打算開發什麼時
很多時候你會想...
這又是另一個問題
代辦清單上有個項目
常常你就是領了項目就開工了
不討論，直接做
這很問題嚴重
因為可能在此就產生了浪費
IMVU
精實創業的出生地
IMVU 是...
3D 聊天室
能在裡面跟其他人講話
IMVU 早期的狀況是
雖然熱衷玩家持續地在成長
但同時也抱怨說
我想要移動我的角色
像玩模擬市民那樣
在模擬市民的 3D 場景裡
角色活動的樣子很炫
IMVU 研究過後，說
既然大家都想要移動這個功能
我們開發起來可能要花上...
至少兩個月來寫程式
因為這功能很難
牽扯到物理學有的沒的
但我們真的沒有那種時間
有其他辦法嗎？
那不然
不然滑鼠點到哪角色就飛到哪吧
瞬間移動
他們不知道玩家會不會喜歡
但就試驗看看吧
因為這很快就可以做出來
兩天就行
基本上他們就這樣做了
你可以到看成果就像這樣
在 IMVU 裡
點一下椅子就可以坐上去
點另一張椅子就換過去
非常陽春
就這樣上線了
看玩家反應如何
猜猜發生什麼事
玩家愛死了
他們會定期調查玩家最喜歡
IMVU 的五個點是什麼
結果玩家說
我們超喜歡瞬間移動的
甚至有玩家說
IMVU 的瞬間移動
強過模擬市民
因為點了就飛過去了
不用導航
只花了兩天
不是很複雜很難的功能
快速地在客戶身上實驗，從中學習
不一定是在所有的客戶上實驗
可以是小規模的
這是你可以快速學習的方式
持續交付價值
Timothy Fitz 在 2007 年的這個演講
令我印象非常深刻
題目為：在一天之內做五十次不可能的事
Timothy 在 IMVU 工作
當時用戶規模已達百萬等級
他們一天內能成功部署上線五十次
他們有各種還原機制
還有「叢集免疫系統」
(Cluster Immune System)
幫他們分析硬體有沒有出問題
是很複雜的持續部署環境
讓我也想跟著做持續部署
我們不久後也學會怎樣做
發現這威力太驚人了
大大地減輕我們的壓力
現在我們可以很輕鬆地
做到每日多次部署
雖然我們持續部署跟 IMVU
比起來單純的多
但運作起來很也很可靠
部署不會失敗
持續部署大大地改變了我們
在 09 還 10 年的時候
來看雅虎
雅虎的軟體開發、整合和發佈
都有很嚴重的問題
糟到不行
我刪掉了一個故事
因為時間不夠
簡單地說就是雅虎
一定要做出改變了
於是雅虎做了這些事情
雅虎不會再有 QA 了
不會再有品質保證可做
如果你想做品質保證
去別的地方吧
或者
你接受訓練，成為品質工程師
我的公司 Industrial Logic
去幫雅虎上了一些課
教他們測試驅動開發
重構等等的技能
QA 人成為了品質工程師
這是第一步
第二步，當雅虎建好很多測試後
他們告訴我，有了自動測試
好像就不需要跑 sprint 了
因為他們其實在跑的是...
Scrumerfall！
分析、設計、寫程式
測試都在同個 sprint 裡
當測試都做到位時
跑 sprint 好像就不是必須了
變得更像持續流
但還是需要手動建置
最終還是要從手動建置
轉成 CI 和 CD 持續部署
在雅虎所有的產品都這樣做
只要是還活著的產品
也就是至少一季會改動一次
都做了持續部署
聽起來很美好對吧
雅虎裡有人抗議說
我死都不會做持續部署的
這太荒唐了
但他們被逼著去做了
過了一陣子，他們卻說
天呀這太棒了
我不可能走回頭路了
有時候，你不能讓團隊
自己決定要不要做持續部署
雅虎要求大家一定得這樣做
這大大改造了雅虎
好的，很快的來看些案例研究
我還有多少時間？
哈哈哈不妙
時間到了是嗎？
我就不講案例了
投影片都已經放上 SlideShare 了
你只要在 SlideShare 上
搜尋 Modern Agile
就可以找到完整投影片
裡面有我想講的案例分析
但是時間到了。謝謝大家