Agile Software Development - making programming fun again


Published on

Agile Software Development - making programming fun again

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Software Development - making programming fun again

  1. 1. Agile Software Development making programming fun again
  2. 2. How Projects Really WorkSoftware engineering done right.
  3. 3. How the customer explained itSoftware engineering done right.
  4. 4. How the project leader understood itSoftware engineering done right.
  5. 5. How the analyst designed itSoftware engineering done right.
  6. 6. How the programmer wrote itSoftware engineering done right.
  7. 7. How the business consultant described itSoftware engineering done right.
  8. 8. How the project was documentedSoftware engineering done right.
  9. 9. How much the project costSoftware engineering done right.
  10. 10. What the customer really neededSoftware engineering done right.
  11. 11. “CHAOS Report” by Standish GroupSoftware engineering done right.
  12. 12. Challenged Projects - Reasons  Lack of User Input  Technology  Incomplete Incompetence Requirements &  Lack of Resources Specifications  Unrealistic Expectations  Changing Requirements  Unclear Objectives & Specifications  Unrealistic Time Frames  Lack of Executive  New Technology SupportSoftware engineering done right.
  13. 13. Failed Projects - Reasons  Incomplete  Changing Requirements Requirements & Specifications  Lack of User  Lack of Planning Involvement  Didnt Need It Any  Lack of Resources Longer  Unrealistic Expectations  Lack of IT Management  Lack of Executive  Technology Illiteracy SupportSoftware engineering done right.
  14. 14. Successful Projects - Reasons  User involvement  Project manager  Executive management expertise support  Financial management  Clear business  Skilled resources objectives  Formal methodology  Optimizing scope  Standard tools and  Agile process methodologySoftware engineering done right.
  15. 15. Whats wrong with “Waterfall”?Software engineering done right.
  16. 16. Whats wrong with “Waterfall”?  Mistakes are hard to find in early stages  Expensive to fix mistakes in later stages  Customers dont know what they want from the beginning  Developers dont know how long a project will take from the beginning  Business needs changeSoftware engineering done right.
  17. 17. Effects of “Waterfall”  Death March projects ‒ Mis-estimated schedules lead to successive overtime ‒ Delays in one stage cause delays in succeeding stages  Conflict between customers and developers ‒ Customers dont get the software that they want ‒ Developers dont get clear requirements  Process and tool obsession ‒ People focus on creating artifacts but lose sight of the goal of working software ‒ Processes replace natural communicationSoftware engineering done right.
  18. 18. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.Software engineering done right.
  19. 19. Selected Practices  Iterative Development  User Stories  Test-Driven Development  One Team  Self-Managed Teams  Sustainable PaceSoftware engineering done right.
  20. 20. Iterative Development  Software development as an evolutionary processSoftware engineering done right.
  21. 21. Iterative Development  All steps of SDLC are done at each iterationSoftware engineering done right.
  22. 22. Iterative Development  Working software produced at each iteration – No such thing as “X% complete”, only done and not doneSoftware engineering done right.
  23. 23. Iterative Development  Benefits ‒ Customers can evaluate what they want and adjust requirements ‒ Developers get better estimates of future tasks ‒ Better communication between customer and developers and among developers  Talk is about something concrete, not abstract ‒ Just enough artifacts are created to produce working software  Less wasteSoftware engineering done right.
  24. 24. User Stories Traditional requirements: “The system shall... the system shall...”Software engineering done right.
  25. 25. User Stories As a < user role > In order to < business goal > I want to < behavior >  Focus on business goals - Requirements have context  Story-telling is the most natural way of communicationSoftware engineering done right.
  26. 26. Test-Driven Development  Bugs are harder to find and fix when found later  Modifying code tends to introduce bugs - Difficult to know if one has introduced bugs without tests  Manual tests are expensive to repeat and provide limited informationSoftware engineering done right.
  27. 27. Test-Driven Development  Programmers should write automated tests as they code - Write test before implementation  Provides immediate feedback if their code works  Builds suite of automated tests that can be run each time code is modified  Makes it safe to modify existing code  Frameworks: JUnit, NUnit, hundreds of others...Software engineering done right.
  28. 28. Software engineering done right.
  29. 29. TDD Benefits  Code is safe to modify  Tests are excellent documentation - Programmers hate writing documentation, but they like to code  Design improves - Programmers think of their codes behavior before coding - Programmers see their code from a second-persons point-of-view • Is my code readable? Easy to use? - Components become decoupled to facilitate testingSoftware engineering done right.
  30. 30. One Team  Everyone is considered part of one team, including the customer  Developers, testers, business analysts, project managers, web designers, etc, work in the same place, place usually on the same tableSoftware engineering done right.
  31. 31. Software engineering done right.
  32. 32. One Team  Faster communication – Issues resolved faster  Natural communication – Face-to-face, ad hoc and continuous throughout the day  Less misunderstanding and antagonism between functional groupsSoftware engineering done right.
  33. 33. Self-Managed Teams When teams manage themselves...  Higher motivation  More creative solutions  Faster resolution of issues  Drive for continuous improvementSoftware engineering done right.
  34. 34. Self-Managed Teams Practices/Tools  Daily Stand-Up Meetings  Retrospectives  Big Visible Charts, Whiteboards  Direct access to customersSoftware engineering done right.
  35. 35. Sustainable Pace  Overtime leads to lower productivity  Lowers moraleSoftware engineering done right.
  36. 36. Sustainable Pace  Team should measure “velocity” at each iteration  Keep work load within velocity  If iteration load was underestimated, ask customer to decide which features to move to future iterationsSoftware engineering done right.
  37. 37. Other Practices...  Planning  Tracking  Continuous Integration  Pair Programming  Refactoring  Planning Boards  Burn-Down Charts  Collective Code Ownership  Coding Standards Many more...Software engineering done right.
  38. 38. Agile at Orange & Bronze • Been doing Agile since its foundation in 2005 – Before it became mainstream • Weve tried different methodologies and practices – XP, Scrum, Kanban – Not all practices work in all conditions • The first to offer training in Agile methodologies and practices – Scrum, TDD, Agile Business Analysis, Agile QA, etc – Trainers are seasoned practictionersSoftware engineering done right.
  39. 39. Open WorkspacesSoftware engineering done right.
  40. 40. Project AutomationSoftware engineering done right.
  41. 41. Collaborative DesignSoftware engineering done right.
  42. 42. Agile TrainingSoftware engineering done right.