Agile Mëtteg series session 7
Download as PPTX, PDF1 like1,439 views
The document discusses agile architecture and design practices. It begins by addressing myths about agility and architecture, defining key terms, and explaining how agility affects architecture. It promotes lightweight, evolving designs over big upfront designs. It also introduces domain-driven design and component-based design approaches. Finally, it discusses coding best practices like test-driven development, version control, continuous integration, and refactoring that support agile architecture and design.
Agile Mëtteg series session 7
- 1. Agile architecture & programmingAgile Mëtteg – 16 September 2010
- 2. OBJECTIVESUnderstand the implications of agile development on architecture, design and coding practicesExplain some myths about software architecture and agilityShow some best practices16 Sept 20102Agile Mëtteg - Agile architecture
- 3. AGILE PARTNER SERVICESCustom Software Development & MaintenanceOur core business to answer customer needsIS servicesThanks to our expertise we can support IT team to reach their productivity & quality objectives (Assessment, Coaching, Support, Training, Resource delegation…)IS SolutionsTake benefit from commercial or Open Source platform to answer as quick as possible to specific needsIS users servicesWe can support Product & Services owners to work closely with the IT team (Assessment, Coaching, Support, Training, Resource delegation…)16 Sept 2010Agile Mëtteg - Agile architecture3IS users Services14Software Development & SoftwareMaintenance2ISSolutionsIS ServicesAgilityAgility31234Agility
- 4. ABOUT MEAbout Me16 Sept 2010Agile Mëtteg - Agile architecture4
- 5. AGENDAAgendaMyths about agility and architectureWhat do we mean by Architecture?What do we mean by Agile?How does agility affect architecture?Introduction to Domain-Driven DesignIntroduction to Component-Based DesignCoding practices16 Sept 2010Agile Mëtteg - Agile architecture5
- 6. Myths about Agility and Architecture16 Sept 2010Agile Mëtteg - Agile architecture6
- 7. MYTHS ABOUT AGILITY & ARCHITECTUREAgile = FragileNo Architecture No DesignOnly works for small projects16 Sept 2010Agile Mëtteg - Agile architecture7
- 8. What do we mean by Architecture?16 Sept 2010Agile Mëtteg - Agile architecture8
- 9. WHAT DO WE MEAN BY ARCHITECTURE?Architecture embodies the critical design decisions that classify a systemEnterprise Architecture (relates to organizational structure, cost of change, ...)Technical Architecture (infrastructure)Software Architecture (capabilities of the system, structure of code ...)etc.16 Sept 2010Agile Mëtteg - Agile architecture9
- 10. WHAT DO WE MEAN BY ARCHITECTURE?A good architecture is one in which the significance of decisions is reducedThis means key decisions are the ones that reduce the significance of other decisionsMakes changes easy Reduces cost of changeA stable and robust architecture does not mean it is “frozen”16 Sept 2010Agile Mëtteg - Agile architecture10
- 11. WHAT DO WE MEAN BY ARCHITECTURE?The importance of decisions needs to be well understood and assessedHeavy-weight approaches are likely to reduce the understanding and the ability to evaluateKeep it simple!16 Sept 2010Agile Mëtteg - Agile architecture11
- 12. WHY ARCHITECTURE IS SO IMPORTANTBase for further decisionsInfluence on team structureFoundation for GUI“The interface is the program” (Raskin)Reflects system designWeb, Smart Client, Client/Server, Embedded ...16 Sept 2010Agile Mëtteg - Agile architecture12
- 13. What do we mean by AGILE?16 Sept 2010Agile Mëtteg - Agile architecture13
- 14. AGILE MANIFESTOIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan16 Sept 2010Agile Mëtteg - Agile architecture14
- 15. AGILE DEVELOPMENTWhat makes development agile is ...Sustainability of process and codeFeedback at different levels of scaleAwareness of what is being built and howThe right detail at the right time and in the right placeThe engagement of people in the processEconomy16 Sept 2010Agile Mëtteg - Agile architecture15
- 16. How does agility affect Architecture?16 Sept 2010Agile Mëtteg - Agile architecture16
- 17. HOW DOES AGILITY AFFECT ARCHITECTURE?Requirements for an “agile” designThe design should improve inter team communicationIt must be comprehensible to everyone without a lot of documentationIt must support testingThe design must support customer communication and collaborationIt must respond to change16 Sept 2010Agile Mëtteg - Agile architecture17
- 18. BUFD, NUFD or RUFD?16 Sept 2010Agile Mëtteg - Agile architecture18
- 19. WATERFALL / CLASSICAL APPROACH16 Sept 2010Agile Mëtteg - Agile architecture19ProjectPlanBuildTestReviewDeploy
- 20. WATERFALL / CLASSICAL APPROACHBig upfront designImpossible to know everything in advanceLack of flexibilityLack of extensibilityLack of adaptability“Ivory Tower” metaphorArchitecture might be ignored because team members were not involved in its creation16 Sept 2010Agile Mëtteg - Agile architecture20
- 21. SCRUM16 Sept 2010Agile Mëtteg - Agile architecture21SprintPlanDeployPlanPlanPlanReviewBuildBuildBuildBuildTestTestTestTestReviewReviewReviewReviewFeature 1Feature 2Feature 3Feature 4
- 22. AGILE MODELLINGNo Up-Front DesignTeam members have a very high technical expertiseTeam members have in-depth knowledge of the domain16 Sept 2010Agile Mëtteg - Agile architecture22
- 23. AGILE MODELLINGKeep up-front design shortBut not tooshortYou do not have to know precisely what to build before you can start building it.A sprint/iteration 0 can help defining key architecture concepts, a vision and initial architectureUse existing expertiseDelaying critical design decisions does not mean we ignore existing knowledgeUse proof of concepts to backup the architecture and document it16 Sept 2010Agile Mëtteg - Agile architecture23
- 24. DRUFD vs NUFD 16 Sept 2010Agile Mëtteg - Agile architecture24Release GAHA - JEBIFCJ1st Sprint2nd Sprint3rd SprintInceptionDAGJA - IEBHKFCIL1st Sprint2nd Sprint3rd Sprint4th Sprint
- 25. EVOLVING ARCHITECTURE16 Sept 2010Agile Mëtteg - Agile architecture25FeedbackModels, VisionEnvision Initial ArchitectureCommunicate Architecture to StakeholdersUpdate ArchitectureModels, VisionFeedbackModels, VisionWork with developersModels, Vision
- 26. LAYERED ARCHITECTUREIteration n16 Sept 2010Agile Mëtteg - Agile architecture26Iteration 3Iteration 2Iteration 1
- 27. InTrODuction TODoMain-DRIVEN DESIGN16 Sept 2010Agile Mëtteg - Agile architecture27
- 28. DOMAIN-DRIVEN DESIGNDomain-Driven Design (Eric Evans)Focus on the core domain and domain logicModel is the base of complex designsInitiating a creative collaboration between technical and domain experts to find the conceptual heart of the problem iteratively.16 Sept 2010Agile Mëtteg - Agile architecture28
- 29. DOMAIN-DRIVEN DESIGNDomain-Driven Design ConceptsJust in time modelingUbiquitous languageBounded ContextsDecoupling business logic from other aspects of the systemSeparation Of ConcernsCohesiveness16 Sept 2010Agile Mëtteg - Agile architecture29
- 30. InTrODuction TOCOMPONENT-BASED DESIGN16 Sept 2010Agile Mëtteg - Agile architecture30
- 31. COMPONENT-BASED DESIGNComponent-Based DesignAn individual component is a software package, a web service, or a module that encapsulates a set of related functions (or data).All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes)Software as a circuit board16 Sept 2010Agile Mëtteg - Agile architecture31
- 32. COMPONENT-BASED DESIGNComponent-Based Design ConceptsModularityReusabilityCompositionEncapsulationSeparation Of ConcernsCohesiveness16 Sept 2010Agile Mëtteg - Agile architecture32
- 33. COMBINING APPROACHESUsing Domain-Driven Design within a componentTo create domain model and logicBounded ContextsAnti-Corruption layersImprove communication with UL16 Sept 2010Agile Mëtteg - Agile architecture33
- 34. COMBINING APPROACHESUsing Component-Based design to achieveModularityCompositionEncapsulation and DecouplingThe component defines a bounded contextEnables us to focus on one problem at a time16 Sept 2010Agile Mëtteg - Agile architecture34
- 35. SOFTWARE CELLS16 Sept 2010Agile Mëtteg - Agile architecture35PresentationPresentationPresentationPresentationDomain ModelDomain ModelDomain ModelDomain ModelData AccessData AccessData AccessData Accessis composed ofPresentationPresentationDomain ModelDomain ModelData AccessData Access
- 36. Coding practices16 Sept 2010Agile Mëtteg - Agile architecture36
- 37. TEST-DRIVEN DEVELOPMENTTest-Driven DevelopmentDesign tests BEFORE implementing a featureTests are testing the expected behavior of a component or classImplementation is done step by step until all tests passSupports thinking of a design that can be tested16 Sept 2010Agile Mëtteg - Agile architecture37
- 38. BEHAVIOR-DRIVEN DEVELOPMENTBehavior-Driven DevelopmentGet business specialists involved in testing!Focuses on collaboration between developers, quality assurance and business usersMight be used for User Acceptance testing16 Sept 2010Agile Mëtteg - Agile architecture38
- 39. VERSION CONTROL & CONTINUOUS INTEGRATIONVersion ControlA version control system allows the team members to simultaneously work on the code base. It automatically merges differences and reports conflicts.Continuous IntegrationRegular builds of the code baseEarly discovery of introduced bugsAutomatic execution of test baseReduces Regression16 Sept 2010Agile Mëtteg - Agile architecture39
- 40. REFACTORINGRefactoringImprove code quality without changing its behaviorCode towards design patternsConsider separation of concerns and cohesivenessTDD, BDD, Version Control and CI are the foundation for refactoring (a safety-net), they reduce the fear of change16 Sept 2010Agile Mëtteg - Agile architecture40
- 41. DECOUPLINGDecouplingHow?Inversion of controlDependency Injection EncapsulationHelps withModularityExtensibilityMaintainabilityTestability16 Sept 2010Agile Mëtteg - Agile architecture41
- 42. DESIGN PATTERNSDesign PatternsDo not re-invent the wheelDesign Patterns provide solutions for common problemsDomain-Driven Design defines a set of architectural patterns16 Sept 2010Agile Mëtteg - Agile architecture42
- 43. DEMo16 Sept 2010Agile Mëtteg - Agile architecture43
- 44. QUESTIONSIntentionallyBlank(ish)16 Sept 2010Agile Mëtteg - Agile architecture44
- 45. RESOURCESAgile Partner: www.agilepartner.netAgile Partner blog: blog.agilepartner.netAgile Interest Group Luxembourg:www.aiglu.orgAgile Alliance: www.agilealliance.orgScrum alliance: www.scrumalliance.orgScrum.org16 Sept 2010Agile Mëtteg - Agile architecture45
- 46. NEXT TRAININGS & CERTIFICATIONSJune 17th, 2010Agile Mëtteg - Continuous improvement in practice46Complete calendar on: http://www.agilepartner.net/training/
- 47. CONTACTSThank You16 Sept 2010Agile Mëtteg - Agile architecture47
Editor's Notes
- #2: SCH
- #3: SCH
- #5: CPO & PAG
- #6: CPO
- #7: PAG
- #8: PAG
- #9: PAG
- #10: PAG
- #11: PAG
- #12: PAG
- #13: PAG
- #14: PAG
- #15: PAG
- #16: PAG
- #17: PAG
- #18: PAG
- #19: PAG
- #20: PAG
- #21: PAG
- #22: PAG
- #23: PAG
- #24: PAG
- #25: PAG
- #26: PAG
- #27: CPO
- #28: PAG
- #29: PAG
- #30: PAG
- #31: PAG
- #32: PAG
- #33: PAG
- #34: PAG
- #35: PAG
- #36: PAG
- #37: CPO
- #38: CPO
- #39: CPO
- #40: CPO
- #41: CPO
- #42: CPO
- #43: CPO
- #44: CPO
- #45: CPO