BTS530: Major Project Planning and Design Iterative Development References: Agile & Iterative Development, by Craig Larman, 2004, Addison Wesley. Agile & Iterative Development, by Craig Larman, 2004, Addison Wesley. Applying UML and Patterns, 3 rd Edition, Chapter 21, Craig Larman Applying UML and Patterns, 3 rd Edition, Chapter 21, Craig Larman Web sites as listed Web sites as listed

Agenda Iterative development Iterative development Agile modeling Agile modeling SCRUM SCRUM Extreme Programming Extreme Programming Refactoring Refactoring

Iterative Development Product development lifecycle is composed of several iterations in sequence, each delivering a “chunk” of functionality Product development lifecycle is composed of several iterations in sequence, each delivering a “chunk” of functionality Each iteration is a self-contained mini project: Each iteration is a self-contained mini project: Planning Planning Development (including testing) Development (including testing) Implementation Implementation Review/Refactoring Review/Refactoring

Iterative Development Iteration 1 + Feedback/Input from Iterations Production System (grows with each iteration) Initial Requirements, Vision Iteration 2 Iteration 3 … (Typically between 3 and 30 iterations in a system development project)

Iterative Development Each Iteration Each Iteration Plan Plan tasks, time estimates, milestones tasks, time estimates, milestones Track/Control progress Track/Control progress adjust scope if required adjust scope if required Develop Develop Implement Implement Review/Refactor Review/Refactor

Iterative Development Planning Each Iteration Planning Each Iteration Risk driven Risk driven choose riskiest, most difficult elements choose riskiest, most difficult elements Client driven Client driven choose highest business value choose highest business value Ideally—a mixture of both Ideally—a mixture of both

Iterative Development Tracking/Controlling Tracking/Controlling Timeframes for iterations are typically shorter than for traditionally run projects, necessitating more control Timeframes for iterations are typically shorter than for traditionally run projects, necessitating more control “Timeboxing” Approach is common in iterative development methodologies using agile methods “Timeboxing” Approach is common in iterative development methodologies using agile methods Iterations typically 1 to 6 weeks Iterations typically 1 to 6 weeks Scope adjusted if necessary; not time, not quality Scope adjusted if necessary; not time, not quality

Iterative Development Benefits over “Big Bang” approaches Benefits over “Big Bang” approaches “Depth” vs “breadth” – issues through to implementation uncovered and addressed more quickly “Depth” vs “breadth” – issues through to implementation uncovered and addressed more quickly Early results reveal and enable required changes— end product is more suitable Early results reveal and enable required changes— end product is more suitable Early results enable more accurate estimates for the rest of the system Early results enable more accurate estimates for the rest of the system Momentum sustained…constant visible progress Momentum sustained…constant visible progress Other? Other?

Agile Methods Iterative methods typically (but not always) employ agile methods Iterative methods typically (but not always) employ agile methods Agile methods defined and supported by Agile methods defined and supported by Agile methods start with the “Manifesto for Agile Software Development” Agile methods start with the “Manifesto for Agile Software Development”

Agile Methods Principles Principles

Agile Methods Iterative development methodologies employing agile methods include: Iterative development methodologies employing agile methods include: Scrum Scrum Extreme Programming (XP) Extreme Programming (XP)

SCRUM: Intro An agile method for software development. An agile method for software development. Projects progress via a series of iterations called sprints. Projects progress via a series of iterations called sprints. Each sprint iteration is approx. 2-4 weeks long. Each sprint iteration is approx. 2-4 weeks long. Ideally suited to projects with rapidly changing or “sudden” requirements. Ideally suited to projects with rapidly changing or “sudden” requirements. Mountain Goat Software

SCRUM: the players Mountain Goat Software Scrum Team people --no traditional roles --All working together Key Stakeholder or user Ensures team productivity by removing roadblocks and protecting the team from the “outside”

SCRUM Product Backlog: a prioritized list of features containing every desired feature or change to the product. Prioritized by the product owner. Mountain Goat Software

