Certschool Certified Agile Practitioner Cs-Cap

CertSchool Certified Agile Practitioner CS-CAP
Copyright 2011 CertSchool.com. All rights reserved.
CertSchool Certified Agile Practitioner
Pre-Requisites
General understanding of Agile Methodology Agile Vs. Traditional PMI and ACP certification basics
Goal
PMI ACP Exam

Exam
100 Scored Questions + 20 Unscored Questions 3 Hours, preceded by 15 min tutorial and survey
Blueprint
Agile tools and techniques 50% Agile knowledge and skills 50%
Blue Print - Tools and Techniques

Total below listed 10 Sections, Around 60 topics
1. Communications (10) 2. Planning, Monitoring and Adapting (10)

3. Agile Estimating (8) 4. Analysis and Design (7)
5. Product Quality (5) 6. Soft Skills & Negotiation (3) 7. Value Based Prioritization (3)
8. Risk Management (2) 9. Metrics (1) 10. Value stream Analysis (1)
Blue Print - Knowledge and Skills

Total 43 Knowledge and Skills to cover Level 1 33 Questions
18 Skills
Level 2 12 Questions
12 Skills
Level 3 5 Questions
13 Skills
Level 1
Active listening Agile Manifesto values and principles Assessing and incorporating community and stakeholder values Brainstorming techniques Building empowered teams Coaching and mentoring within teams Communications management Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations) Incremental delivery Knowledge sharing Leadership tools and techniques Prioritization Problem-solving strategies, tools, and techniques Project and quality standards for Agile projects Stakeholder management Team motivation Time, budget, and cost estimation Value-based decomposition and prioritization
Level 2
Agile frameworks and terminology Building high-performance teams Business case development Colocation (geographic proximity)/distributed teams Continuous improvement processes Elements of a project charter for an Agile project Facilitation methods Participatory decision models (e.g., input-based, shared collaboration, command) PMI's Code of Ethics and Professional Conduct Process analysis techniques Self assessment Value-based analysis
Level 3
Agile contracting methods Agile project accounting principles Applying new Agile practices Compliance (organization) Control limits for Agile projects Failure modes and alternatives Globalization, culture, and team diversity Innovation games Principles of systems thinking (e.g., complex adaptive, chaos) Regulatory compliance Variance and trend analysis Variations in Agile methods and approaches Vendor management
The Iterative Model
Implement Enhancement
Yes
No
Agile Methods
Scrum Extreme Programming (XP) Lean

Kanban ?
Feature Driven Development (FDD) Dynamic Systems Development Method (DSDM) Adaptive Software Development (ASD)
More
General Agile Buzz-Words
Evolving Requirements ? Iteration / Sprint ? User Story ? Story Points ? DoD (Definition of Done) ? Collaboration ? Timebox ? Spike ?
Scrum
Team size = 7 2
2-4 weeks
Scrum
Pigs get the work done - Scrum Master, Developers, Testers, and so on. Chickens are the people who gain from the product - Product Owner, Customers, Management.
Scrum
Extreme Programming
Core Values
Simplicity Communication Feedback Respect Courage
Team Size = 2-12 Iteration duration = 1-3 weeks
XP Feedback Loop
XP Roles
XP Coach
XP Customer
XP Roles
XP Programmer
XP Programmer (Administrator)
XP Roles
XP Tracker
XP Tester
10
XP
Lean
Essential Features
Nonessential Features
11
Lean Principles
Value Stream Muda / Waste Lean Agile PM
Lean
12
The Dynamic Systems Development Methodology (DSDM)
Feature Driven Development (FDD)
13
FDD
Feature Driven Development (FDD) is an iterative and incremental software development methodology typically used in large software projects. Employing this methodology enables you to efficiently manage a large team of developers and handle a myriad of tasks involved in developing software. In FDD, features to be incorporated in software are first identified and prioritized. A feature in the FDD context is a small functionality that is of value to the customer and can be described as an actionresult-object sequence. Given the complexity of projects, FDD endorses up-front planning and domain-driven design techniques to enable developers to focus on the domain and context of use of software rather than the technology used to implement the system.
5 Phases of FDD
1. The Develop an Overall Model Phase: involves describing the overall scope and context of software and understanding the domain in which the software application is used. 2. The Build a Features List Phase: wherein a list of features that need to be incorporated into the software is created. The features are then grouped into related sets based on the commonality of their functions and implementation. 3. The Plan by Feature Phase: where an overall development plan is created. This phase also involves assigning roles for team members to include class owners and feature set owners. 4. Design by feature phase: where detailed modeling for each feature is created. 5. Build by feature phase:, each feature is then built, unit tested for its performance, and integrated with the overall system.
14
The Feature Driven Development Methodology

