Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 六月 2015

Agile Project Management with Kanban 讀後感Part 2.

leave a comment »

微軟XBOX開發團隊由多個採用Scrum 或 Waterfall的開發團隊,順利的轉成敏捷的Kanban 開發模式,這是一個需要天時、地利加上人和相互配合才能擁有的成就(轉型需要群策群力,絕對不是一、二個優秀的人才就能作到的)。作者分別描述在:

  • 第四章. 描述如何由傳統Waterfall開發轉成Kanban

  • 第五章. 描述如何由敏捷Scrum開發轉成Kanban

在我多年的開發歷程裡,也曾有過這種經歷。那是在一種不知不覺當中完成的,開發團隊的素質就是那麼優秀而人品又是那麼和諧,那時我也是開發團隊的成員之一(哈哈!不小心誇到自己XD),我們每天都在一種很High 的開發情緒中度過,遇問題解問題沒問題就向前衝。成就感遠遠把疲憊拋在腦後,團隊的精神似乎超過一切,完全不知道怎麼做到的。然而;在我成為顧問以後,卻一直再沒有機會遇到這樣的場景、這樣的挑戰及這樣的團隊。但是;今天在這本書裡頭,卻又有見到這種情景,Eric竟能順暢的只用三言二語便把整個變化的過程描述了出來,真是值得稱許。

.

Rude Q&A

這本書的結構是在每一個章節結束前一定會有一堆所謂的 Rude Q&A。一般書籍習慣用「結論」來做為一個章節的結束及回顧。但作者採用一種藉由問答的形式來對整個章節的描述做一個總結。如果你看過作者 Eric Brechner 在Youtube上的教學影片,你就會知道他最擅長的就是這種問答的方式。這些篇幅可以說是精華所在,值得一再回味。例子:

Ch2.1  Problem: Blocked because all items in an intermediate step are done.

Ch2.2  Problem: Blocked because prior step has no item done.

… .

Inside XBOX

每個章節裏頭都會有描述 Xbox 的開發團隊如何來面對各種狀態及他們如何處裡的過程說明。作者運用這種方式,將理論跟實務做了結合,效果相當不錯,可以讓人對理論的部分留下更深的映象。

.

下面這一句話,道出了開發理論對專案的處理態度,值得強調一下:

A large part of project management is limiting the chaos inherent in group work.

— Eric Brechner.

混亂Chaos無疑是專案開發的最大敵人。「傳統的軟體開發法」試圖以事前的完整規劃來限制住它。因此假設失敗的最大原因是事前規劃的不足所造成,所以需要更精細的規劃,因此逐漸的失去了快速回應變化的能力。近代的「敏捷開發法Scrum」則以小的循環迭代來取代必須事前做精細規劃的成本,運用較少的循環時程來增加對變化的回應能力,以此來制衡混亂。相較於前面的二種方式;「看板方法Kanban Method 」則採用直接限制Work In Progress 的方式來直接面對混亂限制混亂。這就是看板方法的精髓。(描述得好極了,但過分的簡潔,反而教人摸不著邊,這一點;(有機會的話)我會在未來的Session上強調的。其實敏捷開發Scrum是用小循環也就是微分的動作,精實的看板方法則是運用WIP直接設限問題點,這是一種積分的動作,把二者加起來,便是一種「軟體開發的微積分」! 有機會再聊…)

.

Kanban Method 只有每日站立會議

精實的最大原則便是消除浪費,Scrum的四大會議在這裡則只剩下每日的站立會議了。因為在計畫會議時做挑選Backlog、Breakdown Backlog 成為 Task等等工作,還有隨時都可進行的展示及回顧動作,都已經融入在工作流程的關卡中去完成。此時;每日站立會議只問一件事:

 

The only required question at daily standup:

Project manager asks whether anyone needs extra help.

.

簡潔優於複雜

下圖左側是XBOX開發團隊所採用的簡單型看板,右側則是上課時用來訓練用的看板遊戲的模擬看板看起來就複雜多了。

簡潔型看板

.

明顯的簡單讓人容易一眼看出問題,怎麼說都是比較務實的。如果能夠選用另一種形式的個人看板來配合使用效率就會更高一些了。

.

加入電子看板

我顧問過的團隊以採用 Kanbanflow.com 或 Trello.com 的居多,而且都已經能夠持續一段時間了。推薦給大家:

using

.

廣告

Written by ruddyllee

2015 年 06 月 27 日 at 10:35:39

新書: Agile Project Management with Kanban 讀後感 Part 1.,

leave a comment »

Eric Brechner 用不同的方式帶領XBOX開發團隊實踐Kanban的過程,就紀錄在這裏面。

Agile Project Management with Kanban

