Unified Process versus Extreme Programming

Outline Compare and contrast UP and XP  Processes / Disciplines  Management  Artefacts Risk management – some thoughts

Disciplines Unified Process

Process Disciplines Requirements Specification (Kravspesifikasjon) System Analysis (Systemanalyse) Design Implementation Testing Deployment (iverksetting) Maintenance (Vedlikehold)

Supporting Disciplines Configuration management Change management Environment Project management  Time  Risk  Priorities  Estimation  Status Tracking / Follow up

XP key practices Customer is Team Member User Stories Short Time Boxed Iterations Pair Programming Test-Driven Development Collective Code Ownership Sustainable Pace Open Workspace The Planning Game Simple Design Refactoring Metaphor (Coding standards)

UP Disciplines vs XP Practices UP Disciplines Requirements Specification System Analysis Design Implementation Testing Deployment Configuration management Change management Environment Project management  Time  Risk  Status tracking XP Practices Customer in Team User Stories Short Time Boxed Iterations Pair Programming Test-Driven Development Collective Code Ownership Sustainable Pace Open Workspace The Planning Game Simple Design Refactoring Metaphor

Business modelling UP Processes  Process map  Use Cases Domain  Domain model ?  Glossary ? XP None?

Requirements Specification UP Use Cases UML artefacts  Domain model  Dynamic models Non-functional requirement XP User stories Metaphores (?) UML Model schetches Non-functional requirements

System Analysis UP Subtasks More detailed Use Case UML Domain model Prototypes? XP Subtasks UML model schetches Acceptance tests Working code

Design UP UML design model  Class  Interaction  Packages / Modules Base Architecture Prototypes XP UML schetches Simplest possible design Incremental code development Refactoring

Implementation UP Integrated, executable code after each iteration XP Integrated, executable code after each iteration Test suites – automatic tests

Testing UP No particular demand for test method Types  Unit tests  Integration tests  Acceptance tests  (Regression testing) Test first can be used XP Test first Automatic testing Acceptance Testing

Deployment UP Deployed system XP Deployed system

Configuration Management UP Version Control Iteration releases XP Collective Ownership Refactoring Integrated, testable code Iteration releases

Change management UP Requirements tracking Change requests XP ”Embrace change” Planning game Refactoring

Environment UP No particular demands for working environment Artifacts important for communication XP Pair Programming Test-Driven Development Collective Code Ownership Sustainable Pace Open Workspace

Risk and priority UP Identify and manage risk High risk tasks first Prototypes Base architecture Prioritize use cases High priority first ”Use Case driven” XP Identify risk High risk tasks early, but only if useful for current user stories Prioritize user stories High priority first ”User driven” – user in team

Managing time UP Time boxing: 2 – 6 weeks No particular method XP Time boxing: 1 – 4 weeks Estimate on basis of experience - velocity Velocity increases

Project management (1) UP (Release planning) Iteration planning Follow up  Finished tasks  Unfinished tasks  Used time  Remaining time ”Manager driven”? XP Release planning Iteration planning Task planning Follow up  Finished tasks  Unfinished tasks  Velocity ”Developer driven”?

Project management (2) UP Course plan for future iterations Detailed plan for next iteration  Users prioritize Use Cases  Developers estimate tasks XP Developers continuously involved in estimation Weekly plan stable Overall plan changes continuously

Risk – some thoughts Risk in the waterfall model Risk in iterative development Managing risk

Risk in the waterfall model RISKRISK T I M E Implement. Testing Design Analysis Req.Spec Deployment

Risk in iterative development T I M E Iteration 1 RISKRISK Iteration 2Iteration 3 Risk iterative Risk waterfall

Risk factors (1) Resources  Lack of people  Lack of money Competence  Lack of knowledge  Misunderstanding requirements  Missing important requirements Communication  Bad coordination  Misunderstandings  “Bad chemistry”

Risk factors (2) ”Technical risk”  Uncertain solution method  Uncertain requirements  Uncertain performance Identify uncertain subtasks  Difficult  Uncertain of difficult  Uncertain extent Deadlines  Illness  Underestimated size of task  Partners not delivering on time

Reducing risk Manage risks  Identify risks  Assess Seriousness and Probability  Get an idea how to handle a risk if it occurs Prioritize work according to risk level  High risk tasks in early iterations  Prototypes  Basic functionality used by many components  Consider high risk issues in early iterations E.g.: Many simultaneous users

Discussion themes MDD vs XP // CASE tools vs XP  Model is source vs Code is source Non-functional requirements in XP  Have XP sufficient focus?  Have users sufficient focus? Is XP downplaying software architecture?  When is overall architecture introduced?  Can refactoring lead to good architecture? Is XP too dependant on good people?  Very little written documents – need good memory  Need helpful team members

Takk for oppmerksomheten!