Ruddy Lee 分享空間

Emergent Design 演化設計

善用「站立會議」來建立組織的提問型文化

leave a comment »

.

沒辦法,這就是我們的企業文化。

– 實施敏捷轉型的企業經常會這麼抱怨

我深信「提問」這個簡單的動作,卻擁有著無比的威力可以改變許多許多我們原本認為不可能更改的事情(例如:老闆早已下定決心了的事情,但可能因爲你運用風險式的提問,而產生重大的轉變,尤其是有關安全性的考量。 但由上往下的效果會更好,也就是倒過來由主管向屬下提問)。當企業要實行敏捷化的過程裡,它可能是唯一可以從根部做起的改變。就因為提問讓人深醒、讓團隊集思廣義,並足以作到徹底的轉變。雖然我沒有具體的數據來支撐我的想法,但我已經開始把這種技巧運用在自己所顧問的案例上了。

企業文化本來就會表現在主管們的身上,因此才會有:「主管的敏捷度是企業實施敏捷化的重要成敗因素(註1),雖然這是眾所週知的事(相信主管們也知道這件事,雖然我的課堂裡也常常會有那種很高階的主管出現,但是卻很少有人會問我,要怎麼樣作才能提高敏捷性呢?答案會是:採用「提問式」的領導方式,當你越能問出好問題的時後,也就是團隊越能發揮他們創意的時候了。試試看,它是觸發人們自省的力量,而它經常都在沈睡中),但上面那句沒辦法,這就是我們的企業文化卻依然經常掛在大家的嘴上,到底有什麼方法可以具體的來改善企業文化呢? 這裡提出運用「站立會議」來建立組織成為一種「提問型的文化」,然後再透過形成提問型文化來改變企業文化。至於為什麼要透過站立會議呢? 因為這是每天都要實施的團隊共同的行為,而還有什麼機會比這個時候更適合一起來洗腦的呢? 不是的,而是站立會議本來就是設計成一種用來問問題的過程,因此最適合運用在經營提問型文化上頭(在看板前面的提問應該是詢問看板上所看不見的資訊,而會議預期的結果則是團隊受到激勵而更積極的展開開發作業)。

.

提問型文化.png

站立會議是形成提問型文化的最佳時機

.

提問型文化是什麼?

當我們問別人問題,並請他們和我們一起找答案時,這不僅僅是分享資訊,也是分擔責任。一個提問型文化是一個分擔責任的文化。同時,當責任分擔後,大家就會交換意見、共同解決問題(問題不是你的或我的,而是我們的)、一起承擔後果。當一個組織發展出提問型文化後,他也同時創造了我們的文化,而非你對抗我或雇主對抗雇員的文化 (From: Michael Marquardt)。

.

運用站立會議來落實提問的文化

問問題一直是中國學生最難身體力行的,這一點造成了畢業生進入社會成為社會人後也難以根除的不好習慣(其實歐美的教育,早已經是由學生上課提問的方式來進行教學的。註4.),也就是很少能在大眾的集會場合裡大膽提問的習慣,但其實我們都知道,成員問問題是讓團隊透過討論的方式解決自己的問題的最好方法(註2.而不是由上級直接下指令)。因此在每日實行的站立會議上讓團隊成員確實提問將是團隊自我管理的最佳實踐。目前大家實施站立會議時仍然是以Scrum Master 提問的方式居多,這樣做當然沒有什麼問題,但若是能夠由團隊成員交互提問的話,則這種行為將逐漸形成團隊的提問文化。具體說來;就是當有人移動工作單時(選擇新工作項目或完成工作項目時),工程師們互相關心彼此的作業方式的詢問,將會藉由彼此關心及交談進而帶動相互間的協同合作模式,團隊可以藉由分組或相同性質的組合小團隊來訓練提問的技巧。讓提問文化落實於小組之間。藉由小組擴充到團隊,並藉由團隊來影響整個組織。

.

提問型文化的基本認知

首先要讓團隊成員願意承認「我不知道」。因為沒有人是無所不知的,尤其是在這個資訊爆炸的世界,往往承認不知道時反倒是學到最多的時候。因此在接受別人提問時,不但要能夠接受而且要相互鼓勵提問,然後再一起來尋找答案,達到雙贏的策略。當然;需要培養出一套會問問題的技巧,而且能夠問對問題,尤其是不應該問那種打擊信心的問題,反之;應該問那種具有激勵型的問題,讓交互問答的過程來形成解答,而無需去強調什麼才是對的答案。因為往往業界的標準答案卻不見得就適用在你們的團隊裡。

