Ruddy Lee 分享空間

Emergent Design 演化設計

學習與解題

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 one comment

.

01.png

.

01_01.png

.

03.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

.

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

你這輩子唯一需要的程式設計指南?

leave a comment »

.

<< 參考 PPT 在這裡 >>

尋找這本書的原由是因為另一本書叫《先讓英雄救貓咪:你這輩子唯一需要的電影編劇指南》,完全是因為它的副標題所造成的(你這輩子唯一需要的電影編劇指南,可能嗎?!如果編劇可以,那程式設計可以嗎?難道寫程式會比拍攝電影還要困難!)。因為我答應《agile tour Taipei 2016》會以「先讓英雄救貓咪」這本書的書名做一場演講,而這個副標題又這麼有挑戰性,怎能放過呢! 因此自己就開始持續在尋找這個答案,似乎找到了但又充滿了疑惑?!而說出來又好像會造成負面效應,想了再想還是留在會場上說吧。

.

投影片4.PNG雖然 李安 試過程式開發的路途,然後他沒有成功 …,但這不代表寫程式就比較難!

.

 

但,在找尋「你這輩子唯一需要的程式設計指南」的時候,無意間找到的另一本老書(2006),它有著相同的意義: 「软件工程的事实与谬误」by Rebert L. Glass,值得陳列給大家。書裡頭陳述了55個事實及5+5個謬誤,節錄如下:

{ 它的pdf檔應該很容易在網路上瀏覽到 }

事實1:在軟體發展中,最重要的因素不是程式師採用的工具和技術,而是程式師自身的品質。

事實2:對“個體差異”研究表明,最好的程式師要比最差的程式師強28倍之多,即使他們的報酬不同,優秀程式師仍是軟體業中最廉價的勞動力。

事實3:(Brook法則)給延期的專案增加人手會使專案進一步延期。

事實4:工作環境對工作效率和產品品質有深刻影響。

事實5:多數軟體工具對於效率和品質的提高幅度僅為5%~35%,但是總有人反復的說提高幅度是數量級的。

事實6:學習新工具和新技術的初期,程式師的工作效率和產品品質都會下降,只有克服了學習曲線以後,才可能得到實質性的收益。

事實7:軟體發展者對工具說得多,評估得少,買得多,用得少。

事實8:專案失控的兩個主要原因之一是糟糕的預算。

事實9:許多估算是在軟體生命週期開始時所完成的,後來,我們才認識到在需求定義以前,即理解問題之前進行專案估算是不正確的;也就是說,估算時機是錯誤的。

事實10:許多軟體專案是由高層管理人員或行銷人員來估算,而不是真正構建軟體的人或是他們的主管來進行估算。因此,估算軟體的人員是錯誤的。

事實11:軟體估算很少根據專案進度進行調整。因此,這些估算通常是錯誤的人 在錯誤的時間 所得出的錯誤結果。

事實12:因為估算的資料是如此的糟糕,所以在軟體專案不能達到估算目標時,不應該再考慮估算。但無論如何,每個人都在考慮它。

事實13:在管理者和程式師之間存在隔閡。對於一個未滿足估算目標的專案的調查表明:從管理者看來失敗的一個專案,可是技術人員看來卻是最成功的專案。

事實14:對於可行性調研的回答幾乎總是可行。

事實15:小規模的複用(副程式庫)開始於50多年以前,這個問題已經得到很好的解決。

事實16:雖然每個人都認為大規模的複用(元件)非常重要,非常急需,但這個問題至今還沒有基本解決。

事實17:大規模複用最好使用於相關的系統,也就是依賴於具體應用領域,這樣就限制了它的應用。

事實18:有關複用問題,有兩個“三倍法則”:(1)構建可複用元件比使用元件難三倍。(2)在將組件收錄到複用庫並成為萬用群組件之前,應該在三個不同的應用中嘗試應用該組件。

事實19:修改複用的程式碼特別容易引起錯誤。在一個元件中超過20%~25%的程式碼需要修改,那麼重新實現效率會更高。

事實20:設計模式複用是解決程式碼複用中固有問題的一種方法。

                設計模式源於實踐,而不是理論。

事實21:問題的複雜性增加25%,解決方案的複雜性就增加100%。這不是一個可改變的條件(即使人們努力降低複雜性),而是客觀存在的。

事實22:80%的軟體工作是智力活動,相當大的比例是創造性的活動,很少是文書性的工作。

事實23:導致項目失控的兩個常見原因之一是不穩定的需求。

事實24:在產品完成時修訂需求錯誤的代價最大,在開發早期修訂需求錯誤的代價最小。

事實25:遺漏需求是最難修訂的需求錯誤。

最持久的軟體錯誤是遺漏邏輯錯誤,它可以逃離軟體測試過程,進入發佈的產品中。遺漏需求導致遺漏邏輯。

事實26:從需求轉入設計時,因為制定方案的複雜性,會激生出大量的衍生需求(針對一種特定設計方案的需求)。設計需求是原始需求的50倍之多。

事實27:對於一個軟體問題,通常不存在唯一的最佳設計方案。

事實28:設計是一個複雜的反覆運算的過程,最初的設計方案可能是錯誤的,當然也不是最優的。

