在處理敏捷開發的需求時, 敏捷社群常使用 user story 來描述要做的需求. 有天我忽然發現到, IDEO 設計思考的流程中, 有個叫做設計觀點 (POV, Point of View)的東西, 和 user story 很相似. 讓我們來比較一下吧
使用者故事(User Sotry) 的格式如下:
As a [Role], I want [Feature] because of [Some Reason].
範例: [身為買書的客戶], 我希望能[利用部分書名來找書], 因為[我無法記得完整書名]
kojenchieh 發表在 痞客邦 留言(2) 人氣()
之前有位朋友提到, 用 Trello 記錄要的的事情, 發現工作一直在增加. 這件事情讓我感觸很多, 因為現在我所處的維護團隊也有相同的狀況.
那在這種情況時, 我們該怎樣使用 Kanban 來輔助我們改善這樣的情形呢? 以下是我想到的:
kojenchieh 發表在 痞客邦 留言(0) 人氣()
之前和朋友談天, 他說在執行 Scrum 時遇到一些困難, 讓他覺得 Scrum 似乎並不是那麼美好. 讓我們來看看他遇到了什麼困境:
1. 基本消費額太高
在每個 sprint 中, Scrum 要進行 planning meeting, daily standup meeting, review meeting 和 retrospective, 很多人在抱怨都一直在開會, 2 周的 iteration 其實不是兩周, 可能只剩下 7-8 天而已. 如果再加上要參加別人的 review, 或是公司的會議, 那其實沒有多少時間在工作上面.
kojenchieh 發表在 痞客邦 留言(3) 人氣()
在 Kanban 最神奇的地方, 就是要求限制同時工作項目的數量 (WIP limit), 也就是讓團隊成員專心處理一件事情, 這樣會讓 cycle time 比較小.
可是你會遇到一個問題, 就是每個人的處理速度不一樣快, 或者每個工作的大小不一, 會導致你整個流程會走走停停. 例如下圖所示:
kojenchieh 發表在 痞客邦 留言(0) 人氣()
魚骨圖是由日本管理大師石川馨先生所發展出來的, 所以又叫做石川圖. 魚骨圖是一種發現問題的“根本原因”的方法, 通常搭配腦力激盪法進行.
進行方法 (簡易版)
kojenchieh 發表在 痞客邦 留言(0) 人氣()