Ruddy Lee 分享空間

Emergent Design 演化設計

需求分布圖

leave a comment »

.

由需求的數量、開發時間及它在示意圖上的服務節點,可以看出專案開發的負荷及重點所在,以及它完成後將對使用者的影響。

.

1.

示意圖提供了使用者的種種行為場景,接著在針對示意圖,把各個需求放在它所服務的節點上,這樣就可以看出相對於使用者行為上開發團隊將要付出的努力所在了。當然也能拿來看出此次專案的開發重點(同常就是需求最多,最花時間的地方)。下面們就用範例做說明,讓大家比較容易了解。

.

用一場演講來作範例

首先講師把演講的過程畫成示意圖,下面的範例是我在參加Agile Tour 2017所演講的題目: 讓英雄先救貓咪。 演講過程的示意圖如下,左邊是「涉及人」也就是來聽演講的學員,最右邊是「標的物」也就是做完演講之後,所產出的圖像紀錄。

.

2.jpg

讓英雄先救貓咪的演講場景圖示

.

這裡我們把演講的Slides當成需求,演講的過程當成描述使用者行為的場景,

圖上打勾的符號表示會講到的 Slide, 打叉的是不會講到的 Slide(這是講師的一種習慣,通常我們會先針對演講主題準備演講資料,最後才是針對演講的時間長短進行刪刪減減,也就是那一堆打叉的slide囉,我的習慣是把它留給學員自己參考用而不做刪除,目的是針對演講主題的完整性而不是演講時間的限制)

花較多時間講的正是講師所想闡述的重點 

我們把slide數當成需求,由需求在示意圖上各個節點的分布數量,便可以一眼望穿每個節點個別需要多少使用者故事才足以完成這項服務(功能)。也能藉著視覺化看出專案服務客戶在進行各種操作行為上的負荷(完成此項需求,工程師所需要投入的開發時間),我們也可以依據它來進行價值判斷,考慮是不是值得做這麼大或是應該再加重投資開發某項功能的比例。因此,需求分布圖足以讓我們看見專案在開發上各個需求所占的比重大小。

.

3.jpg看見專案負荷的比重

.

專案開始之初  — 看見全貌

專案開始之初首要在先看見全貌,而「需求分布圖」則是可以在需求示意圖完成後用來分析專案開發的重點所在。我們可以拿來作為投資報酬率的評估用,依據開發功能、數量在某一個服務節點上是否做了過度的投資的統計依據。它可以讓我們再一次客觀的審視各個使用者故事在某一個情境上的負荷及相對的價值。

.

結語

需求分布圖的依據是使用者的場景示意圖,一切以使用者為主軸。它的效用就好必影響地圖一般,可以看見工程師開發某一個功能相對於它對使用者的影響路徑所在,可以用來分析用。而需求分布圖看的則是全貌,展示專案開發在需求負荷下的分布狀態,我們可以拿來評估專案的目標跟預期的計畫重點是否一致,有沒有做錯重點、把時間及開發功能投資錯了地方。

它也是我上課時的依據,我會把課程先做成情境的描述示意圖(它就是整個演講的過程),然後把如何協助講課的 Slide當成需求(凡需求就要區分重要性,也就是Must have/ Should have/ Could have/ Won’t have的區分),它是我拿來對演講時間有限的清況下,這時候;我只要斟酌這張投影片的重要性,再決定要不要放棄不講(也就是在右上角標示 W: won’t have 符號)。

 

參考: 「讓英雄先救貓咪」的演講投影片

https://1drv.ms/f/s!AtlpfGB0RrJoh7sK0CvFHArPKK95qA

 

Written by ruddyllee

2017 年 03 月 24 日 at 11:46:42

引導看板 Facilitated Kanban

leave a comment »

前言

  • 已身.png孔子《論語·子路》,「以身作則」“其身正,不令而行;其身不正,雖令不從。”
  • 「潛移默化」,形容人的思想、性格或習慣受到影響, 不知不覺中起了變化。

.

引導 Facilitation
我教敏捷開發課程已經超過15個年頭了,這麼多年來我一直相信敏捷是一種文化,他可以深深的改變一個團隊,甚至是一個人的家庭文化,因此我很早就在家中實施敏捷教育了。為了讓孩子們也能像我一樣熱衷於追求學問,我總是以身作則;經常在餐桌上擺滿了書籍,表現得用功而認真的埋首於書寫或閱讀中,企圖用這種行為來感化孩子們,深深的希望這麼作能影響到孩子們的求學之路,有時候;我只要聽到孩子們下樓或要進到餐廳的聲音時,就會刻意的把書本打開來,裝作很用功的在研讀中,因此家中的餐桌上,總是長期的堆滿了各式各樣的書籍,嚴然就是一副圖書館的樣子,目的就為了形成孩子們愛讀書的風氣(真是用心良苦啊!)。

但這麼多年過去了(十幾年了,孩子們都超過30歲了),家中的餐桌上依然只有我的書籍,它們依然經常凌亂的躺在餐桌上,卻從來就沒見過孩子們這麼作過。所以我實在不相信以身作則就能夠有效的改變風氣。

05.png.

一直到我遇見了引導,才晃然大悟;其實,除了以身作則之外還需要依靠引導的方式,或許這才是循循善誘吧!(建議那些也想要運用以身作則,來感化孩子們的家長)你必需採用適當的引導方式,才能讓孩子們朝向你所期望的方向去前進。而在工作上我們也經常會碰到一些團隊表現的與你所期望的有相當差距的情形,這時候就是你該思考如何加強團隊引導的時機了。

