Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 十月 2015

看得見 : 看板讓你看得見

leave a comment »

  • Q&A : 實行看板方法與 PMP 或是 CMMI 有衝突呢?
  • 回答 :  當然不會衝突。

看板方法是精實開發的一員,屬於「視原則重於開發方法的一種漸進改革方式」。他的目的在讓工作流程被視覺化,讓我們的決策更接近事實、更容易作為改善的依據、更容易管理及更有效率。

.

眼見為憑  “To see is to believe"

形容不要輕信傳聞,看到的才是事實。聽來的傳聞是靠不住的,親眼看到才算是真實的。所謂;親眼看見的比聽說的要真實可靠。「看板方法」也就是這麼一回事,它要求我們要畫出價值流程圖來,也就是把開發過程呈現出來讓我們看見浪費所在,並依據他來加以改善(而不是用臆測或聯想的)。而 DevOps 也正是要依靠這麼一回事!讓你依據看見了的現象進行調整與持續改善。

.

投影片2

旅遊是一種透過看得見,來增長見聞的方法

.

看見流程、進度、問題及瓶頸

我們都愛旅遊,因為旅遊可以拓展人的視野,而視野寬廣的人容易讓人喜愛。自己也可以因為行萬里路而增長了知識,對人對事也似乎能夠看得更深更遠一些,好處多多。但這裡我們不談旅遊,我們想談的是「看得見」。

很多事情都需要你看見了,才會意識到也才會知道事情的原委,才曉得接下該怎麼來處理它。這樣的看得見正是看板所能帶來的好處。看板方法的第一條原則,「視覺化」。正是要求透過視覺化你目前的工作流程(產出價值流程圖,Value stream mapping)。讓你看得見工作流程的狀態、看得見進度、看得到問題所在、看到事情的瓶頸。然後才能正確地來進行改善的工作。

.

0 看得見

看得見: 流程、進度、問題及瓶頸

.

可視化的價值 –透明化

看板上流動的工作類別,決定了我們想看到的工作流種類。以開發作業為例,我們用"使用者故事"來描述需求,團隊並針對要如何達成這個需求而將它拆解細分成可以實作的Tasks,並針對各個Task作需要開發時間的估算,接著在卡片上壓上工時以便利追蹤,並在拉入"In Progress"時寫下開始時間,讓他明確地在看板上以貼紙的方式呈現出來,讓大家都能看得見進度及狀態。這個動作讓專案的進度完全落實在看板上頭,就專案而言就稱之為「透明化」。它是實行敏捷開發的基礎,也是主管對敏捷開發最愛的地方,就是能清楚的看得見專案開發的進度。

.

00 user story

.

卡片需要追蹤、更新及follow所衍生出來的問題

工程師容易患見樹不見林的問題。因為工程師通常是把焦點放在工作上,而忽略了使用者故事所要達成的目標。這是Scrum 團隊最常患的迷失,也就是把Task當成目標,這便是「非技術債」最常誕生的原因之一。它往往不是使用者故事寫得不好所造成的,而是工程師經常用 Task 來取代開發作業的目的所造成的結果。此時,Scrum Master是最可以改善這類迷失的當然人選。我們可以在站立會議時適時的提醒工程師在更新工作時,再次正視這些工作的目標,簡單的討論一下距離達成目標的距離,聽聽團隊的意見,不但可以避免忽略了真正的標的,而且可以讓團隊更專注於達成目標的使命感,是一舉數得的動作。

卡片上充足的訊息能讓觀看的人獲得更多的資訊,但適度凸顯重要的訊息(運用顏色、特殊標籤等方式)會遠大於一大堆相同分量的訊息要有價值的多了。也可以便利團隊就事論事的進行問題討論。

.

0 看得見卡片

原本十分抽象而簡單的卡片,在看板上是需要被賦予了各種屬性及訊息。

.

可視化價值流動

在工作步驟與步驟之間,代表的是一個工作的輸出(成果),以及它流動到另一個工作時轉變成輸入的過程,這個轉變的過程正是預告將要製造出的價值所在。工程師則是負責製造達成這個目標的人。團隊依據卡片上對工時的估算,小的Task我們可以很快的看到成果,較大的工作則可以持續在卡片上更新它的進度,讓大家都清楚目前距離達成目標的距離,然後以一個團隊的形式來共通承擔這個任務的成果。

 .

可視化問題及阻礙因素

看得見風險是看板的一大功能。由現象的解讀我們便容易推論出專案接下來可能發生的現象,美其名或許可以稱之為預測,但實際上只是一種後果的猜測而已。團隊可以依據看板上的徵兆,共同討論、共同決定對策(這是團隊表現出自我管理能力的地方),這一點可以提升團隊對任務負責的心態,也能夠具體的提升團隊自我管理的能力,相對於處理的問題或瓶頸而言,是更有價值的一環。

可視化排隊queue 及瓶頸

