Process Model Characteristics (review)
- Heavyweight vs. Lightweight
- Planning vs. Doing
- Efficiency (skillset, personnel, time to market)
- Single vs. Multiple passes
- Role of Maintenance
- View of Evolution
Agile Process Models
- Lightweight, doing (vs. planning), multiple passes, evolutionary approach
- Strongly iterative and evolutionary
- "World is fundamentally chaotic", "Change is inevitable", "Deliver value to the customer".
Agile Process Models: Examples
- eXtreme Programming
- RUP
- Scrum (covered separately)
- Individuals and interactions are more important than processes and tools
- Working software is more important than comprehensive documentation
- Customer collaboration is more important than contract negotiation
- Responding to change is more important than following a plan
eXtreme Programming (XP)
- Pure agile approach
- Given as a set of best practices
- Pushes good practices to their extreme
- Design is kept as simple as possible
- Strongly involves refactoring, test-driven development, etc.
XP: Requirements and Design
- Metaphor - Simple metaphor (story) to use for the entire system
- On-site customer - A real user should be a full-time member of the team
- The planning game - The scope of the next release is quickly determined with the plan updated as necessary
- Small releases - A simple version is released as soon as possible. Short cycles for subsequent releases
- Simple design - the design is as simple as possible for the current requirements
- Testing - Developers continuously write unit tests, and customers write acceptance tests
XP: Implementation
- Refactoring - System is changed to improve design but not affect behavior
- Pair programming - All code is written together by a pair of programmers using one machine
- Collective ownership - Any developer can change the code at any time
- Coding standards - Coding standards to support comprehension and collective ownership
- Continuous integration - Code integrated and built continuously
- 40-hour week - Working overtime is the exception
Rational Unified Process (RUP)
- Developed by Rational Software (IBM)
- Lots of tool support: Rational Method Composer (RMC)
- Between document-driven and agile approaches
- Most formal: specific practices, strong tool support
RUP Phases
- inception - determine objectives, costs, schedule, and risks
- elaboration - analysis to determine architecture
- construction - implementation
- transition - release, integration into existing systems
RUP Practices
- Iterative development - carefully planned with measured progress
- Requirements management - systematic approach, including changes
- Architecture - Decided early with strong use of components
- Modeling & UML - Development of models, use of UML
- Quality of process and product - The responsibility of everyone, with an explicit testing workflow
- Configuration and change management - Sound procedures and appropriate tool support
- Use-case-driven development - UML Use Cases describe behavior
- Process configuration - modified for specific circumstances
- Tool support - strong, especially for modeling and configuration management
RUP Main Workflows
- Business Modeling - context of the delivered software
- Requirements - detailed idea of what the system needs to do
- Analysis & Design - overall architecture and blueprint for code
- Implementation - coding and integration into a complete software system
- Test - all types of testing
- Deployment - external release and integration into the customer system
RUP Supporting Workflows
- Configuration and change management - configuration, change requests, and measurement
- Project Management - coarse-grained (overall project) and fine-grained (individual iteration)
- Environment - tailoring process to project needs
Adoption Reality (for the most part)
- Companies are already following an agile (e.g., iterative) process
- Companies think they are following an agile (e.g., iterative) process
- Companies want to be following an agile (e.g., iterative) process