這裡我嘗試了一種可以運用看板視覺化的力量來協助團隊協作的工具,我稱之為「引導看板」,效果好極了!每當你遇到要主持一些需要較多引導、較抽象的工作坊或會議時就可以自行先設計一個引導看板,讓與會人員一眼就知道今天的會議程序以及目前已有的成果,迅速移除那些讓参加者因爲不熟悉所造成的疑惑而造成的無為現象。它同時也能幫助你更有信心的去引導團隊並毫不遺漏的主持好會議,歡迎嘗試看看。

 .

運用看板來達成引導的目的 – 引導看板

.

引導看板」;一種用來持續顯示討論成果,以作為後續討論依據用的視覺性看板。

 . { 範例參考:  Scrum 四大會議的引導看板,放在文章後面。(其實;越是難以捉摸、越是高抽象度的會議越適合採用「引導看板」來召開,也能越見功效,例如:召開創建使用者故事地圖會議或可稱為Workshop 就屬於較高創意、十分抽象的會議類型,相當適合採用。目前只要是找我指導的會議,我一定會採用引導看板來進行,務必讓参與者迅速進入會議情境,充分的運用視覺化來完成會議紀錄。 )}

.

「引導看板」的目的是用來協助、組織召開複雜性高或曠日費時的會議或工作坊時所可以採用的一種視覺化看板。

.

看板天生就是作來引導用的

因為看板就是設計來顯示、管理工作流程的,因此十分適合拿來進行引導作業。而引導看板是紀錄成果,指引向未來的利器,它不同於一般的看板,一般看板在上面移動的是一個個的工作項目。但「引導看板」的目的是累積成果,持續讓大家一直看得到結論,並以此做為後續討論的依據,因此它顯示的是目前進行到的流程(欄位)以及已經累積下來的討論成果。如下面的創見使用者地圖的看板,紅色倒三角()一看便知是目前進行到的流程位置,也就是進行到第四個欄位(繪製示意圖),明顯的;示意圖不可能繪製在看板內,需要再運用其他的空間進一步產出(最後結果,則可以用照相的方式放上來)。但運用看板做引導的真正目的是消彌大家對程序上的疑慮,讓按部就班成為大家群策群力的依據,讓團隊智慧足以充分發揮。

.

下面是一個"創建使用者故事地圖"的步驟,它隱含"靜態頭腦風暴"的工作坊及會議(這是一個會讓你站到腳痠的會議)。首先;召開的步驟是:

20.png

21.png

.

召開的過程中,前面階段所得到的產出物都是為了用來做為接下來討論的依據。所以必須明確的紀錄在隨時可以看見的地方,以便於接下來的討論。所以十分適合採用看板來視覺化過程。你可以解讀下面的"創建使用者故事地圖看板"為:

  • 目前已經進行到: 第四個欄位,馬上要作畫出使用者操作的情境示意圖。
  • 第三個欄位: 明顯的標示了主要用戶與次要用戶的特性指標。
  • 第二個欄位: 標示了此專案對客戶及公司的利益所在。
  • 第一個欄位: 說明了參與討論者所扮演的角色。

.

14.png

.

所有程序一目了然,可以讓人增加穩定感並提升參與度

針對創建使用者故事地圖製作引導看板的目的,是由於「創建使用者故事地圖」是一種抽象度很高的活動,當召開時我們經常會邀請35名專家來參與這種啟發式的(頭腦風暴)討論。所以與會的人物經常是互不相識的(並且經常是第一次參加這種創意式會議),由於大家都不熟悉,這會讓會議的進行增加許多的不確定性,再加上對會議的成敗的疑惑,因此常常需要更多的暖身活動才能上軌道。所以我才決定運用這種可視化的技巧,讓與會者完全看到會議的步驟,藉以讓大家擁有較高的穩定性,用此拿來做頭腦風暴前提升穩定度的依據。

 

上圖中的看板,除了有明確的陳列出各個工作步驟之外,更把每個步驟的執行成果都記錄在該步驟的欄位中,讓參與會議的成員可以透過持續看見的效果,以此做為後續討論的明確依據,它可以讓會議不容易失焦,而且大家都能持續看到全貌,因此更能專注地去完成討論的目標。

.

devops看板_1.png

.

【 創建引導看板的步驟 】

一、繪製(會議程序的)價值流程圖 — 視覺化你的流程。

二、在最前面加入要達成的目標及說明 — 明確的說明所要達成的目標。

三、保留足夠空間做紀錄用 — 將紀錄用便利貼或其他方式陳列出來。

四、在看板的下方加上欄位說明 ,運用WIP來限制討論時間– 規範流程。

.

結論

製作用戶故事地圖的創建會議,實質上就是一種「設計思考」Design Thinking 的過程。成果是累加出來的,後面的討論往往是依據請面的線索所做的推論。這種形式的會議其實很多,若能夠善用可視化的呈現方式,則對創建的成果將會有著明顯的幫助。此時能夠採用引導看板來做呈現,除了可以大幅增加會議的明確度,又可以讓與會者迅速進入狀況外,還能適當的紀錄下所有的成果(明確的展示了創建使用者故事地圖的會議結論),具有圖像視覺化會議的成效。

.

{你其實可以更明確一點,之所以要保持抽象,目的是為了維持包容性,而再明確一點的目的,則是為了讓流程能夠順利地進行下去。}

— 運用看板進行引導

.

範例參考 】 – 展示會議、計畫會議、回顧會議。

Scrum 的 review meeting 的「引導看板」

明確的說明了即將有幾個展示、是由哪位成員所完成的,以及目前進行到哪裡。更有效的部分是,它可以讓來參與展示會議的使用者都能夠很清楚何時、何刻輪到他必須發表意見,應該要做較大還是較小的回饋,如此可以更順利的獲得客戶的回饋。

20

.

1.png

.

2

.

devops看板.png每日工作看板需與真實的工作流程相符(僅供參考)

.

Written by ruddyllee

2017 年 02 月 20 日 at 22:33:03

如何創建使用者故事地圖看板

leave a comment »

.

看板引導.png

.

08.png

用戶故事地圖看板 – 避免遺漏

 

.

01.png

.

02.png

.

04.png

.

05.png

.

05

.

07.png

.

08.png

.

09.png

.

10.png

.

11.png

.

12.png

.

13.png

.

14.png

.

15.png.

16.png

.

21.png

.

結語

看板與生俱有強大的引導能力。不止於在站立會議時能迅速的顯示更新資訊的來龍去脈,若能善用它的視覺化能力,尤其在團隊的活動上,運用看板來進行引導,可以讓模糊不清的工作步驟容易按部就班的進行,更能讓團隊成員發揮智慧,預先盤算作為下一步的行動依據,讓人變得更聰明。運用看板進行引導工作的優點:

  • 讓模糊不清的工作步驟變得清晰而明確。

  • 讓團隊智慧得以更容易發揮。

  • 便於控制會議時間(用時間來當作 WIP的設限)。

  • 不容易遺漏必要的注意事項。

.

參考:

  1. 用戶故事地圖,   by Jeff Patton
  2. 產品敏捷開發之——創用戶故事地圖,    https://read01.com/o4k53z.html
  3. Google 創投認證, by  傑克.納普, 約翰.澤拉斯基, 布雷登.柯維茲.

Written by ruddyllee

2017 年 02 月 15 日 at 10:37:38

如何培養一個強大的開發團隊?

leave a comment »

.

定義: 一個能夠作出超過他們開發能力的團隊,謂之強大的開發團隊。

.

08.png

敏捷是一種學習型的組織

.

「學習」是最重要的事

要讓一個團隊作超過他們能力所能作的事,其實一點也不難,就是要讓他們一天比一天還要強大,也就是說今天的團隊比昨天還強,明天比今天還強,說穿了,就是要能夠持續成長的意思。而「成長」的方法當然就是透過「學習」了。因此只要讓團隊持續的學習,自然能夠ㄧ天強過一天,經常做到他們原本所作不到的事了。帶領這樣的一個團隊,就要像照顧孩子們學習成長一樣,盡力的去屏除任何會影響他們學習成長的阻礙。並透過引導反思的方式,來落實延伸啟發他們「」的範圍及效果。

.

※    成就強大開發團隊的三個重要原則:

  1. 在敏捷開發的各個活動中注入學習的要素,以做到「增強學習」。
  2. 運用引導的技巧來協助團隊達到「自我管理」。
  3. 結合學習跟引導,讓團隊透過引導來促發延伸學習

.

精實原則:「增強學習」讓團隊更穩定

敏捷是一種學習型的組織(註2),它重度的依靠學習來讓團隊持續成長,尤其是當工程師處在專注於學習的時候,通常也會擁有最高的穩定性,可以產出好的程式,做出好的產品。相對地;當整個團隊都處於高度學習的時候,也正是他們呈現最佳穩定度的時候,這是任何學習型組織都最為珍惜的一刻。至於;要如何培養出一個強大的開發團隊,正是要讓他們能夠持續的維持在這樣的氛圍之下工作,並能夠適度的得到回饋以持續的處在成長的喜悅中,後面所提到的「適度的得到回饋」,則是維持這種高度產出的氛圍下,所不可缺乏的成功要素之一,這一點在創新團隊的組織比較容易實現,也就是給予適當的激勵,這會讓學習具有正面的意義,能更為持久。而在傳統的多階層的古老企業之下,就比較難以實現了,這正是創新團隊在開發上的優勢。

.

06.png

.

引導是為了讓團隊自我管理所引出來的必要技巧

引導的重點在促發團隊產出集體智慧的結晶,使得團隊得以結合眾人的力量,達成個人難以觸及的更高的成就。這個字來自拉丁語,Facil 指的是”容易的”意思。引導的字面意思是讓團隊工作流程變得簡便。但運用在軟體開發上,則是為了避免團體在協同的開發作業上犯了不小心的錯誤,所以引導便成了,指引團隊達成一種正確決策的行為的技巧。若與我們的目標(如何培養一個強大的開發團隊?) 相結合的話,便成為在開發活動中運用引導的技巧來加強團隊學習的成果。

》用來成就一個強大的開發團隊的基本技巧 – 運用引導來引發團隊的學習及促進學習的深度

站立會議中的學習

SCRUM對站立會議的基本要求,成員必須敘述三件事:

  1. 從昨天到現在做了什麼隊團隊有貢獻的事?
  2. 今天準備做什麼?
  3. 是否有遭遇任何阻礙你完成工作的困難事?

SCRUM講了規則卻沒有說明如何應對,怪不得SCRUM稱自己是一種架構Framework而非方法。所以當團隊成員述說我昨天完成了這個工作(Task)時,主持站立會議的Scrum Master應該如何應對呢?

今天我們來假設目標是促進學習的話,則Scrum Master要如何運用引導的技巧來增強學習呢? 反過來思考,假設是自己家裡的孩子拿著聯絡簿要我們確認他已經做完功課了,跑來要求家長簽名的時候,你會怎麼做呢? 你最可能會做的是,用命令的口氣跟孩子們說:「拿過來讓我看一下!」,然後你可能會要求,「來,背這一段我聽聽!」這是驗證的方式,也就確認定義完成(Definition of Done)的基本作法,看起來務實,但其實這麼作對孩子們的學習內容實在沒有多大幫助。假使;你倒過來問孩子們: 你花了多少時間來作這個作業? 這個作業是難還是容易? 從這個作業裡你學到了什麼? 朝著未來的目標及收穫來引導延伸他們的思維前進,這樣子的引導動作,則會把孩子學習的成果更具體化,讓他的思維更能延伸出去,產生較多的聯想。這是依據Knapp 1992的理論說明何謂真正的學習,也就到達足以學以致用的地步。

.

12.png

由情境的「」到經驗,促成引導反思以至於延伸啟發的「

.

換句話說:表面的知與經過實作後的知,需要進一步衍化成足以作判斷的知,再透過引導反思,方足以成為延伸啟發後的「知識」。

.

所以Scrum Master 應該在團隊成員述說自己完成了某個工作時,接著詢問有關這個工作的難易度,然後詢問獲得了怎樣的經驗,並引導他反思再做一次,或改變環境時他會如何改變處裡的方式,盡力去延伸啟發這個「知」。使學習得以真正的落實。(你或許會反問我這麼作會讓站立會議變的好長好久,這麼作值得嗎? 如果有所疑慮,就偶爾才挑一個來試做看看,看你的團隊反應如何再作調整吧!)

.

13.png

藉由站立會議批判完成工作的指導與引導將決定這個工作體驗的目標與發展的意義大小

.

結語

運用引導來促發及落實學習,讓所獲得的知識能夠持久不忘! 如 Knapp(註 1)所言,表面的知隨著時間拉長,很快就會被遺忘,無法持久。只有透過延伸啟發的知才較能持久,而得以學以致用。工程師撰寫程式,其實從頭到尾就是一種學習的過程,只有程式設計人員真正學會了這一門技術,才可能把程式真正的寫好,因此落實工程師的學習深度,應該是讓專案成功的首要之道。工程師片段的完成程式,往往需要等到組合後才能將片段的知識進行會整,容易像學校教育一般停留在表面與操作之間的主「知」,所以我們經常進行「引導反思」讓片段的知識得以延伸與發想,則可能有超過預期的收獲(註3.學習效果)。因此,當工程師說「我完成了一個Task」的時候,我們應該即刻判斷,是否要花一點時間來進行「引導反思」,讓知識得以歸檔,管理不易遺失。或是可以更進一步的選擇作更大型的code reviw來落實學習呢?!對ㄧ個學習型的組織而言,這可能是最重要的決定,它攸關著辛苦獲得的知識是否能夠落實的保存下來,並得以發揮。

.

 

經驗必需要再經過 process 後,才可能轉變成有價值的知識。

 

.

還有一件事我忘了說,那就是讓團隊成員感覺在這裡是幸福的 Happiness,這是絕招(註4)。效果如下:

%e5%a5%bd%e7%9a%84%e9%96%8b%e7%99%bc%e5%9c%98%e9%9a%8a

 

.

註 1. Knapp 1992,Lasting Lesson: A Teacher’s Guide to Reflecting on Experience

參考: https://www.amazon.com/Lasting-Lessons-Teachers-Reflecting-Experience/dp/1880785064

註 2. R. Lessem(1990)的研究指出:二十一世紀在全球企業競爭風潮之下,未來的組織管理主流將是「發展型管理」,將來組織惟一持久的優勢是具備比競爭對手學習得更快的能力,是以二十一世紀可預見是「學習型組織」(learning organization)引領風潮的時代! (R. Lessem ,1990  Developmental Management. Blackwell, Oxford.)

註 3. Knapp 稱引導反思為一種知的管理。能促成實踐、反思及延伸啟發。

註 4.  by: Sonja Lyubomirsky,2005

註 5. 《引導反思的第一本書 》, 吳兆田著.

Written by ruddyllee

2017 年 02 月 13 日 at 15:59:32

極致的看板運作 : 讓看板成為 SCRUM 的引導工具

leave a comment »

01.png

「潛移暗化」,孔子曾說:「不要去結交道德修養不如自己的人。」和比自己更有品德的人交往,才能自然而然地受到他們的影響。後來「潛移默化」這句成語就從這裡的演變而出,形容人的思想、性格或習慣受到影響,不知不覺中起了變化。

透明化而非潛移默化

引導的目的在讓事情變得更容易進行,是一種讓事物更易於進展的技巧。當運用在團體活動時,便成為「以中立的立場管理團隊活動的各個過程,引出團隊合作,對其提供支援,以讓團隊活動的成果達到優化,或達到最佳化的效果的活動謂之。」而看板正可以運用透明化的特性,讓團隊預先知道接下來要做些什麼的可視化能力,讓團隊的成員能夠提前啟動思考,讓人們透過視覺化後得以降低對未來不確定的恐懼或疑惑。這一點不只能運用在團體的活動項目上,對於傳統的 PPT式教學也能夠提供很大的幫助。

投影片15.PNG

PPT式的教學,少了聽眾的參與和互動,效果打了折扣。

.

Ppt式的講課方式,是典型單向的「推」的授課方式,若能運用引導的技巧,讓授課產生了「拉」的行為模式,則效果必定加倍。試想;透視覺化的看板,讓參與者一目了然於接下來的步驟和行為,再運一些有趣、引人深省的圖像,隨著講述的內容相互輝映,跳躍呈現在看板上頭,這種顯示方式不但可以加深聽者的記憶,更能引發學員有跳脫框架式的聯想,真是太有價值了。(註 1)

投影片13.PNG

一個描述展示會議過程的看板

 .

一目了然的「展示會議看板」,任何進入展示會場的人士,只要看一眼看板就可以清楚的知道今天的議程,而對遲到的人或沒跟上議程的人士,也能很快的跟上來。上面的圖示,表明了這次的展示會議將會有一個大(L)的展示及一個小(S)的展示,展示後將進行回饋,他們的限制WIP數個別是 5 跟 3個回饋。而目前正在進行第二個展示項目。Sprint 目標區的 3及4的工作今天將不進行展示及回饋。

 .

一目了然的看板: 揭開看板在Column之間的規範

