為需求加上故事

.

我們無法通過智力去影響別人,情感卻能做到這一點。”

-亞里斯多德

.

說故事有多重要

為什麼技術人員需要重視故事呢? 原因在於,即使個別的訊息 (需求)看起來都很有邏輯,讓人看了一清二楚,但是只要這些訊息之間相互的關係不是那麼明確,接收者(客戶)所吸收到的程度就容易受限。即使你塞了再多的片段資訊給對方,也很難讓他確切的了解。這一點可以在檢核會議(Review meeting)時的客戶回饋裡看出來。客戶經常是現在沒問題或對單一的功能沒問題,但在最後串起來時卻能提出許多意見。

 

故事能賦予產品生命

敏捷對需求所陳列出的一個個小的使用者故事(小增量、迭代與尋求回饋的對象),需要被串接起來成為更大的故事。PO需要對大故事的環境、演進最為熟悉用心,而團隊則負責弄清楚需求的故事細節與情境。如此才能讓產品有一個足夠量的故事來支撐它,而工程師能做的則是賦予一個一個功能的小故事,它是一個個心血的結晶而終將成為工程師們生命歷程中的經驗所得。因為故事裡帶有情感的要素,可以讓人們產生更多的聯想,而賦予了產品額外的生命。

.

故事可以將訊息組合成邏輯金字塔。重點在於能以明確的連接詞串起所有的訊息,就成了一個大道理。

麥肯錫顧問公司的金字塔原理用於說故事

.

故事連結了片段的訊息

好的溝通需要有清晰的邏輯內容,更需要一個簡單的結構來引導聽者的思維。而故事可以將訊息組合成邏輯金字塔,並讓片段的訊息串成更完整的系統邏輯並讓產品的生命得以成形。

如果在開發的漫長週期裡,我們始終知道自己正在完成的是故事裡的哪一個片段,我們就會做得更好,程式裡也會更有感情、意境與創意也就更容易油然而生。

.

階層的需求故事

敏捷運用故事來描述需求

.

使用者故事不是故事

一個好的故事詮釋了一個產品被開發出來的意義,就好像賦予了它生命一般。如上圖;一個大的故事,在敏捷的需求範疇裡我們稱之為EPIC,有關他的長篇敘述最適合在啟動會議(Kickoff meeting)拿來打動人心,讓大家知道辛苦工作的目的也就是我們是為何而戰的。再小一點的故事可以稱為 Feature 他適合在梳理會議(Refinement meeting) 裡拿來說明這幾次短衝(sprint)的目的,有利於團隊在明確的目標下發揮更好的協作。

 

接下來是使用者故事(User story),雖然名稱是使用者故事但她不是故事。她是敏捷團隊裡PO、團隊與Scrum Master拿來溝通用的共通語言。一般以3C的方式做呈現,也就是 Card卡片、Conversation溝通及 Confirmation確認。它不是需求的文件,而是引發團隊探討需求的手段。再來便是開發工程師將一個使用者故事Breakdown 成可工作的任務Task,它能夠在一天內完成是在好不過的了,因此以小時做估算,最後則是守住這些 Tasks 的測試案例或單元測試。

 

上圖中;故事的範圍結束在 Feature層, 但情感的注入則應該再下去,延續到使用者故事裡,理由是帶著情感、有意識下的開發行為能讓人表現得更傑出、更有創意。因此我們應該為需求加上情感加上創意。而透過的方式便是擁有一個可以活化她的故事。

 

.

演講時;經歷是最好的故事體裁,也是最有說服力的故事。

.

 

結語

早年學寫程式時都是看著開發文件;也就是所謂的 follow Spec依據規格書來寫程式。這種做法很制式很難有創意,偶而浮現出來的 idea 也會擔心是不是會偏出主題的路線,因此經常督促自己還是選擇保守一點的好、少搞怪。在開始進入敏捷領域之後,想法就變了。由於是小增量、多迭代的關係,目標變小了,忽然間就開始不怕搞怪了,而且會經常刻意的去嘗試一些新的想法,樂此不疲。

 

