目前日期文章:201505 (13)

瀏覽方式: 標題列表 簡短摘要
Planning is everything. Plans are nothing! 這是艾森豪將軍的名言. 二次大戰期間, 艾森豪帶領同盟國聯軍, 跨越英倫海峽反敗為勝, 靠的就是縝密的情報蒐集和靈活應變.
 
螢幕快照 2015-05-27 下午11.04.08  
 
我想大家應該都贊同這樣的理念, 專案一開始是要有計劃, 但是更重要的是要隨時隨地在規劃, 以因應各種突發狀況. 
 

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

很多開發人員在開發軟體時, 會說他們的工作很難估得很準, 因為 spec 常常更改, 或者 spec 不明確, 所以無法確保要做多久.
 
Developer-vs-Tester  
 
哪測試呢? 測試的工作就能估得很準嗎? 很多人會以為開發人員都已經寫好了, 測試人員只是把 test cases 跑完就好, 哪有什麼不確定的.
 

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

在碧血劍中, 有一場劇情是這樣的, 男主角袁承志和其師兄的弟子過招, 在過程中他告訴對方華山派拳法的起手式也是能在實戰上被使用的. 小說是這樣寫: 
 
l_p1003201870   
 
袁承志道:「你以為起手式只是客套禮數,臨敵時無用的麼?要知咱們祖師爺創下這套拳來,沒一招不能克敵制勝。你瞧著。」

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

這週 Odd-e 又要在我們公司上課, 這時候讓我想起 Daniel 當初講的範例, 他如何鼓勵一個測試人員, 去熟悉測試自動化技能的過程.
 
激勵 (inspiration) 是有階段的, 並非一蹴可幾的. Daniel 把這過程分成以下階段:
 
Inspiration-words  
 

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

今天在公司教授 Kanban 時談到一個 WIP 設定的範例, 覺得十分有趣, 想跟大家來分享.
 
這裏有一個工作流程, 其看板呈現如下: 
 
螢幕快照 2015-05-21 下午9.34.33  
 

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

在 agile community 中, 常見用來評估工作的手法是 playing poker. 它是一個以共識為主的評估方法. 在軟體開發上, 來評估工作的 effort 和相關的 size.
 
螢幕快照 2015-05-19 下午9.53.18  
 
至於他要怎麼進行呢? 我想網路已經有很多介紹的文章, 已經不需要我再多說明, 有興趣的可以到 wiki 上面看看.

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

敏捷團隊在度量團段士氣方面, 常常是花招百出的. 之前常用的是 happiness index, 可以參考以下文章(http://www.infoq.com/news/2014/02/scaling-happiness-index). 現在我們還換一個新的玩意: Driver of the Team
 
我們會請團隊成員評估在以下這些方面, 他們的感受如何:
 
目標對齊 (Purpose): 手頭上的工作和公司目的對齊程度如何
自主 (Autonomy): 我們有多少授權或是自行決定的程度

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

在網路上常常會看到 Scrum master 和 agile coach 這兩個名詞, 常常不是很清楚兩者的差異. 今天花了些時間整理一下, 還請大家給些意見:
 
AgileCoach@Spotify  
 
Scrum Master
對象: 針對某個團隊

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

Scrum 開發流程中, 第一道關卡就是要進行 sprint planning meeting. 在這個會議中, 你需要找出要做哪些故事, 並且將這個故事拆解成 task. 
 
那要怎麼進行呢? 這裡有篇文章介紹了他們如何進行 sprint planning meeting, 大家可以參考一下.
 
Sprint-Planning  
 

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

如何管理自組織團隊? 這個問題什麼有趣, 都已經是自組織團隊了, 還需要我們去管理嗎? 他們自己就可以處理所有事情了.
 
可是都不理會這樣可以嗎? 這樣會不會跟公司越走越遠, 和公司的策略無法一致?
 
事實上, 依照 Scrum 的說法應該是這樣的: 管理階層的職責在於制定策略目標, 但是團隊成員的工作, 則是在於決定如何達成目標, 也就是團隊成員必須自行決定要如何完成工作.
 

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

Scrum 藉由頻繁交付, 可以讓你的缺點即早曝露, 因此你可以及早修正. 
 
因此, 有人說, Scrum 是一面鏡子, 他會把你的行為, 一舉一動, 呈現出來給大家看, 所以你才知道你哪裡有問題.  
 
螢幕快照 2015-05-05 下午8.44.34  
 

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

之前看了Henrik Kniberg 的Agile Product Ownership in a Nutshell 的 video (https://www.youtube.com/watch?v=502ILHjX9EE ), 外加 Daniel Teng 的教誨, 對於 Agile/Scrum 有更深一層的感觸. 以下是整理出來產品負責人 (Product owner) 應該注意的事情:
 
complete-product-owner-title  
 
1. 知道為什麼比知道要做什麼重要
知道客戶為什麼要, 或者他遭遇到什麼問題, 會比只是知道要做什麼功能還重要. 所以你需要花時間去瞭解客戶, 通常你會利用 design thinking, empathy, user journey map 等技巧, 瞭解客戶背後的問題. 

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

如果你要估算粉刷一間公寓要多久時間, 你的做法可能如下:
(1) 會先知道公寓內某間房間 A 大約多大
(2) 然後再概算這間房間要花多久時間粉刷完成
(3) 接著再看看這間公寓的面積大約是這間房間的幾倍大
(4) 最後便可推出總時間 = 房間 A 粉刷時間 x 幾倍大
 

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

找更多相關文章與討論

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

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

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

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

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