ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
Mở đầu
Khoa học và công nghệ là đặc trưng của thời đại, nghiên cứu khoa học đã trở thành
hoạt động sôi nổi và rộng khắp trên phạm vi toàn cầu. Đặc biệt trong lĩnh vực Công nghệ
Thông tin, khoa học và công nghệ đã trở thành động lực thúc đẩy mọi người coi đó là
nhân tố quan trọng để không ngừng nâng cao, tạo ra các phần mềm hỗ trợ trong cuộc
sống.
Trong quá trình phát triển phần mềm mới, mọi người phải trải qua cả một quy trình
ứng dụng các phương pháp khoa học để thực hiện một cách hiệu quả và sản phẩm làm ra
là tốt và tiết kiệm chi phí nhất. Tuy nhiên các quy trình phát triển phần mềm hiện nay như
Thác nước, Xoắn ốc,… còn gặp một số hạn chế.
Trong phạm vi bài thu hoạch nhỏ này, chúng em xin trình bày Quy trình phái triển
phần mềm Scrum, và các ưu điểm của nó so với các quy trình hiện có. Đồng thời, bài thu
hoạch sẽ trình bày các phương pháp khoa học được thể hiện khi áp dụng quy trình này
vào thực tế.
Qua đây, chúng em cũng xin được gửi lời cảm ơn đến Giáo sư - Tiến sỹ Khoa Học
Hoàng Văn Kiếm, người đã tận tâm truyền đạt những kiến thức nền tảng cơ bản cho
chúng em về môn học “Phương pháp nhiên cứu khoa học trong tin học”. Bên cạnh đó
cũng không thể không nhắc đến công lao trợ giúp của toàn thể các bạn bè học viên trong
lớp.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 1 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
MỤC LỤC
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 2 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
PHẦN I :
GIỚI THIỆU TỔNG QUÁT QUY TRÌNH SCRUM
I. Tổng quan về SCRUM
I.1. Scrum là gì
Scrum là một mô hình làm việc trong đó con người có thể xác định các vấn đề phức tạp
khi phát triển sản phẩm, trong khi đó vẫn giữ được năng suất và sự sáng tạo trong các sản

phẩm nhằm đem lại giá trị cao nhất.
Scrum là sự kết hợp:
• Gọn nhẹ
• Đơn giản và dễ hiểu
• Làm chủ được các khó khăn
Scrum là một trong các mô hình làm việc linh hoạt (agile framework) phổ biến nhất
hiện nay được dùng trong phát triển các sản phẩm phần mềm từ đơn giản đến phức tạp. Được
phát triển bởi Ken Schwaber và Jeff Sutherland từ đầu những năm 1990, Scrum đã dần dần
trở thành phương pháp làm việc và quản lí “tiêu chuẩn” của những người thực hành phát
triển phần mềm linh hoạt (agile software development).
I.2. Mô hình làm việc Scrum
Mô hình Scrum bao gồm nhóm Scrum và các vai trò liên quan, sự kiện, công cụ, và các
quy tắc. Mỗi thành phần trong mô hình đều phục vụ một mục đích cụ thể và cần thiết cho sự
thành công của Scrum.
Các quy tắc Scrum liên kết các sự kiện, vai trò và công cụ với nhau, điều khiển mối
quan hệ và tương tác giữa chúng.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 3 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
II. Lý thuyết Scrum
Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical
process control), hay “lý thuyết thực nghiệm” (empiricism). Lý thuyết này chỉ ra rằng tri thức
đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Scrum sử dụng các
tiếp cận lặp (iterative), tăng dần (incremental) để tối ưu hóa tính dự đoán (predictability) và
kiểm soát rủi ro.
Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: tính
minh bạch (transparency), sự thanh tra (inspection) và sự thích nghi (adaptation).
II.1. Minh bạch (Transparency)
Trong Scrum, tính minh bạch được đề cao như là giá trị cốt lõi cơ bản nhất. Muốn
thành công với Scrum, thông tin liên quan tới quá 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 và rào cản v.v. Từ đó mọi người ở các vai trò các nhau có đủ thông
tin cần thiết để tiến hành các quyết định có giá trị để 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.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 4 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
II.2. 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 dự á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.
II.3. Thích nghi (Adaption)
Scrum rất linh hoạt như các phương pháp phát triển linh hoạt (agile software
development) khác. Nhờ đó nó mang lại tính thích nghi rất cao. Dựa trên các thông tin minh
bạch hóa từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi một
cách tích cực, nhờ đó mang lại thành công cho dự án.
Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho
phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình
hoặc các vấn đề được xử lý phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng
sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra.
Scrum thực hiện tính thanh tra và thích nghi trong các Sự kiện Scrum, bao gồm:
• Buổi Họp Kế hoạch Sprint (Sprint Planning Meeting)
• Họp Scrum hằng ngày (Daily Scrum)
• Sơ kết Sprint (Sprint Review)
• Cải tiến Sprint (Sprint Retrospective)
III. Các vai trò trong Scrum
Trong Scrum, nhóm tham gia phát triển phần mềm được phân chia ra ba vai trò với trách
nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm: Product
Owner (chủ sản phẩm), Scrum Master (quản lý chu trình Scrum) và Development Team
(Đội sản xuất hay Nhóm Phát triển). Các nhóm tự chọn cách thức tốt nhất để hoàn thành
công việc của họ, chứ không bị chỉ đạo bởi ai đó bên ngoài nhóm. Các nhóm liên chức năng

