Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
CHƯƠNG TRÌNH ĐÀO TẠO THẠC SĨ CÔNG NGHỆ THÔNG TIN QUA MẠNG
o0o
BÁO CÁO THU HOẠCH MÔN HỌC
PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC
Đề tài:
Áp dụng những nguyên lý sáng tạo trong xây dựng phần
mềm theo phương pháp SCRUM
Giảng viên hướng dẫn: GS.TSKH Hoàng Văn Kiếm
Học viên thực hiện: Trần Bá Dược
Mã số học viên: CH1201098
TP. HCM, năm 2013
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Mục lục
Lời nói đầu 2
Lời nói đầu 2
PHẦN I 3
GIỚI THIỆU MỘT SỐ MÔ HÌNH TRONG XÂY DỰNG PHẦN MỀM 3
I.1. MÔ HÌNH XÂY DỰNG VÀ HIỆU CHỈNH (BUILD AND FIX MODEL) 3
I.2. MÔ HÌNH THÁC ĐỔ (WATERFALL MODEL) 4
I.3. MÔ HÌNH BẢN MẪU (RAPID PROTOTYPING MODEL) 6
I.4. MÔ HÌNH TĂNG DẦN (INCREMENTAL MODEL) 8
I.5. MÔ HÌNH TĂNG DẦN ĐỒNG THỜI (CONCURRENT INCREMENTAL MODEL)
10
I.6. MÔ HÌNH ĐỒNG BỘ VÀ ỔN ĐỊNH (SYNCHRONIZE AND STABILIZE MODEL)
12
I.7. MÔ HÌNH XOẮN ỐC (SPIRAL MODEL) 12
I.8. MÔ HÌNH HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL) 16
PHẦN II 18
PHƯƠNG PHÁP SCRUM TRONG XÂY DỰNG PHẦN MỀM 18

1. Khái niệm về SCRUM : 18
2. Quy trình thực hiện SCRUM : 19
PHẦN III 26
ÁP DỤNG NHỮNG NGUYÊN LÝ SÁNG TẠO TRONG SCRUM 26
Nguyên tắc phân nhỏ: 26
Nguyên tắc linh động: 26
Nguyên tắc thực hiện sơ bộ: 26
Nguyên tắc tác động theo chu kỳ: 27
Nguyên tắc quan hệ phản hồi: 27
Nguyên tắc vạn năng: 27
. Nguyên tắc tách khỏi: 27
PHẦN IV 28
TÀI LIỆU THAM KHẢO 28
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 1
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Lời nói đầu
Khoa học kỹ thuật giữ một vai trò đặc biệt quan trọng trong cuộc sống hiện nay
của mỗi chúng ta. Nhờ khoa học kỹ thuật mà con người tạo ra nhiều của cải vật chất,
sản phẩm,…phục vụ cho cuộc sống của mình ngày càng tốt hơn; giúp con người khám
phá nhiều quy luật vận động của thế giới xung quanh mình, từng bước điều khiển được
sự vận động của tự nhiên. Chính vì thế, việc nghiên cứu, tìm tòi, sáng tạo ra những giá
trị mới đã trở thành một việc làm cấp thiết của mỗi người chúng ta, nhằm góp một
phần tri thức của mình cho tri thức chung của nhân loại, góp phần cải tạo thế giới.
Trải qua một thời gian học tập và nghiên cứu môn Phương pháp Nghiên cứu
khoa học và tư duy sáng tạo, với sự hướng dẫn tận tình của Thầy GS.TSKH Hoàng
Văn Kiếm, tôi đã hiểu sâu hơn về phương pháp nghiên cứu, tìm tòi, phát hiện vấn đề
mới trong lĩnh vực khoa học máy tính.
Tôi tin rằng, với những kiến thức mà Thầy đã truyền đạt, sẽ giúp ích rất nhiều
cho việc học tập và nghiên cứu của tôi sau này.
Tôi chân thành cảm ơn Thầy GS.TSKH Hoàng Văn Kiếm. Kính chúc Thầy và

gia đình luôn dồi dào sức khỏe.

