Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 六月 2016

如何設計看板 –交互式看板圖

leave a comment »

.

「交互式看板圖」是拿來協助設計看板用的設計工具。

.

如果你看過我寫的「精實開發與看板方法」的話,應該對設計看板的起手勢很清楚了,請把這一段文章當成要設計看板前的進階補充。以下是「交互式看板圖」的製作步驟。交互式看板圖的設計目的是針對傳統看板在設計時,少了留下明確的欄位製作說明,而容易造成看的人去猜測當初設計者到底是什麼用意的現象。為了克服這一點,才引發我設計交互圖示的想法,也就是把產出物及簡單規範都加了進來(產出物,這是一個有趣的概念,我的出發點本來是想加入交互interactive互動式的行為,也就是描述它是在什麼樣的情形之下來進行互動的,但不知不覺的就很自然的變成了輸出入的產出物了)。

.

00 交互式看板結構圖

交互式看板的結構圖示

.

 

【 製作步驟 】

步驟一、把現有的流程畫出來 –視覺化,畫出看板的雛形。
這是務實的作法,不要急著改善任何東西,先照實的畫出目前的工作流程,這個動作叫做「看見現況」。然後一定要把工時標上去,這叫「看見浪費」,請確實的回顧一下自己目前的工作效能。

 

步驟二、區分整個流程的輸入及輸出部份,把它寫在看板的上面,也就成了交互式看板的中間層。
拿寫程式來作比喻,我們在撰寫功能程式的時候,第一件事便是要清楚的界定輸出入的各個參數。一定要先隔離功能的邏輯部份讓它變成黑盒子似的盡量抽象。抽象可以讓你看到更多,讓你減少改來去的次數(這是年輕工程師往往在沒有規劃之下,就太快開始coding時,造成大量返工而大量浪費時間的的地方,也就是沒想清楚就開工了,然後落入改來改去的迷陣中,而不知不覺的就把簡單的功能變複雜了)。

 

步驟三、開始針對各個欄位,依照它們的目的來制定規範(也就是最上面的說明層)。
從簡單的地方開始,用三言二語的簡單描述來敘述規則,用它來說明每個欄位的基本定義。目的是讓團隊的成員或後來才加入的成員,都能清楚看板設計在最初設計時的用意。同時它也能成為下次修改時的依據。

 

讓Wip的設定值有所依據
剛開始接觸看板的學員, 通常都不知道如何來設定Wip值。為此我經常會收到求救的email,信裡面附上看板的照片,然後求教該從那裡著手設定WIP值呢? 一般,我會先問開發團隊的品質如何?(很少聽到有滿意的答案的。)所以接著我就會要求把看板上負責檢核的欄位的 WIP值直接設定成【WIP= 1 】,先不要管其他的欄位,就只設定檢核的欄位的WIP值,試試看結果會如何?而且要求他們要忍耐三天以上,才能通過開會的方式,適度的放寬這個數值。你猜結果會怎麼樣呢?!歡迎嚐試看看。

.

我把學員不知道如何設定WIP值,

歸咎於沒有可以反覆推敲的說明來作為依據。

.

{ WIP:Work In Progress半成品。所指的是尚未作完全的工作,也就是沒有跑完所有流程的工作。當 WIP值越大時,即表示團隊的開發效能越差,也就是越浪費的意思。 }

.

由於每個欄位都會直接影響到執行流程時的效能,所以尋求正確的WIP值來作為調整的依據至為重要,因此交互式看板圖示才會刻意設計一段簡約的說明來規範它。這段規範正是用來教導你如何設定Wip值的依據。不論你是把它調大還是調小,只要能針對規範所想達成的目的去設就可以了(一旦你開始採用交互式看板來設計看板時,那種不知道為何或如何設定Wip值的疑惑,自然就不會產生了,因為你已經製定了簡單的規範,它能告訴你怎麼來定Wip值了)。

.

範例說明: 下面是在一般課程結束時通常都會有的問答時間,而我喜歡把它作成看板,上一篇文章裡沒有仔細的說明,現在補上,我稱它為「Q&A 看板」。對學員們解說看板,通常我會把欄位規則,都放在每個欄位裡面,才來解釋給學員聽,讓學員的視覺有所依據。但一旦採用了交互看板的設計圖示,則說明就可以放到相對應產出物或互動的區域作統一的描述,它可以讓說明變得更完整。說明如下:

.

Screenshot_20160628-100332~2

.

欄位一、「問題」欄位WIP=10,

是用來設限整個Q&A區段的時間,當講師預計回答一個問題需要2分鐘的話,則WIP設10就等於設定整個Q&A問答的時間將會在20分鐘內結束。