很多規畫看板的人士都忽略了,讓人們很清楚的知道看板背後的各個欄位的規則,可以十分有效的造成團隊的共識。作者Henrik Kniberg的佳作,針對看板的說明直接描述在看板下方,簡明易懂效果奇佳。

投影片9.png

運用圖像,簡單的說明圖示及欄位規則

 .

運用看板作為視覺化的引導工具 – 展示會議

這張圖示就是上面的展示會議看板,但稍稍作了一下變化,讓展示變成聖誕節的禮物或是過年過節時的紅包,有人會不喜歡的嗎? 是跨張了些,但回饋是鞭炮,大的、小的或一連串的炮竹果然是來自利益相關者的回饋,不過癮嗎?!

15.png

看板也可以輕鬆一下

.

結語

引導是一種技巧,因為很容易運用因此也很容易誤導,所以務必謹記減少誤踩"引導的技術債" (有人默認了,但心存不爽) — 當你常常運用引導的方式來刻意的影響或改變團隊的決擇時,可能會有不小心走了捷徑(違背了團隊的正常決策體系)而自己卻沒有查覺到的情形,久而久之後自然會累積出不良的團隊反饋(團隊成員不願意作決策、容易起衝突、鬧皮氣),就稱之為「不良引導所產生的技術債」。而用來消除引導技術債的良方,則是持續培養建立給予團隊自我作決策的依據標準(例如: 道德標準),而運用看板方法進行引導時,可以視覺化的力量消彌技術債的累積。

(年初收到北京 2017DevOpsDays的邀請函,順勢就把最近自己正在嘗試的看板與引導作了結合,拿來做發表的題目。希望對大家有些幫助! )

目前的PPT檔如下:

(右上角的符號,表示: Must: 一定會講的, Should have: 應該會講, Could have: 可能會講, Won’t have: 不會講的)

02

 

06_02.png

08.png

04

05

06

07

08

09

10

11

12

15

 

16

17

18

19

20

21

24.png

47.png

註 1.

PPT的推與拉;請參考 David Sibbet 著 Visual Meetings。及"PPT的認知風格"網路請搜尋PowerPoint Tufte.

 

Written by ruddyllee

2017 年 01 月 27 日 at 11:47:20

張貼於未分類

從敏捷建模看Google Sprint

leave a comment »

.

現代的工程師寫程式的方式太隨性了! 不禁讓人有些懷念那種命令式的開發方式;它硬性的規定你一定要先作完這個才能進行下一步(其實這一點,還蠻適合一些自主性差或太衝動愛自幹的工程師)。但在敏捷當道的時代,人們太容易在還沒有弄清楚要做什麼之前,團隊裡就已經有工程師自以為是的偷偷起跑了,後遺症當然是返工跟無形間所增加的溝通成本。這一點;會讓人懷疑起,是不是所有的工程師都適合採用敏捷開發呢?

 .

我想說的是,建模優先: 談一下「敏捷建模」

我習慣在動手寫程式之前先畫張草圖,在草圖上嘗試著對相關的功能元件進行命名,然後試著標示它們的輸入及輸出屬性,接著再把它們串起來,然後進行修修改改的補強動作,最後在劃一個大框框把它們通通包起來。在隨後的程式撰寫中,這張圖示將一直映射在我的腦海裡,我會隨興的在程式碼中修正它,但通常不會再回去修改圖了,而最後在終於能夠成功通過測試之後,它便成了最終的模型了。如果有機會在Demo meeting時作展示的話,它會進一步成為powerpoint的產物,然後就成了可以交付與公開展示的文件了。

.

FullSizeRender.jpg

手繪程式功能模型草圖

.

敏捷化的建模,可以是一張草圖,一些描述恰恰好的使用者故事伴隨著淺顯易懂的示意圖。

.

一個感想,為了敏捷而過度的忽略了一些好的開發行為

Modeling「建模」這個字言似乎成了軟體世界的禁忌辭彙,有一段時間沒聽人提起它了。即便聽到有人說到建模時,也總是語帶保留戰戰兢兢的作了一堆附帶的說明,深怕被誤會要大張旗鼓的製作文件或花上很多時間來建立模型。這可能是敏捷初期大家害怕被誤解為又要來CMMI這一套複雜的開發作業所致吧!但老實說;在開發作業前的建模是讓大家能有一致認知的一種重要行為,是非常有價值的動作,只是要能兼具模型的價值與平衡花多少時間來建立模型的投資時間,它是否值得這麼做呢? 則是依你自己如何來實行所造成的(敏捷是一種在務實不過的精神了,減少不必要的浪費經常是第一考量)。

【 對 Modeling 的一些誤解

  • 模型 = 文件

  • 可以在一開始就把什麼都想清楚

  • 建模意味著重量級的軟體開發過程

  • 必須凍結需求

  • 設計是刻在石頭裡的

  • 必須使用Case 工具

  • 建模是浪費時間

  • 世界繞著數據建模轉

  • 開發人員都知道怎麼建模

》參考自《敏捷建模》原書的 第九章 培養敏捷文化。(原本想一一做說明的,但怕見文章變得臭又長,就刪掉了)

.

Google sprint 就是快速建模

年前看了Google為創投所作的五日 Sprint(書名: Google創投認證!SPRINT衝刺計畫,這一陣子Google開發團隊出了一系列的好書,幾乎都可成為教材,感恩了!), 這五天是: 第天,以終為始,確定明確目標。第天,檢視舊點子,畫出方案草圖。第天,決定,選擇最佳方案。第天,模擬,只需要做出逼真的外觀,作原型。第天,回饋,小數據,詢問五個人,問對問題吸取教訓。巨觀的來看它,在這五日裡,團隊只有一天是花在實作上,其他時間都只是在建模!我想這可稱它為精實建模或是敏捷建模呢?!

