工程師多任務單工的作業方式

.

「解決多工作業的多任務單工作業 Multi-mission but Single Task

– Multitasking is evil

.

Coding! 基本上進行的方式就一定是一個人一個鍵盤的形式,當然或許你同時使用多個畫面,但基本上在做邏輯思考時,一定是一次思考一件事情,程式寫這麼多年來還沒有看過能夠用二隻手同時間寫二支以上程式的人。這是寫程式的天性,一次寫一支程式的進行方式。因此單工作業是不可避免的,跟我們平常一邊走路一邊嚼著口香糖是絕然不同的事。如果你同時間進行多個程式撰寫的工作的話,可以預期的是,工時一定會更長,Bug也會變得更多(請參考下面圖示)。這種弊多於利的作業方式;你還要繼續嘗試嗎?

 

有趣的是,老闆們就是一直把工作丟下來,這一點;造成了幾乎所的工程師都兼具多個任務在身上,很少有工程師能夠一次只作一件工作的(那是一種福氣!)。因此多工作業便成了常態性的現象。而許多工程師會在上一個工作尚未完成時就放下來跑去作別的工作。當然;有時是在工作上遇到障礙或落入苦思無解的情境,就藉著轉換工作的形式來讓思維能多出一些空間來,試著讓自己進入解題的狀況。因此就多工了,這種多工 Multi-tasking的現象,實質上正是殘害邏輯完整性跟程式品質不佳的元凶。下面這一張圖,顯示同時做三件事,跟順序的完成這三件事的時間差異。

.

多工_task3

醒醒吧! 多工只會多增加switching task所花的時間

.

用看板來可視化多工

多工的行為牽扯到的不只是工時上的問題,還有團隊工作分配是否合理的問題,除了能讓團隊更勞累之外同時也會帶動員工的情緒起伏。多工;不管從哪一方面來看對公司或團隊都是一種傷害,但事情一直來,就是那麼多工作要完成,而且它們總是會挑相同的時間一起來,那工程師該如何處理這種情形呢? 這裡運用「多任務單工看板」來處理它,請參考。

.

多工多任務單工作業看板

.

多任務單工作業看板

Multi-mission but Single Task

這是一種以人員為主的看板,上圖中第二個欄位【負責人】就是以工作負責人的姓名為主的欄位,在他左邊陳列的是它所背負的任務,分別依它們的重要性由右至左來排列在【TO Do】欄位裡。接下來是第三個欄位【分析】;這裡可能有工作的細分或進一步的拆解、估算。然後是【執行】、【測試】及【完成】欄位。看板的下方則是緊急渠道。目前正在負責完成工作的人是 Allan。他之前正在做A3的工作,但遇到緊急事件,就先暫停下來,做好了紅色倒三角的標誌之後就下來解決急件了。

它完全符合看板的基本原則,也就是單工的拉動系統作業。工程師在同一時間內只能做一件事。而【TO Do】欄位裡排列的是他所被要求要完成的任務。

.

看板是敏捷迭代開發的縮影

        看板方法沒有任何固定的會議或是角色的定義,它針對的就是流動在欄位之間的工作項目。至於這個工作;可能是一個任務或是一個較大的使用者故事所描述的需求,或單純就是一個工作項目(Task),當然也可能是一個缺陷(Bug)。這一點要看你的工作性質來做定義。上圖中的【TO Do】欄位就像是敏捷開發中按重要性所排列的需求 Queue.而全部的 【TO Do】欄位內的總合就像是敏捷開發在迭代循環中所必須完成的全部工作項目(Sprint backlog item)。它就是整個迭代開發流程的縮影,這正是讓看板十分適合拿來取代Scrum工作板的主要原因。而看板的單工作業原則,就更適合工程團隊拿來解決一般工程師被要求多工作業的問題,拿來設計成看板就成了「多任務單工的作業」的看板了。讓可視化的現象,提供主管看見每位工程師的負荷,讓進度據實的呈現出來,讓相關人員可以容易進行協調工作。它也正常展現了精實開發的基本精神 – 單工作業。

.

工程師千萬別要因爲你被同時指派多個工作就忙著進行多工的開發作業,請務必繼續單工開發的作業模式,但必須讓你的工作透明化,如此其他人才好配合。

.

.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s