Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 一月 2015

我寫程式的習慣 My Habit of coding.

leave a comment »

年輕的工程師問我如何開始建構程式? 真是好問題。基本上我不覺得有什麼標準作業程序(SOP)存在,也一向不覺得自己寫得好什麼程式。但幾杯威士忌下肚後還是答應今天一大早寫給他。

.

我寫程式的習慣

  1. 先啟動 PPT 把草稿建立起來。(目錄是重點,紀錄)

  • 選定Keyword、建目錄。
  • 相關資料收集、分析。
  • 概念模式成型。
  1. 啟動IDE建立程式雛型

  • 選擇程式pattern。
  • 修正撰寫程式的模式。(微軟VS的Template 太一般的雜亂)
  • 決定解決問題的主戰場。
  • 加入版本控管。
  1. 問題陳列

    (不宜太早做的步驟,因為還看得不夠深入)

  • 找出真正的客戶? 真正的問題? 決定該放入多少比重在看板牆上。
  • 風險: 評估出恰當的架構。
  • 設計運作流程(可控制與不可控制的部分)
  1. 開始嘗試建立解決方案…

  • 奢侈一下,告訴自己今天建的是 prototype。(可以不怕改)

.

解題從抽象化開始

沒有太多東西可以教你的,但我習慣從抽象化開始,因此就選擇由PowerPoint開始。PPT其實是抽象化最好的工具。選擇在PPT裡頭進行草稿的思考,通常是預做未來包裝上的簡介手冊,但有時候一不小心就會把Prototype也畫完了^_^。接著把所有的資料都塞到這個固定的目錄裡去當做文件,可以省掉未來要寫文件時沒東西參考的煩惱(就在目錄裡命一個叫"文件"的目錄),反正有相關資料就塞進去,可以拿來做應付外界詢問用。只要有人要求做訓練或交接,隨時可以用它來做簡報。有趣的是;自從我養成取一個目錄叫"文件"之後,它就從來沒有空白過,這也是一種成就感、一種習慣。現在只要我回頭尋找程式的時候,一定會先去"文件"看看它。

.

取Keyword 是我寫程式之前最快樂的事

為專案命名! 想到甚麼就取什麼名字,反正高興就好,可以拿來講故事的話,就更有樂趣了。它往往會成為日後回憶的關鍵字,很有趣的,不妨試試看。回想一下微軟 Longhorn = WPF 的由來,它是 Michael Wallent 取的名字,典故是他來自德州,長角牛Longhorn具有德州的代表意義。如果可以的話,再拍個幾張照片來陪襯就更有味道了,更能有利記憶。記得有一回我取了一個codename = 劍潭(Jiantan),專案合作的對象有不少老外,茶餘飯後老來問Jiantan到底是甚麼意思!? 哈哈! 其時背後隱藏的是鄭成功把配劍扔進有妖怪的湖裡,而引來"劍潭"取名的由來。但老實說;大部分的人從頭到尾都搞不清楚,純粹是程式員的自得其樂而已。

.

由PPT做起手勢好處多多,有時候做完PPT之後,coding就省下來了,因為分析完畢之後;就找到不用寫程式也能解決的方案了,那還寫甚麼程式呢! (上回因為需要重複改幾十個檔案名稱,就決定來寫一個好用的改檔名的工具,想說日後一定還派得上用場,但做完PPT檔之後,回過頭來就找到已經寫得很棒的工具程式了。真是前人種樹,後人乘涼)。

.

還記得由"抽象"到"明確"的解題法則嗎?

你很少會有一眼就望穿問題的時候(一見鍾情還是存在的,只是不多見),所以跟在畫廊看畫一樣,不要急著讚嘆,先後退個幾步,試圖看清楚輪廓再動手。通常我都是在這個時候找靈感的。找不到就請出Google來幫忙。相信自己不是第一個需要寫這支程式的人。所以先看看前人都是怎麼做的,有沒有物件可以拿來繼承的。(我定期會把一些程式丟到 Codeproject 網站上面,只是想像有人會用到它。如果你在那裏找到了合用的資料,記得要感恩,順便給下一次禱告增添一些內容)。搞清楚些再開始! IDE是我們寫程式的主要工具,但它太過於明確了,不利客觀思考,多抽象一回兒;等你迫不急待要真正寫一點東西的時候,再來動手寫。不要急,急只會出錯!