因此在做Scrum Master的時候;總是要求產品負責人 PO要把需求整理成故事,用一段帶著感情的陳述把需求涵蓋進來,運用故事的情境把團隊帶入開發的課題裡,讓工程師們聽完了需求就恨不得能夠立即為他們解決問題(也可以讓工程師反思自己是否有能力做到?),大家對此都沒有意見,但照著做的PO卻不多,也沒看出來有多大的差異,因此久而久之就越來越少PO這麼做了。這對工程師是一種損失,它忽視了故事的力量也減少了許多可能的創意與樂趣。

 

記得為需求加上故事,請不用擔心會走偏了;因為

事實確實重要,但情感卻能將事實的意義傳達給你的聽眾。

 

-Annette Simmons

註:

  1. 你的團隊需要一個會說故事的人》by: 安妮特·西蒙斯 Annette Simmons
  2.  影響地圖 Impact Mapping 是編劇、講故事的絕佳工具。
  3. .神鬼獵人_impactMapping電影: 神鬼獵人的影響地圖分析,適合拿來做劇情說明
  4.  一個PO做需求描述的故事與使用者故事的拆解範例
  5. .83故事在描寫一家三口出遊的需求
  6. .84陳列出來的使用者故事

 

 

需求落點分析模型

.

目的

提供團隊在開發完一個Sprint的增量後針對需求的價值給出回饋,讓工程師有機會就自己所剛剛完成的任務有發表意見的機會,同時運用專家的視角將回饋傳達給PO。

.

步驟

首先;在便利貼上畫一個 2X2的矩陣,垂直軸是對市場的差異化影響的大小,水平軸表示我們作了哪些工作(任務與努力)的多寡。

接著;讓團隊成員針對剛剛完成Sprint的使用者故事的落點進行評估。

layout

(團隊在進行點評時,務必再說明一回各個方塊的意義,讓點評更明確些)

.

該怎麼點評呢?

差異化活動

右上角的方框是用來表示我們完成的這些個使用者故事,它對市場差異性是有所幫助的任務。如上圖的 U1及 U2.

 

校驗活動

右下角是指我們完成的任務僅僅是用來追上目前市場的水平,也就是市場上其他品牌基本上都已經有的功能。一般新的產品通常都要向已有產品靠齊,但如果花太多功夫在這個方塊中,產品是不會有更大的成長的。反過來應該做剛剛好的人力調適,多朝右上方的方塊靠攏才是比較具有價值的任務。

 

合作夥伴活動

左上角是指如呼叫後台的API或是其他廠商所提供的支援API等,算是與合作夥伴共同完成的任務,但這對產品的差異性是有幫助的,雖然不是自己做,但卻也有一定的價值。

 

無用的活動

左下角,指的是我們作了一些對產品在市場差異化上完全沒有幫助的功能。

.

基於目的的對準模型(Purpose-base Alignment Model)

工程師對需求的認知圖一、依據 Kent J. McDonald的Purpose-base Alignment Model 所改良的需求落點分析模型 (1上面的紅色說明是依據Kent 所發表的白皮書所加上的,黑色字體則是Niel Nickolaisen 原著的翻譯)

上面二位作者的宗旨都是針對專案尚未開始時所設計用來「理解情境」用的模式。因此稱之為基於目的的對準模型,下面則是我把程序反過來;拿來用在工程師開發完需求後的落點評估說明。

.

為甚麼要工程師來評比呢?

因為剛剛完成任務的工程師,正是對該功能最熟悉的人士(專家),他可以用最專業的立場來看它的價值。雖然主觀了一點,但這不正是專家的意見嗎?

 