có đủ kĩ năng cần thiết để hoàn thành công việc mà không phụ thuộc vào bất kì người ngoài
nào khác. Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa sự linh hoạt, sáng tạo và
năng suất.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 5 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
Các Nhóm Scrum chuyển giao sản phẩm theo phân đoạn lặp đi lặp lại và tăng dần, tối đa
hóa cơ hội cho các phản hồi. Việc chuyển giao tăng dần (incremental) các gói sản phẩm đạt
tiêu chuẩn “Hoàn thành” đảm bảo một phiên bản khả dụng của sản phẩm luôn luôn sẵn sàng
để cung cấp tới chủ sản phẩm.
III.1. Chủ sản phẩm (Product Owner)
Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu
và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm.
Product Owner là một người chủ yếu chịu trách nhiệm về việc quản lý Product
Backlog (Yêu cầu, tính năng lớn của một sản phẩm). Đây là công cụ quản lý chứa:
• Mô tả các hạng mục Product backlog.
• Trình tự của các hạng mục trong Product Backlog để đạt được mục đích và hoàn
thành các nhiệm vụ.
• Sự đảm bảo giá trị của các công việc của Nhóm Phát triển.
• Sự đảm bảo cho Product Backlog là luôn luôn hiện hữu, thông suốt, và rõ ràng
tới tất cả mọi người, và chỉ ra những gì mà Nhóm Scrum sẽ làm việc.
• Sự đảm bảo cho Nhóm Phát triển hiểu rõ các hạng mục trong Product Backlog
với các mức độ cần thiết.
Product Owner có thể thực hiện công việc trên, hoặc để Nhóm Phát triển làm. Tuy
nhiên, Product Owner vẫn phải chịu trách nhiệm chính.
Để Product Owner thành công, cả tổ chức phải tôn trọng các quyết định của người
này. Các quyết định đó được hiển thị trong nội dung và thứ tự trong Product Backlog. Không
ai ngoài Product Owner được phép yêu cầu Nhóm Phát triển làm gì khác, và Nhóm Phát triển
cũng không được phép làm gì theo lời bất cứ người nào khác.
III.2. Đội sản xuất – Nhóm phát triển (Development Team)
Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các

yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 6 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
Nhóm Phát triển (Development Team) gồm các chuyên gia làm việc để cho ra các
phần tăng trưởng có thể phát hành được (potentially releasable) cuối mỗi Sprint. Chỉ các
thành viên của Nhóm Phát triển mới tạo ra các phần tăng trưởng này (Increment).
Nhóm Phát triển được cấu trúc và trao quyền để tổ chức và quản lý công việc của họ.
Sự hợp lực sẽ tối ưu hóa nỗ lực và hiệu quả tổng thể của Nhóm Phát triển. Nhóm Phát triển
có các đặc trưng sau:
• Đó là nhóm tự tổ chức. Không ai (kể cả Scrum Master) có quyền yêu cầu
Nhóm Phát triển làm sao để chuyển Product Backlog thành các phần tăng
trưởng có thể chuyển giao được.
• Đó là nhóm liên chức năng, với tất cả các kĩ năng cần thiết để tạo ra phần tăng
trưởng của sản phẩm.
• Scrum không ghi nhận một chức danh nào trong Nhóm Phát triển ngoài Nhà
phát triển (Developer), theo tính chất công việc của người này; không có ngoại
lệ cho quy tắc này.
• Các thành viên Nhóm phát triển có thể có các kĩ năng chuyên biệt và các
chuyên môn đặc thù, nhưng họ phải chịu trách nhiệm dưới một thể thống nhất
là Nhóm Phát triển.
• Nhóm Phát triển không chứa các nhóm con nào khác với các chức năng đặc thù
như ‘nhóm kiểm thử’ hay ‘phân tích nghiệp vụ’.
Độ lớn tối ưu của Nhóm Phát triển là đủ nhỏ để giữ được sự linh hoạt và đủ lớn để
hoàn thành công việc. Ít hơn ba người có thể làm giảm sự tương tác và dẫn đến năng suất
thấp. Các Nhóm Phát triển nhỏ hơn có thể phải đối mặt với các ràng buộc kĩ năng trong suốt
Sprint, dẫn đến Nhóm Phát triển khó có thể chuyển giao gói tăng trưởng phát hành được.
Một nhóm nhiều hơn chín người cần nhiều sự điều phối hơn. Các Nhóm Phát triển lớn phát
sinh quá nhiều phức tạp để thực hiện việc kiểm soát tiến trình thực nghiệm. Các vai trò
Product Owner và Scrum Master không được tính vào kích thước của Nhóm Phát triển, trừ
khi họ cũng kiêm luôn vai trò là thành viên của Nhóm Phát triển.

MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 7 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
III.3. Quản lý chu trình Scrum (Scrum Master)
Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả
với Scrum.
Scrum Master chịu trách nhiệm đảm bảo mọi người hiểu và dùng được Scrum. Scrum
Master thực hiện việc này bằng cách đảm bảo Nhóm Scrum tuân thủ lý thuyết, thực tiễn và
các quy tắc của Scrum. Scrum Master là một lãnh đạo, nhưng cũng là đầy tớ của Nhóm
Scrum.
Scrum Master giúp đỡ những người ngoài Nhóm Scrum hiểu cách phải tương tác với
Nhóm sao cho hiệu quả nhất. Scrum Master giúp đỡ tất cả mọi người thay đổi các mối tương
tác này để tối đa hóa giá trị mà Nhóm Scrum tạo ra.
IV. Các sự kiện trong Scrum
IV.1. Sprint là gì
Trái tim của Scrum chính là Sprint, một khung-thời-gian (time-box) có thời gian một
tháng hoặc ngắn hơn để tạo ra các phần tăng trưởng của sản phẩm có thể phát hành được.
Sprint có khoảng thời gian nhất quán trong suốt quá trình phát triển. Một Sprint mới bắt đầu
ngay khi Sprint trước khép lại.
Trong suốt Sprint:
• Không cho phép bất kì sự thay đổi nào ảnh hưởng đến Mục tiêu Sprint (Sprint
Goal).
• Thành phần Nhóm Phát triển được giữ nguyên.
• Mục tiêu chất lượng không được cắt giảm.
Phạm vi có thể được làm rõ và tái thương lượng giữa Product Owner và Nhóm Phát
triển.
Mỗi Sprint có thể được coi như một tiểu dự án với độ dài một tháng. Giống như dự
án, Sprint được dùng để hoàn tất điều gì đó. Mỗi Sprint có một định nghĩa về việc phải xây
dựng cái gì, một bản thiết kế và bản kế hoạch linh hoạt sẽ hướng dẫn quá trình xây dựng đó,
các công việc cần làm, và sản phẩm của quá trình đó.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 8 -

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
IV.2. Họp kế hoạch Sprint (Sprint Planning Meeting)
Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint.
Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và
nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các
tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó,
việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi
lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.
IV.3. Họp Scrum hằng ngày (Daily Scrum)
Cuộc họp Scrum Hằng (Daily Scrum) ngày được đóng khung trong 15 phút để Nhóm
Phát triển đồng bộ hóa các hoạt động của thành viên và tạo lập kế hoạch cho 24 giờ tiếp theo.
Điều này có được nhờ việc thanh tra các công việc kể từ cuộc họp Scrum Hằng ngày trước,
và dự báo những công việc sẽ được hoàn thành trước buổi họp lần sau.
Cuộc họp Scrum Hằng ngày được tổ chức tại cùng một địa điểm để giảm thiểu sự
phức tạp không cần thiết. Trong suốt cuộc họp, mỗi thành viên Nhóm Phát triển giải thích rõ:
• Việc gì đã được thực hiện kể từ lần họp trước?
• Việc gì sẽ được hoàn thành trước buổi họp lần sau? Có vấn đề gì nảy sinh trong
quá trình làm việc?
Nhóm Phát triển sử dụng cuộc họp Scrum Hằng ngày để đánh giá tiến độ công việc
hướng tới Mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint
Backlog. Cuộc họp Scrum Hằng ngày tối ưu hóa khả năng để Nhóm Phát triển có thể đạt
được Mục tiêu Sprint.
IV.4. Họp sơ kết Sprint (Sprint Review)
Buổi Sơ kết Sprint (Sprint Review) được tổ chức khi Sprint kết thúc để rà soát lại
phần tăng trưởng vừa làm ra trong Sprint đó, và để thực hiện các biện pháp thích nghi nếu
cần. Trong cuộc họp này, Nhóm Scrum và các bên hữu quan sẽ trao đổi với nhau về những gì
vừa hoàn thành trong Sprint vừa rồi. Trên cơ sở đó và những sự thay đổi trong Product
Backlog trong suốt Sprint, người tham dự cuộc họp sẽ hợp tác để thảo luận về những công
việc sắp triển khai. Đây là cuộc họp không trang trọng, và việc trình bày về gói tăng trưởng
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 9 -

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
chủ yếu nhằm mục đích cung cấp các phản hồi hữu ích và khuyến khích sự cộng tác giữa các
bên.
Buổi Sơ kết Sprint có một số đặc điểm sau:
• Product Owner nhận biết phần nào là “Hoàn thành” và phần nào chưa “Hoàn
thành”.
• Nhóm Phát triển thảo luận những điều thuận lợi trong Sprint vừa qua, những
khó khăn mà nhóm đã trải qua, và cách thức giải quyết các vấn đề đó.
• Nhóm Phát triển trình diễn các phần việc đã “Hoàn thành” và trả lời các câu hỏi
của cử tọa về gói tăng trưởng.
• Product Owner trao đổi về Product Backlog. Dựa trên tiến độ hiện thời, Product
Owner đưa ra dự đoán ngày hoàn thành dự án.
• Toàn bộ nhóm thảo luận về những gì sẽ làm, nhờ đó buổi Sơ kết Sprint cung cấp
các giá trị đầu vào cho buổi Họp Kế hoạch Sprint tiếp theo.
IV.5. Họp cải tiến Sprint (Sprint Retrospective)
Buổi họp Cải tiến Sprint (Sprint Retrospective) là cơ hội để Nhóm Scrum tự thanh tra
và đưa ra kế hoạch cho các cải tiến trong Sprint tiếp theo.
Buổi họp Cải tiến Sprint được tổ chức ngay sau Sơ kết Sprint và trước khi cuộc Họp
Kế hoạch Sprint tiếp theo diễn ra. Cuộc họp này được đóng khung trong phạm vi ba giờ cho
các Sprint một tháng. Sprint ngắn hơn thì cuộc họp sẽ được rút ngắn lại cho phù hợp.
Mục đích của cuộc họp Cải tiến Sprint là để:
• Thanh tra lại tất cả các yếu tố trong Sprint vừa diễn ra, từ con người, các mối
quan hệ, quy trình, và công cụ.
• Nhận biết và xếp đặt lại các hạng mục chủ chốt đã được thực hiện tốt, và các cải
tiến dự định.
• Tạo ra một kế hoạch để triển khai các cải tiến cách thức làm việc của Nhóm
Scrum.
Scrum Master động viên Nhóm Scrum để cải tiến, trong phạm vi khung làm việc
Scrum, quy trình phát triển và các biện pháp thực hành để nâng cao hiệu quả và thú vị cho
Sprint tiếp theo. Trong cuộc họp Cải tiến Sprint, Nhóm Scrum sẽ lập kế hoạch để gia tăng