Eric Brechner 2015.3月出版. by: Microsoft Press

.

這是一本不直接談Kanban Method理論的書,他只有實務而且是微軟 XBOX開發團隊的開發實務。他不是教科書,沒法拿來教學用。它是我在尋找「在傳統開發方法下運行KANBAN」的資料時所找到的新參考書籍。作者手法特殊讓人大開眼界,過去在MSDN上偶而可以看到他的文章。作者果然出書了,這是一本看板實務的絕佳參考書籍。作者文筆輕鬆、簡潔呈現出俱有相當深度的問題解答能力,真是受教了! 我們可以從書裡頭看到他思維的靈活與巧妙(不同於一般講師)的解題方式,相當有趣討好(怪不得成為Amazon五顆星的暢銷書),我不知道你看了以後是否會跟我有一樣的感受。由於我習慣用正統(也就是David J Anderson)的方式來講授看板方法,Eric 的方式還真讓我有一些個驚訝。讀完後;學到了如何用不同角度看Kanban的解題方法及如何更靈活的使用Kanban。整本書看了一遍又一遍,好過癮!(但是我必須強調的是: 看這本書時,是需要先有一些對看板方法的基礎了解。也就是說;你可能需要多看一下正統的看板方法的書籍,才能意會作者在強調些什麼,基本上他不是一本用來入門的書籍)。這裡面有太多東西可以跟大家分享了,先來個 Part 1,把它介紹給大家,順便以實用的 Track Column 來做開場。這本書雖然薄了些,但頗具內涵,閱讀時常常會發人深省,所以決定分段來介紹它。

.

與眾不同的看板 quick-start guide

熟悉看板方法的人都知道,實行看板只有三步驟: 一、視覺化你的工作流程。二、設定WIP限額。三、管理流程。真是夠簡單了! 但作者把quick-start增加為五步驟(不禁讓人想說,這還叫quick-start嗎?!)

quick-start guide:

  • Step 1. Capture your team’s high-level routine.

  • Step 2. Redecorate your wall

  • Step 3. Set limits on chaos

  • Step 4. Define done

  • Step 5. Run your daily standup

仔細讀完後你就能意會到,它完全是踏實的執行步驟,當你要實作時;基本上只要照著做就對了(然後;在加上一句作者愛用的話: Good luck!)。

所謂的 High-level routine 其實長成這樣,其實它就是團隊開發時的基本工作步驟。

High Level Routine

High-Level Routine 對照到看板牆(這張圖是我畫的,目的是便利大家做參考)


.

是的;Eric 只是把它實務上的視覺化再口語化罷了,然後在這裡把 XBOX團隊所用的看板介紹給大家。在David J Anderson 的定義是《視覺化你的工作流程》。其它幾個步驟就明確多了,無須多說,有問題的人歡迎參考我的書

.

相對於電子看板,不但不要放棄實體看板,更要以它為主。  

Eric Brechner

.

實體看板 >> 電子看板

很多人都不會同意這句話的,尤其是我們面臨的是Mobile is eating the world 的時代。很難想像我們應該捨棄電子化看板而採用實體看板(實質上是二者都要用,只是要以實體看板為主而已)。但是由Eric 在書裏頭的用法,不論是TFS 或是目前市面上的Kanban 工具,都很難做到這種靈活度 — 這是採用實體看板的真正理由。基本上 Eric 是 Xbox開發團隊的成員,而他們所採用的當然是微軟的TFS囉! 但他却以實體看板為主,電子看板為輔。至於對電子看板的做法則是指派一個人,每天花個5分鐘把看板上的資料更新到 TFS上頭,也就是用人工的方式額外來進行工作同步的作業。當然電子白板是提供團隊共同編輯、同步行事曆的最佳工具,對大型開發團隊更是不能缺少(可以讓專案透明化,並有利於與其它團隊配合協作)。實體看板則是每日工作的重心,它是便利團隊一起討論,發掘問題的神器,當然應該以實體的白板為主,電子看板為輔。

XBOX team kanban board

微軟 XBOX 開發團隊所採用的實體 Kanban Board

.

》Track Column 的運用

這裡先來介紹 Track column的運用,當遇到工作流程受阻礙被Blocked 住的狀態時,在遭遇到你無法控制的事來堵住你的流程時(上課時我會教大家避開那些無法控制的事項,而這裡則是教大家如何面對它),在你唯一可以做的就只有不斷的提醒自己跟等待時,此時這個 Track column 就可以派上用場了。把它拿來暫時擺放這件事的工作卡片(參考下面的圖示),它可以隨時拿來提醒團隊進行追蹤或討論,有關這件 Blocked 的事該如何處裡、進度又是如何。

Track Column

