Agile Scrum Training

AGILE SCRUM WORKSHOP

Author  :  Nguyễn  Thành  Châu   E-­‐mail:  [email protected]   Cell  phone:  (+084)918226449  

  Tài liệu được biên soạn bởi Nguyễn Thành Châu  theo yêu cầu của   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu theo yêu cầu của Ban quản các dựdựán nghiệp công nghệ thông Banlý quản lý các án công công nghiệp công nghệ thông tin - Bộ TT & TTtin - Bộ TT & TT  

Introductions and Expectations Participant introductions   v  Name v  Position and background v  How long experience with Agile-Scrum development? v  What do you want to get out of this course (expectation)?    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Who Am I ? q  20+ years of working experience in IT industry q  Conducted 50+ training courses related to Agile-Scrum, PM, BA, CMMI, ITIL, ISO 20k, ISO 27k. q  Consulted 20+ organization related to QMS, ISMS, ITSM q  Professional Scrum Master q  ISMS Lead Auditor q  ITIL Expert

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Logistics

EMERGENCY  

EXIT  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

4

Rules of Engagement Participate. One person speaks at any given time. Keep discussions and questions to the point. Turn on your cell phones and other communication devices to Silence mode. v  Be prompt returning from breaks. v  …… v  v  v  v 

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

5

AGENDA v  Traditional Software Development

v  Agile Requirement v  Testing in agile

v  Agile Introduction

v  Agile - Lean development

v  Agile Scrum Introduction

v  KanBan

v  Scrum Roles

v  Scaling and Distributed Scrum

v  Scrum Artifacts

v  Extreme Programming

v  Scrum Meeting

v  Agile For Manager

v  Agile Estimation

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

6

Schedule Day 1 : v Traditional Software Development v Agile Introduction v Agile Scrum Introduction v Scrum Roles

Day 2 : v Scrum Artifacts v Scrum Meetings v Agile Estimation

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

7

Schedule Day 3 : v  Agile Requirement v  Testing in agile v  Agile - Lean development Day 4 : v  Agile - Lean development v  KanBan v  Scaling and Distributed Scrum v  Extreme Programming

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

8

Schedule Day 5 : v  Agile For Manager v  Workshop summary v  Mockup exam

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

TRADITIONAL  SOFTWARE  DEVELOPMENT  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

10

Software Engineering

“ The application of a systematic, disciplined, quantifiable approach to development, operation and maintenance of software: that is, the application of engineering to software.” » IEEE Standard Computer Dictionary

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

11

Exercise 1: Explain waterfall model Traditional model: v  List all of phases of Waterfall model. Each phase will be written in a sticker. v  List all of roles of Waterfall model. Each role will be written in a sticker. v  List all of the tasks of Waterfall model. Each task will be written in a sticker. v  List all of problems, issues, or weaknesses of Waterfall model. Each problem, issue, or weakness will be written in a sticker.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

12

The Traditional Development

v  Analysis v  Design v  Coding v  Testing

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

13

Traditional Project Challenge

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

14

The Traditional Development - Assumptions Traditional model is a good fit when: v  Customer knows all requirements upfront v  Requirements are stable v  Technology is well known and mature v  The problem has been solved before v  Everything goes as per plan

How often are these true?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

15

What are the trusts ? v  The client doesn’t know what they want v  The client thinks they know what they want but are wrong v  We don’t understand what the client wants v  We think we understand but we are wrong v  We don’t know how to do it v  We thought we knew how but we were wrong v  Changes to external factors alter the objectives v  The client has learned along the way that they now want something different

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

16

Weakness of traditional software development method v  All good ideas should come in the beginning, a good idea at the release stage is a threat v  Emphasis on writing things down – leads to lack of clarity in thought and understanding v  Last minute correction not possible v  Unanticipated technical problems may lead to collapse in the model

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

17

The Traditional Process

Analysis   Time  

Design   Coding   Tes0ng  

(The  cost     of  change     increases)  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Do  we  have   ½       final  product   yet?  

18

Legacy of waterfall Model v  Ask Customers what they want §  When they really don’t know v  Reward them for thinking everything upfront §  And manage that as ‘scope’ v  Penalize them for adding things later §  Do strict ‘scope’ control

The result is over production of features

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

19

Features of traditional software v  Biggest cost of Predictive Development is over production of features v  Must be designed, built and maintained

Always   Used   7%  

Frequently   Used 13%

Never  Used   45%  

v  Don’t get used, provide no value

Rarely  Used   19%  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Some0mes   Used   16%  

20

AGILE INTRODUCTION

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

21

Video demo

20 Oracle Agile PLM Customer Results in 90 Seconds

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

22

What is Agile Software Development? In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized: v  close collaboration between the programmer team and business experts; v  face-to-face communication (as more efficient than written documentation); v  frequent delivery of new deployable business value; v  tight, self-organizing teams; v  and ways to craft the code.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

23

Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

24

Principles behind the Agile Manifesto

1 2 3

•  Our  highest  priority  is  to  satisfy  the  customer   through  early  and  continuous  delivery  of  valuable   so_ware

•  Welcome  changing  requirements,  even  late  in   development.  Agile  processes  leading  the  change   for  the  customer’s  compeccve  advantage.

•  Deliver  working  software  frequently,  from  a   couple  of  weeks  to  a  couple  of  months,  with  a   preference  to  the  shorter  cmescale.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

25

Principles behind the Agile Manifesto

4 5 6

•  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  conversacon.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

26

Principles behind the Agile Manifesto

7 8 9

•  Working  so_ware  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.

•  Concnuous  ahencon  to  technical  excellence  and   good  design  enhances  agility.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

27

Principles behind the Agile Manifesto

10 11 12

•  Simplicity  the  art  of  maximizing  the  amount   of  work  not  done  is  essencal.  

•  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.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

28

Agile Process

A  N  A  L  Y  S  I  S     D  E  S  I  G  N   C  O  D  I  N  G   T  E  S  T  I  N  G  

20%  done   100%  usable  

Time  

The  best  way  to  manage   ‘scope’  is  to  write  less   code!     •   Develop  20%  of  features   that  deliver  80%  values   • Develop  and  deploy   highest  priority  first     • Stop  when  you  run  out  of   0me  or  money      

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

29

Waterfall Model vs. Agile Process Waterfall Model

Agile Process

Analysis  

Analysis  

Design  

Design  

Coding   Tes0ng   Time  

Coding   Tes0ng   Time  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

30

Some advantages of the Agile approach v  The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development project. v  The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project. v  If time to market for a specific application is a concern, Agile can more quickly produce a basic version of working software. v  Development is often more user-focused, likely a result of more and frequent direction from the customer

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

31

Some disadvantages of the Agile approach v  The very high degree of customer involvement may present problems for some customers who simply may not have the time or interest for this type of participation. v  Agile works best when members of the development team are completely dedicated to the project. v  Time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the Timeboxed. Additional sprints may be needed, adding to the project cost.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

32

Some disadvantages of the Agile approach The iterative may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

33

Exercise 2: Drawing a picture Draw a picture based on Waterfall model – 20 minutes v  Customer looks at a picture carefully. v  Customer explains the picture to the team. v  The team listen requirement from customer and take a note. v  The team draw a picture.

Draw a picture based on Agile – 20 minutes v  Customer looks at a picture carefully. v  Customer joins with the team to draw the picture. v  Every 5 minutes, customer can look at the original picture and come back with the team.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

34

Exercise 2: Drawing a picture

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

35

Exercise 2: Drawing a picture

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

36

How to deliver project?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

37

Agile Methods v  Scrum v  Extreme Programming v  Adaptive Software Development (ASD) v  Dynamic System Development Method (DSDM) v  Feature Driven Development (FDD) v  Lean Software Development v  Lean/Kanban v  …

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

38

Video demo 1. Five Levels of Agile Planning 2. Agile vs Traditional System Development

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

39

AGILE SCRUM INTRODUCTION Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

40

SCRUM The agility way…. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

41

Video demo

1. Scrum Master Training

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

42

History of Scrum v  1995 §  Analysis of common software development processes not suitable for empirical, unpredictable and non-repeatable processes §  Design of a new method: Scrum by Jeff Sutherland and Ken Schwaber §  Enhancement of Scrum by Mike Beedle and combination of Scrum with extreme programming v  1996 §  Introduction to Scrum at the OOPSLA conference v  2001 §  Publication of the Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

43

What is Scrum used for? v  US FDA-approved software for X-Rays, MRIs v  High availability systems (99.9999% uptime) v  Enterprise workflow systems v  Financial payment applications v  Large database applications v  Embedded systems v  ISO 9001 organizations v  CMMi Level 5 organizations v  Onshore / offshore development

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

44

Who is using Scrum?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

45

Even the Government is doing it…

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

46

Share

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

47

What is Scrum? “Scrum is a framework for developing complex product and systems. It is grounded in empirical process and control theory. Scrum employs an iterative and incremental approach to optimize predictability and control risk.” - Ken Schwaber

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

48

A Management Framework v  Scrum is a management framework for incremental product development using one or more cross-functional, self- organizing teams of about seven people each. v  It provides a structure of roles, meetings, rules, and artifacts. v  Teams are responsible for creating and adapting their processes within this framework. v  Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long. v  Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

49

Scrum Framework v  Scrum is designed to add energy, focus, clarity, and transparency to project planning and implementation. It will: §  Increase speed of development §  Align individual and corporate objectives §  Create a culture driven by performance §  Support shareholder value creation §  Achieve stable and consistent communication of performance at all levels §  Enhance individual development and quality of life

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

50

Scrum Has Three Legs

We  all  know  what     Is  going  on  

Transparency  

Adaptacon  

Check  your  work   as  you  do  it.    

Inspeccon  

OK  to  change   tacccal  direccon   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

51

Scrum Values v  Commitment

Scrum asks you to commit to a goal and then provides you with the authority to meet those commitments.

v  Focus

It insist that you focus all your efforts on the work you’re committed to and ignore anything else.

v  Openness

Openness is prompted by the fact everything about a scrum project is visible to everyone.

v  Respect

Scrum tenets acknowledge that the diversity of team members’ background and experience adds value to your project.

v  Courage

Finally, Scrum asks you to have courage to commit , to act, to be open and expect Respect Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

52

Scrum framework

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

53

Product Owner

•   Product    Owner    decides    what    should    be    produced    so    as     to  achieve  success     SPRINT   •  Gets    inputs    from    end    users,    team    managers,  stakeholders,   execucves,  industry  experts  etc     NO  CHANGE  

