David Ko的學習之旅

貝爾賓團隊角色理論 (Belbin Team Roles) 是英國 Dr. Raymond Meredith Belbin 教授所提出, 對於團隊組成和管理要怎麼做提出一些作法. 貝爾賓研究後發現, 成功團隊中成員, 通常會包含以下九種角色. 如果這九種角色齊全, 團隊就能運作良好.
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(2) 人氣()

這個週末去上了識博管理所開的: 流程設計與跨部門溝通. 之前聽人家說這門課十分有趣, 並且 JB 也鼓勵我來看看. 因此特定找了一個時間來上課. 
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

 
Developer Productivity Report 2013 - How engineering tools & practices impact software quality & delivery
http://zeroturnaround.com/rebellabs/download/?token=80eb432c1d5edfc886f91ad2169c139196a99127&utm_medium=email
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

最近在準備一份簡報時, 需要研究一下管理學的演進, 發現到泰勒和彼得杜拉克, 這兩個人對於管理的方式, 有著很不一樣的想法.
 
    

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(2) 人氣()

通常團隊中, 我們會建立一些指標, 來衡量我們做得好不好. Henrik Kniberg 在 “How do you know that your product works?” 的分享中, 提出了三種常見的方式:
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在 Scrum Gathering Shanghai 2014 中, 有一場演講的講者是 Alan Atlas, 他之前擔任過 Amazon S3 的開發經理, 那時候他用的就是 Scrum 方法來帶領團隊. 所以那天特別期待他的分享. 這次他演講的題目是: 敏捷開發中的客戶角色的演變. 他利用開發方法的演進, 來說明開發團隊和客戶的關係. 
1. 瀑布式開發
客戶? 客戶是什麼東西? 從 waterfall model 中, 你根本看不到客戶在哪. 在這個階段, 開發人員只是自己做得很爽, 只希望別人不要來打擾他, 只要時間一到奇蹟就會發生, 就會做出客戶要的東西.

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

目前公司是一個很注重教育訓練的公司, 它舉辦了不少內部訓練, 因此每個員工都有很多機會學習到不同的知識. 
在這個過程中, 遇到一件很有趣的事情. 我們一共有三個單位負責不同的教育訓練:
A 單位: 負責辦理內部讀書會的規劃
B 單位: 負責辦理語文訓練
C 單位: 負責辦理內部分享會議, 以及短期和中期的教育訓練課程.
大家都很努力把手頭上的工作給做好, 因此辦了非常多的課程, 看起來似乎各司其職, 大家都很盡責任. 
可是老闆卻有很多抱怨, 他說我們員工都跑去參加訓練, 那工作誰要來做?  

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(2) 人氣()

開始當經理後, 常常會聽到一堆企業策略, 可是不管這些策略再高明, 如果你的員工工作沒有熱忱, 不願意投入到工作中, 那一切都是空談.
此外, 現在一心多用的狀況, 已經是很常見的. 同時間會有好多東西, 吸引著你的員工, 像是 Facebook, WeChat, Line 等等訊息, 隨時會讓員工分心去處理. 
因此公司的成敗, 在於能爭取到, 員工多少熱忱的參與. 為了讓員工有興趣, 你必須要盡可能地, 打造好玩和吸引人的工作體驗, 這樣你才能打敗對手. 而這個過程就是企業遊戲化.
所以企業遊戲化, 就是要結合遊戲設計, 忠誠方案, 以及行為經濟學, 來讓大家樂於解決重要的問題, 並且提高參與的熱忱. 
在 Scrum gathering Shanghai 2014 中, 有一場分享: Reality Healing - 3 個真實遊戲化項目試驗, 就是談他如何在公司中進行遊戲化, 試圖來幫助專案能進行得更順利, 員工的士氣能夠更提升. 其中一種做法, 就是他建立出一個遊戲化的畫布, 來規劃遊戲化要如何進行. 這樣的概念歐美已經有人提了, 你可以在這裡找到 template
http://www.kioskcts.com/wp-content/uploads/2013/12/gamification_model_canvas_poster.pdf
不過, 演講者提出的比較特別, 他的畫布長的像下面這個樣子

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

David J Anderson 在 Kanban 一書中提到, 他想出一組成功的方法, 認為如果可以做到這些事情, 專案的執行應該可以成功.
 
 
1. 專注于品質
2. 減少同時進行的工作
3. 頻繁的交付
4. 根據交付速度, 來平衡需求的請求
5. 進行優先順序的排序
6. 消除變異性, 以提高可預測性
這些方法是需要照順序來實施的, 這是有原因的. 前面的項目通常都是團隊能夠控制, 或者是能控制的狀況比較多. 後面的項目, 你不太可能只有自己做好就可以, 你必須和其他人配合, 要和上下游的部門一起合作. 
改變是困難的, 尤其還要改變別人, 因此你必須要從自己先做起, 或者自己能控制的部分開始, 然後才去考量別的事情.
為什麼會提到這些事情呢? 最近在公司內要和其他團隊, 一起合作開發新的產品. 老大給的時間很短, 可是要做事情很多, 如果大家想要能將產品做得很好, 是件不容易的任務. 
根據 David J Anderson 的建議, 如果想要能有所改進, 我想可以先做的, 就是專注于品質的改進, 唯有先確保自己產品有一定的水準, 這樣後面才不會因為大量的 bug, 要不斷的重工 (rework) 去修復,  導致產品 release 時程遙遙無期. 
此外, David 也提到, 要改善品質, 不管傳統方法或者是敏捷的做法, 都是能發揮作用. 因此, 不管你用 review, inspection, unit testing, TDD, design pattern  或者是 pair programming, 重點在嚴格落實, 確實執行. 經過一段時間後, 系統品質自然會控制在一定範圍之內. 
所以在未來的二個月中, 最重要的是確保以下事情進行順利:
團隊成員需要密切討論合作, 確保大家知道相同的事情, 減少 handsoff 的狀況.
設計要及早檢視, 避免誤解需求, 或者考慮不周的設計
及早測試, 不管是利用自動化或是手動測試, 期待第一時間給與回饋
希望三個月後, 可以很高興的跟大家講, 這樣的做法, 是對專案有幫助. 一定要成功啊 …..

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

上次提到在集體討論中, 會遇到一些問題, 導致效果並沒有很好. 為了解決這些問題, 你可以嘗試這些方法
 
 
1. 7 +- 2 人的團隊
盡可能讓團隊不要太大, 這讓每個人曝光機會變大, 都需要發言或是做些事情, 否則很快就會被別人知道自己沒有貢獻.
2. 讓他們有 ownership
不要每次團隊成員就只是扮演聽命行事的人, 你可以讓他們主持 planning meeting, review meeting, 或是 retro meeting. 讓他們有機會自己決定, 或自己處理一些事情.
3. 利用便利貼討論
在使用便利貼討論時, 先讓大家寫個 5-10 鐘的意見, 然後再從非管理階層, 或是不常說話的人, 開始輪流發表. 避免聲音大的人, 或是老闆一下就控制講話的方向.
4. 利用白板討論
把討論的內容發表在白板上面, 讓大家重點集中在白板上面, 而不是對方或是另一個人上面, 也就是不要讓人們直接面對面衝突.
5. Playing poker 進行方式
不是只有少數服從多數的表决, 它讓不同意見的, 不同角色的人能發表, 並且加上遊戲的因素, 使得集體評估的過程, 變得好玩又有效.  
6. 不同形式的 retro
為了讓集體討論不會流於形式, 你需要有不同形式的執行方式, 例如 retrospective meeting 便需要很多花招, 這樣大家才不會覺得很悶
http://kojenchieh.pixnet.net/blog/post/354638144
所以我常常說 scrum master 不是只要會 scrum, 帶團康, 跳大腿舞可能樣樣都要具備, 這樣才能引導大家, 做好集體討論的活動 XDDD

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在 agile 的開發方法中, 有很多時候都是利用團隊集體合作討論, 來產生最後的結果, 或者是產生共識. 可是不要忘記人多在一起時, 可能會有以下問題
 
 
1. 混水摸魚
反正少我一人沒有差, 只要團隊成員大於 5 個以上就容易發生. 我想大家很容易觀察得出來, 誰老是不說話, 或者故意做得慢一點.
2. 逢 X 必反
我想社會上這種新聞不少, 有些人逢某種顏色就反. 同理, 有些人在團隊中, 只要是其中某個人提出來的意見, 就會加以批評, 不管他的想法是否正確.
3. 大聲就贏
有些資深, 或者是長官, 說話聲音會比較大聲一點, 因此意見就會比較受人注目. 導致其他比較小聲, 或者口才不好的人, 意見常常被忽略.
4. 表面上的祥和
中國人通常都會以何為貴, 不想跟人家大聲爭吵. 因為即使對方有錯, 或者是意見不合, 只要不是太嚴重, 都不會據理力爭. 可是這樣的情況一久, 之後爆發出來就會很嚴重.
5. 三個臭皮匠不一定勝過一個諸葛亮
你一定聽過, 明明是一群聰明人, 可是聚在一起工作, 所作出的決定卻很可笑. 這可能是不同立場的牽制, 結果被折衷的很厲害, 導致出來的方案四不像.
切記切記, 任何方法都有優缺點. 在群體決策時, 要小心這些事情發生.

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

很多人想找個好的測試人員, 問我說是否有祕訣, 能夠找到有潛力的人.
 
 
以下這幾個面向是我以前老闆強烈要求的
1. 快速學習的能力
2. 主動積極的態度
3. 創新能力
4. 如何克服低潮
如果 candidate 能在這些面向上舉證歷歷, 說明他可以處理的很好, 相信這個人已經是合適的人選.
至於技術的部分, 則是下一個階段要問的問題. 因為前面的部分不行, 技術再好, 我都會有 concern. 所謂江山易改, 本性難移. 心態這東西, 不是短時間可以改善的.
此外, QA 是否要會 coding, 這個問題也是很多人會問. 在台灣這樣的結構下, 大多數會寫程式的人, 是不太會想做 QA 的工作. 但是我還是期待找到會寫程式的人, 至少 scripting language 是沒有問題的. 因為在做 performance testing, 或是某些重複性質的工作, 以及在 reproduce 某些bug時, 能夠產生一些小工具, 將會幫助很多.
如果真的不會寫扣, 這時候我就會很注重創造力. 這時候最好的方式, 就是當場出考題來互相切磋一下. 標準答案不是重點, 我在乎的是他的思考邏輯, 如果他的想法很有創意, 也能很清楚地解釋他的思維, 那他就是很棒的人選. QA 就是要有自己想法, 不要被開發人員牽著走. 並且也要擅長溝通, 讓開發人員願意買單修改問題.
此外, 我會看看 candidate 是否參加過一些社團, 或者熱愛某些運動, 我想這也能加分不少, 因為這代表他們對生活有熱情, 願意和人一起合作, 這是測試人員很需要的特質. 大多數我的優秀團隊成員也是如此, 因此這也我觀察的重點.
最後, 我的團隊裡最不需要的是英雄或是天才, 我認為我很平庸, 我喜歡和願意互相幫忙的人一起工作. 所以我不會找 super hero…. 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()