Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 五月 2015

將 To Do List 轉換成 Personal Kanban

leave a comment »

這一段影片是用來補充書本裏頭 第五章 個人看板 所缺少的動態資料演示。

(書: 精實開發與看板方法)

000 PB_demo

《 將 To Do List 轉換成  Personal Kanban 》的影片。

展示環境 

  • 採用 Windows 10 的 Windows Edge 瀏覽器,呼叫純 Web Application 的免費軟體  www.Kanbanflow.com 作展示。

  • 影片放在 Youtube 上頭。

.

內容說明 】

一個針對傳統的 To Do List 如何轉換成「個人看板」的簡單展示。

首先;對 To Do List的工作進行分類(加入顏色區分),接著進行排序,然後設定今日工作的範圍,然後是;開始一步一步展開成個人看板的基本步驟說明,歡迎大家參考。

.

To Do List 缺少了什麼?

以條列式的表格方式來顯示資料,好處是可以顯示很多資料,但缺點是沒有重點、無法聚焦。也就是找不到重點的意思。所以我們用新增一個「今日工作」的欄位來造成聚焦的效果。同時它讓我們可以更清楚各種工作在我們生活中的比重。這種顯示出生活重心的做法相當有意義。

例如: 在專案開始之初;我們必須要在對專案的專注上多投入一些關懷,所以在一天的規劃裡便可以刻意的多投入一些工時在處理公司的工作上,這種做法讓我們避免因為習慣而忽略了真正的重點。(影片裡我將日常生活已 3:7 的比例,習慣性的將公司的工作以不到一半的比例來執行工作,但在專案之初,我會建議你多選擇幾個工作,以 5:7 或更高的比例來渡過專案一開始的不穩定期,會比較明智些。)

.

「今日工作」欄位

這個欄位就好比預備欄位。他表現出來的是我們對一天的安排,也就是我們對一天的計畫,影片中我拉入了7個工作項目,保留了三個額度,這三個刻意保留的項目是用來處理突發的干擾所做的保留。這一點在生活裡是最常見的事情了,例如臨時的會議或是較長的電話討論、Email撰寫…等等事件都會吃去我們不少工作時間,因此做了保留。

它顯示了我們對一個工作天的期待,其實也就是規劃了今天我想要達成什麼樣的目標! 是我們回應生活、工作的一種事前計畫。通常我們會在前一個晚上擬定好這個計畫或是上床睡覺之前做好計畫,以便第二天可以順利進行。一般而言就是我們預期了一天最高的產能。同時它使我能夠清楚的看到即將開始的一天裡我想做些甚麼?跟即將會以什麼樣的方式來度過這一天。老實說;干擾總是以我們計畫之外的姿態到來。所以到了晚上,也就是一天要過完時的回顧便可以拿來細細回味了。它可以讓我們看見自己的生活,然後便於改善的生活方式,是很值得用心的地方。

.

更接近真實世界的「等待欄位」

提升效能是我們控制流程的最大目的。而半成品WIP則是效能的最大傷害。在團隊進行開發工作時,不斷的進行消耗工時成本的溝通的目的,就是要促使團隊在協作時進行得更順暢,擁有更少的彼此等待的時間浪費。但是,在我實行個人看板時卻驚訝的發現,在生活上竟然處處都是你等我,我等你的事情,這種事由網路訂貨一直到衣物送洗等等,都無時無刻不在發生等待的事件。因此適當的在個人看板上加入「等待欄位」是絕對必要的。雖然你加了這個欄位,但實質上還是要等待,唯一不同的是你可以自行來設限正常的等待時間了,對那些不能控制的事情,進行設定規則性的限制,這是拿來做改善的 一種依據,讓自己有所遵循又有機會改正過來的依據,相當值得嘗試。

 .

展示內容由於時間的關係,說明的快了些,也跳過一些我上課時的細部說明。但這畢竟是個人看板,怎麼發揮就完全見仁見智了,好壞不在一時之間,只要記得《持續改善》就可以了。

