agile mëtteg series - session 3

Agile Mëtteg – 20 May 2010Agile architecture & programming

2

OBJECTIVES

Understand the implications of agile development on architecture, design and coding practices

Explain some misbelieves about software architecture and agility

20 May 2010 Agile Mëtteg – Agile architecture

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…)

20 May 2010 Agile Mëtteg - Agile architecture 3

IS users

Services

Software

Development

& Softwa

reMaintenance

ISSolutions

IS Services

1 23

4

1

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

Agile Mëtteg - Agile architecture 4

WHO’S WHO

Who are we ?

What is our role in our organization ?

What are our expectations from this seminar ?

20 May 2010

5

AGENDA

AgendaCan Enterprise Architecture be Agile ?Misbelieves about architecture and agilityWhy Up Front Design doesn’t always work ?Emerging architectures and evolutionary designCoding practicesSo is Design dead ?

20 May 2010 Agile Mëtteg - Agile architecture


ARCHITECTURE ? WHICH ONE ?

Architecture: very contextual activityEnterprise architecture

Software architectureTechnical architectureEtc.

20 May 2010


CAN ENTERPRISE ARCHITECTURE BE AGILE ?

20 May 2010


CAN EA BE AGILE ?

Enterprise architecture:Vision, principles, standards, roadmap

Enterprise architecture frameworks:TOGAF 9, Zachman framework, …Define extensively structure and modelsUse them as guides, not as rulesBeware of over-documentation

20 May 2010


CAN EA BE AGILE ?

20 May 2010

Example: Zachman framework


CAN EA BE AGILE ?

Example: Zachman framework

20 May 2010

EA Armory ;)Choose one or two weapon(s)Use Agile modeling (JIT Modeling)Helps to structureLeave no stone unturnedDO NOT TRY AND IMPLEMENT EVERYTHING!!!!


MISBELIEVES ABOUT SOFTWARE ARCHITECTURE AND AGILITY

20 May 2010

12

MISBELIEVES ON ARCHITECTURE

You have to know precisely what to build before you can start building it.

Building software is like construction building


13

MISBELIEVES ON AGILITY

No architectureCode and fix nightmareCowboy codingOnly works forsmall projects



WHY UP FRONT DESIGN DOESN’T ALWAYS WORK ?

20 May 2010


Traditional / Waterfall approachDesign is done up frontBig Design Up Front = BDUF

Requirements Analysis Design Developmen

t Test Release

WHEN DO YOU DESIGN ?

20 May 2010


IS THAT THE RIGHT APPROACH ?

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” [D.Eisenhower]

20 May 2010

17

WHAT DO AGILISTS SAY ?

“Design is there to enable you to keep changing the software easily in the long term.” [Kent Beck]

Source : http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx



WHAT DO AGILISTS SAY ?

“eXtreme Programming recognizes the importance of design decisions, but it strongly resists upfront design. Instead, it puts and admirable effort into communication and improving the projects ability to change course rapidly” [Eric Evans, DDD]

20 May 2010

19

BDUF NOT ALWAYS WORKING ?

You cannot foresee the future

Requirements changeArchitecture documents are not carved in stone




The « Architect » in his Ivory Tower

Architects far from teamsDevelopers kept out of architecture definitionFrustrated teams ignore / bypass the model

20 May 2010



20 May 2010

Ever heard about over design ?


OVER DESIGN CONSEQUENCES

Lack of FlexibilityAdaptabilityExtensibility

20 May 2010

Effect on CostROITime to market


EMERGING ARCHITECTURES AND EVOLUTIONARY DESIGN

20 May 2010


Requirements Analysis Design Developmen

t Test Release

Waterfall approachDesign is done up front


20 May 2010


Agile approachDesign is part of the development process


20 May 2010

Iteration 1

Requirements

Analysis

Design

Development

Test

Release

Iteration 2

Requirements

Analysis

Design

Development

Test

Release

Iteration n

Requirements

Analysis

Design

Development

Test

Release

No specific order

Agile Mëtteg - Agile architecture 2620 May 2010

How would you eat this cake ?

LAYERED CAKE


ARCHITECTURE

Iteration n

LAYERED CAKE

20 May 2010

Iteration 3

Iteration 2

Iteration 1

Data base

Data Access Layer

Business Layer

Application Layer

User Interface


ABOUT EMERGENCE

Tobias MayerEmergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work.

They will not become clear if we simply talk about them. Big Up Front Design might result in Big Wrong Design or at best Big Working But Totally Inflexible Design.

When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface.

Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.

20 May 2010


ABOUT EMERGENCE

Tobias MayerEmergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work.

They will not become clear if we simply talk about them. Big Up Front Design might result in Big Wrong Design or at best Big Working But Totally Inflexible Design.