chất lượng sản phẩm bằng việc định nghĩa lại Định nghĩa “Hoàn thành” khi cần thiết.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 10 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
V. Các công cụ trong Scrum
Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc. Chúng
bao gồm bản yêu cầu của chủ sản phẩm được gọi là Product backlog, bản kế hoạch của từng
Sprint (Sprint Backlog) và biểu đồ Burndown Chart.
V.1. Product backlog
Product Backlog là một danh sách sắp thứ tự tất cả những gì cần thiết của sản phẩm.
Nó là nguồn yêu cầu duy nhất thể hiện các thay đổi trong sản phẩm. Product Owner là người
chịu trách nhiệm về Product Backlog, nội dung của nó, sự hiện diện, và thứ tự các hạng mục
trong đó.
Product Backlog liệt kê tất cả các tính năng (feature), chức năng, yêu cầu, cải thiện,
vá lỗi cần thiết để làm nên sản phẩm trong tương lai. Các hạng mục trong Product Backlog
được mô tả với các thuộc tính như: mô tả, thứ tự, và ước lượng.
Product Backlog thường được sắp xếp theo các giá trị, độ rủi ro, độ ưu tiên, và sự cần
thiết. Các hạng mục đứng đầu danh sách sẽ trực tiếp điều khiển các hoạt động phát triển.
Càng ở thứ tự cao hơn, các hạng mục càng được quan tâm nhiều hơn, và được tập trung nỗ
lực nhiều hơn vì chính giá trị của chúng.
V.2. Sprint backlog
Sprint Backlog là tập hợp các hạng mục Product Backlog được lựa chọn để phát triển
trong Sprint, kèm theo một kế hoạch để chuyển giao phần tăng trưởng của sản phẩm và hiện
thực hóa Mục tiêu Sprint. Sprint Backlog là một bản dự báo của Nhóm Phát triển về những
chức năng sẽ có trong phần tăng trưởng sẽ được chuyển giao.
Sprint Backlog xác định công việc mà Nhóm Phát triển phải làm để biến các hạng
mục Product Backlog thành phần tăng trưởng đạt tiêu chuẩn “Hoàn thành”. Sprint Backlog
cho thấy tất cả những việc Nhóm Phát triển cần phải làm để tiến tới Mục tiêu Sprint.
Sprint Backlog là một kế hoạch với chi tiết vừa đủ để những thay đổi về tiến độ công
việc có thể nhìn thấy được trong các cuộc họp Scrum Hằng ngày. Nhóm Phát triển chỉnh sửa
Sprint Backlog trong suốt Sprint, và Sprint Backlog sẽ được cập nhật trong suốt thời gian đó.

MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 11 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
Sự cập nhật này xảy ra khi Nhóm Phát triển làm việc theo kế hoạch của họ, và hiểu rõ hơn về
các công việc cần thiết để đạt Mục tiêu Sprint.
Mỗi khi có thêm việc mới, Nhóm Phát triển đưa vào Sprint Backlog. Khi công việc
bắt đầu hay kết thúc, giá trị ước lượng về thời gian còn lại để hoàn tất công việc được cập
nhật. Khi có phần nào đó của kế hoạch là không cần thiết, chúng sẽ bị bỏ đi. Chỉ có Nhóm
Phát triển mới có thể thay đổi Sprint Backlog trong Sprint. Sprint Backlog là một bức tranh
thời gian thực về công việc mà Nhóm Phát triển lên kế hoạch để hoàn thành trong Sprint, và
nó cơ bản thuộc về Nhóm Phát triển.
V.3. Burndown Chart
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại
để hoàn tất công việc. Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint
(được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart). Biểu đồ
burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn
được sử dụng rộng rãi do tính hữu ích của nó.
VI. Định nghĩa thế nào là “Hoàn thành” (Done)
Định nghĩa “Hoàn thành” cho các Product Backlog là các tiêu chí mô tả và kiểm tra
đánh giá xem tính năng đã làm có đúng với yêu cầu đặt ra trong Product Backlog hay không.
Mọi thành viên trong Scrum đều phải hiểu rõ các tiêu chí, mô tả và đánh giá để đảm bảo làm
đúng tính năng và tính minh bạch trong Scrum.
Đồng thời, dựa trên định nghĩa “Hoàn thành”, đội phát triển có thể biết được bao nhiêu
Product Backlog đã hoàn thành và lựa chọn các Product Backlog phù hợp để thực hiện trong
Sprint kế tiếp.
Trong quá trình thực hiện, định nghĩa “Hoàn thành” có thể thay đổi với các tiêu chí
nghiêm ngặt hơn nhằm tăng chất lượng sản phẩm cao hơn.
VII. Các thức vận hành Scrum
Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục
được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu
của Product Owner với sự lặp đi lặp lại các giai đoạn nước rút từ 1 đến 4 tuần làm việc (gọi

MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 12 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm
hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment). Trước khi cả
nhóm cùng đua nước rút trong Sprint, đội sản xuất cùng họp với Product Owner để lập kế
hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint
Backlog chứa các công việc cần làm trong suốt một Sprint. Trong suốt quá trình phát triển,
nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum)
để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau.
Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công
việc trong Sprint. Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn
chỉnh, sẵn sàng chuyển giao (shippable) cho khác hàng. Buổi họp Sơ kết Sprint (Sprint
Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì,
còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến. Sau khi kết thúc việc đánh giá
Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) để
tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học
hỏi và trưởng thành qua từng Sprint.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 13 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog
đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình
thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều
giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang lại giá trị cao
nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường
có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.
PHẦN II : CÁC NGUYÊN TẮC SÁNG TẠO TRONG MÔ
HÌNH PHÁT TRIỂN PHẦN MỀM SCRUM
I. Nguyên tắc phân nhỏ
Scrum thực hiện phân nhỏ các hạng mục lớn thành các yêu cầu nhỏ, quá trình phát triển
sản phẩm thành các giai đoạn phát triển nhỏ hơn (Sprint) và các công việc trong từng giai