(再囉嗦一下,Jim Benson 的個人看板所指的是包含且適用在小的軟體開發團隊在內的軟體看板)。

廣告

Written by ruddyllee

2015 年 05 月 29 日 at 09:06:02

個人看板的展示 — 白河事件

leave a comment »

應邀前往台南白河.關子嶺演講。3個小時. 講個人看板,目的在提升個人的效能。已經有60幾張slides了,但針對「如何提升個人效能」的部分實在是越想越難表達。想要試著列下要Demo的步驟,再來思考一下,或許可以更有感覺些。

展示的步驟:

  1. 運用 Kanban flow,顯示最基本的 To-Do list, 然後加入一堆待辦的工作事項。(讓它看起來有些亂)

  2. 首先;為這些工作事項加上一點顏色,區分出: Job、Coding、Health、Urgent。讓人瞬間看到自己的一天人生就是這麼過的。

  3. 在待辦事項後面,加入【今日工作】 的欄位。把今天想要完成的工作依百分比多寡, 放進今日工作的欄位裡。聚焦: 這個動作讓視覺變得清晰的多了,我們可以清楚的看到今天就是做這些事囉?!(才怪,干擾通常都是不請自來的…)。

  4. 加入【進行中】及【完成】二個欄位。這個動作讓To-Do List 變成了看板。

  5. 開始工作: 便是啟動拉動系統,拉入工作, 一次拉進來一個工作。雖然人是多工的動物,但 programmer 能做的是 “同時肩負多項任務,但一次只能進行一項工作”。

  6. 為流程加入現實中最常出現的【等待】欄位,讓流程更符合真實世界。

  7. 該是回過頭來審視《待辦事項》的時候了 – 這是我們一般所謂的梳理待辦事項也就是需求調適,對個人而言,便是決定生活方向的時候。

   弄不好,生活會變得太太辛苦,

(加加減減待辦工作是再所難免的)。

.

  1. 加半成品WIP 限額 – 思考什麼是真正的完成 Done.

    (人的生活事件不能跟生產線相比較,沒有完成定義 Done 的事情實在太多了)

  2. 搭捷運、有空閒滑手機的時候,記得回顧完成了些什麼,作得好嗎?收穫是什麼? 學到了什麼?

  3.  站在看板前的基本步驟: 更新 – 解讀 – 提問 – 調整。

 .

0001

開始時的樣子

(Demo影片已放置在 youtube上了)

這是統茂飯店…(拍幾張照片留念)

IMG_20150523_113415 IMG_20150523_114217

Written by ruddyllee

2015 年 05 月 23 日 at 10:25:32

張貼於未分類

消除浪費: 精實開發的首要原則

leave a comment »

話說;大家都知道要消除浪費,很顯然浪費是任何企業都應該避免的行為,但不同的企業跟企業之間就有著完全不同的想法和作法。企業在獲利時跟賠錢的時候(面臨危機的時候)也會有著完全不一樣的思維。是什麼影響他們的思維呢?

是對消除浪費的「認識 與 感知」決定了企業執行的績效。

一個好例子,就是豐田生產。豐田企業的成功意味著他對消除浪費的成就是值得去研究與學習的。但我們都知道,必須把自身的環境加以考慮進去,這種仿效才可能會有效果。這裡,讓我們先由定義來看何謂浪費。(我不小心把個人與企業的消除浪費混著談,有一點是是而非,請多包涵…)
.

浪費是指不能為我們增加價值的任何事物

