Agile Practices Prep
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
TitleDesc
2
Requirements
3
Product Vision / Vision StatementDocument the vision with what success is, why it's important, and how you know you've achieved it. Post it prominently and involve your visionaries in planning and demos.
4
User StoriesA user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.
5
Use CasesA use case is a list of steps, typically defining interactions between a role (actor) and a system, to achieve a goal. The actor can be a human, an external system, or time.
6
Usage ScenariosA usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction.
7
PersonasSynthetic biographies of fictitious users, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person.
8
Requirement PrioritizationUse of one or more specific techniques to prioritise backlog items for implementation. Example techniques: Cost-Value Approach, Bubble sort, MoSCoW, 100-point method .
9
Architectural Spikes / Spike SolutionsCreate spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns.
10
Emergent Design / Evolutionary DesignWith emergent design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what they have in common and refactor out the commonality, allowing the design to emerge.
11
CRC CardsMembers of a brainstorming session will write up one CRC card for each relevant class/object of their design. The card is partitioned into three areas:
1) On top of the card, the class name
2) On the left, the responsibilities of the class
3) On the right, collaborators (other classes) with which this class interacts to fulfill its responsibilities
Using a small card keeps the complexity of the design at a minimum.
remove?
12
Design by ContractPrescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants.
13
System MetaphorSystem Metaphor is itself a metaphor for a simple design with certain qualities. The most important quality is being able to explain the system design to new people without resorting to dumping huge documents on them.
The second quality is a design that makes naming classes and methods consistent.
14
Coding Style/Guidelines/StandardWhen all team members write code in the same dialect, no part of the system would look alien, thus enabling programmers to practice collective ownership. They would then be comfortable to fix problems in code written by other programmers on the team.
15
Test Driven Developmentadd a test, get it to fail, and write code to pass the test, remove duplication
16
Behavior Driven Development- Each proposed User Story, so that its purpose is clearly related to business outcomes.
- Implement only those behaviors which contribute most directly to these business outcomes
-Describe behaviors in a single notation which is directly accessible to domain experts, testers and developers
17
Collective Code OwnershipCollective Ownership elliminates turf. Everyone on the team owns all of the system. Whoever is best equipped to work on any part of the system is empowered to act. This means that the team shares code collectively. If a defect needs fixing, the first person who knows how to fix it and wants to do so goes ahead. There is no attempt to find someone responsible for the defect.
18
Frequent Delivery/ReleasesRisk Management is central to the success of software projects. Any team that is building a system for months on end without getting any feedback is taking a big risk. Without feedback, it is entirely possible to build systems that do not meet the customer's needs
19
Unit TestingMethod by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.
20
Smoke Testing / Build Verification TestA subset of test cases that cover the most important functionality of a component or system is selected and run, to ascertain if the most crucial functions of a program work correctly.
21
System TestingIs testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements.
System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.
22
Test AutomationIs the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.
Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or add additional testing that would be difficult to perform manually.
23
Storytesting / Acceptance Criteria / Acceptance Testing
Acceptance tests are created from user stories. During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented.
24
Definition of Done / Done DoneThe Scrum Guide describes the Definition of Done (DoD) as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality.
25
VelocityIs a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration.
26
Root Cause Analysis / 5 WhysWhen mistakes occur, blame your process, not people. Root-cause analysis helps. What allowed the mistake to happen? What will prevent them in the future? Assume people will continue to make mistakes and build fault-tolerance into your improvements.
27
Cross-Functional TeamCross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.
28
Self-Organizing Team / Scrum TeamA group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands.
29
Product OwnerIs responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog.
30
Sustainable PaceMeans working at a pace you can comfortably sustain and occasionally sprinting when you need to. Sustainable Pace is easy to define and harder to practice.
31
Move People AroundMove people around to avoid serious knowledge loss and coding bottle necks. If only one person on your team can work in a given area and that person leaves or just has too much to do you will find your project's progress reduced to a crawl.
32
Scrum of ScrumsThe scrum of scrums meeting is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
33
Explicit policies
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
Main menu