在某一場回顧會議中的對話:
A: 那個需求每次都很不明確, 所以在之後都要花很多時間釐清
B: UI mock 花太多時間做了, 我們拿到時都已經很晚了
C: RD 應該對重要部分進行 code review, 否則後面品質好不穩
A: 測試人員太晚進行 performance test, 導致我們後面沒時間 turn system
- Dec 09 Wed 2015 22:28
以欣賞的角度來進行回顧會議
- Dec 09 Wed 2015 09:53
誰說我們不能一起做決定 - 參與式討論
敏捷方法要求團隊一起合作, 一起思考. 可是這在傳統的組職中很難辦到, 因為大部分時間, 都是老闆說了算, 或者員工不想參與決策, 因此導致敏捷很難被導入成功.
那團隊一起討論, 真的有比老闆單人決策好嗎? 如果有的話好在哪裡?
- Dec 06 Sun 2015 22:23
敏捷轉型時常見的風險
在導入敏捷, 進行敏捷轉型時, 我們通常一開始會規劃要怎麼做後, 便開始開工了.
可是轉型這件事情, 就像我之前文章所提到的, 它其實像是一件創業的工作. 你提出來的產品功能或是想法, 都是沒有經過確認的, 使用者可能覺得這不是問題, 或者雖然他是問題, 但是我現在不急, 不想付錢來解決. 因此我們必須要步步為營, 利用 MVP 的概念, 來確認方向是否正確.
- Dec 01 Tue 2015 20:51
尋找還在戰場上的英雄
很多時候有人問說敏捷轉型有沒有絕招, 可不可保證一定成功的. 我想任何有經驗和有良知的人, 應該都會跟你說沒有.
很多時候, 顧問或是大神只是把這方面的知識唸得很熟, 把它整理的很好, 或者是只是看得比較多而已. 但是到實際戰場上, 能不能做得像他講的一樣神勇, 其實都是個未知數.
- Nov 30 Mon 2015 22:48
精實改變畫布
我們在創業時, 需要有個創業計畫. 以前需要寫個很複雜的商業計劃, 可是以現在快速變遷, 並且高度不確定的狀況下, 那已經不切實際. 因此, 以商業畫布來取代商業計畫, 是目前的趨勢.
同理, 在做敏捷轉型時, 也遇到類似的問題. 轉型後會達到什麼效果, 會有什麼進度, 這通常是不確定的. 如果, 我們還是以以前的方式來規劃, 只是浪費自己的時間, 並且也因為不確定高, 會讓自己感到很挫折.
那敏捷轉型也有畫布可以使用嗎? 是的, Jeff Anderson 提出了 Lean Change Canvas 的做法, 便是要採用雷同的想法到敏捷轉型上面.
