Ruddy Lee 分享空間

Emergent Design 演化設計

從敏捷建模看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

先讓英雄救貓咪 session ppt

with 2 comments

.

01.png

.

01_01.png

.

03.png

.

03_01

.

03_02.png

.

04.png

.

06

.

07.png

.

08.png

.

10.png

.

09.png

.

10

.

13.png

.

14.png

.

15.png

.

16

.

17.png

.

15_1

.

19.png

.

20.png

.20_1.png.

10%e6%ad%a5_1

.

21.png

.

22

.

23.png

.

24.png

.

 

接下來是 彩蛋時間 …

 

.

19

.

20

.

.

.

.

.

.

.

.

47.png

.

48.png

.

註:

  1. 這是預定的演講內容,但提醒大家: 當我們在窺視未來時,未來也會跟著改變的。
  2. 奇異博士片段參考自yutube上的早期預告,與實際上映稍有不同,強調需求與現實必定有所差異,請大家重視版權,上電影院欣賞吧。
  3. 場景示意圖取材自 Google Sprint 的佳作,它才是說好故事的流程圖示,適合探索及開發需求時全程採用(而 使用者故事地圖影響地圖 則是絕佳的分析工具)。

.

 

 

 

Written by ruddyllee

2016 年 11 月 16 日 at 11:16:14

顧問第一守則: 專案透明化

leave a comment »

.

透明化;觀測者能夠對所看見的事物有一個共同的認知

–       Scrum Guide

.

這是專案透明化嗎?

現在的ALM工具都做得太好了。各級主管幾乎可以坐在房間裡頭,無須透過任何層次的會議或等待就可以看到專案的進度報告,這種隨時隨地可以獲得專案即時資訊的方式,讓專案進度的能見度大大的提升了,尤其是對擁有遠端開發團隊的組織,不論在控制或管理上都是一大利器。但這就叫專案透明化嗎?

.

%e9%80%8f%e6%98%8e%e5%8c%961

管理階層與開發團隊有共同的認知才是真正的專案透明化

.

讓專案真正的透明化

讓與專案有關的人士有著「共同的認知」才是真正的專案透明化。這是我做顧問時的第一件要務,設法讓專案透明化,也就是讓與專案有關的人士都能擁有共同的認知。所謂共同的認知,指的是看到或聽到同一份報告或畫面時,能有著相同的感覺與理解。能夠具有「看見」的深一層意義。這便是為何要在顧問工作的一開始;先處理人們對專案的認知問題。設法讓與團隊有關的各種人士,都能夠擁有相同的共識。

要知道;這一點通常就是造成組織對專案人員、團隊有所報怨,或對進度始終感到不滿意的真正問題所在。原由是;他們沒有看到真正的問題,亦或是看到了卻有著完全不同的詮釋,結果就是造成一堆沒必要的誤解跟不滿,以至於產生了,主管始終不了解開發團隊真正的疾苦,而開發團隊又始終沒能得到上級有用的支援的種種現象,這要歸罪於沒有能讓專案真正的被看見。因此我把它定為做顧問時的第一守則: 讓專案透明化。也就是大家對專案都能有相同的認知。

.

顧問目標.png

顧問針對組織問題而提出解題之道的目標輪迴

.

顧問工作: 一開始,總以為是一些技術上的問題

在與工程師進行訪談作業時,我們很容易發覺是 專業素養 上的不足以至於產生了這些問題。但對於工程師在專業上的知識而言,永遠沒有足夠的時候。而這些問題的背後,一定還有其他隱藏的問題存在。 然後,馬上你就會聯想到應該是 系统架構 方面的問題所造成的現象。如果要徹底解決的話,改變 工作流程 應該是最有效的方法,接著你就會開始思考要如何來推廣新的工作流程也就是新的 軟體開發方式。然而推廣的過程中,你將會發現敏捷開發在執行起來有很多地方會與公司的 管理政策 上有些牴觸,勢必要與管理階層進行大量的溝通才行。 繞了一大圈,最後你會發現實際上還是 人的問題。因此我總是盡量掌握與公司高層接觸的機會,不斷灌輸、強調公司高層的敏捷觀念是不是足夠,才是公司實施敏捷化是否會成功的最大要素,也就是說 公司文化 在進行敏捷開發時的調適性才是最大的問題(而解題之道,當然是精實文化)。而我在一開始所能做的便是;讓專案盡量的透明化。

 .