.

用看板來取代 To-Do List

用看板來取代 To-Do List,一下子就能讓你想到如何加速開發作業的方法了,它有視覺化的神奇魔力,能讓人看到那些事是浪費,是可以改善的地方。可以客觀的看到,你現在正在那裡做掙扎,該怎麼下決定才對? 因為它把流程都攤在桌上了,只要記得反省一下,改正一下,這就做到敏捷了,好棒! 現在的數位化工具太多、太強了,尤其是看板牆的App,手機、平板App到處都能用,隨時可以進行瀏覽、修改,做為搭乘捷運時的低頭滑手機族,正好可以拿來充分運用時間!

.

先做問題陳列會比較好嗎?

你可能會覺得,是不是應該先做問題陳列呢! 但經驗跟我講;思考的時間太少了,就列不出太多東西來,急著做等於白做。這跟精實軟體開發原則的盡量延持決策(Decide as late as possible)或許有些相關吧。急著想清楚反而適得其反,不如先用漏斗理論客觀的在外圍觀察一下,再從最大的風險處切入做架構設計。(請記得設計模式是針對問題而生的,若沒能肯定遭遇到何種問題,就無需決定採用何種設計模式。像現在一窩蜂的;所有寫ASP.net 的 Web 程式的工程師,無論寫甚麼程式,一律採用 MVC的模式,真是違背了設計模式的基本精神。難怪設計模式的書賣得好,因為確實是需要的。)

.

不寫了,再寫下去就過中午了,有機會再聊。寫程式,弄清楚問題才是主角。怎麼寫則是其次的事。要知道;問題只有一、二個,但解決之道則絕對不是只有一種方法的。對於寫程式的語言、工具或環境不熟,不用擔心,K一下很快就可以上手了,但放心好了,很快你就又會忘掉的,不用急著成為熟手,有需要時自然會的。(我習慣睡前靠在床頭滑iPad,睡前走一趟看板流程,雖然個人看板上都是些瑣事,但滑一滑總能讓人安心,好睡)。

廣告

Written by ruddyllee

2015 年 01 月 31 日 at 12:09:40

Scrum in four

leave a comment »

Scrum_41

Ken & Jeff 對不起,我把 Scrum 分成四塊了。》

.

採用 Divide and Conquer 的模式讓敏捷的觀念進階

上完Scrum 的課程之後要如何進階呢? 把它切成四塊就容易看得多了。從改變上、從學習的角度來進行思考可以看得較清楚些。

※ 從改變上

(1) 撰寫需求的方式要改。

(2) Breakdown 使用者需求到 Task及進行估算的方式要改了。

(3) 開發循環的方式要與工作流程配合了,記得要設計自己的 Task Board 來配合真正的開發流程。

(4) 展示進度給客戶看是為了確認開發方向及需求的回饋修正,檢討則是為了持續改善。

.

※ 從學習的角度

(1) 需求的探索方式 : 參考 Robertson 夫婦的 Brown Cow 理論,先思考如何改善既有的系統,老系統有甚麼讓人詬病的地方,先思考如何改善再邁向未來。由 How-Now, What-Now 到 Future-What, Future-How。

(2) 使用者故事是幾乎無法預估得準的極度商業化的描述,需要向下一個階層才可能做估算,也就是Breakdown 成Task才能做預估。此時務必採用使用者故事對照 User Story Mapping的技巧進行分階層式的思考模式。

(3) 學會將自己日常的工作流程轉換到工作白板Task Board上的欄位,並做好流程對照的動作。這種行為我們稱之「價值流程圖的對照」 Value Stream Mapping。

(原先的 Not-Checked out, Checked out, Done 有甚麼不好的嗎? 為什麼要改呢? 答案是: 想要把自己真正的工作流程上的訊息,清楚地反映出來)