đoạn phát triển.
Người chủ sản phẩm (Product Owner) sẽ tiến hành tiếp nhận yêu cầu từ khách hàng và
tiến hành phân rã thành các tính năng, hạng mục. Các hạng mục này được sắp xếp và phân rã
theo thứ tự ưu tiên nhằm giúp quá trình phát triển sản phầm hiệu quả nhất, tránh được các rủi
ro và giảm thiểu lãng phí.
Dựa trên hạng mục được phân rã, quá trình phát triển sản phẩm của Scrum sẽ được
phân nhỏ thành các giai đoạn phát triển (Sprint). Việc phân nhỏ công việc thành các Sprint
nhằm thục hiện một cách ưu tiên các danh mục, các yêu cầu giá trị hơn cho khách hàng.
Ngoài ra, qua mỗi Sprint, khách hàng cũng sẽ từng bước thấy được sản phẩm.
Trong mỗi Sprint làm việc, Nhóm Phát triển tiếp tục phân nhỏ các hạng mục thành từng
công việc cụ thể cho từng thành viên phát triển.
Sự phân nhỏ trong Scrum giúp ta thấy được thành viên nào phát triển tính năng nào,
những tính năng này thuộc Sprint nào, Sprint này sẽ hoàn thành được các hạng mục nào và
sản phẩm sẽ ra sao.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 14 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
II. Nguyên tắc tách khỏi
Scrum loại bỏ các hạng mục, yêu cầu không phù hợp hoặc ảnh hướng lớn đến chất
lượng của sản phẩm.
Việc phát triển phần mềm luôn đi kèm với nhiều yếu tố không chắc chắn dẫn đến nhiều
sự thay đổi. Các yêu cầu từ khách hàng đưa ra từ ban đầu chưa thể kiểm định được rằng nó
có cần thiết cho sản phẩm hay không. Vì vậy, Scrum vận hành theo quá trình lặp lại các
Sprint giúp khách hàng có sự trải nghiệm rõ ràng về sản phẩm của mình. Qua sự trải nghiệm
sản phẩm ở cuối mỗi Sprint, khách sẽ xem xét lại yêu cầu đưa ra từ ban đầu và từ đó sẽ loại
bỏ các yêu cầu vốn không ổn định hoặc không cần thiết nhằm giúp giảm thiểu lãng phí.
III. Nguyên tắc thực hiện sơ bộ
Scrum sử dụng chiến thuật “có giá trị hơn làm trước”, tổ chức sắp xếp phát triển sản
phẩm theo các hạng mục một cách thích hợp nhất.
Ngay từ đầu các danh sách các hạng mục yêu cầu được sắp xếp theo một thứ tự ưu tiên
từ trước. Thứ tự này sẽ dựa trên các hạng mục nào có giá nhiều hơn hoặc đóng vai trò cốt lỗi

sẽ ưu tiên thực hiện trước. Các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được
hoàn tất trước và sẽ là tiền đề để phát triển các hạng mục tiếp theo.
Việc sắp xếp theo thứ tự này nhằm tạo ra một quá trình phát triển thích hợp nhất tránh
sự lãng phí thời gian khi có thay đổi. Do đó Scrum luôn luôn mang lại giá trị cao nhất cho
người đầu tư cho dự án. Đồng thời quy trình luôn luôn được cải tiến để nhóm Scrum thường
có năng suất lao động rất cao.
IV. Nguyên tắc dự phòng
Scrum dự đoán trước các yếu tố xấu sau mỗi Sprint làm việc và đưa ra các phương
pháp dự phòng các yếu tố này cho Sprint tiếp theo.
Trong quá trình phát triển phần mềm luôn gặp phải các yếu tố xấu ảnh hướng chất
lượng của sản phẩm. Các yếu tố xấu này không phải lúc nào cũng được thấy trước trong các
mô tả ban đầu. Trong mô hình Scrum, sau mỗi Sprint, đội phát triển cùng nhau xem xét lại
tính năng vừa hoàn thành. Theo đó, đội sẽ phát hiện các vấn đề hay yếu tố ảnh hưởng đến
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 15 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
tính năng của Sprint sau. Thông qua việc dự đoán này, đội sẽ đưa ra các phương pháp hay
thay đổi về tính để dự phòng trước các yếu tố sẽ ảnh hưởng và gây lỗi chương trình.
Việc vận hành theo Sprint giúp phát triển phần mềm qua từng bước, đồng thời cũng hạn
chế được nhiều vấn đề gặp phải khi sản phẩm đã được phát triển hoàn chỉnh.
V. Nguyên tắc cầu (tròn) hoá
Scrum vận hành thông qua việc lặp lại các Sprint theo một chu trình vòng tròn không
đổi.
Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog
đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình
thực tế. Quá trình lặp lại này theo một chu trình từ lên kế hoạch đến thực hiện sprint và cuối
cùng họp sơ kết và họp cải tiến trong một khoảng thời gian không đổi.
Việc vận hành theo một chu trình vòng tròn không đổi nhằm tạo ra một không gian làm
việc không đổi giúp cho các thành viên tham gia tuân theo và cố gắng thực hiện đúng tiến độ
của dự án.
VI. Nguyên tắc linh động

