這過去這一個星期，我們開始進行了實際操作。將目前所有的工作區分，依據專案開發與維護成兩個區塊：
系統維護
目前維護的系統，仍有需多修改需求單，若要單獨將這些需求都納入 SCRUM 方式管理，很明顯的不符合效益；因此使用 KANBAN 方式，直接將所有的需求、BUG利用 BACKLOG 紀錄，並且簡單的提供 ARRPOVE – COMMIT -DONE 三個步驟。
基本上不使用 SPRINT，因為大部分的工作都只需要指派的成員 COMMIT 之後就可以完成 DONE 的。
各項欄位用途：
NEW：使用者提出的需求，這裡我們要先逐項討論，並依據優先序安排上、下的順序。
APPROVED：已經確認要列入處理的項目中，這裡的目標就是要描述工作內容，團隊討論給定 EFFORT 的分數
COMMITED：上面兩項是由PM 決定移動，這裡就是成員依據自己的時間，由 APPROVED 移動到 COMMITED，代表已經開始進行
DONE：同樣由成員將已經完成的項目移動。
這樣的方式主要目標就是簡化成員的工作項目，讓使用率可以普及。
專案開發
走標準的 SCRUM 架構，這一週花費許多時間討論 TASKS ＆CAPACITY，並且說明 BURNDOWN CHART 的目的：
此外，在專案開發部分，採用小組訓練，而非全部的成員一起參與。因為 TASKS 的細分需要許多討論，無關的人參加畢竟有時間上的浪費，且成效也未必大。
目前接受度算是可以，尤其對專案經理而言，也同意這樣的方案有許多優點，並且能夠積極參與，算是已經邁出第一部了。
有問題嗎？歡迎一起討論喔！