1. Agile Development Methodology Jeff Bollinger VP of Information Systems jeff.bollinger@w3i.com @Jbollinger www.jeffbollinger.net St. Cloud State University IS 350 10.13.2010
3. What’s a Development Methodology? A process or methodical approach to developing software. A repeatable process used to: Handle Requirements Improve Quality Manages Risk
6. Waterfall Works Well When… Requirements are stable Technology is well known and mature Everything happens as one would expect We are not taking on anything new or unknown We have done this many times before
7. Waterfall The Real World Requirements Change Design Implementation Takes too long Testing Gets skipped Deployment Maintenance
8. What is Agile? Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
9. 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 softwareover 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. http://agilemanifesto.org/
10.
11. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
12. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
13.
14. Agile Principles Simplicity--the art of maximizing the amount of work not done is essential. Continuous attention to technical excellence and good design enhances agility. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
19. Scrum Planning Meeting User Story Burndown Chart Epics Retrospective Review Meeting Story Points Estimating Tasks Backlog Velocity
20. User Stories A software requirement formulated as one or two sentences in the everyday business language of the user Format: As a (role) I want (something) so that (benefit) Example: As a customer service representative, I want to search for my customers by their first and last name, so that I can spend less time browsing lists.
21. Estimating A consensus-based estimation method Estimate effort or relative size of development tasks Estimate in Story Points Story points possibilities are 0,1,2,3,5,8,13
22. Velocity Number of story points completed in one sprint (iteration) Calculated by taking the last three sprint’s rolling average
23. Planning Meeting Approximately one day Includes Development Team and Business Owners Pull prioritized stories from the backlog and technically plan them Call in business owners to clarify requirements Database design – ERD API Specifications Break stories down into several tasks Commitment is made to Business Owners to deliver stories by end of the sprint
24. Daily Scrum Stand-up meeting Not longer than 15 minutes Each developer answers 3 questions: What did you work on yesterday? What are you going to work on today? What are your roadblocks, if any?
26. Sprint Reviews Occurs at the end of every sprint Business owners and Development Team are present Demonstration of working software is given by the development team
27. Retrospectives Learning Continuous Improvement Meeting with product management, team members, managers Discussion on successes and areas for improvement in the current sprint
