Ruddy Lee 分享空間

Emergent Design 演化設計

看板之我思故我在

leave a comment »

.

敏捷開發;實質上都是在處理人的問題。

.

我思故我在參考自維基百科

.

我思故我在 I Think, Therefore I am.

敏捷開發;實質上都是在處理人的問題。因此我們不能不對行為科學有所了解。為了更了解人的行為模式,這就是為什麼專注在 Scrum 的人後來都跑去研究引導、精實或是系統思維(system thinking)的原因。其實行為科學就是心理學加上人類學的研究範疇,就是在研究人類的行爲,而如果我們弄不清楚工程師們爲什麼這麼做的因果關係的話,又如何來談改善呢?

》站立會議不是一般的例行會議,不是你報告完了就沒事了,它是提供你在這裡跟著大家一起學習、一起成長的地方。

但這裡想談得東西,其實是因為看到許多運用看板在執行站立會議的團隊成員們經常沒有把心給帶上。只是人站在團隊中,輪到我報告的時候就是交待一下工作的進度就了事了,少了團隊組合裡的責任與義務,也就是對團隊事務的參與。為了這一點,我經常在自己顧問的團隊裡給出會議的宗旨,例如: 專案開始之初,第一周的主題一般都是「專注」。(我用Scrum的價值觀來做站立會議的主旨,它們是: 專注、承諾、公開、尊重、勇氣)而我以專注做開始,實際上是為了在專案開始之初,要求成員盡速的把手頭原有的工作完成或交接清楚,如此才能專心在這個專案上頭。其實任何會議都應該有一個明確的宗旨,否則就容易讓來参加的人變得行屍走肉般的缺乏目標式的参與。

 .

站立會議的四種提問模式

在看板前運行站立會議不是一層不變的,怎麼問、問些什麼? 詢問問題的內容、形式跟得到的答案或效果也將大不相同,以下是我整理出來的四種模式:

  •  激勵提問模式

  •  品質提問模式

  •  反思提問模式

  •  領導提問模式

重點不是在選擇哪一種模式來進行,而是在是否能產生「有效的提問」(註1.),選擇使用那種模式只是用來弄清楚希望獲得的效果或是想要達成的目標是否達到了。因為站立會議的時間簡短,必須迅速的問到重點。因此提問的技巧及方式就非常重要了,他是經驗主義的產物,你必須透過經常性的練習才可能達到好的提問效果的。說明如下:

激勵提問模式

這一點幾乎是所有團隊行為裡必然會被問到的基本要素,共同激勵模式。我們可以從球場上每一節都有的簡短休息中看到教練在休息室裡頭運用慷慨激昂的喊話來激勵球員,團隊成員幾乎沒有個體回應的機會,問的問題也都運用封閉式(註2)的提問方式,團隊瞬間成了一個凝結起來的個體,一致的回答讓情緒快速的高漲了起來。當然在站立會議上我們不必要運用喊口號的方式來激勵士氣或提高大家的腎臟腺素,光是運用掌聲其實就夠了。

相對於激勵模式之下的是可以打擊團隊士氣的提問方式 – 打擊式的提問!當我們把問題重點放在「為什麼未能準時完成任務」、「是誰跟不上進度」。這類有歸罪責任傾向的問題時,常常會立即導致被詢問者打開自我反衛能力的保護傘,是站立會議時最應該避免的提問方式。

品質提問模式

由於軟體品質的好壞幾乎和整個開發的過程都息息相關,因此在站立會議的進行過程中被詢問到最多的問題,幾乎都是跟品質有關的提問: 「程式碼做過code review了嗎?」、「有作單元測試嗎?」但這樣問的效果常常不良,若能改變一種方式來提問(這類問題都是跟程式設計人員的基本素養有關的問題),以主動協助式的提問方式會比採用上面那二種被動式的提問要有用的多,例如: 「讓我來幫你做測試,如何?」、「有誰對這段程式碼有興趣的?」。若是能夠讓團隊整個動起來,則效果更好。具體上可以這麼做,將團隊分成數組,分別負責單元測試(單元測試小組)、負責code review(程式碼檢核小組),就能夠在有人異動工作單時,藉由負責的小組主動發問,主動要求協助。這種既具有提醒作用又有主動提出協助的方式將可以大量提升團隊的協作能力。