uracon  or  Goal   •  Produces  the  product  in  bDacklog   which  contains  the  features  of   the  product  to  be  produced  in  order  of  priority  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

54

Product Backlog

•   The  Product  Backlog  is  the  single  master  list  of  features,   funcconality  etc…  prioriczed  based  on  business  value  and  risk       •   The  Product  Backlog  is  constantly  being  revised  by  the  Product   Owner,  to  maximize  the  business  success  of  the  team’s  efforts  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

55

Scrum Team

•   Ideally  consists  of  7+/-­‐  2  people     •   The  team  has  to  be  cross  funcconal  –   containing  members  from  the  different   verccals  required  for  developing  the   product     • The    team    is    self    organizing    and    self     managing    –    makes    a  commitment  and   manages  its  responsibilices  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

56

Sprint

•   Sprint  is  referred  to  the  fixed  period  of   cme  the  team  commits  to  work  in  course   of  developing  the  product       • The    length    of    the    sprint    is    decided    by     the  Team    and    the    Product  Owner       • Working  at  a  sustainable  pace  is   important  to  avoid  burn  out  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

57

Sprint Planning Meeting

•   Before  each  Sprint,  the  team  selects  what  it   will  commit  to  deliver  by  the  end  of  the  Sprint.     •   The  team  creates  a  task-­‐level  plan  for  how   they  will  deliver.       •   The  team  works  together  to  create  an  inical   assignment  of  tasks,  and  compares  total   escmated  task  hours  with  total  escmated   available  hours,  to  make  sure  the  commitment   is  reasonable.     • Everyone  on  the  team  takes  part,  regardless   of  experience-­‐level  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

58

Sprint Backlog

•   The  Sprint  Backlog  lists  all  the  tasks,  and  the  hours   remaining  for  each.     • The  Task  Board  shows  where  tasks  are  in  progress.   •  The Sprint Backlog is updated every day by team member  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

59

The “no change” of Sprint

•   During  the  Sprint,  what  the  team   commihed  to  deliver  does  not  change,   and  the  end-­‐date  of  the  Sprint  does   not  change.     •  This  enables  team  to  make  and  keep   commitments,  it  gives  the  team  focus   and  stability  during  the  Sprint,  and  it   trains  Product  Owner  to  clearly  think   through  what  is  on  the  Product   Backlog.     •  If  something  major  comes  up,   Product  Owner  can  direct  the  team  to   terminate  the  Sprint  prematurely,  and   start  a  new  one  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

60

The “no change” of Sprint (continue)

•  In  return  for  not  making  changes   during  the  Sprint,  Product  Owner  can   make  any  changes  they  want  to  the   Product  Backlog  before  the  start  of  the   next  Sprint.     •  Product  Owner  can  add,  remove,   reorder,  or  change  items.  They  can  also   ask  the  team  to  re-­‐implement  work   that’s  already  been  completed.  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

61

Daily Standup Meeting

Each  day,  the  team  has  a  short  meecng  to  update   each  other  on  progress  and  surface  blocks.  They  stand   up,  to  keep  it  fast.     •  To  keep  the  meecng  to  15  minutes,  everyone   reports  just  3  things:  done  since  yesterday,  done  by   tomorrow,  and  blocks.   •  Scrum  Master  notes  blocks,  and  a_erwards  helps   resolve  them.     •  Others  can  ahend  the  meecng  if  the  team  invites   them,  but  they  do  not  speak.  This  meecng  is  not  for   monitoring  team  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

62

Burnt-down Chart

Each  day,  the  team  updates  simple  charts  that   make  visible  how  they  are  progressing  towards   their  goal  for  the  Sprint.     •  The  Sprint  Backlog  lists  all  the  tasks,  and  the   hours  remaining  for  each.  The  Burn-­‐down  Chart   graphs  the  total  hours  le_  for  all  tasks.  The  Task   Board  shows  where  tasks  are  in  progress.     •  These  charts  enable  the  team  to  successfully   self-­‐manage  and  deliver  what  they  commihed  to   by  the  end  of  the  Sprint    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

63

Scrum Master

The  ScrumMaster  is  a  new  role.  It  can  be   played  by  an  exiscng person  (such  as  a   former  Project  Manager  or  team-­‐member).     •  The  ScrumMaster  serves  the  team   (helping  them  remove  any  and  all   impediments  that  surface),  protects  the   team  (from  any  outside  disrupcon  or   interference),  and  teaches  and  guides  the   team’s  use  of  Scrum.     •  Without  a  ScrumMaster,  the  team  has  a   high  risk  of  failure.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

64

Finished Work

The  aim  for  the  team  is  to  complete  100%  of  what  they   commihed  to,  ideally  an  increment  of  Potencally   Shippable  Product  at  the  end  of  each  Sprint.     •  For  so_ware,  this  means  funcconality  that  has  been   designed,  fully  implemented,  and  fully  tested,  with  no   major  defects.     •  Few  teams  can  do  product  Potencally  Shippable  Product   from  Sprint  1,  but  each  Sprint  they  work  to  get  closer  to   this  goal.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

65

Sprint Review Meeting

At  the  end  of  the  Sprint,  the  Product  Owner,  Team,  Scrum  Master,   and  Stakeholders  come  together  and  see  a  demo  of  what  the  team   has  produced.     •  The  Product  Owner  gathers  feedback  from  everyone  on  ways  to   improve  what’s  been  built.     •  This  feedback  is  incorporated  into  the  Product  Backlog.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

66

Sprint Retrospective

The  Team,  Product  Owner,  and  Scrum  Master  meet  at  the  end  of   each  Sprint  to  review  their  way  of  working,  and  look  for  ways  to   improve  their  effeccveness.     •  This  is  the  mechanism  for  concnuous  improvement,  and  also   where  criccal  problems  are  idencfied  and  addressed,  or  surfaced  to   management  for  assistance  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

67

Components of Scrum

Scrum   Ar0facts  

Scrum   Roles  

Scrum   Ceremonies   (Events)  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

68

Benefits of Scrum v  Improvement Statistics:

§  Productivity Improvement – 68% §  §  §  § 

Team Morale – 52% Adaptability – 63% Accountability – 62% Collaboration and Cooperation – 81%

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

69

Challenges of Scrum v  Inability to get everyone involved with planning v  Failure to have dedicated roles –Scrum Master, Product Owner and Team v  Product Owner that isn’t ready for the team v  Teams lacking authority and decision-making ability v  Ineffective use of the retrospection v  Obtaining only “checkbook commitments” from executive management v  Failure to pay attention to infrastructure required v  A culture that does not support learning

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

70

Summary v  It is an iterative, incremental framework v  Sprints – cycles of work developed, duration 2 – 4 weeks; occur one after another without pause v  Time-boxed – they end whether or not the work ends v  At the beginning, cross-functional team forms the priority list based on customer requirements v  During the sprint the chosen items do not change v  Everyday inspection and adjustment v  End of the sprint, review with stakeholders v  Feedbacks are taken and incorporated into the sprint v  End of sprint, fully tested product is formed as per customer requirements Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

71

Video demo

1. Scrum introduction

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

72

Exercise 3: SCRUM Roles SCRUM: v  List all of roles of SCRUM. Each role will be written in a sticker. v  Put all of the tasks of Waterfall model match to SCRUM roles.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

73

SCRUM ROLES Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

74

Scrum Roles

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

75

Story of Pig and Chicken

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

76

Roles - Chickens v  “Chicken” roles Chicken roles are not part of the actual Scrum process, but must be built. v  Stakeholders (customers, vendors) These are the people who enable the project and for whom the project They are only directly involved in the process during the sprint reviews. v  Managers People who will set up the environment for the product development organizations.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

77

Roles - Pigs

Product   Owner  

Scrum   Master  

Scrum   Team  

Pigs

The Pigs are the ones committed to the project and performing the actual work of the project.   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

78

Product Owner Role v  Single person responsible for maximizing the return on investment (ROI) of the development effort v  Responsible for product vision v  Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans v  Finalize the answer for requirements questions v  v  v  v 

Accepts or rejects each product increment Decides whether to ship Decides whether to continue development Considers stakeholder interests

v  May contribute as a team member v  Has a leadership role Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

79

Product Owner Role The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog, includes: v  Clearly expressing Product Backlog items; v  Ordering the items in the Product Backlog to best achieve goals and missions; v  Optimizing the value of the work the Development Team performs; v  Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, v  Ensuring the Development Team understands items in the Product Backlog to the level needed. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

80

As a Scrum Product Owner You… v  Hold the vision for the product on behalf of the business, the customer, and the user. v  Represent the interests of the business to the team. v  Represent the product and the team to the business. v  Communicate with stakeholders regularly. v  Write user stories. v  Help others write user stories. v  Understand the business value of each user story. v  Assign numeric business value to each user story. v  Prioritize the user stories into a strictly ordered backlog.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

81

As a Scrum Product Owner You…(continue) v  Identify acceptance criteria for each story. v  Collaborate with the rest of the team to create the team’s definition of done. v  Accept or reject completed work, determining whether it has met the acceptance criteria. v  Resolve conflicting requirements from stakeholders. v  Provide the information that the team needs to estimate each story. v  Make yourself available to answer the team’s questions about requirements and business value. v  Make the call in the rare instances when a sprint needs to be terminated early.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

82

As a Scrum Product Owner You…(Continue) v  Clarify requirements for the team. v  Lead the first part of the sprint planning meeting. v  Lead the story time meetings. v  Gather feedback from stakeholders at the sprint review. v  Do not hold the role of scrum master. v  Do not do implementation work. v  Do not tell the team how to do the work. v  Do not estimate stories

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

83

Video demo 1. The Impatient Product Owner

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

84

Exercise 4: Product Owner Role SCRUM: v  List all of the tasks of a product owner and put the tasks under Product Owner role on the board.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

85

Scrum Team

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

86

The Development Team role The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. v  They are “self-organizing” v  They are “cross-functional” v  They decides “what to commit to” v  Scrum recognizes no titles for Development Team members v  Scrum recognizes no sub-teams in the Development Team, v  Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

87

The Development Team role (Continue) v  One team normally does all the work - planning, analysis, programming, and testing v  Negotiates commitments with the Product Owner, one Sprint at a time v  Develops the product and gives ideas to the product owner v  Has autonomy regarding how to reach commitments v  Intensely collaborative v  Most successful when located in one team room, particularly for the first few Sprints v  Normally contain 7+ or – 2 people v  Avoid multi-tasking, avoid member changing

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

88

