Agile_terms Flashcards
acceptance testing
An acceptance test is a formal description of the behaviour of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios; in many cases the aim is that it should be possible to automate the execution of such tests by a software tool, either ad-hoc to the development team or off the shelf. Similarly to a unit test, an acceptance tests is generally understood to have a binary result, pass or fail; a failure suggests “though it does not prove” the presence of a defect in the product. For many Agile teams acceptance tests are the main form of functional specification; sometimes the only formal expression of business requirements. In other cases, they merely complement a specification document resulting from a less specifically Agile technique or formalism, such as uses cases or more narrative documents.
ATDD (acceptance test driven development) or STDD (story test driven development)
Analogous to test-driven development, this practice consists in the use of automated acceptance tests with the additional constraint that these tests be written in advance of implementing the corresponding functionality.
In the ideal situation (though rarely attained in practice), the product owner, customer or domain expert is able to specify new functionality by writing new acceptance tests or test cases, without needing to consult developers.
automated build
The “build” in developer parlance consists in the process which, starting from files and other assets under the developers’ responsibility, results in a software product in its final or “consumable” form. This may include compiling source files, their packaging into compressed formats (jar, zip, etc.) but also the production of installers, the creation or updating of database schema or data, and so on. The build is “automated” to the extent that these steps are repeatable and require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.
backlog
A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release:
if an item on the backlog does not contribute to the project’s goal, it should be removed;
on the other hand, if at any time a task or feature becomes known that is considered necessary to the project, it should be added to the backlog.
These “necessary and sufficient” properties are assessed relative to the team’s state of knowledge at a particular moment; the backlog is expected to change throughout the project’s duration as the team gains knowledge.
The backlog is the primary point of entry for knowledge about requirements, and the single authoritative source defining the work to be done.
backlog grooming
The team (or part of the team including the product owner) meet regularly to “groom the product backlog”, in a formal or informal meeting which can lead to any of the following:
removing user stories that no longer appear relevant
creating new user stories in response to newly discovered needs
re-assessing the relative priority of stories
assigning estimates to stories which have yet to receive one
correcting estimates in light of newly discovered information
splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
BDD (behavior driven development)
BDD (Behaviour Driven Development) is a synthesis and refinement of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development). BDD augments TDD and ATDD with the following tactics:
apply the “Five Why’s” principle to each proposed User Story, so that its purpose is clearly related to business outcomes
thinking “from the outside in”, in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste
describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication
apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap
burndown chart
The team displays, somewhere on a wall of the project room, a large graph relating the quantity of work remaining (on the vertical axis) and the time elapsed since the start of the project (on the horizontal, showing future as well as past). This constitutes an “information radiator”, provided it is updated regularly. Two variants exist, depending on whether the amount graphed is for the work remaining in the iteration (“sprint burndown”) or more commonly the entire project (“product burndown”).
collective ownership
Teams typically adopt conventions governing who is allowed to modify some source code that was originally written by another, often referred to as “ownership”. These conventions can written and explicit, merely oral, or entirely implicit. Many different modes exist; commonly only one developer “owns” each code file. Collective code ownership, as the name suggests, is the explicit convention that “every” team member is not only allowed, but in fact has a positive duty, to make changes to “any” code file as necessary: either to complete a development task, to repair a defect, or even to improve the code’s overall structure.
continuous deployment
Continuous deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.
To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.
Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.
crc cards
CRC cards (for Class, Responsibilities, Collaborators) are an activity bridging the worlds of role-playing games and object-oriented design.
With the intent of rapidly sketching several different ideas for the design of some feature of an object-oriented systems, two or more team members write down on index cards the names of the most salient classes involved in the feature. The cards are then fleshed out with lists of the responsibilities of each class and the names of collaborators, i.e. other classes that they depend on to carry out their own responsibilities.
The next step is to validate - or invalidate as the case may be - each design idea by playing out a plausible scenario of the computation, each developer taking on the role of one or more classes.
The dialogue may go as follows, for instance: “Hello, Authentication Controller! I am a Web Request and I would like the contents of this resource.” - “Very well, let me have your Credentials so I can give them, together with the name of the operation you are trying to perform, to our Access Control List; I will redirect you to one of our View components depending on the result, etc.”
daily meeting
Each day at the same time, the team meets so as to bring everyone up to date on the information that is vital for coordination: each team members briefly describes any “completed” contributions and any obstacles that stand in their way. Usually, Scrum’s Three Questions are used to structure discussion. The meeting is normally held in front of the task board.
This meeting is normally timeboxed to a maximum duration of 15 minutes, though this may need adjusting for larger teams. To keep the meeting short, any topic that starts a discussion is cut short, added to a “parking lot” list, and discussed in greater depth after the meeting, between the people affected by the issue.
definition of done
The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.
definition of ready
By analogy with the “Definition of Done”, the team makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration.
estimation
In software development, an “estimate”, in the usual sense, consists of a quantified evaluation of the effort necessary to carry out a given development task; this is most often expressed in terms of duration.
The intent is to agregate many such individual estimates, so as to obtain an indication of the overall duration, effort or cost of a software project.
exploratory testing
Exploratory testing is, more than strictly speaking a “practice”, a style or approach to testing software which is often contrasted to “scripted testing”, and characterized by the following aspects among others:
it emphasizes the tester’s autonomy, skill and creativity, much as other Agile practices emphasize these qualities in developers;
it recommends performing various test-related activities (such as test design, test execution, and interpretation of results) in an interleaved manner, throughout the project, rather than in a fixed sequence and at a particular “phase”;
it emphasizes the mutually supportive nature of these techniques, and the need for a plurality of testing approaches rather than a formal “test plan”
Agile teams tend to shift and redraw the role boundaries between “developer” and “tester”, mostly as a result of the heavy use by developers of automated unit and functional tests - in one sense an extreme form of scripted testing. These activities are not sufficient to ensure quality, and Agile teams can find valuable assets in team members who have well-developed testing skills (whether or not their job description includes the term “tester”). These skills will be deployed more effectively in the exploratory style on an Agile team, as this style is more consistent with an Agile approach than the “scripted testing” style.
facilitation
A facilitator is a person who chooses or is given the explicit role of conducting a meeting. This role usually entails that the facilitator will take little part in the discussions on the meeting’s topic, but will focus primarily on creating the conditions for effective group processes, in the pursuit of the objectives for which the meeting was convened.
Facilitation is a specialization of its own, the details of which go well beyond Agile practices; a good introduction is the material provided by the International Association of Facilitators.
given - when - then
The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a User Story:
(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should obtain
An example:
Given my bank account is in credit, and I made no withdrawals recently,
When I attempt to withdraw an amount less than my card’s limit,
Then the withdrawal should complete without errors or warnings
Tools such as JBehave, RSpec or Cucumber encourage use of this template, though it can also be used purely as a heuristic irrespective of any tool.
heartbeat retrospective
The team meets regularly, usually adhering to the rythm of its iterations, to explicitly reflect on the most significant events to have occurred since the previous such meeting, and take decisions aiming at remediation or improvement.
This is often a facilitated meeting following a set format. Several distinct formats have been described, depending in large part on the time set aside for the meeting, typically between one and three hours. One important reason to use a facilitated format is to give all team members an opportunity to speak up.
incremental development
Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality. These are called “vertical” increments (that is, difference between successive product versions), as opposed to the opposite strategy which successively delivers complete technical components: for instance, creating a database schema, then building business rules on top of that, and only then implementing a UI. (This article offers a typical illustration of the distinction. It echoes the “layered cake” metaphor of software architecture: one can either cut along the horizontal layers, or vertically across them.) It is difficult to imagine an incremental approach in the Agile sense which is not also iterative, at least to some extent, but the two concepts are not identical. (They also prove surprisingly difficult to pin down, and are often the subject of heated semantic debates.)
information radiators
“Information radiator” is the generic term for any of a number of handwritten, drawn, printed or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on.
integration
The term “integration” (or “integrating”) refers to any efforts still required, after individual programmers, or sub-groups of programmers working on separate components, for a project team to deliver a product suitable for release as a functional whole.
For instance, if two developers, working in parallel, implement new features on two components A and B, and each thinks to their own satisfaction that the work is complete, then verifying that changes to A and B are consistent, and resolving any inconsistencies, belong in the category of integration.
Integration is often required at different levels: individual developers may work on components integrated into subsystems, which are in turn integrated with other teams’ subsystems to form a larger system, and so on.
