Agile Development Chapter 10 - part 2

Agile Philosophy  A guiding philosophy and set of guidelines for : developing information systems in an unknown, rapidly changing environment − complements Adaptive SDLCs & Methodologies − makes sure developers are fast to respond to changes “Manifesto for Agile Development”  agilemanifesto.org − Value responding to change over following a plan − Value individuals and interactions over processes and tools − Value working software over comprehensive documentation − Value customer collaboration over contract negotiation

Agile Methodologies  These are complete adaptive development methodologies that incorporate Agile principles: Unified Process Extreme Programming Scrum 3

Unified Process (UP)  Object- Oriented systems development methodology Invented by 3 Amigos: − Grady Booch, James Rumbaugh, & Ivar Jacobson Rational Software, which is now owned by IBM Also, invented UML 4

Unified Process (UP)  4 Phases  Phases are made up of iterations 5 InceptionElaborationConstructionTransition A&D and Implementation of Core Reqs -Use Cases Design & Implementation of Tech, Perf, Reliability of each use case o Data validation o Data maint. o Help o User preferences Scope & Prelim est. User acceptance testing Preparing for & deploying InceptionElaborationConstructionTransition Each phase can consist of one or more iterations.

Unified Process (UP) 6 9 Disciplines Incep- tion ElaborationConstruction Transi- tion Business Modeling Requirements Design Implementation Testing Deployment Configuration & change Project management Environment System Development Project Management

Extreme Programming (XP)  XP An iterative and incremental agile SW development methodology − With frequent releases in short development cycles − Main Concepts: 4 Core Values 12 Software Engineering Practices extends these “to the extreme” Emphasizes Software quality 7 Open & frequent Keep it simple From Client, users, developers Courage to do it right; re-do if necessary 4 Core Values

XP's 12 Software Engineering Practices  Planning – quick rough plan; develop user stories; heavily involve users  Testing – "user stories" tests written before coding; can be re-run anytime  Test-Driven Development & Automated Testing  Pair Programming – one writes, one inspects, trade turns  Simple Designs – few classes & methods, no duplicate code  Refactoring – improving code quality without changing what it does  Owning Code Collectively – allows anyone to improve code  Continuous integration – unit-tested code is integrated daily  On-site customer – customer must commit to the project  System metaphor –have an easily-understood vision in laymen's terms – e.g. assembly line  Small Releases – small & frequent deployment  40-Hour Work Week – don’t overload the developers  Coding standards – follow standards 8

XP Project Approach  Outer layer – 1x per PROJECT Create all user stories − Create class diagrams to support each Create system metaphor Create all acceptance tests Plan all releases − Each release has certain user stories Loop thru each RELEASE (Middle Layer)  Middle Layer – 1x per RELEASE Plan all iterations Loop thru each ITERATION (Inner Layer) Acceptance testing (of the Release) Finish -> Deploy the Release!  Inner Layer – 1x per ITERATION Code & unit test (each user story) Integration testing (for all user stories in Iteration) 9 1x per PROJECT 1x per RELEASE 1x per ITERATION Project ends when the final release is completed!

Scrum  Scrum An iterative and incremental agile SW development methodology − With frequent releases in short development cycles − Main Concepts: Team has complete control over organization & work processes Product Backlog - Prioritized list of user requirements Organization Product Owner - client stakeholder who controls the Product Backlog Scrum Master - Scrum project manager a facilitator, removes impediments, resolves issues However, the Scrum Team does the schedule Development Team - 5 to 9 developers Small self-organizing teams; have all the skills necessary Only they ultimately decide what goes in a Sprint Can have more than 1 team in larger projects 10

Scrum Sprint  Sprint - A time-controlled mini-project to implement part of the system Scope is frozen (but can be reduced) Time period is kept constant 11 Sprint Planning Meeting Sprint Review Sprint Retrospective Daily Scrum In Progress DoneTo Do Task Board

Scrum Meetings  All attended by: Scrum Master, Development Team, Product Owner  Time: assumptions are for a 1-month sprint  Sprint Planning - 8 hours before the Sprint Purpose: Creating of the Sprint Backlog − Finalizes the user stories they will work on & all the tasks − Product Owner attends to explain User Stories; Team gets to say if there are detail lacking & cant work on certain user stories yet  Daily Scrum (aka Stand-Up) - 15 beg of day Purpose: Daily status update between the development team − Yesterday − Today − Barriers  Sprint Review (aka Demo) – 4 hours at the end of the Sprint Purpose: a demo; additions to product backlog may be identified − Product Owner was part of the sprint so it isn't an approval meeting Also Attended by: stakeholders, management and developers from other teams  Sprint Retrospective - 3-hours at the end of the Sprint Purpose: process improvement - lessons learned, successes and failure 12

XP vs Scrum XPScrum Work Units  Iterations; 1-2 weeks  Sprints; 2-4 weeks Rate of Change  Can add a feature of equal size (for an unstarted feature within an iteration)  No changes allowed once sprint has started (i.e. to the sprint backlog) but can remove a feature Order of Features within an iteration  Features prioritized by the customer  Must work on features in order!  Features prioritized by the Scrum product owner  Team determines the sequence (but typically works on priority) SW Engineering Practices  12 Principles: test-driven development, pair programming, etc.  No engineering practices prescribed 13