例如: 某件事它看起來總是可有可無,做了以後,卻完全不知道成果,它便是一種浪費。或是一堆閒置的事情,因為有事務被插斷了進來,它就被放在一旁了,便成做了一半的事,這也是一種浪費。或是工程師製作了一堆沒人會去看的文件,這絕對是一種浪費。因此,我們需要先由識別浪費開始。從目前自己的行為去分析,先嘗試定義何謂浪費? 這一點;對生產線的工作而言,好像容易的多。但對人類的生活行為而言,恐怕就較難作判斷了,因為每個人對事物的價值觀可能都有所不同,因此對浪費的判定可能也都有所不同。真正能做評斷的,可能還是自己了。相較之下,團隊的協作工作就比較容易由工作流程的產出效能上來做出是否是浪費的判斷。因此我覺得,我們可以綜合工作的產能及自己的價值觀來作個人行為是否是浪費的判斷。哈哈! 就這一點而言;真是太抽象了,說了又好像沒說ㄧ樣。沒關係! 實施的時候,請按部就班去做,常常依靠回顧來衡量成果便可以了。

.

用明辨篤行去實行它

看見浪費便能開始消除浪費,至於成果如何? 依靠回顧,運用持續改善來修正它。

基本上;開始去做才是重點,只有身體力行才是消除浪費的開始。所謂的「看見浪費」可以比喻為「明辨」,而實作則可謂之為「篤行」。我們先透過分析的行為來看見自己現在在工作上的浪費,然後再依靠獲取最高產能與自己價值觀的取捨來修正工作上的行為,藉此以獲得可以消除浪費的行為,並持之以恆的進行改善讓自己能夠生活的更好更有效率。

(看一下,看板原理:談麥當勞Drive-Through點餐,這一篇說明你會明瞭產能是怎麼一回事)

.

上課送書這回事
送書! 這是我講課時最大的浪費,但我的價值觀卻不這麼認為。 很多人嘰笑我,這是又浪費又得不到任何效果的行為。但是我不這麼認為,我可是非常慎重的去看待這種行為的。話說;醫生可以靠他的醫術懸壺濟世,而我是講師,我能作的就是散播知識了,書本是我借助那些智者的智慧結晶拿來當禮物的獻禮,我的課程時間短暫,你可能聽不到什麼太具體而立即可以實踐的東西,所以只能祈求你在短暫的時間裡能有一些個領悟,那怕就是一丁點,就該感謝上蒼了。「送書」則是希望收者能夠再多有一些些機會去接觸這方面的知識,或許在不久的未來能有所幫助也說不一定,(所以我不喜歡用問問題的方式來送書,而是喜歡用機緣)這也算造七級浮屠吧!這一點完全是自己把寫程式或講課教書這檔事視成是濟世救人的行業,所以價值觀引導我說這不是浪費,它的加值遠勝於金錢,所以就更篤定去實行它了。

 .

視覺化你的浪費: 如果是工作上的產能,用工作流程來分析,再把時間填上去,就可以看見浪費了。(下圖中的黃色區塊是增值的部分,其餘沒有顏色的數字則是減值的部分,也就是浪費的部分。當我們把流程畫出來的時候,便很容易看出哪些地方是最大的浪費了)

Bug report

.

生活的意義: 如果是生活、生命活著的意義的話。老實說;我們經常會有某一個百分比是為別人而活的,這一點再正常不過了,大家都是如此,無可厚非,彼此彼此! 這一點可能是 “個人看板" 最能夠提醒你的事,如果你老實的紀錄了自己的工作內容,只要多看幾回,就會發覺你做太多別人要你做的事,而做太少自己想做的事了,所以勇敢地放下手邊的工作,真正做自己吧。 其次;便是去做你所喜歡的事,也就是為興趣而工作,當然沒那麼容易,但努力的把興趣的比率加重一些,你會覺得活得更快樂些。但先決條件是要先培養出願意去持之以恆的興趣。

 .

興趣能為我們做什麼?

人;因為愛好運動,能夠持之以恆,不以為辛苦。健康則是伴隨而來的獎勵。

人;因為努力追求成功,能夠克服萬難而達成目標。財富則是伴隨而來的獎勵。

.

Written by ruddyllee

2015 年 05 月 12 日 at 12:28:33

張貼於未分類

TDD 與 Unit test 練習 — 從簡單開始

leave a comment »

