AGILE SOFTWARE ARCHITECTURES. Krasimir Baylov

Transcription

1 AGILE SOFTWARE ARCHITECTURES Krasimir Baylov

2 2 Content Game Agile & Software Architectures Architecture Evolution Agile Practices for Software Architectures Architectures in Small and Big Projects

3 3 Outcomes How much design do we need? How do we evolve design in agile projects? What techniques can we apply to build agile software architectures?

4 4 Before We Start Don t take anything for granted! Always doubt in what you hear! Is a certain approach good? IT ALL DEPENDS!!! How do we pick a proper approach? THINK!!! THINK!!! THINK!!! All models are wrong but some are useful, George Box

5 5 GAME End of Lecture Retrospective

6 6 End Of Lecture Retrospective Assume it s the end of the lecture The lecture was a complete failure WHY DID IT HAPPEN? WHAT SHOULD YOU HAVE DONE TO AVOID THE FAILURE?

7 7 AGILE AND SOFTWARE ARCHITECTURES

8 8 Agile Manifesto Valued more Individuals and interactions Working software Customer collaboration Responding to change Valued processes and tools comprehensive documentation following a plan contract negotiation

9 9 Agile Characteristics Deliver business value Welcome requirements changes Iterations Frequent delivery what else?

10 10 Software Architecture Overview Backbone of a system Link between business requirements and system implementation Special attention in waterfall and critical projects What about agile projects?

11 11 Architectures in Waterfall vs. Agile Requirements Analysis Design Code Integration Test Some Requirements Timebox Timebox Timebox Timebox

12 Value Delivery 12

13 13 Architectures in Agile Projects Key To System Evolution It s hard to say whether your architecture is good but it ll take you a minute to find out if it s not

14 14 so far (summary) Agile widely defined, many practices Architecture too much theory, detailed definitions Can they live together?

15 15 ARCHITECTURE EVOLUTION

16 16 Basic System Evolution IMPLEMENT AND EVOLVE BUSINESS GOALS Changes in the business must be reflected in the system And opposite SYSTEM SATISFY

17 17 Basic System Evolution IMPLEMENT AND EVOLVE DESIGN IMPLEMENT BUSINESS GOALS ARCHITECTURE SYSTEM SATISFY CONFORM SATISFY

18 18 Architecture Evolution Agile vs. Waterfall

19 19 so far (summary) Agile Software Architecture evolves through the entire system development Design for change ALWAYS evaluate your architecture against business goals and system implementation

20 20 AGILE ARCHITECTURE BEST PRACTICES

21 21 Design Spikes /Prototypes Prototyping Look outside Experiment Time boxed Limited scope FAILURE IS AN OPTION

22 22 Continuous Integration Commit Report Initiate CI Process Test Build

23 23 Refactoring Improve code Reduce complexity Improve maintainability Background task Whenever you spot something

24 24 Managing Architectural Tasks Add to Product Backlog Separate Architecture Backlog Product Backlog Item X Technical Task Item Y Prototype for WSs Architectural Backlog Architecture task Investigation task Technical Task Prototype for WSs

25 25 Managing Architectural Tasks Kanban Separate Architecture Swim Lane

26 26 Quality Attributes in Agile A.k.a Non-Functional requirements Define as part of User Stories Put in Definition of Done (DoD)

27 27 Retrospective and Futurespective At the end of each sprint What went well What could have been improved Actions Futurespective retrospective assuming we are at the end of the sprint

28 28 (Point vs.) Set Based Design Broad Sets of Design Parameters are Defined Concurrent Design Sets are gradually narrowed until a global optimum solution is revealed

29 29 Reduce Architectural Debt When: continually implement without going back Long term negative impact Use Refactoring Unit testing Redesign Test for architectural qualities Positive Value Negative Value Visible Visible Feature Visible Defect Invisible Hidden Architectural Feature Technical Debt

30 Find Your Sweet Spot 30

31 31 so far (summary) Design for change Isolate parts that are likely to change Maintain high quality Do not overdesign Do not under design Don t forget TDD, reviews, XP,

32 32 ARCHITECTURES IN SMALL AND LARGE PROJECTS

33 33 small Projects 6-8 people Non-life critical projects Architecture evolves with implementation without much risk May or may not need extra architecture attention

34 34 small Projects Pay Attention To Architecture Don t only work on feature implementation Strive For Design Consistency Review Architecturally Critical Areas

35 35 BIG Projects > 9 people Groups split into teams None knows everything Work needs coordination

36 36 BIG Projects Architecture should comply with teams organization Multiple technical risks Don t forget the right part in the Agile Manifesto

37 37 Agile Architecture Values Respect your system s shearing layers Make what is too difficult, time consuming, or tedious easier Don t overdesign!!! Don t underdesign!!! Architect for sustainable development/delivery of features and customer value

38 38 so far (summary) Define if you are working in a small or big project Pick the proper practices for you Manage technical risk accordingly

39 39 some answers How much design do we need? How do we evolve design in agile projects? What techniques can we apply to build agile software architectures?

40 40 REMEMBER Is a certain approach good? IT ALL DEPENDS! How do we pick a proper approach? THINK!!! THINK!!! THINK!!!

41 Q&A 41