Luận văn thạc sĩ ứng dụng logic mờ giải bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình agile

..

ĐẠI HỌC ĐÀ NẴNG
TRƢỜNG ĐẠI HỌC BÁCH KHOA

LÊ DUY TUẤN

ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƢỚC LƢỢNG
NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MƠ HÌNH AGILE

LUẬN VĂN THẠC SĨ
Chun ngành: Khoa học máy tính
Mã số: 8480101

Đà Nẵng – Năm 2019


ĐẠI HỌC ĐÀ NẴNG
TRƢỜNG ĐẠI HỌC BÁCH KHOA

LÊ DUY TUẤN

ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƢỚC LƢỢNG
NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MƠ HÌNH AGILE

Chun ngành: Khoa học máy tính
Mã số: 8480101

LUẬN VĂN THẠC SĨ

NGƢỜI HƢỚNG DẪN KHOA HỌC:

TS. LÊ THỊ MỸ HẠNH

Đà Nẵng – Năm 2019


LỜI CAM ĐOAN
Tơi cam đoan đây là cơng trình nghiên cứu của riêng tôi. Các số liệu, kết quả nêu
trong luận văn là hoàn toàn trung thực và chƣa từng đƣợc ai cơng bố trong bất kỳ cơng
trình nào khác.
Tác giả luận văn

Lê Duy Tuấn

1


MỤC LỤC

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT .................................................. 5
DANH MỤC CÁC BẢNG .............................................................................................. 6
DANH MỤC CÁC HÌNH VẼ ......................................................................................... 7
MỞ ĐẦU ......................................................................................................................... 8
CHƢƠNG I: CƠ SỞ LÝ THUYẾT .............................................................................. 11
CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM ............ 11
1.1 Tổng quan ƣớc lƣợng phần mềm ......................................................................... 11
1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm ..................................................... 12
1.3 Các phƣơng pháp ƣớc lƣợng ............................................................................... 14
1.4 Tổng quan mơ hình Agile .................................................................................... 14
1.4.1 Mơ hình phát triển phần mềm Agile ............................................................ 14
1.4.2 Tun ngơn phát triển phần mềm Agile và các nguyên lý ........................... 15

1.4.3 Các đặc trƣng của mơ hình Agile ................................................................. 16
1.5 Giới thiệu Scrum ................................................................................................. 18
1.5.1 Giới thiệu ...................................................................................................... 18
1.5.2 Khung làm việc Scrum ................................................................................. 19
1.5.3 Nguyên lý hoạt động của scrum: .................................................................. 24
CHƢƠNG II. LOGIC MỜ VÀ ỨNG DỤNG ............................................................... 25
2.1 Cơ sở lý thuyết..................................................................................................... 25
2.1.1 Cơ sở lý thuyết về logic mờ.......................................................................... 25
2.1.2 Cơ sở toán học của logic mờ ........................................................................ 25
2.1.3. Khái niệm về tập mờ ................................................................................... 26
2.1.4. Các phép toán của tập mờ............................................................................ 28
2.2 Logic mờ .............................................................................................................. 31
2.2.1 Khái niệm ..................................................................................................... 31
2.2.2 Biến ngôn ngữ .............................................................................................. 32
2.2.3. Mệnh đề mờ ................................................................................................. 32
2.2.4 Các phép toán của logic mờ. ........................................................................ 36
2.2.5 Biến ngôn ngữ. ............................................................................................. 37
2.2.6 Các luật trong mơ hình logic mờ .................................................................. 37
2.2.7 Qui trình hoạt động của Logic mờ ............................................................... 38
2.2.8 Một số ứng dụng ........................................................................................... 38
2


CHƢƠNG III: ỨNG DỤNG LOGIC MỜ VÀO BÀI TOÁN ƢỚC LƢỢNG NỖ LỰC
PHÁT TRIỂN PHẦN MỀM THEO MƠ HÌNH AGILE .............................................. 40
3.1 Mơ hình tổng quan ............................................................................................... 41
3.2 Bài tốn ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile ................. 41
3.3 Áp dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm ............. 43
3.3.1 Xác định độ phức tạp (nỗ lực) ...................................................................... 44
3.3.2 Xác định vận tốc ........................................................................................... 50

3.3 Tóm tắt các bƣớc thực hiện: ................................................................................ 53
3.4 Ví dụ minh họa. ................................................................................................... 54
3.5 Chƣơng trình ứng dụng ....................................................................................... 56
KẾT LUẬN VÀ TRIỂN VỌNG ................................................................................... 58
1. Kết quả đạt đƣợc. ................................................................................................... 58
2. Hạn chế .................................................................................................................. 58
3. Hƣớng phát triển .................................................................................................... 58
TÀI LIỆU THAM KHẢO ............................................................................................. 59

3


TĨM TẮT LUẬN VĂN
ỨNG DỤNG LOGIC MỜ GIẢI BÀI TỐN ƢỚC LƢỢNG NỖ LỰC PHÁT
TRIỂN PHẦN MỀM THEO MƠ HÌNH AGILE
Học viên: Lê Duy Tuấn

Chuyên ngành: Khoa học máy tính

Mã số: 8480101

Trƣờng: ĐH Bách Khoa – ĐH Đà Nẵng

Khóa: K33

Tóm tắt: Mơ hình phát triển phần mềm linh hoạt (Agile Software
Development) gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần
mềm, mơ hình này khắc phục đƣợc những hạn chế của các phƣơng pháp phát triển
phần mềm truyền thống, góp phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu
khách hàng trong thời gian ngắn nhất với hiệu quả cao nhất. Cũng nhƣ các mơ hình

phát triển phần mềm khác, trong mơ hình phát triển phần mềm Agile khâu ƣớc lƣợng
cũng đóng vai trị quyết định đến sự thành cơng hay thất bại của dự án phần mềm.
Nghiên cứu này nhằm mục đích ứng dụng logic mờ vào bài tốn ƣớc lƣợng nỗ lực phát
triển phần mềm theo mơ hình Agile để giảm thiểu đƣợc thời gian, chi phí cho q trình
ƣớc lƣợng nỗ lực phát triển phần mềm, qua đó góp phần nâng cao hiệu quả cho dự án
phần mềm.
Từ khóa: Mơ hình Agile, quy trình Scrum, ước lượng nỗ lực, công nghệ phần
mềm, logic mờ.

