Your SlideShare is downloading. ×
Agile Mëtteg series - Session 3
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Mëtteg series - Session 3

2,433
views

Published on

Agile architecture & programming …

Agile architecture & programming
20 May 2010

Published in: Technology, News & Politics

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,433
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
45
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • SCH
  • SCH
  • CPO & PAG
  • CPO
  • CPO
  • PAG
  • PAG
  • PAG
  • PAG
  • CPO
  • CPO
  • CPO
  • PAG
  • PAG
  • PAG
  • PAG
  • PAG
  • CPO
  • CPO - Parler du « rôle » de cet architecte 
  • CPO
  • CPO
  • PAG
  • PAG
  • PAG
  • CPO
  • CPO
  • CPO
  • CPO
  • PAG
  • PAG
  • PAG
  • PAG
  • CPO
  • CPO
  • CPO
  • CPO
  • CPO
  • CPO
  • CPO
  • PAG
  • PAG – Enchainement « Is Design Dead ? »
  • PAG
  • PAG
  • PAG
  • CPO
  • CPO
  • Transcript

    • 1. Agile architecture & programming
      Agile Mëtteg – 20 May 2010
    • 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
      2
      Agile Mëtteg – Agile architecture
    • 3. AGILE PARTNER SERVICES
      Custom Software Development & Maintenance
      Our core business to answer customer needs
      IS services
      Thanks to our expertise we can support IT team to reach their productivity & quality objectives (Assessment, Coaching, Support, Training, Resource delegation…)
      IS Solutions
      Take benefit from commercial or Open Source platform to answer as quick as possible to specific needs
      IS users services
      We 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
      1
      4
      Software Development & SoftwareMaintenance
      2
      ISSolutions
      IS Services
      Agility
      Agility
      3
      1
      2
      3
      4
      Agility
    • 4. WHO’S WHO
      Who are we ?
      Whatisourrole in ourorganization ?
      What are our expectations fromthisseminar ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      4
    • 5. AGENDA
      Agenda
      Can Enterprise Architecture be Agile ?
      Misbelieves about architecture and agility
      Why Up Front Design doesn’t always work ?
      Emerging architectures and evolutionary design
      Coding practices
      So is Design dead ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      5
    • 6. ARCHITECTURE ? WHICH ONE ?
      Architecture: very contextual activity
      Enterprisearchitecture
      Software architecture
      Technical architecture
      Etc.
      20 May 2010
      Agile Mëtteg - Agile architecture
      6
    • 7. Can Enterprise Architecture be Agile ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      7
    • 8. CAN EA BE AGILE ?
      Enterprise architecture:
      Vision, principles, standards, roadmap
      Enterprise architecture frameworks:
      TOGAF 9, Zachman framework, …
      Define extensively structure and models
      Use them as guides, not as rules
      Beware of over-documentation
      20 May 2010
      Agile Mëtteg - Agile architecture
      8
    • 9. CAN EA BE AGILE ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      9
      Example: Zachman framework
    • 10. CAN EA BE AGILE ?
      Example: Zachman framework
      20 May 2010
      Agile Mëtteg - Agile architecture
      10
      EA Armory ;)
      Choose one or two weapon(s)
      Use Agile modeling (JIT Modeling)
      Helps to structure
      Leave no stone unturned
      DO NOT TRY AND IMPLEMENT EVERYTHING!!!!
    • 11. Misbelieves about SOFTWARE architecture and agility
      20 May 2010
      Agile Mëtteg - Agile architecture
      11
    • 12. MISBELIEVES ON ARCHITECTURE
      You have to know precisely what to build before you can start building it.
      Building software is like construction building
      20 May 2010
      Agile Mëtteg - Agile architecture
      12
    • 13. MISBELIEVES ON AGILITY
      No architecture
      Code and fix nightmare
      Cowboy coding
      Onlyworks forsmallprojects
      20 May 2010
      Agile Mëtteg - Agile architecture
      13
    • 14. Why up front design doesn’talwayswork ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      14
    • 15. Traditional / Waterfallapproach
      Design isdoneup front
      BigDesign Up Front = BDUF
      WHEN DO YOU DESIGN ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      15
    • 16. IS THAT THE RIGHT APPROACH ?
      “In preparing for battle I have always found that plans are useless, but planningis indispensable.”
      [D.Eisenhower]
      20 May 2010
      Agile Mëtteg - Agile architecture
      16
    • 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
      20 May 2010
      Agile Mëtteg - Agile architecture
      17
    • 18. 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 changecourse rapidly”
      [Eric Evans, DDD]
      20 May 2010
      Agile Mëtteg - Agile architecture
      18
    • 19. BDUF NOT ALWAYS WORKING ?
      You cannot foresee the future
      Requirements change
      Architecture documents are not carved in stone
      20 May 2010
      Agile Mëtteg - Agile architecture
      19
    • 20. BDUF NOT ALWAYS WORKING ?
      The « Architect » in hisIvoryTower
      Architects far from teams
      Developers kept out of architecture definition
      Frustrated teams ignore / bypass the model
      20 May 2010
      Agile Mëtteg - Agile architecture
      20
    • 21. BDUF NOT ALWAYS WORKING ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      21
      Everheard about over design ?
    • 22. OVER DESIGN CONSEQUENCES
      Lack of
      Flexibility
      Adaptability
      Extensibility
      20 May 2010
      Agile Mëtteg - Agile architecture
      22
      Effect on
      Cost
      ROI
      Time to market
    • 23. Emerging architectures and evolutionary design
      20 May 2010
      Agile Mëtteg - Agile architecture
      23
    • 24. Waterfallapproach
      Design isdoneup front
      WHEN DO YOU DESIGN ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      24
    • 25. Agile approach
      Design ispart of the developmentprocess
      WHEN DO YOU DESIGN ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      25
      Iteration 1
      Iteration 2
      Iteration n
      No specificorder
    • 26. 20 May 2010
      Agile Mëtteg - Agile architecture
      26
      How would you eat this cake ?
      LAYERED CAKE
    • 27. ARCHITECTURE
      LAYERED CAKE
      Iteration n
      20 May 2010
      Agile Mëtteg - Agile architecture
      27
      Iteration 3
      Iteration 2
      Iteration 1
    • 28. ABOUT EMERGENCE
      Tobias Mayer
      Emergence 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
      Agile Mëtteg - Agile architecture
      28
    • 29. ABOUT EMERGENCE
      Tobias Mayer
      Emergence 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
      Agile Mëtteg - Agile architecture
      29
    • 30. HOW DOES IT START ?
      It all startedwith a vision
      Initial architecture envisionning
      20 May 2010
      Agile Mëtteg - Agile architecture
      30
    • 31. AGILE MODELING
      20 May 2010
      Agile Mëtteg - Agile architecture
      31
      JIT modeling / design
      Coding practices
      Envisioning
      Source : http://www.agilemodeling.com/essays/initialArchitectureModeling.htm
    • 32. DESIGN DURING DEVELOPMENT
      eXtremeProgramming
      Iteration 0
      "The first iteration must be a functioning skeleton of the system as a whole.“ [Kent Beck]
      System metaphor
      Followingiterations
      Spike solution
      Proof of concept
      20 May 2010
      Agile Mëtteg - Agile architecture
      32
    • 33. DESIGN DURING DEVELOPMENT
      Domain Driven Design (Eric Evans)
      Just in time modeling
      Ubiquitouslanguage (cf System Metaphor)
      20 May 2010
      Agile Mëtteg - Agile architecture
      33
    • 34. VALUES OF AGILE ARCHITECTURE
      20 May 2010
      Agile Mëtteg - Agile architecture
      34
    • 35. Coding practices
      20 May 2010
      Agile Mëtteg - Agile architecture
      35
    • 36. PRACTICES
      Test DrivenDevelopment
      BehaviorDrivenDevelopment
      Refactoring
      Continuousintegration
      20 May 2010
      Agile Mëtteg - Agile architecture
      36
    • 37. TEST DRIVEN DEVELOPMENT (TDD)
      Makeit breakwrite the test first
      Makeitpasswrite the simplestimplementation
      Makeit right refactorwithoutchanging the behavior
      20 May 2010
      Agile Mëtteg - Agile architecture
      37
    • 38. TDD EXAMPLE
      FizzBuzz Kata
      Multiple of 3  Fizz
      Multiple of 7  Buzz
      Multiple of 3 and 7  FizzBuzz
      20 May 2010
      Agile Mëtteg - Agile architecture
      38
      Source : http://www.viddler.com/explore/Lostechies/videos/1/
    • 39. BEHAVIOR DRIVEN DEVELOPMENT
      20 May 2010
      Agile Mëtteg - Agile architecture
      39
      User stories
    • 40. BDD : EXECUTABLE SPECIFICATIONS
      Scenario : Accountis in credit
      20 May 2010
      Agile Mëtteg - Agile architecture
      40
    • 41. REFACTORING
      Refactoring
      Change “How” not “What”
      Pay your technical debt
      Use of patterns
      Refactor towards patterns only when needed
      Leverage ubiquitous language
      20 May 2010
      Agile Mëtteg - Agile architecture
      41
    • 42. CONTINUOUS INTEGRATION
      Your product builds at any time
      Run the tests often
      Ease deployment
      20 May 2010
      Agile Mëtteg - Agile architecture
      42
    • 43. So is design dead ?
      20 May 2010
      Agile Mëtteg - Agile architecture
      43
    • 44. 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.
      Refactorto confidently make improvements.
      Use design patterns when needed.
      Communicate the design using code, diagrams and above all conversation.
      20 May 2010
      Agile Mëtteg - Agile architecture
      44
    • 45. EMPHASIZED COMMUNICATION
      20 May 2010
      Agile Mëtteg - Agile architecture
      45
    • 46. AGILE ARCHITECTURE MANIFESTO ?
      Business focus
      Emergence
      Simplicity
      Extensibility
      20 May 2010
      Agile Mëtteg - Agile architecture
      46
      Technical perfection
      Up front design
      Excessive design
      Omnipotence
    • 47. QUESTIONS
      47
      Agile Mëtteg - Agile architecture
      20 May 2010
    • 48. NEXT TRAININGS & CERTIFICATIONS
      20 May 2010
      Agile Mëtteg - Agile architecture
      48
      Complete calendar on: 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
      20 May 2010
      Agile Mëtteg - Agile architecture
      49
    • 50. CONTACTS
      Thank You
      20 May 2010
      Agile Mëtteg - Agile architecture
      50