ACP Exam Flashcards
1
Q
4 Agile Values
A
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a Plan
2
Q
Agile Guiding Principles 1-3
A
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
3
Q
Agile Guiding Principles 4-6
A
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
4
Q
Agile Guiding Principles 7-9
A
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
5
Q
Agile Guiding Principles 10-12
A
- Simplicity, the art of maximizing the amount of work not done is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective then tunes and adjusts its behavior accordingly.
6
Q
Three Pillars of Scrum
A
Transparency, Inspection, Adaptation
7
Q
Scrum Roles
A
Product Owner, Scrum Master, Development Team
8
Q
XP Core Values
A
Simplicity: Reduce complexity, extra features, and waste. Communication Feedback Courage Respect
9
Q
XP Roles
A
Coach, Customer, Programmers (Developers), Testers,
10
Q
XP Practice Release Planning
A
Push of new functionality all the way to the production user.
Customer outlines functionality required.
Developers estimate difficulty of build.
11
Q
XP Practice Iteration Planning
A
Conducted at the start of every iteration.
Customer explains functionality they would like.
Developers break functionality into tasks and estimate work based on amount of work accomplished in previous iteration.
12
Q
XP Practice Small Releases
A
Frequent small releases to test environments.
Demonstrate progress and increase visibility for the customer.
13
Q
XP Practice Customer Tests
A
Customer describes one or more tests to show software is working.
Team builds automated tests to prove software is working.
14
Q
XP Practice Collective Code Ownership
A
Any pair of developers can improve or amend any code.
Multiple people work on all code, which results in increased visibility and knowledge of code base.
Less risk if programmer leaves, since knowledge is shared.
15
Q
XP Practice Code Standards
A
Follow consistent coding standard so code looks like it has been written by a single knowledgeable programmer.
16
Q
XP Practice Sustainable Pace
A
While periods of overtime may be necessary, repeated long hours of work are unsustainable and counterproductive.
17
Q
XP Practice Metaphor
A
XP uses metaphors and similes to explain designs and create a shared technical vision. These descriptions establish comparisons that all the stakeholders can understand and explain how the system should work.
18
Q
XP Practice Continuous Integration
A
Integration involves bringing the code together and making sure it all compiles and works together. All code changes are checked and tested daily.
19
Q
XP Practice Test Driven Development (TDD)
A
The team writes tests prior to developing the new code. If the tests are working correctly, the initial code that is entered will fail the tests. The code will pass the test once it is written correctly.
20
Q
XP Practice Pair Programming
A
In XP, production code is written by two developers working as a pair to write and provide real-time reviews of the software as it emerges.
21
Q
XP Practice Simple Design
A
Code is always testable, browsable, understandable, and explainable. Do the simplest thing that could possibly work next. Complex design is replaced with simpler design. The best architectures, requirements, and designs emerge from self-organizing teams.
22
Q
XP Practice Refactoring
A
Remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs. Refactoring throughout the entire project life cycle saves time and increases quality. Code is kept clean and concise so it is easier to understand, modify, and extend.
23
Q
Lean Principles
A
Eliminate waste Empower the team Deliver fast Optimize the whole Build quality in Defer decisions Amplify learning
24
Q
7 Wastes of Lean
A
- Partially done work
- Extra processes
- Extra features
- Task switching
- Waiting
- Motion
- Defects
25
Kanban Definition
It is derived from the Lean production system used at Toyota. Kanban means signboard.
26
Kanban 5 Core Principles
1. Visualize the workflow
2. Limit work in progress (WIP)
3. Manage flow
4. Make process policies explicit
5. Improve collaboration
27
Feature Driven Development
Agile method where the team will first develop an overall model for the product then build a list and plan the work.
28
Return on Investment (ROI)
The ratio of the benefits received from an investment to the money invested. Usually a percentage.
29
Internal Rate of Return (IRR)
Interest rate you will need to get in today's money to receive a certain amount of money in the future. The higher the better. IRR is a superior measure to NPV.
30
Present Value/Net Present Value (NPV)
Value of future money in today's terms.
31
Earned Value Management
Formulas that monitor the value of the project as it is progressing.
32
Manual Regression Testing
Testing parts of the program to make sure new updates have not introduced bugs that were not there before. Instead of just testing new features and small updates alone you also test what areas of the program the updates may have affected.
33
INVEST
```
A good user story should be:
Independent
Negotiable
Valuable
Estimable
Small
Testable
```
34
Agile Declaration of Interdependence
Agile and adaptive approaches for linking people, projects, and value.
We are a community of project leaders that are highly successful at delivering results. To achieve these results:
We increase return on investment by making continuous flow of value our focus.
We deliver reliable results by engaging customers in frequent interactions and shared ownership.
We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
We boost performance through group accountability for results and shared responsibility for team effectiveness.
We improve effectiveness and reliability through situationally specific strategies, processes, and practices.
35
Value Added Time
Time spent that improves the outcome of a process.
36
Spikes
A short effort (usually timeboxed) that is devoted to exploring an approach, investigating an issue, or reducing a project risk.
37
Pareto Principle
The Pareto Principle states that 80% of consequences come from 20% of the causes.
38
Wideband Delphi
Estimation based on the input of a panel of experts.
39
Monte Carlo Estimation
A broad class of computational algorithms that rely on repeated random sampling to obtain numerical results. The underlying concept is to use randomness to solve problems that might be deterministic in principle. They are often used in physical and mathematical problems and are most useful when it is difficult or impossible to use other approaches.
40
Acceptance Test Driven Development
Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality.
41
Rapid Application Development
Rapid Application Development (RAD) is a development model prioritizes rapid prototyping and quick feedback over long drawn out development and testing cycles. With rapid application development, developers can make multiple iterations and updates to a software rapidly without needing to start a development schedule from scratch each time.
42
Cycle Time
Cycle time is a measure of the elapsed time when work starts on an item (story, task, bug etc.) until it's ready for delivery. Cycle time tells how long (in calendar time) it takes to complete a task. Total units completed divided by time to complete.
43
Lead Time
Lead time is the measurement of how much time passes between task creation and when the work is completed.
44
Pruning the Product Tree
Product Managers will “prune the product tree.” This innovation game represents a product roadmap as a simple tree complete with trunk, branches, roots, and leaves. The tree metaphor invites participants to think about how to grow (and shape) a product or service
45
EVM
Earned Value Management (EVM) is a project management technique that measures the technical performance, cost and schedule of a project against planned objectives. The result is a simple set of metrics that provides early warnings of performance issues, allowing for timely and appropriate adjustments. Should be measured at the iteration level because this is where velocity is measured.
46
5 Steps of TDD
1) Read, understand and process the feature
2) Translate the requirement by writing a unit test
3) Write and implement the code that fulfills the requirement. Run all the tests
4) Clean up your code by refactoring.
5) Rinse, lather, and repeat.
Test>Code>Refactor>Deliver
47
Relative Sizing
Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty.
48
Cost Performance Index
CPI gives a measure of efficiency. It is calculated by dividing Earned Value by the Actual Cost. CPI > 1 you are under budget.
49
Scheduled Performance Index
SPI is calculated by dividing the Planned Value into the Earned Value. SPI > 1 indicates you are ahead of schedule.
50
Schedule Variance
Earned Value - Planned Value. SV > 1 indicates you are ahead of schedule.
51
Definition of Ready
The Definition of Ready defines the criteria that a specific user story has to meet before being considered for estimation or inclusion into a sprint. Whereas a Definition of Ready is focused on user story level characteristics, the Definition of Done is focused on the sprint or release level.
52
Feature Buffer
The customer selects all of the absolutely mandatory work. The estimates for that work are summed. This represents the minimum that can be released. The customer then selects another 25% to 40% more work, selecting toward the higher end of the range for projects with more uncertainty or less tolerance for schedule risk. The estimates for this work are added to the original estimate, resulting in a total estimate for the project. The project is then planned as normal for delivery of the entire set of functionality; however, some amount of the work is optional and will be included only if time permits.
53
DevOps
DevOps is the combination of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes
54
Iteration Planning Time
1-2 hours for each week of sprint duration.
55
Force Field Analysis
A technique for analyzing the forces that are encouraging and resisting potential or real change and the strength of those forces.
56
Persona
An imaginary person or identity created by the team to model interactions with the system to gather requirements.
57
Product Roadmap
A prioritized matrix that describes product features that the team will deliver in each release over time.
58
Exploratory Testing
A means of testing that relies on the tester's autonomy, skill, and creativity in trying to discover issues and unexpected behaviors.
59
Acceptance Criteria
An acceptance criterion works per product backlog items (user story) and is defined by the product owner. The done criteria are set for story, iteration or release and defined by the team.
60
Empiricism
Empiricism asserts that knowledge comes from experience and making decisions based on what is known.
61
Hardening Iteration
A hardening iteration is used for readying the product for production—capturing screenshots for marketing materials, training the help desk, and other small tweaks and final tests that couldn’t be conducted within the regular iterations.
62
Caves and Common
The phrase “caves and common” refers to the creation of two zones in the room. The “common” area is organized to maximize osmotic communication and information transfer. The “caves” portion of the room is organized to give people a private place to do e-mail, make phone calls, and take care of their need for separation. For the common area to work well, each team member should be working on one and the same project.
63
Complex Story
The complex story is a user story that is inherently large and cannot easily be disaggregated into a set of constituent stories. If a story is complex because of uncertainty associated with it, you may want to split the story into two stories: one investigative and one developing the new feature.
64
Process Tailoring
Process tailoring is when a project team takes the organization’s standard process definition and tailors it to the specific needs of their development project.
65
Fist of Five
Fist to five, also called fist of five, is a technique used by agile teams to poll team members and help achieve consensus. Fist of five is similar to thumbs up, thumbs down or thumbs sideways.
66
Scrum Artifacts
Product Increment, Product Backlog, Sprint Backlog
67
Agile KPI's
Rate of progress
Remaining work
Likely completion date
Likely cost remaining
68
Graduated Fixed Price Contract
Buyer and seller share risk and rewards. There is a higher rate for finishing early, normal rate for on time, and a lower rate for finishing late.
69
Fixed Price Work Packages
In this type of contract, as each work package gets completed, the contractor can re-estimate the remaining work packages in the SOW, based on the latest information and risks. This gives the contractor and the customer a realistic estimate of the costs and risks involved in the upcoming work packages and an opportunity to reprioritize the backlog or to decide whether to continue with the rest of the project.
70
Little's Law
Cycle times are proportional to queue lengths. We can predict completion times based on the queue size. L = A x W where L is the number of items inside the queue (WIP), A represents the arrival rate and departure rate of items in and out of the business system or throughput. A = (1 item) / (unit of time) and is displayed as a fraction. W = the amount of time an item spends in the queuing system.
71
Servant Leadership
1) Shield the team from interruptions
2) Remove impediments to progress
3) Communicate project vision
4) Carry food and water
72
Minimal Viable Product (MVP)
Refers to a set of functionality that is complete enough to be useful, but small enough not to be an entire project. Usually a software module.
73
Theory of Constraints
A methodology for identifying the most important limiting factor that stands in the way of achieving a goal then systematically improving that constraint until it is no longer the limiting factor.
74
Money for Nothing and Change for Free Contract
Contracts that allow for early termination (with a fee) and no charges for changes to scope provided the customer works with the team on every iteration. Changes are free so long as they do not alter the total amount of contracted work.
75
Ideal Time
The time it would take to complete a given task assuming zero interruptions or unplanned problems.
76
Iteration 0
Sets the stage for development efforts. Does not build anything.
77
Technical Debt
Backlog of work caused by not doing regular cleanup. If not dealt with the cost of development will increase and it will be harder to implement changes. Refactoring is the solution.
78
Escaped Defects
Defects that make it to the customer.
79
Kaizen
Kaizen is a Japanese business philosophy that focuses on gradually improving productivity by involving all employees and by making the work environment more efficient. Kaizen translates to "change for the better" or "continuous improvement."
Follows the Plan-Do-Check-Act cycle. Agile uses the Plan>Develop>Evaluate>Learn Cycle.
80
Retrospective Stages
1) Set Stage: Get everyone focused, check-in
2) Gather Data: Timeline, 555, mad sad glad, collect data
3) Generate Insights: Analyze data, brainstorm, 5 whys, fishbone
4) Decide What to do SMART goals, start doing, stop doing, do more, do less, how can we improve?
5) Close Retrospective Plus/Delta two columns of what the team can do more or less of.
81
Top-down Estimation
Top-down estimating occurs when company management imposes a cost and/or duration on a project, usually without a detailed cost analysis. The estimating process is derived from the opinions of a group of experienced managers, possibly supplemented by outside experts.
82
5 Agile Project Management Model Phases
1) Envision. what, who, how, and when about getting the project off the ground.
2) Speculation. defining broad requirements
3) Explore. focus on delivering product features
4) Adapt. focus on modifications, changes, corrections
5) Close.
83
Why People Fail
1) Making mistakes
2) Preferring to fail conservatively
3) Inventing rather than researching
4) Being creatures of habit
5) Being inconsistent
84
Acceptance Test
Acceptance test is a process of verifying that stories were developed such that each works exactly the way the customer expected it to work.
85
Empirical Process Control
In empirical process control, you expect the unexpected. With defined process control, every piece of work is understood. Using empirical process control is working in a fact-based, experience-based, and evidence-based manner that control is exercised through visibility, inspection, adaptation.
86
Domain Knowledge
Domain knowledge is the subject matter expertise in the business domain of our clients, such as understanding the merchant acquisition process in the payments industry.
87
Process Cycle Efficiency
The formula for process cycle efficiency is value-added time divided by total lead time. For instance, if the total lead time for a process is 4 hours and the value-added time equals 1.2 hours, you get a process cycle efficiency of 30 percent – a figure generally viewed as very good.
88
Active Listening Levels
1) Internal Listening: Listen to your inner voice
2) Focused Listening: Listen to another person
3) Global Listening: Listening to others in the context of their entire surroundings.
89
Risk Burndown Chart
Risk Burndown graphs are very useful Communication Tool for seeing if the total project risk is increasing or decreasing over time. It allows stakeholders to see instantly if we are reducing project risk. Risk burndown graphs show the cumulative risk severities over time.
There are two key pieces of information which the Risk Burndown Graph shows immediately:
Whether the overall level of risk in the project or program is decreasing over time (are we reducing project risk?)
Whether individual risks are increasing in severity over time and whether new risks are being introduced.
90
Agile Team Charter
Why are we doing this project? Who benefits and how? What does done look like? How are we going to work together?
91
Behavior Driven Development (BDD) Acceptance Criteria
Given, When, Then
| Given some scenario, when this happens, then do this.
92
Crystal Core Values
People, Interaction, and Community
93
Crystal Colors
```
Clear: Teams of less than 8 people
Yellow: 10 - 20 people
Orange: 20-50 people
Red: 50-100 people
Magenta: 100-200 people
```
94
Disciplined Agile (DA) Principles
People first, Learning oriented, Goal driven, Scalable
95
Dynamic Systems Delivery Method (DSDM) Principles
Focus on the business need and deliver on time.
96
Red-Green-Refactor
TDD. Where a test is written first that fails, then passes once the solution is developed, then it can be refactored or streamlined. Known for constraint driven delivery which sets cost, quality, and time at the beginning, then uses formalized prioritization of scope to meet those constraints.
97
S-Curve
A graph that tracks cost or some other variable against time.
98
Five Focusing Steps of Goldratt's Theory of Constraints
1) Identify the constraint
2) Exploit the constraint
3) Subordinate all other processes to exploit the constraint
4) If after steps 2 and 3 are done, more capacity is needed to meet demand, elevate the constraint
5) If the constraint has not moved go back to step 1, but don't let complacency become the constraint.
99
DSDM Contract
This contract focuses on work being "fit for business purposes" and passing tests rather than matching a specification.
100
Usability Testing
Tries to answer the question "How will an end user respond to the system under realistic conditions?"
101
Shu-Ha-Ri
Model of skill mastery.
Shu: Obeying the rules
Ha: Consciously moving away from the rules
Ri: Unconsciously finding an individual path
102
Dreyfus Model of Adult Skill Acquisition
```
Novice
Advanced Beginner
Competent
Proficient
Expert
```
103
Affinity Estimating
Grouping smaller items into similar categories or collections. It offers a comparative view of the estimates and provides a reality check that the estimates are in fact comparable.
104
Story Map
A high-level planning tool that allows stakeholders to map out project priorities early in the planning process. Once created it can be adapted to serve as the product roadmap.
105
Product Roadmap
A visual depiction of the product releases and main components that will be included in each release.
106
Architectural Spike
A spike devoted to proof of concept, or will the approach the team hopes to use work on the project?
107
Risk-Based Spike
A spike that sets out to investigate and hopefully reduce or eliminate an issue or threat to the project.