FUZZY LOGIC APPLICATION SOLVES THE ESTIMATION PROBLEM OF
AGILE SOFTWARE DEVELOPMENT EFFORTS
Abstract: Agile Software Development model has become very popular in
software development industry, this model overcomes the limitations of traditional
software development methods, contribute to creating software that can meet customer
requirements in the shortest time with the highest efficiency. Like other software
development models, in Agile software development model, the estimation also plays
a decisive role in the success or failure of software projects. This study aims to apply
fuzzy logic to the estimation of Agile software development efforts to minimize time
and cost for the process of estimating software development efforts, thereby
contributing improve efficiency for software projects.
Keywords: Agile Software Development, Scrum, Software Effort Estimation,
Software Engineering, Fuzzy Logic.

4


DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
STT

Ký hiệu

Diễn giải

1

SLOC

Source Line Of Code: Dòng mã nguồn

2

FP

Function Point: Điểm chức năng

3

OP

Object Point: Điểm đối tƣợng

4

COCOMO

Constructive Cost Model - Mơ hình giá cấu thành

5

SP

Story Point là đại lƣợng chỉ độ lớn tƣơng đối của các user story

6

FR

Friction: Hệ số ma sát

7

DF

Dynamic Force: Yếu tố dao động

8

ES

User Story Effort

5


DANH MỤC CÁC BẢNG
Số hiệu

Tên bảng

Trang

2.1

Mô tả hoạt động của máy sƣởi

38

3.1

Qui mơ, kích thƣớc của Story

44

3.2

Độ phức tạp của User Story

46

3.3

Trọng số các User Story

47

3.4

Yếu tố thành phần nhóm

47

3.5

Giá trị độ phức tạp

49

3.6

Yếu tố ảnh hƣởng hệ số ma sát

50

3.7

Yếu tố ảnh hƣởng hệ số dao động

52

3.8

Minh họa các yếu tố ảnh hƣởng đến hệ số ma sát

54

3.9

Minh họa các yếu tố ảnh hƣởng đến hệ số dao động

55

6


DANH MỤC CÁC HÌNH VẼ
Số hiệu
hình vẽ

Tên hình vẽ

Trang

1.1

Đồ thị hình nón khơng chắc chắn

12

1.2

Quy trình hoạt động Scrum

24

2.1

Hàm phụ thuộc của tập kinh điển A

26

2.2

Hàm liên thuộc của tập mờ

27

2.3

Độ cao, miền xác định, miền tin cậy của tập mờ

27

2.4

Các dạng hàm liên thuộc của tập mờ

28

2.5