《規則》,預計回答一個問題需要2分鐘,希望能夠回答盡量多的問題。

(因此,我們便可以依靠調整WIP的大小,就能控制Q&A的時間了)

.

欄位二、「分析」欄位WIP=3,

意思是最多可以同時綜合幾個類似的問題一起同時回答的上限值。

《規則》,允許同時回答類似問題的數目設為3,大於3的時候會害怕太凌亂無序。因此原則是為了減少一下回答問題的時間,並要求能夠保持清晰而不致於凌亂。

.

欄位三、「回答」欄位WIP=1,

意思是明確的要求教師在回答問題時以2分鐘為上限。

《規則》,為了控制整個Q&A的時間,所以希望教師在回答問題時內有時間的限制。

.

欄位四、「確認」欄位WIP=3,

意思是最多可以同時有三個問題可以進行確認的動作(通常就是要求提問題的人,點頭識意對剛剛的回答是否滿意)。

《規則》,確認欄位必須與分析欄位相對襯,綜合了三個問題一起回答,當然確認的問題數也要設為三了。

.

》交互式看板圖的說明部份,正是希望把欄位設定的規則寫在「說明」的部份,讓未來在需要調整Wip數值時知道要依據些什麼。

 .

IMG_20160630_085027~3

{用中文直式的寫法來撰寫欄位說明,很有趣。 }

.

小結

復習一下;看板方法的基本設計步驟: 一、視覺化即有流程. 二、設定WIP值. 三、 管理流程. 而「交互式看板圖」則為一、視覺化即有流程。 二、針對流程寫出對應它的輸出入產物。 三、在說明欄寫入各個欄位的規範,並依據規範設定WIP值。

交互式看板圖,目的是在協助設計看板時寫下欄位的規範以協助觀看者進行「解讀」看板的動作,同時也能協助你作為設定WIP值時的參考依據。它強調的是說明與規範,它能讓看板本身更容易被了解,希望你喜歡它。

 

 

 

 

 

廣告

Written by ruddyllee

2016 年 06 月 30 日 at 22:58:00

張貼於未分類

用看板來檢視你準備好了沒?

leave a comment »

看板一點也不難,難的是「解讀」,是讓看了的人都有一致的解讀。

.

IMG_20160627_022628~2

一個典型的開發用看板,上半部是產出物。

 

.

下半部是一個典型的軟體開發的看板(尚未設定wip值)。而上半部則是對應到下面欄位(columns)的產出物,或是你可以說它們是交互運作下的產物。接下來我要採用 interactive diagram的觀念,將看板區分成上、中、下三個區塊。最下面是我們的看板,中間部份是interactive之下的產出物,最上面則是對照交互運作內容的說明。

.

IMG_20160627_061127~2

上半部是輸出入產出物對照的詳細說明,下半部則是軟體開發的基本看板。

.

解讀看板

給看板加上說明,這是一般設計看板的時候最容易忽略的一件事。大家總以為看板夠簡單了,很容易弄清楚,所以就忽略了對它作詳細的說明,讓看得人都能有共同的認知。其實任何「看板」都有它隱藏的規則,團隊在運作之初,一定要把規範說清楚,尤其是有新人來報到的時候。我的作法是如上圖的方式,在看板上面加上針對交互產出物的對照說明,讓看著看板的人知道輸入及輸出是什麼。這是一般設計看板的時候最容易忽略的一件事。日常的看板將只會有下半部。但設計看板之初就必須保留這種交互設計的圖示,它可以更有效的說明我們到底在作什麼(當然它也需要持續的修正)。

.

為何需要交互圖示

這樣的圖示讓看板變成了三部份,上面是站立會議時看不到的「說明」部份,下面則是可以作為日常執行任務的看板,中間則是二者之間的交互關係。它能用來作什麼呢?

@ 它提供了看板所缺少的輸出入是否備妥的前置說明。

@ 另一點是它提供直接說明每個欄位的規則。簡單的規範能夠讓認知更一致。

      千萬不要假設大家一起站在看板前面,看著同一塊板子開會,就都能擁有同樣的認知了,當然不可能。過多的假設往往是造成團隊認知不一致最大的罪魁禍首。其實只有透過溝通才能肯定認知的程度。

.

範例: Q&A 看板的交互圖示

下半部是問題看板,實際操作時只有這一部份。

中間部份是產出物:輸入是問題 Question,輸出是回答Answer.

上半部則是說明的部份,它說明了看板每個欄位的定義規則。

IMG_20160628_224855~2

 

實際上運作時的Q&A 看板

Screenshot_20160628-100332~2

 

 