(4) 在展示會議上向客戶請教學習,讓客戶用專家的角度說出來他對產品的真實運作外貌及內涵。讓客戶教導我們下一步該擁有甚麼功能,能自然行成了絕佳的共識。

(5) 回顧是自我學習的時機,我們很容易修正個人的錯誤,但團隊的缺陷就不是每個人都能知道該如何來修正,它需要互相配合與學習才有機會修正的。

.

※ 運用 User Story Mapping 來結構化 Scrum

使用者故事對照 User Story Mapping的最大能力,就是讓你知道下一步要做甚麼,這就是經由抽象化思考之後,便比較容易在結構裡面知道該補上些甚麼。我們稱之為將模糊需求結構化的能力。

scrum 剖析圖片

區分成四個部分的 Scrum分析圖

.

※ 個別加強,避免局部優化

由於我們把Scrum 的流程進行了切割,採用「分而治之」Divide and Conquer 的模式進行分析,因此一定要避免局部優化。指派團隊成員個別成立Study團隊,再由各組進行建議改善報告,然後綜合起來,這種做法可以避免局部優化,又可以增加團隊的和諧運作。

.

Scrum Process chart

scrum process

參考自 Scrumpapers 2012

 

Written by ruddyllee

2015 年 01 月 23 日 at 10:53:49

Agile Documentation 敏捷開發需要哪些文件?

with 2 comments

.

敏捷文件?  敏捷開發不是只要會動的原始碼就 OK了嗎! ?

.

客倌,不要開玩笑了! (關於敏捷開發不寫文件的傳說 — 那是神話!)

沒有文件的程式就像孤兒一樣,沒人認得出他來! 而沒有文件的專案,就像走私一批貨物一樣,少一樣或是多一樣也沒人知道。你會讓辛辛苦苦寫出來的程式像孤兒一樣沒人照料嗎?

再說;雖然原始碼是最佳的文件,但也是最不容易閱讀的文件。所以單單依靠程式碼來說明它自己是不夠的。單獨的程式碼是孤兒,沒有人知道它是做什麼的,更不知道該如何對待它。所以它需要一些足以代表它的說明。最好的說明當然就是文件囉!(簡報檔在此)

所以程式 >> 需要文件來替它作說明、更需要測試程式來保證它的好壞、也需要系統架構以便進行維護運作。

三種基本必備的文件:

  • 需求說明文件」: 作說明用

  • 系統概述文件」: 便利維護運作

  • 活文件」: 提供自動化測試的基礎

(請注意: 文件不是好的溝通工具,是不得已的時候才採用的溝通工具最好的溝通方式,是面對面站在白板前面的溝通方式,其次是通電話用聲音來溝通、用email,對溝通而言文件是單方面的、必需耗費較多時間又容易產生誤解的不良溝通方式)

communicationModes - 副本

文件不是好的溝通方式

在你開始動手寫文件之前,有幾件事必須先弄清楚:

 ※ 文件是寫給誰看的

很多人在寫文件的時候,忽略了自己準備開始寫的這份文件,是寫給誰看的? 他們可能是:

  • 客戶(對軟體專案而言,文件的第一大要求者是客戶。文件是客戶投資的回報之 一)
  • 自己(思考、規劃的草稿)
  • 團隊(成員相互溝通用)
  • 紀錄(手機拍照是絕佳的紀錄。經常有人是寫給老闆或主管看的,就當成是紀錄吧)

針對客戶你必須先弄清楚:

1. 誰是真正的客戶? 2. 他們需要的是什麼樣的文件? 3. 你要如何提供给他們? 4. 你要如何讓他們能夠很快的了解? 5. 你如何產出文件? 6. 你該放進去些什麼?

.

※ 文件是交接時的必備物件

程式設計師要學會如何把程式交接給自己。這跟學習物件化(OO)是一樣重要的事情,如果你找不到或甚至看不懂自己寫的程式,試問:要如何reuse呢? 又何必物件化?

最需要文件的人是客戶,再來就是程式設計師自己了。客戶是為了保障他的投資,我們則是重複使用(reuse)。千萬不要丟棄辛辛苦苦做好的物件化功能。所以一定要學會 Design for reuse.

re-use