SCRUM A Sprint Planning Meeting is held at the start of each sprint. The product owner reprioritizes the product backlog and the scrum team decides what it can complete in the coming Sprint. The result is the Sprint Backlog a list of tasks to complete all work in the current sprint.

SCRUM Mountain Goat Software The Scrum: a daily meeting for entire Scrum team: Scrum Master asks “What did you do yesterday?”; “What will you do today?”; “Are there any roadblocks?”

SCRUM Mountain Goat Software Product Increment (working, high- quality software) 2-4 Week Sprint Scrum Sprint Backlog Product Backlog At the end of a sprint the team has a Sprint Review Meeting to demonstrate the result of the sprint: a Product Increment.

XP: Intro A form of agile software development. A form of agile software development. Promotes simplicity and agility Promotes simplicity and agility Managers, customers, developers are equal partners in the development team Managers, customers, developers are equal partners in the development team

XP: Specifications User Stories are at the heart of XP User Stories are at the heart of XP They are written by the customers, are each about 2-3 sentences long and are similar to scenarios. They are written by the customers, are each about 2-3 sentences long and are similar to scenarios. User stories drive acceptance tests User stories drive acceptance tests User stories are the “specs” User stories are the “specs”

XP: Iterations A Release Planning Meeting creates a release plan which details which user stories will go into a release (80 + or – 20 is the “norm”) A Release Planning Meeting creates a release plan which details which user stories will go into a release (80 + or – 20 is the “norm”) An Iteration Planning Meeting is held at the start of each Iteration in the release to decide what will go into that iteration An Iteration Planning Meeting is held at the start of each Iteration in the release to decide what will go into that iteration Each “time boxed” iteration is usually a constant length; typically 1-3 weeks. Each “time boxed” iteration is usually a constant length; typically 1-3 weeks.

XP: Meetings Daily Standup Meeting is used to communicate problems, solutions, and promote team focus Daily Standup Meeting is used to communicate problems, solutions, and promote team focus Everyone stands up in a circle to avoid long discussions Everyone stands up in a circle to avoid long discussions

XP: Coding Coding done in pairs: Pair Programming Coding done in pairs: Pair Programming The customer is ALWAYS available The customer is ALWAYS available Coding Standards must be followed Coding Standards must be followed Test Driven Development: The Unit Test is written first Test Driven Development: The Unit Test is written first Code is integrated at frequent (hours) intervals Code is integrated at frequent (hours) intervals No overtime No overtime Code is Refactored frequently Code is Refactored frequently

Refactoring: Intro Part of each iteration – review and refactor what is “smelly” Part of each iteration – review and refactor what is “smelly” Simplify! Simplify!

Refactoring Structured, disciplined Structured, disciplined Rewrite/restructure existing code without changing its external behaviour Rewrite/restructure existing code without changing its external behaviour Apply small transformation steps combined with re-executing test steps Apply small transformation steps combined with re-executing test steps

Refactoring Why? Why? remove duplicate code remove duplicate code improve clarity improve clarity shorten long methods shorten long methods remove “hard coded” constraints remove “hard coded” constraints “smelly code” –consider refactoring “smelly code” –consider refactoring “code stench” – MUST refactor “code stench” – MUST refactor

Refactoring Code Stench Code Stench duplicated code duplicated code BIG GIANT METHOD BIG GIANT METHOD BIG GIANT CLASS (lots of code) BIG GIANT CLASS (lots of code) Class with MANY instance variables Class with MANY instance variables strikingly similar subclasses strikingly similar subclasses little or no use of interfaces in the design little or no use of interfaces in the design high coupling between many objects high coupling between many objects and so on… and so on…

Sample Refactorings RefactoringDescription Extract Method transform long method into shorter one by farming out a portion to a helper method Extract Constant replace literal constant with constant variable Introduce Explaining Variable put the result of the expression into a temporary variable with a name that explains the purpose Replace Constructor Call With Factory Method For example—in Java, replace using the new operator and constructor call with invoking a helper method that creates the object (hiding the details)

Refactoring Examples: pg , chapter 21, Larman text Examples: pg , chapter 21, Larman text Resources Resources