The Development Team Responsibilities v  The Scrum Team is responsible for the high-quality and timely delivery of sprint commitments in line with the expectations of the Product Manager and Product Owner. v  The Scrum Team is cross-functional and multi-skilled they know their strengths and work together to support each other through challenging times. v  The team members are not all experts in every area, however between them they have a wide range of abilities and areas of expertise. v  The Scrum Team takes responsible for their commitments and are held singularly accountable for their actions and decisions -- they are as one.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

89

The Development Team Responsibilities v  The Scrum Team demonstrate their output to the Product Manager and relevant Product Owner(s) and Stakeholders at the end of each Sprint. v  The Scrum Team self-organize in order to deliver Sprint commitments. they do whatever is required in order to deliver the highest quality/value output during a sprint. [PROACTIVE] v  Question the Product Manager/Product Owner to ensure they fully understand the requirements of the Product Owner and end-user

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

90

Video demo

1. Team Work - https://www.youtube.com/watch?v=o9mdHMtxOjY

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

91

Exercise 5: SCRUM Team Role SCRUM: v  List more the tasks of a SCRUM team and put the tasks under SCRUM TEAM role on the board.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

92

Scrum Master

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

93

Scrum Master role v  The Scrum Master is responsible for ensuring Scrum is understood and enacted by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. v  The Scrum Master is a servant-leader for the Scrum Team. v  The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. v  The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

94

Scrum Master role v  Facilitates the Scrum process v  Creates an environment conducive to team self-organization v  Captures empirical data to adjust forecasts v  Enforces time-boxes v  Keeps Scrum artifacts visible v  Promotes improved engineering practices v  Has no management authority over the team v  Has a leadership role

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

95

As A Scrum Master You… v  Serve as the keeper of the scrum process, “holding space” for the team. v  Provide facilitation for team meetings during the sprint this can mean leading them yourself, recruiting an outside facilitator, or helping the team facilitate their own meetings. v  Know when to step back and let the team learn through their own experience, including mistakes. v  Are available to the team and the product owner to answer questions and give advice. v  Protect the team from outside distractions, serving as a buffer between the team and external stakeholders. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

96

As A Scrum Master You… v  Remove impediments for the team, so they can get on with the work. v  Are not the boss. Your role is defined by a unique set of responsibilities, not by rank. v  Act as an advocate for the team to the business. v  Coach the product owner in scrum practices. v  Help the team master the use of scrum artifacts, like the task board, the sprint backlog, and burn charts. v  Coach the team, and individual team members, in scrum practices.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

97

As A Scrum Master You… v  Lead the daily scrum until the team members are comfortable running it by themselves. v  Run the second half of the story time meeting, or assist the team members in running it themselves. v  Provide facilitation for, and participate in, the sprint retrospective. v  Are not the scrum police! You’re not there to tell the team what they’re doing wrong. v  Ensure that your duties as a technical contributor.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

98

Scrum Master Skills v  Facilitating. v  Listening. v  Working towards self-organizing the team. v  Leading by serving.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

99

Video demo 1. The Power of Scrum Master

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

100

Exercise 6: SCRUM Master Role SCRUM: v  List all of the tasks of a SCRUM Master and put the tasks under SCRUM Master role on the board.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

101

SCRUM ARTIFACTS

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

102

Product Backlog v  Is a high-level document for the entire project. v  Force-ranked list of desired functionality v  Contains backlog items: broad descriptions of all required features, wishlist items, etc. prioritized by business value. v  Visible to all stakeholders v  Any stakeholder (including the Team) can add items to Product Backlog. v  Constantly re-prioritized by the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team. v  Items at top are more value than items at bottom v  Maintained during the Backlog Refinement Meeting v  A Product Backlog is never Done.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

103

Product Backlog

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

104

Product Backlog

Product Backlog items (user stories, features, or bugs)

Items are listed in top-down priority order

-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐  

#  

-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐  

#  

-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐  

#  

-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐  

#  

Estimate for each backlog item

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

105

Product Backlog

Priority

Description

Size

Value

(from SizeTeam)

(from Product Owner)

1

Feature A

3

Extra-High

2

Feature B

5

Extra-High

3

Feature C

3

High

4

Feature D

8

Extra-High

5

Feature E

5

High

6

Feature F

2

Medium

7

Feature G

13

High

8

Feature H

3

Low

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

106

Product Backlog

Priority

Description

Size

Value

(from Team)

(from Product Owner)

1

Feature A

3

Extra-High

2

Feature B

5

Extra-High

3

Feature C

3

High

4

Feature D

8

Extra-High

5

Feature E

5

High

6

Feature F

2

Medium

7

Feature G

13

High

8

Feature H

3

Low

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

107

Product Backlog Item (PBI) v  Specifies the what more than the how or who of a customer-centric feature v  Often written in User Story form v  Has a product-wide definition of done to prevent technical debt v  May have item-specific acceptance criteria v  Effort is estimated by the team, ideally in relative units (e.g., story points)

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

108

Product Backlog Item (PBI)

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

109

Product Backlog- Video demo 1. Populate Product Backlog 2. Prioritize Backlog

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

110

Exercise 7: Develop a Product Backlog Product Backlog: v  Each team will discuss and develop a product backlog for a specific software project such as develop a website for a training center. v  Each product backlog item will be written on a stick note and put on a board.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

111

Sprint Backlog v  Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting v  Scope commitment is fixed during Sprint Execution v  Initial tasks are identified by the team during Sprint Planning Meeting v  Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution v  Visible to the team v  Referenced during the Daily Scrum Meeting

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

112

Sprint Backlog

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

113

Sprint Task v  Specifies how to achieve the PBI’s what v  Requires one day or less of work v  Remaining effort is re-estimated daily, typically in hours v  During Sprint Execution, a point person may volunteer to be primarily responsible for a task v  Owned by the entire team; collaboration is expected

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

114

Sprint Task

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

115

Sprint Video demo 1. Populate Sprint Backlog 2. Sprint

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

116

Monitoring Sprint Progress v  Make the daily sum of remaining work v  Create trend v  Post for high visibility v  Reflects Development Team intuition v  Burn down charts are common

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

117

Sprint Burn down Chart v  Indicates total remaining team task hours within one Sprint v  Re-estimated daily, thus may go up before going down v  Intended to facilitate team self-organization v  Fancy variations, such as itemizing by point person or adding trend lines, tend to reduce effectiveness at encouraging collaboration v  Seemed like a good idea in the early days of Scrum, but in practice has often been misused as a management report, inviting intervention. The Scrum Master should discontinue use of this chart if it becomes an impediment to team self-organization.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

118

Sprint Burn down Chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

119

Definition of Done v  Agile teams make an agreement on what criteria potentially shippable software in their environment. This agreement is called the definition of done. v  The DoD serves as a contract the delivery team writes with its stakeholders as well as the team’s standard of excellence. v  Creating the Definition of Done is a collaborative effort between the Scrum Master, Delivery Team and Product Owner. v  The initial Definition of Done can be created before or during the future iteration planning meeting, and continually revisited in future iteration planning meetings.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

120

Definition of Done (DOD) v  Defines the acceptance criteria for a user story. v  It states the deliverables that accompany each Product Backlog item. v  Applies to all stories. v  Set by Product Owner in discussion with SCRUM Team. v  Should be clear and self explanatory. v  Separate DOD for Story, Sprint and Release.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

121

Exercise 8: Develop a DOD for Story Definition of Done: v  Each team will discuss and develop a DOD for story.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

122

Sample DOD for Story v  All story should have automated acceptance test. v  The story should have working code supported by unit test that provide around 60 – 70 percent coverage. v  The story should have well defined acceptance criteria. v  The code must have been written as a pair or should be code reviewed. v  Code must be completely checked in to the source control system and the build should pass with all the automated tests running. v  The product owner must accept the story.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

123

Sample DOD for Sprint v  Product owner should have defined a sprint goal. v  All stories completed for the spring must be accepted by the product owner v  All the automated acceptance tests should be running for the stories in the sprint. v  The completed stories demonstrated successfully.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

124

Sample DOD for Release v  Product is deployed to the test box and makes it to staging v  Product has a formal release date. v  There are deployment documents for the release v  Training manuals are available for users. v  All stories for the release are completed and accepted. v  The release does not have any level one bugs.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

125

DoD Video demo

1.      Agile  in  Praccce_  Definicon  of Done  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

126

• 

Tài liệu được biên soạn bởi Ông Đoàn Đức Đề 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

SCRUM MEETING Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

127

Sprint Planning

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

128

Sprint Planning meeting v  The purpose of the Sprint planning meeting is for the team to commit to the completion of a set of the highest ranked product backlog items. v  This commitment defines the Sprint backlog and is based on the team’s velocity or capacity and the length of the Sprint timebox The sprint planning meeting is to v  Establish goals for your sprint. v  Choose the user stories that support those goals. v  Break user stories into specific development tasks. v  Create a sprint backlog.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

129

Sprint Planning Meeting v  Iteration planning is a collaborative effort involving these roles: §  Scrum Master - facilitates the meeting §  Product Owner - represents the detail of the product backlog items and their acceptance criteria §  Delivery Team/Agile Team - define the tasks and effort necessary to fulfill the commitment There are two sections in the Sprint planning meeting 1. Setting goals and choosing user stories 2. Creating tasks for the sprint backlog • 

@   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

130

Setting goals and choosing user stories During a sprint planning meeting, the product owner and development team, with support from the scrum master: v  Discuss and set a sprint goal: The sprint goal should be an overall description supported by the highest-priority user stories in the product backlog. v  Review the user stories: Review the user stories from the product backlog that support the sprint goal and revisit and adjust the effort estimates as necessary. v  Determine what the team can commit to in the current sprint: The development team should agree and confirm it can complete the goal planned for this sprint.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

131

Creating tasks for the sprint backlog v  Creates the sprint backlog tasks associated with each user story: Break the user stories into discrete individual tasks and allocate a number of hours to each task. v  Double-checks that the team can complete the tasks in the time available in the sprint: Be careful about over- committing at the beginning of a sprint, especially in the project's first few sprints. Note : If the tasks exceed the hours available, seek the project owner’s advice on which user stories to remove from this sprint.

v  Each member chooses a first task to accomplish: Development team members should work on only one task on one user story at a time

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

132

Sprint Planning Meeting v  The maximum time for planning a 30-day Sprint is eight hours, reduced proportionally for a shorter Sprint.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

133

Sprint Planning 1              Calculate  the  team’s  

total  manhour  capacity  for   the  upcoming  Sprint  

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    

2              Add  the  manhour  

estimates  for  all  the  Sprint   Backlog  tasks  

3              Compare  the  2  