Design for reuse 跟我們積極的作物件化(OO)是一樣重要的。 (參考自: http://www.cad.strath.ac.uk/~alex/aiedam96/ml-abstract.html)

.

版本控管文件程式

文件及程式是團隊共通的資產。對程式而言;極致編程XP首推,「集體程式碼共有」(Collective Code Ownership)的概念,讓團隊共同擁有程式,不但可以降低維護的困難,還可以讓大家看看那些厲害的傢伙是如何解決問題的。對文件而言;如同完美而簡潔的程式,令人心生佩服一般,乾淨而有序的文件,能夠贏得同僚之間的尊敬。(再說;沒有文件是很難看懂厲害的程式的)

 ※ 文件製作的價值觀: Good Enough 及四個準則

文件包含「概述部分」與「明確描述」的部分,二者都必需遵守文件的敏捷規範:

1. 一定要維持輕量化(lightweight)。 2. 產出文件一定要維持高品質,也就是具有:準確、最新的、高可讀性,足夠簡潔跟嚴謹的結構。 3. 撰寫文件,必需採用方便、易開發維護,並能夠產出高品質文件的工具。 4. 明確描述的文件部分,必須可以跟著程式碼做改變,也就是與程式同步。

usefulness - 副本

跟架構設計一樣 — 浮現式文件 Emergency Document

不能在專案一開始就把架構設計的工作做完,因為需求一直在變所以設計也必須跟著改變。這是敏捷開發較困難完備的一面。另外就是單元測試(Unit test)和測試開發(TDD),這二個被XP嚴格規範的程式員守則,隨時隨地做測試的高難度習慣,也很少人做得好。把他們引申到文件的開發上,你會發覺難度更高了,幾乎找不到程式設計師願意一邊寫程式一邊寫文件的,但這個動作便是所謂的「浮現式文件」 Emergency Document。寫文件的時機:

  • Before/ After
  • 撰寫程式文件的最佳時機,是在程式被認可為完成Done的時候,
  • 讓邏輯思緒做好最後的收斂動作 ,才是真正的Done。
  • (往往它可以幫你又找到許多邏輯思維上的缺陷!)

很少人會這麼做,他就好像要我們必須養成每天記帳的動作,大家都知道只有每天記帳才會知道錢都花哪裡去了? 可是你很難找到一個可以這麼做到的人。

 Just Enough 剛剛好就可以了

這是所有教敏捷開發的書本上都會提到文件製作的不二守則,然後就沒再說什麼了! 因此久而久之大家便把敏捷開發不做文件的神話當真了。其實是浮現式撰寫文件的嚴謹態度太難了! 而這些講敏捷的書是害怕強調文件製作會讓人們把注意力放錯地方了(該注意的是:正確的程式)。敏捷宣言第二條所說的「可用的軟體 重於 詳盡的文件」,就被拿來做為不寫文件的藉口。其實詳盡的文件雖然不如可用的軟體重要,但卻是一樣不可或缺的。

.

敏捷開發需要什麼文件呢?  light-but-sufficient

1. 提供 概述部分Big Picture 的文件。 「需求說明」文件: 能讓人很快弄清楚程式目的的文件。 「系統概述」文件: 能讓人很快弄清楚系統架構的文件。 (使用者故事對照 User Story Mapping 是最佳的文件之一)

scrum 課程

結構化的說明文件

2.  提供明確描述的活文件 Living document 。 解決「沒有銀子彈」的活文件。 活文件提供自動化測試的基礎。

「活文件」: 能夠伴隨著程式開發同步更新的文件謂之活文件。

given-when-then-1-638

以測試案例為文件

※ 邁向未來的文件

在你開始動手寫文件之前,請先思考部門或組織對文件的需求,運用未來的科技他應該會長成什麼樣子呢? 用未來觀去看待它,寫起文件來心情會好一些! 或許文件會像對程式的描述由像Word一般鬆散的文件製作 ,邁向結構化的多元結構,再走向模組化(Pattern)的樣式。

Document_new

結構化 Structured、模組化 Pattern

※ Big Picture 請參考 Agile Document (原書在此)

Written by ruddyllee

2015 年 01 月 16 日 at 09:11:42

User Story Mapping – IPO篇:串連使用者故事

leave a comment »

 

將使者故事串連起來

串連使用者故事的最大目的在藉著看清楚每一個使用者故事的輸入及輸出,

適當的消除不必要的故事。

(當然也有很多故事是獨立的,是沒有必要串連起來的)

使用者故事太抽象了,抽象的東西總是比較難以掌控,但使用者故事一旦不夠抽象又會變得過度明確了, 太明確就可能會落入規劃得太仔細,而規劃太仔細了就容易失去敏捷的能力,進而落入Scrum But 的危機。建議限制團隊編排User Story Mapping 的時間,一般3個月以內的專案,建議不要超過8小時(不用擔心會做得太粗糙了,真正的要注意的是要能持續改善)。

運用 Input Process Output 將使用者故事對照圖中的個別使用者故事關聯起來。(簡報資料在此)

17

.

如何進一步有序的分析使用者故事呢?

把他們連結起來 Gumming 使用者故事可以進一步明確化它的商業價值。運用IPO的方法: 首先把使用者故事的必要參數列出來,接著陳述如何去處理這些參數,然後把輸出的結果也陳列出來。

18

 

※如何繪製使用者故事 IPO ?

步驟一、首先挑一個使用者故事,把 Input列出來
步驟二、接著問自己,為什麼會存在這個過程,目的是什麼?
步驟三、把輸出列出來:說明這個過程將帶來什麼服務或產出?

重點在弄清楚:

  • 思考誰在使用這個過程的產品或者服務?
  • 過程:每項輸入需要發生什麼變化?

【對照輸出、入的價值】
使用者故事粒度的大小是影響整個開發流程估算不準確的最大因素,運用IPO的方式,可以看出由輸出、入的參數及處理Process的範圍看出相連接的故事之間大小的差異,多做比較可以相當程度的改善使用者故事的範圍。IPO能夠由功能面看出使用者故事那些應該做整合與應該刪除的無價值工作任務,能夠縮短開發的周期時間,更容易找出瓶頸所在,加以特別處理(例如: MVP: Minimal Viable Product )。

【範例】
使用者故事1: 身為一個愛好用手機拍照的人,我希望拍出來的照片可以自動同步到我的筆電裏頭,從此以後我就可以直接在筆電上做搜尋編輯。
分析:
輸入– 轉存照片,一般手機會存成JPG檔。但也有可能出現錄音檔(MP3)或短片(MP4)存檔的機會。
輸出– 存入筆電,需要設定、指定目錄嗎?存入同一目錄時是否要提供覆蓋功能? 是否依日期創建新目錄?

討論– 經過上面的輸入及輸出分析後就容易發現,有關這一條使用者故事我們大概需要問那些問題? 是應該採取收斂的態度還是發散追求較完整的內容呢?

使用者故事2: 身為一個愛好用筆電編輯照片的人,我希望可以從我的筆電裏頭快速找到拍過的照片,從此以後我就可以直接在筆電上做編輯。
分析:
輸入– 搜尋照片,或其他媒體檔案。
輸出– 找到照片後顯示它的詳細資訊(EXIF)。

討論– 順序型的使用者故事,前一個使用者故事將完全影響到後一個使用者故事的內容。可以考慮合併或再細分。

運用「輸入-處理-輸出」的IPO方式分析,可以發現對應使用者故事1的輸出應該相等於使用者故事2的輸入,他們是息息相關的,所以前一個使用者故事的決策將會直接影響到下一個使用者故事的功能,也就是他們是有順序性的故事。這是二個相依性很高的使用者故事,其中細節的決策與功能範圍的限制是這二個使用者故事相關聯的部分。

.

※ 在雲端時代裡我們常常會遇到類似的檔案傳送的需求,如果我們回歸來探討「到底客戶真正的需求是甚麼?」的根本問題,便很容易注意到,要解決客戶的真正需求,其實最佳解可能是直接幫可戶申請一個Dropbox帳號就解決了,沒有必要做一大堆深入的考量,當然還是要客戶同意了才行。

[參考自戴明 Deming 的 SIPOC 模型,SIPOC (Supplier 供應者—lnput 輸入—Process 流程—Output 輸出一client 客戶)是識別業務流程中關鍵風險點的分析方法。]

 

 

Written by ruddyllee

2015 年 01 月 12 日 at 12:04:01

User Story Mapping 使用者故事對照

with one comment

 《 對付需求模糊的好幫手 – User Story Mapping》

.

(想寫一系列的User Story Mapping的實際應用,打算從 breakdown 自己上的《Scrum課程》開始: 簡報資料在這裡。我採用電子化的App來做這件事,它是純HTML的版本,可以隨時隨地更新故事,下面那張圖正是運用它EXPORT的功能所產生出來的。對時時需要做規劃的人而言;省時、省力,真是棒極了! )

.

User Story Mapping 它能夠結構化使用者故事,好處多多,還能告訴我們:

  • 專案該從哪裡開始做起(What to build first).
  • 增強學習,鼓勵迭代開發(Encourage iterative development)
  • 界定專案範圍(Scoping the project)
  • 易於規劃專案(Planning the project)
  • Backlog疏理及優先順序考量(Prioritizing and grooming the backlog)
  • 專案進展的可視化(Visualize project progress)

(尤其能處理模糊的需求,它採用的是功能強大的 Hierarchical Planning 技巧,"階層“在這裡再次的展現了它的魔力)

.

迅速展開的階層模式,能解決模糊的需求

其實我最喜歡它的是階層式(Hierarchical)的規劃模式,這是早該出現的使用者故事規劃方式了。大家還記得IBM早期作業系統的規劃文件嗎? 一種叫做 HIPO(Hierarchical Input Process Output)的文件製作模式,它被運用在描述OS/360、S/34/36/38 …等作業系統上。是1970年的古董了。凡是我經手的委外開發案,我一向採用HIPO來做交接文件(簡單、好用又不出狀況)。User Story Mapping (使用者故事對照)與HIPO 確實具有異曲同工之妙。

 

用它來做需求規畫可以讓原本顆粒較大、比較難以下手的需求,迅速的明確起來(試了幾回,效果好極了)。尤其是配合使用者故事的標準描述Template.

As a <role> , I want <goal/desire> so that <benefit>

完全相同,都是"以使用者為出發“,真是再適合不過了。描述: 第一層、針對該使用者(角色),第二層、是他的目標(主題),再依該目標所需要的第三層、活動及完成該活動所需要的第四層、任務來層層相扣,形成大故事包含小故事的情境。

下圖就是大故事包含小故事的情境,而我們現在所做的描述動作正是在作反過來用對照的訊息來說故事,這是它的另一個好處(参考資料)。我試著把上課的內容依聽課的學員種類,規劃如下:

scrum 課程_0

Scrum 課程的Story Mapping

上圖是將Scrum課程的內容依照:

第一層是使用者: 區分成共通的部分、主管級、資深工程師、工程師。

第二、三層是主要題目及細項: 包括

1) 敏捷觀念;極致編成、SCRUM及看板方法。

2) Scrum原汁原味,採用2012 的Scrum Papers.