When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface.

Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.

20 May 2010

Emergence

Empirical approach

As we work

Simple and

appropriate

Current context Flexible


HOW DOES IT START ?

It all started with a visionInitial architecture envisionning

20 May 2010


AGILE MODELING

20 May 2010

Source : http://www.agilemodeling.com/essays/initialArchitectureModeling.htm

Envisioning

JIT modeling / design

Coding practices


DESIGN DURING DEVELOPMENT

eXtreme ProgrammingIteration 0• "The first iteration must be a functioning

skeleton of the system as a whole.“ [Kent Beck]

• System metaphor

Following iterations• Spike solution• Proof of concept

20 May 2010


DESIGN DURING DEVELOPMENT

Domain Driven Design (Eric Evans)Just in time modelingUbiquitous language (cf System Metaphor)

20 May 2010


VALUES OF AGILE ARCHITECTURE

20 May 2010

Simplicity•Consider the simplest thing that could

possibly work•YAGNI (You Ain’t Gonna Need It)•Once and only once

Courage•Throw away what is not needed•Change what is not adapted anymore

Flexibility and extensibility•Single Responsibility Principle (SRP)•Open / Closed Principle (OCP)•Dependency Injection

Testability•Run all tests often•Reveal all the intention•No duplication•Fewest number of classes and methods


CODING PRACTICES

20 May 2010


PRACTICES

Test Driven DevelopmentBehavior Driven DevelopmentRefactoringContinuous integration

20 May 2010


TEST DRIVEN DEVELOPMENT (TDD)

Make it break write the test first

Make it pass write the simplest implementation

Make it right refactor without changing the behavior

20 May 2010

Test

CodeRefactor


TDD EXAMPLE

FizzBuzz KataMultiple of 3 FizzMultiple of 7 BuzzMultiple of 3 and 7 FizzBuzz

20 May 2010

Source : http://www.viddler.com/explore/Lostechies/videos/1/

http://www.viddler.com/explore/Lostechies/videos/1/


BEHAVIOR DRIVEN DEVELOPMENT

20 May 2010

As a •Who

customer

I want to

•Whatwithdraw cash from an ATM

So that

•WhyI don’t have to wait in line at the bank

User stories


BDD : EXECUTABLE SPECIFICATIONS

Scenario : Account is in credit

20 May 2010

Given

•Some initial contextthe account is in credit AND the card is valid

When

•An event occursthe customer requests cash

Then

•Ensure some outcomesensure cash is debited AND ensure the cash is dispensed AND ensure the card is returned


REFACTORING

Refactoring Change “How” not “What”Pay your technical debt

Use of patternsRefactor towards patterns only when neededLeverage ubiquitous language

20 May 2010


CONTINUOUS INTEGRATION

Your product builds at any timeRun the tests oftenEase deployment

20 May 2010

Watch code

Build product

Run tests

Publish results


SO IS DESIGN DEAD ?

20 May 2010


SO IS DESIGN DEAD ?

“Not by any means, but the nature of design has changed.” [Martin Fowler]

Keep code as clean and simple as possible.Refactor to confidently make improvements.Use design patterns when needed.Communicate the design using code, diagrams and above all conversation.

20 May 2010


EMPHASIZED COMMUNICATION

20 May 2010


AGILE ARCHITECTURE MANIFESTO ?

Business focusEmergenceSimplicityExtensibility

20 May 2010

Technical perfectionUp front designExcessive designOmnipotence

47

QUESTIONS

Agile Mëtteg - Agile architecture20 May 2010

48

Certifications Duration Date

Certified Scrum Product Owner

2 days 16 Nov. 2010

Certified Scrum Master 2 days 2011 (TBD)

NEXT TRAININGS & CERTIFICATIONS

Courses Duration

May June July

Agile methods 1 day 17 1 12

Scrum 2 days 18 2 13

eXtreme Programming

2 days 6 - 8

Scrum Advanced 1 day 20 4 15

Scrum Product Owner

2 days - - 1


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

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

49

RESOURCES

Agile Partner: www.agilepartner.net

Agile Interest Group Luxembourg: www.aiglu.org

Agile Alliance: www.agilealliance.org Scrum alliance: www.scrumalliance.org Scrum.org


http://www.agilepartner.net/

http://www.aiglu.org/

http://www.agilealliance.org/

http://www.scrumalliance.org/

http://www.scrum.org/

50

CONTACTS

Thank You


Pierre-Antoine GREGOIRE

Cédric PONTET

IT Architect / CSM .Net Architect / [email protected]

[email protected]

mailto:[email protected]




agile mëtteg series - session 3

Technology

agile mtteg agile architecture

design dead

design doesntalwayswork

building software

zachman framework20

team assessment

resource delegation20

emerging architectures