agile mëtteg series session 7

Agile Mëtteg – 16 September 2010Agile architecture & programming

Agile Mëtteg - Agile architecture 2

OBJECTIVES

Understand the implications of agile development on architecture, design and coding practicesExplain some myths about software architecture and agilityShow some best practices

16 Sept 2010

AGILE PARTNER SERVICES

Custom Software Development & Maintenance

Our core business to answer customer needs

IS 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 needs

IS users servicesWe can support Product & Services owners to work closely with the IT team (Assessment, Coaching, Support, Training, Resource delegation…)

16 Sept 2010 Agile Mëtteg - Agile architecture 3

IS users

Services

Software

Development

& Softwa

reMaintenance

ISSolutions

IS Services

1 23

41

3

2

4

http://images.google.fr/imgres?imgurl=http://www.logic1.com.au/Picture%20Library/Sharepoint_logo_med.gif&imgrefurl=http://www.logic1.com.au/Picture%20Library/Forms/DispForm.aspx?ID=20&usg=__FqUktnCKyh2MlU1dcd1gRh4Fdyk=&h=139&w=161&sz=8&hl=en&start=3&um=1&tbnid=Bf-JPByx4cVwtM:&tbnh=85&tbnw=98&prev=/images?q=sharepoint+logo&hl=en&rlz=1T4TSEA_en-GBLU305LU310&um=1


ABOUT ME

About Me

16 Sept 2010

5

AGENDA

AgendaMyths 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 practices

16 Sept 2010 Agile Mëtteg - Agile architecture


MYTHS ABOUT AGILITY AND ARCHITECTURE

16 Sept 2010


MYTHS ABOUT AGILITY & ARCHITECTURE

Agile = FragileNo Architecture No DesignOnly works for small projects

16 Sept 2010


WHAT DO WE MEAN BY ARCHITECTURE?

16 Sept 2010



Architecture embodies the critical design decisions that classify a system

Enterprise Architecture (relates to organizational structure, cost of change, ...)Technical Architecture (infrastructure)Software Architecture (capabilities of the system, structure of code ...)etc.

16 Sept 2010



A good architecture is one in which the significance of decisions is reduced

This means key decisions are the ones that reduce the significance of other decisionsMakes changes easy Reduces cost of change

A stable and robust architecture does not mean it is “frozen”

16 Sept 2010



The importance of decisions needs to be well understood and assessed

Heavy-weight approaches are likely to reduce the understanding and the ability to evaluateKeep it simple!

16 Sept 2010


WHY ARCHITECTURE IS SO IMPORTANT

Base for further decisionsInfluence on team structureFoundation for GUI

“The interface is the program” (Raskin)Reflects system design

Web, Smart Client, Client/Server, Embedded ...

16 Sept 2010


WHAT DO WE MEAN BY AGILE?

16 Sept 2010


AGILE MANIFESTO

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

16 Sept 2010


AGILE DEVELOPMENT

What 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 processEconomy

16 Sept 2010


HOW DOES AGILITY AFFECT ARCHITECTURE?

16 Sept 2010


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 change

16 Sept 2010


BUFD, NUFD OR RUFD?

16 Sept 2010


WATERFALL / CLASSICAL APPROACH

16 Sept 2010

Plan

Build

Test

Review

Deploy

Project


WATERFALL / CLASSICAL APPROACH

Big upfront designImpossible to know everything in advanceLack of flexibilityLack of extensibilityLack of adaptability“Ivory Tower” metaphor• Architecture might be ignored because team

members were not involved in its creation

16 Sept 2010


SCRUM

16 Sept 2010

Plan

Build

Test

Review

Deploy

Plan

Build

Test

Review

Plan

Build

Test

Review

Plan

Build

Test

Review

Review

Sprint

Feature 1 Feature 2 Feature 3 Feature 4


AGILE MODELLING

No Up-Front DesignTeam members have a very high technical expertiseTeam members have in-depth knowledge of the domain

16 Sept 2010


AGILE MODELLING

Keep up-front design shortBut not too short• You 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 architecture

Use existing expertise• Delaying critical design decisions does not

mean we ignore existing knowledgeUse proof of concepts to backup the architecture and document it

16 Sept 2010


DEF

RUFD vs NUFD

16 Sept 2010

1st Sprint 2nd Sprint 3rd SprintInception

ABC

HIJ

G

DEF1st Sprint 2nd Sprint 3rd Sprint

ABC

HI