3) 需求分析;BrownCow理論說明: 採用 Robertson夫婦所撰寫的Mastering the Requirements Process: Getting Requirements.

4) 召開Scrum四種會議的練習:      Planning meeting/ Standup meeting/ Review meeting/ retrospective meeting.

5) 繪製 Scrum 流程練習: 請學員分別以目標、開發作業、特殊目的做主題繪製Scrum Process圖。

6) 使用者故事練習: 產品負責人做需求描述、Scrum Master及團隊成員做需求描述。

7)  讀書計畫練習: (分別參考以下書籍)

  • 敏捷武士:看敏捷高手交付卓越软件
  • 硝烟中的Scrum和XP
  • Scrum 精髓
  • 使用者故事與敏捷開發
  • 敏捷教練
  • Scrum 捷徑
  • 30天軟體發展:告別瀑布擁抱敏捷
  • Succeeding with Agile:Software Development Using Scrum

8) 針對主管的敏捷項目說明:

  • 複雜專案的定義 Stacey Matrix
  • 敏捷式的專案估算
  • 敏捷合約
  • 敏捷文件
  • 制定簡單的團隊規範
  • 敏捷風險管理

9) 針對資深工程師:

  • 敏捷式的估算
  • 結對編程   Pair Prohgramming
  • 專案測試 – 測試案例 Testcase

