施行「敏捷開發」要從那裡開始?

這是一系列文章的開始,由於經常被新的客戶問道,您作顧問這麼多年一定有一些模式可以讓我們參考的。我的回答是:「當然了!」但心裡却總覺得有些虛虛的。案例是累積了許多,但把它們變成Pattern!這確實是從來沒有想過的念頭。原因;因為沒有一個顧問案例會一模一樣的,更何況大家的組織大小與文化更是有著很大的差異(新創公司跟一般的IT資訊部門實施起來就有大不同),要想歸納成一個放諸四海皆准的模式,不太可能吧! 回顧自己的職業生涯,在進入職場後曾經換過20幾個工作,從事顧問後也顧問了十多家廠商。為什麼就不能勇敢一點,嚐試看看呢! OK,或許能協助那些自己很想協助但卻始終顧問不到的公司也說不定(哈哈! 報價是一種技巧),所以就從先把他們寫出來開始。

 

{此時自己正和老婆在美西旅遊,這是三個星期的假期,難得輕鬆。這個roadmap我稱它為「Scrum 顧問 Pattern」,接下來的說明就是圍繞著下面這個 roadmap,它交叉了我對Scrum及Kanban 方法的理解及運用(每看一次這張roadmap就會有好多回憶湧上心頭,它看起來平淡無奇,但有多少經歷跟陷阱隱藏在其中,偷偷跟你說,雖然看起來我是在實行 Scrum 但其實我一直是採用看板的Column 來調整開發團隊的工作流程的。 哈哈! 這些招式有多少功用我都太熟悉了,而人老了就是容易多愁善感),我盡量長話短說,畢竟這不是在寫書。但必須聲明一下,放在 Blog上的東西完全歡迎大家拿去用,它是屬於大家的。即使你冠上自己的姓名也會得到我的祝福的。}

 

 

想要施行「敏捷開發」要從那裡開始?

 

敏捷開發不只是一種開發方法,更是一種觀念的改變。如果只是學習一種技能,只要多下功夫就一定能有回報,但觀念要作改變就比較難了。改變觀念,其實就是一種「變革」,試想要從接受變革開始到去適應變革,然後能夠發揮它的效益,這就需要一定的時間才能作到。那該從那裡開始呢?

001 Agile training roadmap
包含二個Sprint的Agile Training pattern. 一般而言執行他需要一個月,但最長我曾經 run了一整年。  (因為他跟組織文化息息相關)

 

 

 

第一篇、從看見既有的工作流程開始

二個目的:

  1. 減少推行Scrum的阻力,並協助工程師取得盈餘時間。
  2. 提前面對需求。

.

看見 (Visualize) 的力量非常之大(這一點從iPad/iPhone誕生以來,各種媒體就在不斷的教導我們視覺化的力量,尤其是在使用手冊與UI介面的變化上,紙張版的使用手冊真是越來越少見了)。透過網路的力量,造成使用者界面的突飛猛進可能是這個時代最大的改變來源,許多的前端工程師因此應運而生,而這股熱潮將不會隨著時間的推演而逐漸平息,它反而更突顯了客戶視覺體驗的重要性,而他也是產品本身價值重要的一環。我個人一直視「看得見」是一種務實的行為。你可以試著把一些平常總認為稀鬆平常的習慣,試著務實的分析一下這些動作,把他們記錄下來之後讓自己看見這些活動是否有足夠的效能表現,讓紀錄下來的時間花費告訴我們它們是不是一種浪費,然後依此來做改善,增進自己的工作效率。這是看得見與務實能給我們的建議(一種自我的回饋),千萬不要忽略了。

我們總是在看見了浪費的真正原由,才知道要思考如何來改善它。因此要先從看見現在的流程開始。(註: 我之所以挑「浪費」來作說明,除了浪費是精實開發最重要的一條原則之外,再來便是他是團隊提升效能的最佳開始之處,其實我是在替工程師找出他工作上的「盈餘時間」)。