下圖說明,工程師在接收到開發任務之前對所要完成的功能及相關信息是全然無知的(中間藍色點鏈線),必須透過持續的摸索與學習,在無數次的嘗試失敗之後,才能累積完成工作的足夠能耐,然後才能把工作完成。(綠色點線即為PO的認知,我們的目的正是將藍線在峰頂的知識回饋傳達給PO產品的負責人)

 

認知

圖二、開發人員對需求了解的時間曲線

如上圖的紅點,是在描述在開發工作中我們持續的學習到相關的新知識並把它們轉化成實際能工作的程式,這時候我們總會認為除了自己之外再沒有一個人能比我們更了解這段程式碼了,此時我們達到了一種專業的領域,一種將需求轉化成可工作軟體的境界。而「需求落點分析模型」正是要在你成為領域專家時對需求進行評比的工具。原因是這個時候你具有最專業的視野,正是可以對所完成的需求進行回饋的最好時機點。回顧會議似乎是一個好時機點。這個簡單的模型是這樣進行的:

.

範例: 假設這個Sprint完成了7個使用者故事,Scrum Master 可以在回顧會議時,首先把需求落點模型的圖示畫在白板上頭並加以簡單說明,接著要求團隊就剛剛完成的工作以他們自己的認知點在便利貼的四個方塊上。然後由Scrum Master 收齊,交給PO做參考用。

IMG_20180101_083503

實際運作時一個工程師的點選結果

說明:

  1. 在 差異化活動裡有U1,U2.

這是有意義的需求開發工作。越多越好!

  1. 在 校驗活動裡有 U3,U4及U5.

我們正在追上市場的基本水平中,團隊雖然忙碌但距離市場的期望越來越近了。

  1. 在 合作夥伴活動裡有 U6.

有協同合作的機會,交互配合度的好壞可以拿出來分享。

  1. 在 無用的活動 裡有 U7一個,這表示該團隊成員認為 U7是一個較無意義的需求工作。平白耗費了工程師的資源。

 

{ 上面這一張落點圖示,是以一個人為標的一次評打完所有的使用者故事,適合在 Review會議後進行,另一種方式則是一次一個使用者故事但包含所有人的點評,團隊每個人依序輪流點評,這種方式會進行得更為快速但不適合較大的團隊採用,優點是不需要事後再做統計的動作。 }

 

※ PO若有感興趣的地方(例如發覺團隊跟自己的認知有差距時),可以在與團隊進行溝通,而這種直接來自專家的回饋,可以提供PO做需求排序時的參考,當然有必要時更可以做為進一步溝通的依據。

需求落點模型可以讓PO與負責開發作業的團隊成員,透過回饋的方式交換彼此的意見,並藉以提升二者對需求的共同認知。

.

說明文檔在這裡

 

參考:

  1. Using the Purpose Based Alignment Model by Kent J. McDonald
  2. 超越需求: 敏捷思維模式下的分析 (Beyond Requirements: Analysis with an Agile Mindset)
  3. 精益創業實戰  原作名: Running Lean, 作者:Ash Maurya , 2013

 

需求要作到哪裡為止?

.

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

.

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) ,當然就可以忽略這一條線了,因為廠商會自動把資源控管住,你想多做一點都很難!

 

.

消化需求,拯救這個世界

.

程式碼不會改變這個世界,需求才會。

.

專家.png

PO及開發團隊對需求了解程度圖示(註1)

.

》工程師在開發程式的過程中,經常會覺得自己才是最了解這個行業的人士(上圖中的藍色曲線說明了這一點)。

.

【圖示說明】

縱軸是對需求了解的專業度,橫軸是開發的時間,描述的是ㄧ個sprint 的開發週期。

.① 是程式設計人員一邊進行程式開發,一邊持續吸收專業知識,迅速成為行業的專家。

.② 綠色的線條,指的是需求的提出者 PO,他由對產品的初步構想一直到工程師交付產品後的知識變化曲線。

.③ 藍色的線條,指的是開發團隊,由對產品的一無所知開始學習的路程,一直到達 ① 的至高點成為行業的專家,再到交付後對專業知識的迅速遺忘的曲線。

