Download as ODP, PPTX
Uploaded byOrange and Bronze Software Labs
Agile Software Development - Making Programming Fun Again
The document discusses agile software development, emphasizing its advantages over traditional waterfall methods by highlighting user involvement, iterative processes, and test-driven development. It argues that successful projects feature clear business objectives, skilled resources, and effective communication among team members. Additionally, the document outlines common pitfalls in project management and provides practices for better software engineering outcomes.
Agile Software Development - Making Programming Fun Again
- 1. Agile Software Development making programming fun again
- 2. How Projects ReallyWork Software engineering done right.
- 3. How the customerexplained it Software engineering done right.
- 4. How the projectleader understood it Software engineering done right.
- 5. How the analystdesigned it Software engineering done right.
- 6. How the programmerwrote it Software engineering done right.
- 7. How the businessconsultant described it Software engineering done right.
- 8. How the projectwas documented Software engineering done right.
- 9. How much theproject cost Software engineering done right.
- 10. What the customerreally needed Software engineering done right.
- 11. “CHAOS Report” byStandish Group Software engineering done right.
- 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 Support Software engineering done right.
- 13. Failed Projects -Reasons Incomplete Changing Requirements Requirements & Specifications Lack of User Lack of Planning Involvement Didn't Need It Any Lack of Resources Longer Unrealistic Expectations Lack of IT Management Lack of Executive Technology Illiteracy Support Software engineering done right.
- 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 methodology Software engineering done right.
- 15. What's wrong with“Waterfall”? Software engineering done right.
- 16. What's wrong with“Waterfall”? Mistakes are hard to find in early stages Expensive to fix mistakes in later stages Customers don't know what they want from the beginning Developers don't know how long a project will take from the beginning Business needs change Software 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 don't get the software that they want ‒ Developers don't get clear requirements Process and tool obsession ‒ People focus on creating artifacts but lose sight of the goal of working software ‒ Processes replace natural communication Software 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 on the left more. Software engineering done right.
- 19. Selected Practices Iterative Development User Stories Test-Driven Development One Team Self-Managed Teams Sustainable Pace Software engineering done right.
- 20. Iterative Development Software development as an evolutionary process Software engineering done right.
- 21. Iterative Development All steps of SDLC are done at each iteration Software engineering done right.
- 22. Iterative Development Working software produced at each iteration – No such thing as “X% complete”, only done and not done Software 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 waste Software engineering done right.
- 24. User Stories Traditionalrequirements: “The system shall... the system shall...” Software engineering done right.
- 25. User Stories Asa < 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 communication Software engineering done right.
- 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 information Software engineering done right.
- 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.
- 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 code's behavior before coding - Programmers see their code from a second-person's point-of-view • Is my code readable? Easy to use? - Components become decoupled to facilitate testing Software engineering done right.
- 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 table Software engineering done right.
- 31.
- 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 groups Software engineering done right.
- 33. Self-Managed Teams Whenteams manage themselves... Higher motivation More creative solutions Faster resolution of issues Drive for continuous improvement Software engineering done right.
- 34. Self-Managed Teams Practices/Tools Daily Stand-Up Meetings Retrospectives Big Visible Charts, Whiteboards Direct access to customers Software engineering done right.
- 35. Sustainable Pace Overtime leads to lower productivity Lowers morale Software engineering done right.
- 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 iterations Software 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 • We've 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 practictioners Software engineering done right.
- 39. Open Workspaces Software engineeringdone right.
- 40. Project Automation Software engineeringdone right.
- 41. Collaborative Design Software engineeringdone right.
- 42. Agile Training Software engineeringdone right.