熟悉看板方法的人(或是看過我所寫的看板方法書的人)大概都知道我為什麼從這裡開始,因為這樣作阻力最小,讓工程師由他們既有的流程開始,可以將既將產生的變革先置之腦後,先把自己習慣的工作流程畫出來,用價值流程圖的模式畫出來,然後再把每個步驟及步驟跟步驟之間所需要消耗的時間標上去。這個時候,便可以一目瞭然浪費的所在了(就是那些對我們的工作沒有產生價值的行為或等待,當然是浪費了)。

 

我選擇「看見」作為起手勢,還有另外一層意義就是想要提前來面對「需求」。

 

Scrum 缺少處理需求的前置方法

大部份的開發團隊輕估了需求是否備妥的重要性,也就是所謂的 Definition of Ready(DOR)。執行敏捷開發時,如果你覺得團隊的開發速度始終沒有起色的話,第一個值得懷疑的便是DoR 了。Scrum 沒有強調DoR的重要性,但在實作時却強烈的依靠後續的會議來對需求作檢驗, 這一點可以由最近的refinement meeting 越來越受重視,就可以看出它的重要性。

.

讓開發工作少作白工

敏捷開發採用使用者故事(User Story)來描述需求。目的是它夠抽象(抽象的目的是減少細節,減少我們對未來、還不確定的東西作預設性的假設,說白了就是胡亂作猜測),它的目標是夠抽象又簡單到可以直接寫在小小的卡片上、便利作交談討論及確定如何驗證它。

而這裡我想追求的是提前在開發作業之前的解題動作。我長期把它稱為是在抽象與明確之間解題。你會問我是嚐試在開發作業之前就把事情都想清楚了嗎?這不正是傳統開發法所想作的嗎!不,當然不是。我的意圖在把需求說清楚,也就是用說故事的方式把故事講的圓滿。要知道,如果是一個好的創意,則大概在說故事的途中我們已經能夠體會到了(就是有驚歎聲跟賀彩聲)。當然,如果故事實在不怎麼樣的話,說完了的時候,大家也應該曉得沒太大作為了(不相信! 請在下一次有好 idea 出來的時候,大聲講給大家聽,看反應的好壞就是他該得的分數了),其實idea如果不講出來就會變成是空想了,空想是很傷的,作多了會分不出來是空想還是幻想,還是多多講出來吧,如果連需求都講不好的工程師,你相信他能把需求作好,才奇怪了。

有很多方法可以幫我們來看清楚一點「需求」的真貌,例如:最小可行性產品MVP(Minimal Viable Product)就是其中一種。它的基本觀念跟測試開發的理念很類似: 試著作出一個最基本功能的產品,然後在取得客戶回饋的數據後進行修正。這種作法對新創公司很合理值得去作,但對大部份的IT資訊部門就不見得合適了(敏捷就是這麼回事,永遠沒有放諸四海皆準的事兒,一定需要調整的)。

 

下一篇、Definition of Ready: 工程師要學會如何講好故事。

接下來要來面對需求了。來談 DoR: Definition of Ready 需求的描述資料是否備妥? (它可以說是影響開發速度最大的關鍵,千萬別小看它了,這是我最近一年以來,花掉最多時間在處理的事情之一了)。

(上面的文章中有很多專有名詞都沒有多作解釋,在《看板方法》的書裡頭都有。如果還有問題的話,就請問吧!)

 

 

先讓英雄救貓咪

 

未命名
這是一本很棒的編劇教學手冊,作者: 布萊克.史奈德。

 

(這裡不打算介紹這本書,我只是要把從書裡面學到的東西,講出來。當然我一直相信,我們是自己人生的導演,所以就一定要有好的劇本囉!)

 

英雄為什麼要先救貓咪呢? 目的只為了在電影一開始的時候,能夠快速的朔造英雄的形象。而執行Scrum的計畫會議也是要如此。

 

Scrum的計畫會議;要由PO說故事開始