好用的 Track Column 運用  (Implement 欄位內出現少了見的三個次欄位的設計)

.

Track Column可能是看板中少數有機會「倒退嚕」的區域,也就把貼上去的卡片放回來,他也是少數不計算在 WIP (Work In Progress)內的Column,是遇到我們無法掌控的情形,例如: 跟外部團隊或其他公司配合的API呼叫,當遇到對方改來改去或一再延期交付,這個時候便可以用 Tracking 來掌握他的動向,當然你也可以考慮把這種不能控制的流程關卡移除在看板牆之外,但有時候為了能夠持續追蹤,還是選擇多花一分力氣來時時看管他。(在Scrum 的 Task board上,有一個右下角的特殊區塊就是在處理這種特殊情形的工作,常常被稱為 parking lot.)

.

A large part of project management is limiting the chaos inherent in group work.

— Eric Brechner.

就先談到這裡了,待續…

Written by ruddyllee

2015 年 06 月 22 日 at 11:23:22

張貼於未分類

曳光彈 Tracer ammunition 的原理

leave a comment »

對軟體開發而言;所指的是程式碼在執行時所留下的軌跡。

From: The Pragmatic Programmer一書

.

回答一下;學員在上課時問到的軟體開發時非常實用的原理 — 曳光彈的原理。語出 Andrew Hunt  & David Thomas 所合寫的《The Pragmatic Programmer》一書。原文是隱喻在黑暗中用機槍射擊時找到目標的一種方式。當你在黑暗中進行射擊時,你可以依循與正常子彈參雜在一起的曳光彈的發光軌跡來找出目標的確切位置(距離、角度及方位)。也可以用來確定環境狀況(例如: 溫度、濕度、風,等影響因素)。然後你便可以用計算的方式找到你的目標。(如果每一樣東西都嚴格按照規定的方式工作,你的計算表也正確無誤、而且環境沒有再發生任何變化的話,則你的子彈應該能落在距目標不遠的地方。)

在黑暗中發光的程式碼

“發光的程式碼"是在描述一旦你在程式碼中隱含了擁有曳光彈特性的程式碼後,就能夠透過這些軌跡來查看你所想的或是預設的程式執行方向,是否與假設的軌跡相同。我們可以藉此來偵錯或進一步了解程式的運作(有許多種產生程式軌跡的方法,其中;程式的Log 就是一種曳光彈方式的軌跡紀錄)。

曳光彈

黑暗中的曳光彈

.

含有曳光彈的彈藥箱裡,通常是在三或五顆子彈之後參雜一顆曳光彈,對夜間射擊而言它讓我們容易看到目標,也可以用來確認交織的空間火網,當然相對的敵人也同時能看到我們,也就是我們也成了他所看得見的目標了。所以對射擊而言它不一定是最好的方法。但對軟體開發而言,卻相當有用。而且;曳光程式碼並不是用過就扔掉的,通常你編寫它,是為了保留它。它含有任何一段程式碼都擁有的完整的錯誤檢查、結構、資料。它只不過是功能較不全而已。但是,一旦你在系統的各元件間實現了端到端(end-to-end)的連接,你就可以檢查你離目標還有多遠,並在必要的情況下進行調整。一旦你完成成功的瞄準了目標,對於日後再增加功能時,將是一件容易的事情。對程式的改動或功能增加都是絕佳的利器。他同時也是良好的測試程式。

如果曳光彈的方式對程式的正常運作會有所影響,例如大量的Log會造成程式的負荷加大,則運用參數來關閉它則是一種必要的行為,也就是只有在需要時才打開這項功能。絕對有必要將執行時期與偵錯期作一適當的區分。

容易被忽略的Logger

老實說;在雲端的時代裡沒有程式可以沒有Logger的。沒有Log的程式就好像在黑暗裡憑著記憶在射擊一般的盲目。下面是一個典型的 Logger圖示,經驗不足的程式設計人員很少去運用Log的功能,甚至經常忽略了Log 的特性(通常要等到客戶要求改善程式的執行速度時,才會意識到需要查看程式執行的軌跡)。圖示說明:左側是Log資料的來源種類。一般的Logger 通常會統一把資料交給「Logging Core」來處理。最後再根據所指定的輸出目標作輸出。我們可以透過Output的資料就可以畫出程式執行的路徑了。也就是曳光彈所指出的路徑了。Logger可以很簡單,也可以設計成處裡多種方式的複雜logger,下面是一個典型的範例圖示。(辛苦的畫下面這張圖的目的是希望大家對Logger能有多一分了解。)

logger

可處理多種輸入類型的Logger

.

Written by ruddyllee

2015 年 06 月 16 日 at 10:46:18

張貼於未分類