前一陣子, 討論到員工不應該同時處理太多事情, 因為多工代表 interrupt 太多, context switch 會導致太多浪費, 會讓工作效率降低.
我想這件事情大家基本上是同意的. 老闆不能同時叫員工處理很多事情, 然後又希望他又快又好.
- 4月 06 週一 201519:27
敏捷是為了解決什麼問題而產生的?
前一陣子, 討論到員工不應該同時處理太多事情, 因為多工代表 interrupt 太多, context switch 會導致太多浪費, 會讓工作效率降低.
我想這件事情大家基本上是同意的. 老闆不能同時叫員工處理很多事情, 然後又希望他又快又好.
- 3月 23 週一 201521:11
Scrum Master 常見的工作
這位作者列出了 Scrum master 該做的工作, 大家可以參考一下, 那些是你認同的, 或者哪些是你做到的:
- 3月 15 週日 201518:44
以大雁氣功培養團隊成員
什麼是大雁氣功呢? 老實說我不知道, 我要學習的, 是雁子團隊飛行的精神.
- 2月 08 週日 201520:33
Scrum 團隊成功的三個要素
有人提到打造 Scrum 團隊, 有哪些事情要注意的. 因為他發現到, process 再有用, 也需要有對的人來實施才能發揮其效果.
他真的內行人, 人的問題永遠是最重要的. 搞定人, 問題就解決一半了.
- 1月 27 週二 201506:50
如何建立優秀的團隊 - 男女比例
在 IT 領域, 很多時候是都以男性為主, 很少看到有女性的出現, 因此在團隊男女比例是嚴重的失調. 那男女比例對於建立高效的團隊是否有關係呢? 我想這個問題還蠻有趣的.
目前在網路上有找到一個研究, 是在探討性別比例, 對技術團隊效能的影響:
WHAT IS THE IMPACT OF GENDER DIVERSITY ON TECHNOLOGY BUSINESS PERFORMANCE?
- 12月 30 週二 201423:19
你們是哪一種層次的團隊?
最近敏捷流行在探討如何建立好的工程師文化, 談到這個, 就不得不提到組織的結構(structure), 如果沒有好的組織相輔助, 敏捷轉型將會是非常困難的事情.
在 infoQ 有篇文章, 談到 self-organizing teams 的文章, 他提出了一些觀點, 值得大家參考一下.
- 10月 12 週日 201419:27
改變組織結構才能改變文化
在實施 agile /scrum 時, 大家都知道要有敏捷的文化很重要, 否則推行起來會事倍功半. 那要如何解決文化的問題? 這真的是一個很難的主題.
為什麼呢? 大多數敏捷的顧問或是專家, 雖然精通敏捷的各項技能, 但是對於處理文化的問題, 或者是人與人之間的互動, 還是無法琢磨太多. 一方面是清官難斷家務事, 另一方面他們也可能不是引導師或是變革管理的專家, 所以很少人, 或是很少文章談論這方面的主題.
最近在在網路上閒逛時, 發現到一個好玩的東西, 暢銷書 - Practices for Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Product Development with Large-Scale Scrum 的作者Craig Larman 有提到一個定律: Laws of Organizational Behaviors
1. Organization are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structure
2. As a corollary (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo
3. As a corollary (1), any change initiative will be derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which deflects from addressing weakness and manager/specialist status quo.
4. Culture follows structure
http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
這一大段單字很多, 並不好翻, 我也不想翻, 避免限制了大家的想像. 但是可以用一句比較白話, 比較流行的句子來說明: "國民黨不倒 台灣不會好” (我只是比喻, 不要來跟我來政治筆戰)
也就是組織結構不改, 你就無法改變組織文化.
結構的問題, 真的嚴重影響工作的效率. 例如,
(1) 你組織如果是專業分工分明, 開發人員只做開發, 測試同學只做測試. 所以交棒的文件沒有就做不下去, 或者各自對同一份文件有不同解釋
(2) Feature team v.s. component team: 這裡要講很長的故事, 有興趣的可以去看這裡. 簡單的說, 元件團隊帶來低效率的軟體開發行為
http://www.featureteamprimer.org/
(3) 前端開發人員 v.s. 後端開發人員: 只有前端同學才能寫 UI, 後端的就不行. 所以每次專案進行, 就看到那少數的前端忙的要死, 但是後端的沒事做.
所以根據 Larman 的定律, 你可以有兩種做法
1. 改變組織結構
你需要對組織的結構做些改變, 這是硬碰硬的做法, 必須要很多東西配合才容易成功.
在我們公司, 大多數的測試人員是不寫測試自動化的, 而是由專職的 test developer 來寫. 因此在我花了不少時間, 招募到大多數的測試人員會寫程式, 因此才開始談所有測試人員都要寫自動化. 即使等到大家都寫之後, 也要到第二個專案後, 整個自動化的結果才讓大家很激賞.
現在我開始挑戰所有人員都要寫自動化, 包含開發人員, 期待也能有好的結果. 不過前提是我是所有人的老闆, 哈哈...
2. 利用一些工具讓大家知道目前組織的困境
像是利用 Kanban 這個方法, 從現有的組織結構開始, 利用視覺化和 WIP, 讓大家知道目前的困境發生在哪, 然後才來試著推動組織結構的變動.
這樣的做法是比較溫和的方式, 但重點是看到有問題後, 一定記得要處理. 很多團隊雖然知道有問題, 可是常常就沒下文了, 這樣就誰有救不了你了.
記住, 唯有組織結構改變了, 你的 agile 才有大效用, 否則沒多久就會被打回原形的. 切記!! 切記!!
- 10月 05 週日 201411:17
打造真正的團隊 - 破冰篇
在 Agile 中很強調一點, 我們要建立一個自組織的團隊, 這件事情對於想要成功地推廣 Scrum 的人, 一定要念茲在茲地牢記.
小弟最近被指派帶一個新的團隊, 這個團隊的成員是來自兩個不同小組所組成, 因此雙方並不是那麼熟悉, 這樣對日後工作的順暢度可能會有影響, 所以特地安排了一個 team building, 期待能讓大家能更彼此更加熟悉.
首先, 為了讓大家不會這個尷尬, 我一開始帶了一個小的遊戲, 讓大家圍在一起, 玩一個小的互動遊戲. 這裡你可以參考任何團康活動, 只要進行個 5-10 分鐘, 讓大家先放鬆心情即可.
接下來, 我們進入今天的主題活動. 第一關是認識自己. 認識自己??? 沒錯, 不要認為這件事情很簡單, 其實在大部份的狀況下, 大家對於自己並不見得很了解. 所以更不用說要去了解其他人了.
我讓大家做以下幾件事情 (1) 畫自畫像 (2) 寫出自己 5 個優點, (3) 和 5 個不同的人分享自己的優點. 大家可能會以為最難的是自畫像, 因為工程師們都宅宅, 會畫不出來. 其實最難的是寫自己的優點.