我總是要求需求提出者,也就是PO(Product Owner),在計畫會議(Planning Meeting)一開始時,不要直接把使用者故事一個一個陳列出來,隨後就開始平鋪直敘的進行討論。要倒過來;要把感情放進去的好好地說一段完整的故事,一段能把團隊拉進任務裏頭的故事。首先,要做一段 200字以內的故事描述,試試看工程師是否被你感動了,然後團隊決定主動的協助你完成任務。也就是,嘗試把要討論的個別存在的使用者故事,都濃縮在這段要描述的故事內容裡。目的正是;先讓英雄救貓咪。(讓團隊清楚的知道為何而戰,這一段衝刺的真正目標在哪裡?)

 

PO常常會反問我,所有的使用者故事都要放進去嗎? 這樣會有一點困難,且會有一點不順暢!

 

 

老實說;這正是我的目的,那些串不起來的,很難硬塞進來的使用者故事,他們通常就是那些比較不重要的需求了,或是完全屬於另一個功能區塊的使用者故事了,所以當然會比較難融入到一個完整的故事裏頭。這種作法,可以讓 PO在會議之前的準備工作中,透過自己編寫故事的時候,自行意識到要做的這些使用者故事,是否真正的解決了使用者的需求,做完之後是否就能夠得到真正的價值。(另一個好方法是透過製作影響地圖 impact mapping的方式,讓團隊弄清楚 Why? 也就是為何而戰,Who?我們要價值給誰以及How? 如何交付價值)透過這種思維的自我回饋,先做一次優化,對使用者故事先做好一定的區隔。

 

範例: 由po以故事的方式描述了他的需求。

83

故事開始: 從先詢問在場的學員,你(妳)們出遊會拍照片嗎? 會拍很多照片嗎?

那拍完的照片什麼時候會看呢?

(這是一個家庭出遊後回到家中齊聚一起觀賞照片時的景象)

84

 

使用者故事已經隱含在上面的整體故事裡了

 

溝通是為了造成共識

其實要求PO講故事的目的還不只於此;因為使用者故事的目的就是為了描述需求,然後對需求進行溝通討論,進一步造成使用者與開發人員之間的共識。而以這種講故事的方式作為開始,對需求的探討而言會有一個比較好的融入感和完整性。當然,故事說得好的時候,效果自然也會好上許多。這種作法,比起一個一個使用者故事的表列式討論方式要好上許多(離題一下,這也是 refinement meeting最為人詬病的地方,大家只是想快速的對個別的使用者故事進行大小估算與討論,很容易忽略了這個衝刺(Sprint)增量的目的,也就是它所應該有的整體性目標)。

 

我們都知道;要想在演講的前5分鐘就抓住聽眾的心,只有一種方法,就是講一個感人的故事。PO的任務就是要把需求明確的轉達給大家,讓團隊有感同身受的意味,自然的把任務當成是自己的事,為完成任務來負責,所以就該從故事開始囉!

 

下一回;我們來談「先讓英雄救貓咪2」 – 老實說,二版更精彩! 它對軟體開發更為有用。你相信嗎?

 

 

2015 Scrum process chart

2015 Scrum Chart
2015 Scrum Process Chart

.

2015年 Scrum 課程將採用的 Scrum Process 說明圖

繪製的目的是希望上課時看著這張圖就不會遺漏該講的一些重要資料。整張圖塞的滿滿的根本看不出重點。請不要擔心,上課時我會拆分開來對各個部份做加重說明的。在這裡我也會持續加入說明,便利學員們做溫習用。

.

中間那朵雲是標準的Scrum

簡潔的Scrum架構,包含了3 種角色(Product Owner、Scrum Master 及Team團隊),4 種會議(最重要的計畫會議、每日站立會議、展示會議及回顧會議),3種產物(產品待辦、衝刺待辦及增量)。Scrum的特色是淺顯易懂,規則很少屬於輕量型的架構,但卻是很難精通的。它是屬於經驗主義型的開發架構,因此最可貴的便是執行時對經驗的繼承及對客戶回饋的檢討與回顧了。就是這一點造成它很難精通與駕馭,所以不管你曾經帶過多少成功的Scrum的團隊,你總是得戰戰兢兢的小心處理每個 Scrum 的過程,這就是為甚麼需要一個專職的 Scrum Master的原因。