很久沒有被問到測試的問題了,工程師滿臉的疑惑,看起來可能是剛剛才看了一堆談測試的書籍,還沒能抓到真正的精神。請不要著急! 理論固然重要,但請從實務做開始,而且要做得越簡單就越好…。在開始之前,請先自問一下:

你的程式加Log了嗎?沒有程式可以沒有LOG的,請從務實著手。

.

難的東西看起來總是比較有學問,所以要養成先看問題再找解答(尤其是使用設計模式)

坊間談單元測試的書都講得太多了些,立意良好,但害人不淺。測試程式是配角(XD),可有可無?! 全在你一念之間。太繁雜的步驟不如不要(以後實力變強了,再來試試)。一定要力求簡單、再簡單,如果簡單不下來,則不如不做。(假設你連主程式都沒有力氣寫好,測試對你的負擔就更大了 ??? 還不如先把需求弄清楚,真正弄懂了需求,自然能評估自己或團隊有沒有能力做出來了!)

.

實作看看: 先來一個夠簡單的TDD含單元測試

Test Driven Development 測試開發練習:

步驟一、啟動 IDE 編輯器,選擇 Winform Application,

            命名: WindowsForms_TDDUnittest。

步驟二、新增一單元測試專案,命名: UnitTestProject_TDDunittest。

步驟三、完成起手勢(在第一個TestMethod內寫入 3A註解)。

        [TestMethod]

      public void TestMethod1()

        {            

             // Arrange

            // ACT

            // Assert       

        }

            (請務必參考: 3A Pattern 發明人 Bill Wake 網站 ,他會跟你講變化何在?)

步驟四、開始撰寫程式功能,命名 ParseAndSum( string inputData)

error_1

紅燈代表錯誤,綠燈表示pass.

吃到錯誤訊息! (如上圖所顯示的紅色波浪線)。

步驟五、到主程式加入此功能程式 Public  Int ParseAndSum( String Number)

    這是新增功能的起手勢(依個人喜好而定,下面的預設result值是我的個人習慣)

 public int ParseAndSum(string number)

        {

            int result = -1;   

.

             // — 程式碼 –//

.

            return result;

        }

步驟六、執行一次此單元測試,應該得到以下錯誤訊息:

error_2

亮紅燈是正常的開始

.

註: 有時候如果你在預設值與測試資料值設成相同的時候,就會很驚訝竟然過了! XD

步驟七、為此程式功能加入程式碼:

error_3

參考: 單元測試的藝術中的一個簡單範例

.

執行一次此單元測試,看結果。

OK_1
綠燈表示通過測試

.

結果是OK(綠燈),表示單元測試測得該功能能夠正確執行預設的 IO輸入值。

如果還吃Error(紅燈),表示單元測試測未通過,繼續主程式端的程式修改作業一直到它能夠通過此測試。

.

【結論】

此時的 TestMethod1 就是我們的單元測試程式碼,在進行重構主程式之前,務必重新命名此測試程式,讓他能夠一眼就看出來是哪一塊主程式的測試程式。(例如: Unittest_ParseAndSum)

這個時候你應該對剛剛的程式碼產生足夠的信心了,可以繼續做下一個功能了. 如果信心不夠的話,就去執行一次主程式好了。一般的測試開發過程,我們不會一直去執行主程式的,尤其不會跑去執行從頭到尾都沒有修改過的那些程式區塊,這就是單元測試的好處,總是以手頭上的程式邏輯為主,這樣的習慣可以適當的增強小區塊程式的邏輯完整性,也就是避免掉了不應該要有的Bug,程式會自然的變得更堅強。

.

再來強調一下,單元測試才是重點,TDD只是一種寫程式的習慣,我不會整支程式都這麼開發的,通常在邏輯越是模糊的時候,越需要邊走邊弄清楚原委的時候,我就會想紮紮實實的做好該做的基礎,這時候正是TDD最可以幫上忙得時候了。

.

( 91 在網路上有一系列的相關說明: [30天快速上手TDD] 可以作為參考)

Written by ruddyllee

2015 年 05 月 07 日 at 23:09:17

張貼於未分類