Agile Scrum Workshop và và Professional Scrum Professional Scrum Master Master

Giới thiệu quy trình SCRUM & ứng dụng SCRUM vào phát trien phần mềm.

Trang 1

Chương trình đào tạo cho làm việc

nhóm trong phần mềm

Agile Scrum Workshop

Master

Trang 2

Tài liệu được biên soạn bởi Ông Amit Ranjan theo yêu cầu của Ban Quản lý các dự án công nghiệp công nghệ thông tin/Bộ TT&TT

- Forms of Agile(SCRUM, XP, Lean)

- SCRUM v/s Waterfall v/s Iterative

- Definition of Done

2 Coin Game(Waterfall v/s SCRUM) 1 Hands on - How to prepare Definition of Done 1 SCRUM Roles and Responsibility

Trang 3

Estimation Techniques(Relative Estimation, Poker) 1

Hands on exercise - Playing Poker 1 INVEST Model for Story Writing 1

Hands on exercise for Story writing and WBS 1

Trang 4

Agenda

Day - 3

SCRUM Meetings

- Release Planning Meeting

- Sprint Planning Meeting

- Daily Standup Meeting

- Sprint Review Meeting

Hands-on(Three Hour sprint game)Things to explain and learn:

- Sprint Planning Meeting

- Kanban Preparation

- Daily Standup Meeting

- Sprint Retrospective MeetingRole to perform and learn:

Trang 6

Trang 7

SCRUM

Trang 8

What is SCRUM?

• SCRUM is an interactive and incremental framework for project management based on

multiple self organized small teams(5-9 members) working in an intensive and interdependent manner within the specified Timebox.

• SCRUM is based on a "Sprint," which is a 2-4 weeks period for delivering a working part of the

system right through Concept to Executable.

• Developed by Ken Schwaber and Jeff Sutherland in the mid-1990s

• SCRUM objective is to deliver a product increment in a fixed time period called Sprint

Trang 9

We are uncovering better ways of developing software by doing it and helping

others do it Through this work we have come to value:

Trang 10

Trang 12

SCRUM v/s Waterfall Model

Time

Analysis Design Coding Testing

Trang 13

• All sprints are iterations but not all iterations are sprints

• Sprint is time bound, but iterations are not.

• Shippable code at the end of Sprint, may not be in case in iteration.

• Concept to code in a sprint, may not in case of iteration.

Trang 14

Projects Suited for Agile

The most appropriate projects for agile are, ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them

Novelty: If you are building the same

things over and over again, you have mastered the nuances You don’t need Agile

Urgency : Timeboxes and iterations

keeps the intensity and focus going

Complexity: Anything that requires that

extra bit of functionality or variation that

is unique.

Trang 15

SCRUM Roles : Pig and Chicken

Trang 16

Pigs

The Pigs are the ones committed to the project and performing the actual work

of the project

Product Owner

• Defines the product development roadmap.

• Prioritizes features for the product.

• Sets rules.

• Maintains enough details for each feature( story writing).

• Is open to the negotiation that will occur.

Trang 17

SCRUM Master (or Facilitator):

 Protect the team and keep them focused on the tasks in hand

 Remove impediments to the ability of the team to deliver the sprint

goal/deliverables.

 Is the enforcer of rules.

 Is the Moderator of the team.

 Represents the team in front of Stakeholders.

SCRUM Master Skills:

 Facilitating

 Listening

 Working towards self-organizing the team.

 Leading by serving.

Trang 18

Team

 Rest all constitute the team.

 Cross-functional.

 No hierarchy

 All share the same responsibility for delivery.

 Reports to SCRUM Master.

Trang 19

 “Chicken” roles

Chicken roles are not part of the actual Scrum process, but must be taken into account They are people for whom the software is being built.

 Stakeholders (customers, vendors)

These are the people who enable the project and for whom the project will produce the agreed-upon benefits, which justify its production.

They are only directly involved in the process during the sprint reviews.

 Managers