numbers  to  help  the  team   confirm  the  commitment   is  reasonable   179 ≈ 176 è J Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

176  

134

Sprint Planning – Best Practice

Divide the Planning into 2 Halves

•  In the first half, the Product Owner briefs the team on the next priorities from the Product Backlog, and the Team selects a set of items they deem reasonable •  In the second half, the team decomposes the commitments into the Sprint Backlog of action items and tasks needed to accomplish those commitments

Defer Task Assignments

•  Many teams spend too much effort pre-assigning Sprint Backlog action items to Team Members, often causing the Sprint Planning to last many hours too long. •  Consider leaving the task assignments until later. This will allow Team Members the opportunity to self-assign the tasks, generating more buy-in.

Defer Unknown Details

•  The Sprint Backlog is an imperfect living work plan. 30-40% of the Sprint Backlog tasks will change over the course of the Sprint. •  Consider deferring the task definition for those things that are not fully understood, and simply

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

135

Video demo

1.      How  to  improve  your  Scrum  Sprint Planning   2.      Agile  in  Praccce_  Prioricsacon using  MoSCoW  

 

 

   

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

136

Daily Scrum

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

137

Daily Scrum

Same   cme   Every   day  

Same   place  

Daily   Scrum  

15   minutes  

Each team member summarizes v  What did you do yesterday? v  What will you do today? v  Are there any impediments in your way? • 

 

 

 

 

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

138

Daily Scrum v  The daily stand-up should be time-boxed. v  The Scrum Master should facilitate regular daily meeting times. Don't change the time of this meeting if you can avoid it; Scrum requires discipline. v  Each member of the team should participate in this meeting v  Don't update the sprint backlog during this meeting. v  Team members should be active listeners so they know how the team as a whole is doing, and so they can help one another resolve impediments. v  Ensure that each team member remains present till the end of the meeting because of the purpose of the stand-up is to understand how well we're doing to achieve sprint goals as a team. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

139

Video demo

1.  How  to  improve  your  Daily  Scrum  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

140

Sprint Review

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

141

Sprint Review Meeting v  After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product increment to the Product Owner and everyone else who is interested. v  The meeting should feature a live demonstration, not a report. v  The Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he now considers done. v  The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items. v  The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend v  Four-hour time limit

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

142

Sprint Review - Video demo

1.  How  to  improve  your  Review Meecng  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

143

Sprint Retrospective

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

144

Sprint Retrospective Meeting v  All team members reflect on the past sprint v  Make continuous process improvements v  Two main questions are asked in the sprint retrospective: §  What went well during the sprint? §  What could be improved in the next sprint? v  Three-hour time limit v  This meeting is facilitated by the Scrum Master

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

145

Common impediments and Mistakes Common impediments v  A common impediment to full transparency on the team is the presence of people who conduct performance appraisals v  The human tendency to jump to conclusions and propose actions too quickly v  The psychological safety is geographic distribution

Common mistakes v  Mistake 1: Retrospectives become a dull and boring routine. v  Mistake 2: Too many non-actionable improvements. v  Mistake 3: Focus on what can NOT be changed next sprint Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

146

Retrospective - Video demo

1.  How  to  improve  your  Retrospeccve  meecng  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

147

Backlog Refinement meeting

SPRINT  

NO  CHANGE  

in  Duracon  or  Goal  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

148

Backlog Refinement Meeting v  Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. v  Teams have found it useful to take a little time out of every Sprint to help prepare the Product Backlog for the next Sprint Planning Meeting. v  It is common to write Product Backlog Items in User Story form. v  Agility requires learning to split large epics into user stories representing very small product features v  The Backlog Refinement Meeting lacks an official name and has also been called “Backlog Grooming,” “Backlog Maintenance,” or “Story Time.”

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

149

Story, Theme, Epic

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

150

Backlog Refinement Meeting

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

151

Backlog Refinement - Video demo

1.  How  to  improve  Scrum  Backlog Refinement  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

152

The Sprint v  The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. v  Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

153

Sprint Goal v  A Sprint’s Goal is fixed and may not change • Decrease  upstream  payloads  by  30%  

Decrease  upstream   payloads  by  30%  

• Deliver  a  minimal  set  of  administra0on  features  

run     n o 0 plica p a   e  in   k e c i v Ma r L  Se on  SQ  to  Oracle   on ad d i 0

Increase  find  acc search  b uracy  of   y  20%  

Deliver  a  minimal  set  of   administra0on  features  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

154

During Sprint v  No changes are made that would endanger the Sprint Goal; v  Quality goals do not decrease; and, v  Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

155

Canceling a Sprint v  A Sprint can be cancelled before the Sprint time-box is over. v  Only the Product Owner has the authority to cancel the Sprint.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

156

Release Planning

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

157

Purpose of Release Planning v  To make visible as much as is known about the desired release. v  Its purpose is not to make commitments. Release planning is a collaborative effort involving these roles: v  Scrum Master - facilitates the meeting v  Product Owner - represents a general view of the product backlog v  Delivery Team/Agile Team - provide insights into technical feasibility and dependencies v  Stakeholders - act as trusted advisors as decisions are made around the release plan

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

158

Release planning v  Breaking down barriers – The business and stakeholders and developers all plan together. v  Interactions between people - when we do Release Planning, we get all of the people who are involved into a room so they can interact. v  Iterative and incremental –We do Release Planning once (usually near the beginning of the release development), and then again and again as needed. v  An Agile Release Plan increases in accuracy over time as the results of each iteration are incorporated into it. v  4 hours max( 2hrs for 2 week sprint)

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

159

Release planning 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 Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

160

Release planning

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

161

Release planning

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.

Steps  in  Release  Planning   Understand  the  goal   Understand  the  customer   requirement   Priori0ze  and  es0mate  the  backlog   Calculate  the  team  velocity   Create  a  release  plan   Communica0ng  the  release  plan   Upda0ng  the  release  plan  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

162

Release planning v Preparing for Release Planning •  •  •  •  • 

Set themes Prepare the backlog Divvy stories up Understand the issues Identify key dates

v After a Release •  Do Release Retrospective

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

163

Tips for Release Planning v  Do as little planning as is necessary. v  Start release planning when you realize you need it, even if it’s near the end of the release effort. v  Plan using stickies on the walls and update them into an online tool, do that later, after the meeting. v  Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen. v  Include vendors and other third parties who are relevant and involved in your release planning meeting. v  Revisit the release plan after each sprint and update it.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

164

AGILE ESTIMATION Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

165

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

166

Agile Uses ‘Point” to Estimate Story Size

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

167

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

168

What is a story point? v  Story point is a random measure for estimation used by Agile teams. This is used to determine the size of effort required to complete the development of a user story.

v  A story point is usually assigned after considering following factors § 

Effort required in development of story

§ 

Complexity of story

§ 

Unknowns or risk factors in the development

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

169

How to assign story points? Pick a baseline story

v  In the beginning team picks up a baseline story and assigns some story point to that story. Rest of the stories are assigned story points based on their comparative size with the baseline story.

v  Baseline could be different for different teams. For example one team can assign 5 where as other can assign 3 to the same story.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

170

Story Point v  Sizing sequence should be geometric series: 1, 2, 4, 8, 16, 32, … v  Mike Cohen proposed Fibonacci series: 1, 2, 3, 5, 8, ... v  Its relative data and not absolute. v  Advantage: Accuracy is less important than consistency. v  Disadvantage: Its team specific values and may not have any meaning for others. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

171

T-Shirt Sizing v  S, M, L, XL, ... v  Apply story points later. v  Good first step for tam to adapt Relative Sizing technique. v  Advantage: Easy to grasp. v  Disadvantage: Size vs Time comparison is difficult

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

172

Planning Poker

3                                                                    5  

• 

3   • 

•  5  

5  

5   • 

3  

5  

5  

5   3  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

173

Poker Estimation

Estimator

Round 1 Round 2

Sheila

3

5

Raj

8

5

Suresh

2

5

Annie

5

8

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

174

Exercise 9: Poker Estimation Poker estimation: v  Each team will use poker estimation to estimate a picture given by instructor.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

175

User Story inputs  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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 Tài liệu được biên soạn bởi Ông Đoàn Đức Đề theo yêu cầu của

@Author  :  Đoàn  Đức  Đề                                                                                  [email protected]  

176

Sizing

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

177

Sizing

Priority

Description

Size

Value

(from Team)

(from Product Owner)

1

Feature A

3

Extra-High

2

Feature B

5

Extra-High

3

Feature C

3

High

4

Feature D

8

Extra-High

5

Feature E

5

High

6

Feature F

2

Medium

7

Feature G

13

High

8

Feature H

3

Low

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

178

Velocity v  Is how much product backlog effort a team can handle in one sprint. v  It is measured in Story Points. v  Once established, velocity can be used to plan projects and forecast release and product completion dates. v  Can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. v  Should not vary too much. v  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.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

179

Velocity 1

1

2

1

2

1

2

1 2

1 2

1 2

1

1

2

2

3

1 2

1 1

3

5

Sprint 1

Sprint 2

15 Points

12 Points

of size

of size

Sprint 3

14 Points of size

Average of ~14 Points per Sprint è “Velocity” Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

180

Velocity The Product Backlog Priority  

Descripcon  

Size   (to   build)  

1

Feature A

3

2

Feature B

4

3

Feature C

3

4

Feature D

2

5

Feature E

4

6

Feature F

4

7

Feature G

3

8

Feature H

5

9

Feature I

2

10

Feature J

4

11

Feature K

2

12

Feature L

4

Total = 40 points Velocity = 14 points Time to complete = 40/14 = 2.8 Sprints

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

181

Planning Poker Video demo

1.      Agile  in  Praccce_  Planning  Poker   2.      SCRUM  03  -­‐  Escmate  Backlog  Using Planning  Poker  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

182

AGILE REQUIREMENT  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

183

Key Principles for Agile Requirements v  Active user involvement is imperative v  Agile teams must be empowered to make decisions v  Requirements emerge and evolve as software is developed v  Agile requirements are ‘barely sufficient’ v  Requirements are developed in small, bite-sized pieces v  Enough’s enough – apply the 80/20 rule v  Cooperation, collaboration and communication between all team members is essential.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

184

A picture is worth a thousand words

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

185

Requirements are a Communication Problem v  Written requirements

v  Verbal requirements

§  can be well thought through, reviewed and edited

§  Instantaneous feedback and clarification

§  provide a permanent record

§  Information packed exchange

§  are more easily shared with groups of people

§  easier to clarify and gain common understanding

§  may be less relevant or superseded over time

§  more easily adapted to any information know at the time

§  can be easily misinterpreted

