在處理敏捷開發的需求時, 敏捷社群常使用 user story 來描述要做的需求. 有天我忽然發現到, IDEO 設計思考的流程中, 有個叫做設計觀點 (POV, Point of View)的東西, 和 user story 很相似. 讓我們來比較一下吧

使用者故事(User Sotry) 的格式如下:
As a [Role], I want [Feature] because of [Some Reason].
範例: [身為買書的客戶], 我希望能[利用部分書名來找書], 因為[我無法記得完整書名]

 

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

之前有位朋友提到, 用 Trello 記錄要的的事情, 發現工作一直在增加. 這件事情讓我感觸很多, 因為現在我所處的維護團隊也有相同的狀況.

 

trello-2  



那在這種情況時, 我們該怎樣使用 Kanban 來輔助我們改善這樣的情形呢? 以下是我想到的:

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

之前和朋友談天, 他說在執行 Scrum 時遇到一些困難, 讓他覺得 Scrum 似乎並不是那麼美好. 讓我們來看看他遇到了什麼困境:

 

US_Navy_110813-N-XS652-351_Runners_navigate_an_obstacle_during_the_11th_annual_Armed_Services_YMCA_Mud_Run_at_Joint_Expeditionary_Base_Little_Creek  

1. 基本消費額太高
在每個 sprint 中, Scrum 要進行 planning meeting, daily standup meeting, review meeting 和 retrospective, 很多人在抱怨都一直在開會, 2 周的 iteration 其實不是兩周, 可能只剩下 7-8 天而已. 如果再加上要參加別人的 review, 或是公司的會議, 那其實沒有多少時間在工作上面.

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

在 Kanban 最神奇的地方, 就是要求限制同時工作項目的數量 (WIP limit), 也就是讓團隊成員專心處理一件事情, 這樣會讓 cycle time 比較小.

可是你會遇到一個問題, 就是每個人的處理速度不一樣快, 或者每個工作的大小不一, 會導致你整個流程會走走停停. 例如下圖所示:

 

螢幕快照 2014-04-02 下午10.38.21  

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

魚骨圖是由日本管理大師石川馨先生所發展出來的, 所以又叫做石川圖. 魚骨圖是一種發現問題的“根本原因”的方法, 通常搭配腦力激盪法進行.

 

10152585_780252181986177_789316847_n  

 

進行方法 (簡易版)

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

Close

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

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

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

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

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