畫成雲的目的是要體醒大家,這是雲端運算的時代,無遠弗屆的地域關係讓委外開發更加便利,成本也更加低廉(對廠商而言就是競爭更加激烈,利潤更難拿捏),開發的時間上也成了無時無刻都在進行開發與整合,溝通與需求的確認成為了專案是否能成功,最最重要的一環。

大雲圖形的左上角有一朵小雲,這朵小雲所指的是「社交網路」Enterprise social network,這是暗示網路時代對團隊的開發做業有著相當的影響作用。如果你尚未運用到的話,要加油了!它已經明顯的成了另一類高效的溝通方式,一種不需面對面又能無時無刻追蹤工作、表達關懷 …。一種團隊的無線集結模式,有趣的很!

.

Scrum in four

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

 

先學 Scrum還是 Kanban?

先學寫程式還是先學測試?

對於初學者或新人而言由測試開始是再好不過的了。

一旦寫程式的功力夠了,製造缺陷的機率自然會下降些,這個時候再來寫程式,才不會害己害人。

原因很簡單;因為缺陷是程式沒寫好所造成的,所以要學寫好程式,先學如何測試別人的程式,先看懂別人的程式,再來嘗試寫好程式,似乎會好一些!

.

先學 Scrum還是 Kanban?

大部份的時候;你可能完全沒有選擇的餘地,這可不是老天能安排的,而是看老闆的安排。

從屬性上來看:

Scrum 容易探討未知,處理複雜專案,拿來開發新東西威力無比。

Kanban 是教我們如何自我檢討,可以迅速消除浪費,而得到好的效能。

如果你是開發團隊,當然是先從Kanban 開始。先檢討好團隊的基本動作,整頓好了再來開始作新的東西,從事開發的動作,自然少浪費。這是精實Lean 的好處。

(有太多開發團隊,只曉得一意往前衝刺,忽略了自己在開發上的浪費,這會造成很難走得久遠,尤其是Startup的團隊尤其如是。)

如果你是維護團隊,當然是先從Kanban 開始。視覺化是最大的亮點,團隊可以看見工作上的維護流程是一件相當有價值的事,針對個人亦是如此,人們常常因為養成習慣了,就一直持續做同樣的事情,很少會有機會回過頭來檢討,哪裡做得浪費了應該改進。看板方法的第一步: 視覺化。正是團隊可以拿來持續改進的基礎。這一點對維護工做更顯得珍貴。

如果你是測試團隊,當然是先從Kanban 開始。看的見以後才可以減少猜測的比例。測試團隊在擬定測試計畫之前,一定要對待測的產品或程式有足夠的了解,才可能開出實用的測試案例,不至於浪費大量的測試資源。或做了過多的重複性測試。

.

(你可能覺得奇怪,為什麼都是 Kanban Method 先行呢? 其實原因很簡單,因為它"單純“,不是簡單喔! 它沒有想像上的簡單,因為它可以演進得很有深度,但是它的目的很單純,就是追求效能。不像 Scrum 的目的,是要來應付複雜的專案開作業,基本的方向就完全不一樣的)

.

將看板方法融入Scrum的開發過程才是上策

看板方法是一種流程控制,他不是一種具有完備基礎的方法學,雖然他的潛在發展相當可觀,但目前他仍只是一種提供我們產出高效能的流程控制法而已。他缺少需求描述、沒有完備的會議規畫、少了團隊職責分配,少了很多很多軟體開發上該有的措施,這一點讓他看起來十分空泛,但就是這個特性也讓他十分適合融入其它開法方法中,尤其是 Scrum。

看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發法 Scrum 的時候發明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發法而已。卻由於他熟悉限制理論的運作而開創了看板方法Kanban Method。做出了對敏捷開發的精實Lean 一支的重大貢獻。也就是這樣的典故,讓看板方法Kanban Method可以十分容易的融入到Scrum的開發過程。

著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書),書中就大量的採用 WIP(Work-In-Process)的觀念,實際的運用在工作看板上面。讓Scrum在開發流程上減少了許多的浪費現象。

 .

