David Ko的學習之旅

Daily Scrum 在 Scrum 流程中, 是一個重要的會議. 在 "Scrum 用一半的時間做兩倍的事” 一書中, Jeff 提到好的每日例會應該具備以下條件:
 
 
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

很多人不喜歡每日立會, 覺得他很無聊, 很浪費時間. 可是為什麼會這樣呢? 我想請大家思考幾個問題
 
 

1. 在不在乎你做的東西是否影響別人?
你做的東西都真的跟別人沒有關係嗎? 如果有關係, 為什麼別人不需要知道你做了什麼? 或者你改了什麼東西, 不會對他們有影響. 
當然啦, 如果是負責多個專案的狀況, 或許就不該和在一起開, 應該要分開處理, 讓會議有專注性, 大家才會集中精神, 把會議給開好
2. 在不在乎專案是否成功?
你覺得專案成功, 是否會帶給你成就感? 是否會讓你覺得與有榮焉? 可是這些事情都不會無冤無故發生, 都是要你有所付出, 願意一起把它做好, 這才會發生. 
3. 明明專案出了問題為何不說?
如果你常常加班加得很晚, 專案 spec 不清楚, 或是時程已經延遲,你為何不想說, 為何都只報平安. 明明你討厭官員這樣做, 可是你為何也如此呢?
4. 我們坐在一起, 所以我知道他所有事情
即使再親密的情侶, 都有可能會有對方不知道的小秘密. 有時候你覺得這些小事不重要不想說, 可是對方卻很在意. 所以你怎麼可以假設你知道同事所有事情呢?
講這些問題, 並不是要說這是誰的錯誤. 想說的一個 practice 的導入, 並不是要大家去照著步驟去實施, 而是要去思考, 當初這個 practice 想要解決的事情是什麼, 他所在的 context 是什麼? 這樣你在施行時, 你就能知道重點為何.
所以回到每日立會上面, 雖然每日立會要談的是三個問題:
你昨天做了什麼?
你今天打算做什麼?
你遭遇到什麼問題?
其實前面兩個問題, 都是在為第三個問題鋪陳. 想要跟大家說我做了什麼會影響到大家; 我遇到了什麼狀況, 你們可能也會遇到; 我延遲了, 專案可能因為它而有風險 ……
如果你沒有想清楚它問題背後想解決的問題, 沒有轉變你的思維, 那你的每日立會就會是流水帳, 你只是在 doing agile, 而非 being agile. 你的 agile 終究有天會失敗的

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在 Scrum 中, 我們會用任務版, 將目前的工作狀態視覺化, 好讓我們可以依據其內容, 快速作出判斷和行動.
 
 
通常我們會包含以下欄位: 
Feature: 這個 iteration 要處理哪些功能
To Do: 這些功能拆解出哪些 task
In Prog: 目前正在處理哪些 task
Done: 哪些 task 已經處理完畢
經過一段時間的執行, 常常會發現到有以下問題
1. 大多集中在 In Prog
在 iteration 的過程中, 你會發現很多 task 都是移到 In Prog, 然後就不動停很久. 雖然每天有standup meeting 可以知道狀況, 但是有時候太多 task, 你無法清楚記得所有項目. 如果 iteration 時間到了, 移到 done 那就好. 如果還停留在 in prog, 這時候就會頭大
2. 太多便利貼任務版上面
像我們團隊, 每個 iteration 大約會做個 7 - 8 的 features, 或者更多. 然後每個 feature, 可能會拆解出 6 - 7 個工作. 這時候任務版上就大約會有 42 - 56 張便利貼. 這時候真的一整個花到不行. 所以很多人就會想要用電子看版, 因為可以進行過濾的動作. 可是用了電子看板後, 更新速度很慢, 資訊不及時, 導致電子看板失效, 進入鬼打牆的狀況....
3. 有問題的無法立即看出來
接著前面的的狀況, 這時候如果你要找哪個是 delay, 哪個是超前, 哪個是被 blocked, 這真的是大海撈針, 常常花個 5 - 10 分鐘來掃描, 這會讓 standup 進行得很慢, 或者是失去效果. 這是可以用一些小的便利貼當作 tag, 來標示某些特定的 state. 可是如果遍地都有問題時, 也容易進入鬼打牆的花花綠綠狀況.
4. 多個團隊負責一個專案
遇到這個狀況時, 大多一定用電子看版,這樣才不會互相干擾, 也可以處理讓大的問題. 這很正常. 但是將像寫程式一樣, 一個函式過胖時, 是不容易維護的, 並且需要被改變的因素增加了, 只要某個團隊想做一些變化時, 別的團隊就會受影響. 即使是電子看板也是不容易處理這樣的狀況.
不知大家還遇到哪些狀況, 那你們怎麼處理呢?

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在實施 Scrum 時, 最容易被人家採用的, 就是每日立會(standup meeting). 它主要是用來同步資訊, 互相幫助, 以及儘早解決所遭遇的問題.
在我待過的團隊, 通常有以下幾種報告方式:
1. 每個人輪流報告
說明: 大家站在一起, 不管是在站在 task board 面前, 或者不是, 但是在報告的時候, 就是大家輪流講自己的部分, 並不會看 task board, 或是某個檔案.
好處: 很容易就開始, 大多數人都這樣做.
壞處: 他講的東西, 跟 task board 上計劃的東西可能不同, 但是你無法比對

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Issue driven kanban standup
Posted by Jorg Hollenberg in Development Process, kanban on June 14th, 2009
http://agile.luminis.nl/?p=65
我想很多團隊在執行daily standup 一段時間後, 可能會覺得這樣的事情很沒有效率, 很無聊. 這時候你必須對你的standup meeting 做refactoring.
甚麼? refactoring? 是的你沒有看錯, 雖然不是寫code, 但是還是可以做refactoring.
Refactoring是指, 在不改變對外的介面或功能下, 把內部的事情改善得更好.
同樣地, daily standup 主要目的是要即時溝通, 適時收到回饋, 及早發現問題. 對內你可以改變你的做法,
以更有效率的方法來達到相同的目的.
本文作者想出了一個方法, 來增加daily standup 的有效性. 他認為會議最主要是要處理問題, 所以他把會議形式改成問題導向的站立會議.
此外並且搭配kanban WIP 的觀念, 也就是問題的量要被限制. 要先確保這些問題被解了, 然後才加新的問題進去

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(4) 人氣()

根據 VersionOne 的調查[註1]，Scrum 中最受歡迎的的實務之一是站立會議。公司內很多團隊在導入 agile 時，都會採用這個實務。但是水能載舟，亦能覆舟。雖然它很容易被導入團隊中，但是也是聽到不少人對它抱怨連連，認為那是罰站會議，是一個無奈的活動。
 
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Agile強調要self-organized, 一切都是由團隊來決定, 因此經理在裡面要做甚麼呢?
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(4) 人氣()