Ruddy Lee 分享空間

Emergent Design 演化設計

團隊如何解讀看板 – 1分鐘統計報告

leave a comment »

.

許多敏捷團隊都已經運用看板進行站立會議,但卻仍然採用傳統Scrum站立會議的三件事來進行會議:

  • 昨天做了什麼?

  • 今天準備做什麼?

  • 有沒有遇到障礙?

 

對看板而言;其實這三件事都已經記錄在看板上了。雖然這種做法基本上沒有什麼問題(我也一直是這麼做的,但總是會覺得好像有些不足的地方,好像可以作得更好才是,因為這是團隊共同的事,所以應該是團隊一起運作才是,一問一答的輪詢方式似乎太個人化了?!)。這麼做會忽略了看板上已有的資訊,而無形間浪費了看板上的基本資訊,也就是團隊在「視覺化」上的認知機會。團隊也會因此把焦點放在了個別成員的身上,而忽略了看板所具有的團體性。那要怎麼做才能充分運用這些特性呢? 一種看板式的站立會議,它是以團體為主的方式,它專注於回饋(一分鐘統計報告):

.

解讀看板

適合團隊共同運作的看板式站立會議

.

一分鐘統計報告

首先;運用值星生的方式,讓團隊成員輪流擔任這個職務,輪到的人,就要負責看板的維護工作,然後必須在站立會議時做先期解讀的工作,先幫大家做一次統計式的解讀,目的是協助團隊迅速進入狀態。然後才是由SM負責一對一的輪詢,問的內容當然就不止於那三件事了。進行的步驟如下:

  • 設定「值星生」的制度,以一個星期為一輪,讓他負責日常看板的整理工作還有看板的維護。並於站立會議時首先發言,用一分鐘來向大家解譯目前的看板狀態,讓團隊能迅速進入狀態,而無須重新做個別解讀。提供團隊一起能夠同步看板的視覺認知。這是一種單向的報告方式,團隊無須立即回饋。「值星生」必須以統計分析的方式進行報告看板現狀。

  • 然後由SM 接手以 提問 的方式輪詢團隊成員個別的工作狀態,並要求成員對值星生的報告進行必要的解釋或回饋

  • 最後,SM針對個別事件進行 重點討論,詢問團隊是否變更流程以解決障礙、等待Waiting狀態說明及討論是否需要進行變更(WIP值)來改善流程速度,作總結或重申重要事項。

.

統計式解讀.png

參考自一日看板遊

.

統計式的看板解讀

解讀上圖: ( 由右往左)

》團隊還沒有成功的發佈任何東西,因此發佈欄位是空的。

》有一個嚴重障礙,就是測試區Task-A 無法被正常布署,沒能夠通過測試,測試人員正在努力中,但因為測試欄位的 WIP值設成1(因此只要有任何一項測試失敗看板就會被卡住)。

》這時候當初做Task-A的成員正在做 Task-C(是否請他們協助偵錯? 畢竟解鈴還須繫鈴人),而另外一組成員已經做完Task-B了,但受限於看板測試欄位的上限WIP值因此無法移進來做測試,因此沒有進度。

》預備欄位目前只有一個 Task-D 可以再移入一項工作。

》此時產品負責人PO仍在審視所有的工作項目。

看板解讀由右往左的目的是希望能盡快看到障礙,尤其是上圖中將測試欄位的WIP上限設定成1,表示這個團隊非常重視品質,只要有任何一個測試失敗的工作項目,團隊就要停下來解決,一直到解決之後才能繼續開發的流程。當然我們可以考慮把WIP上限調高,但這樣做了就會延遲解決問題的速度,但仍然能夠持續有產能輸出,好處就是生產線不會完全停下來。

 .

善用值日生

看板需要整理,又必須與工具(ALM: Application Life Cycle Management)同步,SM常常為此抱怨連連。採用值星生的方式能夠適當的降低SM的負荷,又能多一個人出來管理、解讀看板。是團隊落實自我管理的一種實踐。

因為以星期為範圍所以稱為值星生好像比較準確。看板值星這件事,勢必會造成「值星生」不得不在站立會議之前先行整理過看板,然後再運用統計的方式先行解讀過看板,然後才能在站立會議時運用足夠簡潔的語句描述給團隊聆聽,而團隊也會因為有人代為解讀了看板,便可以省下各自解讀的時間花費,一起聆聽看板解讀也能造成大家對看板上的動態有更一致的認知。同時這也是一種回饋的方式(只要團隊成員聽完後覺得跟自己的解讀有所差異時,此時成員之間任何的交談與討論都是極具價值的)。

.

小結

團隊共同解讀看板的方式:  (站立會議開始)由「值星生」先為大家以統計的方式做1分鐘看板解讀,然後才是由 SM 接著進行輪詢團隊成員,成員一一更新看板上的工作項目,同時就剛剛值星生的解讀進行解釋或更正。完成一輪後SM 做成重大事項的總結或重申重要任務。站立會議於 15 分鐘內結束。

.

Written by ruddyllee

2017 年 04 月 25 日 at 17:27:26

需求要作到哪裡為止?