※ 看板方法先行

因為它可以減少組職在推行敏捷上的阻力,它能讓工程師以最好的節奏持續進行開發工作。又能將精實觀念帶入團隊運作。

※ 融入Scrum的開發過程

因為看板方法的流程控制方式是用來提升Scrum運行迭代開發時的效能。讓 Scrum 能真正用來克服複雜的軟體程式開發過程。

.

Scrum 的目的在解決複雜的軟體開發作業

許多人誤把Scrum 當成加速軟體開發的銀子彈。這是錯的! 他的目的不在加速開發(加速開發工作是開發工具的廣告詞),它的目的是在解決複雜的軟體開發作業,讓它提高成功率。在協助團隊能夠提供給客戶真正要的產品,且讓他在市場上具有實際的競爭力。這一點也正好是看板方法所缺少的。

開發團隊千萬別因為實施了看板方法而誤以為需要把 Scrum 拋棄了,這是一種錯誤的想法,讓他們相輔相成才能有更大的效益。下一回就來談"運用看板方法的十個不應該放棄 Scrum的理由"。

.

測試難還是寫程式難

讓我們回到一開始的主題,到底是測試難還是寫程式難? 其實正確的說法應該是寫出正確無缺陷的程式難! 實際上程式設計人員在寫出程式之後,也必須透過測試,才知道他是否能正確運行。因此"寫跟測"實質上是一體的二面,一樣重要。

至於Scrum 與 Kanban Method 之間,則都是通往敏捷開發的路徑。已經在使用 Scrum 作開發工作的人士,學習 Kanban Method 可以讓他們進入精實的領域,有所依據的持續追求更好的效能。先學會Kanban Method 再跨足 Scrum 的人呢? 則可以看到敏捷開發在處理複雜問題上的具體方法,真正懂得去追求效能之外的正確性與方向。

先學 Scrum還是 Kanban? 二者之間並沒有衝突存在,端看你現在最需要的是那一樣,那一樣就先來吧!

給 Sprint 一個更有意義的名稱

Sprint 絕對需要重新命名的,但也不是說 Sprint 1/ Sprint 2/ … 這種命名方式就不好!? 採用預設的方式能有良好的順序性,這是命名時不可缺少的資訊,也足夠區分不同的 Sprint了,算是還OK的。

但這種命名的缺點是它提供給Scrum團隊或相關人士的資訊太少了,很容易讓人感覺麻木…。

 

註: 感覺麻木是Sprint 團隊效能最大的隱憂之一。

 給Sprint 一個好名字

Sprint 需要朝氣,要有能一眼就被看出團隊在這個衝刺區間所想達成的願景。同時,這也能讓所有參與者時時記得目標及任務所在。不論這個Sprint執行的好壞都能讓人印象更為深刻。所以值得團隊在Planning meeting 時花一點時間來決定Sprint 的名稱。而且討論得越激烈越好,要知道情緒的提升對開發工作是無價的。這便是所謂的『膽大心細模式』。

註: “膽大心細模式": 這是參考《學徒模式》一書對模式的運用方式而產出的一種容易讓人一看便有所體會的模式命名。這種模式命名方式對敏捷開發的衍生式設計有著極重要的影響(賣個關子,有機會會在課堂上說明的)。在這裡我是假借一個為即將展開的Sprint的命名進行會議討論,藉此來激發開發人員的士氣,進而提升團隊效能,讓人能夠更勇於嘗試創新,並透過團隊參與人員較多的情形下,使得考慮變得較細心些。

 給Sprint 一個有意義的名字

例如:

<年份> CW<日曆上的開始星期數>-<結束星期數><目標>(<版本>)

2014 CW 20-22: Define project spec (v1.0.1)

2014 CW 23-24: Create the first spec (v1.0.2)

...

(CW: Calendar with Week numbers)