Hợp của hai tập mờ có cùng cơ sở theo qui tắc Max (a) và
theo Lukasiewiez (b

29

2.6

Giao của hai tập mờ có cùng cơ sở theo qui tắc Min (a) và
theo tích đại số (b)

30

2.7

Bù của tập mờ

31

2.8

Quy trình hoạt động của hệ Logic mờ

38

3.1

Mơ hình đề xuất

41

3.2

Mơ hình xử lý dữ liệu

43

3.3

Minh họa hàm phụ thuộc giữa SP, ILF với Com

46

3.4

Minh họa các giá trị Story Point trên Matlab

47

3.5

Minh họa các giá trị ILF trên Matlab

48

3.6

Minh họa các giá trị luật trên Matlab

48

3.7

Minh họa kết quả trên Matlab

49

3.8

Minh họa các giá trị Hệ số ma sát

51

3.9

Giao diện xác định độ phức tạp

56

3.10

Giao diện xác định vận tốc

56

3.11

Giao diện dự đoán kết quả

57

7


MỞ ĐẦU
I. Lý do chọn đề tài
Trong quản lý dự án phần mềm, khâu ƣớc ƣớc lƣợng đƣợc xem là vấn đề trực
tiếp ảnh hƣởng đến sự thành công hay thất bại của một dự án phần mềm. Thực tế đã có
rất nhiều dự án thất bại do trong khi thực hiện dự án q trình ƣớc lƣợng khơng chính
xác dẫn đến kế hoạch bị phá sản. Trong quá trình thực hiện dự án ta khơng thể tính
tốn, ƣớc lƣợng chính xác tuyệt đối đƣợc chi phí để phát triển phần mềm, tuy nhiên

nếu các con số dự đoán nằm trong khoảng cho phép sẽ góp phần giảm rủi ro cho dự án
phần mềm. Do đó, nếu ta có một phƣơng pháp ƣớc lƣợng phần mềm hiệu quả thì sẽ
hạn chế đƣợc sự thất bại của một dự án phần mềm.
Hiện nay mơ hình phát triển phần mềm linh hoạt (Agile Software Development)
gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm, mơ hình này
khắc phục đƣợc những hạn chế của các phƣơng pháp phát triển phần mềm truyền
thống, góp phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu khách hàng trong
thời gian ngắn nhất với hiệu quả cao nhất. Tuy nhiên, cũng nhƣ các phƣơng pháp
truyền thống khác, khâu ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile
cũng đóng vai trị quyết định đến sự thành công của một dự án phần mềm.
Dựa trên lý thuyết logic mờ và xét thấy có sự liên quan trong q trình ƣớc
lƣợng nỗ lực đến logic mờ. Do đó, tôi đề xuất chọn luận văn cao học:
"Ứng dụng logic mờ giải bài toán ƣớc lƣợng nỗ lực phát triển phần mềm theo mơ
hình Agile"
II. Mục đích nghiên cứu
Xây dựng đƣợc ứng dụng hỗ trợ ƣớc lƣợng nỗ lực phát triển phần mềm có ứng
dụng logic mờ áp dụng vào mơ hình Agile để giảm thiểu đƣợc thời gian, chi phí cho
q trình ƣớc lƣợng nỗ lực phát triển phần mềm, qua đó góp phần nâng cao hiệu quả
cho dự án phần mềm.
III. Mục tiêu và nhiệm vụ nghiên cứu
1. Mục tiêu:
- Nắm vững lý thuyết về công nghệ phần mềm và kiến thức về ƣớc lƣợng nỗ lực
phát triển phần mềm
- Nắm vững mơ hình phát triển phần mềm Agile
- Nắm vững về lý thuyết logic mờ và áp dụng đƣợc logic mờ vào bài toán ƣớc
lƣợng nỗ lực phát triển phần mềm.

8

- Xây dựng đƣợc ứng dụng để hỗ trợ ƣớc lƣợng nỗ lực phát triển phần mềm
2. Nhiệm vụ:
- Nghiên cứu mơ hình phát triển phần mềm linh hoạt ở thực tiễn.
- Nghiên cứu lý thuyết logic mờ và tình hình ứng dụng logic mờ vào bài tốn
ƣớc lƣợng nỗ lực phát triển phần mềm ở hiện tại.
- Tìm hiểu và cài đặt thuật tốn có ứng dụng logic mờ vào bài toán ƣớc lƣợng
nỗ lực phát triển phần mềm
- Thực nghiệm và đánh giá giá kết quả theo yêu cầu mà đề tài đặt ra
IV. Đối tƣợng và phạm vi nghiên cứu
- Mơ hình phát triển phần mềm Agile
- Lý thuyết ƣớc lƣợng nỗ lực phát triển phần mềm
- Lý thuyết Logic mờ và ứng dụng của logic mờ
V. Phƣơng pháp nghiên cứu
- Phƣơng pháp lý thuyết
- Phƣơng pháp phân tích và tổng hợp
- Phƣơng pháp thực nghiệm
VI. Ý nghĩa khoa học và thực tiễn
- Nghiên cứu và vận dụng đƣợc mơ hình phát triển phần mềm Agile trong công
việc quản lý dự án phần mềm
- Nắm vững phƣơng pháp ƣớc lƣợng nỗ lực phát triển phần mềm
- Nắm vững đƣợc lý thuyết về logic mờ và áp dụng đƣợc vào bài toán nỗ lực
phát triển phần mềm
- Xây dựng đƣợc ứng dụng hỗ trợ ƣớc lƣợng nỗ lực phát triển phần mềm để có
thể áp dụng vào các dự án thực tế
- Kết quả nghiên cứu có thể làm tài liệu tham khảo trong quá trình ƣớc lƣợng nỗ
lực phát triển phần mềm cho các dự án phần mềm
VII. Dự kiến kết quả đạt đƣợc
- Biết đƣợc mô hình phát triển phần mềm Agile
- Biết đƣợc kiến thức về logic mờ và ứng dụng kiến thức về logic mờ để áp
dụng vào bài tốn ƣớc lƣợng chi phí

9


- Xây dựng đƣợc ứng dụng để minh họa cho nội dung luận văn
- Có kết quả thực nghiệm để đánh giá tính thực tế của đề tài
VIII. CẤU TRÚC NỘI DUNG LUẬN VĂN
CHƢƠNG I: CƠ SỞ LÝ THUYẾT
CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM
1.1 Tổng quan ƣớc lƣợng phần mềm
1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm
1.3 Các phƣơng pháp ƣớc lƣợng
1.4 Tổng quan mơ hình Agile
1.5 Giới thiệu Scrum
CHƢƠNG II. LOGIC MỜ VÀ ỨNG DỤNG
2.1 Cơ sở lý thuyết
2.2 Logic mờ
CHƢƠNG III: ỨNG DỤNG LOGIC MỜ VÀO BÀI TOÁN ƢỚC LƢỢNG NỖ LỰC
PHÁT TRIỂN PHẦN MỀM THEO MƠ HÌNH AGILE
3.1 Mơ hình tổng quan
3.2 Bài tốn ƣớc lƣợng nỗ lực phát triển phần mềm theo mơ hình Agile
3.3 Áp dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm
3.4 Ví dụ minh họa
3.5 Chƣơng trình ứng dụng
KẾT LUẬN VÀ TRIỂN VỌNG
1. Kết quả đạt đƣợc
2. Hạn chế
3. Hƣớng phát triển
TÀI LIỆU THAM KHẢO

10

CHƢƠNG I: CƠ SỞ LÝ THUYẾT
CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM
1.1 Tổng quan ƣớc lƣợng phần mềm
Ƣớc lƣợng là cơng việc tính tốn gần đúng một đại lƣợng nào đó dựa trên các
tập dữ liệu liên quan đến đại lƣợng đó. Cũng giống nhƣ bất cứ một dự án nào khác, dự
án phần mềm cũng cần phải ƣớc lƣợng các đại lƣợng trên với mục đích:
- Dự tốn chi phí hợp lý
- Sự chính xác cao
- Đảm bảo tiến độ
- Kiểm soát dự án tốt hơn
- Thể hiện đƣợc sự chuyên nghiệp
Ƣớc lƣợng phần mềm từ lâu đã đƣợc xem là vấn đề cốt lõi có ảnh hƣởng trực
tiếp đến sự thành bại của dự án. Ƣớc lƣợng là một trong những nền tảng cho việc lập
lịch dự án một cách hiệu quả. Nhiều công ty phát triển phần mềm phải chịu thất bại
hoặc bị mất lợi thế cạnh tranh do các ƣớc lƣợng xấu.
Khi phát triển phần mềm cần phải đƣa ra một ƣớc lƣợng về giá cả, nhân lực và
thời gian thực hiện dự án một cách hợp lý. Nếu ƣớc lƣợng thiếu cho một dự án, quản
lý thiếu các nỗ lực đảm bảo chất lƣợng sẽ dẫn đến việc quá tải, vƣợt quá về khả năng
và thời gian làm việc. Ngƣợc lại nếu ƣớc lƣợng dƣ cho một dự án sẽ dẫn đến việc phát
sinh chi phí nhiều hơn so với mức cần thiết dẫn đến sự lãng phí đối với dự án.
Trong suốt quá trình phát triển phần mềm, cho dù có sử dụng mơ hình quản lý
phần mềm nào đi nữa thì sau mỗi cột mốc phát triển phần mềm, các trƣởng dự án
thƣờng phải hoạch định công việc cho cột mốc tiếp theo và tính tốn lại những phần
công việc đã thực hiện đƣợc ở cột mốc trƣớc. Điều đó dẫn đến việc ƣớc lƣợng đƣợc
tiến hành xuyên suốt quá trình thực hiện dự án, trải qua từng bƣớc của quy trình phần
mềm. Ở giai đoạn đầu, dự án cịn ở dạng đơn giản, thiếu thơng tin, việc ƣớc lƣợng
trong giai đoạn này có độ chính xác khơng cao. Càng về những giai đoạn sau, các chi
tiết của dự án đã đầy đủ, độ chính xác của ƣớc lƣợng sẽ tăng lên. Hình 1 cho thấy quá

trình ƣớc lƣợng chính xác hơn sau mỗi giai đoạn của dự án phần mềm.

11


Hình 1.1: Đồ thị hình nón khơng chắc chắn [1]
1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm
Các bƣớc chính trong ƣớc lƣợng dự án phần mềm là:
- Ƣớc lƣợng kích thƣớc, phạm vi dự án: Đây là thơng số ƣớc lƣợng rất đƣợc
quan tâm là yếu tố về độ lớn phần mềm. Một ƣớc lƣợng chính xác về kích thƣớc phần
mềm là cơ sở cho một ƣớc lƣợng có hiệu quả. Ta cần thu thập các thơng tin về phạm vi
của dự án bắt đầu với những mô tả với những yêu cầu của khách hàng. Tài liệu ƣớc
lƣợng cần phải đƣợc làm mới lại sau mỗi lần có thêm thơng tin phạm vi ƣớc lƣợng.
Để ƣớc lƣợng kích thƣớc, phạm vi ta có thể dựa vào các dự án tƣơng tự trong
quá khứ (nếu nhƣ ta đã từng làm). Chúng ta có thể ƣớc lƣợng cho dự án mới bằng cách
dùng phép tính phần trăm của kích thƣớc với phần tƣơng tự của dự án trƣớc đó, sau đó
sẽ tổng lại các kích cỡ đã đƣợc ƣớc lƣợng.
Ngồi ra ta có thể dùng phƣơng pháp phân tích để ƣớc lƣợng kích thƣớc bằng
cách đo độ lớn phần mềm bằng đơn vị dòng mã nguồn (SLOC – Source Line Of
Code). Tuy nhiên trong khi phần mềm chƣa hoàn thành, thơng số này phải phỏng đốn
nên khơng tránh khỏi những sai sót. Để khắc phục tình trạng này ngƣời ta dùng đơn vị
điểm chức năng (FP Function Point). Đơn vị này đƣợc tính tốn dựa trên các u cầu
về chức năng và phi chức năng của một dự án nên mang tính thực tế hơn. Hiện nay
một đơn vị khác cũng đƣợc sử dụng là điểm đối tƣợng (OP – Object Point). Đây là đơn
vị đƣợc tính tốn dựa trên yêu cầu về số màn hình và báo biểu của phần mềm. Nó
thƣờng đƣợc dùng để đo độ lớn phần mềm trong giai đoạn sơ khai của sự án, lúc
những chi tiết dùng để tính điểm chức năng chƣa đƣợc làm rõ.

12

- Ƣớc lƣợng nỗ lực: Sau khi chúng ta đã có đƣợc một ƣớc lƣợng kích thƣớc,
phạm vi của sản phẩm, chúng ta có thể tính tốn đƣợc ƣớc lƣợng nỗ lực từ nó. Kích
thƣớc của phần mềm là yếu tố quan trọng nhất trong việc xác định bao nhiêu nỗ lực là
cần thiết để xây dựng nó. Tuy nhiên, kích thƣớc cuối cùng thì khơng đƣợc biết khi dự
án vẫn cịn đang đƣợc hình thành, và phần mềm chƣa thực sự tồn tại. Do đó, nếu kích
thƣớc đƣợc sử dụng cho một mơ hình ƣớc lƣợng nỗ lực, nó phải đƣợc ƣớc lƣợng ngay
từ lúc đầu. Có 2 cách để tính tốn nỗ lực là dùng dữ liệu lịch sử và sử dụng mơ hình
tính tốn.
Dùng dữ liệu lịch sử tức là dựa vào các dữ liệu nỗ lực và kích thƣớc của các dự
án trƣớc đã sử dụng trong quá khứ để ƣớc lƣợng cho dự án hiện tại. Sau khi đã có
đƣợc một nỗ lực tổng thể ta sẽ xác định các nỗ lực cho các hoạt động hoặc các giai
đoạn bằng tỉ lệ phần trăm so với nỗ lực tổng thể.
Trƣờng hợp ta khơng có dữ liệu của dự án trong quá khứ chúng ta có thể tiếp
cận một số thuận tốn đã hồn thiện và đƣợc cơng nhận rộng rãi (ví dụ mơ hình
COCOMO, COCOMO II). Các mơ hình này có đƣợc từ việc nghiên cứu một số lƣợng
lớn các dự án đã đƣợc hoàn thành từ nhiều tổ chức khác nhau để xem xét các kích cỡ
dự án so với tổng nỗ lực của dự án tổng. Vì dữ liệu đƣợc thu thập từ nhiều dự án của
các tổ chức nên có thể độ chính xác so với dữ liệu so với tổ chức của mình nhƣng
chúng có thể giúp chúng ta có đƣợc những ƣớc lƣợng nỗ lực gần đúng.
- Ƣớc lƣợng tiến trình: Sau khi nỗ lực đã đƣợc biết hoặc đã đƣợc ấn định cố
định ngay từ đầu, các thời gian biểu khác nhau có thể tính đƣợc tính, tùy thuộc vào số
nhân sự đƣợc đƣa vào để thực hiện dự án. Ta sẽ ƣớc lƣợng số lƣợng ngƣời làm việc
trên dự án, họ sẽ làm những gì, thời gian bắt đầu làm, thời gian kết thúc. Khi ta có
đƣợc thơng tin này ta sẽ phải tính tốn để đƣa vào lịch trình theo thời gian. Ƣớc lƣợng
lịch trình cho một dự án là một vấn đề phức tạp vì phần lớn dự án đều trễ tiến độ
nguyên nhân là do mất sự kiểm soát tiến độ dự án.
- Ƣớc lƣợng chi phí: Trong ngành sản xuất phần mềm yếu tố ƣớc lƣợng đƣợc
quan tâm là chi phí phần mềm. Chi phí phần mềm bao gồm:
Chí phí sản xuất: Chi phí để phát triển phần mềm dựa trên số công thực hiện dự

án phần mềm.
Chi phí mơi trƣờng: Bao gồm những chi phí phát sinh trong q trình phát triển
dự án.
Trong 2 loại chi phí này thì chi phí mơi trƣờng phụ thuộc vào rất nhiều yếu tố
nhƣ: giá cả, xu hƣớng thị trƣờng, mức độ lạm phát... nên việc ƣớc lƣợng là khơng khả
thi. Trong đó chi phí sản xuất đƣợc tính tốn trên cơng thực hiện dự án phần mềm nên
việc ƣớc lƣợng có thể làm đƣợc.
13


1.3 Các phƣơng pháp ƣớc lƣợng
Ƣớc lƣợng phần mềm là một quá trình phức tạp. Đầu vào của quá trình ƣớc
lƣợng là các thông số, các thông số này ảnh hƣởng đến cơng việc thực hiện của dự án,
có thể chia các thông số thành các loại sau:
- Thông số về sản phẩm: những yếu tố của sản phẩm phần mềm ảnh hƣởng đến
công thực hiện dự án: độ lớn, độ phức tạp, loại phần mềm.
- Thông số về môi trƣờng: gồm những yếu tố mơi trƣởng có ảnh hƣởng đến
cơng thực hiện sự án nhƣ: quy trình thực hiện, công nghệ triển khai...
- Thông số về đội ngũ phát triển: trình độ, khả năng chun mơn, kinh nghiệm
Các phƣơng pháp ƣớc lƣợng nỗ lực có thể đƣợc sử dụng:
- Ƣớc lƣợng dựa vào chuyên gia: Phƣơng pháp này dựa vào các kinh nghiệm
của những chuyên gia làm phần mềm, tuy nhiên phƣơng pháp này mang tính chủ quan,
khơng phải kết quả lúc nào cũng tin cậy.
- Ƣớc lƣợng dựa vào các dự án cũ: Phƣơng pháp này sử dụng những số liệu của
các dự án phần mềm trƣớc đó, từ đó dự đốn ƣớc lƣợng cho dự án hiện tại
- Ƣớc lƣợng bằng các mơ hình thực nghiệm: Phƣơng pháp này sẽ sử dụng một
mơ hình thực nghiệm cụ thể để ƣớc lƣợng. Tuy nhiên phƣơng pháp này cần có các
tham số về dự án
1.4 Tổng quan mơ hình Agile
Phƣơng pháp phát triển phần mềm linh hoạt đƣợc đƣa ra vào giữa những năm

90 nhƣ là một phần của sự nỗ lực chống lại những phƣơng pháp “nặng nề” – điển hình
bởi những quy định khắt khe. Ban đầu chúng đƣợc gọi là “phƣơng pháp nhẹ”. Đến
năm 2001, 17 thành viên nổi bật của cộng đồng phát triển phần mềm linh hoạt đã gặp
gỡ tại Snowbird, Utah để thảo luận về cách thức tạo ra phần mềm linh hoạt hơn, nhanh
hơn và hƣớng con ngƣời hơn. Họ đã thông qua tên gọi chính thức “phƣơng pháp linh
hoạt”
1.4.1 Mơ hình phát triển phần mềm Agile
Agile là mơ hình phát triển phần mềm linh hoạt, dựa trên phƣơng thức lặp
(iterative) và tăng trƣởng (incremental). Nó sẽ gắn kết khách hàng vào quy trình phát
triển của phần mềm, mọi ngƣời cố gắng cho ra sản phẩm càng nhanh càng tốt. Sau đó
đƣa cho khách hàng dùng thử và phản hồi lại, đội ngũ phát triển sẽ tiếp tục phát triển
các giai đoạn tiếp theo. Tùy vào dự án mà thời gian release ra sản phẩm dài hay ngắn
(có thể 2 tuần, cũng có thể 1 tháng…)

14


Thuật ngữ "Agile" chính thức đƣợc sử dụng rộng rãi theo cách thống nhất kể từ
khi “Tuyên ngôn Agile” đƣợc giới thiệu ra cơng chúng năm 2001. Nhờ tính linh hoạt,
đa dạng và hiệu quả cao, các phƣơng pháp Agile ngày càng trở thành sự lựa chọn hàng
đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm.
1.4.2 Tuyên ngôn phát triển phần mềm Agile và các nguyên lý
Tuyên ngôn phát triển phần mềm Agile [1]
- Tuyên ngôn 1: Cá nhân và sự tƣơng tác hơn là quy trình và cơng cụ.
Khơng phải lúc nào mọi việc đều có giải pháp mà giải pháp chính là nằm bên
trong công việc. Đối với một số công việc để tìm giải pháp khơng chỉ tập trung vào lý
thuyết mà phải trải qua thực tiễn. Ở đây bản tuyên ngơn nhấn mạnh vai trị của từng cá
nhân và mối quan hệ giữa các cá nhân trong nhóm phát triển phần mềm. Nếu dự án có
những thành viên có năng lực, luôn sẵn sàng chia sẻ kiến thức, hỗ trợ lẫn nhau trong
cơng việc thì sẽ mang đến thành cơng. Nếu dự án của bạn có quy trình làm việc tốt,

đƣợc hỗ trợ những công cụ tốt nhất nhƣng những thành viên khơng “cùng nhìn về một
hƣớng” thì khả năng dự án thất bại là rất lớn. Ở Agile mọi ngƣời cùng làm việc trong
nhóm, chia sẻ thơng tin với nhau hơn là theo sát một quy trình hay cơng cụ nào đó.
- Tun ngơn 2: Phần mềm chạy tốt hơn là tài liệu đầy đủ.
Một phần mềm dù có tài liệu hƣớng dẫn tốt, chi tiết tới đâu nhƣng vận hành
khơng hiệu quả thì xem nhƣ khơng đạt, vì vậy việc tạo ra sản phẩm phần mềm trong
trọng hơn và tài liệu chỉ đóng vai trị hỗ trợ phần mềm, mơ tả phần mềm một cách
chính xác. Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt
mang lại. Tất cả các phƣơng pháp linh hoạt thể hiện ở Agile bằng cách nhấn mạnh việc
cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời
gian nhất định, Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là phần
mềm chạy tốt, thƣờng đƣợc biết nhƣ "Định nghĩa của hoàn thành". Ở mức độ cao, một
phần của chức năng hồn thành chỉ khi các tính năng của chúng vƣợt qua tất cả các
kiểm thức và có thể vận hành bởi ngƣời dùng cuối. Ở mức thấp hơn, các nhóm phải
vƣợt qua những kiểm thự đơn vị và kiểm thử hệ thống.
- Tuyên ngôn 3: Cộng tác với khách hàng hơn là đàm phán hợp đồng:
Việc ký kết hợp đồng là quan trọng nhƣng chƣa đủ. Một môi trƣờng hợp tác tốt
sẽ giúp cho những ngƣời phát triển đƣa ra những giải pháp tốt nhất cho khách hàng,
khách hàng và những ngƣời phát triển phải tƣơng tác với nhau để làm rõ các yêu cầu
cũng nhƣ các vấn đề cần thiết. Bản tun ngơn khuyến khích khách hàng cũng tham
một phần của dự án hơn chỉ là viết hợp đồng.

15


- Tuyên ngôn 4: Phản hồi với các thay đổi hơn là bám sát kế hoạch: Việc lập kế
hoạch cho phát triển phần mềm là rất quan trọng. Một bản kế hoạch tốt sẽ giúp công
việc đƣợc định hƣớng tốt hơn. Tuy nhiên trong thực tế có rất nhiều sự thay đổi và nếu
nhƣ ta cứ bám sát và kế hoạch ban đầu mà không thay đổi theo thực tế thì sẽ dẫn đến
sự thất bại. Vì vậy nhóm phát triển phần mềm phải ln sẵn sàng đón nhận các sự thay

đổi khi có yêu cầu.
12 nguyên lý sau tuyên ngôn Agile [1]
- Ƣu tiên cao nhất là thỏa mãn khách hàng thông qua việc chuyển giao sớm và
liên tục các phần mềm có giá trị.
- Chào đón việc thay đổi u cầu, thậm chí rất muộn trong q trình phát triển.
Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng.
- Thƣờng xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến
vài tháng, ƣu tiên cho các khoảng thời gian ngắn hơn.
- Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong
suốt dự án.
- Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ
mơi trƣờng và sự hỗ trợ cần thiết, và tin tƣởng họ để hồn thành cơng việc.
- Phƣơng pháp hiệu quả nhất để truyền đạt thơng tin tới nhóm phát triển và
trong nội bộ nhóm phát triển là hội thoại trực tiếp.
- Phần mềm chạy tốt là thƣớc đo chính của tiến độ.
- Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát
triển, và ngƣời dùng có thể duy trì một nhịp độ liên tục không giới hạn.
- Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
- Sự đơn giản – nghệ thuật tối đa hóa lƣợng công việc chƣa xong – là căn bản.
- Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ đƣợc làm ra bởi
các nhóm tự tổ chức.
- Đội sản xuất sẽ thƣờng xuyên suy nghĩ về việc làm sao để trở nên hiệu quả
hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.
1.4.3 Các đặc trƣng của mơ hình Agile
Phát triển linh hoạt bản thân nó khơng phải là một phƣơng pháp. Nó là một
thuật ngữ chung mô tả rất nhiều các phƣơng pháp linh hoạt. Tại thời điểm ký kết
Tuyên ngôn Agile năm 2001, những phƣơng pháp này bao gồm: Scrum, XP, Crystal,
FDD và DSDM. Mỗi phƣơng pháp phát triển linh hoạt có một cách tiếp cận hơi khác
16

nhau để thực hiện các giá trị cốt lõi trong tun ngơn Agile, cũng giống nhƣ các ngơn
ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hƣớng đối tƣợng theo
những cách khác nhau. Phƣơng pháp linh hoạt có những đặc trƣng sau:
- Tính lặp: Dự án sẽ đƣợc thực hiện trong các phân đoạn lặp đi lặp lại. Các phân
đoạn này thƣờng có khung thời gian ngắn (từ một đến bốn tuần). Trong mỗi phân đoạn
này, nhóm phát triển thực hiện đầy đủ các cơng việc cần thiết nhƣ lập kế hoạch, phân
tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các
phần nhỏ của sản phẩm. Các phƣơng pháp agile thƣờng phân rã mục tiêu thành các
phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và khơng thực
hiện việc lập kế hoạch dài hạn.
- Tính tăng trƣởng và tiến hóa: Cuối các phân đoạn, nhóm phát triển thƣờng cho
ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thƣờng là đầy đủ, có khả
năng chạy tốt, đƣợc kiểm thử cẩn thận và có thể sử dụng ngay. Theo thời gian, phân
đoạn này tiếp nối phân đoạn kia, các phần chạy đƣợc này sẽ đƣợc tích lũy, lớn dần lên
cho tới khi toàn bộ yêu cầu của khách hàng đƣợc thỏa mãn. Sản phẩm trong các dự án
agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt đƣợc trạng thái đủ để phát
hành.
- Tính thích nghi: Do các phân đoạn chỉ kéo dài trong một khoảng thời gian
ngắn, và việc lập kế hoạch cũng đƣợc điều chỉnh liên tục, nên các thay đổi trong q
trình phát triển (u cầu thay đổi, thay đổi cơng nghệ, thay đổi định hƣớng về mục tiêu
v.v.) đều có thể đƣợc đáp ứng theo cách thích hợp. Theo đó, các quy trình agile thƣờng
thích ứng rất tốt với các thay đổi.
- Nhóm tự tổ chức và liên chức năng: Cấu trúc nhóm agile thƣờng là liên chức
năng và tự tổ chức. Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc
mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự
phân cấp rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo
dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ
không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control).
- Quản lý tiến trình thực nghiệm: Các nhóm agile ra các quyết định dựa trên các