leave a comment »

.

敏捷開發需求要不要全部做完?

.

Sprint可以消化需求,但展示會議又會在尋求回饋時增加需求,因此便產生了更多的需求,每個迭代下來需求只會不斷的增加,試問需求什麼時候才能做得完呢?

 「梳理會議 Refinement meeting 是需求進行調整、刪除的時機,但PO經常只做需求修整,很少會去刪除需求」

 .

敏捷開發的一大特色,需求持續的增長

需求的增長可能是來自展示會議的回饋,也可能是開發團隊越來越清楚應該給客戶些什麼(團隊自我回饋)或是為了強化程式架構性的需求(來自工程師的回饋)。總之;需求增加了,但專案的開發時程卻隨著時間的過去一再地減少著,而人力與資源也持續的消耗著。請問;需求要作到哪裡為止呢? 這裡提出一個新的措施,設定需求停止開發線

需求無限上綱.png

左側: 解決之道,右側: 持續增加的需求

.

停止開發線  Stop Development Line

一條屬於PO與團隊共同協議下的需求停止開發線(SDL)。它可能是因為要作發布作業所以必須停止開發的工作日,也可能是專案預定開發時程的結束日,當然也可能是專案的資源用完了、專案預算被終結了都有可能(需要多考慮到使用者測試及發布作業所需時間)。總之;專案的需求開發工作在這裡停止了,接著來的是使用者的測試作業或是測試後的缺陷修補,在敏捷開發的作業下,需求很少是被完全做完的,這要歸因於敏捷開發採用迭代的開發方式,因此需求只有在要進入開發之前(一般是梳理會議 Refinement meeting) 時才會被拿出來仔細討論,因此也就產生了較大顆粒與較小顆粒不同的大小差異的需求存在 backlog 裡頭。一旦較大的需求被開始Breakdown 時,需求的數量就可能會再增長,這是需求不斷增加的另一個來源點。

.

需求的無限上綱

每個Sprint開發團隊都會努力的去消化需求,這是需求主要減少的來源,另外就是梳理會議,它可以就不需要的需求進行討論後決定是否刪除,這時需求也會減少。但每個迭代後的展示會議又會向客戶尋求回饋,繼續新增需求,因此就產生了需求數量的持續增長,試問需求什麼時候才能做得完呢? 答案:

實施敏捷開發時,一切以滿足使用者為主,需求是不需要全部做完的

.

如上圖右側的區間,為了克服持續增加的需求量,所以我們在需求的累積堆疊裡新增一條停止開發線(SDL),這一條時間線限制了開發作業的停止開發日,換句話說;需求只做到這裡,線以下的需求預計將不會被做到,也就是成為了需求的候選名單,之所以稱為候選名單,原因是這些需求可能透過梳理會議時因為其他需求的刪除與修改,而向上提升到停止線的上方,進入到可以被開發到的範圍。這是敏捷開發的動態化需求的一種特色,它是隨著客戶的要求做增減的(唯一的例外是: 只有當Sprint在進行時,該次Sprint所要完成的需求是不容許被變動的)。此外,PO擁有梳理需求的絕對權限,但停止開發線卻是PO與開發團隊共通的協議(是被討論出來的)。

.

線的上方有一個區域稱之為需求的競爭區。這是一個在停止開發之前最後被做到的需求區,這塊資源是由所有客戶所共享的,使用者可以決定在發布作業之前產品將擁有的功能範圍。之所以稱為需求的競爭區的原因是,每一個提出需求的使用者,都希望自己所提出的功能被做到產品裡頭(我們應該以滿足所有提出者的希望為圭臬),但受到停止開發線的限制時,就有可能被規畫到不會被做到的需求,因此就會產生競爭;一種希望自己的需求能被放入開發功能區裡頭的競爭(PO與其他的利益相關者 Stackholder 持續進行角力與溝通),這是難以避免的現象,至於採用甚麼標準來做取捨,就由組織自行決定了。這是一種良性的需求取捨行為,對敏捷開發有著正面的效應。需求在透過不同的 Stackholder 討論之後將更為精煉。

.

圖的左側提供解決原則:

  需求的優先順序

我們以完成此需求對客戶所產生的價值為依據,依序排列下來便可以得到需求的優先順序。即便是到了最後需求沒有完全作完,但基於有限的開發時間裡至少我們把較重要的部分都開發完成了(請參考註解,談到需求開發與功能真正被使用者使用到的百分比)。

  需求的梳理

產品負責人Po擁有對所有需求進行新增、刪除、修改的權利。這屬於PO對產品進行開發的權利與義務的一環,梳理會議refinement meeting是它的執行時間,一般以不定期的每周召開一次為主,時間為固定的一個小時之內完成,梳理原則如下:

  將較大的使用者故事調整(Break down)到適合開發的大小。

  改善那些寫得不好的使用者故事。

  開發團隊對使用者故事進行相對估算,以符合 Sprint 足以開發完成為主。

  對使用者故事加入驗收標準。

  深入規劃產品待辦事項,做較長期性的技術規畫。

  刪除沒有必要開發的需求(對於開發作業,少就是多的哲學,參考註解)。

