Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 十月 2016

消化需求,拯救這個世界

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

個人如何敏捷化?

leave a comment »

.

mail_2.png

想要敏捷化,就從寄Email給自己開始,運用自己給自己的回饋,來達成個人的敏捷化。

.

起因: 上Scrum課程時,經常被問到Scrum 需要3種角色,又一個最佳的Scrum團隊大小是由7加減2個人所組成,那一個人開發的時候怎麼辦?一個人要如何敏捷化呢?

.

(國外有一個推廣 Personal Scrum 的網站 ,但這裡要談的不是它所謂的個人Scrum,我想陳述的是自己使用敏捷的方式,供大家做參考。)

寫信給自己然後再回信給自己,就這樣一直下去一直到問題的解答慢慢浮出水面來(當然是我們自己透過不斷的搜尋、閱讀及思考所換來的結果。就是上面圖示裡的下半部份),我不是在開玩笑,雖然聽起來有一點儍,但這是我讓自己敏捷起來的方法,已經行之有年了,歡迎你來試試看,很有效的。

.

給自己回饋

敏捷開發的核心概念,就是運用小的循環迅速獲取客戶的回饋。如果敏捷開發少了回饋,需求就無從修正起,也就相對的敏捷不起來了。因此;一個人作敏捷開發時就用Email來給自己回饋,給自己針對同一件事情同一個結果,運用不同的時空做區隔,讓自己有機會較客觀的重新審視它,然後重新思考它的來龍去脈,重新再給自己一個回饋一個再一次尋求解答的機會(但身為工程師,最好能在完成一個功能之後,就請坐在一旁的同事給予comment迅速的取得回饋,這是最廉價又有效的回饋了,它要比幾天之後你都忘的差不多的時候,才得到客戶的回饋要好多了)。

 

Email 就是有這個好處,它按時間來流動。前一刻所接觸到的人、地、事、物,就在下一刻來重新檢視一遍,思維就會變得不一樣了,精實開發裡稱它為「盡量延遲決策」的法則。目的是做更深層的思考,讓決策擁有更多可以參考的訊息,更能夠客觀的加以評論。

.

「搜尋」然後Email給自己

搜尋資料的時候,把瀏覽到、認為有參考價值的資料寄給自己,即使它不是這一刻進行搜尋這個動作的目標,但只要覺得未來有可能會用的上的東西,就把它拷貝下來寄給自己吧! 讓未來的自己能夠有機會重新審視這個資料。至於到底對自己是有價值還是沒有參考的意義,讓下一刻客觀一點的自己來做決定吧,不要讓似曾相識成為了擦身而過的遺憾。

 

把「心事」Email給自己

把心裡所想的事情,寫下來寄給自己。或許是開會時沒有說出口的問題或是上課時的疑惑,讓Email幫你記憶下來供下一刻的你,在沒有時間緊迫性的時候能夠靜靜的重新進行回憶。

這時候我經常會展開一個人的對話。就是在信裡頭回覆上一封信所提及的問題,這是一種讓自己能夠高效的學習方式。讓學習過或是思考過的自己,把問題重新再做一次文字式的說明,看看現在的自己是否能把問題說得清楚,如果不行的話,那這封信就可以有繼續持續的回覆下去的機會了,一直到解題的答案能讓自己覺得滿意為止。(這是參考費曼先生的快速學習法的心得,因此寄Email給自己,然後在反覆去回答也是一種有效的學習方式,註1)

.

mail_2.png

遇問題找人交談是一種快速、低成本回饋的好方法

.

小結

說明一下上面那張圖示。標題是「運用寄信給自己,再回覆來信給自己的方式」循環的紀錄下去,一直到問題得到讓自己滿意的解答。當然解答的人還是自己,但這是一種回饋,一種自己給上一刻的自己的一種回答方式(時間上或許是當下,但大部分時間是隔天或是幾天之後)。我用這種方式來讓自己能夠敏捷起來 –換句話說: 需求;也就是上一封信的問題,可能在這一封信抵達之前我的心意或是了解的程度又改變了,因此就運用Email給自己的方式來產生重新審視它的機會。讓新的答案能夠更加滿足自己,也就是真正的客戶。

 

我習慣把搜尋的結果、正在思考的問題或是閱讀的時候所看到的佳句或是自己鬼畫符的草圖在當下就寄給自己。目的;除了把它做成紀錄之外,最重要的是模擬敏捷循環時的客戶回饋,讓自己給自己回饋。然後運用最上面的二個方法,就是左側的與人交談,或是右側的看板方法來過濾它。因為這是自己對自己的一種文字/圖形或照片的對話方式,如果可以再進一步透過與人交談的形式,也就;又可以進一步的得到回饋演進的機會了。否則就做一下最終記錄: 選擇看板牆或是寫到個人的部落格裡的方式。也算是對自己有一種交代了(資料庫的部份,由於我採用的是Gmail系統,因此有許多外掛可供使用,就不在多談了。但把會議或討論後白板上的照片寄給自己倒是最常用到的方式)。

 

習慣單打獨鬥的工程師,記得寄信給自己,讓自己能夠敏捷起來。

 

.

範例: 我喜歡在捷運上思考問題,因為在車廂這種封閉式的空間裡非常適合邏輯思考的飛馳。下圖是由世貿會場搭捷運紅線到石牌站的路上,思考「一個人如何敏捷」及如何架構這篇短文,我持續反覆寄信給自己跟自己交談的演進內容,這段時間裡我找到了Mike cohn的個人使用Scrum在生活上的運用,還有一個個人運用Scrum的好範例「安排婚禮」,可是我都沒有採用它們,雖然它們也都是不錯的運用方式,繞了一大圈的搜尋、篩選但最終還是講了自己的習慣。請参考:

mail_3.png搭捷運是最適合獨立思考的時機(從iPad傳送)

.

註1. 費曼先生的快速學習法 ,四個步驟如下:

第一步 – 選擇一個你想要理解的概念

第二步 – 設想一種場景,你正要向別人傳授這個概念

第三步 – 如果你感覺卡卡的, 就回顧一下學習資料

第四步 – 為了讓你的講解通俗易懂,簡化語言表達

.

 

Written by ruddyllee

2016 年 10 月 12 日 at 17:35:59

張貼於未分類

Tagged with ,

工程師進階之道 – 畫草圖

with 3 comments

.

1.png

.

2.png

.

3

.

5.png

.

4

.

6

.

7.png

.

 

 

 

Written by ruddyllee

2016 年 10 月 03 日 at 12:38:08

Sprint 計畫會議

leave a comment »

.

0_1.png

.

all

.

p0

.

p1

.

p2

.

2.png

.

3.png

.

4.png

.

5.png

.

 

Written by ruddyllee

2016 年 10 月 02 日 at 21:58:29