Agile Modernization – Underlying Principles
This is one of a series of blogs connecting the principles described in the eBook to agile legacy modernization.
It is possible to apply agile development practices to legacy modernization. The often cited disadvantages of waterfall development apply equally to modernization projects. If you have to completely understand and document the legacy application before writing a line of new code, you will incur tremendous risk.
Let’s see how the principles described in the recent ebook can facilitate agile modernization.
| Use Case 2.0 First Principles | Applied to Legacy Modernization |
|---|---|
| Keep it simple by telling stories | When interviewing stakeholders about how they use the system, start with stories key to the business. Add exceptions and alternate endings in subsequent iterations. |
| Understand the big picture | After initial functional reviews, you should have a high level view and complete scope of the system. In other words, a use case model. The use case model should include batch and system interfaces, a complete functional overview. |
| Focus on value | Focus on current business values. Retain and prioritize the value of the legacy application. |
| Build the system in slices | Reverse engineer and re-engineer in slices. Based on user value, isolate the most useful parts as slices. Include the test cases for early validation of functionality. |
| Deliver the system in increments | Apply agile practices to legacy modernization. Use cases provide for overall planning. Determine increments according to risk and priority. |
| Adapt to meet the team’s needs | Applying agile modernization principles depends on the team. Determine formality based on team size and collaboration issues. |
Subsequent blogs will detail each principle and what it means in the context of legacy modernization. The goal is to build on extensive use case experience for application to legacy modernization and leverage state-of-the-art knowledge about use cases.
Use-Case 2.0 exists as a proven and well-defined practice. Although the term Use-Case 2.0 suggests a new version of use cases, it does not refer to an update of the Unified Modeling Language, but rather to cumulative changes in the way software developers and business analysts apply use cases. A use case is still a use case but the ways that we present, address and manage them have all evolved to be more effective. The changes are not theoretical but are pragmatic changes based on 20 years of experience from all over the world and all areas of software development. [1]
- [1] http://www.ivarjacobson.com/Use_Case2.0_ebook/, page 4 ↩