10) 針對工程師:

  • 工作項目的估算
  • 使用者故事的拆解練習
  • 單元測試 Unit Test

第四層是參考資料:

1) 針對主管: 說明”從Reifer的十個知識點”及Just Enough Software Architecture.

2) 針對資深工程師:” Scrum+Kanban敏捷專案管理培訓” 加上“Fit for Developing Software Framework for Integrated Tests”.

3) 針對工程師: 番茄工作法 The Pomodoro Technique","Code Simplicity“,"C#測試驅動開發“,"修改代码的艺术"

.

» 使用者故事對照的一個特色就是在你對照完成之後,可以反過來;按著表格把一塊一塊的故事說一遍,採用這種方式跟客戶進行確認故事的描述是否正確(這ㄧ點很像過去做系統訪談時,最後總要把內容疏理ㄧ遍,讓客戶確認)。例如:上圖中所分類的三種使用者,在第四層、参考資料的地方,1) 針對主管:我們取用Reifer的十個知識點作参考。目的是為了說明透過過去的統計資料,採用Scrum這種開發架構,在那些範圍適用,而那些地方較不適用。

 .

故事先說到這裡,下一篇我會把剛剛完成的看板方法的書本章節,也來用 User Story Mapping 對照一下,經過對照之後,整個課程看得讓人神清氣爽,相信我你也會喜歡它的。