dữ liệu thực tiễn thay vì tính tốn lý thuyết hay các giả định. Việc phân nhỏ dự án
thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập
dữ kiện cho phép điều chỉnh các chiến lƣợc phát triển của mình. Theo thời gian, các
chiến lƣợc này sẽ tiến gần đến trạng thái tối ƣu, nhờ đó nhóm có thể kiểm sốt đƣợc
tiến trình, và nâng cao năng suất lao động.
- Giao tiếp trực diện: Mơ hình Agile đánh giá cao hơn việc giao tiếp trực diện
thay vì gián tiếp thơng qua giấy tờ. Về yêu cầu của khách hàng, agile khuyến khích
17


nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng
thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản. Trong giao tiếp giữa nội bộ
nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ
sƣ (thực hiện việc thiết kế) giao tiếp với nhau thơng qua bản thiết kế, agile khuyến
khích hai ngƣời này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống
và cùng nhau triển khai thành các chức năng theo yêu cầu. Bản thân các nhóm agile
thƣờng nhỏ để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả. Các
nhóm phát triển thƣờng tạo ra các thói quen trao đổi trực diện một cách thƣờng xuyên.
Một trong các cơ chế thƣờng thấy là các cuộc họp tập trung hằng ngày (daily meeting).
Tại đây, tất cả các thành viên đƣợc u cầu nói rõ cho nhóm của mình biết mình đã
làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong q trình làm
việc. Khi cơ chế này đƣợc thực hiện hiệu quả, nhóm ln ln nắm đƣợc tình hình
cơng việc của mình, có các hành động thích hợp để vƣợt qua các trở lực để thực hiện
thành công mục tiêu của dự án.
- Phát triển dựa trên giá trị: Một trong các nguyên tắc cơ bản của agile là “phần
mềm chạy tốt chính là thƣớc đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ
đi các công việc dƣ thừa không trực tiếp mang lại giá trị cho sản phẩm. Để vận hành
đƣợc cơ chế “làm việc dựa trên giá trị”, nhóm agile thƣờng làm việc trực tiếp và
thƣờng xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ
để biết yêu cầu nào có độ ƣu tiên cao hơn, mang lại giá trị hơn cho dự án. Nhờ đó các

dự án agile thƣờng giúp khách hàng tối ƣu hóa đƣợc giá trị của dự án. Một cách gần
nhƣ trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.
Các phƣơng pháp phát triển phần mềm linh hoạt hiện nay bao gồm: Extreme
programming (XP), Scrum, Crystal family of methodologies, Feature Driven
Development (FDD), The Rational Unified Process, Dynamic Systems Development
Menthod (DSDM), Adaptive Software Development, Open Sourse Software
Development, ngồi ra cịn có các phƣơng pháp khác.
1.5 Giới thiệu Scrum
1.5.1 Giới thiệu
Scrum là một phƣơng pháp Agile dùng cho phát triển sản phẩ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. 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. Để 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.

18


Cốt lõi của qui trình Scrum đó là Sprint, một vịng thời gian của một tháng hoặc
ít hơn, sự phát triển và tung ra sản phẩm có tiềm năng, hữu dụng đƣợc tạo ra. Những
Sprints tối ƣu là sprint có thời hạn thông qua sự nỗ lực phát triển. Sprint mới sẽ bắt
đầu ngày sau khi Sprint trƣớc kết thúc. Trong mỗi Sprint:
- Khơng có sự thay đổi đƣợc thực hiện nhằm duy trì đƣợc kết quả của Sprint đó.
- Chất lƣợng kết quả khơng đƣợc giảm và có thể làm rõ và thảo luận lại bởi chủ
sản phẩm và đội phát triển.
1.5.2 Khung làm việc Scrum
a. Ba giá trị cốt lõi: [6]
a) Minh bạch (Transparency): Trong Scrum, minh bạch xem 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 phải minh bạch và thơng suốt.
Từ đó mọi ngƣời vớ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á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 bảo đảm thông tin minh bạch cho các bên.
b) Thanh tra (Inspection): Công tác thanh tra liên tục các hoạt động trong scrum
bảo đảm cho việc phát triển 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. Với việc 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ải tiến liên tục trong Scrum.
c) Thích nghi (Adaptation): Scrum là một trong những phƣơng pháp phát triển
rất linh hoạt. Nhờ đó mang lại tinh thích nghi rất cao. 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 nhiều thành cơng lớn cho dự án.
b. Ba vai trò: [6]
Ba vai trò trong Scrum là: Product Owner, Nhóm Phát triển, và ScrumMaster.
Tất cả hợp thành nhóm Scrum
Product Owner: Là ngƣời chịu trách nhiệm về sự thành công của sản phẩm
đang đƣợc phát triển. Product Owner có thể là ngƣời trực tiếp sở hữu sản phẩm hoặc
có thể là đại diện cho các bên liên quan khác nhƣng ln ln là ngƣời chịu trách
nhiệm và có tiếng nói cuối cùng về mọi quyết định liên quan đến sản phẩm. Công việc
chủ yếu của Product Owner là tối ƣu hóa giá trị của sản phẩm thơng qua việc quản lý
thật tốt Product Backlog.
ScrumMaster: Là ngƣời đảm bảo Nhóm Scrum hoạt động năng suất nhất thơng
qua việc áp dụng tốt Scrum. 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ỏ
19


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