People who will set up the environment for the product development organizations.

Trang 20

◦ Defines the acceptance criteria for a user story.

◦ It states the deliverables that accompany each Product Backlog item.

◦ Applies to all stories.

◦ Set by Product Owner in discussion with SCRUM Team.

◦ Should be clear and self explanatory.

◦ Separate DOD for Story, Sprint and Release.

Trang 21

◦ All story should have automated acceptance test

◦ The story should have working code supported by unit test that provide around 60 – 70 percent coverage

◦ The story should have well defined acceptance criteria

◦ The code must have been written as a pair or should be code reviewed

◦ Code must be completely checked in to the source control system and the build should pass with all the automated tests running

◦ The product owner must accept the story

Trang 22

DOD for Sprint

◦ Product owner should have defined a sprint goal

◦ All stories completed for the spring must be accepted by the product owner

◦ All the automated acceptance tests should be running for the stories in the sprint

◦ The completed stories demonstrated successfully.

DOD for Release

◦ Product is deployed to the test box and makes it to staging

◦ Product has a formal release date

◦ There are deployment documents for the release

◦ Training manuals are available for users

◦ All stories for the release are completed and accepted

◦ The release does not have any level one bugs

Trang 23

◦ Is a high-level document for the entire project

◦ Contains backlog items: broad descriptions of all required features, wish-list items, etc

prioritized by business value.

◦ It is the “What” that will be built and not “How” or “Who”.

◦ Is the property of the Product Owner Business value is set by the Product Owner

Development effort is set by the Team

◦ Anyone can add to the Product backlog.

◦ A Product Backlog is never Done.

◦ Evolves over time.

◦ Should be described in just enough details that the team can complete in one sprint.

stories, features,

or bugs)

Trang 24

Trang 25

Priority Description (from Size

SizeTeam)

Value

(from Product Owner)

Trang 26