看到問題便可以針對問題進行改善,這是看板最能發揮精實精神的地方,也就是運用「看見浪費」,來實踐精實第一大原則,也就如何「消除浪費」的具體方法。我一直以為看板之所以稱為方法(Kanban Method)的地方便在這裡,它是一種消除浪費的方法。

產生Queue的地方,便是出現盈餘時間的地方,也是多出WIP(Work In Progress)限額的地方,就是我們可以加以改善的地方。在運行看板的時候,在這裡的半成品(WIP)已經從原本的一種猜測,轉變成是一種現象了。依據這個現象,我們便能夠對看見到這樣的現象,針對它來進行改善的工作。

.

看板方法是一種消除浪費的方法。

.

看見之後,要如何來改善呢?  看板方法的第二條原則:設定WIP限額就是要完成這件事。我們下回再來談吧!

廣告

Written by ruddyllee

2015 年 10 月 15 日 at 12:24:43

敏捷開發的規格文件 – 活文件

with 2 comments

在實施敏捷開發時,由於敏捷對文件的描述較為模糊,常常讓開發單位為了應該產出甚麼文件而傷透腦筋。這一篇敏捷的規格文件,正是針對這個問題,採用 HIPO 的模式,解決實施敏捷開發方法時對文件的需求。

.

HIPO是什麼? (Hierarchy plus input-process-output)

它是IBM公司於70年代中期在層次結構圖(structure chart)的基礎上,所推出的一種描述系統結構和模組內部處理功能的工具(技術)。當時IBM所有的產品文件都使用這一種規格,其中包括著名的作業系統 OS360、OS34 等。

HIPO chart

完整的HIPO圖

.

我是30 年前開始接觸到HIPO文件的,它是IBM的創作,IBM運用這種 Function Diagram 加上 Input-process-output 的圖形描述方式(別懷疑;就只有這二種圖示),用它便能夠完整的製作了許多龐大的軟體,真是令人刮目相看。10多年前當我開始接觸敏捷的時候,便一直以這種文件模式做為開發專案時的架構文件。後來,在看到使用者故事地圖(user story mapping)時就興起了,拿它來置換 Function Diagram(Hierarchy chart),再加上慣用的 Excel 檔來作為輸出入的規格紀錄,二者合起來便剛好是 HIPO的架構模式,真是太棒了! 真是 Just Enough一點也不多。

.

HIPO chart_all

運用使用者故事地圖取代Function Diagram, 運用Excel 活文件與IOP chart互補

.

委外開發要給什麼文件?

常常被問到;委外開發要給什麼文件? 答案是: 夠簡單又剛剛好的文件(給多了怕估價太高及工時太長,給少了怕做簡單了,影響到應用程式的功能開發不完全)。 而這剛好是敏捷開發所謂的 Just Enough 的文件規格。在敏捷式開發裡,文件一直是跟隨專案的屬性,視需要適量的產出的一環。而且只有一條準則:  「夠用就好」。所以我就想到,用使用者故事地圖來取代階層式的結構圖(function diagram/hierarchy chart)。接著再用Excel 實做的活文件規格來取代輸出入處理圖示。結果是,超好用的。(但也不是沒有但書的,例如,開發者必須先對使用者故事有相當的認識,才能順利地運用使用者故事地圖來規劃整個功能架構。至於Excel的部分就順暢多了,因為已經有太多人拿它來做I/O 輸出入欄位的定義用了,因此這部分就水到渠成很容易就發揮它易改易維護的特色了)。個別說明如下:

.

階層式的結構圖 Hierarchy chart 

階層式的結構圖是一個抽象化的功能區塊圖示,它像極了「使用者故事地圖」,足以描述我們對需求的上層架構及骨幹。(在這裡我們必須小心地處裡二者之間的轉變,因為Hierarchy chart 是面向程式設計的功能,而使用者故事地圖則是面向使用者的需求。)

HIPO chart_1

左邊是階層圖示,右邊是使用者故事地圖

.

階層式IPO chart

階層式的 IPO chart 簡潔的描述了輸入、輸出及程式處理的功能說明,這種善用抽象化的方式,聰明的避開了許多細節及參數,看起來清晰明瞭。當出現複雜度過高的圖示時,則可以再串接到下一個階層式的 IPO chart ,如此串連下去,一直到出現足夠明瞭的功能說明為止。

HIPO chart_2

 .

一個簡單的範例說明: 簡單描述一下IOP chart的繪製細節。

0 sample

控制流程細節概述

.

結論

HIPO 是一種古老的文件格式,是規格文件演進過程的一個佳作,他實際上被大量使用了(所以勘用程度是OK的),你可以在這裡(64 HIPO (hierarchy plus input-process-output)找到原版的說明,他因為太簡單而被複雜的文件系統淘汰了,但卻因為適合敏捷使用,又轉成了另一個形式又誕生了。或許該給他另一個名字,就看他能發揮多大貢獻再說吧。

.

請參考: Slideshare 上的PPTX: http://www.slideshare.net/ruddylee/ss-53404378

HIPO wiki 上的說明

Written by ruddyllee

2015 年 10 月 01 日 at 15:47:06