Để đạt đƣợc điều này thì ScrumMaster có thể sử dụng một số kỹ thuật nhƣ dạy,
huấn luyện để nhóm am hiểu về triết lý cũng nhƣ áp dụng tốt các kỹ thuật thực tế sử
dụng trong Scrum. ScrumMaster cũng có nhiệm vụ loại bỏ tất cả các trở ngại mà nhóm
gặp phải, bảo vệ nhóm trƣớc tất cả những nguyên nhân gây ảnh hƣởng tới cơng việc
của nhóm.
Nhóm Phát triển: Là tập hợp của từ 3 đến 9 thành viên chịu trách nhiệm trực
tiếp tham gia sản xuất. Hai tính chất quan trọng nhất của Nhóm Phát triển đó là tự-tổ
chức và liên-chức năng. Tự-tổ chức tức là các thành viên tự sắp xếp công việc, tự đƣa
ra các quyết định để đạt đƣợc mục đích của nhóm mà khơng bị sự quản lý, điều khiển
từ bất cứ ai bên ngồi nhóm, kể cả các lãnh đạo. Liên-chức năng có nghĩa là nhóm có
đầy đủ tất cả các kỹ năng cần thiết để có thể độc lập hồn thành tất cả các công việc
mà không cần chờ đợi ai khác từ bên ngồi. Nhóm liên-chức năng tức là nhóm có đầy
đủ các kỹ năng chứ không phải là mỗi thành viên đều phải có hết tất cả các kỹ năng.
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. Một vài
ngƣời liên quan chẳng hạn nhƣ những ngƣời quản lý chức năng (ví dụ, ngƣời quản lý
kỹ thuật) có thể thấy vai trò của họ nếu còn giá trị thì cũng thay đổi khi áp dụng
Scrum. Ví dụ:
Họ hỗ trợ Nhóm Phát triển bằng cách tơn trọng các quy tắc và tinh thần của
Scrum
Họ giúp loại bỏ các trở ngại mà Nhóm Phát triển và Product Owner chỉ ra
Họ sẵn sàng đóng góp chun mơn và kinh nghiệm của mình
c. Năm cuộc họp: [6]
1. Sprint Planning (Họp Kế hoạch Sprint): 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 (xem thêm phần Sprint bên dƣới).
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.