在這裡,我嚐試了把看板延伸出設計的理念。主要是加入了I/O的輸出入元素,及一直困擾我的欄位規則說明。在旅行途中的圖示看板,都只能用餐廳桌上的紙巾來畫,難看又不準確,可是還蠻有意思的,但看不太清楚就是了,請大家多包涵。至於「問題看板」不知道是那位前輩先發明的,我好喜歡用它來作演示,給大家參考了。

.
 

Written by ruddyllee

2016 年 06 月 28 日 at 07:46:53

張貼於未分類

Agile Training Roadmap 的前置作業

leave a comment »

 

Roadmap的前置作業

 

                                          Scrum 顧問 Pattern

.

000 顧問模式_0

我想自己嚐試 run Scrum,可以嗎?怎麼作呢?

.

答案是,先作好準備工作。

首先讓我們來談一下Roadmap的前置訓練部份,他們分別是 訪談、Scrum 訓練及看板方法的訓練。它發生在我們即將運行的二個Sprint循環之前。

 

》訪
目的是彼此認識,知己知彼。對身為顧問的人而言,是為了與團隊主管或關鍵人物打開一道溝通之門,當然是為了後面所有的活動鋪路。重點在建立溝通管道,而成功之道是「至誠」。這個時候我通常會決定那些keyman是那些事件的負責人,他們應該在事件發生前先被知會與咨詢,而好的開始點則是「尊重」。

(一個成功的訪談,重點不在完成了什麼?就是為了默契而已。想進一步了解的話,可以參考薩提爾相關的訓練)

 

》Scrum的訓練
目的是在教授Scrum的架構,讓學員們俱有一致的敏捷認知。這一點至為重要,即便是整個組織有超過10000人以上的規模,務必讓大家都聽到同一個scrum講師的訓練課程,這一點真的太重要了!因為它將決定組織推行scrum的順利程度與效果。

為什麼我不用Scrum的認知,而採用「敏捷的認知」呢? 因為接下來所有的活動都必須依據人們對敏捷開發的認知來作為依據。團隊運作如果認知點不在同一條線上,自然會漸行漸遠了,這是百分之90的團隊,第一次實施Scrum時,會失敗的最大的原因。

.

第一次實施Scrum時,會失敗的最大的原因是團隊對敏捷的認知不一致。尤其是主管與團隊之間對scrum沒有共同的認知時更為嚴重。也就是我們常說的由上往下推行的敏捷開發才會成功,由下往上就太難達成了。

.

大量閱讀,用前人的心血結晶來補充經驗的不足

Scrum是基於經驗主義的。也就是實施時期你需要大量的協助,不論是會議實施義程或遇到狀況時如何作決策。務必這麼作: 反覆的,透過閱讀、觀看YouTube上的影片來告訴你別人是怎麼作的。積極學習可以縮短這一段時間的長短,成功之道是「愉快的心情」,因為愉悅的心情可以提升學習的效能。

.

 

》看板方法的訓練

實施看板方法能讓專案既務實又透明

運用看板的一個目的是透過視覺化的力量來看見特定流程的效能,然後在依據看到的結果,務實的思考如何進行改善。

 

視覺化帶來務實

很多時候我們都不會刻意去思考作這件事的效能到底如何?或許是懶,或許是不在意! 而很多時候,就是照著習慣去作而已。大部份人都是這樣的。但有趣的是,當我們能夠看見事情在執行過程上的種種浪費時,給你再作一次的時候大概作法就會改變了。因此如果你要改善工作或是生活上的效能,就必須跳脫這種選擇性的忽略方式,設法讓自己看見更多,效能自然就會改善更多了。

.

敏捷化就是要務實

我長期在作顧問的工作,有一條簡單的準則便是:「看到問題時立刻處理,處理時追根究底」。也就是說,遇到「問題」的時候絕對不能放過它,一定要去追出底層的原委。因為追出原委本來就是作顧問人的職責。如果我們看不見事情的真象,又如何能對症下藥呢。這樣的描述還真有一點「柯南的味道」,只是要作柯南還真是一件很累人的事,而作法和偵探比較起來則是恰恰好完全相反。通常我們會把追根的過程和結果讓大家都知道,這樣可以迅速的避開誤解,讓團隊或相關人員跟著我們一起看到問題的演進(會不會有人不認同呢?這是常有的事,此時,多少要靠訪談得到的基礎來支撐主管們的信心跟疑惑)。這種作法最好,也最可以迅速的撇清一些細微的躲在牆角的故事,但也不能每次都這麼作,因為這麼作的成本很高,你會浪費到許多人的資源,所以快捷是我的原則,一定要作到很快看到問題,迅速追查真象,然後讓當事人把原委講出來給我們聽(道聽途說是絕對找不出真象的)。有時候,在當事人講出來的同時,問題也解決一半了。

.

 

