David Ko的學習之旅

在 Scrum 中, 很多人會用燃燒圖(burndown chart)來算還剩多少工作要做, 這是一個不錯的方法, 以視覺化的方法來顯示工作進度, 讓大家很容易了解目前狀況, 使得進度不再只是經理神秘檔案中的資訊. 

可是很多人也會提到, 繪製燃燒圖需要花很多時間, 因為你一張張計算, 尤其當張數一多時, 這是一件相當不容易的事情. 

最近有些人在問, 在推行 agile, scrum 或是 XP時, 到底要不要用電子看板, 像是 Trello, Jira, 或是者Visual Studio. 因為有些研討會在大肆推廣工具的使用, 導致被問的頻率變高. 

 

之前我寫過文章來回答過, 今天我再補上幾點, 希望能讓大家思考一下
http://kojenchieh.pixnet.net/blog/post/340762163

在談 user story mapping 時, 有人問我什麼是 walking skeleton?

我說這不是行屍走肉嗎? 哈哈, 我是開玩笑的, 它不是骷髏, 它是指瘦如柴骨.

在執行 Scrum 時, 大家都知道需要召開 sprint planning meeting, 去規劃這次的 sprint 要做什麼. 通常進行的重點, 就是在了解要做的東西是什麼, 以及要拆解出工作的細項.

 

我發現很多團隊在這個會議中, 都是由專案經理介紹這個 sprint 要做哪些功能. 在一一介紹完後, 便請大家各自自己去估做事的項目和時間. 因此會議到這邊就結束了, 並沒有再進一步的討論. 

話說程式有錯時, 你會怎樣找出錯誤方法在哪裡呢? 有些人會一行一行去單步執行, 有些人會一直反覆閱讀程式碼, 有些人會一直在程式中加入 log 來查看, 各種方法真的是應有盡有. 

最近又聽到一種很好玩的做法, 叫做黃鴨除蟲法(Rubber Duck Debugging), 或是稱為橡皮鴨調試法. 就是在程序的調試、糾錯或測試過程中，耐心地向小黃鴨解釋每一行程序的作用，以此來激發靈感。

Agile Meetup  首次在假日有聚會 (2014/8/31), 這次除了小弟上去代打外, 最重要的是要聽聽日本朋友的分享. 這次日本朋友(Someda Takashi, 染田貴志)分享的題目是”如何在反覆試用中開發更好的產品”. 主要的重點是如何早點確定產品是有用的. 以下是這次演講的摘要:

 

講者一開始介紹的他們公司的資訊, 以及當初為什麼會有這些改善. NuLab 是一家以敏捷方法來進行軟體開發的公司, 致力提供能改善及培養協同工作的軟體工具, 目前擁有『貝格樂專案管理工具』和『Cacoo線上繪圖工具』Typetalk 等產品. 這家公司非常相信, 在溝通順暢與愉快的工作環境中才能創造成功.
官網: https://cacoo.com/lang/zh_tw/

在學習 Scrum 時, 最快能讓學員了解的方式, 就是讓大家在遊戲中學習, 不但有趣, 並且還能讓你印象深刻. 其中一個有趣的遊戲就是 ball game, 讓我們一起來看看這個遊戲要怎麼進行.

      

規則
1. 球必須要在空中有停留的時間.

這次讓我們來看看 Lean 陣營的人, 在被訪問的時間, 如何說嘴 agile 的不是 (誤)

Mary/Tom 認為 agile 和 lean 

差別

精實基本上源自於製造業的方法, 是由豐田的 Taiichi Ohno 在 1995 年所創造出來的. 那時候日本經過二次世界大戰, 整個產業景氣不是很好, 他為了克服資金短缺和資源不足的問題, 提出了降低成本, 消除不必要的浪費的做法, 這就是精實做法的起源. 西方世界把這樣的做法稱之為精實製造. 

敏捷軟體開發(Agile Software Development) 是一堆軟體開發方法的集合名詞, 在 1990 年代左右由一堆前輩聚在一起所提出來的. 這些軟體開發方法都有相同的開發哲學, 也就是大家耳熟能詳的敏捷軟體開發宣言和原則.

Why we moved from Scrum to Kanban
http://nealchampion.blogspot.tw/2014/01/why-we-moved-from-scrum-to-kanban.html

這篇文章裡作者提出他對 scrum 的一些經驗和看法, 我想很多人也遭遇到相同的狀況. Scrum 雖然是一個不錯的開發方法, 但是由於本身能力不夠, 或是被誤解誤用, 導致最後對它有所埋怨情況還時有所聞. 讓我們來看看他遇到了什麼事情:

Nordstrom Innovation Lab 是家有趣的公司, 迅速產生創意並以周為單位, 開發新的數字化產品和應用. 讓我們來看看他們開發流程的演進過程

Our Process Told as our Team's Timeline
http://secure.nordstrominnovationlab.com/pages/our_process_told_as_our_team_s_timeline

敏捷可以幫忙找出解法

