Converting a Scrum team to Kanban,
Mattias Skarin
source: http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
我們如何解決跨團隊的問題
在持續改進的會議中, 有個問題被提出: “我們如何和客戶團隊合作, 並且將這樣合作模式的教給客戶團隊?” 為了解決這個問題, 我們誘使開發人員主導去安排每週的電話會議, 一起來解決共同的問題. 我們也開始進行開發人員的交換活動, 讓客戶團隊的工程師花時間和我們一起工作; 我們也從他們身上, 去學習到他們的來龍去脈.
我們如何在最後一周還保持專注
在最後兩個禮拜, 經理們和團隊緊密合作, 處理可能會阻礙發行的問題. 例如, 我們的 CEO 便擔保某個資深工程師, 在接近發佈時, 會全職在這個專案, 以加速某個核心模組的修復.
所以... 我們有完成這個專案嗎?
是的, 團隊有守住最後期限. 在兩個月前, 這看起來還是不可能的目標. 我記得當通過終點時, 我還是跟平常一樣, 並沒有特別興奮. 在發佈完後, 客戶覺得沒問題, 在一個禮拜後便發出正式的通知給我們.
我們都知道不可能去達到這麼艱難的期限. 真的, 所有你能做的就是大量加班. :) 所以, 讓我感到真的高興的, 是在發佈完後專案經理的評論:
"你知道嗎? 團隊不用再超時工作了."
回顧
我發現很難找出"單一事情”就讓我們成功. 而是很多小事情合起來, 加速彼此的效果.
看板真的有幫助的地方, 是顯示出我們哪裡有問題(或是哪裡沒有問題). 但是解決問題是要靠我們自己.
好消息是這樣的資訊的獲得是很”便宜”. 我們要做的, 只是擺一個白板在牆壁上, 然後去使用它. 不需要要求其他改變事情. 我們還是繼續用 Jira, 我們專案的架構或是進行方式還是不變. 但是很快地, 問題被發現, 我們就專心去修復它.
為什麼 Scrum 對我們來說不可行?
無疑的, 我們 Scrum 的執行狀況並不是這麼完美. 我想這也強調了, 要做到很棒的 Scrum 是件不容易的事. 例如, 如果其他組織可以決定你的軟體, 何時可以測試, 或是何時可以發佈, 你不太可能去實施嚴格的做完的定義.
但是, 還是有其他的原因導致我們的 Scrum 不可行.
無法及時在 sprint 完成的功能所產生的浪費
每個功能預計是要在一個 sprint 內完成. 但是當開發開始時, 開發人員發現它太大了, 因此在後期將它們切小, 重新規劃要做的範圍. 在下個 sprint 時, 便會有另一個功能便會被移掉. 當這樣的事情一直重複時, 原先的專案計劃變得不太可靠. 後來我們轉向 Kanban 後, 我們便允許這個功能一直待到做完為止. 這個功能完成後, 便放到下一個即將到來的發佈中.
重構常常被阻止不要做
在排定功能的優先順序時, 通常需要考量兩件事情: 功能的商業價值, 以及客戶那邊不斷來的壓力. 這通常會導致大家只想專案準時交付, 而重要的重構便會被排除在外. 如果團隊說服管理階層去嘗試重構, 但是卻無法在單一 sprint 內就完成這個功能. 如此一來, 客戶的管理階層就會認為重構是浪費錢, 是血本無歸的事情.
解決問題需要和其他利害關係人合作
在某個機會中, 團隊需要重構由外面廠商所寫的重要元件. 這需要透過我們團隊, 平台專家, 管理階層, 和客戶一起合作. 因此, 即使團隊發現問題, 也需等到每個利害關係人拋下一切事情, 問題才能被解決. 所以要解決像這樣的問題, 重點是要邀請所有利害關係人. 如果把團隊孤立在 sprint 內, 這將會沒有任何幫助.
評估是件浪費資源的事
…. 評估不會增任何準確度.
讓我們正視這件事, 它並不是只跟 Scrum 有關. 有好幾個面向需要一起考量, 才能確保軟體專案成功.
那其他的解法如何?
對於任何一個問題, 通常都存在一個以上的解法. 所以讓我們來思考一些事情.
“所以看起來你很痛苦, 為什麼你不把 sprint 拉長一點?”
這也是個選項, 問題是我們沒有信心, 告訴客戶我們要這樣做. 我不確定像 ”我們要做比較久的 sprint, 我們做事的時候, 請不要來煩我們”, 這樣的訊息會產生正面的回應.
“那什麼是你做完的定義?"
確實我們是以 ScrumBut 的方式在做事. 但是我們不是專案中唯一的一群, 例如, 我們不能控制客戶那邊的開發程序. 要改變做完的定義, 必須要求客戶一起接受這樣的結論. 事實上, 我們有做類似的事情, 像是提供較長的可見度, 可以看到價值鏈的下游部分.
那有什麼數據?
速度/生產量
在五月時平均的生產量是每週 7.25 個故事. 到九月時是每週 13.50 個故事 (紅線)
速度/ 人天
如果我們看的是人天的生產量, 五月的平均值是 0.64. 在九月是 1.04 (綠線, 在圖形中縱軸的值是百分比)
我們今天在哪?
團隊很努力並且已經完成, 大部分他們想要加進去的測試框架. 我提過之所以會這樣做, 是為了證明可以克服技術上的困難, 以及專案管理對外銷售的問題. 我們從沒想到, 當初我們還要找時間去把這個改進給放進去, 但是到現在我們已經做到了.
大部份團隊所學到的技術, 已經轉移給客戶的開發團隊. 現在的挑戰, 是如何將這些知識教導給客戶的 IT 組織和專案管理團隊.
一個團隊成員的觀點
“最難的部分是訓練自己擁抱新的思維. 能夠真的了解到, 程式碼寫完, 不代表這個工作就完成了.
看板讓我們重心放在思考品質上面. 當你看到白板上有個欄位叫做”功能測試”時, 你很難去忽略它. :) 它強迫我們離開只有寫程式, 寫程式, 寫程式的輪迴中.
我想我們學到最棒的教訓, 就是隨時要考量到品質”
- 開發人員, Mariana.
Kanban 變得狂熱
在專案的後期, 一位來自 H&R 的女孩子來找我, 問我是否有任何想法, 可以減低她所遭遇到的壓力. 我一開始有點懷疑, 但是告訴她一開始所做的 - 頻繁去調整優先順序, 是其中一個有問題的地方, 我們討論了一些可行方案, 然後我在她座位旁邊的玻璃牆壁上, 畫了一個簡單的看板流程. 我要求她去告訴委託她的利害關係人, 把他們的需求依據優先順序, 放到” in queue” 欄位中, 但是不要和已經開始處理的混在一起.
一個禮拜後, 我經過她的辦公室, 發現到整個牆壁上有很多看板系統. 看板系統已經開始被她的同事們使用 - 包括財務, 行銷部門和 IT 部門.
我希望你可以從這裡學到一些東西. 至少我學到不少.
Mattias Skarin斯德哥爾摩, 四月 2010
如何將 Scrum 團隊轉換成 Kanban 團隊 (2) http://kojenchieh.pixnet.net/blog/post/376108454
留言列表