敏捷需要看得見,我們都說過的一句話:「早知道!」但是看板方法的目的,是希望我們能一直都知道。

.

看板可以作什麼?

看板方法可以設計的像功課表一樣,成為了你上課的依據。它也可以設計成標準作業流程SOP一樣,代表最標準、最快速的執行流程。但它的功能不止是這麼樣而已。而我每回顧問Scrum團隊為什麼都從看板開始呢?!一個重要的原因,便是希望能按部就班把那些始終沒進入狀況的,那些還沒上車的人士,一個一個拉上來。

 

 

 

 

 

 

Written by ruddyllee

2016 年 06 月 24 日 at 22:35:31

張貼於未分類

如何增加、減少DoR — 運用看板方法

leave a comment »

 提要

1. 什麼時機點需要增加DoR? (過濾需求是否備妥)
2. 什麼時機點需要減少DoR的動作?(避免浪費)
3. 在看板上要怎麼作?(看板如何控制流程)

.

前二篇文章一直圍繞著如何來檢查需求的資料是否備妥,也就是 DoR(Definition of Ready)的作法。現在則要來談一下,什麼時候應該要作DoR?及什麼時候則可以省略它。

.

需求很難拿捏是否Ready了?
DoR的出現是因為 Refinement meeting 的被高度關注。你可能會有一點疑惑,為什麼從前不去談它呢?難道從前它就不重要,一直到現在才開始變得重要了嗎? 當然不是的;「視覺化」抬頭是其中一個因素。另一個原因是因為敏捷開發在開始之初,擔心大家容易在這裡又會像傳統開發一樣把時間都花在作文件上了,會重犯了CMMI的老問題,因此刻意不作深入的描述。但近幾年尤其是對需求的控管變得越來越重要,而開發流程又受到新創團隊的MVP策略ㄙㄨㄛ影響,使得refinement meeting就越來越受到重視了。

.