於是就上網尋找了一下,結果找到的是《敏捷建模:极限编程和统一过程的有效实践

.

book.png

Scott W. Ambler 2002, March

.

原文: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process 2002年三月出版的老書(簡體版已經買不到了)。這是一本唯一掛上敏捷字眼,然後大談建模的書了,書中提到:當一個模型能夠滿足以下條件時,它就是足夠好的:

  •  滿足了創建者的目的

  • 易於理解的

  • 足夠精確的

  • 有足夠的一致性

  • 是足夠詳細的

  • 提供專業的價值

  • 是盡可能簡單的

.

基本上;《Google Sprint》完全符合上述的條件,因此可說成是一種敏捷建模,一種MVP式的敏捷建模。

.

敏捷模型的定義

敏捷建模是一個達到了它的目的而且僅此而已的模型。它能夠被所針對的聽眾理解,它簡單、足夠精確、一致和詳細,對創建和維護敏捷模型所做的投資提供了職級的價值。

.

這是Scott Ambler 對敏捷建模的定義詮釋,真是低調了,其實程式碼本身就是模型,程式設計人員在開始 coding 的時候模型就在持續地累積,由糢糊到逐漸清晰,由一個功能的完成到驗證,這就是在建模啊,他依循著程式設計師對問題的認識,然後再逐步的把解題方法實作出來,這幾個實踐的步驟,無一不是依靠自己對問題的認知與腦筋裡的解題模型一步一步來達成。因此,模式是解題前的基礎,這一點一直是敏捷開發乏人問津的一塊,或許是擔心又走回 CMMI 的長時間文書作業的惡夢,但這回精實創業的開發方法,所謂的 MVP 或是 Google Sprint 的做法,正好可以讓大家把注意力又拉回運用建模來解題的基礎上。敏捷開發在需求的描述上使用者故事,基本上也是一種建模,而且他兼具了足夠的抽象度,是一種絕佳的建模,只是少了圖形化的全貌視角,這一點幸好可以用使用者故事地圖(User story mapping)的技巧來補足它。

.

小結

逐步漸進、小增量的建模是敏捷化團隊不可或缺的行為,一張圖成就了溝通時的最佳利器。它既可讓創意者將腦子裡較凌散的觀念塑造成一個較完整的雛型,又可以讓團隊透過視覺化來迅速理解,進一步開啟討論的空間,實質的提供了快速的形成共識的機會。要敏捷化;怎能不做呢?!

建模的目的是為了能夠提高開發的品質和速度,同時能夠避免過度簡化和不切實際的期望,最後造成了過多的返工。尤其是進行團隊協作時,一個圖形模式可以迅速地造成大家一致的認識,是絕對有價值的。敏捷建模(Agile Modeling,簡寫程 AM) AM是有效的,而且在這個精創時代也又開始實行起來了(Google Sprint就是一個好例子)。AM告訴你:要使你的專案的投資最大化;應當有清晰的目的以及需要提供團隊在需要時要建立模型或文件(它可能是少數提到敏捷文件的地方,註1);運用合適的方式(工具)來記錄手頭的情形;不論何時都盡可能創建 簡單的模型。敏捷很好但千萬不要忽略了建模。寫程式不可缺少的建模行為。

.

解題之前請先建模

今天的模式早以被定位成溝通的中介質,但如果工程師只有一個人的時候,建模的價值,便成了對問題的更深入的認知了。

.

註1 敏捷文件 (Agile Documentation)

Agile 對文件的要求是一句 Just Enough 就好了。但是在實作時,工程師總是急著向前衝,大家總把作文件當成是停下來的行為,因此就是跑了一段很長的路程,然後沒有留下多少紀錄,這是最糟糕不過的。因此有很多團隊就開始把測試案例轉換成基本文件規範(這是好的一種現象),但其實筆記才是重點,一種紀錄開發過程重要事實的筆記紀錄,可以讓我們清晰看到或迅速回憶的筆記可能是最務實的做法,因為3個月以後第一個回過頭來看程式的人員,可能就是程式設計師自己了。所以一份讓自己迅速回憶相關知識的筆記可能才是文件記錄的真正重點,例如: 視覺圖像紀錄(Sketchnote)應該是這個時代的脈動之一吧?! (參考: Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects,2003)

.

上課時,老師發現有

同學在筆記本上進行塗鴉時,應該制止嗎?

.

Written by ruddyllee

2016 年 12 月 12 日 at 11:54:41

學習與解題

leave a comment »

.

詢問面試者:  當你()面對問題時,會如何思考? 如何蒐集資料以及如何做決定?

才是面試時最該弄清楚的重點。

  – 價值觀

.

我的職業是講師,專業的講師的生活就是講課(這是最少的一部份),然後是拼命的運動(健康凌架於一切),再過來便是學習了(這是一種無時無刻不在學習的職業生涯)。我是怎麼做到持續學習的呢?

.

生活.png.

 

好奇心才是學習時的首要之務

讓好奇心替自己做決定。好奇心驅動我的學習慾望,讓好奇的比重決定接下來要學什麼? 在這個資訊氾濫的時代,雜亂無序的訊息到處都是,過去我總是讓上天來決定接下來我該往哪裡去(也就是接下來該學點什麼?)而現在的我則是用好奇心來作判斷與區隔,看哪一件事比較吸引我的注意力,誰引發了我的學習慾望,我就一頭栽進去,一直到弄懂為止,不! 是一直要到可以教導別人為止。因為只有好奇心可以驅使我們不辭辛勞的持續去追求知識(Know how)。

.

英雄生於憂患

