Chapter 3 – Agile Software Development (Ian Sommerville)

Vocabulary flashcards covering key terms, practices, roles, and principles from Chapter 3—Agile Software Development. Suitable for exam review and concept reinforcement.

Agile development

An iterative approach where specification, design, implementation, and testing are inter-leaved, emphasizing working code, frequent increments, and minimal documentation.

Plan-driven development

A software process organized around distinct, pre-planned stages with specified outputs; iterations occur within activities but overall progress follows a detailed plan.

Rapid software development

Delivering useful software quickly to keep pace with fast-changing business requirements, often prioritized over up-front completeness of requirements.

Agile methods

Lightweight development approaches that focus on code, iterative delivery, customer collaboration, and rapid response to change while reducing process overheads.

Agile Manifesto

Foundational statement valuing individuals and interactions, working software, customer collaboration, and responding to change over processes, documentation, contracts, and plans.

Customer involvement (agile principle)

Ongoing participation of customers to provide, prioritize, and evaluate requirements throughout development.

Incremental delivery (agile principle)

Developing software in small, usable increments selected and reviewed by the customer.

People not process (agile principle)

Recognizing developer skills, letting teams choose their own working style rather than following prescriptive procedures.

Embrace change (agile principle)

Designing and planning with the expectation that requirements will evolve during development.

Maintain simplicity (agile principle)

Actively striving to eliminate unnecessary complexity in both code and process.

Extreme Programming (XP)

Influential agile method advocating very small releases, continuous testing, pair programming, and constant refactoring.

Incremental planning (XP)

Recording requirements on story cards and selecting stories for a release based on priority and available time.

Small releases (XP)

Delivering the minimal useful functionality first, then adding features frequently (e.g., every 2 weeks).

Simple design (XP)

Creating only enough design to satisfy current requirements—no more, no less.

Test-first development

Writing automated unit tests before implementing functionality to clarify requirements and ensure correctness.

Refactoring

Continuous code improvement to enhance clarity and maintainability without changing external behavior.

Pair programming

Two developers work at one workstation, collaboratively writing and reviewing code in real time.

Collective ownership

All developers can modify any part of the codebase, preventing knowledge silos.

Continuous integration

Merging completed work into the main code line as soon as tasks finish; all tests must pass after each integration.

Sustainable pace

XP practice discouraging overtime to preserve code quality and team productivity.

On-site customer

Customer representative embedded full-time with the XP team to clarify requirements and write acceptance tests.

User story

Short, customer-written description of desired functionality that serves as a primary requirements artifact in agile projects.

Task card

A developer-focused breakdown of a user story into specific implementation tasks used for estimating and scheduling.

Automated test harness

Framework (e.g., JUnit) that executes unit tests automatically each build, verifying new and existing functionality.

Acceptance test

Customer-defined automated or manual test that validates a user story’s fulfillment in a release.

Test automation

Writing executable tests before or during coding so they can be run quickly and repeatedly with minimal effort.

Scrum

Agile project-management framework organizing work into fixed-length sprints and emphasizing daily team coordination.

Product backlog

Ordered list of features, requirements, and tasks the Scrum team must address during the project.

Sprint

Time-boxed development iteration in Scrum, usually 2–4 weeks, resulting in a potentially shippable increment.

Potentially shippable product increment

Software produced at the end of a sprint that is complete enough to release, pending business decision.

Product owner

Person responsible for maintaining the product backlog, prioritizing work, and representing business needs.

ScrumMaster

Facilitator who ensures adherence to Scrum, removes impediments, and shields the team from external disruptions.

Velocity (Scrum)

Measure of backlog effort a team can complete in one sprint, used for planning and performance tracking.

Scrum of Scrums

Daily coordination meeting where representatives of multiple Scrum teams discuss progress and dependencies.

Scaling up (agile)

Adapting agile practices for large, complex systems that require multiple teams, up-front design, and documentation.

Scaling out (agile)

Extending agile adoption across an entire organization with established processes and legacy systems.

Brownfield system

System developed in an environment containing existing interacting systems, limiting flexibility for change.

Agility at scale (IBM model)

Framework describing disciplined agile delivery while addressing scaling factors like team size, distribution, compliance, and complexity.

Multi-team Scrum

Approach where several Scrum teams work on one product, using role replication, product architects, release alignment, and Scrum of Scrums.

Contractual issues (agile)

Challenge of aligning flexible, evolving requirements with traditional fixed-specification contracts; often requires time-and-materials agreements.

Agile maintenance

Applying agile practices to evolve existing systems, complicated by sparse documentation, customer availability, and team continuity.

Release alignment

Coordinating release dates of multiple teams so combined increments form an integrated, usable product.

Continuous delivery / frequent releases

Practice of providing regular software increments to stakeholders for feedback and value realization.

Rapid feedback

Core agile benefit where stakeholders evaluate frequent increments, enabling early detection of issues and realignment of priorities.

Sustainable architecture (large agile)

Balance between emergent design and intentional architecture needed to support long-term, multi-team agile development.

Distributed Scrum

Adapting Scrum for geographically separated teams using video conferencing, shared environments, and continuous integration.

Test coverage

Extent to which a set of tests exercises the codebase; difficult to judge completeness in test-first approaches.

People and teams factor

Consideration of skill levels, organization, and tooling when choosing between agile and plan-driven methods.

Regulatory compliance constraint

Requirement for documentation and formal evidence of quality that can clash with agile informality, especially in safety-critical domains.