Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 七月 2016

敏捷開發為何會比較快?

with 8 comments

.

敏捷開發的目的不是為了快速交付!

它是一種用來應付需求快速變化的軟體開發方法。

–          Wiki

》許多IT主管或是工程師,都把敏捷開發誤以為是一種快速交付的方法,就因為它比傳統開發方法快一些,當然;還有它叫做「敏捷」的緣故。因此我們常常聽到主管們在會議上抱怨:「不是已經在RUN敏捷開發法了嗎,為什麼開發速度還是那麼慢呢?」

 .

「敏捷」二字的誤導

這一篇文章的目的不在回答上面那個說來話長,必須用聽診器仔細推敲才能回答的問題,而只是想修正一下大家對「敏捷」這二個字的誤解。敏捷二字其實是針對需求變化的快速反應而來,而不是過去所謂的 RAD 快速應用程式開發法(附註1)。下面的說明則是在解釋敏捷開發為何會比傳統開發方法快的原因。

.

 透過遊戲來做說明

敏捷開發不是一種快速的開發方法,為了解釋這件事敏捷課程的講師們經常會在課程裡依靠遊戲的方式來作說明(這是效果最好的一種方式,大家玩上一回便知道前置時間所造成的浪費之處了),但時間不夠的時候,則會改成放影片的形式。請欣賞上課時我們經常會放的一段翻銅板遊戲(Coin Flip Game: https://www.youtube.com/watch?v=HW2DEZLRAhw)。放這段影片的目的在導正大家對敏捷的誤解。尤其是給高階的主管知道 – 敏捷開發不是一種為了快速交付而出現的方法,它之所以比較快則是因為避開了許多浪費的處理方式 。下面這一張圖是為了更容易作說明而畫的,希望能解決困擾。

.

 透過圖示的方式作說明

000 敏捷快的原因

 

 上面這一張傳統vs敏捷的開發流程圖示,強調四個實施敏捷開發時為何會快於傳統開發流程的地方:

 .

※   前置時間

傳統開發法依循計畫、分析、設計、程式開發、測試再進行修改整合後發布的步驟進行,是一種順序性的開發模式,也就是說當前一個步驟還沒完成之前,後面的步驟就會位在等待的行列,當前一個步驟用掉越多時間時則後面步驟的前置時間就會越長,而形成時間上越多的浪費。也就是說傳統開發浪費了太多的時間,在前置作業上的意思。前置時間造成了一種沒有充分運用資源的現象,當進行到分析或設計的步驟時,程式設計人員仍然處於等待的狀態,因此形成了時間的浪費。

反觀敏捷開發,實行的是一種務實的做法,例如:在進行需求蒐集的步驟時,當收集到足夠一次迭代開發的需求時即向下一個步驟前進,盡量縮短前置時間的浪費,然後將"分析、設計、開發與測試“形成一個開發步驟,減少了步驟與步驟之間的銜接時間,這種開發方式形成了一種所謂的「衍生式的設計」,也就是遇到實質上的問題時才採用設計方法來克服它,而不是預先作好設計的方式。 因此讓起步顯得輕量化了,再加上只有少少的規範,所以敏捷才有了輕量化的開發方法的稱謂。

 

(在銅板遊戲中,我們通常會用一張A4的紙張作為前置時間的限制,要求學員把10或20個銅板放上去,遊戲進行時只有在所有在紙張上的銅板都完全翻轉過之後才能傳遞給下一位,形成後面的學員空等待的時間,也就是前置時間的浪費。在銅板遊戲中,我們通常會分成三次來進行遊戲,第一次採用 A4的紙張,代表最大的前置時間,接著將A4紙張撕成四等分,也就是採用四分之一的前置時間大小的紙張,最後一回則完全拿掉紙張,也就是極小化前置時間的限制,目的在讓學員更容易意識到速度上的差異)

 .

※      首次發布的時間

敏捷開發採用迭代的開發方式,每個循環都會有一個潛在可以進行發布的小增量用來展示開發的成果,透過這種展示給了我們要求客戶在看完之後給予回饋以便進行改善的機會,這種讓客戶體會開發成果的作法同時也給予了客戶決定開發方向的絕對主權(客戶可以在看到需求如何被達成,然後評估產品的堪用程度,是否已經達到提前上線的水準,也就是產品足以提前交付了嗎?)。

通常這個展示時間會設定在 1到 4個星期之內,因此客戶幾乎可以預期在這段時間之後可以看到預期的開發成果。這與傳統開發只在產品完成後才做一次發布的方式,客戶只有在這個時候才看得到成果,在開發過程中完全沒有改善的機會。這種迭代展示的形式,給予了客戶提前驗收的機會,也給予了開發團隊自然提前完工的機會。

 .

※      資料需求

敏捷開發不作完整的需求分析(因為計畫總是趕不上變化的),當需求的蒐集量及品質,已經足夠一個開發週期的工作量時就可以開工了。這便是敏捷開發著名的「需求夠二個星期的工作量了,可以開幹了!」,一種盡快開工不浪費時間去等待需求全部收集完整的開發模式。(需求的品質,就是所謂的 Definition Of Ready: DOR,它才是決定開發速度的決定性因素)

.

 

※      測試方法

敏捷開發對軟體帶來的最大影響便是測試了。傳統的α(內部測試,註2)、β(交付客戶測試)、γ測試(優化處理)方式在採用敏捷開發後幾乎不存在了,因為敏捷開發在開發週期內即不斷的在進行測試的動作,因此也就沒有了在交付做α、β、γ測試時必須停下開發作業來,凍結程式開發的時間浪費了。

 走了近二十年的敏捷開發,有二個明顯的趨勢成為了敏捷團隊的持續研究重點,一個就是測試,也就是從頭到尾都要測試。另一個則是組織上頭的徹底改變,這個較難,因為觀念要變。有空再來聊一聊.

.

 小結

這是觀念的問題,當你知道敏捷開發是針對需求變化的快速反應而來以後,便容易意會到為什麼它會花費那麼多的功夫在處理需求的變化了。例如Scrum 目前很流行的 Refinement會議,為什麼它每周都要召開一次呢,有必要嗎?是不是太浪費時間了呢?其實,它的目的正是在應付隨著時間而善於改變的需求變化罷了。

 

如果想要加速開發的時間,則前提是把需求弄好,擁有好的需求品質,當需求越能抽象的解題(注意不是明確的解題,一旦太明確化就失去變化的能力了),抽象解題提供了巨觀上的 Big Picture, 讓我們能夠看見全貌,然後據此擬定正確的開發方向,方向對了返工(rework)的次數自然變少,減少了在返工時所浪費的時間,減少了浪費的時間開發作業也就自然地變快起來了。

 

》為何要抽象化呢? 因為抽象時比較能包容那些屬於不確定的因素,也就是未來還沒發生的事情,他可以減少我們提前做決策時的方向偏差。而敏捷開發對抽象化最大的貢獻大概就是採用使用者故事(User Story )來描述需求了,它實現了我們用抽象化來做快速解題的能力。如果你尚未或是正準備進入敏捷開發的領域,記得從需求開始,而需求的撰寫請不要忘了採用使用者故事。

.

》如果一定要把敏捷開發說成是一種快速的開發方法的話,則應該要正名成〝一種快速處理需求變化的方法〞。是的;用來處理改變需求它就變得快得不得了了。原因是它在迭代中採用了使用者故事作為需求描述的方法,所以比起傳統的文件規格更能應付需求的變化,更加擁有彈性,所以特別能夠變通。而你運用使用者故事來描述需求的好壞,也決定了你應付需求變化的速度及能力。

.

 

附註1.

快速應用程式開發法 RAD

速應用程式開發(Rapid Application Development: RAD)是指一種以最小幅度的 … 技術設計的方式"。 快速應用程式開發的方法正是需要在功能與效能間取得一個平衡點,藉此來加速應用程式的開發時間,並減少之後所需的維護成本。他是對應到1970至80年代間的非敏捷流程開發,例如說結構化系統分析與設計方法以及其他像是瀑布模型等所誕生的一種開發法。(wiki)

註2.

α、β、γ 常用來表示軟體測試過程中的三個階段: α (Alpha) 是第一階段,一般只供内部測試使用; β (Beta) 是第二階段,已經消除了軟件中大部分的不完善之處; γ (Gamma) 是第三個階段,此時產品已經相當成熟,只需在個別地方再做進一步的優化處理。

.

廣告

Written by ruddyllee

2016 年 07 月 21 日 at 18:59:53

張貼於未分類

Tagged with

需求變化太過頻繁?

leave a comment »

解決需求變化太過頻繁的最好方法,就是提升需求的品質。

提升需求的品質的良方 — 使用者故事地圖。

.

User Story Mapping  使用者故事地圖 / 使用者故事對照

000 Jeff-Patton-Headshot-200x200.jpg

Jeff Patton

.

化繁為簡,看見全貌

使用故事地圖的二個最大功能,第一、是化繁為簡;把一堆使用者故事用階層的方式加以排列出來之後,便可以讓需求的主從關係透過誰包含誰的方式逐漸的清晰化。讓你宛如在瀏覽書籍一般,那些個章、節、細節以至於小節及附錄都變得層次分明,確確實實的可以看得見需求的整體、看得見專案的Roadmap了。尤其可以讓你從龐大的需求中找出開發的起始點來,看到哪裡才是這次開發上的主要章節。

.

第二、是看見全貌 The Whole Picture。

我們往往要擁有足夠的抽象化才看的見全貌。例如:在畫廊裡欣賞畫作,想要細細品味時我們會站得近一些,想看見全貌時我們會往後退一些。尤其當有人請我們批評一下這幅畫作時,勢必要向後退個兩步,設法來看見全貌免得偏頗的妄下定論,避開以偏蓋全的小家視野。在英文著作裡常常可以看到作家寫道「從三萬英尺的高空看地面」正是這個意思。

常常有人批評我老是把「抽象」掛在嘴上,一副很容易的樣子,但對別人而言其實是很難的。我要辯駁一下,其實覺得空泛只是缺少練習罷了。請多練習讓自己退一步! 退一步有多難嗎? 就是不要看得太仔細了而已,先把細節拋在腦後,不要太快看到細節,因為這樣你反而不容易看見全貌了,是細節的內容先佔據了你的主觀。隨後要在逐步弄清全貌就要反反覆覆花上許多工夫了,這是需求必須反覆變動的一大因素 — 沒能夠在一開始,先看到全貌(這便是我們經常要求工程師不要太快將使用者故事 breakdown 成 Task 的主要原因)。

.

哈哈! 我知道你要埋怨我講得太容易,不急,我們不要空談,我們用工具來解決這個問題。

.

工具能夠能夠讓你事半功倍,尤其是 User Story Mapping

.

介紹二個我最喜歡的工具: Featuremap & StoriesOnBoard.

這二個工具都讓我學到一些運用使用者故事地圖的技巧,都很棒! 不論你用或不用他們,請一定要看完它們的廣告簡介,設計的真好,能一眼就教會你它是怎麼設計、怎麼來詮釋使用者故事地圖的。唯一不好的是,它們都要花錢去買,而且是按月計費的不是很便宜,這一點便很難讓人輕易的下決心將整個需求的大業就這樣子的交給他,但老實說,他們是絕對值得的。

.

我在太多地方推行過使用者故事地圖了,但客戶用得很成功的例子卻少之又少,原因是它們缺少好的工具(這一點微軟的 VSTS 或 Atlassian 的 JIRA都太讓人失望了),這些挫折事後給我的教訓便是上完課後盡快推薦上面二個工具給他們,藉由好的工具來協助它們能夠化繁為簡,確實地掌握需求的全貌。

 

FeatureMap

這是一家法國公司Salience 的佳作,他採用的是平鋪直敘式的陳列使用者故事,我已經使用好幾年了,因為他針對個別的使用者帳號可以免費製作二個地圖。這一點確實很方便,我的"精實開發與看板方法"一書裡附錄的地圖就是用他編輯的。用起來像在編課表很簡單又好用,還可以列印出來分享。

.

0 看板方法 map

實施"看板方法"的使用者故事地圖

.

 

 StoriesOnBoard

匈牙利一家叫做 DevMads 的公司的傑作。他最精彩的地方是擁有二個操作模式,一個是創意模式,可以大量的放入使用者故事。 另一個是規劃模式,PO可以依據已有的使用者故事,開始區分相對功能的重要性及何時作甚麼版本的Release。他可以讓擁有構想的人們的抽象視野變得清晰可見(這是我最喜歡他的地方)。

.

這一 張圖的左右二邊,說明了二階段的運作。

000 StoriesOnBoard

.

不能再寫下去,再寫下去就有幫廠商廣告的意思了。純粹是把好東西介紹給大家,不過如果你已經試過採用 Excel 或 Powerpoint 來製作使用者故事地圖,而始終覺得少了些什麼的話,請試試上面的工具吧!

.

是的,敏捷宣言是這麼說的;「人與互動 更勝於 流程與工具」,但當你需要化繁為簡的時候,還是運用工具吧!這不就是我們身為軟體人所努力的方向嗎?

 

參考自:  Top Tools for User Story Mapping: From Post-Its to the Best Digital Apps

.

請用影響地圖講故事

有了架構良好的使用者故事地圖之後,該是PO把願景透過使用者故事逐步傳遞給團隊的時候了 — 講故事。這段前置作業的時間十分重要,雖然因為運用了抽象化的使用者故事來描述需求,讓我們擁有了避開傳統 waterfall 的計畫枷鎖,但過度的注重故事的細節將會導致團隊的開發時間的受到壓縮,會導致團隊因此而沒有了足夠的開發時間,這是一種浪費。但什麼時候才可以開始說故事呢? 正式的回答是在需求達到 Definition Of Ready 的時候,這是一個較大的議題,我們先不談他,跳過這個問題,我們來談談如何講故事?

.

使用者故事地圖不是一個講故事的好工具。因為好的故事總是從主角開始,然後描述了他的生長環境及背景,接著帶引大家一窺在各種遭遇之下他的種種反應成就了現在的他 – 這正是影響路徑。哈哈! 故事就是要這麼開始才有吸引力。所以我介紹大家要運用影響地圖 Impact Mapping 來說故事。因為他可以輕易的把你辛辛苦苦所寫出來的功能對應到他所要實現的業務目標上(我們稱他為影響路徑)。這裡不在贅述,請大家參考Gojko Adzic 的 Impact Mapping《影響地圖》這本只有73頁的小冊子。(我的說明在這裡)

.

使用者故事地圖可以讓你看見全貌、化繁為簡,

但影響地圖卻足以讓你開始講故事。

.

適合講故事用的《影響地圖》

強調一下,不是所有故事都該做 Impact Mapping 的(這麼做就太浪費時間了),但他實在比使用者故事地圖要適合用來講故事用了。我通常會慎選在主要的網頁上那個主要的元件來做說明(一般就是這一個網頁的特色所在),因為他值得我們多花一些時間來弄清楚,寫了這麼多的程式到底是為了甚麼。而相對的,目的通常是拿來評論(讓大家都看見)這麼做是值得的嗎?

.

 

 

 

Written by ruddyllee

2016 年 07 月 16 日 at 10:47:29

敏捷開發顧問模式

leave a comment »

敏捷開發顧問模式 Agile Development Consultant Pattern  ver 1.1

.

000 Agile Consultant Pattern

.

Version 1.1 更新

分別在 Sprint I 及 Sprint II 執行期間,運用看板欄位的 增加/刪除 來調整團隊開發流程的增減關卡。第一個 Sprint 以加入「測試欄位」的關卡。第二個 Sprint除了繼續加強測試之外,則以加入「文件製作」為主。

.

只有在開始繪圖之後才意識到,在任何模式之後還有一塊看不見的東西。看的見的可以畫下來,透過圖形做成紀錄讓人們看到細節末支。看不見的則需要意會、需要透過巧妙的文字來做解說,那就是「講故事」了

.

Written by ruddyllee

2016 年 07 月 11 日 at 17:00:45

張貼於未分類

Scrum 的價值觀

with one comment

.

如果45天以後我注定會被變成某種動物的話,你會選擇什麼動物呢?

– The Lobster, 單身動物園

 

 

面試時一定要弄清楚的事 – 價值觀

常常有同事問我,為什麼可以面試的這麼快? 到底是依據甚麼呢? 其實我以為,作為面試官,一定要弄清楚的是,這個新進人員遇到問題的時候,他會採取什麼樣的態度去面對它而那就是他的價值觀了。然後,再依據他的價值觀來判斷他跟團隊之間會越走越近、越來越融入團隊呢? 還是漸行漸遠? 這才是我真正在乎的。如果我必須在30分鐘內,決定這位面試人員適不適合進入公司的基本依據的話。我很少會去問技術性的問題的,因為總覺得那是一件很可笑的事,因為記問之學,不過是先看過或是後來才看到的事罷了!還是選擇可以比較持久的人性吧!

 

.

什麼是價值觀?

價值觀是指個人對客觀事物的總體評價,什麼是對的、好的、是應該的總看法,是一個人決定和行動的原則、標準,是個性心理結構的核心因素之一。

– wiki

價值觀有什麼用? 它是你做決策時的依據。

以下是Scrum的五大價值觀,它不是今天才出現的,Scrum的講師們已經講了很多年。只是它一直到 july 2016才被加進 Scrum 指南 裡的。

 

專注 Focus:把你的心思和能力都用到你承诺的工作上。在一段時間內只專注於少數幾件事情。團隊的能力是有限的,在有限能力和有限時間範圍內,專注於最有價值的事情,以取得更好的成果。它是精實開發Lean 的本質之一。

勇氣 Courage:我們常常說專案開始,讓我們開始衝刺吧! 正是勇氣的一種表現,表示我們願意去迎接跟面對各種挑戰。實行極致編成XP、測試開發法 TDD…,這些都是勇氣的表現。

公開 Openness:在團隊中公開展示進度時(也就是展示會議review meeting),就是進行可視化、透明化的動作。要知道,能讓大家都看見相同的情境,才容易建立一致性的認知。這樣可以相對容易的暴露出面對風險、問題和障礙。同時透明也是尊重、信任的基礎。

承諾 Commitment:一個自組織團隊,會依據團隊所做出的承諾極力的去維護他,並在迭代期間盡全力去完成這個承諾。它是運行 Sprint是否成功的基礎。

尊重 Respect:團隊是工作在一起的團體,必須建立在相互尊重之下,才會穩定的成長,而相互尊重更是有助於加深彼此之間的認識與了解。

.

敏捷精神.png

.

{ Scrum Guide 2016 新增的價值觀原文},如下:

 

Scrum Values

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

 

 

.

不要疏忽了人的價值觀,因為當你面對一個沒有遇過的問題時,請教有經驗的顧問是一個方法,但真正下決策的還是你自己。(我想Scrum Guide是想用它來補足執行Scrum的時候,需要很多經驗的問題吧!)

.

如果讓你選擇變成哪一種動物的話,你會選擇變成什麼呢?

.

參考:

Written by ruddyllee

2016 年 07 月 08 日 at 08:44:07