Báo cáo môn học hệ hỗ trợ ra quyết định nghiên cứu scrum

TRƯỜNG ĐẠI HỌC TÀI CHÍNH – MARKETING
KHOA CƠNG NGHỆ THƠNG TIN

BÁO CÁO MÔN HỌC
HỆ HỖ TRỢ RA QUYẾT ĐỊNH

NGHIÊN CỨU SCRUM

Giảng viên hướng dẫn: Thái Thị Ngọc Lý
Sinh viên thực hiện 1: 2021010354 – Đỗ Tường Vy
Sinh viên thực hiện 2: 1921006688 – Trần Thị Thiên Hảo

Tp.HCM, tháng 6 năm 2022


TRƯỜNG ĐẠI HỌC TÀI CHÍNH – MARKETING
KHOA CƠNG NGHỆ THƠNG TIN

BÁO CÁO MÔN HỌC
HỆ HỖ TRỢ RA QUYẾT ĐỊNH

NGHIÊN CỨU SCRUM

Giảng viên hướng dẫn: Thái Thị Ngọc Lý
Sinh viên thực hiện 1: 2021010354 – Đỗ Tường Vy
Sinh viên thực hiện 2: 1921006688 – Trần Thị Thiên Hảo

Mã lớp học phần: 2221112003901

Tp.HCM, tháng 6 năm 2022

LỜI CẢM ƠN
Báo cáo được thực hiện tại Khoa Công nghệ thơng tin – Trường Đại học Tài
chính – Marketing dưới sự hướng dẫn của cô Thái Thị Ngọc Lý.
Trước tiên, chúng em xin bày tỏ lòng biết ơn sâu sắc đến cô Thái Thị Ngọc Lý
đã giúp chúng em đến với đề tài nghiên cứu này, cô đã tận tình giảng bài và giải
quyết những thắc mắc của chúng em, nhờ đó mà chúng em u mơn học này hơn.
Trong thời gian thực hiện nghiên cứu, mặc dù đã cố gắng nhưng vẫn khơng thể
tránh khỏi thiếu sót. Vì vậy chúng em mong nhận được sự thông cảm, chỉ bảo và
góp ý từ cơ.
Cuối cùng em xin kính chúc cô dồi dào sức khỏe và thành công trong sự nghiệp
giảng dạy để tiếp tục cống hiến và đào tạo ra các thế hệ sinh viên tiếp theo.

Em xin chân thành cảm ơn!

TP.HCM, ngày 16 tháng 6 năm 2022
Sinh viên thực hiện

Đỗ Tường Vy & Trần Thị Thiên
Hảo

i


lOMoARcPSD|12114775

ĐÁNH GIÁ VÀ NHẬN XÉT CỦA GIẢNG VIÊN

...............................................................................................
...............................................................................................

...............................................................................................
...............................................................................................
...............................................................................................
...............................................................................................
...............................................................................................
...............................................................................................
...............................................................................................
...............................................................................................
...............................................................................................
-.....................................................................................

Điểm số:

.......................................................................................
Điểm chữ:

.......................................................................................
TP. HCM, ngày 24 tháng 4 năm 2022
Giảng viên phụ trách học phần
(Ký và ghi rõ họ và tên)

ii


lOMoARcPS D|12114775

MỤC LỤC
LỜI CẢM ƠN................................................................................................................ i
ĐÁNH GIÁ VÀ NHẬN XÉT CỦA GIẢNG VIÊN...................................................... ii
MỤC LỤC.................................................................................................................... iii

DANH MỤC HÌNH ẢNH............................................................................................. v
CHƯƠNG 1: ĐỐI TƯỢNG VÀ PHƯƠNG PHÁP NGHIÊN CỨU..............................1
1.1. Lý do hình thành nghiên cứu.............................................................................. 1
1.2. Mục tiêu của nghiên cứu..................................................................................... 1
1.3. Phạm vi nghiên cứu............................................................................................ 1
1.3.1. Đối tượng nghiên cứu.................................................................................. 1
1.3.2. Không gian và thời gian............................................................................... 1
CHƯƠNG 2: NỘI DUNG VÀ KẾT QUẢ NGHIÊN CỨU SCRUM............................2
2.1. Giới thiệu Scrum................................................................................................. 2
2.2. Đặc điểm của Scrum........................................................................................... 3
2.3. Tính chất của Scrum........................................................................................... 3
2.4. Lợi ích của Scrum............................................................................................... 4
2.5. Vai trị................................................................................................................. 4
2.5.1. Product Owner:............................................................................................ 5
2.5.2. Nhóm phát triển........................................................................................... 5
2.5.3. Scrum Master............................................................................................... 6
2.6. Các sự kiện trong Scrum..................................................................................... 8
2.6.1. Sprint........................................................................................................... 8
2.6.2. Lập kế hoạch Sprint (Sprint Planning):......................................................10
2.6.3. Scrum Hằng ngày (Daily Scrum)...............................................................11
2.6.4. Sơ kết Sprint (Sprint review).....................................................................12
2.6.5. Cải tiến Sprint (Sprint Retrospective)........................................................13
2.7. Các tạo tác trong Scrum – Scrum Artifact........................................................14
2.7.1. Product BackLog.......................................................................................14
2.7.2. Sprint Backlog...........................................................................................16
2.7.3. Phần tăng trưởng........................................................................................18
CHƯƠNG 3: ỨNG DỤNG SRUM VÀO TỔ CHỨC.................................................19
iv

lOMoARcPSD|12114775

