David Ko的學習之旅

第九章 處理程式的錯誤 (1) 


摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 9 Handling Bugs

第八章 處理技術性的使用者故事

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 8 Handling Tech stories

第七章 定義什麼叫做”做完” 

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 7 Defining Ready and Done

第六章 追蹤最高目標

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 6 Tracking the High-Level Goal

我曾經過做過的公司, 很多人都不知道灣案的最高目標是甚麼, 或者和專案經理想的不同. 如果能讓人們知道它們要達到的目標是甚麼, 那它們會比較想要去完成它.

在這個團隊中, 我們將專案的最高目標, 貼在Kanban白板的右上角. 例如: 在2011 Apr 5, 我們要一個沒有嚴重問題的版本, 並且要能在全國運作. 並且會列出相對應的里程碑. 當這個目標完成後, 我們會再列下個目標.

第五章 延展你的Kanban 白板  


摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 5 Scaling The Kanban Boards

第四章 專案進度版 (The Project Board) (1)

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 4 The Project Board

第三章    參加每日的雞尾酒宴會

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 3 Attending the Daily Cocktail Party

作者基本上將每日會議分成三個階段:

第一階段: Feature team的每日會議 
其中有兩個feature teams是由9:00開始每日會議, 另外一個feature team是9:15開始. 每個人在任務版(task board)面前站成半圓形, 討論今天要做甚麼, 以及他們遇到那些問題要解決. 

第二章    組織團隊

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 2 Structuring the Teams

軟體專其中一個重要挑戰, 是如何把人們拆解適當大小的團隊, 並且讓這些團隊能合作得很好

當人數到達60 人時, 我們面臨了溝通和合作的困難, 這是典型團隊太大的問題. 很幸運地, 我們都在同一個地方工作, 最多花30 秒走路的距離就能找到彼此. 因此我們很容易實驗要如何組織團隊. 事實上, 組成適當團隊可能是這個專案最重要成功的因素.

以下是我們的團隊結構:

我們有五個團隊. 有些成員是在這些團隊以外, 負責一些特殊事務和協調的事情. 這些人像是project manager, project admin, configuration manager, performance test expert, development manager, coach等等.

1.      一個需求團隊 
-          它基本上是一個virtual team, 所以並沒有和團隊坐在一起, 但是會坐在附近, 讓團隊成員可以方便找得到. 

第一章    關於專案背景

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 1 About the Project
 

Henrik Kniberg幫瑞典警察局(RPS, rikspolisstyrelsen), 開發了一個數位查詢系統(PUST, Polisens mobia Utrednings Stod). 基本上, 每台警車上需要配備一個小的手提電腦, 可以連上無線網路, 利用一個網頁程式, 來讓警察人員快速處理查詢的工作.

因此警察人員可以利用系統, 直接查詢到所有資訊. 因為這系統直接整合到所有相關的系統.

這個專案的目標, 是打算在2011年早期, 就能讓所有瑞典警察使用. 開發團隊大約是從2009 九月開始, 第一個release (pilot version)在一年後出來, 之後每兩個月接著一連串的release.

專案在2009 Q3一開始時只有10 人, 在2010中時成長到30人, 到2010 Q4 超過 60人.

或許很多agile的團隊會說一年才release第一版似乎太久, 但是對於一個政府專案, 這已經是很快的. 之前政府專案有成經高達7 年才有一個版本出來. 並且之後每2個月有release 出來也是很不簡單, 通常的案子都是兩年一次更新版本.

為了降低大型專案的風險, 關鍵的做法是找出方法來切割它. 因此作者把這個專案, 根據兩個面向來做切割: 從地理位置和犯罪型態.

(1)   Release 1.0-1.2: 僅處理一個地區(Ostergotland), 以及一小部分常見的犯罪型態(像是酒駕, 擁有槍械). 之後連續的release我們在改進穩定度和增加支援的犯罪型態.

(2)   Release 1.3: 增加一個能支援的地區(Uppsala)

(3)   Release 1.4: 擴充能支援到瑞典其餘的地方. 這是我們主要的release

(4)   Release 1.5: 增加支援額外的犯罪型態, 以及新的查詢

一開始時, 我們有一個客戶幫我們列出high level的功能清單. 我們叫做feature areas, 或者你可以說它是epics. 我們使用這分清單來進行high level 的排程和規劃.

接著, 我們請一個客戶, 駐點到我們開發團隊, 給我們一些深入的回饋, 幫我們看demo, 回答開發人員的問題等等. 一開始, 他大約是每周來一次. 後期, 會每天排定一名駐點客戶和我在一起.

在每次 release的一個禮拜前, 我們會有一個驗收測試小組, 基本上大約10名警務人員或是其他實際的使用者, 花幾天的時間來進行測試, 並且給我們一些回饋.