Z26 Project Management

Agile and Iterative Planning

Lecture 2a

Graham Collins, UCL

graham.collins@ucl.ac.uk

Phases of UPPhases of UP

Inception. Agreement on scope Elaboration. Vision, requirements and

architecture stabilized, build and test risky core several iterations

Construction. Build and test the rest, largest set of iterations

Transition. System deployed, beta testing, release evaluation, training

Useful websitesUseful websites

www.agilealliance.com www.agilemodelling.com www.martinfowler.com www.jimhighsmith.com www.alister.cockburn.com www.controlchaos.com www.dsdm.org www.rational.com

Further readingFurther reading

Kent Beck (2000), Extreme Programming explained:embrace change, Addison-Wesley ISBN 0-201-61641-6

Jim Highsmith (2002) Agile Software development Ecosystems, Addison-Wesley ISBN 0-201-76043-6

Paul Allen (2002), Realizing e-Business with Components, Addison-Wesley ISBN0-201-67520-X

Walker Royce (1998), Software Project Management: A Unified Framework, Addison-Wesley ISBN 0-201-30958-0

Ian Graham et al (1997) ,The OPEN Process Specification, Addison-Wesley ISBN0-201-33133-0

Murray Cantor (2002) Software Leadership: A Guide to Successful Software Development,Addison-Wesley, ISBN 0-201-70044-1

Philippe Kruchten (2000) The Rational Unified Process an Introduction, Second Edition, Addison-Wesley new edition being published

Ian Graham (1998), Requirements Engineering and Rapid Development: An object-Oriented Approach, Addison-Wesley ISBN 0-201-36047-0

Predictable projectsPredictable projects

Possible to complete specifications then build

Near start can estimate effort and cost Possible to define schedule and order

activities Adaptation to unpredictable change not

‘normal’

Innovative projectsInnovative projects

Cannot create upfront unchanging annd detailed specification

Only as empirical data emerges is it possible to plan and estimate

Adaptive steps driven by build-feedback cycles are required

Creative adaptation the norm.

Plan Driven ApproachesPlan Driven Approaches

Plan driven methods are considered the traditional way to develop software

Methods encourage a waterfall style approach

Requirements/design/build/test paradigm Well defined processes that

organisations continuously improve

Introduction of StandardsIntroduction of Standards

MIL-STD-1521 IBM Siemens

Often for internal use

Software EngineeringSoftware Engineering

Process discipline and structured techniques were developed

Fitted well with the concept of formal mathematical specification and verification

CharacteristicsCharacteristics

Well defined work products Verification and validation Although iterative and incremental

processes (evolutionary) processes have gained momentum, still a high documentation and traceability mandates across requirements, design and code

Process Improvement CycleProcess Improvement Cycle

Improve Process

Define Process

Control Process

Measure Process

Perform Process

Plan-driven ConceptsPlan-driven Concepts

Process improvement Process capability Organizational Maturity Process group Risk management Verification and validation Software systems architecture

Document generation rather than software developmentDocument generation rather than software development

‘Planning can cause problems. If too strictly applied, plans and processes can impede innovation or lead to mechanical check list mentality, where the object of the endeavor becomes so focused on the process that the product (often along with the customer) is afforded secondary status.

Barry Boehm & Richard Turner (2004), Balancing Agility and Discipline: A guide for the perplexed, Addison-Wesley

ISBN 0-321-18612-5

eXtreme programming (XP)eXtreme programming (XP)

Planning game Small frequent releases System metaphors Simple design Testing Frequent refactoring Pair programming Team code ownership Continuous integration Sustainable pace Whole team together Coding standards

Pair ProgrammingPair Programming

Study Effort Schedule Defect rate

Satisfaction Length (hrs)

Williams +15% -43% -60% High >10

Ciolkowski +9% -46% High 14

ScrumScrum

Self directed and self-organizing teams No external addition of workload to an

iteration Daily stand-up meetings 30 day iterations Client driven iterations with demo at end

of each to client

Unified ProcessUnified Process

Development in short timeboxed iterations

Develop high-risk high value first Use case driven Architecture centric Accommodate changes early Work together as a team

Method ComparisonMethod Comparison

method Concept Dev.

Requirements

Design Development

Maintenance

Scrum

ASD

Lean Dev

Crystal

XP

RUP

OPEN

Adaptive PlanningAdaptive Planning

R1

R2

Milestone 1 1st May R1…R10 complete

R5

R7

Milestone 2 1st July R11…R20 complete

Iterations

Improving estimates with Wideband DelphiImproving estimates with Wideband Delphi

Kickoff meeting Estimation Meeting Repeat steps Calculate

PlanningPlanning

Team members estimate their time budget each iteration

Volunteering Visible project plans Iteration Goals: risks, coverage,

criticality, (examples demo of product, skills development)

Ranking listsRanking lists

Request Type

Process Sale-pay by credit

scenario

Log-in window not closing

defect

Handle returns Use case

Tracking Iteration ProgressTracking Iteration Progress

Frequent Wall list for small projects XP task cards held by the volunteer Asking team members to self-record

their remaining task effort. Better XP practice of a ‘daily tracker’.

Test driven development

Earned valueEarned value

Recognition rules ‘rubber baseline’ Experimental stage Philippe Kruchten article

Risk ManagementRisk Management

Risk Probability Impact

Insufficient number of skilled OO developers

H H

Demo not ready for OOP conference Munich

M H

Then develop a management plan on wall, ie risk, actions, owner, status

EnvironmentEnvironment

Continuous integration Project Wiki webs Reverse engineering- Somatik

Caves, walls, digital technology