Features grouped based on functionality
Plan
ASD
The Adaptive Software Development (ASD) methodology is a variation of the agile methodology. It is typically used to develop large, complex software systems. It advocates incremental development of software through constant iterations by developing prototypes at each iteration. The primary objective of ASD is to provide developers with development guidelines that enable them to avoid chaos but does not restrict creativity. The ASD process involves three phases that are used cyclically to create a robust software product. The three phases of the ASD life cycle are the speculate phase, the collaborate phase, and the learn phase.
15
Adaptive Software Development (ASD)
Development Phase
The Agile Life Cycle

Define business opportunities Older versions updated with newer versions
Design initial architecture, form a team
Support product in real-time environment
Develop software
Deploy product to production environment

Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
16
TEST Your Knowledge

Q. Which of the following is NOT an Agile model?
a) b) c) d)
Feature Driven Development Dynamic Systems Development Method Lean Development Spiral Model
Answer: d
TEST Your Knowledge

Q. Which of the following Agile practices are MOST helpful in implementing Collective Code Ownership in a Team?
a) b) c) d)
Daily Stand-ups Pair-Programming Version control Continuous Integration
Answer: b
17
TEST Your Knowledge

Q. Which of the following is NOT an XP Role
a) b) c) d)
XP Coach XP Manager XP Programmer XP Customer
Answer: B
TEST Your Knowledge

Q. What is the outcome of Sprint Planning Meeting
a) b) c) d)
The Product Backlog The Sprint Backlog Both of the Above None of the Above
Answer: b
18
Blue Print - Tools and Techniques

Total below listed 10 Sections, Around 60 topics
1. Communications (10) 2. Planning, Monitoring and Adapting (10)

3. Agile Estimating (8) 4. Analysis and Design (7)
5. Product Quality (5) 6. Soft Skills & Negotiation (3) 7. Value Based Prioritization (3)
8. Risk Management (2) 9. Metrics (1) 10. Value stream Analysis (1)
Tools and Techniques -- COMMUNICATION

~ 10 / 50 Questions
19
Communication ~ 10 / 50
Information Radiator
Effective Information Radiators are.. Simple Stark Current Transient Influential Highly Visible Minimal in number
Burn Down Chart: Effort Remaining (Hours / Days) Vs. Days Remaining
20
Tasks
Code the user interface Code the middle tier Test the middle tier Write online help
Mon Tues Wed Thur Fri

8 16 8 12 4 12 16 8 10 16 7 11 8
50 40 30 20 Hours 10 0 Mon Tue Wed Thu Fri

Burn Up Chart: Story Points Completed Vs. Time
21
Osmotic Communication
Rapid and Rich Feedback LOW cost-of-communication But HIGH Feedback Rate
Communication Modes
22
TEST Your Knowledge

Q. Two team members are trying to resolve a very critical issue in the Standup meeting. As an Scrum Master, what action you must take?
a) b) c) d)
Without interruption allow them to resolve the issue as it is critical Emphasize of the criticality of the issue to the rest of the team and then allow the two members to discuss while the other wait. Ask them to wait until the end of the Stand up meeting and suggest a breakout discussion thereafter. Wait for another team member to interrupt them.
Answer: c
TEST Your Knowledge

Q. What does Burn-up chart represent?
a) b) c) d) Story points Completed against Time Story points Remaining against Time Hours Completed against Hours Planned Effort Remaining against Time
Answer: a
23
Time Check
3/24/12 6:48 PM
Tools and Techniques PLANNING, MONITORING and ADAPTING

~ 10 / 50 Questions
24
Planning, Monitoring and Adapting ~10 / 50
Source: The Enterprise and Scrum By: Ken Schwaber

25
Ceremonies
Ceremony Release Planning Iteration Planning Daily Stand Up Iteration Demo Retrospective Attendance Product Product, Manager, Team Team Product, Manager, Team Product, Manager, Team Artifacts Key Dates, Definition Of Done, Organized Backlog Sprint Backlog Updated Radiator Velocity Retro Actions
26
Planning, Monitoring and Adapting ~10 / 50 -- User Stories

Card
Stories are traditionally written on note cards. May be annotated with notes, estimates, etc.
Conversations
Details behind the story come out during conversations with product owner
Confirmation
Acceptance tests confirm the story was coded correctly
Ron Jeffries, inventor of XP, one of 3 extremos

Planning, Monitoring and Adapting ~10 / 50 -- User Stories