§  can spark ideas about problems and opportunities

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

186

What is User Story? v  A user story is one or more sentences in the everyday or business language of the user or customer that captures what the user or customer wants to achieve through software. v  They tell a short story about how the user, customer or other persona will use the system, and what benefit they derive from the functionality. v  The goal is to provide context, which helps the Product Owner effectively manage and rank the backlog, and help the team understand how to implement functionality with the goals of customers in mind.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

187

User Story v  A simple statement in a user story format gets us started, but doesn’t tell the whole story. v  The Three C’s indicate the three elements of a user story Card, Conversation, Confirmation. 1. Card - A written description of the user story for planning purposes and as a reminder 2. Conversation - A section for capturing further information about the user story and details of any conversations 3. Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

188

Story Card

As a [user role] I want to [goal] so I can [reason] For example: As a registered user I want to log in so I can access subscriber-only content

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

189

Story Card description v  Who (user role) v  What (goal) v  Why (reason) •  Gives clarity as to why a feature is useful can influence how a feature should function can give you ideas for other useful features that support the user's goals

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

190

Conversation v  Through conversation, the Product Owner and Delivery Team develop a shared understanding of the goals for functionality as well as the constraints. Often the team asks questions. v  For our password reset example, questions might include: §  What type of authentication do we need? §  What information do we need to collect about the user? §  Are there different types of users that we have to worry about? v  The whole team can participate in these discussions. Different roles and different viewpoints will surface different questions and concerns.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

191

The Confirmation – Acceptance Criteria v  How will the Product Owner confirm that the story was implemented properly? v  Acceptance criteria are the conditions of satisfaction and acceptance for the story. v  Product Owners and the Delivery Team work together to provide acceptance criteria and remove any ambiguity from the user story. v  Acceptance Criteria for our Reset Password story might include: v  Username, password, and email address are all required. Display name can be provided, but is optional. v  Passwords can be 6 – 200 characters in length. v  Passwords should be stored encrypted and cannot be decrypted.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

192

User Story Example: Front of Card  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

193

User Story Example: Back of Card

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

194

How detailed should a User Story be?

 

Detailed enough for the team to start work from, and further details to be established and clarified at the time of development.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

195

INVEST in Good User Stories v  Independent – User Stories should be as independent as possible.

v  Negotiable – User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

v  Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

196

INVEST in Good User Stories v  Estimateable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

v  Small – User Stories should be small. Not too small. But not too big.

v  Testable – User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

197

User Stories Summary v  User Stories combine written and verbal communications, supported with a picture where possible. v  User Stories should describe features that are of value to the user, written in a user’s language. v  User Stories detail just enough information and no more. v  Details are deferred and captured through collaboration just in time for development. v  Test cases should be written before development, when the User Story is written. v  User Stories should be Independent, Negotiable, Valuable, Estimable, Small and Testable.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

198

Story Point Video demo

1.      Agile  In  Praccce_  StoryCards_User Stories 2.      Non-­‐Funcconal  Requirements  Add Value  to  User  Stories  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

199

Exercise 10: User Stories User Stories: v  Each team writes user stories of your product backlog. v  Use poker cards to estimate your user stories

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

200

Product Backlog Prioritization Overview v  Prioritization is a process of ranking user stories in product backlog. v  Highest customer value first. v  Owned by Product Owner. v  To be revisited whenever new requirement comes.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

201

Criteria for Prioritization

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

202

MoSCoW Method

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

203

Exercise 11: Prioritization Prioritization: v  Each team prioritizes PBIs in your product backlog.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

204

 

TESTING IN AGILE

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

205

How testing is different in Agile? Traditional Testing

Agile Testing

Testing occurs at the end

Testing occurs iteratively within each Sprint

Communication is formal

Communication cannot always be formal as interaction is required between the groups

Test Automation is optional

Automation is highly recommended

Testing from Requirements

Testing from Customers perspective

Detailed Test Plan exists

Lean Test Planning

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

206

Testing in agile 1.  During the planning phase of a project, agile testers do: v  Help the rest of the team understand the user stories v  Only take on stories that can be fully tested by the end of the sprint v  Collaborate with customers to better understand their stories v  Collaborate with developers to make sure all have the same understanding v  Start working on high level user acceptance tests for each story v  Think about any test data or testing dependencies needed for story testing

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

207

Testing in agile 2.  When in coding and testing phase of the project, testers do: v  Write detailed tests once coding starts v  Start with simple tests and add more complex ones later on v  Complete tests for one story at a time v  Identify testing obstacles as early as possible and communicate to team v  Facilitate communication between the customers and developers for issues that arise from coding and testing. v  Write some manual tests for scenarios that are too difficult to automate with the automated agile testing tool in hand. v  Start automating tests once enough code is written for regression suite.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

208

Testing in agile 3.  During the final stage & post-release testers take part in: v  Identifying testing related obstacles during sprint v  Estimating if there was enough time to test all completed stories v  Finding ways to improve next sprint v  Demo product to business owners for feedback

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

209

Challenges in Agile Testing v  Testing occurs within each sprint and not just at the end v  Testing teams do not have a great deal of time to develop and maintain the test scripts v  Different skills for testers v  Requirements and plan evolve over time v  The Regression testing scope increases each sprint v  Testers may lose overall system perspective while testing from sprint to sprint

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

210

Automation build v  Every commit to the code should be build. v  Only the latest build to be tested or used for demo. v  Early warning for broken code. v  Pushes developers for more modular and less complex code. v  Hardware cost for automated build setup. v  Ideal in case of distributed team.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

211

Build Strategy: Nightly Build v  Typically take place when no one is likely to be working in the office so that there are no changes to the source code during the build. v  Takes place automatically at a specified time. v  Ideal in case of high load and short schedule. v  Can be done on a machine which is also used for active development. v  Easy to maintain. v  Finding bugs or testing can be delayed. v  Ideal in case of centrally located team.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

212

Exercise 12: Spring Backlog Spring Backlog Development: v  Each team develop Spring backlog based on priority of PBIs in your product backlog.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

213

AGILE - LEAN DEVELOPMENT

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

214

A Lean History v  Lean is a manufacturing & production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. v  "value" is defined as any action or process that a customer would be willing to pay for. v  Lean is centered around preserving value with less work. v  Lean manufacturing is based on optimizing flow, increasing efficiency, decreasing waste, and using empirical methods to decide what matters, rather than uncritically accepting pre- existing ideas v  Toyota was a leader in implementing lean practices in the 80s

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

215

A Lean History

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

216

Seven Lean Principles

LEAN PRINCIPLES

Eliminate Waste Amplify Learning Decide as Late as Possible Deliver as Fast as Possible Empower the Team Build Integrity In See the Whole Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

217

Principle  #  1:  Eliminate  Waste

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

218

What  is  waste? v  Anything that doesn’t add value (as perceived by the customer) to the product v  Unnecessary code or functionality v  Unclear requirements v  Slow internal communications or processes v  Bureaucracy

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

219

Tool #1: Seeing Waste v  Agile practices seek to eliminate waste, but the first step is to learn how to see waste v  Good examples of waste are parts of the software process that are not analysis and coding - do they really add value to the customer? v  Shigeo Shingo identified seven types of manufacturing waste v  Mary and Tom Poppendieck translated these into the software domain in the following table

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

220

Tool #1: Seeing Waste Learn to see waste Waste of Manufacturing

Waste of Software Development

Inventory

Partially work done

Extra processing

Paperwork or excess documentation

Overproduction

Extra features

Transportation

Task Switching

Waiting

Waiting for the information

Motion • 

• 

Defects Wastes of Manufacturing

Learn  Motion to  see  waste  

Defects Development Wastes of Software

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

221

Tool #2: Value Stream Mapping v Mapping your value stream is a good way to start discovering waste in your process   v This involves drawing a chart of the average customer request, from arrival to completion   v At the bottom, draw a timeline that shows how much time the request spends in value-adding, waiting, and non-value- adding activities  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

222

Tool #2: Value Stream Mapping v  Reduce management activities such as unnecessary tracking systems. Minimize tracking by create a smooth flowing work system   v  Rethink Authorization systems. Make “approvals”  unnecessary   v  Retrain you brain to see waste. Ask yourself “Why am I  really doing this?”   v  Map your value stream to identify inefficiencies  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

223

Principle # 2: Amplify Learning

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

224

Exercise 13: The Ball Game Create a process for giving and receiving the ball in your group: v  You cannot pass the ball to the person next to you v  The ball must be returned to the person who started with it. v  The ball must travel through the air v  The ball cannot be rolled across surfaces e.g. floors, walls, tables and chairs.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

225

Tool #3: Feedback v  Feedback adds complexity to a system, but it also adds considerable value   §  For example, a traffic light that senses cars is more useful than a traffic light on a strict timer   v  The Waterfall development model does not provide much feedback; it is generally thought of as a single-pass model   v  Traditional processes consider feedback loops threatening because incorporating feedback could modify the predetermined plan   v  Developers should know their immediate and have ways for that customer to provide feedback  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

226

Tool #3: Feedback

v Increasing feedback is the single most effective way to deal with troubled software projects   §  Instead of letting defects accumulate, run tests as soon as the code is written   §  Instead of adding more documentation or detailed planning, check out ideas by writing code     §  Instead of gathering more requirements, show the customer an assortment of potential users screens and get their input   § 

Instead of studying which tool to use, bring the top three candidates in-house and test them  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

227

Tool #4: Iterations v  Iterations provide a dramatic increase in feedback   §  The operational environment is considered early   §  Design problems are exposed early   §  Change-tolerance is built into the system   v  Short iterations allow the system to respond to facts rather than forecasts   v  Iterations are a point of synchronization between the different teams and the customer   v  Iterations force decisions to be made because the system is deployed early and often     Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

228

Tool #5: Synchronization v  Build the system every day after a small batch of work has been completed by each of the developers   v  At the end of the day, a build takes place followed by an automated set of tests   v  If the build works and the tests pass, then the developers have been synchronized   v  The more builds, the better because it provides rapid feedback   v  Full system tests should be run as frequently as possible    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

229

Tool #6: Set-Based Development Set-Based Versus Point-Based   v  The point-based approach starts with one choice and is refined until it works, which takes many iterations and might not converge   v  The set-based approach starts by defining everyone's constraints and then selects a choice that fits into those constraints   v  Set-based development bases communication on constraints rather than choices which requires significantly less data to convey far more information   v  Talking about constraints allows developers to defer making choices until the last possible moment

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

230

