Prioritizes speed of delivery and working software over comprehensive planning and documentation.
Key characteristics:
- Specification, design, and implementation are interleaved.
- System developed in increments.
- Stakeholders evaluate each version.
- UI often built using IDE tools.
Agile Development
Reduces process overhead. Focuses on delivering working software in short iterations.
The Agile Manifesto
A declaration of priorities for lightweight software development. Created in February 2001 by 17 software practitioners.
Values:
- Individuals and interactions > processes and tools
- Working software > comprehensive documentation
- Customer collaboration > contract negotiation
- Responding to change > following a plan
Agile Principles
- Customer involvement
Continuous feedback throughout development. - Incremental delivery
- People over process
- Embrace change
- Maintain simplicity
Avoid unnecessary complexity in code and process.
Agile vs Plan-Driven Development
Plan-Driven
- Separate stages: requirements, design, implementation.
- Detailed specification before coding.
- Suitable for regulated, large, or safety-critical systems.
Agile
- Activities interleaved.
- Requirements evolve during development.
- Suitable for small or medium systems with active customers.
Choice depends on:
- System size
- Regulatory requirements
- Team skill level
- Expected system lifetime
- Organizational culture
Extreme Programming
XP is an agile method that pushes agile principles to their extreme.
Characteristics:
- Multiple builds per day.
- Releases every ~2 weeks.
- All tests must pass before accepting a build.
Practices:
- Incremental planning (story cards)
- Small releases
- Simple design
- Test-first development
- Refactoring
- Pair programming
- Collective ownership
- Continuous integration
- Sustainable pace
- On-site customer
User Stories and Tasks
Requirements written as short scenarios from a user’s perspective. Developers break stories into tasks. Customer selects stories based on priority.
Cost and schedule estimated from tasks, not vague requirements.
XP and Change
Traditional View
Design for change early to reduce later cost.
XP View
Future changes cannot be predicted reliably. Continuously refactor code instead.
Refactoring
Improving code structure without changing functionality. Examples: removing duplicate code, renaming methods.
Keeps the system clean and maintainable. Architectural refactoring remains expensive.
Testing in XP
Testing is central to XP.
Features:
- Test-first development (TDD).
- Automated test framework (e.g., JUnit).
- All tests rerun after every change.
- Customer helps define acceptance tests.
Test-First Development
Write tests before writing code. Implement code to pass those tests. Tests become the specification.
Benefits:
- Clarifies requirements.
- Prevents regression errors.
Limitations:
- Hard to test UI-heavy systems.
- Full coverage is difficult to guarantee.
- Developers may write weak tests.
Pair Programming
Two programmers share one workstation. More productive than two programmers working independently.
Benefits:
- Continuous code review.
- Knowledge sharing.
- Supports refactoring.
- Reduces project risk if someone leaves.
Scrum
Agile project management framework. Focuses on project management, not coding practices.
Phases:
- Outline planning and architecture design
- Sprint cycles
- Project closure
Each sprint is 2 to 4 weeks long and produces a working increment. Based on a product backlog: a prioritized list of features.
In daily standups, each member answers:
- What did I do?
- What will I do?
- Any problems?
Suited to:
- Unstable or evolving requirements
- Teams needing improved visibility
- Establishing customer trust
Scrum Master
Facilitator. Removes obstacles. Protects the team from distractions.
Scaling Agile
Agile works best for small, co-located teams. Large systems introduce complications:
- Multiple teams
- Distributed locations
- External regulations
- Long system lifetime
- Many stakeholders
- Integration with existing systems
Scaling Up
Applying agile within a larger team.
Requires:
- More up-front design.
- More documentation.
- Cross-team communication mechanisms.
- Frequent system builds.
Scaling Out
Applying agile across multiple teams in an organization.
Difficult due to:
- Bureaucracy
- Cultural resistance
- Skill variation
- Traditional management mindset