Priority Description (from Team)Size (from Product Value

Trang 27

2

Trang 28

Trang 30

Defined A high-level roadmap that forecasts “when we will

do what”

Owned by • Product Owner

Rules • Only the PO can prioritize the backlog

• Dependencies are offered by the team, must be considered

• Velocity (average output per sprint) is required to know how much to forecast for future sprints

Best

Practices • Realistic –Explains delivery dates as best case, worst case, most likely scenarios

• Fresh – Updated after each sprint

Trang 32

Release planning is all about

understanding what you're going

to do towards those themes in

the next release It is setting a

common understanding amongst

the teams on what the release

will likely look like It is not a

commitment, rather a projection

It helps to establish a common

baseline across the teams.

Trang 33

 Preparing for Release Planning

• Set themes

• Prepare the backlog

• Divvy stories up

• Understand the issues

• Identify key dates

• After a Release

• Do Release Retrospective

Trang 34

Calculate the team’s

total manhour capacity for

the upcoming Sprint

1 5 people x 2 wks x 6hrs/day: 300.0

Minus vacation: 224.0 Minus 20% Slack/ Risk Buffer: 179.2

Commitment Cap: 179.2

Add the manhour

estimates for all the Sprint

Backlog tasks

2

Compare the 2

numbers to help the team

confirm the commitment

Trang 36

Product Backlog

Prioritization

Trang 37

• Prioritization is a process of ranking user stories in

product backlog

• Highest customer value first

• Owned by Product Owner

• To be revisited whenever new requirement comes.

Trang 38

Trang 40

• The Sprint Backlog is an artifact of the Sprint Planning Meeting

• Is a document containing information about how the team is going to

implement the features for the upcoming sprint Features are broken down into tasks.

• Product Backlog's features are broken down into a Sprint Backlog

• Collect the agreed Sprint tasks in a sprint backlog.

• Team members sign up for tasks, they are not assigned.

• Estimated work is entered in the sprint backlog.

• Estimations are set by the Team.

• Can be updated by any team member during the sprint.

• The sprint backlog is the property of the Team

Trang 41

• Is a publicly displayed chart showing remaining work in the sprint backlog

• Updated every day, it gives a simple view of the sprint progress.

• Burn Down chart for Release.

Trang 42

Artifacts : KANBAN

 Kanban is a true PULL system implementation in software engineering

 Kanban is a Visual Card.

KANBAN Principles :

• Agree on a Team capacity

• Limit WIP to that capacity (WIP limits) ~ “Stop the line mentality”

• Measure and Optimize Flow

• Explicit Policies ( definition of done, WIP limits, etc)

• Make both work and workflow visible ( Kanban Board)

Trang 43

• What is Kanban

• Where did Kanban come from

• Kanban Principles

• Kanban and PULL system

• Class of services and Policies

• Kanban Board

• Kanban Metrics

• Velocity vs Lead Time

• Kanban and Scurm – Similarities and differences

Trang 44

 Kanban is a method that helps

• Establish a culture of continuos improvement

• Implement and scale Agile

• Enable evolutionary change

 Kanban is a true PULL system implementation in software

engineering

 Kanban is a Visual Card

Trang 45

 Roots: Lean

 Muda; Muri; Mura – Waste, Unreasonableness,

Unevenness

 Goals of Lean

• Leaning to recognize waste

• Enhances shareholder value – Improved ROIC

• Improves Quality

• Reduces Time

• Reduces Total Cost

Trang 46

• Agree on a Team capacity

• Limit WIP to that capacity (WIP limits) ~ “Stop the line mentality”

• Measure and Optimize Flow

• Explicit Policies ( definition of done, WIP limits, etc)

• Make both work and workflow visible ( Kanban Board)

Trang 47

• There is a queue of work, which goes through

a number of stages until it is done

• When work is completed in a stage, it goes downstream to the next stage

• When someone needs new work to do, they pull from upstream

Trang 48

 We:

• Don’t build features that nobody needs right now

• Don’t write more specs than you can code

• Don’t write more code than you can test

• Don’t test more code than you can deploy

Trang 50

• Agree on Goals

• Visualize the work

• Limit WIP

• Measure and manage Flow

• Make process policy explicit

• User models to identify improvement opportunities

Trang 51

• Both are Lean and Agile

• Both use Pull Scheduling

• Both limit WIP

• Both use transparency to drive process improvement

• Both focus on delivering releasable software early and often

• Both are based on self organizing teams

• Both require breaking the work into pieces

• In both, release plan is continuously optimized based on empirical

data (velocity / lead time)

 Reference :

http://www.infoq.com/minibooks/kanban-scrum-minibook

Trang 52

Trang 53

 Is how much product backlog effort a team can handle in one sprint

 It is measured in Story Points.

 Once established, velocity can be used to plan projects and forecast release and product completion dates

 Can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant

 Should not vary too much.

 How to establish velocity for a new team? :- Run 2-3 sprints without any set velocity Benchmark could be the mean velocity of first 3 sprints.

Trang 54

Story Points

◦ Sizing sequence should be geometric series: 1,2,4,8,16,32……

◦ Mike Cohen proposed Fibonacci series: 1,2,3,5,8

◦ Its relative data and not absolute.

◦ Advantage: Accuracy is less important than consistency.

◦ Disadvantage: Its team specific values and may not have any meaning for others.

T-Shirt Sizing

 S, M, L, XL

 Apply story points later.

 Good first step for tam to adapt Relative Sizing technique.

 Advantage: Easy to grasp.

 Disadvantage: Size vs Time comparison is difficult

Trang 56

Sheila Raj

Suresh Annie

3 8 2 5

1

Round 1

5 5 5 8

Round 2

www.planningpoker.com

Tiêu đề	Agile Scrum Workshop and Professional Scrum Master
Tác giả	Amit Ranjan
Trường học	Information Technology Projects Management Department, Ministry of Information and Communications
Chuyên ngành	Software Development Methodologies
Thể loại	Training Documents

Định dạng
Số trang	180
Dung lượng	17,19 MB