想讓專案透明化:

最好的方法 – 運用看板方法讓開發工作被看得見。

最好的時機 – 在站立會議時作更新,讓開發團隊能更忠於自己的工作。

.

具體方法怎麼做呢? 請參考 如何讓專案透明化?

 .

:

軟體生命週期管理 (Application lifecycle management),是指軟體從產生一直到報廢的全部過程。

.

Written by ruddyllee

2016 年 11 月 13 日 at 20:47:37

Scrum 的 SOP

leave a comment »

.

Scrum 有標準作業程序SOP?

答案是當然沒有。執行 Scrum的方式千變萬化,有無數種可以執行Scrum的方法,重點在能夠符合「Scrum指南」的指導原則。那麼「Scrum指南」在某種程度上,應該也可以說是某種 SOP? 答案還是錯的。Scrum指南不是SOP

Scrum是敏捷開發的一員,「目的是為了使用在管理複雜的產品開發上。Scrum 並不是用來建造產品的一個工作流程或者技術,因此我們常說它是一個架構。」(節錄自Scrum指南)

但是,如果我們需要某種SOP來協助使用者快速且明確地上手的時候,怎麼辦呢?

.

01

 

.

02

.04

.05

.

06

.15

.22

.27

.31

.

38.png

.39

.40

.41

.

 

Written by ruddyllee

2016 年 11 月 03 日 at 11:34:51

張貼於未分類

消化需求,拯救這個世界

with 2 comments

.

程式碼不會改變這個世界,需求才會。

.

專家.png

PO及開發團隊對需求了解程度圖示(註1)

.

》工程師在開發程式的過程中,經常會覺得自己才是最了解這個行業的人士(上圖中的藍色曲線說明了這一點)。

.

【圖示說明】

縱軸是對需求了解的專業度,橫軸是開發的時間,描述的是ㄧ個sprint 的開發週期。

.① 是程式設計人員一邊進行程式開發,一邊持續吸收專業知識,迅速成為行業的專家。

.② 綠色的線條,指的是需求的提出者 PO,他由對產品的初步構想一直到工程師交付產品後的知識變化曲線。

.③ 藍色的線條,指的是開發團隊,由對產品的一無所知開始學習的路程,一直到達 ① 的至高點成為行業的專家,再到交付後對專業知識的迅速遺忘的曲線。

.④ 通過定義完成(DOD)點時,工程師的專業知識迅速下降,但 PO 透過對產品的學習操作,維持了它對產品的認知。

 

.

寫程式是一種學習的過程

程式設計人員是知識的消化者。他們在大量的訊息中尋找有用的知識。透過無數次的排列組合,努力的從凌散龐大的訊息中尋找組合出一幅看起來有意義的簡單圖示,它們是一串讓我們感覺得出意義來的模型圖示。然後在似懂非懂又隱含著抽象跟模糊不清的一堆想法下,我們開始以嘗試錯誤的方式來撰寫程式的過程(此時;在我們腦海裡的模型越是清晰明確,寫出來的程式就越加實用持久)。

其實一開始我們知道得很少,知識隱含在很多人和許多文件中,當然其中也夾雜著許多無用的知識,所以在寫程式的過程裡我們必需持續的去請教專家或通過搜尋再進行過濾學習。一直到上圖 ① 的地步,程式設計人員經由學習而逐漸成為行業的專家。

.

成為高效的知識消化者

