David Ko的學習之旅

在傳統瀑布式開發中, 最被人家詬病的地方, 就是反應太慢. 因為他要經過點子發想, 需求分析, 架構設計, 程式撰寫, 測試, 才能交付到客戶手頭上, 因此整個過程的回饋要拖得很久.

 

那要怎麼處理這個問題呢? 那我們來看看 agile 用哪些招式, 來減輕這個狀況.

我們都知道, 在 Scrum 中是由 Product Owner 來決定 product backlog 的內容. 可是大家知道backlog 中的內容, 要如何來決定什麼事情要先處理呢?

大部分的人會回答, Product owner 會根據商業價值, 來安排要做的事情的順序. 

很多時候我們會發現, 我們做了很多東西, 可是產品不見得賣得很好, 並且也常常延遲交付, 為什麼會這樣呢?

可能是我們沒有價值的事情做太多, 也就是我們做了很多 output, 但是我們不是在產生價值(outcome) 給客戶. 

最近聽到一個名詞 Cargo Cult, 查了一下 wiki 他的典故如下:

第二次世界大戰太平洋戰爭時, 美軍於塔納島建立一臨時基地. 當時島上的土著看見美軍於「大鐵鳥」內出來, 覺得很驚訝. 此外他們也看到，飛機還運送穿著美軍軍服的人, 以及許多物資, 更覺得十分神奇。加上美軍也提供部份物資給土著, 而這些物資對土著來說十分有用, 因此使得這些土著將美軍當作神來膜拜.

第二次世界大戰完結後, 美軍離開這個小島, 只留下一些美軍軍服及一些貨物. 這些土著便認為這些貨物具有神奇力量, 又相信神(美軍)他日會回來, 並帶來更多貨物, 使他們展開一個幸福新時代. 當然啦, 美軍再也沒有回來. 

最近上課的時候老師提到, 當你一直逼迫開發人員, 要儘快交付某些功能, 開發人員將會開始使用神奇的工具箱, 來應付這樣的狀況.

 

那神奇的工具箱是什麼呢? 讓我們一一道來:

最近幾次 review 會議中的 demo, 讓我印象十分深刻, 不吐不快, 特別列了幾點和大家分享:

 

1. 使用實際資料
工程師們為了讓大家看到真實的一面, 很有勇氣的現場開始產生資料傳送給要 demo 的系統, 不是事先預錄 demo 流程. 我想有 demo 經驗的人都知道, 實際傳送資料是很驚險的事情, 很多原因會導致失敗. 可是我很喜歡大家勇於接受挑戰, 願意讓大家知道我們是玩真的, 不是來騙大家說一切都沒事.

敏捷其實是文化的轉變, 不是只有照著流程一步一步做而已. 因此除了了解 scrum, kanban 或 XP 是什麼東西外, 你的工作環境也要到位. 因此今天就讓我們來看看, agile 工作環境應該要怎樣:

1. 開放空間
通常傳統台灣公司, 隔間都是為的滿高的; 或者是經理的房間, 都和其他員工隔得滿開的. 對敏捷團隊來說, 密集的溝通, 是促進效率的重要關鍵. 如果辦公室可以沒有隔間, 或是隔間高度不大, 這樣會比較適合討論; 

在推廣 Scrum 時, 很重要的事情, 是要組成自組織的團隊. 可是你要怎麼知道, 我們已經是自組織的團隊呢? 讓我們來看看一些跡象:

1. 願意改變
通常這團隊願意接受別人的建議, 願意去嘗試一些新的事情, 或是不同的做法. 例如在測試自動化, 我看過一個團隊, 他之前因為時間的壓力, 並沒有安排這樣的工作. 可是在新的一個版本中, 團隊成員願意從小規模開始嘗試, 結果最後成績是讓人家滿意的.

今天想來談談如何在循環中, 需要先進行設計嗎? 什麼? agile 不是不用設計, 直接就來開工了, 不是嗎?

這是很多人對 agile 的誤解, 認為 agile 就是不用設計. 因此很多老人家, 只要一聽到要採用敏捷開發, 就認為這是不可行的, 或者說這是妖言惑眾.

此外, 不只老人家擔心, 也很多敏捷擁護者, 也認為 design up front 不是 agile, 敏捷就是要先開始寫程式, 一邊寫一邊修改, 也就是 TDD + CI + refactoring 一起上.

對於如何開始實施 agile, 昨天談了 5 點, 今天繼續接著聊下半部
http://kojenchieh.pixnet.net/blog/post/358677134

有些朋友打算開始實施敏捷, 問我說怎樣做會比較好. 老實說, 每家公司背景不同, 我也不是待過各種環境, 沒有所謂的銀製子彈, 可以適用所有地方的. 因此只能提供一堆祕籍(誤) 淺薄的建議:

 