Written by ruddyllee

2015 年 01 月 09 日 at 18:36:03

需求不正確的描述是專案失敗的最大因素

leave a comment »

研究表明 80%~85% 的專案開發的失敗歸咎於需求的不正確。有經驗的開發者都知道,管理軟體需求是比技術實務更艱難的挑戰。

By: Don Reinertesn

(The Principles of Product Development Flow: Second Generation Lean Product Development一書的作者)

雖然我們都知道這個道理,但是我們還是任由經驗不是很豐富的PM或是資深工程師單身匹馬的去做需求訪談。這是誰的錯呢?

3042951-fm-b

簡體版2015/01/01出版(國內已有該書了)

下午與幾位講師在討論第二代Lean精實思想的時候,Google 搜尋到這本 Agile Software Requirements,是Dean Leffingwell 所著,Don Reinertesn推薦的那本厚厚的書。感慨自己講了十年的 Scrum及 Kanban的課程了,卻沒能把需求描述得扎實些。回想到上課時只能讓學員參考 Mike Cohn的「使用者故事與敏捷方法」那本經典老書,然後做一些使用者故事的基本拆解練習,玩一下估算Poker 試著讓學員體會敏捷開發的歷程。然而這樣就夠了嗎?

 

※ 有些東西是每回都上不到的:

  • 敏捷開發需要那些文件?

  • 如何當一個 proxy Product Owner?

  • 需求開發的 Brown cow理論。

  • 大型系統的使用者故事拆解及Mapping.

  • 大規模敏捷開發框架 SAFe.(一個需求管理的敏捷方法論)

  • 精實開發七大原則及精神在 Kanban上的實際運用。

  • 作 Scrum But 及 Agile But 練習,然後進行分析解說。

  • 展示TFS 由 portfolio- Epic- Feature到User Story Breakdown的操作。

  • 講解Spike solution(刺穿)。

  • 講解敏捷測試的作法。

還有一些上完課後,學員回去後不知該如何處裡的實質問題,例如怎麼做第一次專案的估算?需要哪些文件? 如何跟大老闆做敏捷式專案報告? 等等。

 

但其實講師們都早有共識,不管上課的時間有多長,總是會有一堆講不到的東西。或許你應該為自己沒講到的感到懊惱。但實際上;還不如讓學員們學會自己判斷「怎麼做才是敏捷」來得重要。

Written by ruddyllee

2015 年 01 月 05 日 at 16:57:21