3.1. Các tình huống và mức độ sử dụng Scrum.......................................................19
3.2. Lộ trình để đưa Scrum vào tổ chức...................................................................20
3.3. Quản trị dự án linh hoạt vơi Scrum...................................................................20
3.4. Nhận diện và vượt qua các trở lực từ yếu tố văn hóa........................................22
3.5. Quản lý sự thay đổi...........................................................................................23
CHƯƠNG 4: KẾT LUẬN...........................................................................................24
4.1. Ưu điểm và nhược điểm của quản lý dự án Scrum...........................................24
4.1.1. Ưu điểm.....................................................................................................24
4.1.2. Nhược điểm...............................................................................................24
4.2. Hướng nghiên cứu tiếp.....................................................................................25
TÀI LIỆU THAM KHẢO...........................................................................................26

v


lOMoARcPSD|12114775

DANH MỤC HÌNH ẢNH
Hình 2.1 Tổng quan về Scrum....................................................................................... 2
Hình 2.2 Các vai trị trong Scrum.................................................................................. 5
Hình 2.3 Đặc điểm Sprint.............................................................................................. 9
Hình 2.4 Sprint Planning.............................................................................................11
Hình 2.5 Daily Scrum..................................................................................................12
Hình 2.6 Sprint Review...............................................................................................13
Hình 2.7 Sprint Retrospective.....................................................................................13
Hình 2.8 Product Backlog...........................................................................................15
Hình 2.9 Quản lý trực quan: Các hạng mục Product backlog trên tường.....................15
Hình 2.10 Bảng mẫu Sprint Backlog theo dạng Spreadsheet.......................................17

Hình 3.1 Quy mơ Scrum vào tổ chức..........................................................................19
Hình 3.2 Lộ trình đưa Scrum vào tổ chức....................................................................20
Hình 3.3 Mơ hình Hofstede.........................................................................................22
Hình 3.4 Bảng thống kê ứng dụng Scrum vào các nước..............................................22
Hình 3.5 Quy trình quản lý sự thay đổi.......................................................................23

vi


lOMoARcPSD|12114775

CHƯƠNG 1: ĐỐI TƯỢNG VÀ PHƯƠNG PHÁP
NGHIÊN CỨU
1.1. Lý do hình thành nghiên cứu
Nếu trước đây việc quản lý dự án theo mơ hình truyền thống (waterfall) giới
hạn về khả năng thích ứng trước sự thay đổi liên tục từ khách hàng và thời gian
hồn thiện sản phẩm chậm thì quản lý mơ hình Agile Scrum đã “cởi trói” được
những hạn chế trên. Mơ hình Scrum là một phương pháp hiệu quả được nhiều
doanh nghiệp áp dụng trong việc quản lý dự án và phát triển phần mềm.
Ngày nay, Scrum đã trở nên quá phổ biến bởi yếu tố đơn giản, dễ hiểu và được sử
dụng ở nhiều công ty trên thế giới và Việt Nam. Chính vì sự phổ biến và những lợi ích
của nó, nhóm chúng em muốn tìm hiểu về Scrum để mở rộng thêm kiến thức trong
ngành cũng như học hỏi bổ trợ cho quá trình học môn Hệ hỗ trợ ra quyết định.

1.2. Mục tiêu của nghiên cứu
Báo cáo nghiên cứu Scrum hướng đến các mục tiêu sau:
- Hiểu được Scrum là gì và các đặc điểm của Scrum
- Nghiên cứu Scrum Framework và diễn đạt lại nội dung
- Tìm hiểu Lợi ích của Scrum mang lại cho doanh nghiệp
1.3. Phạm vi nghiên cứu

1.3.1. Đối tượng nghiên cứu
Đối tượng nghiên cứu các kiến thức xung quanh Scrum:
- Khái niệm, đặc điểm, tính chất, lợi ích
- Vai trò, các sự kiện, các tạo tác
- Kết luận ưu nhược điểm
1.3.2. Không gian và thời gian
Không gian: Nghiên cứu được thực hiện trên phạm vi sách báo và các tài liệu
liên quan đến phương pháp phát triển phần mềm Agile, đặc biệt là Scrum
Thời gian: từ 2/6/2022 đến 16/6/2022

vii


lOMoARcPSD|12114775

CHƯƠNG 2: NỘI DUNG VÀ KẾT QUẢ NGHIÊN
CỨU SCRUM
2.1. Giới thiệu Scrum
Scrum là một phương pháp Agile dùng cho phát triển sản phẩm, đặc biệt là phát
triển phần mềm. Scrum là một khung quản lý dự án được áp dụng rất rộng rãi, từ những dự
án đơn giản với một nhóm phát triển nhỏ cho đến những dự án có yêu cầu rất phức tạp với
hàng trăm người tham gia, và kể cả những dự án đòi hỏi khung thời gian cố định.

Hình 2.1 Tổng quan về Scrum

Trong Scrum, cơng việc được thực hiện bởi Nhóm Scrum thơng qua từng phân đoạn
lặp liên tiếp nhau được gọi là Sprint.

viii

lOMoARcPSD|12114775

Để hiểu được Scrum thì cần hiểu nguyên lý của Scrum, các Vai trò, Tạo tác, Sự
kiện và sự vận hành của một vịng đời Scrum.

2.2. Đặc điểm của Scrum
Nhóm Scrum có 2 đặc điểm đó là tự quản (self-managing) và liên chức năng (crossfunctional).
Tự quản (self-managing): Đây là một thuật ngữ mới thay thế cho thuật ngữ cũ (selforganizing) được cập nhật trong tài liệu Hướng dẫn Scrum mới nhất năm 2020. Điều này
có nghĩa là nhóm sẽ cùng ra quyết định sẽ làm gì, ai sẽ làm và làm như thế nào mà không
bị sự chỉ đạo bởi ai đó bên ngồi nhóm. Các Nhóm Scrum được trao quyền để quản lý
công việc của họ nhằm hướng tới một mục tiêu chung là giúp tổ chức giải quyết các vấn đề
phức tạp nhanh nhẹn hơn và tạo ra kết quả chất lượng hơn.
Liên chức năng (cross-functional): Một nhóm liên chức năng bao gồm nhiều cá
nhân với các chuyên môn khác nhau đủ năng lực được kết hợp lại cùng làm việc hướng tới
một mục tiêu chung. Trong dự án, các cá nhân có thể đến từ nhiều phịng ban chức năng
khác nhau, cũng có thể xuất phát từ bên ngồi. Nhưng khi đã thành một nhóm (team), thì
các cá nhân làm việc tập trung cho đội như là một đơn vị (unit) để hoàn tất mục tiêu chung.
Bên trong nhóm liên chức năng khơng có các nhóm nhỏ khác.