反思提問模式

試問要如何讓一個人改變他的決定? (尤其是那種固執的可以的人物,例如: 老闆。註2) 答案是: 「問他一個會讓他進入自我反思的問題」。藉由當事人自我的省思,是觸發一個人改變行為的最基本條件,至於他會做什麼樣子的選擇就另當別論了,這種引導的過程,有一個專有名稱叫做「引導反思」。

當遇到需要集思廣益來共同解題時的最佳提問方式。團隊會透過這種協作方式而變得更為團結、默契更上層樓,人們總是把一起學習一起成長的伴侶視成知己,合作起來效能當然就更好了。

提出讓團隊成員產生延伸思考的問題。例如:

  •    這種做法可以得到什麼效果呢?
  •    能不能舉個例子,或說得更清楚一些?
  •    有沒有可以二者兼顧的做法呢?

 

領導提問模式

傳統的領導方式是採用告知的方式。就是直接把重點告知下屬,讓他們照著做,用來避開在自我學習的過程中所可能產生的時間浪費及風險,但這麼做固然快又不出問題,可是這麼做卻會破壞團隊自我管理的機制,不但會限制了團隊發展的潛力,也會無形中讓團隊解決問題的能力下降。在這裡,我所謂的領導則是指向類似教練模式的指導方式,領導者不是以下指導棋的命令方式提問,而是以教練作指導鼓勵學習的方式來進行提問,讓團隊成員能夠透過討論或是集思廣益的方式來進行解題。你可以這麼提問:例如;

  • 這麼做固然可以解題,但大家想想看是否還有其他方法可行?  張三你來說說看 

結論

請把專案開發視為是一種創意的行為,而不是一種解決問題的手法。這是一種跳脫系統來回擺盪的方法。(註4. 請參考《最小阻力之路》這本書的副標題:以創造力修練取代「不斷解決問題」的人生結構革命。)這是系統思維的基本考量。如果你對Scrum、Agile、Lean以至於 System Thinking還有些許迷惑的話,請參考下面這一張圖示。

.

scrum、Agile、Lean.png

.

實在很難去界定什麼樣的提問是問了個好問題,但好的提問卻擁有一些共同的優點:(註4.)

.讓人專注並竭盡心力。
.創造深度的自省力。
.挑戰那些被視為理所當然的假設;它阻礙了人們用更新更有力的方式做事。
.激發勇氣和力量。
.引導突破性思考。
.掌控打開通往解決途徑之門的鑰匙。
.讓人對情況看得更清楚。
.讓人敞開心胸、思考得更透徹。
.考驗假設,讓大家思索為何他們會這麼做,還有為何他們會選擇採取行動。
.激發正面及強有力的行動。

.

註1. 有效的提問

提問難在哪裡? 我們經常在問問題時,太過專注於立刻想把問題給解決掉,經常不能等到被詢問者經過較完整的思考所作的回答,就急著想下結論了。因此就經常得不到好的回答,因此一個有效的提問必須要考慮到在正確的時機點提出正確的問題,並得到預期的效果。

參考自《你會問問題嗎?》 by Michael Marquardt

 

註2. 每當我想到這個問題就想到《Inception》全面啟動 這部電影,主角李奧納多 費了千辛萬苦,設計了一層又一層的夢境就為了改變繼承人的一個念頭(放棄父親既有的事業,重新建立自己的事業),如果把這個問題交給你來,你會怎麼做呢?

註3. 引導反思 Processing

五南出版社.吳兆田先生出的書引導反思的第一本書

