Strategies for replacing systems in agile projects

1. 2009 Agile Conference Strategies for replacing systems in agile projects 985202042 王鈺歆

2. Background Replacement projects 要使用什麼策略來替換舊系統? 最簡單的策略: “at least as good as the old one” before switching Is it agile!?

3. Propose 如何決定最佳的開發順序才能在合理的時間內才能具有生產力? Minimal Deployable Entity (MDE) GeneralPrinciples MDE strategies as patterns

4. Minimal deployable entity • In a typical replacement project • Face with a large, monolithic and undocumented legacy system • Knowledge of the workings of legacy system is fragmented and partial • 使用者們對立的情緒與心聲 • 如果最後能把這個老系統完全關掉該有多好 • 直到新的至少能跟舊的這個一樣好，否則我不能接受你把他換掉

5. Minimal deployable entity Release plan with many sprints before the first release to production

6. Minimal deployable entity • The smallest set of features that must be developed before a system can be deployed into production • To count as being “deployed to production” • The system must be used by at least one user set to perform real tasks within a particular workflow or set of operations • Early feedback • Risk reduction

7. Case : Research application system • The legacy system: • 誕生於 internet 時代之前的老古董 • 只設計了human interface 給內部員工使用 • Researchers 必須藉 paper 發送 applications 然後才 punched 進系統 • 外部 reviewers of proposals 也必須收發paper • projects 的處理報告與收到的資金也同樣的隱密

8. Case : Research application system • 四個主要的策略 • 採用 “shared database” • 新系統應該建構在 現存的 database 之上 • 系統應該要建立在基本的工作流程上: submission of application, peer review, funding decision, progress reporting, and final end report • 第一次的 release 應該要是一個能讓 researchers 組合與提交 applications 的 web-based system 。

9. Case : Research application system • First release 應該只能讓一小部分的 applications 所使用 • 處理最簡單的 research proposal 類型 並 限制能夠送 applications 的使用者的數量 • First release只包含了必須的functionality • 即使是具有價值但不是必須的 features 仍不予列入 • 較困難 • 這四個策略運作良好，在開發四個月後佈署了 first version 且在之後的一個月內收到了 約100 applications

10. Case : Research application system • 要怎麼 verifying legacy system 如何去使用database? • 幾乎所有的 validation 都是在系統中，而不是使用database • database 接受的資料中有一部分會讓 legacy system 出錯 • many很少使用 功能幾乎遍佈整個系統 • 過時的功能 (→ 移除) • 很少使用的功能 (→保留) • 必須將這兩類功能完全區分出來

11. General principles • Is it necessary? • 在 planning 時第一個問題應該問 “Is it really necessary to replace?” 增強 legacy system 通常會比替換掉好。 作者提出自己的經驗法則: 替換 legacy system 會是預估的兩倍貴 。 • The value of delaying • 在 project 剛開始的時候，最缺乏的通常是 legacy system 的 knowledge 。 如果不能辨識出合理的 small MDE ，也許是該採取 delaying 戰術的時候了。 • The value of pain • 使MDE 最小化的過程會在 version 1.0 時非常的痛苦。 只包含絕對必需的功能，其餘的就算有價值也不放入 first release 。 這點很難讓顧客 (both users and management) 去接受 ，尤其是對外部的使用者來說更是如此

12. General principles • Limited releases • 試著去找出一小群的使用者來做測試 • 使人更能接受在 MDE 中限制功能這件事 • 測試者能影響的人甚少，一些議論的影響力甚低。 • Verify your strategy • 訂出 MDE 策略後要去確認能符合所有使用者 groups的測試 • Scope control • Agile methods 強調 iterations 的範圍控管，在發展 MDE 時也是如此。控制 MDE 的大小非常難以取捨，在 MDE 中的 iterations 會產生非常嚴重的 優先權爭議

13. MDE strategies as patterns • Shared database • 將新系統建造在現存的 database 之上，實際上也是在增強 legacy system • Workflow by workflow • 大系統通常提供許多 workflows 。在 first release 時只包含一個 workflow 能縮小 MDE • Follow the workflow • 先佈署的 workflow 作為 後續要開發的 workflows 的出發點。 在接下來的 陸續 release 中 延伸出 或是 cover 到 更多的 workflows

14. MDE strategies as patterns • New business • 在保險中稱之為分流策略， legacy system 處理現有的 business ，新系統處理新的 business • Pilot product • legacy system 提供舊有的服務，新系統提供新的服務 • Product by product migration • 逐個將 legacy system 的服務一個一個遷移到新系統上

15. What does it take to identify MDE? • 找出適合的 patterns • 結合成一個 MDE strategy • 在作者的經驗中，必須結合 technical and business knowledge 才能夠成功 • Technical knowledge 用來找出可能的策略以及各個策略所需要花費的開發成本； • Business knowledge 用以評估 哪些策略能被 customer 所接受