善用停止開發線

這是一條以時間為依據的動態限制線,它明確的規範了需求開發的終止日。停止開發線的產出方式:

.

PO與開發團隊一起討論出來的共同協議。

  開發團隊評估自己的開發能力並與PO預期想要獲得的商業功能,在二者之間進行協調後取得的停止開發線。

初期估算的日期較不準確,應該隨著專案進行到後期,相關訊息越完整時持續進行調整。

需要多考慮到使用者、整合測試及發布作業所需的時間。

.

它可以用來應對需求很少被刪除的情形進行改善(一般PO的通病,偏好需求的修改很少有刪除的動作,造成需求的數量出現容易增加但卻不容易減少的現象)。PO通常可以運用使用故事地圖作為劃分出產品最後完工時的功能雛形,而停止開發線能讓此雛形得以具體化。

停止開發線的好處:

  可以拿來解決需求只增不減的問題。

   讓發布作業變得明確。

  便於掌握資源與預算。

  便於具體化產品的功能雛形

.

小結

敏捷開發不願重導傳統開發對需求過度計畫的問題,因此只有在 Sprint 開始前才會花時間去做需求個別的細部 break down。因此對需求的堆疊(本體)而言會始終保持一種足夠抽象的形式,直到他被選擇進入開發週期才會被細化,也就是只有在開發團隊真正要開發的時候(進入Sprint的週期)才會花時間去做估算。在這種作法之下,實在很難進行整體專案的時程預估,所以;如何決定停止開發線 DSL的時間呢?確實很難估算,有一種好的做法是: 運用資源的多寡來決定停止開發的時間線,這是一種務實的作法。也符合敏捷開發做到客戶滿意為止的精神。範例: 在精煉(將專案資源考慮進去)之後產出的使用者故事地圖,團隊就可以依據此地圖的總需求量來決定第一次停止開發時間線。你可能會擔心它的準確度,但因為它是動態的一條線(隨時都可以來調整它,一般會在每次的梳理會議refinement meeting時進行調整)因此不需要太在意第一次的設定日期,真正該重視的反而是它上面的需求競爭區間的大小。

.

.

  Standish Group 總裁 Jim Johnson 2002年的調查,針對軟體被使用的開發功能應用統計。一般僅有( 一直會被使用到 7% + 經常使用 13%=) 20% 的功能經常被使用者用到,其他有 45%的功能,幾乎重來沒有人去使用,這張圖可以提醒我們應用程式的少數功能,其實就能滿足真正使用者的需求了(這個統計結果是用來粉碎需求必須全數完成的謬誤觀念,為 Jim 在 2004 extreme programming 年會所發表)。

pie-chart-copy

.

:  如果你的開發作業是委外開發的形式(outsourcing) ,當然就可以忽略這一條線了,因為廠商會自動把資源控管住,你想多做一點都很難!

 

.

敏捷委外開發時的守護策略 –實例化需求

leave a comment »

.

一個經常被問到的問題:「實行敏捷,遇到大量委外開發時,怎麼辦?」

.

※ 實務上,你唯一能作的就是持續的作驗收測試,用來保證廠商所交付的功能是否仍然符合你的需求?但,當你運用「實例化需求」的解決方法時,你將會變成努力的在維護文件系統與程式的同步性,並依靠一個由文件喚起的自動化測試的系統,來持續的驗證並維護這個活文件的系統(一般而言,我會建議採用 FitNesse來維護你的活文件系統)。

.

採用「實例化需求」的最大好處,就是能夠持續做到ˋ自動化測試,並明確的運用文件上可自動化驗收的測試案例數據,做到測試與文件同步的效益。

.

守住「活文件」- Living Document

運用活文件來守住委外廠商所交付的功能程式還是不是好的? 是否還能夠正常工作。請參考《實例化需求》(註1)一書第三章一開始的說明:

.

“一般認為實例化需求說明的過程和工具有二種流行的模型。以驗收測試為中心的模型及以系統行為規範為主導的模型。

以驗收測試為中心的模型,就是 A-TDD也就是驗收測試開發,側重於自動化測試。並把它作為實例化需求說明的一部分。他的主要優點是使開發目標更為明確,並且可以防止功能退化。

以系統行為規範為主導的模型,通常稱為行為驅動開發,也就是 BDD。則側重於制定系統行為的場景。它的主要工作是透過協作與需求澄清,在專案關係人和交付團隊之間建立共識。“

.