宜減少DoR的時間
當專案的技術複雜度遠高於需求變化度的時候。工程師能盡快開始問題挖掘作業,則對專案的進展越是有幫助。反過來換個角度來看它;一個較大的組織,往往在運作的時候會有層層負責的現象,這種每個人各盡其職的結構是造成專案開發之所以「快不起來」的最基本原因(因為界面變多了,人們往往會認為自己已經作的夠多了,忘了要全面性的來看問題,因此就容易造成許多工作掉落一地,沒人去作。出問題時,大家都忙著在弄清楚是你該做還是我該做。對很需要快速回饋市場運作的專案,讓「運作扁平化」是一道管理者的功課。

宜增加DoR的時間
當專案的需求變化遠大於技術的挑戰性的時候。此時不宜讓工程師太快拿到問題,也就是增加用抽象解題的時間,讓問題的可能性更容易分晰的時候,也就是更明確的知道「需求」要些什麼的時候,再把工程人員請進來,這個時候對團隊戰力快速推進,才會有大幫助。

.

適度的運用看板來控制它
在product backlogs的欄位後面多加上【DoR】的欄位。當應該減少浪費在DoR的時間的時候,給它較大的WIP值(Work In Process)。相反的,當需要嚴格過濾需求的時候,把WIP訂小一點。

.

》什麼時候可以不用有 DoR的欄位呢?

 

即便是完全在同一個單位裡運作DoR還是很難省略,維護的工作也是如此,不作DoR就好似瞎子摸象一般,對問題大部份都用猜的來作探討。(這一點大家都很習慣了XD)。但在團隊運作良好,專案開始漸上軌道的時候,哈哈!一種可有可無的現象便會應運而生,正是可以省去DoR的時機來了。

 

小結

我的團隊需要DoR嗎?

》正確的問法應該是:這個專案的DoR需要重視到什麼程度?

 

 

 

 

 

Written by ruddyllee

2016 年 06 月 22 日 at 23:21:44

張貼於未分類

Tagged with ,

Definition of Ready: 工程師要學會如何講好故事

with one comment

大家都認為,弄清楚需求、講好使用者故事,是PO的責任(因為Scrum 是這麼說的)。但我們也都知道如果對工作,沒有深入的了解,是絕對無法把事情作好的,因此工程師一定要比誰都更了解需求。也就是比誰都更會講故事  — 軟體開發是一種工藝。

 

(會講故事,所指的是對劇本也就是使用者故事的描述及場景深度的了解,而且能表達的出來。當然,並不是一定要真的強迫工程師在大家面前說故事。其實真正說出來比空想的要好上許多,只是太浪費時間了。但通常我會透過跟開發團隊坐下來以比較輕鬆、非正式的聊天方式《用問答的方式》,設法激發他們進行超過Scrum基本會議的討論。當然,要不要這麼作完全視團隊所面臨的問題了,基本上抉擇就是會不會太浪費時間,這是底線。至於為什麼要作超過Scrum規範的討論呢? 理由是追求更「敏捷」)

.

重點:

* Scrum 遇到需求糢糊,不知從何下手的時候,怎麼辦?
* 讓工程師們看著影響地圖impact mapping說故事。

 

Scrum 對需求糢糊,不知從何下手的時候,該怎麼辦呢?
一個好的作法是透過一種稱為「集思廣義」的作法(很流行的作法,看起來也很客觀,可以治標,至於該不該這麼作?就要視團隊的狀況而定囉!)。首先,尋找有經驗的專家學者二至三名,然後讓他們和需求的相關人員共聚一堂一起來發覺、討論需求。大家一起透過腦力風暴的方式產出許多使用者故事來描述需求。接著,運用「使用者故事地圖」user story mapping 將需求階層式巨觀的大架構(big picture)給呈現出來,並以此作為需求的骨架。最後,再依照著PO所訂的使用者故事地圖的優先順序,逐一的將需求放進Sprint中來進行開發的作業,讓它們成為每個Sprint的開發目標。用這種方式來找到較明確的需求,也就是透過階層化的方式讓需求依大小及先後順序更明朗化,透過看見需求的共同目標來讓問題變得更容易解決些。

 

一些疑惑:

? 真的能找到厲害的專家來協助嗎?值得嗎?還是找曾經作過的長官來參與就ok了?(千萬不要和直屬長官合作,說來話長XD)
? 應該產出多少張需求呢?200、300還是400張。一張使用者地圖就夠了嗎?
? 排成使用者故事地圖了。但是需求,還是覺得很糢糊?

 

》看起來似乎這麼作便能解題,但是你的心裡一定不免有一些疑惑,這樣的處理方法之下,我們到底作對了多少?又作錯了多少?怎麼作才對呢?

 

其實,真正的關鍵是出在治本或是治標的問題上頭。

上面的方法理想化了一點,它是治標之道,基本上可以解決問題,只要能專注的去執行它便會有效果的。真正值得你關注的,應該是你負責進行開發作業的工程師,他對需求的了解程度才是重點,解決了這個問題才是真正的治本!

 

你看見了嗎!工程師也看見了嗎?
需求必經之路就是討論的過程,唯有透過討論來取得溝通上的共識,才可能開始開發的作業。而談到溝通的時候,說故事則可能是最佳的溝通方式之一,所以敏捷開發以使用者故事的方式來描述需求。但工程師很少說故事的(他們通常沒經過太久的討論就迫不及待的直接將使用者故事breakdown 成Task了,而且還是以真正的時間小時或天來作估算,至於什麼是故事點story point?工程師總是認為它太抽象了,好像沒什麼作用?!還是直接用小時來作估算比較實用,如果你這麼作了,那真是可惜,它破壞了敏捷對需求的不確定解決之道,也就是只作相對估算,而不作絕對性的猜測)。要對如何來維持需求自動調整的素養,往往是敏捷開發的一個基礎課題,是一般工程師在開始實行敏捷化時較不容易接受的原因。多花一點時間來作訓練是值得的,通常最適宜的訓練時機點是refinement meeting的所謂的前置作業時期。

 聆聽負責開發的工程師描述還沒開發但預備進行開發工作的作法「工程師說故事」是一種好的需求探討與協作(聽眾的回饋是一大重點,千萬別把它稱作是工作報告,那就太waterfall了)。

.

我還在找怎麼怎麼稱呼它會比較合適的名稱,就先叫它"工程師說故事"吧XXD。

.

但問題是,大部份的工程師都不擅長說故事。如果連需求都描述不好,又如何能開發出符合需求的好產品呢?

.

工程師能好好的描述需求的時候,才可能真正的解決問題
講故事太太重要了,尤其是講到讓別人可以感同身受的時候,這就成功的達到了溝通的最高境界。那些成名或成功的電影製作也就是這麼回事。從原著劇本到改編劇本,然後到每個演員的過場劇本,它們都有著相同一致的目標,就是感動你我。只要我們受到感動了,它也就成功了。要知道如果將故事講得凌亂無序,真正的需求又怎能浮現出它的輪廓來,目標也才可能逐漸的變為清晰而可見了。

.

全力以赴是唯一的選項           — 飛越奇蹟 Eddie the Eagle.

.

老闆老以為產品沒作好時,最難過的人是他。其實「掉東西的人,比送東西的人還要難過」。工程師接到任務在寫程式的時候,只有會不會的問題,很少有人會故意偷斤減兩的,每次都一定是全力以赴的!要知道,開發人員只要看到需求下來,總是立刻就用盡全力來撰寫程式的,也不知浪費了多少個深夜的好眠,就為了完成任務。但產品究竟是為什麼還會有那麼多問題呢? 答案是,因為一開始就沒搞得很清楚啊?!(要知道,在開發產品的時候,正確的方向,其實比速度更重要太多了)

.

DoR 就是開始開發動作時的底限
用「問五個W」的方式作開始很直覺也很直接,是很好的作法。但如果能採用impact mapping的方式,讓工程師來看圖說故事的話,那就更棒了。原因是,工程師可以依據影響地圖的路徑開始作故事的描述。而聽眾也可以看到它上、下有關係物件的陳列,再來聽故事的說明時,自然就清楚多了。

.

1_post-2

小結:

讓工程師們看著影響地圖 Impact mapping說故事!

需求開發上的工具不多,較有名的有 Jeff Patton的「使用者故事地圖」,再來便是 Zojko的「影響地圖」了。許多人都認為二者十分相似,運用起來應該是二者選擇其一的抉擇問題,但實際上它們是非常適合相結合的。使用者故事地圖能讓我們看見需求的 whole pictures,而影響地圖則可以讓工程師看見業務目標所對應到的開發功能,並依照影響路徑來說故事。二者缺一則「對需求到底準備就緒了嗎?」就不容易弄清楚了,也就不容易作到治根或治本之道了。(請注意,impact mapping的運用方式一定是部份的。只有針對重要的、複雜的功能才有必要花這個時間)

.

DoR: Definition of Ready 需求是否備妥的定義
DoD: Definition of Done 完成的定義

.

DoR是敏捷開發的大門,DoD則是Sprint成果的關鍵。
DoR的目的其實是為了DoD.它決定了團隊是否能順暢開啟Sprint衝刺速度的關鍵。但它太抽象了,不但沒個準則又要讓還沒開始開發作業的工程師來決定需求的資料是否備妥了,還真難!因此,每當有負責的工程師把一長串的使用者故事製作成excel表格用來確認DoR的項目是否備妥時,我就會有一種帶他們使用Waterfall的罪惡感。在敏捷開發中很少提到DoR的,正是它太容易走叉了,如果因此而落入傳統的開發方式,則不如還是不要好了。這一點在組織越龐大,分工越細的地方越容易發生,不得不時時警惕!

 

正是為此我才會致力於提倡讓「工程師說故事」這個作法。想用抽象化的故事描述來克服未來的、那些不確定性的因素,企圖在抽象轉向明確化之間先行解題。這裡「解題」的意思是指先用完整、抽象化的產品敘述來描朔產品的雛形,用它來取代看見需求直接就Coding下去,太快明確化的弊端。讓工程師在需求探討的時候先抽象化的進行解題的思維,就此加深對需求較為全面性的了解,而不是一如以往的,一味的用嚐試錯誤的方式進行開發。

 

 

 

 

Written by ruddyllee

2016 年 06 月 18 日 at 14:13:02

張貼於未分類

施行「敏捷開發」要從那裡開始?

leave a comment »

這是一系列文章的開始,由於經常被新的客戶問道,您作顧問這麼多年一定有一些模式可以讓我們參考的。我的回答是:「當然了!」但心裡却總覺得有些虛虛的。案例是累積了許多,但把它們變成Pattern!這確實是從來沒有想過的念頭。原因;因為沒有一個顧問案例會一模一樣的,更何況大家的組織大小與文化更是有著很大的差異(新創公司跟一般的IT資訊部門實施起來就有大不同),要想歸納成一個放諸四海皆准的模式,不太可能吧! 回顧自己的職業生涯,在進入職場後曾經換過20幾個工作,從事顧問後也顧問了十多家廠商。為什麼就不能勇敢一點,嚐試看看呢! OK,或許能協助那些自己很想協助但卻始終顧問不到的公司也說不定(哈哈! 報價是一種技巧),所以就從先把他們寫出來開始。

 

{此時自己正和老婆在美西旅遊,這是三個星期的假期,難得輕鬆。這個roadmap我稱它為「Scrum 顧問 Pattern」,接下來的說明就是圍繞著下面這個 roadmap,它交叉了我對Scrum及Kanban 方法的理解及運用(每看一次這張roadmap就會有好多回憶湧上心頭,它看起來平淡無奇,但有多少經歷跟陷阱隱藏在其中,偷偷跟你說,雖然看起來我是在實行 Scrum 但其實我一直是採用看板的Column 來調整開發團隊的工作流程的。 哈哈! 這些招式有多少功用我都太熟悉了,而人老了就是容易多愁善感),我盡量長話短說,畢竟這不是在寫書。但必須聲明一下,放在 Blog上的東西完全歡迎大家拿去用,它是屬於大家的。即使你冠上自己的姓名也會得到我的祝福的。}

 

 

想要施行「敏捷開發」要從那裡開始?

敏捷開發不只是一種開發方法,更是一種觀念的改變。如果只是學習一種技能,只要多下功夫就一定能有回報,但觀念要作改變就比較難了。改變觀念,其實就是一種「變革」,試想要從接受變革開始到去適應變革,然後能夠發揮它的效益,這就需要一定的時間才能作到。那該從那裡開始呢?

001 Agile training roadmap

包含二個Sprint的Agile Training pattern. 一般而言執行他需要一個月,但最長我曾經 run了一整年。  (因為他跟組織文化息息相關)

 

 

 

第一篇、從看見既有的工作流程開始

二個目的:

  1. 減少推行Scrum的阻力,並協助工程師取得盈餘時間。

  2. 提前面對需求。

.

看見 (Visualize) 的力量非常之大(這一點從iPad/iPhone誕生以來,各種媒體就在不斷的教導我們視覺化的力量,尤其是在使用手冊與UI介面的變化上,紙張版的使用手冊真是越來越少見了)。透過網路的力量,造成使用者界面的突飛猛進可能是這個時代最大的改變來源,許多的前端工程師因此應運而生,而這股熱潮將不會隨著時間的推演而逐漸平息,它反而更突顯了客戶視覺體驗的重要性,而他也是產品本身價值重要的一環。我個人一直視「看得見」是一種務實的行為。你可以試著把一些平常總認為稀鬆平常的習慣,試著務實的分析一下這些動作,把他們記錄下來之後讓自己看見這些活動是否有足夠的效能表現,讓紀錄下來的時間花費告訴我們它們是不是一種浪費,然後依此來做改善,增進自己的工作效率。這是看得見與務實能給我們的建議(一種自我的回饋),千萬不要忽略了。

我們總是在看見了浪費的真正原由,才知道要思考如何來改善它。因此要先從看見現在的流程開始。(註: 我之所以挑「浪費」來作說明,除了浪費是精實開發最重要的一條原則之外,再來便是他是團隊提升效能的最佳開始之處,其實我是在替工程師找出他工作上的「盈餘時間」)。

熟悉看板方法的人(或是看過我所寫的看板方法書的人)大概都知道我為什麼從這裡開始,因為這樣作阻力最小,讓工程師由他們既有的流程開始,可以將既將產生的變革先置之腦後,先把自己習慣的工作流程畫出來,用價值流程圖的模式畫出來,然後再把每個步驟及步驟跟步驟之間所需要消耗的時間標上去。這個時候,便可以一目瞭然浪費的所在了(就是那些對我們的工作沒有產生價值的行為或等待,當然是浪費了)。

 

我選擇「看見」作為起手勢,還有另外一層意義就是想要提前來面對「需求」。

 

Scrum 缺少處理需求的前置方法

大部份的開發團隊輕估了需求是否備妥的重要性,也就是所謂的 Definition of Ready(DOR)。執行敏捷開發時,如果你覺得團隊的開發速度始終沒有起色的話,第一個值得懷疑的便是DoR 了。Scrum 沒有強調DoR的重要性,但在實作時却強烈的依靠後續的會議來對需求作檢驗, 這一點可以由最近的refinement meeting 越來越受重視,就可以看出它的重要性。

 .

讓開發工作少作白工

敏捷開發採用使用者故事(User Story)來描述需求。目的是它夠抽象(抽象的目的是減少細節,減少我們對未來、還不確定的東西作預設性的假設,說白了就是胡亂作猜測),它的目標是夠抽象又簡單到可以直接寫在小小的卡片上、便利作交談討論及確定如何驗證它。

而這裡我想追求的是提前在開發作業之前的解題動作。我長期把它稱為是在抽象與明確之間解題。你會問我是嚐試在開發作業之前就把事情都想清楚了嗎?這不正是傳統開發法所想作的嗎!不,當然不是。我的意圖在把需求說清楚,也就是用說故事的方式把故事講的圓滿。要知道,如果是一個好的創意,則大概在說故事的途中我們已經能夠體會到了(就是有驚歎聲跟賀彩聲)。當然,如果故事實在不怎麼樣的話,說完了的時候,大家也應該曉得沒太大作為了(不相信! 請在下一次有好 idea 出來的時候,大聲講給大家聽,看反應的好壞就是他該得的分數了),其實idea如果不講出來就會變成是空想了,空想是很傷的,作多了會分不出來是空想還是幻想,還是多多講出來吧,如果連需求都講不好的工程師,你相信他能把需求作好,才奇怪了。

有很多方法可以幫我們來看清楚一點「需求」的真貌,例如:最小可行性產品MVP(Minimal Viable Product)就是其中一種。它的基本觀念跟測試開發的理念很類似: 試著作出一個最基本功能的產品,然後在取得客戶回饋的數據後進行修正。這種作法對新創公司很合理值得去作,但對大部份的IT資訊部門就不見得合適了(敏捷就是這麼回事,永遠沒有放諸四海皆準的事兒,一定需要調整的)。

 

下一篇、Definition of Ready: 工程師要學會如何講好故事。

接下來要來面對需求了。來談 DoR: Definition of Ready 需求的描述資料是否備妥? (它可以說是影響開發速度最大的關鍵,千萬別小看它了,這是我最近一年以來,花掉最多時間在處理的事情之一了)。

(上面的文章中有很多專有名詞都沒有多作解釋,在《看板方法》的書裡頭都有。如果還有問題的話,就請問吧!)

 

 

Written by ruddyllee

2016 年 06 月 16 日 at 12:39:47

先讓英雄救貓咪 2

leave a comment »

在這個創意橫行的時代,如果你突然間靈感乍現,行雲流水般的寫下絕佳構想(起碼你是這麼認為的)之後,接著該怎麼辦呢?

首先,是不是要先到處尋訪專家學者,來肯定一下這個概念是否可行?到底有沒價值?

再來呢,便是開始到處找找看從前有沒有人作過類似的產品?試想,我不可能是第一個想到這個概念的人類吧? 總之,先看看別人是怎麼作的。

接著:找伙伴,找志同道合的有志之士,一起合作,團隊的力量一定會大於個人的。我們群策群力,仔細的把過往數十年來的相類似產品都拿出來好好剖析一番(聽起來好像誇張了一點,但其實並不為過),試著找出攸關成敗的原因或要素,細細的思考一下,如果是我來作。應該是如何?

最後,務必要弄清楚二件事:

一、你想開發的東西,跟同「類型」的產品之間,到底差異在那裡?憑什麼你會成功呢!

二、決定「架構」,架構是這個產品能否存活下來的關鍵因素。

 

這就是我從《先讓英雄救貓咪 2》裡學到的東西,他在前言裡的第10頁到 13頁。

save2.png

布萊克.史奈德出第二輯了,更精彩!

拿同一類型的產品作借鏡

先以類似的產品做為參考,千萬不要閉門造車,一個人的視野通常都會有所侷限的。因此務必要找一群志同道合的朋友,大家一起討論一起剖析,讓共同成長成為最快的一種成長方式(這叫做團隊開發)。當然產品也會以更快速的方式來誕生。但前題是;這個idea 夠好,真得值的我們去做。 接下來,我要解釋「架構」為何是這個產品能否存活下來的關鍵因素。

 

「架構」才是重點

好的概念不是全部! 要知道;創意有一大部分來自持續的演進跟堅持。但若是一開始的架構建錯了,要隨著趨勢脈動來作修正的屏障就會大上許多,它經常會大到你無法克服而必須從來。所以好的創意,往往需要好的架構來支撐的。

身為程式設計師,我們經常會突然有一二個好的 idea 就這麼出現了,而通常它們的下場都是無疾而終,或許你可以稱他們是不夠成熟的創意吧! 但我總以為他們是少了真實場景(scneraio)的支撐,所以沒能繼續下去。如果你一開始就依據5個 W的問題方式來加深創意的內涵的話,則成功的機率自然會再上升一些。很多時候;先想一下客戶(使用者)會怎麼去使用它,而我們要如何設計好的使用者經驗,讓客戶能夠真正獲利,而願意持續的去使用它才是重點。這種前期的設計思考,正是衍生出產品架構的必要途徑。前萬不要推說這是UX工程師的責任,因為需求跟設計本就是環環相扣的,而架構是支撐功能的基礎,工程師要落實解決問題的模式,它正是用來衍生出架構的。

 

是好萊塢拍戲難還是我們寫程式比較難

因為我一直喜歡拿拍電影或是寫劇本來做為開發程式的參考,所以就經常會遇到這個問題,結論是大家都覺得「好萊塢拍戲比較難」,因為他要討好的客戶群實際上要比我們要多得多了! 而軟體開發也越來越像是在拍電影或寫劇本一般,要找到客戶真正的需求才是重點。

 

借助「先讓英雄救貓咪 2」所做的結論,一部電影是否成功只取決於以下二點:

 

  1. 和同類電影相比,劇情是否有所突破。

  2. 架構是最關鍵的因素。

 

 

 

 

 

 

 

 

Written by ruddyllee

2016 年 06 月 07 日 at 12:11:27

張貼於未分類

Tagged with ,