Tool #6: Set-Based Development Develop Multiple Options   v  When you have a difficult problem, develop a set of solutions, see how they actually work, and merge the best features of the solutions   v  It might seem  wasteful to develop multiple solutions, but set- based development can lead to better solutions faster

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

231

Principle # 3: Decide as Late As Possible

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

232

Sequential versus Concurrent Sequential Depth First (Drilling into the details too fast)

Concurrent Breadth First (seeing things in full view over time)

Order of Creation ( On day 1, We created requirements)

Highest valued features first

Rigid, change is costly

Adaptable, change is manageable

Cost escalation is high when issues are found late

Cost escalation is low, as issues are found incrementally

High stakes decisions are High stakes decisions can be made based on assumptions deferred until the last and with uncertainly responsible moment

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

233

Tool #7: Options Thinking v  People find it difficult to make decisions when there is uncertainty present   v  Delaying Decisions   §  The underlying economic mechanism for controlling complexity in just-intime systems is minimizing irreversible decisions   §  This contrasts with other methodologies that manage complexity by limiting decisions - e.g. "any color as long as it's black"   §  Delaying irreversible decisions leads to better decisions, limits risk, helps manage complexity, reduces waste, and makes customers happy   §  However, delaying decisions has a cost, but the overall system is more profitable and allows the correct decision to be made       Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

234

Tool #8: The Last Responsible Moment v  The last responsible moment is the moment in which failing to make a decision eliminates an important alternative   v  If commitments are delayed beyond this moment then decisions are made by default, which is generally not a good approach to making decisions   v  This is not be confused with procrastination; in fact, delaying decisions is hard work

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

235

Tool #9: Making Decisions Depth-first versus Breadth-first problem solving   v  Breadth-first problem solving could be thought of as a funnel and involves delaying decisions   v  Depth-first problem solving could be thought of as a tunnel and involves making early commitments   v  Depth-first is preferred when approaching new problems because it tends to quickly reduce the complexity of the problems   v  If there is an expert to make early decisions correctly and an assurance that there will not be changes that render the decisions obsolete, then depth-first is more effective. Otherwise, breadth-first will lead to better results

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

236

Principle # 4: Deliver as Fast as Possible

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

237

Exercise 14: The Coins Game Each team, 5 people and 20 coins, has to follow the following rounds: v  The first round: up-side-down 20 coins and pass them to the next person. v  The second round: up-side-down 10 coins and pass them to the next person. v  The third round: up-side-down 5 coins and pass them to the next person. v  The fourth round: up-side-down 1 coin and pass it to the next person.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

238

Tool #10: Pull Systems v  For rapid delivery to happen, it must be clear to every person what he/ she should do to make the most effective contribution to the business   v  There are two ways to ensure that workers are productive: tell them what to do or set things up so they can figure it out for themselves   v  In fast-moving situations, it is more effective to let the workers task themselve    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

239

Tool #11: Queuing Theory Reduce Cycle Time   v  Queuing theory strives to make your wait as short as possible   v  The fundamental measurement of a queue is cycle time - the average time it takes something to get from the beginning of a process to the end   v  The time spent waiting in the queue is wasted time   v  There are two ways to reduce cycle time - look at the way work arrives or look at the way the work is processed   v  One way to control the rate of work arrival is to release small packages of work so that the queue is smaller  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

240

Tool #11: Queuing Theory

v  Once variability has been removed from the arriving work, the next step is to remove the variability in the processing time   v  Small work packages allow parallel processing of the small jobs by multiple teams so that if one team is stalled by a problem, the rest of the project can proceed without delay   v  Software organizations, like highways, cannot funtion at full capacity   v  Having slack in an organization gives the capacity to change, reinvent itself, and marshal resources for growth

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

241

Tool #12: Cost of Delay v  Often, software teams are told that they must meet cost, feature, and date objections simultaneously. This sends two messages:   §  Support costs are not important because they were not mentioned   §  When something has to give, make your own trade-offs   v  Instead, give the team an economic model which will empower the members to figure out for themselves what is important for business   v  Trade-off decisions are easiest to make when they are expressed in the same units   v  Economic models justify the cost of reducing cycle time, eliminate bottlenecks, and purchasing tools   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

242

Principle # 5: Empowering the Team

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

243

Tool #13: Self-Determination v Transfer practices from one environment to another is often an mistake   v Let the team design their own working procedures   v Remember Management’s role is coach, train, and assist the teams   v It is key to understand the fundamentals principals that make up practices, and transform those principles into new practices   v Managers need to improve as much as individual workers. A  feedback loop is critical going both ways between managers and workers to drive improvement

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Tool #14: Motivation Create a sense of purpose at work. People care about a purpose greater then themselves   v  It must be clear   v  It must be achievable   v  The team must have access to customers   v  Let the team make it’s own commitments   v  Management’s role is to provide support, resources, guidance, and protection    

 

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Tool #15: Leadership Respected Leaders   v  Nearly every major product development is spearheaded by a champion who is excited and passionate about their work   v  They probably wrote the product concept, recruited the team, interpret the vision for the team, and set the pace for development   Master Developers   v  Exceptional developers exercise   leadership through superior knowledge instead of bestowed authority   v  It is not essential to identify a master developer at the beginning of every project as more often than not they will emerge as a result of their technical prowess   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

246

Tool #15: Leadership Where do master developers come from?   v  They grow into their role through extensive experience in the technology being employed or the domain being addressed by the system   v  They also possess exceptional abstraction and communication skills   Project Management   v  Often the project manager does not have a technical background and is not responsible for developing a deep technical understanding of the product   v  They focus on identifying waste, coordinate iteration planning meetings, help team acquire resources, coordinate/ synchronize multiple teams, and provide a motivating environment (among many other things)   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Tool #16: Expertise Share Expertise   v  Promote mentorship and pair programming   v  Create communities of expertise   §  Identify the technical and domain specific competencies that are critical to an organization's success   §  Within these communities create forums for knowledge sharing; monthly meetings, newsletters, guest speakers, etc.   Enforce Standards   v  Naming standards,  coding standards, language standards, check in/out standards, build standards   v  Develop standards and practice them   v  Lack of standards leads to sloppy work   v  Standards develop through experimentation and knowledge sharing  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Principle # 6: Build Integrity In

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

249

Tool #17: Perceived Integrity Focus on keeping customer values at the forefront   v  Engineers have a tendency to get lost in the details and lose track of customer values   v  To prevent this, visions of perceived integrity should be refreshed regularly through customer feedback or access to groups of users who can judge the system's integrity   Model Driven Design   v  Construct domain models such that software implementation can flow directly from these models   v  These models must be understood and directly usable by the customers and developers   v  The models should express all the business rules, business processes, and domain related issues using ubiquitous language that can be understood by everyone  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Tool #17: Perceived Integrity Recommended collection of Models   v  Conceptual Domain Model: Class model of the basic entities of the system   v  Glossary: Defines terms found in domain model and ensures consistent language for the team   v  Use Case Model: A dynamic view of the system that captures customers goals for interacting with the domain model and details their expected workflow   v  Qualifiers: Details the qualifiers that might  be applied to the basic functionality of the system such as number of users, acceptable response time, required availability, projections for growth, etc  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Tool #18: Conceptual Integrity Measured by how well a system's components work together as a smooth, cohesive whole   v  Components match/work well together   v  The architecture allows for a balance between flexibility, maintainability, efficiency, and responsiveness   Effective communication is key to achieving conceptual integrity   Reuse existing solutions   v  If something has been proven to solve a problem in the past and you can make use of it, do it   v  This helps to remove degrees of freedom in the development process, reduces the complexity and need for communication   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

252

Tool #18: Conceptual Integrity Employ integrated problem solving practices   v  Understand and store the problem simultaneously   v  Release preliminary data early and don't wait for the complete answer   v  Information is released in small batches   v  Information flows in two directions   v  The preferred method of communication  is face-to-face

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

253

Tool #18: Conceptual Integrity Without integrated problem solving   v  Designers make decisions in isolation and send a large amount of information to those who must make decisions causing a "throw it at the wall approach"   With integrated problem solving   v  Frequent bilateral communication occurs which produces necessary feedback  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

254

Tool #19: Refactoring Complex systems have effects that aren't fully understood at design time   Architecture must remain healthy as the system evolves   v  New features are always being requested by users   v  Features can always be added  separately; often new features are related and redesigning architecture of system to support feature set is the best decision   v  Resist the urge of adding features in a brute force approach and instead adjust the architecture so that system integrity does not degrade  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

255

Tool #19: Refactoring Maintaining conceptual integrity   v  Simplicity   §  A simple design is nearly always the best design   §  Experienced developers know how to simplify complex designs   v  Clarity   §  Code must be easy to  understand   §  Everything should be clearly named and naming conventions and practices should be upheld  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

256

Tool #19: Refactoring Maintaining conceptual integrity   v  Suitability for use   §  Every design must accomplish intended purpose   v  No repetition   §  Repetition should never exist, this is a sign of bad design   v  No extra features   §  When Code is no longer  needed, get rid of it

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

257

Tool #19: Refactoring

Does refactoring slow down productivity?   v  Conventional wisdom suggests that the overhead associated with refactoring would slow down the team - the opposite turns out to be true   v  By spending time making sure code does not get out of hand you make further development much easier and more efficient      

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

258

Tool #20: Testing v  Testing proves that design intent is achieved and that the system does what customers want it to do   § Whenever developers write code, tests should exist to ensure that the features being developed work as intended   v  When developers write code he/she should get immediate feedback about whether or not it works as intended from the existing test code   v  Tests should be automated as much as possible and run as part of the daily build   v  Tests that cannot be automated or take too long to be run daily have much less value than those that can be run frequently   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

259

Tool #20: Testing Types of tests   v  Unit tests (single component), integration tests (multiple components) and system tests (the entire system)   v  Developer  tests (tests that ensure code does what developer intended) and acceptance tests (also known as customer tests these tests ensure that the system functions how the customer expects)    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

260

Tool #20: Testing Roles of tests in development life cycle   v  Communicate how things are supposed to work   v  Provide feedback on whether or not the system actually works how it is supposed to   v  Provide the scaffolding for developers to make changes through the development process   v  After development tests provide an accurate representation of how the system was actually built  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

261

Principle # 7: See the Whole

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

262

Tool #21: Measurements v  Measurements are important for tracking the progress of software development   § Example: defect counts are important for gauging software readiness   v  People will increase their performance in areas that are measured   v  Measurements should motivate the team to collaborate and find better ways to do things    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

263