.④ 通過定義完成(DOD)點時,工程師的專業知識迅速下降,但 PO 透過對產品的學習操作,維持了它對產品的認知。

 

.

寫程式是一種學習的過程

程式設計人員是知識的消化者。他們在大量的訊息中尋找有用的知識。透過無數次的排列組合,努力的從凌散龐大的訊息中尋找組合出一幅看起來有意義的簡單圖示,它們是一串讓我們感覺得出意義來的模型圖示。然後在似懂非懂又隱含著抽象跟模糊不清的一堆想法下,我們開始以嘗試錯誤的方式來撰寫程式的過程(此時;在我們腦海裡的模型越是清晰明確,寫出來的程式就越加實用持久)。

其實一開始我們知道得很少,知識隱含在很多人和許多文件中,當然其中也夾雜著許多無用的知識,所以在寫程式的過程裡我們必需持續的去請教專家或通過搜尋再進行過濾學習。一直到上圖 ① 的地步,程式設計人員經由學習而逐漸成為行業的專家。

.

成為高效的知識消化者

好的程式設計人員需要能夠迅速累積專業知識,當然我們不可能真正成為所有建構軟體的從業人員,所以我們快速獲得的知識也會迅速的遺失。但上圖中那個紅點的高度以及那條曲線的斜率,決定了程式設計師交卷時的品質及時間。(請注意,程式設計人員往往是一個團隊,而不僅僅是一個人)如果我們學得越快越好,也就是對所開發軟體的行業知識認識得越深(也就是上面提到的那個知識模型,一般我們稱它為領域知識模型),則明顯的開發出來的軟體會越優秀對環境的適應性越佳,也就有著較長的軟體生命週期,反之;則可能只是達到使用者足以操作而生命週期十分短暫的軟體。

如 ④ 所顯示的曲線迅速下滑區。所有的專案都會有這個知識遺失期。在團隊裡頭學到這些知識的人員,可能又去做其他的工作了,當然團隊也可能解散或重組去進行其它的任務。要避免或減少大量知識遺失的最佳方法,就是透過作成文件來記錄避免知識的掉失。所以工程師除了高效學習之外,要培養做好文件及使自己能夠從文件中培養迅速學習知識的雙向能力。

.

【圖示說明】

Ready 的綠色區域,我們稱之為 DOR: Definition Of Ready定義「文件備妥區」。Sprint 從這裡開始,它是需求品質的把關點。

Done 的紅色區域,我們稱之為 DOD: Definition Of Done 「定義完成區」。Sprint 結束在這裡,這裡是產品品質的關鍵點。

簡單的解讀:

》當 ① 的專業知識點越高,則表示團隊對需求的了解越深,程式便可能更優秀,有著更高的實用性及擴展度。

》當DOR 與 DOD的區間越小,則表示工程師的學習能力越強,團隊開發的效能越高。

※我們可以透過看板方法的累積流程圖來得到這些數據。

.

是需求在改變這個世界

我是一個軟體工程師,但我立志要拯救這個世界(Save the world. 每回說到這裡大家都會哈哈大笑! 這是多年以前從電影裡學到的,但老實說沒在開玩笑,我終身信奉)。這是我的志願,而達成它的作法則是透過不斷為他人增加價值(是的,是透過為別人增加加值,來提升自己的價值,也就是透過撰寫一些真正有用的軟體來貢獻社會),為人們服務,給人們他們所想要的東西,當然前提是要知道他想要的是什麼,也就是弄清楚需求。原因;是我體會到不是我們的程式碼在改變這個世界,而是需求在改變這個世界,而我們透過持續的努力來滿足他,來創造這個價值,至於成功嘛,則只是伴隨而來的紅利罷了。

.

工程師的職責就是消化需求,拯救這個世界。

.

 

註 1. 參考 Ken.Power 對 DOR: Definition Of Ready 的說明圖示

.