要捨得放棄舒適(這是成功的最基本因素,能夠擁有足夠的毅力下決定毅然地放棄心中的舒適情境,然後選擇較有挑戰的事去做。基本上;這就是我心中的「英雄作為」)、能夠毅然地放棄早已養成的習慣,堅持的去實現一種追求知識的衝動。也只有足夠的好奇心才能激發,這種持續追求知識的慾望,並驅動我們把它做好,在這樣的驅動力之下,成功的機率就自然提高了,所以總是把有限的時間放在好奇心的背包裡然後持續去追尋它。而這一點剛好是;如何讓團隊在專案開始之初盡快進入吸取專案相關學科的知識的方法。 請參考拉姆西的激發學習熱情 3法則。

.

激發學習熱情.png

參考: Ramsey Musallam 拉姆西 的「激發學習熱情法則」

.

20/80 法則

最容易澆熄好奇心熱情的是,你必須要面對接下來的複雜細節。任何一門學科在入門時總有門檻存在的,或許你可以稱之為撞牆期,要如何度過這段時期呢?它考驗著你的智慧、耐心與你對自己的人生規劃。一旦越過這堵高牆之後,快速成長的技能必將改變你的人生。我總是用帕累托法則(20/80法則,註 1.)來鼓勵年輕的學員,這是投入與回報的一種不平衡現象所誕生的理論,但;我一直以為經驗可以在這裡幫上忙,一種基本的專業的素養甚至可以在這裡左右成敗,我常把他稱之為 work smart。也就是讓自己只關注於20%的知識,然後能達成80% 的效益。其實重點在基礎上。也就是你是否弄清楚一些與這個問題最基本的學科知識了。它才是你能否做到 20/80 法則的關鍵因素(例如工程師對物件導向及模式架構的熟悉程度常常就是關鍵所在)。但無論如何,你一定會面對到這堵牆的,而最基本的解決方法是勇於面對和不去逃避它(小步前進是我最常採用的方式,當無法一步跨越它,當然就是多做幾次,用小步漸增的方式來達成囉!)。所以反覆思考,想清楚了就重新在來過是再務實不過的做法了,漸進的累積效果常常會給人持續下去的動力。

.

18.png

養成一種自我學習的本事

.

學會「自我學習」

工作來不及完成的時候就加班熬夜,以增加工時的方式來完成它。例外的是;這個世上有太多工作是屬於創作型的工作,這類型的工作完全無法用重複式的算法來估計進度,因此你問我「加班有用嗎?」這就好像你要求孩子去上課後輔導一樣,希望多上幾次就可以幫助孩子們學會這門學科。但是有關學習的效能,其實是好奇心決定了成果,不是時間的長短,只是家長們就是不信邪。就任由課後輔導與家教班的方式來充分的抹滅了孩子們的好奇心(這一點,反倒是成就了補習班老師的說故事能力。這群辛苦的老師,每天都要面對已經損失80%上課動能的學子,還要想盡辦法吸引他們的注意力,真是辛苦了)。所以學校真正該做的事,是養成孩子們「自我學習」的能力,而老師們真正該做的事,則是建立孩子們的好奇心。

一般人面對陌生知識的學習方法通常是嘗試錯誤法,這是人類最基本的學習方法,它有效的很! 只是挫折與付出就顯得高了些。如果你玩過魔術方塊的話就能體驗到,先嘗試一下解題遇到錯誤與挫折,在小小的成功之後記住教訓並設法在腦海裡印射出成功的模式,然後記住它,下次再遇到這種識曾相識的問題時就有解了。其實寫程式也就是這麼回事,這種成功的模式,在軟體界我們稱它為設計模式。它是需要長期的訓練與學習才會擁有的技能。

 

Dr. Strange 電影裡最吸引我的橋段:

古時候稱為咒語的這種東西,現在我們稱之為程式。

而魔法師便是現代的程式設計師了。

但是要如何才能成為魔法師呢? 回答是: 要透過不斷的訓練與學習。

 

–  奇異博士

{奇異博士古一大師,要如何成為魔法師古一反問奇異博士你是如何成為一名優秀的醫生的呢? 奇異博士 回答: 是透過經年累月不斷的訓練與學習。}

.

 

臨危受命

身為一個顧問,我經常臨危受命(有很多時候是我自願跳進去的),尤其是老闆們拍胸脯互相答應對方的專案事宜,(這種;完全沒有經過開發團隊的估算作業就已經被劃下結案日期的事情,在我做顧問的日子裡,還真是層出不窮),這時候當然不能讓工程師去受難啊!這是做顧問的基本職責。所以就養成自己這種跳火坑的習慣了,但在我介入之後,主管們總會在後面偷偷問我用了這些方法到底可以快多少呢? 此時,我心裡總是盤算著在20/80法則裡,團隊到底能掌握到多少? 是的,一般而言是可以快上幾倍之多,其實說穿了就是要 Work Smart,也就是盡量運用了解了的20%的知識去進行那80%的開發工作。我常常解釋這種Work Smart的成果,是來自於架構以及工程師的專業素養(註1.是否能善用設計模式及物件導向是影響最大的因素)。但這裡我要介紹的是軟技能一書作者John所發明的 「十步學習法」。是的;我把解題跟學習混為一談。

.

解題1.png

.

Learning – Doing – Learning – Teaching

學習 – 實作 – 掌握 – 教授

By: John Z. Sonmez

.

先期準備,形成自學模式

專案開始之初;首先要能看見全局,然後把範圍定下來,接著弄清楚我們可以做到那些(定義)目標,再來是把手上所掌握的資源過濾一下,想清楚從哪裡是最好開始的地方 (創建學習計畫)。 OK,這就是我們自學的前置過程了(前六個步驟是研究準備時期)。這便是十步學習法的前六個步驟,乍看起來還真像極了我們在專案開發初期地做法,先弄清楚專案的全貌,在把範圍也就是邊界畫出來,然後才能開始預估需要多少的資源與時間(所以我把十步學習法稱為十步解題法)。