好的程式設計人員需要能夠迅速累積專業知識,當然我們不可能真正成為所有建構軟體的從業人員,所以我們快速獲得的知識也會迅速的遺失。但上圖中那個紅點的高度以及那條曲線的斜率,決定了程式設計師交卷時的品質及時間。(請注意,程式設計人員往往是一個團隊,而不僅僅是一個人)如果我們學得越快越好,也就是對所開發軟體的行業知識認識得越深(也就是上面提到的那個知識模型,一般我們稱它為領域知識模型),則明顯的開發出來的軟體會越優秀對環境的適應性越佳,也就有著較長的軟體生命週期,反之;則可能只是達到使用者足以操作而生命週期十分短暫的軟體。

如 ④ 所顯示的曲線迅速下滑區。所有的專案都會有這個知識遺失期。在團隊裡頭學到這些知識的人員,可能又去做其他的工作了,當然團隊也可能解散或重組去進行其它的任務。要避免或減少大量知識遺失的最佳方法,就是透過作成文件來記錄避免知識的掉失。所以工程師除了高效學習之外,要培養做好文件及使自己能夠從文件中培養迅速學習知識的雙向能力。

.

【圖示說明】

Ready 的綠色區域,我們稱之為 DOR: Definition Of Ready定義「文件備妥區」。Sprint 從這裡開始,它是需求品質的把關點。

Done 的紅色區域,我們稱之為 DOD: Definition Of Done 「定義完成區」。Sprint 結束在這裡,這裡是產品品質的關鍵點。

簡單的解讀:

》當 ① 的專業知識點越高,則表示團隊對需求的了解越深,程式便可能更優秀,有著更高的實用性及擴展度。

》當DOR 與 DOD的區間越小,則表示工程師的學習能力越強,團隊開發的效能越高。

※我們可以透過看板方法的累積流程圖來得到這些數據。

.

是需求在改變這個世界

我是一個軟體工程師,但我立志要拯救這個世界(Save the world. 每回說到這裡大家都會哈哈大笑! 這是多年以前從電影裡學到的,但老實說沒在開玩笑,我終身信奉)。這是我的志願,而達成它的作法則是透過不斷為他人增加價值(是的,是透過為別人增加加值,來提升自己的價值,也就是透過撰寫一些真正有用的軟體來貢獻社會),為人們服務,給人們他們所想要的東西,當然前提是要知道他想要的是什麼,也就是弄清楚需求。原因;是我體會到不是我們的程式碼在改變這個世界,而是需求在改變這個世界,而我們透過持續的努力來滿足他,來創造這個價值,至於成功嘛,則只是伴隨而來的紅利罷了。

.

工程師的職責就是消化需求,拯救這個世界。

.

 

註 1. 參考 Ken.Power 對 DOR: Definition Of Ready 的說明圖示

.

 

 

 

Written by ruddyllee

2016 年 10 月 27 日 at 14:50:46

3 + 3 的 Scrum 教學

leave a comment »

.

33

運用 3 個半天進行Scrum 教學 + 3 個半天的訪談

.

問題: 只有用3個半天的時間來講解Scrum夠嗎?為什麼要浪費3個半天作訪談呢?為何不全部拿來上課,不是可以講得更深入些嗎?

 

{因為純上課的效果十分有限(註2),所以講求務實的敏捷教學,通常會透過遊戲、引導等等方式來加強學習的效果。而我常用的方式就是 3+3的Scrum教學模式}

.

 回答

 》首先說明一下「訪談」的部分要作什麼?

訪談前我會先要求主管給我他個人對訪談對象的Comment, 包括他(受訪談者)表現好的、不好的地方以及他期許受訪談者未來能夠對團隊作出什麼樣的貢獻。有了這份基本資料後我就可以比較清楚應該跟訪談的人聊些什麼了。

[主管準備資料]

  • @ 該員工表現好的地方。
  • @ 表現的不好的地方。
  • @ 團隊及長官對該員的期許。

 .

[訪談內容]