這個常被使用的命名法,提供了:
即將完成工作的內容及工作的簡單描述,所附帶的版本別則明白的表現出順序及規律,相當不錯。
提供大家做參考。

(相關資料請參考: How do you name sprints in your projects? )

手頭上的工程師效能不彰,如何是好?

* 如果可以加人的話,在你感覺到專案有壞味道出現,也就是負責開發的工程師程度不佳時該如何是好?最單純的做法是,配一個資深對這些技術熟悉的工程師去協助開發,這應該是較簡單的解決方案了。

還記得下面的Stacey Matrix 嗎? 加入資深做過這件工作的工程師,能夠有效降低技術的危險性,成功的將Technology縱軸向軸心拉攏,使的專案趨向簡單易成功的區塊。但,萬一專案已經進入尾巴也正在趕工亟需要收斂的時期時,此時加人反而會增加開發的時間,又該如何是好?  這時候,只能做的就是守住整合測試再加上針對每個模組進行單元測試及code review,遇到了!累人啊.

image_thumb

Stacey Matrix

越早發現問題可以當下就立即加以處理最好,一旦錯過黃金處裡期之後,大部分專案就只能依照專案的特性,死守測試案例囉! 然後眼巴巴的期待他能有達到水平的驗收標準(當然,先做風險評估! George Fairbanks 所寫的 恰如其分的软件架构 ,請特別留意,輕易的妥協與降低驗收標準只會延長對需求者的折磨,這是下下策)。

※    沒有放諸四海皆準的答案,但若能從專案的技術面來思考這個問題會更有價值,因此把問題從新的描述如下:

我把困難度先放大10倍,也就是當專案開發遇到:

  1. 專案開發的技術較艱深(例如Embed system開發作業)。
  2. 開發模組多,時間又長一些(例如 1到 2年)。
  3. 開發工程師多到數百人,而大部分為二到三年經驗的工程師,而離職率又十分頻繁時(每個月都有舊人離職,新人報到)。
  4.  技術難以銜接,交接時間過長,開發進度難以掌控。

身為管理人員在遇到這樣的情境時,當如何是好?

從降底每個程式的複雜性做起,針對問題運用架構來解決它

有時乍看下,工程師效能不彰與較大專案開發團隊不易管理好像都是管理上的問題,也好像與技能不太相干。但是我們如果由技術層面來解題(替換老是想用管理層面解題的思維),換一個思考的角度反而可以解決許多的問題。基本上我覺得,程式開發若是能變簡單了,維護也變容易了,用架構將上面的問題難度下降後再交給管理方法就更容易克服了。因此降底程式撰寫的複雜性或許才是治本之道。

Ripple Theory 漣漪理論

一、較不靈光的工程師適合處理較簡單的問題,較成熟的工程師適合處理較複雜的模組。

這就有如漣漪(Ripple)一般,在中間的部分較深有如專案開發技術較困難的部分,這部分宜由較有經驗的工程師負責。而逐漸向外擴張之後,波紋變淺時就好比較小較簡單的程式模組開發一般,適合經驗較不足的工程師處裡。

ripple

二、 核心部分假設由工作流程引擎來負責(虛擬引擎的概念稍後再談,也就是說我們可以跟開發 GAME的程式一樣,先假設有一個適合開發平台使用的工作引擎存在,老實說 WF4.5 又快又好用),其餘外圍的部分就都是所謂的工作模組(關卡),真正執行流程是交由工作流程引擎依照工作流程來進行。以一種模組化的開發模式來進行程式開發,程式員只負責開發模組,而模組則有小有大,這將大大的降低開發的複雜度,使得維護變得容易,對工程師的經驗素質要求也就跟著下降了許多,此時較不靈光的工程師適合處理較簡單的模組,較成熟的工程師適合處理較複雜的模組。如此也就減少了工程師頻繁離職的負面影響。

因為它具有Ripple的味道,所以我把它取名為漣漪效應(說來話長,當年在寫完第一本工作流程引擎的書之後,就深深被模組化能夠相當程度的降低程式coding的門檻所吸引,但敏捷度不佳…沒想到今天它又復活了!)。

