Report: LIU TENG YUAN

The iteration Short iteration (two weeks) generalist developers v.s domain experts Fig 1: Day one of the iteration. Looking good Fig 2: Last day of the iteration. Not exactly what we’d planned

The iteration Burn-down charts by ScrumMaster Retrospective (valuable, but suggestions ?) Fig 4: The actual burn-down after the iteration. The team did pretty well, but was far from delivering all that had been planned. Scope change is very visible. Fig 3. The burn-down at day one. Expected worst case best case and average case added. In this case the team had planned a little more than could be expected in the average case.

The release cycle three 2-week iterations( test week, stage week,development) test week: regression testing, user stories stage week: more regression testing, no errors, final verification problem: 1.test week was very stressful 2. 3 rd deployment had to be carried out idea: next release cycle started in the stage week of the previous one.

The revolution Time box/iteration was eliminated Stand-up meeting changed from team member to work item focus Support process and bug handling integrated in regular process Work item estimation skipped Burn-down charts dropped A defined workflow was introduced, with clear goals/deliverables in each step The whiteboard was changed WIP limits were introduced The evolution

KPI: 關鍵績效指標

Fig 5: Results of a team survey done a few weeks after introducing FSD

Fig:6 Bugs reported in various environments for each release. FSD introduced after

由上面的問券跟統計 bug 調查顯示, 移除不必需的程序不僅節省時間  工作者能在一件事情更專一、專一 stand-up meeting 對象轉移  這使得目標更明確, 造成有效的討論 更在最後的 bug 數量的結果上有顯著的改善,

圖片來自於以下作者之投影片與報告 “Moving to flow-based software development” by Jorn Ola Birland