Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 八月 2015

什麼是DevOps?

with 2 comments

什麼是 DevOps? 從字面上的定義來回答:

DevOps 是維運和研發工程師一起參與,在產品的整個服務生命週期中,從設計到開發過程中,全程支援產品的做法。

.

英國政府數位服務設計手冊上面的定義:

DevOps 是一種組織內文化與既有職責變革(movement),用以回應大型組織內常見分工謬誤的問題

( 內容說明了: Devops 不是一種方法論或框架, 而是一些指導原則 與致力於打破組織藩籬的決心。)

.

這可能是今年最熱門的主題了! 幾乎所有的廠商都在推銷他們的DevOps解決方案。這些工具及產品(還有即將來襲的DevOps叢書)已經多到令人有些迷惑的地步。如果你曾經好奇的上網去Wiki上查詢DevOps的定義的話,你會得到以下的錯誤資訊:

 .

DevOps(英文Development和Operations的組合)是一組過程、方法與系統的統稱,用於促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。

.

實在很難說它寫錯了,但基本它的描述是不正確的! 因為 DevOps 絕對不是他所說的:「一組過程、方法與系統」。正確地說法: 其實它是一種文化! 為什麼會錯得這麼離譜呢? 這是一種有趣的現象,因為所有的大廠都在開發自己的解決方案,也就很容易讓人誤解它是一種開發方法(但它根本沒有任何規範,更沒有描述任何解題的步驟,因此絕對不是一種方法)。但基本上要作到DevOps,是一串繁複的過程,你要先打通層層的關卡,但真正難的是持續維護的作業。它牽扯到的是企業的文化,這是是一種文化層面的東西,所以必須由改善企業文化來解決問題。他跟敏捷開發強力推廣他的四大宣言一樣,我們舉敏捷開發的第一宣言來作說明:

.

個人與互動 重於 流程與工具

.

他描述的有些形而上,讓人看了以後一時難以完全意會。其實它的目的是要我們「先弄清楚自己要做什麼事、為什麼這樣做、這樣做了能解決什麼問題」,強調運用會議和溝通來找到真正的問題並建立共識才更重要,目的是讓團隊先去弄清問題,再思考解決問題需要那些流程跟工具。這樣的解釋好像簡單了一點,但事實正是如此。(如果從以上的說明,你還看不出哪裡有問題的話;請趕緊去微軟HPIBM的網站上去看一下他們對 DevOps的描述說明,你會很容易的看出來,其實它是一種文化,根本不是一種方法或是可以衍生出來的一種系統。謝天謝地! 這表示廠商們本身並沒有搞錯,只是wiki上的解釋容易誤導讀者,以為DevOps是一種方法)。

.

微軟Devops 在網站上的定義

MS devops

 .

改變文化難 — 要用改善效能的行為來形成文化

以往我們都會認為「改變組織文化,在於改變人的觀念」,而如何改變觀念,往往被視為是一件艱鉅的任務;但 DevOps則沿用精實的理論,它不會嘗試去直接改變人們的觀念,反而選擇以直接改善人們的行為方式,來形成一種團隊的責任精神,用責任文化來改善企業文化。就這一點而言;豐田企業Toyota的選擇是發揮 Lean 精實的精神,以消除浪費的原則來增進組織的工作效率,真實的運用它來改進企業的文化。

※ 這便是精實Lean理論在DevOps中所佔重要地位的原因。

.

(聽眾很容易被各個廠商在宣傳DevOps的影片所誤導! 看完、聽完了之後,難免會容易以為它是一種工具或是解決問題的開發方法,這是因為廠商談的都是產品,很容易讓人誤以為他是一種方法的實踐。希望學員們在聽完我的演講之後,不會再這麼認為了。 今年的Techdays 2015及 Rubyconf taiwan 2015 的 Keynote 上我都會談到這個主題。另外,我也會談到一項值得強調的Microservice的技術,工程師可能會對他比較感興趣,有機會再來談囉 !)

.

下面這張圖,是採用看板方法的角度來看DevOps實施之前跟之後的現象。

0dev0

.

上圖中將產品的整個生命周期都串連起來了,這是透過實施看板方法來讓DevOps完全透明化的圖示。我一直以為看板方法是解決DevOps 必經的過程,請大家拭目以待吧 !

.

Patrick Debois

DevOps 之父

請參考:

(如果你對 DevOps的歷史感興趣的話: http://itrevolution.com/the-history-of-devops/)

1. Patrick Debois (DevOps教父)在Youtube上回答一些基本的DevOps問題的座談會 https://youtu.be/uRMV6tT_mu0

2. http://theagileadmin.com/what-is-devops/ 上的說明。

3. http://newrelic.com/devops/what-is-devops 上的說明。

4. DevOps沒有宣言manifesto,比較務實的說明是: DevOps emphasizing collaboration and integration also looks to automation tools that can leverage an increasingly programmable and dynamic infrastructure from a lifecycle perspective.

廣告

Written by ruddyllee

2015 年 08 月 31 日 at 12:47:44

如何做任務分解?

leave a comment »

任務分解Task Breakdown這是執行SCRUM的「計畫會議」裡第二階段所要進行的工作重點。會議進行的狀態: 一般是工程師依靠過去工作所累積下來的工作經驗,看一眼使用者故事的需求目的之後,便大膽的開始進行Breakdown了,完全是用經驗來進行任務拆解的工作。很直覺,適合經驗豐富的團隊,但團隊要是有一大堆新鮮人的時候,建議採用以下的步驟,先做分析之後再以漸進的方式去拆解故事,會很有幫助的。

步驟一、先定義問題

步驟二、質疑要如何做驗證測試

步驟三、由架構面來做審視(上下文)

步驟四、定義完成(含追加佈署的文件)

.

首先定義問題

使用者故事最棒的地方,就是容易讓大家一起來討論,試著弄清楚這麼做是不是可以解決真正的問題? (千萬別因為覺得麻煩,就省略了這個步驟,我在很多地方都看過它的驚人效果,尤其是對非功能性的需求,在執疑之後;找一個範例走它一遍,相信我,這個發現會很有價值的)定義一下問題所在。定義問題可以讓大家在基本上有一致的認知,可以做為後續討論的基礎。

.

問一下如何測試

習慣上;我會運用倒過來的方式,先問作完了以後要如何驗證呢? 條件是甚麼? 然後就依據這些測試的條件來進行拆解這個使用者故事。這個動作也稱為最初的「定義完成」 DOD: definition of done(但它實際上充滿了未知與期望,與這真正可工作的軟體的定義還有一段距離)。

.

接著你要由架構面來做審視

如果事先開過 workshop之類的會議,已經產出有「使用者故事地圖」的話;則由使用者故事地圖做審視上下文之間的關係,是一個不錯的方式。這麼作的一個重要目的是,倒過來看使用者故事是否需要修正(透過工程師來描述故事,講給客戶或團隊的其他成員聽)。我習慣上會說: 「大家聽我描述一下,看看我有沒有說錯…」,這種做法可以確保大家都上車了,不會有人掉隊。

使用者故事拆解的動作通常結束在我們拆解出來的任務(task)都已經夠小了(一般由3到13個小時,謂之為剛剛好的大小) 就可以停止了。反之;就必須繼續向下去拆解它。團隊一起作拆解的工作,是一件耗時,但卻具有相意義的工作。因為在會議中會有人嘗試努力的來解題,而對問題不了解的人則會從中吸取到相當的經驗,一般來說是值得的。

拆解任務的最後一個步驟 – 定義何謂完成

Scrum對定義何謂完成,指的是已經可以交付給客戶的功能。你可能會質疑都還沒做使用者的驗收測試(也就是 UAT),怎麼能說它是可交付的功能呢? Scrum的解釋是我們的目標是 Ready to ship,因此常常稱此為「潛在可將交付的軟體」。

一般DOD所指的是:

  • 這個功能的程式已開發完成。

  • 已經可以作自動化測試。

  • 相關的文件已經更新

  •  或是可以進入打包作佈署的動作了。

.

會不會沒完沒了

這樣的考量,常常會讓你一再追加幾個可以列入正常工作的任務(task),例如設計、撰寫自動化測試的程式或是追加應該交付的可支援佈署的文件。不用擔心這樣子改來改去,會沒完沒了,如果你有這樣子的感覺,就先去做做看,回頭再來進行檢討審視的動作,總之;試著找出團隊可以工作步調就對了! 控制會議的時間,以時間為限制,有足夠開工的Tasks就可以趕快去做了,大可用事後檢討的方式來做好檢核點,沒有必要開太長的會議,它是一種最常見的浪費,能避免最好。

Written by ruddyllee

2015 年 08 月 23 日 at 09:51:46

敏捷團隊如何制定簡單規範

leave a comment »

(一支能夠自主管理的團隊,其實就是一支擁有責任感的團隊。

大家都知道讓團隊自我管理,可以讓它擁有最佳的效能表現。但我們也都苦惱於如何建立團隊自主的規範。話說得簡單些: 就是讓他們處在只有簡單規範的約束之下,他們才能盡情發揮。但如何制定簡單規範呢? 這就難了。

.

( 課題: 如何克服在企業的傳統文化之下,仍然能夠帶領敏捷團隊建立屬於團隊的責任文化。)

.

簡單規範其實就是擁有自主的責任感

這就好比一個懂得回家就先做完功課再做其他事的孩子一般,家長們總是能放心讓孩子們去做自己喜歡做的事,原因是他能自我約束,也就是擁有責任感,曉得要先完成自己該做的事再去做其他的事,當然就能讓父母親放心的讓他自主了。所以要打造一支自主的團隊,基本上就是想法子打造一支人人懂得負責的團隊。

.

「負責」

負責具有幾個不同的面向,一種是出了問題,必須勇敢的站出來承擔責任的情形。這種被動式的負責,稱不上是團隊精神裡的責任感。基本上;在團隊中盡到自己應盡的責任就叫負責。而團隊型的責任感則更甚於此,它是一種求取團隊最好成績的責任,一種追求榮譽的使命感。這是一種文化層面上的東西。往往需要透過成功的組織式領導才可能獲得的「責任感文化」。而我們所謂的「簡單規範」它便是建立在這樣的團隊文化上頭的。講得有些抽象了,用白話說的意思,就是實際上;我們必須先創建一種責任感的文化,才能寄望團隊能夠表現得足以自主管理。

.

建立自主團隊,先建立責任感文化

身為一個敏捷開發(SCRUM框架)的推廣者,我們總是教學員們:「當在實施Scrum的時候遇到與企業文化相抵觸的時候,記得要以企業的文化為主 」。這是因為Scrum的框架是基於既有的約束(三個角色、四種會議及三種產物之下)來指導專案運行在敏捷開發法之下的規範而已,並非是一種可以放之四海階準的原則。反過來看精實開發(Lean development) 則是一種只有原則而沒有指定任何特定開發方法的規範,因此可以用來改善公司的企業文化。(其中的第五項;授權團隊:正是幫團隊制定簡單的規則。)

※ 如何建立責任感文化呢? 這裡推薦:

引爆責任感文化:幫助企業實現目標的金字塔法則 (Change the Culture, Change the Game) by: Roger Connors,    Tom Smith.

.

成效金字塔

羅傑·康納斯 & 湯姆•史密斯 製作.

.

一個好的開始點(最近的感觸 :你可以這麼做,2016/09/27)

先讓辦公室出些狀況(例如: 太吵雜、太髒亂…),讓問題成功的吸引到大家的注意後,(例如: 讓團隊在會影響到辦公環境下的公共場所進行站立會議,在眾目藈藈之下正常的進行,如果真的影響到辦公環境的安寧的情形時,試著在回顧會議時,讓團隊一起制定一到二條簡單的規則,用來建立團隊的紀律,讓紀律大過聲音)接著讓團隊自主的制訂辦公室規則。就在這些個規則的背後,紀律油然而生!

.

Written by ruddyllee

2015 年 08 月 16 日 at 23:56:44

使用者故事 User story

leave a comment »

最近看到許多傳統的企業正在努力的轉型中,這絕對不是一蹴可幾的工作,若你問我改革應該從哪裡開始呢?我會回答從改善品質,加重測試開始,但對於真正的開發工作,則我會選擇從用來描述需求用的「使用者故事」開始,因此想在這裡寫一些東西,希望能有些幫助,完整的PPTX檔。我一直以為:

.

敏捷開發送給世界最好的需求描述,就是用「故事」的方式來說明需求。

.

它是1998年被 Kant Beck 首先運用在XP極致編程裡,供使用者用來描述專案範圍的方法。這種威力無窮的需求描述方式,因為看起來太簡單了些(註1),常常會讓人們忽略了它的影響。老實說;敏捷專案開發的成敗可是完全靠它來作支撐(註2),要知道如果沒有好的需求描述、問題探討,怎麼會有好的產品產生呢?!

.

all agree_0

Kent Beck 的初始目的是為了避免大家沒有討論清楚,就各自自以為是的點頭開始工作。

.

註1:  看起來簡單的東西,實際執行起來並不一定會簡單。因為規範少了反倒很難具體的來實踐他。後來Bill Wake想出了INVEST的六個法則,最近則以Jeff Patton的使用者故事地圖。對產出好用的使用者故事都有著莫大的貢獻。

註2: 據 Don Reinertsen 所說 80~85%的專案之所以未達到要求,完全是不正確的需求所造成。

Studies show that 80 to 85 percent of project failures are due to incorrect requirements. 

by: Don Reinertsen

author of : The Principles of Product Development Flow

.

使用者故事是最佳的溝通利器

業務人員要依靠它來跟技術人員進行溝通,而工程師要依靠它來了解需求並拆解成為可以實作的任務。而它更是二者之間共同探討真正的問題所在是否有更多選項挖掘更多細節接受更多變化的依據。下圖中顯示了需求的二個面向, 一個是對使用者的,它讓使用者足以用自己所熟悉的業務用詞來談需求,完全不用去描述到任何技術的東西。另一個是對程式設計人員的,它是以畫面、場景或是流程方式,來協助工程師快速學習業務知識用的。

投影片5_1

善用溝通才能發掘真正的問題,也才能提煉出更好的設計。

.

Ron Jeffries在2001寫下了使用者故事著名的 3C理論,用來討論、確認故事的各部分組成。1C:卡片(Card): 極端抽象又簡潔的說明。2C:談話(Conversation): 無時無刻都可進行的溝通與討論。3C:確認(Confirmation): 為談話的內容及目標作成越正式越好的結論。明顯扼要地說明了,使用者故事是用來溝通用的。(很多使用者把它拿來做為規格文件使用,那就大錯特錯了。)

3CC

Ron Jeffries 的 3C

.

舉一個例子來描述一下運用步驟:

步驟一、如以下的陳述,針對某一個目的寫下使用者故事  –> 查詢客戶資料

             身為一個使用者,我希望可以運用姓氏或名字來搜尋我的客戶。

              As a user, I want to search for my customers by their first or last names.

.

步驟二、工程師由使用者故事推敲如何解題  –> 進行功能拆解

        ※將使用者故事拆解成任務(Tasks):

              Task 1:  畫面製作。至少需要輸入: 姓氏、名字的輸入欄位搜尋的按鈕

              Task 2:  訊息顯示。顯示進行中、錯誤訊息。

              Task 3處理搜尋功能呼叫及取回資料

              Task 4:  結果顯示。討論以何種元件(List、Grid、…)作為結果顯示。

步驟三、雙方進行討論,定義何謂完成 –> 討論這樣做是否解決了真正的問題

客戶與程式開發人員就可以針對使用者故事進行討論,確認描述的故事是否解決了真正的問題。

也許找到"使用者的 email “或 “電話號碼“才是查詢者真正的目的。為此;就應該把查到的資料用這兩個欄位作為顯示的重點。還有;一次顯示資料的筆數? 是否需要進行排序? 再加上必要標誌等功能,也需要視各種情況進行適當調整。

.

經過與客戶討論之後的可能結果 — 範圍與限制都更明確了

上面的範例並沒有將最後的利益說清楚,因此留下了讓客戶與程式設計人員有很大的討論空間(是優點也是缺點!)。下面則是二則運用不同的使用者(角色)將同一個使用者故事利益設限的範例:

身為一個電話傳呼員,我希望可以運用姓氏或名字來搜尋我的客戶電話以便於我可以直接按鈕呼叫出去。

身為一個推銷員,我希望可以運用姓氏或名字來搜尋我的客戶Email 地址以便於我可以直接按鈕送出我的廣告。

 .

進階詮釋的3C

這是一個單一且明確的範例,若是把它加以運用在一個團隊開發的專案上。則3C便成了:

[ 1C ]  一份書面的故事描述,用來當作計畫或提示用。

[ 2C ] 在計畫會議時做為有關故事的對話、討論,用來具體化故事的各種細節。

[ 3C ] 測試。用來確認撰寫的故事是否完成解決了它的問題,最終則成為了基本的文件。

 .

 

小結

建構滿足使用者需求的軟體,最好的方法是從"使用者故事"開始。它即簡明扼要又清楚明確地描述對實際用戶有價值的功能。但它(使用者故事)不是規格文件,而是用來探討解答的抽象化方式,它的任務是讓客戶跟工程師能夠就解決真正的問題而進行溝通。對於敏捷而言;真正的規格文件是誕生於持續的開發與維護當中。(敏捷文件;它跟程式的架構有著相同的產生方式,也就是衍生出來的,是一邊設計而同時又一邊撰寫出來的)

.

回答問題:

1. 為何「改革要從改善品質,加重測試開始」呢?

因為加重測試可以喚來紀律,而紀律是開始進行改革時最最需要的東西。

2. 使用者故事的來源典故:

(Kent Beck explained where the idea came from:)

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does.
[For example,]
if I type in the zip code and it automatically fills in the city and state without me having to touch a button.
I think that was the example that triggered the idea.
If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?

— Kent Beck via personal email, Aug 2010

Written by ruddyllee

2015 年 08 月 02 日 at 18:12:39