.

10%e6%ad%a5_1

.

學習方法即解題法則

後四個步驟,就是透過「學習、實作、掌握、教授」進行學習,至於要學習什麼呢? 當然是專案領域的專業知識,這是寫程式之前的必須功課,就是弄清楚要開發的是什麼樣的東西。此時要運用敏捷的核心觀念,小步前進,才可以避免被大量的細節所誤導,而走錯路了,說穿了;就是善用 20/80法則,在正確的方向上持續前進,快速學習。讓我們回過頭來看一下學習金字塔,也就不會奇怪為何最後一步還要教授他人了,因為學習效果最好的是立即學以致用或拿來教授他人(團隊常常做code review的手法在這一點上,可能十分適用)。

.

15_1

.

學習就是解題

工程師需要快速形成自我學習的模式,因為在你開始動工寫程式之前,一定得先學會相關的學科知識才成,所以在學會它之前,你是很難開始動手coding的。所以學習是工程師一開始時的第一要務,而且大部時間裡不會有人主動來教你的,所以自我學習可能是你唯一的途徑了,而所謂的十步學習法,其實正是要教你如何展開自我學習的步驟罷了!至於後面的四步循環,則是強調人們總是透過實作才能進一步了解相關知識的重要性,然後在透過教學相長,才能客觀的評分自己到底學到了多少東西。(這一點正如學習金字塔所做的說明)

.

要學好一種學問,最怕的是一開始就被錯綜複雜的細節所誤導了,尤其是現在的搜尋技術如此的強大,任何搜尋都能查到相當多的細項訊息,很容易就讓人輕易的掉入了訊息的洪流裡,導致我們分散了或忘了原本所想尋找的主題。這正是我所謂的 20/80法則的好處了,透過小量的資訊閱讀專注於 20%的基礎訊息。

.

kanban.png

運用看板來執行十步學習法

.

十步學習法

有二個大步驟,首先是研究準備: 1 ~ 6步(我把它隱含在 定義完成的欄位裡, DoR: Definition of Ready),接著是循環重複的過程 7~10步驟(明顯的學習後的回饋是很重要的)。前面的重點在弄清楚狀況,好擬定學習計畫。後面則是紮實而深入的學習動作,一點都不能偷懶(請參考上面的學習金字塔)。

很少有一個時代像我們這般被資訊淹沒的,10分鐘前才看到FB好友的留言,當時忘了按,事後想補按一下,結果就是在PO文的川流中開始找尋它的蹤跡了。這類訊息的流通方式及過多的流量資訊,真是可怕的很!千萬別輕視它,因為過多的訊息它相對的替我們製造了無比的壓力。這是一種新興事物或是群組所帶來的壓力,我們經常被迫必須快速的回應,自然會形成一股壓力。如果其中又牽扯到更多需要經過消化或學習才會了解的學科常識的話,就會經常觸發我們必須快速學習、消化資訊的壓力,因此不論你是從事何種行業的,快速學習好像都是一種必備的技能。而這種快速學習的方式又明顯得跟我們在學校時的讀書方式大異其趣,所以好像人人都應該建立一種自我學習的模式。運用科技的協助,快速的捕抓資訊,並轉化為對自己有用的知識體系,這裡所談的「十步學習法」正是一種能夠培養你自我學習的學習步驟。步驟雖然多了,但是工程師而言真是再適合不過的了。因為前六不跟我們做專案開始時的思維十分吻合,而後四步則是最基本的教學相長型的學習步調(它與費曼的快速學習法完全相同)。

.

21.png

我雖然是學物理的,但認識費曼先生還是從上面這本書開始的

.

結論

程式開發就是一場學習的過程,團隊必須透過學習才可能了解相關學科的專業知識,也才可能開始coding,因此什麼時候讓團隊開始學習的過程,便是專案開始進入狀況的時候,而工程師們學習得好壞則是開發作業是否順利的基本保證,這一點很難有例外的。一知半解的程式設計人員就會產出一缸子的缺陷bug,然後團隊必須在日後再花上數倍的時間來修正這些錯誤,這些修修補補的債務,也會間接的造成軟體生命週期的縮減,實在是最糟糕的一種開發模式。所以一如敏捷開發的小步迭代開發一般,程式設計人員也應該小量學習知識然後在了解之後,讓程式也採用小量前進的方式進行。此時的作業完全在考驗著程式設計人員的專業素養和他們自我學習的能力。這是何等重要的二大因素,專業素養是絕對需要花很長時間去培養的,但自我學的能力卻是有很多方法可以幫得上忙的。上面的十步學習法就是來自《軟技能》一書作者的佳作,目的正是在培養工程師的自學能力。借助經常性的練習,希望對工程師們能有所幫助。至於學習後再運用學會的知識來創作程式,別忘了筆記成文件,讓程式的生命週期更容易被維護或更容易新增需求,讓這些記錄著學習及撰寫程式過程的文件成為維護者的重要知識來源了。

.

10

開發人員最了解需求的時刻是最值得珍惜的時刻,應該設法補抓這一刻。

(應當運用筆記的方式來記錄知識並製作成文件)

.

  1. 80/20的法則認為:原因和結果、投入和產出、努力和報酬之間本來存在著無法解釋的不平衡。一般來說,投入和努力可以分為兩種不同的類型:

  • 多數,它們只能造成少許的影響;
  • 少數,它們造成主要的、重大的影響。

需求為何一定要排序的理由,20/80法則也說得通,只是業者從來就不認為 20%其實就夠了。

  1. 《軟技能》 作者 John Z. Sonmez

        十步學習法 在第三篇學習篇 的125頁。

.

Written by ruddyllee

2016 年 11 月 24 日 at 11:36:31