Wondershare EdrawMind
Galería de mapas mentales PMP-16 Scrum Agile Practice
- 47
- 1
PMP-16 Scrum Agile Practice
This mind map, Based on Xisai PMP mind map, Expand. This chapter is: PMP-16 Scrum Agile Practice At the same time, there are PMP test questions with relevant knowledge points. From knowledge points to corresponding test questions, It can deepen your understanding and memory of knowledge points!
Editado a las 2023-05-30 17:36:54,
- Recomendados
- Resumen
PMP-16 Scrum Agile Practice
Scrum Agile Practice
three pillars
Transparency, inspection, adaptation
Transparency
The key links in the process are obvious to the relevant people, and at the same time ensure that the stakeholders have a unified understanding of these links.
View
Scrum users must frequently review Scrum artifacts and progress toward completing Sprint goals, and the review frequency should be adapted to
Ensure that significant deviations in the process are detected promptly
adapt
If the inspection reveals that one or more aspects deviate from the acceptable range and would result in an unacceptable product, the process or procedural content must be adjusted.
Adjustments must be performed as quickly as possible to reduce further deviations
three characters
1. Product Owner
1. spokesperson, helmsman, acceptor
2. docking
Connect with customers (initiator), collect needs, and develop high-level customers (initiator)
3. PO Responsibilities
Focus on products
Guide product development direction
4. create
Product Backlog (or create with team)
5. sort
Prioritize tasks based on business value (above team members)
6. Monitoring needs
Clean, change requirements and sort according to actual situation
7. Participate in feedback
Participate in projects and give frequent and timely feedback
Identify "Completed User Stories"
2. Agile Coach
Catalyst, Old Hen, Defender
Key Point 1: Servant Leadership
Role positioning is auxiliary, servant-like and service-oriented
Point 2: Promotional effect
Promote cooperation and communication within and outside the team, and will not make decisions for others
Point 3: Intervene
1. When asked for help
2. When a team violates agile
3. Don’t know how to use agile tools
4. Self-resolving conflicts is ineffective
Key Point 4: Clear Organizational Obstacles
Does not interfere with product development direction and how to develop it
Key Point 5: Pave the way for others to contribute
Provide support and assistance to assist the team in solving problems and ensure the effectiveness of agile practices
3. Self-organizing teams
1. Self-organizing, generalist, transparent communication
Self-organizing characteristics
2. Focus on performance and self-management
Self-claimed tasks, constructive confrontation, no commitment to agile coaching
3. Number of people
3-9 players, plus or minus 2 changes
PO and SM are not included in the number of people
If there are too many people, the team can be split
4. Full-time
focus on one project
5. Generalist
Helps reduce bottlenecks, improve efficiency, and reduce silos/silos
6. Team member replacement
Generally, after a team is formed, it will not change, add or remove personnel at will.
If replacement is necessary, A better time is between two iterations
7. Office style
Centralized office preferred
Definition: Refers to the geographical location where the team works together
As opposed to virtual office
Advantage
Face to face communication
Promote penetrating communication
Definition: Information flows between team members who work together Share unconsciously
Information is shared unconsciously
Generally obtain information without direct attention, thereby reducing the cost of information transmission and communicating subtly.
Global, distributed teams
1. Can use virtual means, fish tank windows and remote pairing
1. fish tank window
By moving the team across locations, Establish long-term video conference links and create a fishbowl window
At the beginning of each day's work, open the link; at the end of the day, close the link
2. remote pairing
Establish remote pairings by using virtual meeting tools to share screens, including voice and video links
They are all communication technologies and methods that may be used in distributed teams
2. Use online collaboration tools (video, billboards) to assist communication
Common principles for CAVES and public areas
CAVES
It is a private space reserved for transactions and requires an isolated and quiet environment.
common areacommon
The public sphere is a public space where communication and collaboration often occur
8. Five stages of team building
form
Clarify team members’ roles and responsibilities
Directive
shock
produce conflicts
Influence/coach type
specification
Try to solve problems and work together
participative
Mature
Operate in an orderly manner like a mature unit and complete work efficiently
Authorization
Disband
The project ends and the team disbands
Tuckman's Ladder Theory
1. Formative stage
Increase resources, new members join the team, and get to know each other
2. shock stage
Different (opposing) opinions, conflicts, disputes and disagreements
3. Standardization stage
Work together, adjust working habits and behaviors according to work needs, and start to learn trust
4. mature stage
Cooperate and solve problems efficiently
5. dissolution stage
Disband the team and release people
9. How to cultivate generalist experts, how to become generalist experts
1. Knowledge sharing
2. Cross training, skills training
3. pair programming
4. Summary
The role of successful agile teams
product owner
1. Guide product development direction
2. Create and maintain product backlog
3. Order tasks according to business value
4. Provide feedback
team facilitator
1. Ensure agile processes are followed
2. Guide and coach the team and remove obstacles for the team
Cross-functional team members
1. Generalist expert with all necessary skills
2. Deliver potentially releasable products at a regular pace
3. Core responsibilities
Deliver tasks in a short time
three artifacts
list
1. Product Backlog
DEEP model
Organize the product backlog
Iteration 0
Create a Definition of Ready (DoR) for the Product Backlog
Definition of ready
It is a checklist for the team centered on user needs. This includes all the information the team needs to get started
Checklist
citation quality management
Checklist
The definition of Ready, the conditions that must be met in order to move user stories from backlog to development in the next Sprint
User story with ready defined state means the story must be immediately actionable
so ready state This means that granularity refinement is appropriate.
DoR and DoD
DoR (Definition of Ready)
Definition of ready
definition
Refers to a set of conditions or criteria that need to be met in order to start a task or function
effect
DoR helps ensure that the team has a clear understanding and consensus of the task or feature before implementation begins
DoR may include the following
1. Task or function
Descriptions are clear, specific, and detailed
2. Feasibility study and risk assessment
completed
3. Required resources (such as personnel, time, budget)
Assigned
4. Project requirements, goals and acceptance criteria
clarified
5. All relevant stakeholders have discussed tasks and functions
reach agreement
DoD (Definition of Done)
definition of done
definition
Refers to a set of conditions or criteria that need to be met before a task or function is considered complete.
effect
DoD helps ensure that teams complete tasks or functions to the expected quality and standards
DoD may include the following
1. The code has been written and passed code review
2. Function has passed all scheduled tests
unit test
Integration Testing
Performance Testing
3. Documentation completed and updated
User manual
Technical documentation
4. Issues and defects related to tasks or features
solved
Nature
An ordered list of all work, value-oriented
sort
1. Consider value risk
Delay cost: Understand the counter-value of delaying a task, Can help teams decide which tasks to complete first
2. Cost, dependency, politics, etc. may also be considered
Refinement and combing
Progressive detailing
content
functional content
non-functional content
Technical debt, risk response, operation and maintenance work, etc. are included in the backlog as non-functional user stories
Performance requirements
Key operational and performance requirements for the product
space shuttle weight
website load
Performance requirements are not specific to a single function, so they should not be placed in the acceptance test of a single function.
Performance requirements should have an overall acceptance test to ensure that the product passes the performance indicators
risk
A risk is an uncertain event that may affect the project if it occurs
In Agile, negative risk is equivalent to anti-value
Value is saving money, risk is spending money
If a risk occurs, time and resources will need to be spent to deal with it
It will also threaten the interests of the project.
agile
It is a combination of business value and risk drivers
Plan risk avoidance and transfer measures as early as possible
Agile projects continue to iterate and deal with high risks in the early stage
Let high risks be exposed early
In this way, the cost of risk response is relatively lower, and the possibility of ineffective work input at a later stage is reduced.
small risk-based experiments
It is a skill of risk management called spike.
Responsible
Mainly created and maintained by PO
Deep model
Detailed, appropriate, estimable, emergent, prioritized
Split
User stories that are too big need to be split
to ensure that it can be completed during the iteration
other
Function-driven development model (FDD)
1. There is no Product Owner role in this model
2. Main people present in FDD
1. Main developer
2. class owner
3. Feature Team
2. Iterate on the to-do list
Nature
The goals and work items that need to be completed in this iteration
Clarify specific tasks
The team will discuss and receive it on their own
time
Created in iteration planning meeting
in principle
During the iteration process, the iteration to-do list will generally not be changed at will.
First, ensure that the iteration tasks are successfully completed
Adjustment
If the user story is already clearly invalid
Or the current situation is urgent and failure to deal with it will jeopardize the entire iteration.
Adjustments can be made to the iteration backlog
3. Deliverable product increment
Shippable product increment is the user story actually completed in an iteration
Potential packaged product feature increment
Deliverable product increment, delivered value
Deliver value as early as possible to better respond to changes
five events
Meeting
1. Iteration and sprint
iteration timebox
Should be consistent with team capabilities and project characteristics
Once determined, it will not be adjusted at will
When requirements change frequently and customers require increased review frequency
Can shorten the overall iteration time box
8843
2. Iteration and sprint planning meetings
PDCA-P
do what
sprint planning meeting
1. It is to determine the iteration tasks and goals
iteration target
What the PO hopes to accomplish and achieve during a Sprint
The team can commit to completion
Iteration Backlog (Sprint Backlog)
2. Discuss how it is done
3. Output iteration backlog
4. Basic content of the meeting
1. Generally, the PO will explain the product backlog (product backlog) and refine the story, and the team will evaluate it and come up with the iteration backlog (sprint backlog).
2. Split user stories into tasks to estimate time
3. Team members’ own domain tasks (tasks)
4. Update sprint backlog
who participates
1. PO, development team, agile coach
PO explains the product backlog and refines the story
Team to evaluate and come up with an iteration backlog
2. When relevant parties want to understand the team plan and changes in demand goals Can be invited to sprint planning meetings
Relevant parties can understand
Team situation
Product situation
How long
Timebox 2X
One-month iteration cycle, sprint planning meeting time box is 8 hours/month
2 hours/week
Main points
3. Daily stand-up meeting
PDCA-D
do what
1. Purpose
Understand project status information (keep track of progress)
Understand the individual status of your team
consensus information
Eliminate information gaps
Identify problems, obstacles, risks
2. The daily stand-up meeting is one of the most important cornerstones supporting agile principles and cannot be canceled at will.
Synchronize information to provide work visibility and information sharing
Keywords: uninterrupted during iteration
How to open
1. Daily stand-up meetings are organized by the team themselves. The time and location are determined through discussion and discussion. Anyone can host the stand-up meeting.
2. The development team and agile coach will all participate in the meeting. The PO will be invited based on the situation, and relevant parties will be invited.
The development team and agile coaches all attended the meeting
3. Time box is usually 15 minutes
Because other reasons (cultural environment, etc.) affect the effectiveness of the meeting, the time can be extended appropriately, but generally not more than 20 minutes.
If there are too many people, consider dividing the team
4. Everyone takes turns answering questions
1. What have I accomplished since the last stand-up meeting?
2. What do I plan to accomplish between now and the next stand-up meeting?
3. What are my barriers (risks or issues)?
The station meeting only synchronizes information and raises questions, but does not solve them.
Solving problems can be arranged individually after daily stand-up meetings
anti-pattern
1. Not a status report meeting
2. Only discovering problems, not solving them
Problems can be solved through special discussion after the stand-up meeting
If it does not affect the current iteration goal and is related to the overall process, you can review the meeting to discuss improvements.
Test points
4. Iteration review meeting
PDCA-C
do what
At the iteration review meeting: 1.PO identification "completed", 2. The customer accepts the completed user story and gives feedback
Describe what was accomplished during the sprint iteration
Demonstrate completed work
The product owner, in principle, must be present
discuss
Expected next time
magnitude of change
Trend analysis
Unfinished or unaccepted user stories need to be negotiated and communicated before returning to the product backlog.
who participates
Product Owner, Key Customers, Agile Coach, Development Team
How long
One-month iteration cycle, meeting time box is 4 hours
4 hours/month
1 hour/week
The iteration review meeting mainly explains the completion of the work and demonstrates the "Complete" function.
Test points
5. Iteration review meeting
PDCA-A
do what
Examine yourself and pay attention to the process, Review the effectiveness of measures, find out the reasons, and propose improvement plans
Discuss what went well and potential areas for improvement
Summarize experiences and lessons learned to help the team adjust the process
Purpose
1. Review the situation of people, relationships, processes, and tools in the previous Sprint.
2. Identify and rank the main areas that have gone well and those that potentially need improvement.
3. Develop a plan to improve the way the Scrum team works
who participates
1. Typically team members, agile coaches
Agile coach ensures meeting
positive and productive
2. PO depends on the situation
3. Stakeholders are invited to participate
How long
After the iteration review and before the next iteration planning
One month iteration cycle, usually 3 hours
Scrum five values
Commitment, focus, openness, respect, courage
promise
commitment
Willingness to commit to goals
focus
focus
Dedicate yourself to the work you promised to do.
1. Team members are full-time and focused on this project
2. Remove obstacles so team members can focus on the project
3. In this round of iteration, focus on the iteration to-do list and do not replace it unless necessary.
open
openness
All information within the team is open to everyone
respect
respect
Everyone has his or her own unique values and experiences
courage
courage
Dare to make promises, fulfill commitments, dare to say no
other
Scrum is a single team process framework for managing product development
The framework includes Scrum roles, events, artifacts, and rules, and uses an iterative approach to deliver work products
Scrum is run on a time box of 1 month or less