Tool #22: Contracts v  A common misconception is that agile development cannot be used in the context contract work in which each firm is expected to look out for itself   v  To make it work, we need to change our idea of a contract being method of keeping two parties from taking advantage of each other into something that supports collaboration   v  In most cases  this means being flexible with regards to scope    

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

264

Tool #22: Contracts Incorporating Lean Development into different types of contracts   v  Fixed-Price Contracts   v  Time-and-Materials Contracts   v  Multistage Contracts   v  Target-Cost Contracts   v  Target-Schedule Contracts   v  Share-Benefit Contacts  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

265

KANBAN   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

266

What is Kanban?

v  看板 – Kanban literally means “visual card,” “signboard,” or “billboard.”   v  Kanban is a method that helps   §  Establish a culture of continuos improvement   §  Implement and scale Agile   §  Enable evolutionary change   v  Kanban  is a true PULL system implementation in software engineering   v  Kanban is a Visual Card

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

267

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

268

What is PULL system?

v  There is a queue of work, which goes through a number of stages until it is done v  When work is completed in a stage, it goes downstream to the next stage v  When someone needs new work to do, they pull from upstream

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

269

Why Kanban is Pull system? WE :   v  Don’t build features that nobody needs right now   v  Don’t write more specs than you can code   v  Don’t write more code than you can test   v  Don’t test more code  than you can deploy

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

270

Time-boxed iterative & incremental development has challenges   Common problems include:   v  Short time-boxes force development items to be smaller and valuable items to be spread over many iterations   v  Quality of requirements suffers as analysts & UX designers rush to prepare for upcoming cycles   v  Quality of current development suffers when busy analysts and UX designers are unable to inspect software or answer questions during development   v  Quality often suffers as testers race to complete work late in the development time-box   v  Unpredictable work makes it difficult to plan even a few weeks in  advance Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

271

Inside an iteration, effort across roles is uneven  

Development work often continues throughout a cycle while testing starts late and never seems to get enough time   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

272

Why Kanban? v  Goal 1: Optimize Existing Processes – Using the visualization and the limiting of work-in-progress (WIP) will catalyze change with minimal disruption.   v  Goal 2: Deliver with Higher  Quality – Limiting work-in- progress and defining policies for work prioritization will bring greater focus on quality. Policies can also address quality criteria directly.   v  Goal 3: Improve Lead Time Predictability – There is a correlation between the amount of work-in-progress, lead time and defect rates. Limiting WIP makes lead times dependable and keeps defect rates low.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

273

Why Kanban?

v  Goal 4: Improve Employee Satisfaction – Kanban reduces context switching and pulls work at the rate the team can complete it. Working at a more even, predictable pace, means employees are never overloaded.   v  Goal 5: Provide  Slack to Enable Improvement – Creating slack in the value chain improves responsiveness to urgent requests and bandwidth to enable process improvement and quality improvement.   v  Goal 6: Simplify Prioritization – Kanban enables fast reprioritization to accommodate changes in the market.      

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

274

Why Kanban? v Goal 7: Provide a Transparency on the System Design and Operation – Improved visibility builds trust with customers and managers. It also shows the effects of actions or inactions. As a result, collaboration improves.   v Goal 8: Enables Emergence of a “High-Maturity” Organization – As   improvements are implemented, organizational maturity improves leading to better decision making and improved risk management. Risk, managed   appropriately, brings predictable results.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

275

Five core principles enable The Kanban Method   Principles 1. Visualize the workflow

Description Represent the work items and the workflow on a card wall or electronic board

2. Limit Work-inProgress 3. Measure & Manage   Flow 4. Make Policies Explicit

Set agreed upon limits to how many work items are in progress at a time Track work items to see if they are proceeding at a steady, even pace.

5. Use Models to Evaluate Improvement Opportunities

Agree upon and post policies about how work will be handled Adapt the process using ideas from   Systems   Thinking, W. E. Deming, etc

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

276

Focusing on smoothing flow     v  平準化 – Heijunka : production smoothing, or the reduction of waste from unevenness     v  斑 - Mura : unevenness, inconsistency in physical matter or human spiritual condition  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

277

KANBAN system

How to set up a simple Kanban system   for   a software development team ? Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

278

1. Define a work process flow  

This  simple  process  flow  has   the  steps:   1.  Elabora0on  &  acceptance   criteria   2.  Development   3.  Test   4.  Deployment  

v  Look at the typical flow for features, stories, or work packages and describe typical process steps Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

3.  Test 4.  Deployment

279

2. Lay out a visual Kanban board  

EXPEDITE  

DONE  

GOALS   WAITING   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

280

3. Prioritized goals  

Having goals visible:   •promotes focus   •helps us prioritize   •helps us manage feature   scope & requirements.  

A good goal describes the outcome we hope to achieve after software ships. Goals help keep focus on the larger outcome   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

281

4. Limits items in queue and work in progress  

Limited Items in queue  

A good limit is a factor of the number of people in a role that can work on an item in a given process step. Start with number of people * 1.5   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

282

5. Place stories or features in queue  

Product owner manage the waiting queue

v  Mark on the story or feature card the date it entered the queue. This begins our measurement of cycle time. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

283

Using a strict Kanban approach drops iteration planning from time-boxed iterations in favor of focusing on continuous flow Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

284

Setting up a simple Kanban system starts to focus the team on the cycle-time of delivered work and give a way to detect and begin to resolve bottlenecks

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

285

DoD Video demo  

  1. Intro to Kanban in Under 5 Minutes  

 

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

286

SCALING AND DISTRIBUTED SCRUM

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

287

Scaling SCRUM: SCRUM of SCRUMS  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

288

Scaling SCRUM: SCRUM of SCRUMS  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

289

Scaling of SCRUM v  Many teams, many backlogs, Chief Product owner, Product Owners, SCRUM Masters.   v  Synchronize within the team and across teams.   v  Correlate team organization to subsystems or modules with minimal crossover.   v  Implement development infrastructure to support the number and locations.   v  Develop standards, guidelines, training courses, templates, and framework to minimize the coordination required.   v  Ensure each team has sufficient resources carefully considering shared resources.   v  Develop common culture across the teams.   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

290

Scaling Impact: Roles  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

291

Scaling Impact: Agile Practices  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

292

Scaling Consideration: Infrastructure  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

293

Scaling Consideration: Tools  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

294

Scaling Consideration: People  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

295

Scaling Product Backlog  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

296

Scaling Product Backlog  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

297

Scaling Product Backlog  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

298

Distributed SCRUM v Rotate members around. v Invest in tools that provide shared environment. v Establish single global instance of project assets, easily accessible by all. v Try virtual team building (wiki/photos) v Establish known hours, with as much overlapping time. v Develop shared team vocabulary.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

299

Distributed SCRUM : Delivery Practices  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

300

Some Overlapping Period  

v  Good part : There is some overlapping here   v  Whole team can communicate to team on other side   v  Chances of mis-communication is less   v  Minimize waste in escalation and follow ups. Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

301

No Overlapping Period  

v  Biggest Challenge – Share the pain   v  Single point of contact, chances of mis-communication is more   v  Less communication between team members   v  Need to take proactive approach to minimize waste   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

302

Distributed SCRUM: Best Practices   v  Easy and continuous access to resources   §  Source code repository   §  Continuous Integration Server   §  Bug Tracking tool   §  Wiki   §  Project Management Tool   v  Setup infrastructure to support team member communication   §  Sprint meetings   §  Offline discussions   §  Knowledge sharing sessions   v  Regular people movement for short periods   §  Mixing of people to overcome  cultural issues, etc.,   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

303

Challenges in Distributed and Scaling SCRUM  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

304

EXTREME PROGRAMMING

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

305

What is Extreme Programming?

•  An agile development methodology •  Created by Kent Beck in the mid 1990’s •  A set of 12 key practices taken to their “extremes” •  A mindset for developers and customers •  A religion?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

The 12 Practices v  The Planning Game v  Small Releases v  Metaphor v  Simple Design v  Testing v  Refactoring v  Pair Programming v  Collective Ownership v  Continuous Integration v  40-Hour Workweek v  On-site Customer v  Coding Standards Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

1 - The Planning Game

•  Planning for the upcoming iteration •  Uses stories provided by the customer •  Technical persons determine schedules, estimates, costs, etc •  A result of collaboration between the customer and the developers

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

The Planning Game – Advantages

•  Reduction in time wasted on useless features •  Greater customer appreciation of the cost of a feature •  Less guesswork in planning

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

The Planning Game – Disadvantages •  Customer availability •  Is planning this often necessary?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

2- Small Releases

•  Small in terms of functionality •  Less functionality means releases happen more frequently •  Support the planning game

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Small Releases – Advantages •  Frequent feedback •  Tracking •  Reduce chance of overall project slippage

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Small Releases – Disadvantages

•  Not easy for all projects •  Not needed for all projects •  Versioning issues

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

3 – Metaphor •  The oral architecture of the system •  A common set of terminology

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Metaphor – Advantages

•  Encourages a common set of terms for the system •  Reduction of buzz words and jargon •  A quick and easy way to explain the system

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Metaphor – Disadvantages

•  Often the metaphor is the system •  Another opportunity for miscommunication •  The system is often not well understood as a metaphor

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

4 – Simple Design

•  K.I.S.S. •  Do as little as needed, nothing more

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Simple Design – Advantages

•  Time is not wasted adding superfluous functionality •  Easier to understand what is going on •  Refactoring and collective ownership is made possible •  Helps keeps programmers on track

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Simple Design – Disadvantages

•  What is “simple?” •  Simple isn’t always best

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

6 – Testing

•  Unit testing •  Test-first design •  All automated

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Testing – Advantages

•  Unit testing promote testing completeness •  Test-first gives developers a goal •  Automation gives a suite of regression test

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Testing – Disadvantages

•  Automated unit testing isn’t for everything •  Reliance on unit testing isn’t a good idea •  A test result is only as good as the test itself

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

6 – Refactoring

•  Changing how the system does something but not what is done •  Improves the quality of the system in some way

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Refactoring – Advantages

•  Prompts developers to proactively improve the product as a whole •  Increases developer knowledge of the system

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Refactoring – Disadvantages

•  Not everyone is capable of refactoring •  Refactoring may not always be appropriate •  Would upfront design eliminate refactoring?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

7 – Pair Programming

•  Two Developers, One monitor, One Keyboard •  One “drives” and the other thinks •  Switch roles as needed

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Pair Programming – Advantages

•  Two heads are better than one •  Focus •  Two people are more likely to answer the following questions: –  Is this whole approach going to work? –  What are some test cases that may not work yet? –  Is there a way to simplify this?

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Pair Programming – Disadvantages

