Adaptable Designs for Agile Software Development
Download as PPTX, PDF5 likes4,666 views
The document discusses adaptable designs for agile software development, emphasizing the importance of creating minimum viable products (MVPs) that facilitate rapid feedback and learning. It proposes a new development mindset that prioritizes software evolution, adaptability, and experimentation, contrasting traditional and modern development approaches. The document outlines architectural needs and microservices practices to support these agile methodologies, ultimately concluding that software systems must be designed to evolve over time to meet changing requirements.
Adaptable Designs for Agile Software Development
- 1. Adaptable Designs for Agile Software Development Hayim Makabee http://EffectiveSoftwareDesign.com
- 2. My life in logos: Education: Experience:
- 3. Agile Software Development Iterative, Incremental Example: Scrum
- 5. Building a Pyramid Incrementally (Wrong)
- 6. Building a Pyramid Incrementally (Right)
- 7. Minimum Viable Product (MVP) The MVP is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The MVP should have the core features which allow it to be deployed to real customers to get initial feedback, but not more.
- 9. Adaptability “A system that can cope readily with a wide range of requirements, will, all other things being equal, have an advantage over one that cannot. Such a system can allow unexpected requirements to be met with little or no reengineering, and allow its more skilled customers to rapidly address novel challenges.” - Brian Foote and Joseph Yoder – “Big Ball of Mud”
- 10. New development mindset Instead of planning for software development, plan for software evolution.
- 11. Adaptable Design Adaptable Software Design: A generic software design for a family of systems which does not need to be changed to accommodate new requirements.
- 12. Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 13. Manifesto for Adaptable Software Development Experimentation instead of Specification Evolution instead of Implementation Adaptation instead of Modification Extension instead of Growth
- 14. Experimentation instead of Specification Traditional software development: ◦ Detailed specification of system requirements, functional and non- functional. Modern software development: ◦ Allows the discovery of requirements through experimentation.
- 15. Evolution instead of Implementation Traditional software development: ◦ Focuses on the prioritized implementation of features according to specified requirements. Modern software development: ◦ Allows the constant evolution of the system’s functionality to meet the dynamically varying customer needs.
- 16. Adaptation instead of Modification Traditional software development: ◦ The code must be modified in order to meet changing requirements. Modern software development: ◦ Allows the existing code base to be easily adapted to satisfy any change in requirements.
- 17. Extension instead of Growth Traditional software development: ◦ The system must grow in order to accommodate additional requirements. Modern software development: ◦ Allows the easy extension of the system’s functionality through modular features.
- 18. Architectural needs The Software Architecture must support: ◦ Experimentation ◦ Evolution ◦ Adaptation ◦ Extension If the Software Architecture is not adaptable, the Agile process will fail. Consequences: Increasing Technical Debt, endless Refactoring.
- 19. SOA Principles 1. Standardized Service Contracts 2. Service Loose Coupling 3. Service Abstraction 4. Service Reusability 5. Service Autonomy 6. Service Statelessness 7. Service Discoverability 8. Service Composability 9. Service Interoperability
- 20. Microservices Practices (I) 1. Separated Build: ◦ Each Microservice is built independently and has its own version. 2. Independent Deployment: ◦ Each Microservice may be deployed without affecting the others. 3. Separated Data Stores: ◦ Microservices should not share data stores. 4. Independence of Platform: ◦ Microservices should be deployed in containers.
- 21. Microservices Practices (II) 5. Individual Technology Choice: ◦ Each Microservice may be implemented using a different technology. 6. Confinement of Failure: ◦ If a failure occurs in a particular Microservice it should not propagate to the other ones. 7. Independent Scalability: ◦ It should be possible to scale each Microservice independently of the others.
- 22. Conclusions Software systems must evolve over time. Evolution must be planned and supported by Adaptable Software Designs. Adaptable Software Development: ◦ Experimentation instead of Specification ◦ Evolution instead of Implementation ◦ Adaptation instead of Modification ◦ Extension instead of Growth
- 23. Adaptability & Evolution “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.” Charles Darwin