Each user story is composed of 3 aspects:
Written description of the story (for planning) Epic Conversations about the story, as foundational knowledge forming the story Decomposed in to stories Theme Acceptance criteria which conveys and document details that can be used to determine when a story is complete
Organize: Epic, Story, Theme, Task (Mike Cohn)
27
Planning, Monitoring and Adapting ~10 / 50 User Stories
I N V E S T
- Dependencies lead to problems estimating and prioritizing - Can ideally select a story to work on without pulling in 18 other stories - Stories are not contracts - Leave or imply some flexibility - To users or customers, not developers - Rewrite developer stories to reflect value to users or customers
Because plans are based on user stories, we need to be able to estimate them
- Small enough to complete in one sprint if youre about to work on it - Bigger if further off on the horizon Testable so that you have a easy, binary way of knowing whether a story is finished Done or not done; no partially finished or done except

User Story Template (by Mike Cohn)
As a <type of user> I want <some goal> so that <some reason>.
28

Benefits of User Stories
Why?
29
Words are imprecise
More benefits!
30
Another benefit!
Exercise
1. Create a functional story for a new travel website. 2. Create a non-functional story.
31
32

Acceptance Criterion (Accrit)
Given <Precondition> When <Actor + Action> Then <Observable Result>.

Note: Accrit is NOT a replacement for test cases

The product backlog iceberg
33
Examples
Epics?
Clearly an Epic!
34
Planning, Monitoring and Adapting ~10 / 50 -- Prioritization
Why Themes?
Often individual stories cannot be prioritized against each other

Whats more important in a word processor?
The A key or the E key? Tables or undo?
Whats more important on a car?

The left front wheel or the right front wheel? Increased leg room or a larger engine?
35

Prioritization Techniques
MoSCoW Theme Screening Theme Scoring Relative Weighing / Value Based Kano

Typical Results
36

MoSCoW Principle
The requirement is essential, key stakeholder needs will not be satisfied if this requirement is not delivered and the timebox will be considered to have failed.
Musthave Shouldhave Couldhave
MUST can be considered a backronum from MinimumUsable SubseT This is an important requirement but if it is not delivered within the current timebox, there is an acceptable workaround until it is delivered during a subsequent timebox This is a nice to haverequirement; we have estimated that it is possible to deliver this in the given time but will be one of the requirements de-scoped if we have underestimated The full name of this category is Would like to have but Wont Have during this timebox; requirements in this category will not be delivered within the timebox that the prioritisation applies to
Won'thave

Theme Screening Example
+ = better than 0 = same as - = worse than

37

Theme Scoring Example

Relative Weighing / Value Based Prioritization
38
Relative Weighing / Value Based Prioritization

Kano Model
Must Haves
39

Kano Model: Surveying users (20-30)
M Mandatory L Linear E Exciter Q Questionable R Reverse I Indifferent
40

Kano Model: Aggregating Results
41
Planning, Monitoring and Adapting ~10 / 50 -- Velocity

Velocity
Forecasting Velocity
Initial Velocity for a new team Situation where you add new member
Tailor
42

Kanban Charts In Agile projects, it's a common practice to visualize and share project status in big visible charts on a wall of the project room. "Kanban," in Japanese means, loosely translated, 'card or sign'. A new card is "pulled" into the system only when the work represented by an "in progress" card is completed Visualization Charts
Kanban Boards: Use a card as a token (Kanban) of a task, story, feature and stick them to a timeline (board). There are several levels of granularities. Burndown Charts: Count the number of Kanbans (backlog tasks) and track it in a timebox to show the trend of work accomplished. There are also several levels of granularities. Parking lot Charts: Summarize the top-level project status. Calendars: there are a lot of variations of using calendars to show project status or plan
Planning, Monitoring and Adapting ~10 / 50 -- Kanban
Kanban Agenda.. 1. Kanban Board 2. Work-In-Progress (WIP) 3. WIP Limits 4. Cumulative Flow Diagram (CFD)
43

Kanban Board and WIP
~ Flow ~

WIP Limits
44

Cumulative Flow Diagram
Air Bubble = Low WIP
Example: A day in Kanban Land
45
TEST Your Knowledge

Q. How to assess initial velocity of an Agile Team
a) b) c) d)
Use Velocity of other similar team Use educated / calculated guess Use any random figure Initial Velocity of an Agile team should not be set
Answer: b
46
TEST Your Knowledge

Q. Which of the following is NOT a good user story attribute
a) b) c) d)
Small Testable Precise Valuable
Answer: c
TEST Your Knowledge

Q. Who sets the WIP Limits in Kanban?
a) b) c) d)
Developer Product Owner Team Project Manager
Answer: c
47

Certschool Certified Agile Practitioner Cs-Cap

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Certschool Certified Agile Practitioner Cs-Cap

Hochgeladen von

Copyright:

Verfügbare Formate

CertSchool Certified Agile Practitioner CS-CAP

Copyright 2011 CertSchool.com. All rights reserved.