Ruddy Lee 分享空間

Emergent Design 演化設計

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

leave a comment »

這是一系列文章的開始,由於經常被新的客戶問道,您作顧問這麼多年一定有一些模式可以讓我們參考的。我的回答是:「當然了!」但心裡却總覺得有些虛虛的。案例是累積了許多,但把它們變成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 需求的描述資料是否備妥? (它可以說是影響開發速度最大的關鍵,千萬別小看它了,這是我最近一年以來,花掉最多時間在處理的事情之一了)。

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

 

 

Written by ruddyllee

2016 年 06 月 16 日 於 12:39:47

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

你正使用 WordPress.com 帳號留言。 登出 / 變更 )

Twitter picture

你正使用 Twitter 帳號留言。 登出 / 變更 )

Facebook照片

你正使用 Facebook 帳號留言。 登出 / 變更 )

Google+ photo

你正使用 Google+ 帳號留言。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: