Csoft_Agile Scrum_v2.0.0

 Mọi người trong mô hình Scrum đều có quyền bổ sung công việc vào Product Backlog và sẽ được sự phê duyệt thông qua của Product Owner... Product Backlog Yêu cầu sản phẩm Product Backlo

Agile Scrum Workshop

Ngô Thị Hoàn

Giới thiệu chung

 Thời gian:30’

 Mục đích:

- Hướng dẫn làm việc theo mô hình Scrum.

- Hướng dẫn sử dụng Jira.

Nội dung

 Nội dung khóa học:

 Tổng quan về Agile Scrum.

 Cách làm việc với mô hình Agile Scrum.

Thế nào là Scrum?

 Mỗi Sprint: 2 – 4 tuần.

 Số người trong team: 5 – 9.

 Scrum được phát triển bởi Ken Schwaber và Jeff Sutherland giữa những năm 1990 với mục tiêu là cung cấp một

sản phẩm có gia trị ngày càng gia tăng trong những khoảng thời gian cố định được gọi là Sprint.

Tuyên ngôn của Agile Scrum

Giá trị của Scrum

 Commitment: Tính cam kết cao trong công việc.

 Focus: Tập trung vào đúng mục tiêu, chiến lược

trong một thời điểm nhất định.

 Openness: Giá trị mở đối với cả trong và ngoài

dự án, mọi thông tin đều minh bạch và công khai.

 Respect: Giá trị gắn kết giữa các thành viên dự

án với nhau, với khách hàng cũng như trong tổ

chức.

 Courage: Giá trị của sự can đảm lãnh nhận và

cam kết với công việc, can đảm công khai minh

bạch mọi thông tin…

Trọng tâm của Scrum

 Timeboxing: Khoảng thời gian là cố định trong mỗi

Sprint của dự án.

 Learning from mistakes and self managing

(Adaptive): Học hỏi, rút kinh nghiệm từ những sai lầm

mắc phải và tự chủ động quản lý.

 Shippable Code: Code đặt trọng tâm vào mục tiêu ngắn

hạn và sản phẩm được đóng gói thành nhiều lần theo

từng giai đoạn để sử dụng thử và cải tiến.

SCRUM Framework

SCRUM Framework

Time

Analysis Design Coding Testing

Vai trò và trách nhiệm

 Product Owner

 Xác định lộ trình phát triển sản phẩm.

 Xác định thứ tự ưu tiên cho các tính năng của sản phẩm.

 Thiết lập các qui tắc trong việc phát triển sản phẩm.

 Mô tả và duy trì mức độ chi tiết cho các tính năng của sản

phẩm.

 Sẵn sàng chuẩn bị cho những cuộc đàn phám có thể xảy ra.

 Định hướng nghiệp vụ trong quá trình phát triển sản phẩm.

 Chấp nhận và xác định mức độ có thể chấp nhận sản phẩm (xác định thời điểm kết thúc việc phát triển sản phẩm).

 Vị trí này có thể là: Trưởng phòng sản xuất, trưởng phòng

kinh doanh, quản trị dự án… hoặc khách hàng.

Vai trò và trách nhiệm

 SCRUM Master (or Facilitator)

 Bảo vệ nhóm và giữ cho họ tập trung tới mục tiêu đã xác

định.

 Loại bỏ các trở ngại đối với nhóm để hướng tới mục tiêu của Sprint.

 Chấp hành, thi hành các qui tắc đối với nhóm.

 Là thành viên điều phối của nhóm.

 Đại diện cho nhóm trước các bên liên quan.

 Kỹ năng cần thiết cho Scrum Master:

 Đặt việc phục vụ nhóm lên dàng đầu.

 Lắng nghe đồng đội cũng như các bên liên quan.

 Phương pháp làm việc hướng tới việc tự tổ chức nhóm.

 Tạo điều kiện (loại bỏ trở ngại).

Vai trò và trách nhiệm

 Team

 Làm việc đa năng trong dự án (có thể làm nhiều công việc

khác nhau không phụ thuộc chuyên môn).

 Không phân cấp thứ bậc trong dự án (không ai quản lý ai).

 Tất cả cùng chịu trách nhiệm với sản phẩm bàn giao cho

