Professional Documents
Culture Documents
Pre-Requisites
General understanding of Agile Methodology Agile Vs. Traditional PMI and ACP certification basics
Goal
Blueprint
Agile tools and techniques 50% Agile knowledge and skills 50%
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
Implement Enhancement
Yes
No
Agile Methods
Feature Driven Development (FDD) Dynamic Systems Development Method (DSDM) Adaptive Software Development (ASD)
More
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
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
Lean
12
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
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
Development Phase
Develop software
16
a) b) c) d)
Feature Driven Development Dynamic Systems Development Method Lean Development Spiral Model
Answer: d
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
a) b) c) d)
Answer: b
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
17
a) b) c) d)
Answer: B
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
a) b) c) d)
The Product Backlog The Sprint Backlog Both of the Above None of the Above
Answer: b
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
18
19
Communication ~ 10 / 50
Information Radiator
Effective Information Radiators are.. Simple Stark Current Transient Influential Highly Visible Minimal in number
Communication ~ 10 / 60
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
Communication ~ 10 / 60
Burn Up Chart: Story Points Completed Vs. Time
21
Communication ~ 10 / 60
Osmotic Communication
Rapid and Rich Feedback LOW cost-of-communication But HIGH Feedback Rate
Communication Modes
Communication ~ 10 / 50
22
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
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
Answer: a
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
23
Time Check
3/24/12 6:48 PM
24
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
Conversations
Details behind the story come out during conversations with product owner
Confirmation
Acceptance tests confirm the story was coded correctly
27
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
28
Why?
29
More benefits!
30
Another benefit!
Exercise
1. Create a functional story for a new travel website. 2. Create a non-functional story.
31
32
33
Examples
Epics?
Clearly an Epic!
34
Why Themes?
35
MoSCoW Theme Screening Theme Scoring Relative Weighing / Value Based Kano
36
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
37
38
Must Haves
39
40
41
Forecasting Velocity
Initial Velocity for a new team Situation where you add new member
Tailor
42
Kanban Agenda.. 1. Kanban Board 2. Work-In-Progress (WIP) 3. WIP Limits 4. Cumulative Flow Diagram (CFD)
43
~ Flow ~
Copyright 2011 CertSchool.com. All rights reserved.
44
45
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
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
46
a) b) c) d)
Answer: c
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
a) b) c) d)
Answer: c
Copyright 2011 CertSchool.com. All rights reserved. CertSchool Certified Agile Practitioner
47