G

4th Sprint

KL

J

Release

A - J

A - I


EVOLVING ARCHITECTURE

16 Sept 2010

Envision Initial Architecture

Communicate Architecture

to Stakeholders

Update Architecture

Work with developers

Models, Vision

Models, Vision

Models, Vision

Models, Vision

Feedback

Feedback


Iteration n

LAYERED ARCHITECTURE

16 Sept 2010

Iteration 3

Iteration 2

Iteration 1


INTRODUCTION TODOMAIN-DRIVEN DESIGN

16 Sept 2010


DOMAIN-DRIVEN DESIGN

Domain-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 2010


DOMAIN-DRIVEN DESIGN

Domain-Driven Design ConceptsJust in time modelingUbiquitous languageBounded ContextsDecoupling business logic from other aspects of the system• Separation Of Concerns• Cohesiveness

16 Sept 2010


INTRODUCTION TOCOMPONENT-BASED DESIGN

16 Sept 2010


COMPONENT-BASED DESIGN

Component-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 board

16 Sept 2010


COMPONENT-BASED DESIGN

Component-Based Design ConceptsModularityReusabilityCompositionEncapsulation• Separation Of Concerns• Cohesiveness

16 Sept 2010


COMBINING APPROACHES

Using Domain-Driven Design within a component

To create domain model and logicBounded ContextsAnti-Corruption layersImprove communication with UL

16 Sept 2010


COMBINING APPROACHES

Using Component-Based design to achieve

ModularityCompositionEncapsulation and Decoupling• The component defines a bounded context• Enables us to focus on one problem at a

time

16 Sept 2010


SOFTWARE CELLS

16 Sept 2010

Presentation

Domain Model

Data Access

Presentation

Domain Model

Data Access

Presentation

Domain Model

Data Access

Presentation

Domain Model

Data Access

Presentation

Domain Model

Data Access

Presentation

Domain Model

Data Access

is composed of


CODING PRACTICES

16 Sept 2010


TEST-DRIVEN DEVELOPMENT

Test-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 tested

16 Sept 2010


BEHAVIOR-DRIVEN DEVELOPMENT

Behavior-Driven DevelopmentGet business specialists involved in testing!Focuses on collaboration between developers, quality assurance and business usersMight be used for User Acceptance testing

16 Sept 2010


VERSION CONTROL & CONTINUOUS INTEGRATION

Version 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 Regression

16 Sept 2010


REFACTORING

RefactoringImprove 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 change

16 Sept 2010


DECOUPLING

DecouplingHow?• Inversion of control• Dependency Injection • Encapsulation

Helps with• Modularity• Extensibility• Maintainability• Testability

16 Sept 2010


DESIGN PATTERNS

Design PatternsDo not re-invent the wheelDesign Patterns provide solutions for common problemsDomain-Driven Design defines a set of architectural patterns

16 Sept 2010


DEMO

16 Sept 2010


QUESTIONS

Intentionally Blank(ish)

16 Sept 2010

45

RESOURCES

Agile Partner: www.agilepartner.net Agile Partner blog: blog.agilepartner.net

Agile Interest Group Luxembourg: www.aiglu.org

Agile Alliance: www.agilealliance.org Scrum alliance: www.scrumalliance.org Scrum.org16 Sept 2010 Agile Mëtteg - Agile architecture

http://www.agilepartner.net/

http://www.aiglu.org/

http://www.agilealliance.org/

http://www.scrumalliance.org/

http://www.scrum.org/

Agile Mëtteg - Continuous improvement in practice

46

NEXT TRAININGS & CERTIFICATIONS

Certifications Duration Date Status

Certified Scrum Master 2 days 20 April Done

Certified Scrum Product Owner

2 days 16 November

Planned

June 17th, 2010

Courses Duration

Sept. Oct. Nov.

Agile methods 1 day 13 11 08Scrum 2 days 14 12 09Scrum in practice 3 days 16 14 11TDD in Java 3 days - 04 -Software factory 3 days - 25 -iPhone development 5 days - - 22Business modeling with UML

3 days - - 08

Complete calendar on: http://www.agilepartner.net/training/

http://www.agilepartner.net/training/

47

CONTACTS

Thank You

16 Sept 2010 Agile Mëtteg - Agile architecture

JohannesTäuber

Software Architect / CSM

[email protected]

http://www.taeuber.org

mailto:[email protected]

mailto:[email protected]

agile mëtteg series session 7

Technology