20


2. Daily Scrum (Họp Scrum hằng ngày): Scrum Master tổ chức cho Đội sản
xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ cơng việc
cũng nhƣ chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một
Sprint.
3. Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng với
Product Owner sẽ rà sốt lại các cơng việc đã hoàn tất (DONE) trong Sprint vừa qua
và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm.
4. Sprint Retrospective (Họp Cải tiến Sprint): Dƣới sự trợ giúp của Scrum
Master, nhóm phát triển sẽ rà sốt lại tồn diện Sprint vừa kết thúc và tìm cách cải tiến
quy trình làm việc cũng nhƣ bản thân sản phẩm. Cuối Sprint, nhóm phát triển cùng với
Product Owner sẽ rà sốt lại các cơng việc đã hồn tất (DONE) trong Sprint vừa qua
và đề xuất các chỉnh sửa hoặc thay đổi cần thiết.
5. Sprint Planning (Họp Kế hoạch Sprint): 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
d. Ba cơng cụ: [6]
- 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à danh sách các hạng
mục cần phát triển của sản phẩm. Danh sách này đƣợc sắp xếp theo độ ƣu tiên do
Product Owner quyết định. Product Owner là ngƣời chịu trách nhiệm quản lý Product
Backlog, kể cả nội dung, đánh giá độ ƣu tiên cho đến việc cập nhật 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). Các hạng mục trong
Product Backlog có thể là các tính năng mong muốn của sản phẩm, hoặc các cải tiến
kỹ thuật lớn, hoặc các lỗi kỹ thuật đã đƣợc phát hiệ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.
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 có độ ƣu tiên cao cần
đƣợc làm mịn và chi tiết hơn so với hạng mục có ƣu tiên thấp hơn vì chúng sẽ đƣợc
lựa chọn để thực hiện trƣớc.

