目前日期文章:201501 (14)

瀏覽方式: 標題列表 簡短摘要
 
Developer Productivity Report 2013 - How engineering tools & practices impact software quality & delivery
 
在這份文獻中, 針對了很多基礎的practice 做了些調查, 其中有關於程式碼檢視 (Code Review) 這個實務的調查, 是一個有趣的結果. 很少人想要實施, 可是一旦實施效果卻很顯著.
 

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

 
Steal Like An Artist: 10 things nobody told you about being creative 第二章摘要
 
steal-like-an-artist   

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

Daniel 在上課時, 提到了一個想法: 就是要不要臉的偷東西. 也就是盡其所能的學習. 
 
頭先, 我以為這是 Daniel 自己的想法, 後來看到這本書: Steal Like An Artist: 10 things nobody told you about being creative, 才知道 Daniel 的這個想法, 以前就有了, 他只是發揮了書中的精神: 偷了書中的好點子. XDD
 
3d-Steal-Like-an-Artist-NYT  
 

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

在 IT 領域, 很多時候是都以男性為主, 很少看到有女性的出現, 因此在團隊男女比例是嚴重的失調. 那男女比例對於建立高效的團隊是否有關係呢? 我想這個問題還蠻有趣的.
 
目前在網路上有找到一個研究, 是在探討性別比例, 對技術團隊效能的影響:
WHAT IS THE IMPACT OF GENDER DIVERSITY ON TECHNOLOGY BUSINESS PERFORMANCE?

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

在我們利用 user story mapping 去組織需求時, 我們會採取 walking skeleton 的想法, 去製作一個最小可行的版本. 在之前的文章中有介紹過這樣的概念.
 
什麼是 walking skeleton ?
 
 

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

常常有人說 Scrum 中的 Product owner, 除了管理需求外, 似乎沒有做什麼事情. 或者說他和傳統專案經理做的事情差不多.
 
ProductOwnerRole  
 
真的是這樣嗎? 或許做的事情有些接近, 但是在所使用的工具是有所不同的, 以下是我整理出的一些差異:
 

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

大家在進行 retrospective 會議時, 常聽到只有一種方法, 因此時間一久了, 大家就會很煩悶, 又是來同一套, 因此換些做法, 對 scrum 團隊來說是必要的.
 
不過, 不管換哪些方法, 大部份的做法都是集中在解決我們遭遇的問題, 或者是改進我們目前的做法. 但是, 卻沒聽到有人說要凝聚團隊的向心力. 需知道, 如果大家沒心, 那些解決方案或是改進計畫, 執行起來都是事倍功半啊.
 
在 Team barometer 一文中, 作者提出了一種調查的方法, 讓我們可以知道目前團隊凝聚的狀態, 然後再搭配一些引導的方式, 讓大家來檢討和改善團隊向心力.
 

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

軟體開發的過程, 分成產品探索和產品交付兩個階段:
 
產品探索: 決定要做什麼東西
產品交付: 決定如何做出東西
 
一般來說, scrum, XP 等方法, 是在處理產品交付的問題. 可是對於產品探索方面, 並沒有太多著墨

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

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

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

最近很多人在討論, 是否同時只做一件事情, 會比同時做很多事情有效率. 根據 Littles Law 的公式來看, 似乎是這樣的, 但是理論上對的東西, 是否在實務上也是這樣呢?
 
o-MULTI-TASK-facebook  
 
Littles Law: 平均處理時間 = 平均同時處理項目的個數 / 平均產能
(註: 若要有較短的平均時間, 由公式來看, 平均同時處理項目的個數需要比較小)

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

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

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

在團體討論時, 團隊成員的參與度不一, 為了改善這種狀況, 將團隊成員的想法寫在海報紙上, 是一種可行的方式.
 
為什麼這樣的方法可行呢?
1. 認同感
當你的想法被寫下來時, 會傳達出"這是個有價值的想法”, 因此你會感到受到重視.
2. 增強記憶 

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

在推行 Scrum 和 教導課程時, 發現到大多數成員不是沈默是金, 要不是就是沒幾句就吵起來了, 因此常使得一個會開下, 仍然還是維持現狀, 你堅持你的, 我仍然還是贊成我的.
 
how-do-specialized-intermediaries-facilitate-creative-crowdsourcing  
 
為了解決這樣的問題, 團隊之中, 或者是團隊的領導者, 需要引導(facilitate) 這樣的能力, 以讓事情的運行能夠有效. 這個名詞大家常常通過, 可是知道它的意義是什麼嗎? 就讓我們來解釋一下, 什麼是引導:
1. 讓事情變容易

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

當有件事情要討論如何處理時, 你們團隊會怎樣處理呢? 一開始時, 你可能會覺得大家就是把意見提出來, 大家專心一致, 熱心參與, 經過一段時間後, 事情就可以歸納出一個解法出來. 
 
事實上, 從來沒有這樣發生過. 是吧? 因為人都會分心, 有時候聊著, 就忽然間換到別的主題. 這個狀況可能還比較好解決, 可以縮短時間, 或者縮小討論範圍, 讓大家比較專心一點. 
 
但是, 每個人都是不同的個體, 容易執著於自己的想法, 這就不是專心可以解決的, 大家會認爲這個過程已經脫序, 已經是一個無效的會議了. 實際上, 這是一個必經的過程, 你需要先經過一個發散的過程, 再經過一個收斂的程序,  最後再得出一個結論出來. 
 

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

找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