khách hàng.

 Báo cáo tình hình công việc mình làm cho Scrum Master và

cả Team.

Vai trò và trách nhiệm

 Stakeholders (customers, vendors)

và những người mà dự án phụ thuộc và soạn ra

những thỏa thuận về lợi ích trong việc phát triển

phần mềm trong dự án.

trong những buổi demo hoặc bàn giao sản phẩm để kiểm chứng khả năng thực tế của hệ thống phần

mềm.

 Managers

việc cho sự phát triển của sản phẩm trong tổ chức.

Definition of Done (DOD) Tiêu chuẩn chấp nhận hoàn thành

của người dùng (user story).

mỗi Product Backlog item.

luận với Scrum Team vào đầu dự án.

(yêu cầu người dùng), Sprint và Release (Bàn giao).

Product Backlog Yêu cầu sản phẩm

 Là tài liệu ở mức độ cao nhất của dự án (tài liệu tổng quan và quan trọng nhất)

 Là tài liệu chứa các yêu cầu của sản phẩm được mô tả tổng quát về các tính năng cần thiết, danh sách các thành phần mong muốn… và được phân thứ tự ưu tiên theo nhu cầu nghiệp vụ

 Tài liệu này chỉ xác định việc dự án cần làm ra sản phẩm gì mà không quan tâm tới việc làm như thế nào và ai là người thực hiện

 Tài liệu này là một tài sản sở hữu của Product Owner, giá trị (độ ưu tiên) của nhu cầu nghiệp vụ được xác định bởi chính Product Owner

 Giá trị ước tính về độ lớn (Size) và công sức cần dùng (Effort)

sẽ do Scrum Team cùng thống nhất và đưa ra

 Mọi người trong mô hình Scrum đều có quyền bổ sung công việc vào Product Backlog và sẽ được sự phê duyệt thông qua của Product Owner

Product Backlog Yêu cầu sản phẩm

 Product Backlog được phát triển lớn dần theo thời gian và có tính chất không bao giờ có thể hoàn thành Như vậy dự án sẽ kết thúc bất kể khi nào Product Owner cảm thấy hài lòng về sản phẩm và quyết định dừng việc phát triển lại, cho dù thời điểm đó Product Backlog có hoàn thiện được bao nhiêu phần trăm đi nữa

 Các tính năng chỉ cần mô tả ở mức chi tiết đủ để Scrum Team

có thể hiểu và đưa vào triển khai trong Sprint Mọi chi tiết với từng yêu cầu sẽ được Scrum Team làm rõ với Product Owner khi triển khai yêu cầu thực tế trong Sprint

 Một số thông tin bắt buộc cần có trong Product Backlog:

 Product Backlog Item: User Stories, Features, Bugs…

 Business Value: Giá trị nhu cầu của nghiệp vụ (Extra High,

High, Medium, Low)

 Product Size: Kích thước ước tính của Team với từng Item.

Product Backlog Yêu cầu sản phẩm