Học viên
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 2
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
PHẦN I
GIỚI THIỆU MỘT SỐ MÔ HÌNH TRONG XÂY DỰNG
PHẦN MỀM
I.1. Mô hình xây dựng và hiệu chỉnh (Build and fix model)
Có khá nhiều phần mềm (software) đã được xây dựng dựa trên mô hình xây
dựng và hiệu chỉnh. Trong mô hình này không có các pha phân tích thiết kế. Phần mềm
được xây dựng như sau: người phát triển sau khi trao đổi với khách hàng sẽ viết phiên
bản (version) đầu tiên. Tiếp theo, phần mềm được chạy thử với sự quan sát của khách
hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý (tức là đáp ứng được
yêu cầu của khách hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa
vào sử dụng và bảo trì. Mô hình này có thể biểu diễn trong sơ đồ sau:
Hình 1. Mô hình xây dựng và hiệu chỉnh
Cách thức này được nhiều người sử dụng để làm phần mềm, nhất là các phần
mềm nhỏ. Nếu nói chính xác hơn thì mô hình trên đây không có tài liệu phân tích, thiết
kế. Vì thực ra khi viết chương trình thì người phát triển cũng phải hình dung ra các
chức năng của phần mềm, những module phải có, những thuật toán sử dụng Nghĩa là
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 3
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
phần nào đó họ cũng có phân tích thiết kế, nhưng họ không biên soạn lại thành tài liệu
mà thôi. Nếu phần mềm do một người viết và dễ dàng trao đổi với khách hàng thì có lẽ
mô hình xây dựng và hiệu chỉnh là cách nhanh nhất để đi tới sản phẩm. Sau khi viết
phiên bản đầu tiên, người phát triển đã hiểu khá rõ yêu cầu của khách hàng, họ cũng
hiểu rõ các dòng lệnh vừa viết. Vì vậy khi khách hàng nêu yêu cầu hiệu chỉnh phần
mềm thì họ biết ngay cần phải hiệu chỉnh phần nào của chương trình. Công việc
thường được thực hiện khá nhanh chóng và phần mềm sớm được hoàn thành và đưa

vào sử dụng.
Về hình thức, cách làm phần mềm theo kiểu xây dựng và hiệu chỉnh cũng giống
như làm bản mẫu. Tuy nhiên có một sự khác biệt, là khi làm bản mẫu ta bỏ qua các yếu
tố quan trọng khác mà chỉ tập trung mô tả các yêu cầu của khách hàng; còn trong mô
hình xây dựng và hiệu chỉnh thì ta chú ý tới cả các đặc trưng này khi xây dựng phần
mềm.
Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì
thường là sửa lỗi và cập nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả
vẫn còn chịu trách nhiệm công việc này thì không có vấn đề gì lắm. Tuy nhiên nếu
phần mềm đã được sử dụng sau một thời gian dài, khiến cho chính người viết chương
trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người khác thực
hiện thì sẽ rất khó khăn. Nếu bạn thử đọc chương trình nguồn của một tác giả khác mà
không có tài liệu giải thích kèm theo thì bạn sẽ thấy rất khó hiểu. Đôi khi bạn tìm hiểu
vấn đề rồi viết mới chương trình có lẽ còn đơn giản hơn là sửa lại chương trình của
người khác.
Mô hình xây dựng và hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người
viết và ít khả năng phải sửa đổi trong quá trình sử dụng. Ngày nay các phần mềm
thường lớn, do nhiều người viết do đó cách thức này trở nên không thích hợp. Khi có
nhu cầu làm phần mềm, ta cần lựa chọn mô hình vòng đời thích hợp (đôi khi ta nói đơn
giản là mô hình). Mô hình này phải được cả nhóm làm phần mềm nhất trí, sau đó công
việc phát triển phần mềm mới thực sự được bắt đầu.
I.2. Mô hình thác đổ (Waterfall model)
Vào năm 1970, mô hình thác đổ được đưa ra lần đầu tiên bởi W.W. Royce.
Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải
qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì. Thực ra, Royce có
mô tả tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó
sai sót hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước.
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 4
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM

Hình 2. Mô hình thác đổ (waterfall model)
Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công
nghệ phần mềm. Tuy nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có
một số nhược điểm như sau:
• Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề
nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là
những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc.
• Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ đầu.
Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự
không chắc chắn tự nhiên tồn tại vào lúc đầu của nhiều dự án. Khách hàng phải
kiên nhẫn chờ đợi, vì bản làm việc được của chương trình chỉ có được vào cuối
của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến lúc có chương trình làm việc
mới phát hiện ra, có thể là một thảm họa.
• Có thể xảy ra các trạng thái tắc nghẽn trong quá trình thực hiện dự án phần mềm,
nghĩa là có một số thành viên của nhóm phát triển phải chờ đợi sự chuyển giao từ
nhóm khác hoàn thành công việc ở pha trước. Trong thực tế, thời gian chờ đợi có
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 5
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
thể vượt quá thời gian sản xuất. Trạng thái nghẽn có xu hướng xẩy ra vào thời
gian đầu và cuối của quy trình phần mềm.
Tuy nhiên, mô hình vòng đời cổ điển có một vị trí quan trọng vì nó đưa ra một
hình mẫu về các bước mà một phần mềm cần phải trải qua là: phân tích hệ thống, thiết
kế, cài đặt, tích hợp và bảo trì. Nhiều mô hình sau này là cải tiến mô hình này, nhưng
vẫn giữ lại những điểm cốt lõi.
I.3. Mô hình bản mẫu (Rapid prototyping model)
Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu
cầu được thay bằng bản mẫu. Mô hình này có thể biểu diễn bởi sơ đồ sau:


GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 6

Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Hình 3. Mô hình bản mẫu (rapid prototyping model)
Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra
(verify), các pha cài đặt và tích hợp có kiểm thử (test).
Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho
phần mềm, nhưng còn chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý.
Trong các trường hợp khác người phát triển có thể không chắc về tính hiệu quả của
thuật toán, việc thích nghi hệ điều hành hay dạng màn hình giao diện cần có. Trong
trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa ra cách tiếp
cận tốt nhất.
Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng. Người phát
triển và khách hàng cùng ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần
mềm, xác định xem yêu cầu nào đã rõ ràng, yêu cầu nào còn phải xác định thêm. Tiếp
theo là việc "thiết kế nhanh". Thiết kế nhanh chỉ tập trung vào việc biểu diễn các khía
cạnh của phần mềm thấy được đối với người dùng, ví dụ như là màn hình nhập dữ liệu,
các chức năng tìm kiếm, truy xuất thông tin, các báo cáo. Người phát triển có thể kết
hợp để thử nghiệm một thuật toán. Tuy nhiên mục đích chính là thể hiện được các yêu
cầu của khách hàng trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự hợp lý
Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được giới thiệu với khách
hàng và có thể để họ dùng thử và đánh giá, góp ý kiến. Trên cơ sở ý kiến khách hàng
người phát triển làm mịn dần bản mẫu cho đến khi khách hàng thấy vừa ý (chủ yếu là
cái vào, cái ra, giao diện ). Căn cứ vào bản mẫu người phát triển cũng hiểu rõ hơn yêu
cầu khách hàng, những yêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn
ngữ lập trình phù hợp
So sánh mô hình thác đổ và mô hình bản mẫu:
Trong mô hình thác đổ, mục đích của pha xác định yêu cầu là làm sao nắm bắt
được những yêu cầu của khách hàng. Tuy nhiên việc này thường gặp khó khăn do
khách hàng đôi khi không diễn đạt được chính xác yêu cầu của mình và có thể người
phát triển đôi khi hiểu sai ý của khách hàng. Việc sử dụng bản mẫu trong pha xác định
yêu cầu sẽ khắc phục được phần nào tình trạng này. Khách hàng dễ kiểm tra lại các yêu

cầu của mình qua việc chạy thử các chức năng của phần mềm bản mẫu. Thực chất thì
mô hình bản mẫu cũng là mô hình thác đổ nhưng kỹ thuật khảo sát được sử dụng là
bản mẫu. Việc sử dụng bản mẫu còn có điểm lợi là giúp các nhà phát triển có cơ hội áp
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 7
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
dụng thử và đánh giá những công nghệ và kỹ thuật mới và có thể giảm thiểu những rủi
ro khi sử dụng những công nghệ mới này.
I.4. Mô hình tăng dần (Incremental model)
Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy. Nếu như
khi xây dựng ngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý
thì khi làm phần mềm chúng ta cũng có thể sửa đổi thậm chí bỏ đi những module
chương trình không phù hợp, một phần mềm ra đời, được đưa vào sử dụng. Trong quá
trình sử dụng ngoài việc phát hiện và sửa chữa sai sót, người ta thấy cần nâng cấp chất
lượng bằng cách cải tiến một vài thuật toán, thêm một số chức năng Ví dụ như khi
làm phần mềm soạn thảo văn bản chẳng hạn. Phiên bản đầu có thể chưa có chức năng
kiểm tra chính tả, chưa có chức năng chèn hình ảnh Người ta nâng cấp phiên bản này
bằng cách bổ sung các chức năng này. Sau khi hoàn thành công việc này người ta lại
thấy nên thêm chức năng vẽ đồ thị, thêm khả năng tính toán trong bảng. Mỗi lần nâng
cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét sửa đổi lại tài
liệu các pha.
Từ nhận xét rằng phần mềm có thể được xây dựng từng bước đã đưa đến việc ra
đời một mô hình mới là mô hình tăng dần.
Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần
(components) tương đối độc lập nhau. Với hệ điều hành chẳng hạn, đó là thành phần
scheduler, thành phần file management system, Mỗi thành phần như vậy được coi như
một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng
theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các
yêu cầu của khách hàng. Ban đầu người ta chưa chú ý đến toàn bộ các yêu cầu của
phần mềm mà chỉ chú ý đến những nét đặc trưng nhất và xây dựng phiên bản đầu tiên
của phần mềm bao gồm các đặc trưng này rồi đưa cho khách hàng sử dụng. Chương

trình được hiệu chỉnh theo ý kiến phản hồi của khách hàng. Tiếp theo người ta lại xây
dựng phần mềm thứ hai thỏa mãn các đặc trưng quan trọng thứ hai và lại đưa cho
khách hàng sử dụng và có ý kiến. Phần mềm thứ hai này sau khi hiệu chỉnh lại được
tích hợp vào phần mềm đầu tiên thành một phần mềm lớn hơn. Phần mềm tích hợp này
lại được kiểm thử để bảo đảm việc ghép nối thành công và chương trình chạy tốt. Cứ
như vậy, thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm
con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn. Sơ đồ sau mô tả mô
hình tăng dần.
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 8
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Hình 5. Mô hình tăng dần (incremental model)
Nhận xét mô hình tăng dần:
Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng
chính là phiên bản hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử
dụng ngay. Thời gian hoàn thành phần mềm được quy định trong hợp đồng và có thể
sớm hoặc muộn hơn. Với mô hình tăng dần thì phần mềm được chia ra nhiều phần
(thường là từ 5 đến 25 phần). Phần đầu tiên chứa đựng những đặc trưng quan trọng
nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian
hoàn thành phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần
mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn
nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Khi mỗi phần sau được
hoàn thành và được tích hợp thì họ được sử dụng ngay. Như vậy họ được làm quen
từng bước với sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng những công nghệ
mới. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có thể có những
ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 9
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
mãn được các yêu cầu đặt ra, thậm chí qua việc sử dụng một số phần đầu, khách hàng
nhận thấy rằng không nên phát triển tiếp vì sẽ không mang lại lợi ích kinh tế.
Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới

phát triển với phần chương trình đã có. Thiết kế của mô hình này do vậy phải có tính
mở và tính mềm dẻo để thích nghi với việc mở rộng dần. Ta có thể nhận thấy rằng,
trong mô hình tăng dần không có sự khác biệt giữa sự phát triển phần mềm và bảo trì
cập nhật (nâng cao). Nếu vận dụng không hợp lý, mô hình này có thể suy thoái thành
mô hình xây dựng và hiệu chỉnh. Sự điều khiển toàn bộ quy trình phát triển phần mềm
có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi kinh hoàng cho
những người bảo trì. Để tránh được điều này, người phát triển ngay từ đầu phải có cách
nhìn toàn cục về sản phẩm, phải đưa ra thiết kế tổng thể của sản phẩm và sự phân chia
các thành phần để phát triển sau này cũng phải trên cơ sở thiết kế toàn cục đó. Như sơ
đồ (trong hình 5) đã chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải được thực
hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng. Nếu không có những
nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành
sản phẩm kém chất lượng.
I.5. Mô hình tăng dần đồng thời (Concurrent incremental model)
Mô hình tăng dần đồng thời còn có tên gọi khác là "lập trình cực điểm"
(extreme programming – viết tắt là XP). Tuy nhiên chúng ta sẽ gọi là mô hình tăng dần
đồng thời cho dễ hình dung. Có thể tóm tắt mô hình này như sau:
Trước hết người ta tìm hiểu nhu cầu khách hàng rồi phân chia thành nhóm các
đặc trưng tương ứng với từng phần của phần mềm cần xây dựng. Sau đó nhóm đặc tả
tiến hành xây dựng đặc tả của phần thứ nhất, sau khi hoàn thành thì trao kết quả cho
nhóm thiết kế thực hiện thiết kế, nhóm lại chuyển qua đặc tả thành phần thứ hai, cứ
như vậy các thành phần được xây dựng song song, và mỗi nhóm sử dụng các thông tin
nhận được từ các thành phần trước đó.
Cách tiếp cận này thực sự đã gây ra rủi ro là các thành phần có thể không tương
thích với nhau. Với mô hình tăng dần, khả năng rủi ro phần nào được giảm thiểu vì
thiết kế kiến trúc được thực hiện trước khi phần mềm được chia nhỏ thành từng phần
và được xây dựng.
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 10
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Sơ đồ mô hình này như sau:

Hình 6. Mô hình tăng dần đồng thời (concurrent incremental model (XP))
Đây là mô hình còn có nhiều tranh cãi. Thực chất là mô hình tăng dần, nhưng
các phần được thực hiện đồng thời. Mô hình này có tính rủi ro cao hơn mô hình tăng
dần thông thường. Bước đầu tiên nhóm phát triển phần mềm dựa vào ý kiến khách
hàng để xác định các đặc trưng khác nhau của phần mềm. Với mỗi đặc trưng như vậy
họ thông báo cho khách hàng là phải xây dựng trong bao lâu và giá cả bao nhiêu. Tiếp
theo khách hàng lựa chọn những đặc trưng cho các phần cần xây dựng dựa trên phân
tích giá cả và lợi nhuận (cost-benifit analysis), tức là phân tích dựa trên thời gian và giá
cả nêu ra bởi nhóm phát triển và lợi nhuận dự tính của công ty họ. Mỗi phần được lựa
chọn lại được chia thành từng phần nhỏ hơn, được gọi là các nhiệm vụ. Mỗi lập trình
viên trước hết nêu ra các trường hợp để thử cho từng nhiệm vụ sau đó cùng làm việc
với cộng sự của họ trước một màn hình (kiểu lập trình này được gọi là pair
programming). Lập trình viên hoàn thành nhiệm vụ được giao và chạy các trường hợp
thử để bảo đảm phần chương trình họ viết đã chạy tốt. Phần chương trình này sau đó
được tích hợp vào phiên bản hiện thời của phần mềm cần xây dựng. Trường hợp lý
tưởng là cả phần lập trình và tích hợp cho một nhiệm vụ chỉ kéo dài trong vài giờ.
Thường thì các cặp lập trình viên thực hiện các nhiệm vụ song song, như thế sự tích
hợp sẽ được tiến hành một cách liên tiếp. Các trường hợp dùng để thử các nhiệm vụ
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 11
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
được giữ lại cho các phép kiểm thử tích hợp sau này. Một số đặc trưng của lập trình
cực điểm (XP) có phần nào hơi khác thường:
• Máy tính của các nhóm lập trình cực điểm được đặt giữa phòng lớn, trong các
phòng nhỏ có vách ngăn.
• Đại diện của khách hàng luôn luôn làm việc cùng nhóm XP.
• Không ai làm việc quá giờ trong hai tuần liên tục.
• Không có phân công đặc biệt. Tất cả các thành viên của nhóm XP đều có thể
tham gia phân tích, thiết kế, lập trình và kiểm thử.
• Như sơ đồ đã chỉ ra, không có thiết kế tổng thể trước khi các phần được xây
dựng. Thay vào đó, thiết kế sẽ được hiệu chỉnh khi sản phẩm được xây dựng.

Thủ tục này được gọi là tái phân tích nhân tố (refactoring). Khi một trường hợp
thử không chạy tốt thì các lệnh sẽ được viết lại cho đến khi nhóm lập trình thấy
rằng thiết kế là đơn giản, rõ ràng và mọi trường hợp thử đều chạy tốt.
Mô hình này thực sự có lợi khi yêu cầu của khách hàng không rõ ràng và hay
thay đổi. Tuy nhiên mô hình này còn chưa được sử dụng rộng rãi .
I.6. Mô hình đồng bộ và ổn định (Synchronize and stabilize model)
Mô hình đồng bộ và ổn định được xây dựng bởi David Yoffie (Đại học
Harvard) và Michael Cusumano (làm việc ở MIT). Pha xác định yêu cầu được thực
hiện bằng cách phỏng vấn rất nhiều khách hàng dự kiến và các đặc trưng của nhu cầu
khách hàng được liệt kê theo thứ tự ưu tiên. Sau đó tài liệu đặc tả được soạn thảo. Tiếp
theo, công việc được chia làm ba hoặc bốn phần. Phần thứ nhất chứa các đặc trưng
quan trọng nhất, phần thứ hai chứa các đặc trưng quan trọng thứ nhì Mỗi thành phần
sẽ được xây dựng bởi một số nhóm nhỏ làm việc song song. Cuối mỗi ngày các nhóm
đồng bộ hóa (synchronize), tức là họ hợp lại những phần họ đã làm riêng biệt thành
một thành phần thống nhất, kiểm tra, sửa lỗi và kiểm thử. Sự ổn định hóa (stabilize)
được thực hiện ở giai đoạn cuối của mỗi phần. Trong giai đoạn này những lỗi còn sót
lại được phát hiện, được sửa chữa và thành phần được đóng gói, tức là không thực hiện
thay đổi nào đối với các đặc tả.
Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau có
thể được kết hợp và cùng làm việc tốt. Một điểm lợi của cách làm này là những người
phát triển có thể sớm nhìn thấy sự hoạt động của phần mềm và có thể hiệu chỉnh các
yêu cầu, có thể là ngay trong quá trình các thành phần được xây dựng. Mô hình này có
thể áp dụng ngay cả trong trường hợp các đặc tả ban đầu không hoàn thiện.
I.7. Mô hình xoắn ốc (Spiral model)
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 12
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Hình 7. Mô hình xoắn ốc (Spiral model)
Mô hình xoắn ốc (do Boehm đề xuất năm 1988) là kết hợp các khía cạnh của
các mô hình trên đây. Cụ thể hơn, mô hình xoắn ốc là sự kết hợp tính lặp của mô hình
bản mẫu và tính hệ thống của mô hình thác đổ. Về bản chất, mô hình xoắn ốc mô tả sự

phát triển của phần mềm qua các giai đoạn tiến hoá, mỗi giai đoạn được coi như một
mô hình thác đổ. Ban đầu người ta chưa định nghĩa hệ thống một cách chi tiết, mà chỉ
chú ý đến những đặc trưng nổi bật nhất. Sau đó phần đặc trưng này được xây dựng và
đưa cho khách hàng xem xét, có ý kiến (cũng không hẳn là sử dụng cho công việc như
trong mô hình tăng dần). Cùng những thông tin phản hồi từ khách hàng, người phát
triển trở lại thực hiện các đặc trưng với mức độ chi tiết hơn. Bản chất mô hình xoắn ốc
như tên gọi của nó, là bắt đầu từ những cái khái quát nhất rồi đi dần đến chi tiết. Trong
quá trình đó có lập kế hoạch cho từng giai đoạn làm chi tiết hóa sản phẩm và phân tích
rủi ro.
Quá trình xây dựng phần mềm thường chứa đựng những rủi ro. Ví dụ người chủ
chốt có thể xin nghỉ việc trước khi phần mềm được hoàn thành. Công ty chế tạo phần
cứng mà phần mềm sẽ cài đặt bị phá sản. Sau khi chi phí hàng trăm nghìn đô la cho sự
phát triển phần mềm bỗng có một bước thay đổi đột phá trong công nghệ làm cho phần
mềm trở nên vô dụng, phải thiết kế lại hoàn toàn. Công ty có thể nghiên cứu và phát
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 13
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
triển hệ quản trị cơ sở dữ liệu, nhưng trước khi sản phẩm được hoàn thành và đưa ra thị
trường thì một công ty khác lại quảng cáo một hệ tương đương có giá rẻ hơn. Có thể
công ty sử dụng mô hình tăng dần đồng thời, nhưng sau đó các thành phần không thể
tích hợp được với nhau để được phần mềm như yêu cầu đặt ra Nói tóm lại, các nhà
phát triển phần mềm thường có thể gặp rất nhiều rủi ro và họ muốn giảm thiểu các khả
năng rủi ro đến mức có thể.
Một trong những cách làm giảm thiểu khả năng rủi ro là sử dụng bản mẫu. Như
ta đã thấy, sử dụng bản mẫu trong pha xác định yêu cầu là cách thức tuyệt vời để ngăn
ngừa khả năng sản xuất ra một phần mềm không thỏa mãn tất cả các yêu cầu của khách
hàng. Trong các pha tiếp theo người ta cũng có thể xây dựng những bản mẫu thích hợp.
Ý tưởng làm giảm thiểu rủi ro thông qua việc sử dụng các bản mẫu và một số
công cụ khác dẫn đến một mô hình mới mang tên: mô hình xoắn ốc( spiral model).
Cách đơn giản nhất để xem xét mô hình này chính là mô hình thác đổ trong đó mỗi pha
(trừ pha bảo trì) được bổ sung phần phân tích rủi ro ở trước. Trước khi bắt đầu một pha

nào đó người ta phân tích các khả năng rủi ro và cách thức giải quyết có thể. Nếu
không có cách nào để giải quyết được các rủi ro quan trọng thì dự án sẽ kết thúc.
Bản mẫu có thể sử dụng một cách hiệu quả để thu thập thông tin về sự rủi ro. Ví
dụ ràng buộc về thời gian có thể kiểm thử bằng cách xây dựng một bản mẫu và ước
lượng thời gian hoàn thành sản phẩm thông qua thời gian xây dựng bản mẫu. Bản mẫu
với số liệu hoặc thiết bị mô phỏng có thể kiểm tra tính thích hợp của một thuật toán
mới.
Tuy nhiên cũng có những rủi ro không thể đánh giá được thông qua bản mẫu. Ví
dụ như nếu một thành viên chủ chốt xin thôi việc trước khi sản phẩm hoàn thành thì
liệu có thể thuê được người thay thế kịp thời hay không? Hoặc trình độ của các thành
viên trong nhóm phát triển liệu có đáp ứng được việc phát triển phần mềm quy mô lớn
hay không? Các thành viên công ty lâu nay vẫn thường xây dựng các phần mềm sử
dụng trong gia đình, nay phải xây dựng phần mềm phức tạp sử dụng trong công sở thì
có làm được không? Một lĩnh vực khác mà bản mẫu cũng không sử dụng được trong
việc đánh giá rủi ro là những hứa hẹn về sự phát triển phần cứng. Phần mềm được phát
triển có tính tới sự ra đời của các thiết bị mà các công ty phần cứng hứa hẹn, nhưng
thực tế lại không xảy ra như vậy.
Mô hình xoắn ốc cung cấp cách thức làm phần mềm bằng cách đưa ra các phiên
bản tăng dần. Sự tăng dần ở đây không phải là bổ sung thêm các thành phần mới như
mô hình tăng dần, mà sự tăng ở đây là sự tiến hóa (evolution), tức là cũng các đặc
trưng ấy nhưng được làm mịn hơn, chi tiết hơn. Phiên bản sau cùng chính là phần mềm
hoàn chỉnh có thể chuyển giao cho khách hàng sử dụng.
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 14
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Mô hình xoắn ốc được chia thành một số khuôn khổ hoạt động, cũng còn được
gọi là vùng nhiệm vụ. Về cơ bản, có khoảng từ ba đến sáu vùng. Ví dụ bốn vùng như
sau:
• Xác định mục tiêu, các giải pháp khác nhau để đạt được mục tiêu, các ràng
buộc.
• Phân tích rủi ro và khả năng giải quyết (thường là xây dựng bản mẫu).

• Phát triển và kiểm tra.
• Lập kế hoạch cho pha tiếp theo.
Để biểu diễn sơ đồ cho mô hình xoắn ốc, người ta vẽ hai đường thẳng vuông góc
cắt nhau chia mặt phẳng thành 4 vùng. Bốn vùng này tương ứng với 4 vùng công việc:
nếu dịch chuyển theo chiều kim đồng hồ và bắt đầu từ góc phần tư phía trên bên trái ta
có các vùng tương ứng là 1,2,3,4.
Coi giao điểm của hai đường thẳng là tâm, ta vẽ các đường xoắn ốc đi từ phía
trong ra ngoài cũng theo chiều kim đồng hồ. Độ dài đường xoắn ốc sẽ biểu diễn giá
tích lũy của phần mềm, Một vòng của đường xoắn ốc sẽ biễu diễn một pha. Nếu đi từ
trong ra ngoài ở góc phần tư số 3 ta được mô hình thác đổ. Một pha bắt đầu từ góc
phần tư phía trên bên trái (góc 1) bằng việc xác định các mục tiêu của pha, các giải
pháp khác nhau để đạt được các mục tiêu này và các ràng buộc cho từng giải pháp. Kết
quả của giai đoạn này là chọn được giải pháp thích hợp. Ở góc phần tư thứ hai là phân
tích rủi ro cho giải pháp đã lựa chọn. Một vài biện pháp được đưa ra để khắc phục rủi
ro. Biện pháp thường được sử dụng là bản mẫu. Nếu rủi ro lớn và không có biện pháp
khắc phục thì dự án phải dừng lại. Trong một số trường hợp, dự án vẫn được tiếp tục
nhưng với quy mô nhỏ hơn. Nếu vấn đề rủi ro được giải quyết thì chuyển sang góc
phần tư thứ ba là phát triển. Ở góc cuối cùng là kế hoạch cho pha tiếp theo. Đường
xoắn ốc sẽ được lặp lại chừng nào sản phẩm chưa đạt mức hoàn chỉnh.
Nhận xét mô hình xoắn ốc:
Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển các phần mềm quy
mô lớn. Bởi vì phần mềm được tiến hóa theo đường xoắn ốc, từ tổng quan cho đến chi
tiết, nên người phát triển và khách hàng hiểu rõ hơn và có phản ứng thích hợp với rủi
ro tại từng mức tiến hóa. Mô hình này dùng bản mẫu như một cơ chế làm giảm rủi ro.
Bản mẫu còn giúp cho khách hàng nhìn rõ từng bước phát triển của phần mềm và có ý
kiến góp ý kịp thời để những người phát triển đi đúng hướng, nhanh chóng đưa đến
phần mềm hoàn thiện. Mô hình đòi hỏi xem xét trực tiếp các rủi ro kỹ thuật cũng như
quản lý tại mọi giai đoạn của dự án, và nếu được áp dụng đúng thì có thể làm giảm rủi
ro trước khi những rủi ro này trở thành vấn đề thực sự.
Tuy nhiên mô hình này không phải là sự lựa chọn tốt nhất cho mọi dự án:

GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 15
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
• Trước hết, phân tích rủi ro sẽ tốn kém, do đó mô hình chỉ có thể áp dụng cho
các dự án lớn, khi mà chi phí phân tích rủi ro là không đáng kể so với tổng chi
phí toàn bộ dự án.
• Phân tích rủi ro được thực hiện trong suốt quá trình phát triển phần mềm. Tuy
nhiên nếu là phần mềm ký hợp đồng mà bị dừng lại thì công ty phát triển sẽ bị
phạt. Do đó với các dự án ký hợp đồng thì nhà phát triển và khách hàng phải
phân tích rủi ro trước khi hợp đồng được ký, chứ không phải trên đường xoắn
ốc như mô hình mô tả.
• Liệu các nhà phát triển đã nhìn thấy hết các rủi ro không? Có thể rủi ro vẫn còn
nhưng họ lại chủ quan cho rằng đã hết và có thể mắc sai lầm. Như vậy mô hình
này chỉ nên áp dụng nếu công ty phần mềm có một đội ngũ chuyên gia phân tích
rủi ro trình độ cao.
I.8. Mô hình hướng đối tượng (Object-Oriented model)
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 16
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Hình 8. Mô hình hướng đối tượng
Trong phương pháp hướng đối tượng, tính lặp giữa các pha và giữa các phần
trong một pha xảy ra nhiều hơn so với phương pháp cấu trúc. Khi xây dựng mô hình
hướng đối tượng người ta muốn chỉ rõ đặc trưng này. Một trong những mô hình như
vậy là mô hình núi đồi được biểu diễn bằng các hình tròn. Mỗi vòng tròn chỉ một pha.
Vòng tròn không rời nhau chỉ ra rằng các pha có phần chung nhau. Bên trong các vòng
tròn có các mũi tên uốn cong ngụ ý nói rằng trong mỗi pha cũng có tính lặp giữa các
phần.
Các pha có phần chung là:
• Pha yêu cầu và pha phân tích hướng đối tượng.
• Pha thiết kế hướng đối tượng, pha lập trình và tích hợp.
• Pha sử dụng và bảo trì.
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 17

Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
PHẦN II
PHƯƠNG PHÁP SCRUM TRONG XÂY DỰNG PHẦN
MỀM
II.1. Khái niệm về SCRUM
SCRUM là quy trình đã được định rõ của phương pháp Agile giúp theo dõi và
điều khiển các hoạt động phát triển phần mềm.
Nó bao gồm những mảng hoạt động thiết lập, theo dõi, và quản lý những việc
chưa làm xong, các công việc hiện tại, những rủi ro, các sự cố và những thay đổi.
Một dự án phần mềm triển khai bằng SCRUM được quản lý qua việc thiết lập,
bảo quản, và theo dõi các thông số điều khiển then chốt. Các cơ chế mang tính kiểm
soát này rất quan trọng khi việc phát triển phần mềm liên quan đến những rủi ro không
định lượng được hay những tình trạng không dự đoán trước được. Việc sử dụng những
cơ chế kiểm soát này cũng là yếu tố then chốt trong quy trình phát triển phần mềm
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 18
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
SCRUM. Các thông số kiểm soát luôn được đo lường, theo dõi, và phối hợp với nhau.
Hai thông số chính là (danh sách) những việc chưa hoàn tất và rủi ro. Danh sách những
việc chưa hoàn tất lúc đầu thường nhiều, sau đó gia tăng thêm trong quá trình lập kế
hoạch, và rồi giảm dần đi khi dự án được tiến hành (qua các bước) - do chúng hoặc đã
được giải quyết xong hoặc đã bị hủy bỏ, và rồi sẽ không còn nữa khi phần mềm được
hoàn tất. Rủi ro sẽ gia tăng khi càng nhiều sự cố, vấn đề, và những việc chưa làm xong
được xác định thêm, sau đó (rủi ro) sẽ giảm đến mức chấp nhận được khi phần mềm
được chỉnh sửa. SCRUM cho phép nhóm phát triển tự xác định khi nào hệ thống (phần
mềm) là ‘đủ tốt’ để chuyển giao cho khách hàng.
II.2. Quy trình thực hiện SCRUM
Hình 9. Tiến trình của SCRUM
Với phương pháp SCRUM, mọi quy trình dự án đều đi qua một series các vòng
lặp, thường dài từ 2 đến 4 tuần, gọi là những đợt chạy nước rút (Sprint). SCRUM đặc
biệt thích hợp với các dự án có yêu cầu hay thay đổi.

GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 19
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
Những việc phải làm trong một dự án SCRUM được liệt kê ra trong Danh sách
các Việc chưa làm cho Sản phẩm (Product Backlog), liệt kê tất cả những thay đổi
muốn có cho sản phẩm.
Ở đầu mỗi đợt chạy nước rút (Sprint), một cuộc Gặp gỡ Lên kế hoạch cho Đợt
chạy nước rút (Sprint Planning Meeting) được tổ chức với người “Chủ” Sản phẩm
(Product Owner) lên thứ tự ưu tiên trước sau cho các phần việc trong Danh sách các
Việc chưa làm cho Sản phẩm (Product Backlog) và nhóm SCRUM (SCRUM Team) sẽ
chọn ra những phần việc mà họ sẽ hoàn tất trong đợt chạy nước rút (Sprint) đó. Những
phần việc đó sẽ được rút ra khỏi Danh sách các Việc chưa làm cho Sản phẩm (Product
Backlog) và đưa vào Danh sách Những việc chưa làm xong trong Đợt chạy nước rút
(Sprint Backlog).
Mỗi ngày, một cuộc họp gọi là “SCRUM hàng ngày” (Daily SCRUM) được tổ
chức nhằm giúp nhóm dự án tập trung với những việc đang cần làm của họ. Những
cuộc họp “SCRUM hàng ngày” (Daily SCRUMs) giúp làm rõ việc gì ai trong nhóm
đang làm, hỗ trợ vấn đề chia sẻ kiến thức, giảm thiểu các việc làm trùng lặp, và đảm
bảo các phần việc đang làm có thể tích hợp được với nhau.
Ở cuối mỗi đợt chạy nước rút (Sprint), nhóm dự án trình bày toàn bộ chức năng
sản phẩm (đã hoàn tất trong đợt chạy nước rút đó) ở cuộc Gặp gỡ Đánh giá Đợt chạy
nước rút (Sprint Review Meeting). Vấn đề then chốt trong triển khai SCRUM là các
vai trò, trách nhiệm, và bổn phận (trong nhóm dự án), được định rõ như sau:
Chủ Sản phẩm có các trách nhiệm sau:
• Xác định các tính năng của sản phẩm.
• Quyết định nội dung và ngày ra sản phẩm.
• Chịu trách nhiệm về lợi nhuận của sản phẩm .
• Ưu tiên thứ tự (phát triển) trước sau của các tính năng sản phẩm dựa theo các
giá trị thị trường.
• Cứ sau 30 ngày thì chỉnh sửa lại các tính năng và thứ tự ưu tiên của chúng
nếu cần.

GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 20
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
• Duyệt hoặc không duyệt kết quả những phần việc (của các thành viên trong
dự án).
Trưởng SCRUM là một người lãnh đạo hỗ trợ cho nhóm dự án, làm việc chặt chẽ
với Chủ Sản phẩm:
• Đảm bảo nhóm dự án hoạt động tốt và có hiệu quả.
• Tạo điều kiện cho sự hợp tác chặt chẽ giữa các vai trò và chức năng trong dự
án.
• Tháo bỏ các rào cản (nếu có).
• Bảo vệ nhóm dự án khỏi những can thiệp từ bên ngoài vào.
• Đảm bảo theo sát quy trình (SCRUM): bao gồm việc mời mọi người tham
dự các cuộc họp “SCRUM hàng ngày” (Daily SCRUMs), các cuộc Gặp gỡ
Đánh giá những Đợt chạy nước rút (Sprint Review Meetings), và các cuộc
Gặp gỡ Lên kế hoạch cho Đợt chạy nước rút (Sprint Planning Meeting).
Nhóm Dự án:
• Đa chức năng, thường gồm bảy hoặc ít hơn (nhưng nhiều hơn hai) thành
viên .
• Chọn mục tiêu cho từng Đợt chạy nước rút (Sprint) và mô tả kết quả công
việc sẽ như thế nào.
• Có quyền làm mọi thứ trong phạm vi quy định về triển khai dự án để đạt
được mục tiêu của từng đợt chạy nước rút (Sprint).
• Tự tổ chức nhóm và công việc của nhóm.
• Trình diễn kết quả công việc cho Chủ Sản phẩm xem.
Các hoạt động của SCRUM
Có 4 hoạt động SCRUM:
• Gặp gỡ lên Kế hoạch cho Đợt chạy nước rút(Sprint Planning Meeting),
• Họp mặt SCRUM hàng ngày (Daily SCRUM),
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 21
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM

• Nhìn nhận lại Đợt chạy nước rút (Sprint Retrospective).
• Gặp gỡ Đánh giá Đợt chạy nước rút (Sprint Review Meeting)

Hình 10. Các hoạt động SCRUM
Hoạt động Gặp gỡ lên Kế hoạch Đợt chạy nước rút (Sprint Planning Meeting):
Việc chuẩn bị cho một đợt chạy nước rút (Sprint) bắt đầu khi Chủ Sản phẩm lên
kế hoạch cho một sản phẩm hay dự án. Chủ Sản phẩm có thể là khách hàng hoặc đại
diện của khách hàng. Người Chủ Sản phẩm phải có tầm nhìn cho sản phẩm cũng như
cho mục đích của sản phẩm để có thể chia nhỏ sản phẩm thành nhiều phần theo một kế
hoạch tổng thể (hay lộ trình thực hiện). Kế hoạch này nêu rõ những đợt duyệt thành
phẩm, với mỗi đợt tập trung vào những tính năng nào đó của sản phẩm. Người Chủ
Sản phẩm chuẩn bị một danh sách những yêu cầu của khách hàng theo thứ tự giá trị
thương mại. Danh sách này gọi là Danh sách các Việc chưa làm cho Sản phẩm
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 22
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
(Product Backlog), là danh sách những tính năng được thứ tự hóa theo giá trị chuyển
giao cho khách hàng.
Dự án SCRUM bắt đầu khi Danh sách các Việc chưa làm cho Sản phẩm
(Product backlog) được xác định đầy đủ và được thứ tự hóa đảm bảo cho đợt chạy
nước rút (Sprint) đầu tiên. Cuộc Gặp gỡ lên Kế hoạch Đợt chạy nước rút sẽ lên kế
hoạch cụ thể cho việc tiến hành công việc. Nó bắt đầu khi người Chủ Sản phẩm đánh
giá lại tầm nhìn, lộ trình, kế hoạch xuất xưởng thành phẩm, và Danh sách các Việc
chưa làm cho Sản phẩm với nhóm dự án SCRUM. Nhóm dự án xem lại những tính
toán cho các tính năng có trên Danh sách các Việc chưa làm cho Sản phẩm (Product
Backlog) để đảm bảo rằng chúng là chính xác nhất có thể. Nhóm dự án quyết định bao
nhiêu việc có thể làm được trong đợt chạy nước rút (Sprint) trước mắt dựa trên thực tế
nhóm dự án lớn hay nhỏ, độ dài ngắn của thời gian thực hiện, và năng suất của nhóm.
Quan trọng là nhóm dự án phải rút được các mục đứng đầu Danh sách các Việc chưa
làm cho Sản phẩm mà họ có thể hoàn tất trong 30 ngày của đợt chạy nước rút (trước
mắt). Khi nhóm dự án đã chọn được tập hợp những tính năng ưu tiên nhất từ Danh

sách các Việc chưa làm cho Sản phẩm, Trưởng SCRUM sẽ lãnh đạo nhóm dự án lên kế
hoạch chia nhỏ các tính năng sản phẩm chưa làm thành những phần việc khác nhau
trong đợt chạy nước rút (Sprint). Đây là những phần việc phát triển cụ thể cần thiết cho
việc triển khai một tính năng và thiết lập Danh sách các Việc chưa làm trong Đợt chạy
nước rút (Sprint Backlog). Trong giai đoạn này cuộc Gặp lên Kế hoạch Đợt chạy nước
rút thường được ước tính vào khoảng tối đa là 4 giờ đồng hồ.
Hoạt động Gặp gỡ SCRUM hàng ngày – Daily SCRUM:
Một khi việc lên kế hoạch đã hoàn tất, đợt chạy nước rút sẽ bắt đầu vòng lặp của
nó. Mỗi ngày, Trưởng SCRUM chủ trì cuộc họp SCRUM hàng ngày. Họp SCRUM
hàng ngày kéo dài khoảng 15 phút nhằm làm sáng tỏ tình trạng (hiện tại) của dự án
SCRUM. Mỗi thành viên trong nhóm sẽ phải trả lời 3 câu hỏi:
1. Bạn đã làm gì kể từ cuộc gặp SCRUM (hàng ngày) lần trước?
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 23
Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM
2. Bạn tính hôm nay sẽ làm gì?
3. Có gì cản trở công việc bạn dự tính sẽ làm hôm nay hay không?
Trong khi ai cũng có thể tham gia cuộc họp này, thì chỉ những thành viên nhóm
dự án trực tiếp có trách nhiệm với những việc cụ thể trong SCRUM mới được quyền
phát biểu. Mục tiêu là để kịp thời có ý tưởng cho dự án, để phát hiện những vấn đề mới
có liên quan lẫn nhau, để xác định những yêu cầu cá nhân của các thành viên, và để
trực tiếp điều chỉnh kế hoạch công việc khi cần nhằm đáp ứng những yêu cầu trong
ngày.
Hoạt động Nhìn nhận lại Đợt chạy nước rút (Sprint Retrospective):
Cuộc họp Nhìn nhận lại Đợt chạy nước rút thường vào khoảng 3 giờ đồng hồ.
Tham dự cuộc họp chỉ gồm nhóm dự án, Trưởng SCRUM, và Chủ Sản phẩm. Cuộc
họp bắt đầu với việc tất cả các thành viên trong nhóm dự án trả lời 2 câu hỏi:
1. Điều gì đã làm tốt trong đợt chạy nước rút lần trước?
2. Những gì đã có thể được cải thiện hơn trong đợt chạy nước rút lần trước?
Trưởng SCRUM sẽ ghi chép lại các câu trả lời trong một mẫu tóm tắt, và nhóm
dự án sẽ thứ tự hóa những dự tính cải tiến mà họ bàn với nhau. Trưởng SCRUM không

cho câu trả lời trong cuộc họp, nhưng hỗ trợ nhóm tìm kiếm các cơ hội cải thiện cho
quy trình SCRUM. Các yêu cầu cần làm, có thể đưa vào (danh sách) những việc sẽ làm
trong đợt chạy tiếp sức tiếp theo, đều được xác định và xem như những yêu cầu quan
trọng, không liên quan đến chức năng trong Danh sách các Việc chưa làm cho Sản
phẩm.
Hoạt động Gặp gỡ Đánh giá Đợt chạy nước rút (Sprint Review Meeting):
Cuối mỗi đợt chạy nước rút, có một buổi Gặp gỡ Đánh giá (lại) Đợt chạy nước
rút. Cuộc gặp này thường kéo dài 4 giờ đồng hồ. Nửa đầu của cuộc gặp, nhóm dự án sẽ
trình bày với Chủ Sản phẩm về những code đã phát triển được trong đợt chạy nước rút
GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 24