.

敏捷文化就是一種學習型的文化

一個提問型文化會造成大家經常性的提問,重點並不見得是要找尋那個答案,實質上反而是去促成一種熱愛學習的文化,在一個組織裡大家透過提問和學習的方式去創造團隊的共同開發成果。況且;對於許多問題而言,其實沒有什麼所謂的正確的答案。重點是要能夠造成大家的共識才重要。彼此詢問;能夠透過團隊成員在不同的觀點下透過討論來尋求共識,是形成組織持續成長的一個重要過程,而當然也就能夠自然地形成團隊自我管理的文化了。

.

最有用的問題,是那些讓人學會從別人的角度看事情、然後自我反省的問題。

– 蘇珊.米其林

.

提問的重要性

好的提問能夠撞出多少好的成果? 《禮記·卷十八 學記》 裡講到: 「善問者,如攻堅木,先其易者,後其節目,及其久也,相說以解; … 善待問者,如撞鐘,叩之以小者則小鳴,叩之以大者則大鳴,待其從容,然後盡其聲;不善答問者反此。此皆進學之道也。」

請善用站立會議時的詢問:在看板前面,為一張剛剛完成的工作單問出「過程」,技巧而細緻的詢問讓大家就好像都看見了現實的開發過程,並為這個工作項目打上(品質的)分數。

.

結論

改善組織文化看似很困難,而且總給人一種需要很長的時間才可能會奏效的感覺。但其實透過簡單的問問題就能由改善組織的溝通效益,進而改善組織的文化。

因此請思考: 如何作好提問?如何建立組織的提問型文化?如何在短短的15分鐘內達成目的。 這不是Scrum Masterㄧ個人的責任,當然SM也沒有必要ㄧ個人絞盡腦汁的從頭問到尾,實際上要能觸發團隊成員在必要時進行彼此交互發問,透過這種方式也才容易廣泛的獲取大家的意見。前提只有一個,那就是作好「有效的提問」?(註3.)讓團隊在有限的時間裡大量的交換意見,並尋求共識。除此之外,要讓團隊成員停止報怨公司文化的前提,就是讓他們有機會去創造自己團隊的文化,而這種機會其實就隱藏在學習型組織成長的過程裡,所以務必在實施良好提問情境下,形成團隊知不足而勇於學習的精神,自然能讓文化成型。

是的,提問型文化能夠強健團隊並改變組織的文化,團隊成員透過持續學習的成長方式來建立協同的運作模式,他也間接的促成了團隊自我管理的成效,讓企業能夠更敏捷化。

》這樣子的作法會不會讓站立會議變得太沈重了些,會因此而造成站立會議大量超時嗎?

很多人都誤解了站立會議,他是ㄧ個相當高成本的會議,雖然只有短短的15分鐘,但在sprint的週期內全員都必須每天参加,所以應該要開得越是簡潔而有效益才是,應該盡量去增加他的CP值,而促進團隊學習與讓團隊自行系統化的運作,可以說是效益較高的行為了,值得投資。

.

好的問題會激勵人心,而一個提問型文化可以激勵一整個組織。

– Margaret Wheatley.

.

註1. 主管的敏捷度是企業實施敏捷化的重要成敗因素

在 Ken Schwaber 與 Jeff Sutherland 合著的《告別瀑布擁抱 Scrum》一書的書尾 P174頁的地方,有一封Ken Schwaber 致某某公司CEO的信件裡寫道,實施Scrum的成敗關鍵在您(CEO)的身上。

.

註2. 《引導的秘訣》 The Screts of Facilitation  by Michael Wilkinson 著

引導的祕訣一、當解決方案是由受到其影響的人所產生並被他們理解和接受時,往往可以的得到更加有效的成果。

.

註3. 「有效的提問」被公認是解決需求模糊、認知不一的最佳方式。

Agree

「提問」是解決 Kent Beck 這張認知不一圖示的最佳方式

.

註4. 翻轉課堂 Flipped classroom

是一種新的教學模式,2007年起源於美國,翻轉課堂會先由學生在家中看老師或其他人準備的課程內容,到學校時,學生和老師一起完成作業,並且進行問題及討論。由於學生及老師的角色對調,而在家學習,在學校完成作業的方式也和傳統教學不同,因此稱為「翻轉課堂」。

.

Written by ruddyllee

2017 年 05 月 22 日 at 18:18:53

團隊如何解讀看板 – 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