Priority Description (from Team) Size (from Product Value

Product Backlog Prioritization

Xác định thứ tự ưu tiên

 Các kỹ thuật trong việc ước lượng size cho Product Backlog Item:

 Phương pháp ước lượng bằng Story Points:

o Thiết đặt size theo giá trị số Geometric series: 1,2,4,8,16,32…

o Thiết đặt size theo giá trị số Fibonacci series: 1,2,3,5,8

o Việc ước lượng size chỉ mang tính tương đối, không thể chính xác tuyệt đối được.

o Ưu điểm: Độ chính xác của size không quan trọng bằng

tính nhất quán của chúng (Sự nhất quán giữa tính năng lớn và tính năng nhỏ phải được thể hiện, không dùng số bừa bãi).

o Nhược điểm: Giá trị ước tính của một Team cụ thể

Product Backlog Prioritization

o Nhược điểm: Khá là khó khăn cho việc so sánh

kích thước với thời gian cần tiêu tốn để thực hiện.

Product Backlog Prioritization

Xác định thứ tự ưu tiên

 Việc ước lượng Size cho các

Product Backlog Item thường

được thực hiện thông qua cách

thức chơi Planning Pocker

 Với cách thức này mỗi thành

viên của Team sẽ có một bộ bài

Pocker với những lá bài giống

nhau được lựa chọn phù hợp

theo phương pháp estimate đã

nói ở trên

 Mỗi người sẽ úp lá bài mình

định chấm điểm Size cho Item

đang được nhắc tới, sau đó lật

bài Nếu các thành viên chấm

điểm lệch nhau thì người cho

Product Backlog Prioritization

 M ust have: Bắt buộc phải có.

 S hould have: Nên có.

 C ould have: Có thể có hoặc không.

 W on’t have: Không cần thiết.

Phương pháp Invest trong viết yêu cầu (User Story)

• I ndependent: Story phải độc lập, không bị phụ thuộc vào

Story khác.

• N egotiable: Có thể thỏa thuận để thay đổi (thêm/bớt).

• V aluable (to users/customers): Phải có giá trị đối với

người dùng/khách hàng.

• E stimable: phải đủ chi tiết để có thể ước lượng được.

• S mall: Chỉ cần ngắn gọn, không quá nhiều, quá dài

dòng.

• T estable: Phải rõ ràng để có thể chứng thực được.

Velocity Năng xuất làm việc

3

2

Sprint 1 Sprint 2 Sprint 3

TEAM A

Velocity Năng xuất làm việc

Product Backlog

Priority Description

Size (to build)

Release Plan for Team A

Release Plan for Team B

Sprint Planning Meeting

 Thời gian: Kéo dài tối đa 4 giờ (2 giờ với Sprint 2 tuần, 3 giờ với

Sprint 3 tuần…).

 Thành phần tham gia: Product Owner, Scrum Master và Team.

 Product Owner cần chuẩn bị Product Backlog (đủ chi tiết để hiểu) trước khi tiến hành Sprint Planning Meeting.

 Team thực hiện kéo các yêu cầu từ Product Backlog vào Sprint Backlog dựa theo thứ tự ưu tiên và Velocity của Team.

 Mở rộng (làm rõ) yêu cầu hơn bằng cách phân rã các tính năng thành

các Task hoặc viết các User Story ở mức vừa đủ chi tiết để lên kế

hoạch cho chúng.

 Các ước lượng có thể được điều chỉnh lại khi xem xét và thảo luận

trong buổi họp này.

 Các thành viên Team tự nhận task cho mình.

 Các công việc (nội dung, ước tính, người thực hiện…) có thể thay đổi

trong quá trình thực hiện Sprint sao cho đạt năng xuất cao nhất có

thể.

 Tính năng có mức độ ưu tiên thấp hơn có thể được đưa vào Sprint

Sprint planning

 Xác định độ dài thời gian cho Sprint (2 – 4 tuần, cố gắng giữ luôn

ổn định không đổi)

Tính toán tổng công

suất (theo manhour)

của Team trong

Sprint sắp tớ

5 people x 2 wks x 6hrs/day”:

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

179.2

Commitment Cap: 179.2

Ước lượng công sức

(theo manhour) cho

các công việc dự kiến

Sprint Backlog

 Sprint Backlog là kết quả của quá trình lập kế hoạch cho Sprint

 Là tài liệu chứa thông tin về việc làm thế nào để Team có thể xây

dựng được các tính năng trong Sprint Các tính năng sẽ được chia

thành nhiều Task khác nhau để thực hiện

 Các tính năng trong Product Backlog sẽ được lựa chọn đưa vào

Sprint Backlog và được bóc tách thành các Task để thực hiện

 Thu thập ý kiến và sự đồng thuận về các Sprint task trong Sprint

Backlog (nội bộ Team)

 Thành viên Team sẽ tự nhận task cho mình để thực hiện, sẽ không

ai giao việc cho họ mà họ sẽ được chủ động tự quản (Chỉ nhận 1

task trong cùng một thời điểm)

 Các task sẽ được ước lượng thời gian thực hiện và ghi lại vào

Sprint Backlog Việc ước lượng này sẽ được thực hiện bở cả Team

 Mọi thành viên Team đều được phép cập nhật Sprint Backlog trong suốt quá trình thực hiện Sprint cho phù hợp với công việc thực tế

 Sprint Backlog là tài sản chung của cả Team, mọi thành viên đều

Sprint Backlog

Product Backlog Item Task Volunteer Effort (h) Day1 Day2 Day3 Day4 Day5

Feature 1

Task1 DEV1 8 4 1 0 Task2 DEV4 5 3 1 0 Task3 DEV2 4 4 2 0 Task4 DEV3 2 3 3 1 0 Feature 2

Task5 DEV4 2 1 0 Task6 DEV1 3 1 0 Task7 DEV2 6 3 1 0 Task8 DEV3 4 2 0

Total: 34 14 7 6 3 0

Daily Standup Meeting

 Cuộc họp này phải được tiến hành hàng ngày với địa điểm và

thời gian chính xác được đặt cố định trong suốt Sprint

 Thành phần tham gia: Tất cả mọi người đều được chào đón

tham gia buổi họp này (Product Owner, Customer, Managers,

Other Teams…) nhưng chỉ “Heo” (Product Owner, Scrum

Master, Team) được phép lên tiếng

 Thời gian: Buổi họp này chỉ tiến hành trong vòng 15 phút (có

thể nhiều hơn tùy vào số lượng thành viên Team, nhưng không vượt quá 30 phút)

 Ba câu hỏi bắt buộc các thành viên Team phải trả lời:

 Hôm qua bạn đã làm được những gì?

 Hôm nay bạn dự định sẽ làm gì?

 Bạn có gặp vấn đề hay khó khăn gì trong công việc không?

 Scrum Master là người sẽ điều phồi thời gian để mọi người tập

trung vào mục tiêu buổi họp, cập nhật Burn Down Chart và ghi

Burn Down Chart Biểu đồ diễn tiến

 Là một biểu đồ công khai thể hiện tình trạng công việc còn tồn đọng của

Sprint (số effort còn phải sử dụng).

 Cần được cập nhật hàng ngày, nó là cái hình tổng quan và đơn giản về diễn tiến của Sprint Và nó được thực hiện cho tới ngày kết thúc Sprint (phát

hành sản phẩm).

Sprint Review Meetings

 Cuộc họp này diễn ra vào ngày cuối cùng của

Sprint.

 Mục tiêu: Xem xét lại những công việc đã làm

được và chưa làm được của Sprint.

 Nội dung: Team sẽ trình bày các công việc đã

làm được với các bên liên quan (demo sản phẩm).

 Thời gian: Cuộc họp này chỉ kéo dài tối đa 4

tiếng.

 Thành phần tham gia: Product Owner, Scrum

Master, Team và các bên liên quan.

 Chú ý: hạn chế hoặc không dùng Power Point để

trình bày mà phải demo trên sản phẩm thật.

Sprint Retrospective Meeting

 Mục tiêu: Xem xét lại toàn bộ quá trình làm việc vào

cuối mỗi Sprint.

 Thành phần tham gia: Chỉ bao gồm Scrum Team.

 Nội dung: Tất cả các thành viên của Team tự đánh giá

về bản thân và phản ánh các vấn đề đã làm tốt hoặc

chưa tốt của Team trong Sprint vừa qua.

 Ý nghĩa: Cải thiện quy trình và cách thức làm việc liên

tục.

 Có hai câu hỏi chính cần trả lời trong buổi họp:

 Những điểm đã làm tốt trong Sprint vừa qua là gì?

 Những điểm nào cần cải thiện trong Sprint sắp tới?

 Scrum Master sẽ tổng kết lại thứ tự ưu tiên của các vấn

đề cần cải thiện dựa trên sự thống nhất của cả Team.

 Thời gian: Buổi họp này kéo dài tối đa 2 tiếng.

HƯỚNG DẪN SỬ DỤNG JIRA

 Create Components, Versions,

 Create Product backlog (epic, story,

task )

 Create sprint and create sprint backlog

 Create Issue & estimate

 Log work

 Dashboards

Thank you