1. 知道為何戰
首先要知道, 你們為什麼要實施 agile, 是因為遭遇到了什麼問題, 然後你打算用什麼方法解決, 最後想達到什麼目標. 需知道只有問題是不變的, 解決方法會因時間或是環境, 有所變化或演進. 千萬不要為了 agile 而 agile.

Feature Driven Development (FDD) 也是一種敏捷開發方法, 它最先出現於 Java Modeling in Color with UML這本書中.  但是聽過的人比較少, 讓我們來簡單的介紹一下.

FDD 是一個 model driven, short iteration 的流程. 一開始要建立一個整體的 model, 然後再利用一連串兩周的 "design by feature, build by feature” 的 iteration, 來建立出整個系統.

常常有人會詢問, 公司再導入敏捷開發, 是否要找敏捷顧問? 

這個問題答案可能很多種, 但是我只能根據自己的經驗, 講我自己經歷過的事情. 僅供參考, 沒所謂正不正確.

在早期時, 當大家都不會的狀況下, 找敏捷顧問是比較快, 比較有效率的方法. 因為他可能先觀念教學. 更重要的是,  他可以分享一些經驗給你, 告訴你這些敏捷方法(XP, Scrum, Kanban … )的優缺點, 適用時機, 導入時間大約要多久, 以及可能遭遇的問題.

最近有人在問我, 如何在企業中推行 scrum. 然後再加上 FB 上的一些討論, 讓我想寫一小段話發發瘋

 

個人覺得在企業中要成功導入新的做法, 是件不容易的事情, 尤其在大型企業, 銀行或是公家單位.

視覺化管理基本精神, 是將你的工作狀態呈現出來, 讓大家可以看到全貌, 進而採取適當的行動.

 

因此我們會希望員工儘量把工作貼到 task board 上面. 一開始, 大家通常會貼的是跟專案有關的工作.  

最近思考 agile 到底是什麼, 到底有沒有效? 想著想著剛好再看這篇文章: 

An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture, Michael Sahota

發現到原來我們最大的問題, 是我們一直在想做 “agile”, 可是並不是讓我們的想法變成很”agile”. Agile 本身是種思維的轉換, 希望在外界狀況一直改變下, 我們能有應變 change 的能力. 

最近參加了一場很特別的 review demo meeting. 專案經理做了一些事情, 讓我覺得眼睛為之一亮.

1. 每個人都有機會上去 demo
以前可能不 demo, 或者只是 demo 一兩個東西. 可是這次經理讓大多數的人, 都上去展示他所做的東西, 並且也保留了適時的時間, 來和外界的關係人討論, 讓大家對產出有較深入的認識.

2. 公開感謝重要貢獻的成員

最近在網路上看到一篇文章, 談到 scrum 團隊的工作的行程和分配, 感觸很多, 深深覺得要執行好 scrum, 組織文化很重要. 所以寫了這篇廢文 XDD

 

根據敏捷宣言的定義, agile 是一堆觀念和原則, 只要是應用這些東西的開發方法, 我們都稱為是 agile method. 所以你才會看到 Scrum, FDD, Kanabn, eXtreme Programming 都叫做敏捷開發方法. 所以嚴格來說,  agile 只是做事情的想法, 而非是開發流程.

此外,  Version One 公司對 agile 的研究調查顯示(http://www.versionone.com/state-of-agile-survey-results/), 公司內推廣 agile, 最大的障礙是組織文化. 那什麼是組織文化呢? 也就是這一群人在這邊做事的理念.  例如, 如果組織文化是 command and control, 自然就是要等老闆說了什麼, 他們才會去做什麼. 要主動提出一些做法, 可能會自討苦吃, 並且還可能會被警告.

當 iteration 結束時,  scrum 通常會進行 demo, 來展示行的成果. 這裡有些小技巧, 來幫助你進行得更有效率:

  
1. 先解釋 scenario 再 demo
很多時候開發人員會一下就 demo下去, 與會者在還搞不清楚的狀況下, 可能就已經結束了. 建議先講解要 demo 的流程, 讓大家有個大方向的了解, 之後再 demo 系統. 

前面談了不少什麼是實例化需求, 以及為什麼要實例化需求, 可是還沒有談要怎麼做. 以下是簡單的實施步驟:

1. 根據商業目標來了解系統範圍
每次做一個產品, 應該都有他的理念, 或者是要解決的問題主軸, 這些東西便會匡住產品的範圍. 像是 MVP(Minimum Viable Product) 等概念便會出現, 好讓你有聚焦, 而不是想包山包海. 這裡我們常用的工具會是像 user story mapping, 整理出要做的功能, 並且也描述哪個 milestone 要做哪些的事情.

範例:  線上購物系統一部分的 user story mapping