21


Estimated (đƣợc ƣớc lƣợng) - Mỗi hạng mục cần có khối lƣợng cơng việc ƣớc
tính cùng một số thơng số khác.
Emergent (Tiến hóa) - 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. Product Backlog luôn đƣợ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 có độ ƣu tiên cao hơn nằm
ở phía trên của Product Backlog. Tiêu chí sắp xếp độ ƣu tiên dựa trên Lợi ích tƣơng
xứng với đồng tiền bạn bỏ ra, nhiều lợi ích với ít tiền nhất. 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.
Để ƣớc tính khối lƣợng cơng việc (Estimated), một kỹ thuật phổ biến đó là ƣớc
tính theo kích thƣớc tƣơng đối (hệ số nỗ lực, độ phức tạp và tính bất định) gọi là “story
point” trong sự thống nhất, tƣơng quan và mặt bằng chung của cả nhóm.
Một lợi thế của Scrum là nhờ vào việc ƣớc tính khối lƣợng cơng việc tốt,
Product Owner có thể theo dõi lƣợng cơng việc hồn thành trong mỗi Sprint: Ví dụ,

trung bình Team hồn thành 26 point cho một Sprint. Với thơng tin này, nếu giá trị
trung bình đƣợc giữ ngun và khơng có gì khác thay đổi, ngƣời ta có thể trù liệu đƣợc
ngày phát hành (đợt Release) mà tất cả các tính năng (dự kiến sẽ ra mắt) đều đƣợc
hồn thành. Giá trị trung bình này đƣợc gọi là “tốc độ” (velocity). Tốc độ đƣợc biểu
diễn cùng đơn vị với ƣớc tính kích thƣớc của hạng mục Product Backlog
Các hạng mục lớn trong Product Backlog cần đƣợc làm mịn + chia nhỏ hơn
trong buổi họp Sprint Planning. Và các hạng mục nhỏ có thể đƣợc hợp nhất lại với
nhau.
Phần lớn thời gian của nhóm Phát triển là dành cho các mục tiêu của Product
Owner chứ không phải là các cơng việc kỹ thuật nội bộ mặc dù nhóm Phát triển có
quyền độc lập trong việc quyết định số lƣợng hạng mục đƣợc đƣa vào trong một
Sprint.
Không nên mô tả tất cả mọi chi tiết có thể có của một hạng mục mà chỉ nên làm
rõ những gì cần thiết đủ để hiểu tốt hạng mục đó.
- Sprint Backlog (tạo tác): Là danh sách chứa các hạng mục Product Backlog
đƣợc lựa chọn cho Sprint hiện tại và các công việc cần thực hiện để hồn thành các
hạng mục đó. Sprint Backlog có thể chứa thêm thơng tin về các ƣớc tính khối lƣợng

22


công việc của từng hạng mục và của cả Sprint. Sprint Backlog đƣợc quản lý bởi Nhóm
Phát triển.
Phần tăng trƣởng Sản phẩm (tạo tác): Đơi khi cịn đƣợc gọi ngắn gọi là Phần
tăng trƣởng. Là kết quả “hoàn thành” đƣợc Nhóm Phát triển chuyển giao sau mỗi
Sprint. Để đƣợc coi là “hồn thành” thì các hạng mục Product Backlog phải thỏa mãn
với Định nghĩa Hoàn thành đã đƣợc thống nhất trƣớc đó. Tính chất cốt lõi của Phần
tăng trƣởng đó là có khả năng chuyển giao đƣợc, tức là có thể đƣa vào sử dụng ngay
mà không cần làm thêm bất cứ công việc nào nữa.
Sprint: Là khoảng thời gian cố định mà ở đó Nhóm 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 ngắn 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.
Lập kế hoạch Sprint (sự kiện): Sự kiện diễn ra đầu Sprint để lên kế hoạch làm
việc cho toàn bộ Sprint. Sự kiện này đƣợc chia làm 2 phần với 2 mục đích rõ ràng:
Phần 1 nhằm trả lời câu hỏi “Mình sẽ làm cái gì?”, cịn Phần 2 nhằm trả lời câu hỏi
“Mình sẽ làm nhƣ thế nào?”. Tồn bộ Nhóm Scrum (bao gồm Product Owner,
ScrumMaster và Nhóm Phát triển) phải tham dự Phần 1 của buổi Lập kế hoạch Sprint.
Product Owner có thể vắng mặt ở Phần 2 nhƣng phải đảm bảo sẵn sàng (có thể là qua
điện thoại, công cụ chat…) để giải đáp các thắc mắc của Nhóm Phát triển nếu có.
Nhóm Phát triển có quyền quyết định lựa chọn những hạng mục mà mình sẽ làm,
không ai đƣợc phép can thiệp và gán công việc cho nhóm, kể cả Product Owner hay
các lãnh đạo khác. Kết quả của buổi Lập kế hoạch Sprint là: Mục tiêu Sprint và Sprint
Backlog.
Mục tiêu Sprint: Là một hoặc một vài câu mô tả tổng quan về kết quả mà
Product Owner mong muốn đạt đƣợc khi Sprint kết thúc. Khi một Sprint diễn ra,
Sprint Backlog có thể có thay đổi nhỏ nhƣng Mục tiêu Sprint thì phải ổn định.
Scrum Hằng ngày (sự kiện): 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 để cập nhật thông tin và phối hợp giữa các thành viên
trong nhóm. Để giữ đơn giản và tạo thói quen thì các buổi Scrum Hằng ngày phải diễn
ra tại cùng một địa điểm vào cùng một khung thời gian. Tại phiên làm việc này, mỗi
thành viên sẽ trình bày câu trả lời cho 3 câu hỏi: “Mình đã làm những gì từ buổi gặp
mặt hơm trƣớc tới nay?”, “Mình sẽ làm những gì từ bây giờ cho đến buổi gặp mặt
sau?”, “Tơi gặp phải khó khăn gì?”. ScrumMaster khơng bắt buộc tham dự nhƣng phải
đảm bảo Nhóm Phát triển đang thực hiện tốt sự kiện này.

23