在 Scrum gathering Shanghai 2014 中, 一位社群的朋友: 李忠利, 他目前在百度擔任資深架構師, 負責百度知道這個系統的研發工作. 我想大家都知道, 百度在大陸是一家很大的公司, 但是還不算是很頂尖的公司, 老闆在最近幾年, 要求他們要有狼性, 要積極改進系統開發的能力, 因為百度也是一家大公司, 相對其它互聯網公司來說, 他們已經有點老態了. (哈, 這些話好像在台灣也很常見)

原先百度知道的工作模式, 是傳統的瀑布式開發方式, 每個角色分工很明確, 他們並沒有明確的項目經理, PM team, Dev team 和 QA team 各自會把工作做好, 可是這樣合作起來, 效率上是沒有太好. 因此他便開始著手流程改造.

Essential Scrum 是Amazon 中賣最好 agile 書籍, 當初也有買一本, 可惜買了之後一直放在書櫃上冷凍. 直到這次, 很幸運地在 Scrum Gathering Shanghai 2014 中, 聽到作者Ken Rubin 的分享, 當下真的覺得, 暢銷書的作者真的不是當假的, 很得十分精彩, 我想應該很值得大家去買一本來看看.

  

在這次分享中, 他的主題是經濟合理的 Scrum (Economically Sensible Scrum), 主要是想表達以下概念:

這次去上海參加 Scrum Gathering, 聽了幾場演講, 發現一些一線的公司(騰訊, 百度, 大眾點評... 等等), 他們開發軟體確實有一套, 基本上都有以下特質: 

1. 持續改進做事方法
在演講的過程中, 會發現他們似乎是套好招了, 每個公司都說明了他們演進過程, 而且每一家都演進了 3 - 4 代. 從一片混亂, 到 iteration, 到 Scrum/XP,  到 Lean Startup, …, 每次的演進, 都讓開發流程的時間再縮短, 而且做事方法都有明顯的大躍進. 這讓我看的三聲無奈, 因為我們大都用相同手法在進行開發, 最多只是用的工具不同, 或是做的專案不同, 但是還是一樣的方法在工作. 用不用 agile 無所謂, 但是持續精進做事手法是必要的.

AgileCommunity.tw 是一群對Agile技術有興趣或是狂熱的人所組成, 期待藉由經驗分享和技術交流, 來讓台灣軟體開發能更進步, 工作能更快樂.

目前 AgileCommunity.tw 已經主辦了17 場聚會, 並且有嘗試過不同整類型的活動, 像是

當初成立  Agile 社群時, 其中一位發起人(Aska) 說到, 除了促進敏捷技術交流之外, 更是期待能夠在國內舉辦 Agile Tour 或是 Scrum Gathering 等國際型 agile 社群研討會活動.

 

很高興地, 我們在一年後, 我們申請了 Agile Tour Taipei, 開始籌辦這個活動, 我知道大家雖然沒有太多經驗, 但是我們有的是無比的熱忱, 以及眾多好朋友(Teddy, 91 and Richard) 支持, 希望今年的活動能夠讓大家滿意.

在很多場合時, 常常有人會問說使用 agile 來開發會不會比較快, 我的答案通常說是不會.

  

接下來很多人就會說, 如果不會比較快, 那為什麼要用 agile? 這樣怎麼跟老闆說要用這個方法, 老闆一定不會答應的, 沒有比較快, 就沒有賣點了.

我們有把產品品質做好的能力, 但是卻沒有能力, 及早確認市場接受度如何. 往往大家花了一兩年時間後, 產品完成日就是專案結束日, 因為沒有人想要. 

那要如何早點釐清方向, 並且及早根據回饋來調整呢? 以下是一些方法:

1. Validation Board
我們很容易認為只要自己把東西做出來, 把品質做好, 東西就會大賣. 可是從不會質疑, 產品定位或是功能的假設是否成立. 例如, 為什麼你會認為客戶需要這個產品, 為何你假設客戶會認為你要解的問題很重要. 一開始需要不斷挑戰這樣的假設. 

敏捷中最大的特色之一, 就是不斷地持續交付產品. 因為它讓所有的空談或是計劃, 變成是一個活生生的東西. 或許一開始的產出並不完美, 但是這樣才能不斷回饋和調整.

 

敏捷這樣的想法, 並不是唯一. 其實中國在很久以前, 就有這樣的想法提出來. 儒家有位重要的代表人物: 荀子, 他曾經說到:
不聞不若聞之, 聞之不若見之, 見之不若知之, 知之不若行之. 

當你開始在公司要實施敏捷時, 一般人通常會找一個試點專案來嘗試, 這時候一個很重要的問題就是如何挑團隊成員, 因為那將會左右你 pilot run 成功的機率.

因為 agile 本身就一種文化的改變, 因此你要找的人的特質, 便是要能緊密地相互合作, 否則將無法把敏捷開發發揮到極致. 以下是幾個基本的選擇條件:

1. 熱情及主動
敏捷會希望團隊是一個 self-organized 的組織, 因此很多事情, 團隊成員會自己自動自發去做事. 像這樣的成員, 通常會很有熱情, 會有自己的想法想要實踐, 不會單單只等老闆的命令. 老闆只要給他方向和目標, 他們便會自己去做事.