2.3. Tính chất của Scrum
Bằng việc sử dụng phương pháp lặp đi lặp lại và tăng dần, Scrum giúp tối ưu hóa khả
năng dự đốn và kiểm sốt rủi ro. Đó chính là ba trụ cột (hay ba chân) của Scrum là Tính
minh bạch, Sự thanh tra và Sự thích nghi. Đây chính là phần lõi của khung làm việc
Scrum, thiếu bất cứ trụ cột nào trong số này đều khiến khung Scrum khơng cịn hoạt động
đúng nữa.

ix

lOMoARcPSD|12114775

Minh bạch (transparency): Đầu tiên, thông tin liên quan tới q trình phát triển
phải minh bạch và thơng suốt. Các thơng tin đó có thể là: tầm nhìn (vision) về sản phẩm,
yêu cầu khách hàng, tiến độ công việc, các khúc mắc rào cản,… Từ đó mọi người ở các vai
trị khác nhau có đủ thơng tin cần thiết để tiến hành các quyết định có giá trị nhằm nâng
cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin
được minh bạch cho các bên.
Thanh tra (inspection): Công tác thanh tra liên tục các hoạt động trong Scrum đảm
bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến
được với các bên tham gia quá trình phát triển. Truy xét kỹ càng và liên tục là cơ chế khởi
đầu cho việc thích nghi và các cải tiến liên tục trong Scrum.
Thích nghi (adaptation): Dựa trên các thơng tin minh bạch hóa từ các q trình
thanh gia và làm việc, Scrum có thể phản hồi các thay đổi một cách tích cực, nhờ đó mang
lại thành công cho sản phẩm. Các nỗ lực minh bạch và thanh tra đều hướng tới hành động
thích ứng nhanh chóng và hiệu quả.

2.4. Lợi ích của Scrum
Sự có mặt của Scrum giúp cho những dự án phát triển phần mềm lượt bỏ những
công đoạn phức tạp, hướng đến những công việc quan trọng nhằm đáp ứng tốt nhất
mọi nhu cầu của khách hàng đưa ra. Những lợi ích nổi bật của Scrum có thể kể đến
là:
Cải thiện chất lượng phần mềm một cách hiệu quả.
Rút ngắn thời gian phát hành phần mềm, mang đến những trải nghiệm sử
dụng sản phẩm nhanh chóng và chất lượng cho khách hàng.
Thúc đẩy tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của nhóm phát
triển.
Gia tăng tỷ suất hồn vốn đầu tư (ROI).
Tạo độ tin cậy, hài lòng của khách hàng.
Kiểm soát tiến độ của dự án tốt, liên tục cải tiến và hạn chế rủi ro không

mong muốn khi xây dựng sản phẩm.
2.5. Vai trị
Trong Scrum, có ba vai trò: Product Owner, Development Team và
ScrumMaster. Tất cả hợp thành Nhóm Scrum.

x


lOMoARcPSD|12114775

Hình 2.2 Các vai trị trong Scrum

2.5.1. Product Owner:
Product Owner chịu trách nhiệm tối ưu hóa lợi nhuận trên đầu tư (ROI Return On Investment) thông qua việc xác định các tính năng của sản phẩm, chuyển
thành một danh sách ưu tiên, quyết định hạng mục nào sẽ nằm phía trên của danh
sách để đưa vào Sprint tiếp theo, và liên tục tái-sắp xếp và làm mịn danh sách này.
Nếu là sản phẩm thương mại, Product Owner chịu trách nhiệm về lợi nhuận cũng
như tổn thất của sản phẩm. Trong trường hợp của một ứng dụng nội bộ, Product
Owner không chịu trách nhiệm về ROI theo nghĩa của sản phẩm thương mại (sẽ tạo
ra thu nhập), mà chịu trách nhiệm tối ưu hóa ROI theo nghĩa lựa chọn các hạng mục
có giá trị cao nhất cho mỗi Sprint. Trong thực tế, “giá trị” là một khái niệm mập mờ
và việc đánh giá độ ưu tiên có thể bị ảnh hưởng bởi mong muốn làm hài lòng các
khách hàng chủ chốt, gắn với các mục tiêu chiến lược, hạn chế rủi ro, cải tiến hay
các yếu tố khác.
Trong một số trường hợp, Product Owner cũng chính là khách hàng; điều này
thường xảy ra đối với các sản phẩm nội bộ. Trong một số trường hợp khác, khách

xi

lOMoARcPSD|12114775

hàng có thể là hàng triệu người với sự đa dạng về nhu cầu, khi đó vai trị Product
Owner là tương tự như vị trí Product Manager (Giám đốc Sản phẩm) hoặc Product
Marketing Manager (Giám đốc Tiếp thị Sản phẩm) trong nhiều tổ chức phát triển
sản phẩm. Tuy nhiên, Product Owner thường khác với một Giám đốc Sản phẩm
truyền thống ở chỗ họ chủ động và thường xuyên trao đổi với Nhóm, ưu tiên làm
việc với tất cả các bên liên quan và rà soát kết quả của mỗi Sprint thay vì ủy quyền
các quyết định phát triển cho một quản lý dự án. Một lưu ý quan trọng là trong
Scrum có một và chỉ một người phục vụ với tư cách Product Owner và có thẩm
quyền tối cao của vai trò này, người này chịu trách nhiệm về giá trị của công việc,
mặc dù không nhất thiết phải làm việc một mình.
Product owner chịu trách nhiệm quản lý product backlog:
- Miêu tả rõ ràng từng backlog item
- Sắp xếp mức độ ưu tiên của backlog item hợp lý
- Tối ưu hóa giá trị mà Development team thực hiện
- Đảm bảo product backlog rõ ràng, minh bạch
- Đảm bảo Development team hiểu product backlog
2.5.2. Nhóm phát triển
Nhóm Phát triển xây dựng sản phẩm mà Product Owner yêu cầu, chẳng hạn
một ứng dụng hoặc một trang web. Nhóm Phát triển quyết định số lượng các hạng
mục (từ tập hợp do Product Owner đưa ra) để xây dựng trong một Sprint cũng như
cách tốt nhất để đạt được mục tiêu đó.
Chú ý rằng khơng có các chức danh chun mơn cố định trong một nhóm triển
khai Scrum; khơng có chun gia phân tích nghiệp vụ, khơng có chun gia DBA,
khơng có chun gia kiến trúc, khơng có trưởng nhóm, khơng có chun gia thiết kế
tương tác/UX, khơng có lập trình viên. Họ làm việc cùng nhau trong từng Sprint
bằng bất cứ cách nào phù hợp để đạt được mục tiêu mà chính họ đã đưa ra.
Do chỉ có các thành viên nhóm, Nhóm Phát triển khơng chỉ là liên-chức năng
mà cịn thể hiện việc học tập lẫn nhau: mỗi người sở hữu một thế mạnh riêng,

nhưng vẫn tiếp tục học các chuyên mơn khác. Mỗi người sẽ có các kỹ năng chính,
kỹ năng phụ thứ hai và thậm chí là thứ ba. Ví dụ, một người với kỹ năng chính là
thiết kế tương tác có thể có kỹ năng phụ là kiểm thử tự động; một người với kỹ
năng chính là viết tài liệu kỹ thuật cũng có thể trợ giúp với phân tích và lập trình
và đối với sản phẩm phần mềm.
Nhóm phát triển sản phẩm đồng thời cung cấp ý tưởng cho Product Owner về
cách để tạo ra sản phẩm tốt. Trong Scrum, Nhóm Phát triển sẽ trở nên năng suất và
hiệu quả nhất khi các thành viên đều dành toàn bộ 100% để làm việc cho một sản
xii


lOMoARcPSD|12114775

phẩm trong suốt Sprint; Nhóm Phát triển tránh làm việc đa nhiệm giữa nhiều sản
phẩm hoặc dự án để loại bỏ sự thất thoát tốn kém do phân tâm và chuyển đổi bối
cảnh.
Nhóm phát triển có những đặc điểm sau:
- Tự tổ chức (self-organizing): Nhóm phát triển tự lên kế hoạch, ước lượng và
quản lý cơng việc của mình.
- Hoạt động chéo (cross-functional): Nhóm phát triển có đầy đủ các kỹ năng
cần thiết của một team cho sự gia tăng của sản phẩm.
- Trong Scrum, chúng ta không nhận ra được các sub team trong
Development team, bất kể những việc cần được giải quyết như kiểm thử, thiết kế
cấu trúc, vận hành hoặc phân tích kinh doanh.
- Mỗi thành viên trong Nhóm phát triển có thể có các kỹ năng chuyên môn
riêng và chỉ tập trung vào một số việc nhất định như chỉ code hoặc chỉ test,
nhưng trách nhiệm thuộc về Nhóm phát triển nói chung.
- Một nhóm phát triển tối ưu nên có từ 3 đến 9 người. Nhóm Phát triển có thể
bao gồm các cá nhân với kỹ năng phân tích, phát triển, kiểm thử, thiết kế giao diện,
thiết kế cơ sở dữ liệu, thiết kế kiến trúc, viết tài liệu, và những kỹ năng khác

2.5.3. Scrum Master
ScrumMaster giúp nhóm học và áp dụng Scrum để đạt được giá trị thương
mại. ScrumMaster làm tất cả những gì trong thẩm quyền của mình để giúp Nhóm
Phát triển, Product Owner và tổ chức trở nên thành công.
ScrumMaster không phải là người quản lý của các thành viên Nhóm Phát
triển, cũng khơng phải là quản lý dự án, trưởng nhóm, hay đại diện của nhóm. Thay
vào đó, ScrumMaster phục vụ Nhóm Phát triển; là người giúp loại bỏ các trở ngại,
bảo vệ Nhóm Phát triển khỏi các tác động từ bên ngồi, và trợ giúp Nhóm Phát
triển ứng dụng các kỹ thuật phát triển hiện đại. ScrumMaster cũng dạy, huấn luyện
và hướng dẫn Product Owner, Nhóm Phát triển và phần còn lại của tổ chức trong
việc áp dụng thành thạo Scrum. ScrumMaster là một huấn luận viên và cũng là một
giáo viên.
ScrumMaster đảm bảo rằng tất cả mọi người (bao gồm cả Product Owner và
những người trong ban quản trị) hiểu các nguyên lý và kỹ thuật của Scrum, và họ sẽ
hỗ trợ dẫn dắt tổ chức vượt qua những thay đổi thường là rất khó khăn nhưng cần
thiết để đạt được thành công với phát triển linh hoạt. Do Scrum giúp phát hiện nhiều
trở ngại và nguy cơ ảnh hưởng đến hiệu quả của Nhóm Phát triển và Product
Owner, một điều quan trọng đó là phải có ScrumMaster làm việc hăng hái để giúp

xiii


lOMoARcPSD|12114775

giải quyết những vấn đè đó, nếu khơng Nhóm Phát triển và Product Owner sẽ khó
mà thành cơng được.
Cần phải có một ScrumMaster làm việc tồn thời gian, mặc dù đối với một
Nhóm Phát triển nhỏ hơn thì có thể cử một thành viên đảm nhận vai trò này (khi đó
sẽ đảm nhiệm ít cơng việc thường ngày hơn). Một ScrumMaster giỏi có thể xuất
thân từ bất cứ nền tảng hoặc chuyên môn nào: Kỹ thuật, Thiết kế, Kiểm thử, Giám

đốc Sản phẩm, Quản lý Dự án, hoặc Quản lý Chất lượng.
Scrum master hỗ trợ product owner
- Đảm bảo rằng mục tiêu, phạm vi và lĩnh vực sản phẩm được các thành viên
trong Scrum team hiểu rõ nhất có thể.
- Tìm kiếm các kỹ thuật để giúp Product owner quản lý Product Backlog hiệu
quả
- Giúp Scrum team hiểu được các mục Product Backlog rõ ràng và ngắn gọn.
- Hiểu quy hoạch sản phẩm trong môi trường thực nghiệm.
- Đảm bảo Product owner biết cách sắp xếp Product Backlog để tối đa hóa giá

trị.
- Hiểu và thực hành linh động.
- Tạo điều kiện cho các Scrum event diễn ra thuận lợi theo yêu cầu.
Scrum Master hỗ trợ Development Team
Huấn luyện đội ngũ phát triển tự tổ chức (Self-organizing) và hoạt động chéo
(Cross-functional).
- Giúp Development team tạo ra các sản phẩm có giá trị cao.
- Loại bỏ các trở ngại ảnh hưởng tới tiến độ của Development team.
- Tạo điều kiện cho các Scrum event cần thiết diễn ra suôn sẻ theo yêu cầu.
- Huấn luyện đội ngũ phát triển trong môi trường của tổ chức, nơi mà Scrum
chưa được chấp nhận và hiểu đầy đủ.
- Scrum Master hỗ trợ cho Tổ chức
- Dẫn dắt và huấn luyện tổ chức trong việc áp dụng Scrum.
- Lập kế hoạch triển khai Scrum trong một tổ chức.
- Giúp nhân viên và các bên liên quan hiểu, ban hành Scrum và phát triển sản
phẩm thực tế theo Scum.
- Tạo ra sự thay đổi trong tổ chức để làm tăng năng suất của Scrum team.

xiv

lOMoARcPSD|12114775

- Làm việc với các Scrum Master khác để làm tăng hiệu quả trong việc
áp dụng Scrum trong một tổ chức.
* Ngồi ba vai trị kể trên, cịn có các bên liên quan khác đóng góp vào sự
thành cơng của sản phẩm, bao gồm các nhà quản lý, khách hàng và người dùng
cuối.
2.6. Các sự kiện trong Scrum
Sprint là một sự kiện chứa tất cả các sự kiện khác. Mỗi sự kiện trong Scrum
là một cơ hội chính thức để kiểm tra và thích ứng các tạo phẩm của Scrum. Các sự
kiện này được thiết kế một cách cụ thể nhằm tạo ra sự minh bạch cần thiết. Việc
không thực hiện được bất cứ sự kiện nào như quy định ở đây sẽ làm mất cơ hội
kiểm tra và thích ứng. Các sự kiện được sử dụng trong Scrum để tạo ra sự điều tiết
và để giảm thiểu nhu cầu tổ chức các cuộc họp không được định ra trong Scrum.
Tốt nhất, tất cả các sự kiện nên được tổ chức vào thời gian và địa điểm cố định để
giảm sự phức tạp.
2.6.1. Sprint
Mục đích: Thực hiện hóa các hàng mục ưu tiên trong Product Backlog
Thành phần: nhóm Scrum và có thể có những người có liên quan khác
Khung thời gian: 1 - 4 tuần
Có thể nói Sprint là trái tim của Scrum, trong đó, các ý tưởng được biến
thành giá trị. Chúng có khoảng thời gian cố định mà ở đó các Nhà Phát triển thực
hiện cơng việc phát triển sản phẩm.
Sprint được đóng khung thời gian khơng dài hơn 1 tháng và thường thì
khơng ngắn hơn một tuần. Các Sprint có độ dài như nhau và diễn ra liên tiếp nhau
mà không bị gián đoạn. Sprint kết thúc khi thời gian đóng khung kết thúc, bất kể
các cơng việc trong đó đã được hồn thành hết hay chưa.
Trong một Sprint:
● Khơng được thực hiện những thay đổi có thể làm tổn hại đến Sprint Goal;

● Chất lượng không giảm sút;
● Product Backlog được tinh chỉnh nếu cần thiết;
● Phạm vi cơng việc có thể được làm rõ thêm và thảo luận lại với Product
Owner khi một số thông tin trở nên rõ ràng hơn.

xv


lOMoARcPSD|12114775

Hình 2.3 Đặc điểm Sprint

Một Sprint có thể bị huỷ bỏ nếu Sprint Goal trở nên lỗi thời. Chỉ có Product
Owner có quyền huỷ Sprint.
2.6.2. Lập kế hoạch Sprint (Sprint Planning):
Mục đích: Xác định việc cần làm, lựa chọn hạng mục và làm rõ và phân rã
thành các nhiệm vụ cụ thể đưa lên Sprint Backlog
Thành phần: nhóm Scrum và có thể có những người có liên quan khác
Khung thời gian: 4 giờ cho Sprint 4 tuần
Lập kế hoạch Sprint khởi đầu Sprint bằng cách sắp xếp công việc cần thực
hiện cho Sprint. Kế hoạch kết quả này được tạo nên bởi sự cộng tác của tồn bộ
Nhóm Scrum. Product Owner đảm bảo rằng những người tham dự được chuẩn bị để
thảo luận về các hạng mục Product Backlog quan trọng nhất và cách chúng liên kết
với Mục tiêu Sản phẩm. Nhóm Scrum cũng có thể mời những người khác tham gia
Lập kế hoạch Sprint để nhận được lời khuyên. Buổi Lập kế hoạch Sprint diễn ra
vào đầu mỗi Sprint. Lập kế hoạch Sprint giải quyết các chủ đề sau:
Chủ đề 1: Tại sao Sprint này lại có giá trị?
Product Owner và Nhóm Phát triển rà sốt lại những hạng mục có độ ưu tiên
cao trong Product Backlog mà Product Owner muốn triển khai trong Sprint này.
Thông thường, những hạng mục này đã được phân tích kỹ trong các Sprint trước

(trong buổi Làm mịn Product Backlog), do vậy lúc này chỉ cần làm rõ những thắc
mắc nhỏ còn lại. Trong phần này, Product Owner và Nhóm Phát triển thảo luận các
mục tiêu và hiện trạng của các hạng mục có độ ưu tiên cao trong Product Backlog,
giúp Nhóm phát triển hiểu rõ mong muốn của Product Owner. Phần Một tập trung
để hiểu Product Owner muốn những gì và tại sao lại cần chúng.

xvi


lOMoARcPSD|12114775

Sau đó, tồn bộ Nhóm Scrum sẽ cộng tác để xác định Mục tiêu Sprint nhằm
truyền đạt lý do tại sao Sprint lại có giá trị đối với các bên liên quan. Mục tiêu
Sprint phải được chốt lại trước khi kết thúc buổi Lập kế hoạch Sprint. Đây là một
đoạn tóm lược lại mục tiêu của Sprint, lý tưởng nhất là nó có một nội dung cơ đọng.
Mục tiêu Sprint cũng giúp cho Nhóm Phát triển có được sự linh hoạt-trong-phạm vi
liên quan đến những thứ mà thực tế họ chuyển giao được, bởi vì mặc dù họ có thể
phải loại bỏ một số hạng mục (do Sprint được đóng khung thời gian), họ vẫn cần
phải cam kết chuyển giao thứ gì đó thấy được và đã “hồn thành” như trong tinh
thần của Mục tiêu Sprint.
Chủ đề 2: Công việc gì có thể hồn thành trong Sprint này?
Thơng qua thảo luận với Product Owner, các Nhà phát triển chọn các hạng
mục từ Product Backlog để đưa vào Sprint hiện tại. Nhóm Scrum có thể tinh chỉnh
các mục này trong quá trình chọn này, nhằm tăng cường sự hiểu biết và sự tự tin.
Việc chọn số lượng hạng mục có thể hồn thành trong một Sprint có thể là một
thách thức. Tuy nhiên, khi các Nhà phát triển càng biết nhiều về hiệu suất làm việc
trong quá khứ, năng lực sắp tới và Định nghĩa Hồn thành của họ, thì họ càng tin
tưởng vào các dự báo Sprint của mình.
Chủ đề 3: Cơng việc đã chọn sẽ được hồn thành bằng cách nào?
Đối với mỗi hạng mục Product Backlog đã chọn, các Nhà phát triển lập kế

hoạch công việc cần thiết để tạo ra Phần sản phẩm gia tăng đáp ứng Định nghĩa
Hoàn thành. Điều này thường được thực hiện bằng cách chia nhỏ các hạng mục
Product Backlog thành các mục công việc nhỏ hơn sẽ được làm trong một ngày
hoặc ngắn hơn. Việc này được thực hiện như thế nào là do các Nhà phát triển quyết
định. Không ai khác chỉ cho họ cách biến các hạng mục Product Backlog thành các
Phần sản phẩm gia tăng về giá trị. Mục tiêu Sprint, các hạng mục Product Backlog
được chọn cho Sprint, cùng với kế hoạch thực hiện chúng được gọi chung là Sprint
Backlog. Lập kế hoạch Sprint có khung thời gian tối đa là tám giờ cho Sprint một
tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.
Khi kết thúc buổi Lập kế hoạch Sprint, Nhóm Phát triển đưa ra một mục tiêu
thực tế mà họ tin là có thể chuyển giao được vào cuối Sprint. Theo truyền thống,
đây được gọi là Cam kết Sprint - nhóm cam kết làm những gì tốt nhất có thể để
đạt được mục tiêu của mình.

xvii


lOMoARcPSD|12114775

Hình 2.4 Sprint Planning

2.6.3. Scrum Hằng ngày (Daily Scrum)
Mục đích: Thanh tra – thích nghi liên tục
Thành phần: ScrumMaster, Nhà Phát triển
Khung thời gian: 15 phút
Là buổi gặp mặt ngắn 15 phút hằng ngày của tất cả các thành viên Nhóm Phát
triển để thanh tra và tái lập kế hoạch cho nhóm.
Trong buổi Scrum Hằng ngày, từng thành viên một lần lượt trình bày với mọi
người ba thứ: (1) Mình đã làm được gì kể từ buổi gặp mặt trước?; (2) Mình sẽ làm
những gì từ bây giờ đến buổi gặp mặt tiếp theo?; và (3) Mình gặp phải trở ngại gì?.

Buổi Scrum Hằng ngày là lúc để các thành viên của Nhóm Phát triển tự-tổ chức có
thể chia sẻ với nhau về tình hình cơng việc, giúp họ phối hợp tốt hơn. Một thành
viên ghi lại các khó khăn, sau đó ScrumMaster chịu trách nhiệm giúp các thành viên
Nhóm giải quyết chúng.
Nội dung chính của buổi trao đổi là trình bày câu trả lời cho ba câu hỏi ở trên.
Nếu cần thiết phải thảo luận thì nên tổ chức ngay sau khi kết thúc buổi Scrum Hằng
ngày, chia thành một hoặc nhiều các nhóm thảo luận cùng lúc, tuy nhiên nó là
khơng bắt buộc. Các cuộc thảo luận này chính là để một vài thành viên hoặc tồn bộ
Nhóm thích nghi với các thơng tin nhận được trong buổi Scrum Hằng ngày (đây
cũng chính là một chu trình thanh tra và thích nghi nữa của Scrum).

xviii


lOMoARcPSD|12114775

Hình 2.5 Daily Scrum

2.6.4. Sơ kết Sprint (Sprint review)
Mục đích: Rà soát kết quả làm được, nhận về phản hồi liên quan đến sản
phẩm
Thành phần: nhóm Scrum và có thể có những người có liên quan khác
Khung thời gian: 4 giờ cho Sprint 4 tuần
Là sự kiện diễn ra ở cuối Sprint nhằm thanh tra và thích nghi sản phẩm đang
được xây dựng. Đây là nơi mà mọi người rà sốt lại kết quả của Sprint. Bất cứ ai
có mặt đều có thể tự do đưa ra câu hỏi và đóng góp ý kiến.
Sự kiện này bao gồm 2 hoạt động chính đó là dùng thử sản phẩm và thảo luận
về tình hình của sản phẩm, hướng đi tiếp theo và những điều chỉnh đối với sản
phẩm nếu cần thiết. Product Backlog và Kế hoạch Phát hành có thể được điều
chỉnh sau sự kiện này.

xix


lOMoARcPSD|12114775

Hình 2.6 Sprint Review

2.6.5. Cải tiến Sprint (Sprint Retrospective)
Mục đích: Cải tiến liên tục cách làm việc để hiệu quả và vui vẻ hơn
Thành phần: ScrumMaster, Nhà Phát triển
Khung thời gian: 3 giờ cho Sprint 4 tuần
Đây là cơ hội để Nhóm Phát triển thảo luận những thứ đang làm tốt và những
thứ khơng làm tốt, từ đó thống nhất các thay đổi cần thực hiện. Kết quả của buổi
làm việc này là một danh sách các thay đổi về cách làm việc được đưa vào áp
dụng ngay trong Sprint tiếp theo.

Hình 2.7 Sprint Retrospective

2.7. Các tạo tác trong Scrum – Scrum Artifact
Các tạo tác của Scrum đại diện cho công việc hoặc giá trị để cung cấp sự minh
bạch và cơ hội để kiểm tra và điều chỉnh. Các tạo phẩm được định nghĩa bởi Scrum

xx


lOMoARcPSD|12114775

được thiết kế đặc biệt để tối đa hóa tính minh bạch của thông tin quan trọng để mọi
người đều có cùng hiểu biết về sản phẩm.

2.7.1. Product BackLog
Khi một nhóm dự định chuyển sang Scrum thì trước khi có thể bắt đầu Sprint
đầu tiên họ cần có một Product Backlog. Đây là một danh sách ưu tiên (được sắp
xếp 1, 2, 3, ...) của các tính năng hướng-khách hàng (customer-centric). Đây là
nguồn yêu cầu duy nhất cho bất kỳ thay đổi nào được thực hiện cho sản phẩm.
Product owner chịu trách nhiệm về Product Backlog, bao gồm nội dung, tính khả
dụng và thứ tự ưu tiên.
Product Backlog tồn tại (và tiến hóa) trong suốt vịng đời của sản phẩm; nó
cũng là lộ trình của sản phẩm. Tại bất cứ thời điểm nào, Product Backlog cũng là
một góc nhìn duy nhất và mang tính quyết định của “tất cả mọi thứ có thể được
Nhóm Phát triển hồn thành theo thứ tự ưu tiên”. Chỉ tồn tại duy nhất một Product
Backlog cho một sản phẩm; có nghĩa là Product Owner cần phải đưa ra các quyết
định đánh giá ưu tiên xuyên suốt toàn bộ phạm vi, đại diện cho quyền lợi của các
bên liên quan (bao gồm cả Nhóm Phát triển).

Hình 2.8 Product Backlog

xxi


lOMoARcPSD|12114775

Hình 2.9 Quản lý trực quan: Các hạng mục Product backlog trên tường

Product Backlog bao gồm nhiều hạng mục khác nhau, chủ yếu là các tính năng
mới cho khách hàng (“cho phép tất cả người dùng thêm sách vào trong giỏ hàng”),
và cịn có các mục tiêu cải tiến kỹ thuật trọng yếu (ví dụ, “viết lại hệ thống từ C++
sang Java”), các mục tiêu cải tiến (ví dụ, “tăng tốc độ các kiểm thử”), các công việc
nghiên cứu (“nghiên cứu giải pháp để tăng tốc độ xác nhận thẻ tín dụng”), và cịn có
thể là các lỗi đã được phát hiện (“chẩn đoán và sửa các lỗi của của đoạn mã xử lý

hóa đơn”) nếu chỉ có ít lỗi. (Một hệ thống với q nhiều lỗi thì thường có một hệ
thống theo dõi lỗi riêng biệt.)
Một Product Backlog tốt cần đạt được tiêu chí DEEP:
Detailed appropriately (Chi tiết hợp lý). Các hạng mục với độ ưu tiên cao
cần được làm mịn và chi tiết hơn so với các hạng mục với độ ưu tiên thấp, bởi vì
chúng được lựa chọn để thực hiện trước. Ví dụ, 10% trên cùng của Backlog có thể
bao gồm các hạng mục rất nhỏ và được phân tích kỹ, và 90% cịn lại thì ít chi tiết
hơn.
Estimated (Được ước lượng). Các hạng mục dành cho bản phát hành hiện tại
cần phải được ước lượng, và hơn nữa cần phải xem xét tái-ước lượng trong mỗi
Sprint khi mà mọi người học và có xuất hiện thêm thơng tin mới. Nhóm Phát triển
cung cấp cho Product Owner khối lượng cơng việc ước tính của từng hạng mục
trong Product Backlog, và cũng có thể bao gồm cả ước tính rủi ro kỹ thuật. Product
Owner và các bên liên quan về nghiệp vụ khác cung cấp thông tin về giá trị của yêu
cầu sản phẩm, có thể bao gồm lợi nhuận thu được, chi phí được giảm thiểu, rủi ro
kinh doanh, tầm quan trọng đối với một số bên liên quan, và nhiều thứ khác.

xxii


lOMoARcPSD|12114775

Emergent (Tiến hóa). Đáp lại việc học tập và biến đổi, Product Backlog
thường xuyên được làm mịn. Trong mỗi Sprint, các hạng mục có thể được thêm
vào, xóa đi, hoặc thay đổi, chia nhỏ và thay đổi độ ưu tiên. Do vậy, Product Backlog
liên tục được cập nhật bởi Product Owner để thể hiện các thay đổi trong nhu cầu
của khách hàng, các ý tưởng hoặc hiểu biết mới, động thái của các đối thủ cạnh
tranh, các rào cản kỹ thuật vừa xuất hiện, v.v…
Prioritized (Sắp xếp theo độ ưu tiên). Các hạng mục ở phía trên của Product
Backlog được đánh độ ưu tiên hoặc sắp xếp theo trật tự 1-N. Nhìn chung, các hạng

mục có độ ưu tiên cao nhất cần phải chuyển giao phần lớn lợi ích tương xứng với
đồng tiền mà bạn đã bỏ ra: nhiều lợi ích (giá trị thương mại) với ít tiền nhất (chi
phí). Một lí do khác có thể dẫn đến tăng độ ưu tiên của một hạng mục là nhằm giải
quyết sớm các rủi ro lớn trước khi chúng tấn công bạn.
2.7.2. Sprint Backlog
Sprint Backlog là tập hợp các mục Product Backlog được chọn cho Sprint,
cộng với một bản kế hoạch bàn giao sản phẩm và thực hiện Mục tiêu Sprint. Sprint
Backlog là dự báo của Nhóm phát triển về chức năng nào sẽ được thực hiện tiếp
theo và công việc cần thiết để có thể bàn giao được chức năng đó thành một phần
tăng trưởng.
Sprint Backlog hiển thị tất cả công việc mà Nhóm phát triển xác định là cần
thiết để đáp ứng Mục tiêu Sprint. Để đảm bảo cải tiến liên tục, nó bao gồm ít nhất
một cải tiến quy trình có mức độ ưu tiên cao đã được xác định trong cuộc họp cải
tiến (Retrospective meeting) trước đó.
Khi có một cơng việc mới bắt buộc, Nhóm phát triển thêm nó vào Sprint
Backlog. Khi cơng việc được thực hiện hoặc hồn thành, cơng việc cịn lại sẽ được
ước tính và cập nhật. Khi các yếu tố của kế hoạch được coi là khơng cần thiết,
chúng sẽ bị xóa. Chỉ Nhóm phát triển mới có thể thay đổi Sprint Backlog của mình
trong Sprint. Sprint Backlog là một hình ảnh thời gian thực rất rõ ràng về cơng việc
mà Nhóm phát triển dự định thực hiện trong Sprint và nó chỉ thuộc về Nhóm phát
triển.
Giám sát tiến trình Sprint tại bất kỳ thời điểm nào trong Sprint, tổng số cơng việc
cịn lại trong Sprint Backlog có thể được tính tốn. Nhóm phát triển theo dõi tổng số
cơng việc cịn lại ít nhất là cho mỗi buổi Daily Scrum (họp Scrum hàng ngày) hàng
ngày để dự đoán khả năng đạt được Mục tiêu Sprint. Bằng cách theo dõi cơng việc cịn
lại trong suốt Sprint, Nhóm phát triển có thể quản lý tiến độ của nó.

xxiii

lOMoARcPSD|12114775

Hình 2.10 Bảng mẫu Sprint Backlog theo dạng Spreadsheet

2.7.3. Phần tăng trưởng
Kết quả của mỗi Sprint được gọi chính thức là Phần tăng trưởng Sản phẩm
Có khả năng Chuyển giao được (Potentially Shippable Product Increment). Trước
khi bắt đầu Sprint đầu tiên, Product Owner, Nhóm Phát triển và ScrumMaster cần
phải rà soát lại những thứ cần làm để biến một hạng mục Product Backlog trở
thành có thể chuyển giao được. Tất cả các hoạt động cần thiết để chuyển giao sản
phẩm cần được đưa vào trong định nghĩa của Có khả năng Chuyển giao được
(Potentially Shippable) và do đó cần phải được hoàn thành trong Sprint.
Trước Sprint đầu tiên, Product Owner và Nhóm Phát triển cần thống nhất một
Định nghĩa Hồn thành, nó là một tập con của các hoạt động cần thiết để tạo ra một
Phần tăng trưởng Sản phẩm Có khả năng Chuyển giao được (đối với một Nhóm tốt thì
hai tập này là giống nhau). Nhóm Phát triển sẽ lập kế hoạch công việc của Sprint dựa
theo Định nghĩa Hồn thành này. Một Product Owner tốt sẽ ln cố gắng để Định
nghĩa Hồn thành bám sát nhất có thể với Khả năng Chuyển giao được vì nó sẽ giúp
tăng tính minh bạch trong phát triển và giảm thiểu chậm trễ cũng như rủi ro. Nếu Định
nghĩa Hoàn thành khơng giống với Khả năng Chuyển giao được thì cơng việc sẽ bị trì
hỗn đến trước ngày phát hành gây ra rủi ro và chậm trễ. Công việc bị chậm trễ đơi khi
cịn được gọi là cơng việc chưa hồn thành (undone work).

xxiv