因此如果企業擁有大量的委外開發廠商的話,一個好的持續進行驗收測試的方法,就是實行 A-TDD(註2)就是驗收測試開發,讓公司內部的人員守住文件的正確性,並讓它能夠與廠商開發的程式持續同步,你能夠運用的方法正是由 ward Cunningham 所創始的 FitNesse (它在: http://www.fitnesse.org/),目前的維護者是著名的 Robert C. Martin, Micah D. Martin, Patrick Wilson-Welsh & other.

我每隔個幾年就會與它相遇一次,同樣是採用 SBE (Specification By Examples 實例化需求),但我總是會採用驗收測試的 FIT 架構,而沒有使用更適合內部開發採用的BDD(Behavior Driven Development行為驅動開發),這一點並非我有所偏好。實質上是我碰巧都遇到處理委外的問題所致。實質上,該採用那一種解題法呢? 就要依照要解決的問題種類來作判斷了。這二種方法要用對場合了,才容易有功效。因為它們都有相對需要付出的維護作業負荷。

.

12.pngFitNesse 架構(參考自www.fitnesse.org)

.

  1. 指的是我們持續維護的活文件系統(一個 Wiki Pages系統)

  2. 指的是委外廠商所開發的系統。

  3. 是讓我們可以客製化用來詮釋實例化表格的方式,以及要呼叫到的功能名稱的介面程式,稱為 Fixture.

中間核心的部分,分成上半段的 FIT(舊有的整合測試功能引擎) 及下半段的 SLIM(Simple List Invocation Method新開發的引擎),網站上有描述舊有的整合測試功能引擎 FIT因為複雜性較高,維護的Load 逐漸變大,才有新引擎的出現。

而你要做的工作,便是把文件寫在 Wiki Pages 上,然後把測試案例加進來,並運用指定 Fixture的方式來指定要測試的程式它的功能名稱,並預先把呼叫此功能的參數及預設回傳值設定在測試案例的表格裡。接著;就可以持續進行自動化驗收測試了(請參考http://www.fitnesse.org/ 的範例)。

.

IMG_1754

圖的上半部是一個填滿測試案例數據的表格,最後抬頭名稱有?號標註的是用來驗證的回傳值。

圖的下半部是一個 Fixture的範例。

.

所謂「簡化」意味著團隊一開始就應該採用一種剛好夠用(barely sufficient)的方法。

.

實例化之前一定要制定簡單化的守則

採用實例化需求之前的共識,團隊需要擁有「簡單化」的共識。因為文件這個東西,往往會因為撰寫人的追求完備性而慢慢的走向於越來越複雜的不歸路上。這是我推廣「實例化需求」時最常聽到的一句話,就是「我們的文件系統比你所展示的文件複雜太多了,如果再把測試的案例,還有那些表格加進來,那還得了 …」。是的,如果要實行實例化需求的活文件系統的話,首先要訂的策略就是盡量的維持簡單化。這一點,就好比維護單元測試的程式一樣,如果測試程式多到需要相當的維護負荷時,就有可能會產生喧賓奪主的情形,也就是維護測試程式的負荷要重於維護主程式的現象。這時候當然就應該要丟棄測試程式的時候了。為了要避免這種情形,簡單化就是最需要遵行的法則,才不會白忙一場。

.

結語

雖然大家都知道,要建立與委外廠商之間的共識才是重點。是的,建立互信是合作關係的基礎,但有趣的是,信任往往是由不信任開始的。第一次合作的廠商一定是建立在不信任之上,慢慢的由於越來越多的接觸,彼此開始產生了解而逐漸建立互信的立場,實例化需求可以成為互信的一個開始,過往的經驗裡,廠商往往在獲知你即將採用FitNesse驗收測試系統時,會主動的在自己的開發環境裡也建立這樣一個系統,並要求經常跟你的文件系統進行同步,這是一個負責的廠商往往會透過實例化需求的過程來建立與客戶之間的互信立場。因此實例化需求往往不只換來可靠的測試系統,更容易的是可以看出協力廠商的可信任度。

.

註1. 實例化需求 Specification by Example:How Successful Teams Deliver the Right Software

為 2012 年 JLOT 震撼獎的得獎作品,作者是 Gojko Adzic,為塞爾維亞人。

《實例化需求:團隊如何交付正確的軟體》是在世界各地調查了多個團隊軟體交付過程後的經驗總結。 它介紹了這些團隊如何在很短的週期內說明需求、開發軟體,並交付正確的、無缺陷的產品;為團隊在實施產生實體需求說明時使用的模式、想法和工件創建了一致的語言;展示了案例中的團隊用來實現產生實體需求說明原則的關鍵性實踐;並在案例分析部分展示了一些團隊實施產生實體需求說明的歷程。適合與專案管理、開發、測試、交付有關的人員閱讀。

註2. ATDD 所指的是驗收測試開發,一般所謂的 TDD 實際上可以加註為 UTDD. U 是 UNIT的意思,它明確的指向進行單元測試開發,但很少人這麼用。

Written by ruddyllee

2017 年 03 月 31 日 at 11:33:31

需求分布圖

leave a comment »

.

為什麼要看需求的分布呢?

因為要了解專案開發的人力、時間都用到那裡去了,是否把開發的主力都放對地方了呢?若要加快專案開發的速度,那些地方(需求)是最可以取捨的、影響又較少的地方。不只開發人員想知道,使用者更應該知道。

.

由需求的數量、開發時間及它在示意圖上的服務節點,可以看出專案開發的負荷及重點所在,以及它完成後將對使用者的影響。

.

1.jpg.

示意圖提供了使用者的種種行為場景,接著在針對示意圖,把各個需求放在它所服務的節點上,這樣就可以看出相對於使用者行為上開發團隊將要付出的努力所在了。當然也能拿來看出此次專案的開發重點(通常就是需求最多,最花時間的地方)。下面們就用範例來做說明,讓大家比較容易了解。

.

用一場演講來作範例

首先講師把演講的過程畫成示意圖,下面的範例是我在參加Agile Tour 2017所演講的題目: 讓英雄先救貓咪。 演講過程的示意圖如下,左邊是「涉及人」也就是來聽演講的學員,最右邊是「標的物」也就是做完演講之後,所產出的圖像紀錄。

.

2.jpg

讓英雄先救貓咪的演講場景圖示

.

這裡我們把演講的Slides當成需求,演講的過程當成描述使用者行為的場景,圖上打勾的符號表示會講到的 Slide, 打叉的是不會講到的 Slide(這是自己講課時的一種習慣,通常我們會先針對演講主題準備演講資料,最後才是針對演講的時間長短進行刪刪減減,也就是那一堆打叉的slide囉,我的習慣是把它留給學員自己參考用而不做刪除,目的是針對演講主題的完整性而不是演講時間的限制)

花較多時間講的正是講師所想闡述的重點 

我們把slide數當成需求,由需求在示意圖上各個節點的分布數量,便可以一眼望穿每個節點個別需要多少使用者故事才足以完成這項服務(功能)。也能藉著視覺化看出專案服務客戶在進行各種操作行為上的負荷(完成此項需求,工程師所需要投入的開發時間),我們也可以依據它來進行價值判斷,考慮是不是值得做這麼大或是應該再加重投資開發某項功能的比例。因此,需求分布圖足以讓我們看見專案在開發上各個需求所占的比重大小。

.

3.jpg看見專案負荷的比重

.

專案開始之初  — 看見全貌

專案開始之初首要在先看見全貌,而「需求分布圖」則是可以在需求示意圖完成後用來分析專案開發的重點所在。我們可以拿來作為投資報酬率的評估用,依據開發功能、數量在某一個服務節點上是否做了過度的投資的統計依據。它可以讓我們再一次客觀的審視各個使用者故事在某一個情境上的負荷及相對的價值。

.

結語

需求分布圖的依據是使用者的場景示意圖,一切以使用者為主軸。它的效用就好必影響地圖一般,可以看見工程師開發某一個功能相對於它對使用者的影響路徑所在,可以用來分析用。而需求分布圖看的則是全貌,展示專案開發在需求負荷下的分布狀態,我們可以拿來評估專案的目標跟預期的計畫重點是否一致,有沒有做錯重點、把時間及開發功能投資錯了地方。

它也是我上課時的依據,我會把課程先做成情境的描述示意圖(它就是整個演講的過程),然後把如何協助講課的 Slide當成需求(凡需求就要區分重要性,也就是Must have/ Should have/ Could have/ Won’t have的區分),它是我拿來對演講時間有限的清況下,這時候;我只要斟酌這張投影片的重要性,再決定要不要放棄不講(也就是在右上角標示 W: won’t have 符號)。

 

參考: 「讓英雄先救貓咪」的演講投影片

https://1drv.ms/f/s!AtlpfGB0RrJoh7sK0CvFHArPKK95qA

 

Written by ruddyllee

2017 年 03 月 24 日 at 11:46:42

引導看板 Facilitated Kanban

leave a comment »

前言

  • 已身.png孔子《論語·子路》,「以身作則」“其身正,不令而行;其身不正,雖令不從。”
  • 「潛移默化」,形容人的思想、性格或習慣受到影響, 不知不覺中起了變化。

.

引導 Facilitation
我教敏捷開發課程已經超過15個年頭了,這麼多年來我一直相信敏捷是一種文化,他可以深深的改變一個團隊,甚至是一個人的家庭文化,因此我很早就在家中實施敏捷教育了。為了讓孩子們也能像我一樣熱衷於追求學問,我總是以身作則;經常在餐桌上擺滿了書籍,表現得用功而認真的埋首於書寫或閱讀中,企圖用這種行為來感化孩子們,深深的希望這麼作能影響到孩子們的求學之路,有時候;我只要聽到孩子們下樓或要進到餐廳的聲音時,就會刻意的把書本打開來,裝作很用功的在研讀中,因此家中的餐桌上,總是長期的堆滿了各式各樣的書籍,嚴然就是一副圖書館的樣子,目的就為了形成孩子們愛讀書的風氣(真是用心良苦啊!)。

但這麼多年過去了(十幾年了,孩子們都超過30歲了),家中的餐桌上依然只有我的書籍,它們依然經常凌亂的躺在餐桌上,卻從來就沒見過孩子們這麼作過。所以我實在不相信以身作則就能夠有效的改變風氣。

05.png.

一直到我遇見了引導,才晃然大悟;其實,除了以身作則之外還需要依靠引導的方式,或許這才是循循善誘吧!(建議那些也想要運用以身作則,來感化孩子們的家長)你必需採用適當的引導方式,才能讓孩子們朝向你所期望的方向去前進。而在工作上我們也經常會碰到一些團隊表現的與你所期望的有相當差距的情形,這時候就是你該思考如何加強團隊引導的時機了。

這裡我嘗試了一種可以運用看板視覺化的力量來協助團隊協作的工具,我稱之為「引導看板」,效果好極了!每當你遇到要主持一些需要較多引導、較抽象的工作坊或會議時就可以自行先設計一個引導看板,讓與會人員一眼就知道今天的會議程序以及目前已有的成果,迅速移除那些讓参加者因爲不熟悉所造成的疑惑而造成的無為現象。它同時也能幫助你更有信心的去引導團隊並毫不遺漏的主持好會議,歡迎嘗試看看。

 .

運用看板來達成引導的目的 – 引導看板

.

引導看板」;一種用來持續顯示討論成果,以作為後續討論依據用的視覺性看板。

 . { 範例參考:  Scrum 四大會議的引導看板,放在文章後面。(其實;越是難以捉摸、越是高抽象度的會議越適合採用「引導看板」來召開,也能越見功效,例如:召開創建使用者故事地圖會議或可稱為Workshop 就屬於較高創意、十分抽象的會議類型,相當適合採用。目前只要是找我指導的會議,我一定會採用引導看板來進行,務必讓参與者迅速進入會議情境,充分的運用視覺化來完成會議紀錄。 )}

.

「引導看板」的目的是用來協助、組織召開複雜性高或曠日費時的會議或工作坊時所可以採用的一種視覺化看板。

.

看板天生就是作來引導用的

因為看板就是設計來顯示、管理工作流程的,因此十分適合拿來進行引導作業。而引導看板是紀錄成果,指引向未來的利器,它不同於一般的看板,一般看板在上面移動的是一個個的工作項目。但「引導看板」的目的是累積成果,持續讓大家一直看得到結論,並以此做為後續討論的依據,因此它顯示的是目前進行到的流程(欄位)以及已經累積下來的討論成果。如下面的創見使用者地圖的看板,紅色倒三角()一看便知是目前進行到的流程位置,也就是進行到第四個欄位(繪製示意圖),明顯的;示意圖不可能繪製在看板內,需要再運用其他的空間進一步產出(最後結果,則可以用照相的方式放上來)。但運用看板做引導的真正目的是消彌大家對程序上的疑慮,讓按部就班成為大家群策群力的依據,讓團隊智慧足以充分發揮。

.

下面是一個"創建使用者故事地圖"的步驟,它隱含"靜態頭腦風暴"的工作坊及會議(這是一個會讓你站到腳痠的會議)。首先;召開的步驟是:

20.png

21.png

.

召開的過程中,前面階段所得到的產出物都是為了用來做為接下來討論的依據。所以必須明確的紀錄在隨時可以看見的地方,以便於接下來的討論。所以十分適合採用看板來視覺化過程。你可以解讀下面的"創建使用者故事地圖看板"為:

  • 目前已經進行到: 第四個欄位,馬上要作畫出使用者操作的情境示意圖。
  • 第三個欄位: 明顯的標示了主要用戶與次要用戶的特性指標。
  • 第二個欄位: 標示了此專案對客戶及公司的利益所在。
  • 第一個欄位: 說明了參與討論者所扮演的角色。

.

14.png

.

所有程序一目了然,可以讓人增加穩定感並提升參與度

針對創建使用者故事地圖製作引導看板的目的,是由於「創建使用者故事地圖」是一種抽象度很高的活動,當召開時我們經常會邀請35名專家來參與這種啟發式的(頭腦風暴)討論。所以與會的人物經常是互不相識的(並且經常是第一次參加這種創意式會議),由於大家都不熟悉,這會讓會議的進行增加許多的不確定性,再加上對會議的成敗的疑惑,因此常常需要更多的暖身活動才能上軌道。所以我才決定運用這種可視化的技巧,讓與會者完全看到會議的步驟,藉以讓大家擁有較高的穩定性,用此拿來做頭腦風暴前提升穩定度的依據。

 

上圖中的看板,除了有明確的陳列出各個工作步驟之外,更把每個步驟的執行成果都記錄在該步驟的欄位中,讓參與會議的成員可以透過持續看見的效果,以此做為後續討論的明確依據,它可以讓會議不容易失焦,而且大家都能持續看到全貌,因此更能專注地去完成討論的目標。

.

devops看板_1.png

.

【 創建引導看板的步驟 】

一、繪製(會議程序的)價值流程圖 — 視覺化你的流程。

二、在最前面加入要達成的目標及說明 — 明確的說明所要達成的目標。

三、保留足夠空間做紀錄用 — 將紀錄用便利貼或其他方式陳列出來。

四、在看板的下方加上欄位說明 ,運用WIP來限制討論時間– 規範流程。

.

結論

製作用戶故事地圖的創建會議,實質上就是一種「設計思考」Design Thinking 的過程。成果是累加出來的,後面的討論往往是依據請面的線索所做的推論。這種形式的會議其實很多,若能夠善用可視化的呈現方式,則對創建的成果將會有著明顯的幫助。此時能夠採用引導看板來做呈現,除了可以大幅增加會議的明確度,又可以讓與會者迅速進入狀況外,還能適當的紀錄下所有的成果(明確的展示了創建使用者故事地圖的會議結論),具有圖像視覺化會議的成效。

.

{你其實可以更明確一點,之所以要保持抽象,目的是為了維持包容性,而再明確一點的目的,則是為了讓流程能夠順利地進行下去。}

— 運用看板進行引導

.

範例參考 】 – 展示會議、計畫會議、回顧會議。

Scrum 的 review meeting 的「引導看板」

明確的說明了即將有幾個展示、是由哪位成員所完成的,以及目前進行到哪裡。更有效的部分是,它可以讓來參與展示會議的使用者都能夠很清楚何時、何刻輪到他必須發表意見,應該要做較大還是較小的回饋,如此可以更順利的獲得客戶的回饋。

20

.

1.png

.

2

.

devops看板.png每日工作看板需與真實的工作流程相符(僅供參考)

.

Written by ruddyllee

2017 年 02 月 20 日 at 22:33:03

如何創建使用者故事地圖看板

leave a comment »

.

看板引導.png

.

08.png

用戶故事地圖看板 – 避免遺漏

 

.

01.png

.

02.png

.

04.png

.

05.png

.

05

.

07.png

.

08.png

.

09.png

.

10.png

.

11.png

.

12.png

.

13.png

.

14.png

.

15.png.

16.png

.

21.png

.

結語

看板與生俱有強大的引導能力。不止於在站立會議時能迅速的顯示更新資訊的來龍去脈,若能善用它的視覺化能力,尤其在團隊的活動上,運用看板來進行引導,可以讓模糊不清的工作步驟容易按部就班的進行,更能讓團隊成員發揮智慧,預先盤算作為下一步的行動依據,讓人變得更聰明。運用看板進行引導工作的優點:

  • 讓模糊不清的工作步驟變得清晰而明確。

  • 讓團隊智慧得以更容易發揮。

  • 便於控制會議時間(用時間來當作 WIP的設限)。

  • 不容易遺漏必要的注意事項。

.

參考:

  1. 用戶故事地圖,   by Jeff Patton
  2. 產品敏捷開發之——創用戶故事地圖,    https://read01.com/o4k53z.html
  3. Google 創投認證, by  傑克.納普, 約翰.澤拉斯基, 布雷登.柯維茲.

Written by ruddyllee

2017 年 02 月 15 日 at 10:37:38

如何培養一個強大的開發團隊?

leave a comment »

.

定義: 一個能夠作出超過他們開發能力的團隊,謂之強大的開發團隊。

.

08.png

敏捷是一種學習型的組織

.

「學習」是最重要的事

要讓一個團隊作超過他們能力所能作的事,其實一點也不難,就是要讓他們一天比一天還要強大,也就是說今天的團隊比昨天還強,明天比今天還強,說穿了,就是要能夠持續成長的意思。而「成長」的方法當然就是透過「學習」了。因此只要讓團隊持續的學習,自然能夠ㄧ天強過一天,經常做到他們原本所作不到的事了。帶領這樣的一個團隊,就要像照顧孩子們學習成長一樣,盡力的去屏除任何會影響他們學習成長的阻礙。並透過引導反思的方式,來落實延伸啟發他們「」的範圍及效果。

.

※    成就強大開發團隊的三個重要原則:

  1. 在敏捷開發的各個活動中注入學習的要素,以做到「增強學習」。
  2. 運用引導的技巧來協助團隊達到「自我管理」。
  3. 結合學習跟引導,讓團隊透過引導來促發延伸學習

.

精實原則:「增強學習」讓團隊更穩定

敏捷是一種學習型的組織(註2),它重度的依靠學習來讓團隊持續成長,尤其是當工程師處在專注於學習的時候,通常也會擁有最高的穩定性,可以產出好的程式,做出好的產品。相對地;當整個團隊都處於高度學習的時候,也正是他們呈現最佳穩定度的時候,這是任何學習型組織都最為珍惜的一刻。至於;要如何培養出一個強大的開發團隊,正是要讓他們能夠持續的維持在這樣的氛圍之下工作,並能夠適度的得到回饋以持續的處在成長的喜悅中,後面所提到的「適度的得到回饋」,則是維持這種高度產出的氛圍下,所不可缺乏的成功要素之一,這一點在創新團隊的組織比較容易實現,也就是給予適當的激勵,這會讓學習具有正面的意義,能更為持久。而在傳統的多階層的古老企業之下,就比較難以實現了,這正是創新團隊在開發上的優勢。

.

06.png

.

引導是為了讓團隊自我管理所引出來的必要技巧

引導的重點在促發團隊產出集體智慧的結晶,使得團隊得以結合眾人的力量,達成個人難以觸及的更高的成就。這個字來自拉丁語,Facil 指的是”容易的”意思。引導的字面意思是讓團隊工作流程變得簡便。但運用在軟體開發上,則是為了避免團體在協同的開發作業上犯了不小心的錯誤,所以引導便成了,指引團隊達成一種正確決策的行為的技巧。若與我們的目標(如何培養一個強大的開發團隊?) 相結合的話,便成為在開發活動中運用引導的技巧來加強團隊學習的成果。

》用來成就一個強大的開發團隊的基本技巧 – 運用引導來引發團隊的學習及促進學習的深度

站立會議中的學習

SCRUM對站立會議的基本要求,成員必須敘述三件事:

  1. 從昨天到現在做了什麼隊團隊有貢獻的事?
  2. 今天準備做什麼?
  3. 是否有遭遇任何阻礙你完成工作的困難事?

SCRUM講了規則卻沒有說明如何應對,怪不得SCRUM稱自己是一種架構Framework而非方法。所以當團隊成員述說我昨天完成了這個工作(Task)時,主持站立會議的Scrum Master應該如何應對呢?

今天我們來假設目標是促進學習的話,則Scrum Master要如何運用引導的技巧來增強學習呢? 反過來思考,假設是自己家裡的孩子拿著聯絡簿要我們確認他已經做完功課了,跑來要求家長簽名的時候,你會怎麼做呢? 你最可能會做的是,用命令的口氣跟孩子們說:「拿過來讓我看一下!」,然後你可能會要求,「來,背這一段我聽聽!」這是驗證的方式,也就確認定義完成(Definition of Done)的基本作法,看起來務實,但其實這麼作對孩子們的學習內容實在沒有多大幫助。假使;你倒過來問孩子們: 你花了多少時間來作這個作業? 這個作業是難還是容易? 從這個作業裡你學到了什麼? 朝著未來的目標及收穫來引導延伸他們的思維前進,這樣子的引導動作,則會把孩子學習的成果更具體化,讓他的思維更能延伸出去,產生較多的聯想。這是依據Knapp 1992的理論說明何謂真正的學習,也就到達足以學以致用的地步。

.

12.png

由情境的「」到經驗,促成引導反思以至於延伸啟發的「

.

換句話說:表面的知與經過實作後的知,需要進一步衍化成足以作判斷的知,再透過引導反思,方足以成為延伸啟發後的「知識」。

.

所以Scrum Master 應該在團隊成員述說自己完成了某個工作時,接著詢問有關這個工作的難易度,然後詢問獲得了怎樣的經驗,並引導他反思再做一次,或改變環境時他會如何改變處裡的方式,盡力去延伸啟發這個「知」。使學習得以真正的落實。(你或許會反問我這麼作會讓站立會議變的好長好久,這麼作值得嗎? 如果有所疑慮,就偶爾才挑一個來試做看看,看你的團隊反應如何再作調整吧!)

.

13.png

藉由站立會議批判完成工作的指導與引導將決定這個工作體驗的目標與發展的意義大小

.

結語

運用引導來促發及落實學習,讓所獲得的知識能夠持久不忘! 如 Knapp(註 1)所言,表面的知隨著時間拉長,很快就會被遺忘,無法持久。只有透過延伸啟發的知才較能持久,而得以學以致用。工程師撰寫程式,其實從頭到尾就是一種學習的過程,只有程式設計人員真正學會了這一門技術,才可能把程式真正的寫好,因此落實工程師的學習深度,應該是讓專案成功的首要之道。工程師片段的完成程式,往往需要等到組合後才能將片段的知識進行會整,容易像學校教育一般停留在表面與操作之間的主「知」,所以我們經常進行「引導反思」讓片段的知識得以延伸與發想,則可能有超過預期的收獲(註3.學習效果)。因此,當工程師說「我完成了一個Task」的時候,我們應該即刻判斷,是否要花一點時間來進行「引導反思」,讓知識得以歸檔,管理不易遺失。或是可以更進一步的選擇作更大型的code reviw來落實學習呢?!對ㄧ個學習型的組織而言,這可能是最重要的決定,它攸關著辛苦獲得的知識是否能夠落實的保存下來,並得以發揮。

.

 

經驗必需要再經過 process 後,才可能轉變成有價值的知識。

 

.

還有一件事我忘了說,那就是讓團隊成員感覺在這裡是幸福的 Happiness,這是絕招(註4)。效果如下:

%e5%a5%bd%e7%9a%84%e9%96%8b%e7%99%bc%e5%9c%98%e9%9a%8a

 

.

註 1. Knapp 1992,Lasting Lesson: A Teacher’s Guide to Reflecting on Experience

參考: https://www.amazon.com/Lasting-Lessons-Teachers-Reflecting-Experience/dp/1880785064

註 2. R. Lessem(1990)的研究指出:二十一世紀在全球企業競爭風潮之下,未來的組織管理主流將是「發展型管理」,將來組織惟一持久的優勢是具備比競爭對手學習得更快的能力,是以二十一世紀可預見是「學習型組織」(learning organization)引領風潮的時代! (R. Lessem ,1990  Developmental Management. Blackwell, Oxford.)

註 3. Knapp 稱引導反思為一種知的管理。能促成實踐、反思及延伸啟發。

註 4.  by: Sonja Lyubomirsky,2005

註 5. 《引導反思的第一本書 》, 吳兆田著.

Written by ruddyllee

2017 年 02 月 13 日 at 15:59:32