Agile Model Driven Development (AMDD) 敏捷模型驅動開發法

我想先說明一下,這裡討論到的AMDD開發方法,並不是我要開始大勢鼓吹這種開發法(純粹是為了解題,但誰又能說它不可行呢?!),就好比接下來要談到的核心部分的工作流程引擎一般,它也可能是虛擬的,我們純脆只是用這種模組化的方式來解題。我只是想假借這種模組式的程式架構方式,拿它的架構模式來解題,適度的降低程式開發的困難度,達到解題的效果。千萬要記得Brooks 大師所說的話,這世界是沒有銀子彈的。

模組式的開發方式本來就具有明確化並可以相當程度的降低開發複雜性問題的能力,但模型驅動開發MDD是一種一開始花時間把問題想清楚了的傳統開發方式(先畫流程再寫程式的專案開發方式),是一種一旦遇到需求有較大的變化時一切便要重來的開發方式。這種開發方式對運用過工作流程引擎來撰寫程式的人都很熟悉,它能把複雜的問題適度的抽象化了。

AMDD 不錯用的幾個理由

1. “project planning needs”

  • 正好補上了Scrum在設計上對前置時間未能提前做設計的缺陷。
  • 讓衍生式設計有一個起始基礎。

2. 提前看到 Technical risk. 

花一點時間建置流程及模組,可以適度的看到一些技術上的風險。

3. 對需求抽象化的巨觀審視

運用模組化的技巧,讓抽象化的思維適度的降低解題的複雜度。

4. 提升問題的品質 

模組化可以讓問題更加明確。

5. 提升使用者與開發團隊對產品有相同的了解

簡單的工作流程可以作為使用者與開發團隊之間良好的溝通依據。

我想在這裡先打住,接著我想把"衍生式設計“與"漣漪效應“之間的關係說明一下,再加上 Mary Shaw 的抽象解題法,應該對大家比較有幫助 … 陽光露臉了: 騎車,待續!"

敏捷書單 — 光碟裡的書目

( 回覆北京 、上海的學員: 這是在光碟裡的書目)

《硝烟中的Scrum和XP》导读

Agile Project Management With Scrum Ken Schwaber

Agile Estimating and Planning

Essential Scrum

Just Enough Software Architecture .George Fairbanks

Kanban And Scrum

Kanban

Lean from the Trenches(精益开发实战)

Succeeding with Agile Software Development Using Scrum .Mike Cohn

Scrum in Practice

Scrum 实战(Scrum in Action)

Scrum 要素

Scrum 敏捷开发产品管理

Specification by Example(实例化需求)

Executable Specificat​ions with Scrum A Practical Guide to Agile Requiremen​ts Discovery

敏捷估计与规划 Agile Estimating and Planning.Mike Cohn

敏捷软件开发:原则、模式与实践

敏捷软件开发工具 — lean software development Agile toolkit. Mary & Tom Poppendieck

敏捷个人-认识自我,管理自我

敏捷项目管理

敏捷开发知识体系

敏捷教练

敏捷迭代开发

迭代软件开发项目管理

管理 3.0

软件项目管理者迈向敏捷式的桥梁

软件开发成功路线图 — 敏捷模式

软件工艺

大规模敏捷开发实践

极限编程XP

解析极限编程拥抱变化

精益思想——消灭浪费,创造财富

精益软件开发管理之道

重构,改善既有代码的设计.Martin Fowler

项目百态

人件集 .康斯坦丁

与熊共舞——软件项目风险管理

持续集成软件质量改进和风险降低之道

浮现式设计 Scott L. Bain

领域驱动设计与模式实战

再談scrum專案的時程預估

明明知道軟體開發工時是絕對估不準的,那為何還要辛苦的計劃估算呢?