註4. 同化 Assimilation

專案開發是一種創作的過程。依系統思維的方式來觀察人類創作的三個主要階段:分別是萌芽期、同化期及完成期。同化期則是我們在學習組合過程中,用來聚集能量以堅持到最後完成的必經過程。

參考自著名的《最小阻力之路》by Robert Fritz.

.

廣告

Written by ruddyllee

2017 年 06 月 06 日 at 10:58:30

張貼於未分類

Tagged with , ,

我的自行車史

with one comment

.

一早醒來,突然覺得應該記錄一下這幾年騎過的不同種類的車款。(也就這些了!)

.

5.png

xtc

Giant XTC 2005紀念車(全一級配備,8公斤碳纖車)

.

fuji

特殊的FUJI 3盤公路車

.

fuji fixed.png

漂亮的 FUJI 座管一體的單速車 (49 X 15)

4

第二台單速車(48 X19),終於騎上冷水坑了

.

carry me

太平洋 Carry Me 小車(採用特殊腳變,有二速)

.

6A-BIKE我在深圳買過3、4台這個車,輪子太小不好騎。

.

傘兵車

傘兵車,還買了許多套件(但沒有M16)大折 15~20公斤重

.

風櫃 2015

FUJI Wedgio 雪怪 4吋胎

1

換了一個2公斤的座墊

3.png

這輛捷安特的胖車是買給老婆的(視覺系)

.

IMG_1619西班牙 MSC Fat Bike(鋁車架,前雙盤,但奇快無比)

.

IMG_0115

往風櫃

.

Fat

古典胖車 FIGO以足球名將的名字命名

2

KHS 5000 在石碇往烏來

.

mcs carbon

MSC的碳纖車(12公斤左右)

.

18814055_1823129654380781_2371937183916641114_n

採用 VOODOO 車架 的高檔小胖車,3吋胎

.

騎士的心聲

事實

瀟灑  vs.  滄桑

騎士的內心裡一直以為自己騎得很瀟灑像左邊這位(多瀟灑),但事實上右邊才是我們(一副鞠躬盡瘁的滄桑德性)。其實;這個大家都心知肚明,只是總要有一個目標來追從吧! 而我一直以下面這個人為典範,原因很明顯。

oldman bicycle

史恩康納萊.出生日期: 1930825

.

深深覺得

人一定要培養一種興趣並終生奉行,因爲等老了之後跟著你的就只剩興趣而已了!

.

Written by ruddyllee

2017 年 06 月 03 日 at 17:10:02

張貼於未分類

Tagged with ,

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

leave a comment »

.

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

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

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

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

.

提問型文化.png

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

.

提問型文化是什麼?

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

.

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

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

.

提問型文化的基本認知

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

.

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

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

.

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

– 蘇珊.米其林

.

提問的重要性

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

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

.

結論

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

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

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

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

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

.

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

– Margaret Wheatley.

.

敏捷價值觀的實踐

不要讓站立會議變得ㄧ成不變。我的習慣作法是以週或衝刺週期為單位,每回都設定ㄧ個 scrum的價值觀來做為這次的站立會議宗旨。例如第一個宗旨,通常會設定成「專注」Focus,這是因為成員雖然已經加入團隊,但手頭上或多或少還有許多工作沒有完成或交接出去,因此常常必需作與現行專案無關的工作,而又不能堂而皇之的說自己忙不過來,所以訂成「專注週」讓他們盡快回歸專注到目前的專案上,避免多工作的作業方式。

 

》站立會議的提問範例:

當成員把工作單由工作中移動到完成的時候。請採用典型的三步式問答。

1)先詢問完成這份工作的感受,相較於上個工作是難些還是容易些。  – 讓比較啟動人們的思考。

2)再問學到什麼?  – 讓被詢問者得以產生反思。

3)作完的功能可以用在那裡? 或會產生些什麼改變或影響?  – 延伸思考。

 

.

註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