•  Many tasks really don’t require two programmers •  A hard sell to the customers •  Not for everyone

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

8 – Collective Ownership

•  The idea that all developers own all of the code •  Enables refactoring

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Collective Ownership – Advantages •  Helps mitigate the loss of a team member leaving •  Promotes developers to take responsibility for the system as a whole rather then parts of the system

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Collective Ownership - Disadvantages •  Loss of accountability •  Limitation to how much of a large system that an individual can practically “own”

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

9 – Continuous Integration •  New features and changes are worked into the system immediately •  Code is not worked on without being integrated for more than a day

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Continuous Integration - Advantages •  Reduces to lengthy process •  Enables the Small Releases practice

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Continuous Integration – Disadvantages •  The one day limit is not always practical •  Reduces the importance of a well-thought-out architecture

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

10 – 40-Hour Week •  The work week should be limited to 40 hours •  Regular overtime is a symptom of a problem and not a long term solution

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

40-Hour Week – Advantage •  Most developers lose effectiveness past 40-Hours •  Value is placed on the developers well-being •  Management is forced to find real solutions

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

40-Hour Week - Disadvantages •  The underlying principle is flawed •  40-Hours is a magic number •  Some may like to work more than 40-Hours

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

11 – On-Site Customer •  Just like the title says! •  Acts to “steer” the project •  Gives quick and continuous feedback to the development team

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

On-Site Customer – Advantages •  Can give quick and knowledgeable answers to real development questions •  Makes sure that what is developed is what is needed •  Functionality is prioritized correctly

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

On-Site Customer – Disadvantages •  Difficult to get an On-Site Customer •  The On-Site customer that is given may not be fully knowledgeable about what the company •  May not have authority to make many decisions •  Loss of work to the customer’s company

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

12 – Coding Standards •  All code should look the same •  It should not possible to determine who coded what based on the code itself

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Coding Standards – Advantages •  Reduces the amount of time developers spend reformatting other peoples’ code •  Reduces the need for internal commenting •  Call for clear, unambiguous code

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Coding Standards – Disadvantages •  Degrading the quality of inline documentation

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

XP – Advantages •  Built-In Quality •  Overall Simplicity •  Programmer Power •  Customer Power •  Synergy Between Practices

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

XP – Disadvantages •  Informal, little, or no documentation •  Scalability •  Contract Issues •  Misconception on the cost of change •  Tailoring

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Application – Advantageous •  Highly uncertain environments •  Internal projects •  Joint ventures

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

Application – Disadvantageous

•  Large, complex environments •  Safety critical situations •  Well understood requirements •  Distant or unavailable customer

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

AGILE FOR MANAGER Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

348

What type of manager are you?   Result-oriented (nutritional quality) • Is mainly oriented towards achieving results • Defines objectives, sets priorities, and assigns resources • Makes decision based on facts • Is consistent and actionoriented

Enjoyment-oriented (fun to eat) • Is mainly oriented towards people to achieve results • Defines challenges, promotes autonomy, and provides appropriate support • Makes decision based on emotions • Is emotional and relational  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

349

A few questions to get to know you   True  

False  

1. In order to get best results, it is better to control the activities of all team members.   2. A process that is not well-defined right from the beginning will always produce suboptimal results.   3. In order to cut productivity loss, it is better to isolate team members in cubicles and use e-mails as a means of communication.   4. A team made up of specialists with extensive skills is more efficient than a multidisciplinary team.   5. The best tools and processes are those chosen by the organization and used by all groups.   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

350

A few questions to get to know you   True  

False  

6. It is generally preferable to comprehensively document what we do even if it reduces our speed. 7. Money is the best way to motivate individuals. 8. It is more important to respect a pre-established plan than to adapt to changes. 9. A signed contract is more important than an informal agreement to obtain cooperation between different departments.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

351

Results: Are you an Agile manager?   No of Your Agility level   ‘False’ 9 Congratulations! You got a perfect score! If you already master the theory of Agile approaches and apply it to your daily activities, you could teach this training course. J 5 to 8 You are almost there! You will feel at ease with most concepts presented during this training course. During the next 3 hours, you will have the opportunity to revise fundamentals on which your management approach is based. 1 to 4 You are up to a good start towards a more Agile management style.   Concepts and fundamentals of this training course should help you become a more Agile manager. 0

During the next 3 hours, you could ask yourself many questions arising from the course content. Your current paradigm will most probably be harshly tested but you could be really surprised.

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

352

Traditional approaches pose many challenges   What we hear from business people…   v  ‘What we get from IT is not what we need, what we asked for.’   v  ‘There should be more control because project teams often do not respect deadlines and budgets.’   v  ‘What is developed has no value to us.’   v  ‘Applications delivered contain too many bugs.’   v  ‘We have to provide the project team with  all documentation required before they begin to work.’   v  ‘Deadlines are way too long. The project must end earlier.’   v  We do not understand the language used by IT, and we often are under the impression that they do not understand ours.’ v  ‘The situation would be better if IT would collaborate        

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

353

Traditional approaches pose many challenges   What we hear from IT people…   v  ‘Users do not know what they want.’   v  ‘With constantly changing needs, we are not able to respect our deadlines.’   v  ‘We are asked to produce more documents than applications.’ v  ‘Usually projects  start slowly, but then we work like crazy at the end.’ v  ‘Nobody has fun in the team. People feel like to go elsewhere.’   v  ‘We do not have much room for manoeuvre. Therefore, we must reduce our costs yet again.’   v  ‘How can we increase collaboration  between business representatives and us?’ Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

354

Too few projects are successful  

v  Projects’ success rate has not improved since 2000.   v  What is the situation like in your organization?  

Chaos Report–Standish Group, 2009  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

355

Larger projects are less likely to be successful   v  In spite of technological progress, projects are more and more complex. v  Success is uncertain for larger projects.   v  To reduce complexity, projects must be broken  up into smaller parts.   “To eat an elephant, one has to eat it one bite at a time."   – an anonymous savannah hunter  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

356

Solutions do not meet the user’s needs

v  Return on investment is low.   v  Nearly 50% of functions are never used.   v  Traditional approaches force users to prepare a comprehensive list of their needs at the beginning of the project.   v  The longer it takes to develop functions (that will not be used), the longer it takes to reach the market.   Jim Johnson @ XP days–Standish Group, 2002

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

357

Complexity and change will keep increasing v To remain competitive, organizations must:   §  Rapidly adapt to changing markets   §  Keep room for manoeuvre regarding resource allocation   §  Remain flexible while rapidly making decisions   §  Develop and maintain their human capital   v When complexity increases, centralized management and control systems rapidly reach their limit.   v It is impossible to anticipate every  thing in advance.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

358

Market trends adoption of Agile approaches     “By 2012, Agile development methods will be

utilized in 80% of all software development projects.”–Predicts 2010: Agile and Cloud Impact Application Development Directions, Gartner, December 2009       Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

359

Agile approaches are offered in a variety of forms  

Agile Project management (Scrum)   Development practices   Lean approach  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

360

Agility means that things will be done differently Agility does not mean...   v  To no longer do project management   v  To be a chaotic organization that no longer respects its IT governance framework   v  To no longer produce documents   v  To leave the team to itself   v  To do things partially   v  To change every thing overnight   v  That there will no longer be any problems   v  It simply means to do things differently      

!

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

361

Using an Agile approach to increase ROI and employee motivation   v  To develop solutions meeting the business needs   v  To develop solutions on time and within budget   v  To increase efficiency and productivity  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

362

Delivering value with Agile approaches Agile approaches aim at delivering value by capitalizing on individuals and their interactions   v  Applying Agility to all phases of a project means:   §  To frequently deliver business value at a sustainable pace   §  To maintain a high level of quality   §  To encourage the team’s empowerment and accountability as well as collaboration between all stakeholders   §  To use an iterative and incremental approach   §  To remain open to change requests throughout the project  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

363

To reach our goal, we must implement a structured approach v Management allowing to reach the vision by delivering tangible added value   v Use of an iterative and incremental approach within well- established timeboxes   v Implementation of performing  teams

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

364

Agile approaches require a change of paradigm  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

365

PLAN vs BUSINESS VALUE We do not wish to deliver a ‘plan’, we aim at achieving business results   v  To avoid planning everything right from the beginning   v  To support an incremental investment model   v  To ensure that priority is given to the delivery of added value   v  To question ourselves about the relevance of additional functions   v  To evaluate progress based on results rather than respecting a plan   v  To take care of the quality component throughout the project   v  To satisfy our clients early with a useful solution   v  To refine the understanding of the client’s needs   v  To adapt ourselves to change requests   Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

366

Increasing ROI   Using an iterative and incremental approach to increase ROI  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

367

What does it mean to the managers? LEADERSHIP   • Definition of the objectives and performance management   • Management and leadership style   ENVIRONMENT   • Work environment and organizational culture   PROJECT TEAM • Self-sufficiency and accountability • Collaboration and teamwork • Communication and knowledge sharing • Skills and professional development • Continuous improvement e and organizational learning • Processes and tools Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

368

Transition from a traditional to an Agile approach v  Transfer authority and responsibility to the team so it can do its work adequately   v  Avoid interference and micromanagement   v  Promote collaboration and teamwork   v  Support learning and not systematically penalize failures   v  Review best practices in order to adapt  them to changing realities   v  Make adjustments to the facilities so the environment facilitates the execution of Agile projects   v  Adapt the management style to the context of the team  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

369

Managers will be supported by organizational coaches As members of the expertise centre, organizational coaches:   v  Offer training courses to groups of managers (e.g. Agile for managers)   v  Participate in steering committees of pilot projects   v  Individually support  the managers that are related to pilot projects in order to go from a traditional management style to a more Agile one   v  Provide individual or group coaching in order to address fears, challenges, and resistances and to provide appropriate support  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

370

Conclusion v  A transition from a traditional approach to an Agile one is not an IT project, it is rather an organizational change.   v  An Agile approach highly impacts project teams but it also impacts managers and their management style.   v  When this type of transition is successful, it gives a competitive advantage  to the organization.   v  Supporting managers is critical to the success of this type of initiative.  

Tài liệu được biên soạn bởi Ông Nguyễn  Thành  Châu 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

371

Q&A

Tài liệu được biênsoạn soạn bởiNguyễn   Nguyễn Châu   theo yêu cầu của   Tài liệu được biên bởi Ông Thành  CThành hâu theo yêu cầu của Ban quản các dự công nghiệpnghiệp công nghệcông thông tin - Bộ TTthông & TT tin/Bộ TT & TT   Ban quản lý lýcác dựánán công nghệ

372