《  話說朋友有難,我們當然應該義不容辭的挺身而出才是。但習慣作救火動作的我,這次卻是去放火的。怎麼說呢?事情是這樣的;軟體公司在議價前夕,對專案唯一有經驗的scrum master卻離職了,這個標案被指定要採用這家軟體公司不是很熟悉的silverlight技術來開發。老闆(就是我那個老朋友了)在不知如何是好時找我來幫忙。你說,該幫他預估時程嗎?所以我始終覺得是來放火的。我搭高鐵南下,大概只有5/6小時的時間可以從了解專案內容,分析規劃到交卷。好刺激,人生嘛~ 就是這麼有趣! 》

首先要弄清楚的是,花這麼多工不是只為了搞清楚開發的時程或是何時可以完工而已。 其實專案成敗的「風險」以及多弄清楚有那些「不確定的因素」才是重點。對我們這些專門推廣scrum的人而言,有時教導才是最最重要的。(說到這裡,難免要報怨一下,Scrum對軟體開發的規範太少了,是個非常輕量化的開發架構。所以經驗與過程的教導便成為十分重要的事,尤其在開發專案中,將會面臨到的各式問題,不但問題本身會相當有挑戰性,也經常扮演著專案成敗的重要因素。但這正是它有趣的地方。

話說回來,依據Mike Cohn 所述,時程估算的三種方法:

1. 依據團隊在相關專案上的歷史開發速度。

2. 針對目前的專案,就實際上執行一個sprint來做做看,然後依據這個sprint團隊所表現得到的速度來作預估。

3. 給自己一個好理由,用猜猜看的方式來估算。

這是Mike Cohn 給的建議。但很不幸的是,我們經常都在指導新的開發團隊,他們又總是在接沒作過的工程技術,因此前二種方法好像都派不上用場。最後只好來玩猜猜看的遊戲了。這個時候我還是習慣、也比較喜歡拿IBM古老的HIPO專案估算法來作breakdown, 原因正是它對專案在程式模塊上有相當的幫助,可以幫助工程人員進行思考並減少盲點(可以降低風險),雖然它的break down正確性有待考驗,但仍不失為委外開發或是專案進展下去的良好參考分析。對降低風險及不確定性有著一定的幫助。

與業者溝通,看清需求的本源

不過這次我沒有這麼做(沒考慮用HIPO來解題),一個理由是,自己對這個專案沒有感覺,或許是倉促之下,一心急著閱讀相關文件,看得快了,也就沒能意識到主軸所在,當然就沒感覺了。 另外一個重要因素則是缺乏溝通,沒跟真正的使用者接觸,進行語言上的交流,總覺得文件的描述少了些甚麼? 所以就在時間不足的情境下,選擇了與業者的需求單位見面,由需求的本源來進行分析的工作。

由發佈專案日期,倒推迭代的次數

台灣最多的就這種價格固定,時程又畫押的專案。對軟體公司而言,我們唯一可斟酌的就是功能的多寡了,做多了就做不完,還要賠錢。當然是想盡辦法來說服使用者少做一些功能了。以降低風險與減少不確定性為主旨來進行分析(然後希望老朋友能據此增加作決策時的準確性)。所以我以模擬"專案發佈會議"的方式來作計畫。這不是Scrum的制式會議,但過去在執行敏捷開發法時常常做。老實說;這是一種宣示性質大於實質意義的會議。能夠讓所有參與專案的人員有著一種共同的目標與期望,對接下來專案的進行工作絕對是一種好事。倒推迭代的方式,可以事前預估那些使用者要求的功能故事將不會被時間內做到。這一點,對雙方都有著極大的意義及幫助,它讓大家看到一個一致性的願景。放心好了,使用者的一致反應便是開始調整功能需求的優先順序。這種即時反應的回饋正是敏捷開發據以成功的依歸,也能讓人安心不少(希望這回火不要放得太大…)。

Break down Product backlog之後,我也順勢多訂了幾回迭代的規劃,感覺上有一些在做傳統專案的規劃動作,但多計畫一二個迭代的規劃,確實讓人更放心了些。這也是好事一樁。

在回程的高鐵車上,抒發一下情緒 …。