任務ㄧ、首先是對受訪者增加認識,然後試著讓他用個人的角度來談一下這個公司及他所屬的團隊(讓ㄧ個人有機會說出他對組織的想法,是作任何改變之前ㄧ定要作的步驟,它叫作歸零。),然後才是試著用他個人的主觀角度去引導他朝向主管的期許去前進,但重點是促發他自行構築未來的方向。

任務二、接著是交付給他與Scrum有關的作業,要求受訪者對Scrum裡的特定約束作演講準備,例如: 深入說明 「PO的職責」或是「描述計畫會議」的進行方式。作業的目的是作到費曼先生所謂的增強學習的效果(教學相長)。還有另一層作用是形成Scrum所謂的全職能工程師的目標,藉由讓團隊中的每個人個自準備不同的主題,(個自擁有ㄧ個較熟練的主題:專長),藉此製造ㄧ種專家式(彼此可以互補)的相互信任模式,來形成他們樂於相互討論與有效的交流,說穿了就是建立團隊的信任基礎。

.

》訪談是採用ㄧ對ㄧ的模式,我可以詢問到學員對上課內容的了解程度或是提供他們詢問的機會。是一種絕佳的雙向回饋方式,雖然成本高了些但對建立團隊的敏捷觀卻是相當有價值的。同時,半天的訪談可以讓團隊在上完半天課後,有下一個半天的時間來繼續手上的工作,或是用來消化課程的內容。既可增強學習效果,又可以減少對工作時間的浪費。

.

 [3個半天的Scrum教學]

 最後來談一下3個半天能講出什麼樣的Scrum來。首先,我們依據Scrum指導手冊來作為課程依據。它只有10多頁(還要扣掉封面、目錄及最後的感謝文),其中最有趣的是它只說明了我們都知道最重要的四大會議的目的,但對會議應該如何執行卻不作任何說明或規定。原因是這些會議應該依據符合該執行組織的文化來進行,只要目的及產出物是明確的,至於如何進行最好,就交給團隊自行作主,重點是懂得持續改善就可以了!所以我把3個半天定位在:敏捷化的精神,符合Scrum指導手冊的指導原則的Scrum實作以及協助團隊建立一個認知基礎(未來才好持續改善),這三個重點來作講解。

[教學重點]

  • @ 敏捷化的精神
  • @ 如何實施Scrum
  • @ 個人與團隊如何敏捷化

.

註1 : Scrum 指導手冊只有簡單的說明

※節錄Scrum指南對「短衝計劃會議」的說明

短衝計劃會議

短衝內要做的工作會在短衝計劃會議中來訂定。工作計劃是由整個 Scrum 團隊協同來制定的。

短衝計劃會議是限時的,以一個月的短衝來説最多八小時爲上限。對於少於一個月的短衝,

這個會議時間通常會縮短。Scrum 隊長確定會議會召開以及參與人員了解會議的目的。

Scrum 隊長教導 Scrum 團隊在時間內完成。

短衝計劃會議回答以下問題

  • 本次短衝的目標為何?
  • 這次短衝可以發表什麼樣的遞增成品?
  • 什麼樣的工作是必須的才能夠達成遞增成品的發表?

.

註2. 學習金字塔

學習金字塔.png

第一種學習方式——「聽講」,也就是老師在上面說,學生在下面聽,這種我們最熟悉最常用的方式,學習效果卻是最低的,兩周以後學習的內容只能留下5%。
第二種,通過「閱讀」方式學到的內容,可以保留10%。
第三種,用「聲音、圖片」的方式學習,可以達到20%。
第四種,是「示範」,採用這種學習方式,可以記住30%。
第五種,「小組討論」,可以記住50%的內容。
第六種,「做中學」或「實際演練」,可以達到75%。
最後一種在金字塔基座位置的學習方式,是「教別人」或者「馬上應用」,可以記住90%的學習內容。
{參考自 學習金字塔}

 .

 

Written by ruddyllee

2016 年 10 月 21 日 at 10:02:03