Scrum là phương pháp phát triển linh hoạt, luôn mang lại sự linh động và tính thích
nghi cao trong các trường hợp phức tạp.
Một trong ba yếu tố cốt lõi của Scrum chính là tính thích nghi. Dựa trên các thông tin
minh bạch hóa từ các quá trình thanh tra và làm việc, ta xác định được rằng có vấn đề nào đó
vượt quá giới hạn cho phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp
nhận được, thì quy trình hoặc các vấn đề được xử lý phải được điều chỉnh. Sự điều chỉnh
phải được tiến hành càng sớm càng tốt để linh hoạt giảm thiểu các sai sót.
Tính thích nghi là một trong những yếu tố góp phần giúp Scrum thực hiện một cách
thành công.
VII. Nguyên tắc tác động thiếu hoặc thừa
Scrum giúp loại bỏ các yêu cầu không cần thiết và bổ sung các tính năng tăng tính
hiệu dụng và tiện lợi của sản phẩm.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 16 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
Người dùng, khách hàng đưa ra các yêu cầu dựa trên kiến thức của họ, việc này
thường dẫn đến các yêu cầu đưa ra không hợp với thực tế. Đồng thời, trong quá trình phát
triển sản phẩm nhóm phát triển hay chủ sản phẩm (Product Owner) có thể thấy được một số
tính năng sẽ mang lại sự hiệu quả và tiện dụng hơn cho sản phẩm.
Dựa vào các những thực tế trên Scrum sẽ lọc bỏ các yêu cầu thừa không cần thiết và
bổ sung thêm các yêu cầu để tăng tính hiệu quả và tiện dụng hơn.
VIII. Nguyên tắc chuyển sang chiều hướng khác
Scrum giúp quá trình phát triển chuyển hướng đúng lúc khi các thiết kế và phương
pháp ban đầu sai hay không giải quyết được vấn đề.
Khởi đầu mọi dự án hay Sprint, nhóm sẽ tiến hành phân tích các hạng mục yêu cầu,
quyết định công nghệ hay giải pháp để xây dựng sản phẩm. Nhưng không phải lúc nào, giải
pháp được chọn là đúng. Sau quá trình xây dựng ở mỗi Sprint, nhóm sẽ xem xét và đưa ra
quyết định thay đổi công nghệ hay giải pháp kịp thời. Việc này có thể hạn chế được lãng phí
về thời gian khi phải thay đổi, đồng thời cũng tránh được việc hủy dự án.
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 17 -
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

Tài liệu tham khảo
[1].Bài giảng môn học “Phương pháp nhiên cứu khoa học trong tin học”, GS.TSKH
Hoàng Kiếm, Đại học CNTT ĐH Quốc gia TP.HCM - 2005.
[2].Giải một bài toán trên máy tính như thế nào?(tập 1, 2, 3), GS.TSKH Hoàng Kiếm,
Nhà xuất bản giáo dục – 2003.
[3].Phương pháp luận sáng tạo khoa học – kỹ thuật, GSTS. Phan Dũng, Trung tâm sáng
tạo khoa học – kỹ thuật, Trường Đại Học Khoa Học Tự Nhiên TP.HCM – 2002.
[4].Scrum Guide, Ken Schwaber và Jeff Sutherland, Scrum.org 10 – 2011.
[5].
[6].
[7].
MÔN HỌC: PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC - 18 -