事實29:從設計轉向編碼階段,設計者按照自己的水準,已經將問題分解成原始語言。如果程式設計者和設計者不是同一個人,二者的原始語言不吻合,就會出現問題。

事實30:COBOL語言是一種非常糟糕的語言,但是其他的(用於商業資料處理的)語言也同樣糟糕。

事實31:錯誤消除是軟體生命週期中最耗時的階段。

        Checkout 檢出 testing 測試  verification and validation 驗證和確認

事實32:普通程式師認為已經徹底測試過的軟體其實只執行了55%~60%的邏輯路徑。採用覆蓋分析器等自動化工具,可以將上述比例提高到85%~90%。幾乎不可能測試軟將中100%的邏輯路徑。

      需求驅動測試(測試是否滿足了需求)

      結構驅動測試(測試已構建的軟體所有組成部分是否正確運行)

      統計驅動測試(隨機測試確定軟體執行的時間和結果)

      風險驅動測試(測試確定是否已經消除了最重要的風險)

事實33:即使測試覆蓋有可能達到100%,這種測試也不夠。大約35%的錯誤來源於邏輯路徑的缺失,還有40%的錯誤來源於執行特定路徑的組合。不可能實現100%的覆蓋。

事實34:沒有工具就無法做好錯誤消除工作。人們常用調試器,很少使用覆蓋分析器等其他工具。

事實35:自動測試太少,也就是說有些測試可以也應該自動完成,但是有許多測試任務不能自動完成。

事實36:程式師在程式中嵌入測試程式碼,目標程式碼中的編譯參數等方法,都是測試工具的重要補充。

事實37:在運行第一個測試用例之前進行嚴格的審查可以消除軟體產品中多達90%的錯誤。

事實38:雖然審查有很多優點,但是不能也不應該代替測試。

事實39:事後評審對於瞭解客戶的滿意度和改進軟體過程都很重要。但是很多公司不進行事後評審。

        多數人建議在軟體交付3~12個月進行事後評審。

 事實40:同行評審涉及技術和社會兩個方面的問題,忽視任何一方面都回產生嚴重的災難。

事實41:維護開支通常占軟體成本的40%~80%(平均60%)。因此,維護可能是軟體生命週期中最重要的階段。

               古老的硬體會被廢棄,古老的軟體每天都在使用。

事實42:增強功能大約占軟體維護成本的60%,錯誤更正僅占17%,因此,軟體維護的主題是在舊軟體中加入新功能,而不是更正錯誤。

事實43:維護是解決方案,而不是問題。

事實44:比較軟體發展和軟體維護中的工作,除了維護中“理解現有的產品”這項工作以外,其他工作都一樣。這項工作佔據了大約30%的維護時間,是主要的維護活動。因此可以說維護比開發更難。

事實45:更好的軟體過程開發導致更多而不是更少的維護。

事實46:品質是一組屬性的集合。

  •  可靠性是指軟體產品滿足預期要求,值得信賴。

  •  人類工程學(可用性)軟體用起來容易舒服。

  •  易理解和易維護性

  •  效率是指軟體產品在執行時間和空間消耗上的經濟性。(有些應用中應在首位)

  •  可測試性

  •  可攜性指易於在不同的平臺之間移植的軟體產品。

事實47:軟體品質不是使用者滿意,滿足需求,滿足成本和時間表,或者可靠性。

事實48:絕大多數程式師會犯某些錯誤。

       N-Version , fault-tolerant programming 容錯程式設計

事實49:錯誤通常聚集在一起。

事實50:沒有唯一的最好的消除軟體錯誤的方法。

事實51:總會有殘存的錯誤。我們的目標是消除嚴重錯誤,或是使之減少。

事實52:效率主要來自優秀的設計,不是優秀的編碼。

  極限程式設計運動宣導簡單化的設計方法和快速進入編碼階段。

  極限程式設計強調:在編碼之後通過持續地重構(refactoring)來修訂設計匯總的低效率和錯誤。

事實53:高階語言的程式碼配合適當的編譯器優化,大約可以達到組合語言的90%的效率。對於一些複雜的現代體系結構,效率更高。

事實54:在時間和空間之間存在著折中,通常改進一方面會降低另一方面。

事實55:許多軟體研究者不是調查,而是鼓吹。

謬誤1你不能管理自己無法度量的東西。

謬誤2可以管理軟體產品的質量。

謬誤3可以,也應該忘我的”編程”。

謬誤4工具和技術是通用的。

謬誤5軟體需要更多的方法論。

謬誤6:要估算成本和時間表,應首先估算程式碼行數。

謬誤7:隨機測試輸入是優化測試的好方法。

謬誤8假如有了足夠多的關注,所有的bug都顯而易見。

謬誤9:估計將來的維護成本和做出產品更新的決策需求需要參考過去的成本資料。

謬誤10:教別人程式設計的好方法是教別人寫程式。(應先閱讀)。

參考自: http://www.it610.com/article/2757007.htm

.

1.png

這是12/17號的演講主題(PPTX在這裡)

.

 

Written by ruddyllee

2016 年 10 月 18 日 at 00:34:42