Z26 Project Management Agile and Iterative Planning Lecture 2a Graham Collins, UCL
-
Upload
ivan-dudley -
Category
Documents
-
view
34 -
download
0
description
Transcript of Z26 Project Management Agile and Iterative Planning Lecture 2a Graham Collins, UCL
Z26 Project Management
Agile and Iterative Planning
Lecture 2a
Graham Collins, UCL
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