1. Agile Software Developmentmaking programming fun again

2. How Projects Really WorkSoftware engineering done right. 3. How the customer explained itSoftware engineering done right. 4. How the project leader understood itSoftware engineering done right. 5. How the analyst designed itSoftware engineering done right. 6. How the programmer wrote itSoftware engineering done right. 7. How the business consultant described itSoftware engineering done right. 8. How the project was documentedSoftware engineering done right. 9. How much the project costSoftware engineering done right. 10. What the customer really neededSoftware engineering done right. 11. CHAOS Report by Standish GroupSoftware engineering done right. 12. Challenged Projects - Reasons Lack of User Input Technology Incomplete IncompetenceRequirements & Lack of ResourcesSpecifications Unrealistic Expectations Changing Requirements Unclear Objectives& Specifications Unrealistic Time Frames Lack of Executive New TechnologySupportSoftware engineering done right. 13. Failed Projects - Reasons Incomplete Changing RequirementsRequirements & Specifications Lack of User Lack of PlanningInvolvement Didnt Need It Any Lack of ResourcesLonger Unrealistic Expectations Lack of IT Management Lack of Executive Technology IlliteracySupportSoftware engineering done right. 14. Successful Projects - Reasons User involvement Project manager Executive management expertisesupport Financial management Clear business Skilled resourcesobjectives Formal methodology Optimizing scope Standard tools and Agile processmethodologySoftware engineering done right. 15. Whats wrong with Waterfall?Software engineering done right. 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. 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. 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 onthe left more.Software engineering done right. 19. Selected Practices Iterative Development User Stories Test-Driven Development One Team Self-Managed Teams Sustainable PaceSoftware engineering done right. 20. Iterative Development Software development as an evolutionary processSoftware engineering done right. 21. Iterative Development All steps of SDLC are done at each iterationSoftware engineering done right. 22. Iterative Development Working software produced at each iteration No such thing as X% complete, only done and not doneSoftware engineering done right. 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. User Stories Traditional requirements: The system shall... the system shall...Software engineering done right. 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 ofcommunicationSoftware engineering done right. 26. Test-Driven Development Bugs are harder to findand fix when found later Modifying code tends tointroduce bugs - Difficult to know if one has introduced bugs without tests Manual tests areexpensive to repeat andprovide limitedinformationSoftware engineering done right. 27. Test-Driven Development Programmers should write automated tests as theycode - Write test before implementation Provides immediate feedback if their code works Builds suite of automated tests that can be run eachtime code is modified Makes it safe to modify existing code Frameworks: JUnit, NUnit, hundreds of others...Software engineering done right. 28. Software engineering done right. 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. One Team Everyone is consideredpart of one team,including the customer Developers, testers,business analysts,project managers, webdesigners, etc, work inthe same place, placeusually on the sametableSoftware engineering done right. 31. Software engineering done right. 32. One Team Faster communication Issues resolved faster Natural communication Face-to-face, ad hoc and continuous throughout theday Less misunderstanding and antagonism between functional groupsSoftware engineering done right. 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. Self-Managed Teams Practices/Tools Daily Stand-Up Meetings Retrospectives Big Visible Charts, Whiteboards Direct access to customersSoftware engineering done right. 35. Sustainable Pace Overtime leads tolower productivity Lowers moraleSoftware engineering done right. 36. Sustainable Pace Team should measure velocity at each iteration Keep work load within velocity If iteration load was underestimated, ask customerto decide which features to move to future iterationsSoftware engineering done right. 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. 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 andpractices Scrum, TDD, Agile Business Analysis, Agile QA, etc Trainers are seasoned practictionersSoftware engineering done right. 39. Open WorkspacesSoftware engineering done right. 40. Project AutomationSoftware engineering done right. 41. Collaborative DesignSoftware engineering done right. 42. Agile TrainingSoftware engineering done right.