Nghiên cứu phương pháp Kanban và áp dụng phát triển phần mềm quản lý con dấu

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ


PHẠM CÔNG THIÊN LÝ






LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƢỜI HƢỚNG DẪN KHOA HỌC: TS TRƢƠNG ANH HOÀNG

NGHIÊN CỨU PHƢƠNG PHÁP KANBAN
VÀ ÁP DỤNG PHÁT TRIỂN PHẦN MỀM
QUẢN LÝ CON DẤU
Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60.48.10

H Nô
̣
i – 2013


1
LỜI NÓI ĐẦU
Trong quá trình làm việc, tôi đã tham gia vào nhiều dự án tin học tại nơi công tác. Một
trong những điều tôi thấy rõ nhất ở các dự án, đó là tỉ lệ thành công thƣờng chƣa cao.
Rất nhiều dự án bị chậm tiến độ, không thoả mãn yêu cầu ngƣời sử dụng và trầm trọng

hơn là không đúng nghiệp vụ.Có thể kể ra đây một số nguyên nhân khiến cho dự án
không đƣợc thành công là: Quy trình quản lý dự án không tốt, công nghệ áp dụng lỗi
thời, khả năng của ngƣời phát triển có giới hạn và sự cộng tác với khách hàng không
đƣợc đảm bảo.
Xuất phát từ lý do đó nên tôi đã chọn nghiên cứu lĩnh vực quản lý dự án và các
phƣơng pháp phát triển phần mềm, với mục đích là làm sao giảm đƣợc rủi ro khi thực
hiện dự án, đƣa ra đƣợc sản phẩm có chất lƣợng cao nhất mà vẫn đảm bảo thực hiện
đúng tiến độ.
Trong luận văn này, tôi tập trung nghiên cứu phƣơng pháp phát triển phần mềm tiên
tiến hiện đang đƣợc chú ý của các nhà phát triển phần mềm trên thế giới, và áp dụng
phù hợp với điều kiện thực tế cơ quan mình đang công tác.
Tôi xin đƣợc gửi lời cảm ơn chân thành đến thầy giáo TS. Trƣơng Anh Hoàng đã tận
tình hƣớng dẫn, cảm ơn Văn phòng Công an tỉnh Tuyên Quang đã tạo điều kiện để tôi
có thể áp dụng thử nghiệm những kiến thức đƣợc nghiên cứu.

2
LỜI CAM ĐOAN

Tôi xin cam đoan rằng, ngoại trừ các nội dung đƣợc trích từ tài liệu tham khảo hoặc
các công trình khác nhƣ đã ghi rõ trong luận văn, các kết quả nêu trong luận văn này là
do chính tôi thực hiện và chƣa từng đƣợc ai công bố trong bất cứ công trình nào khác.
H Nội, tháng 11 năm 2013


Phạm Công Thiên Lý

3
MỤC LỤC
DANH MỤC CÁC BẢNG 5
DANH MỤC CÁC HÌNH VẼ 5

DANH MỤC CÁC TỪ VIẾT TẮT 5
Chƣơng 1. GIỚI THIỆU 7
1.1 Đặt vấn đề 7
1.2 Hƣớng tiếp cận của đề tài 7
1.3 Nội dung của luận văn 10
Chƣơng 2. TỔNG QUAN 12
2.1 Phƣơng pháp phát triển phần mềm linh hoạt 12
2.1.1 Lịch sử 12
2.2.2 Phƣơng pháp linh hoạt 14
2.2 Một số phƣơng pháp phát triển phần mềm linh hoạt tiêu biểu 16
2.2.1 Extreme Programming 16
2.2.2 Scrum 18
2.2.3 Phƣơng pháp phát triển phần mềm thích nghi 21
2.3 Kết chƣơng 23
Chƣơng 3. PHƢƠNG PHÁP KANBAN 24
3.1 Giới thiệu 24
3.2 Kanban là gì? 26
3.3 Quy trình Kanban 26
3.3.1 Trực quan quy trình làm việc của bạn 26
3.3.2 Giới hạn công việc đang tiến hành 28
3.3.3 Thiết lập các chính sách đảm bảo chất lƣợng 31
3.3.4 Đo dòng chảy 33
2.3.5 Ƣu tiên 38
3.3.6 Xác định các lớp dịch vụ 40
3.3.7 Quản lý lƣu lƣợng 43
3.3.8 Thiết lập thỏa thuận mức độ dịch vụ 45
3.3.9 Tập trung vào cải tiến liên tục 46
3.4 Kết chƣơng 47

4

Chƣơng 4. ÁP DỤNG PHƢƠNG PHÁP KABAN VÀO PHÁT TRIỂN PHẦN MỀM
QUẢN LÝ CON DẤU 49
4.1 Quy trình làm việc hiện tại 49
4.2 Phát triển phần mềm 51
4.2.1 Giai đoạn khảo sát 51
4.2.2 Giai đoạn lập kế hoạch 55
4.2.3 Giai đoạn phát triển 57
4.2.4 Giai đoạn đƣa ra sản phẩm 60
4.2.5 Giai đoạn bảo trì 61
4.2.6 Giai đoạn kết thúc 61
4.3 Thảo luận và đánh giá 61
4.4 Kết chƣơng 63
Chƣơng 5. KẾT LUẬN 65
TÀI LIỆU THAM KHẢO 67

5
DANH MỤC CÁC BẢNG
Bảng 4.1 – Đánh giá kết quả thử nghiệm 63

DANH MỤC CÁC HÌNH VẼ
Hình 2.1 Quy trình XP 17
Hình 2.2 Quy trình Scrum 19
Hình 2.3 Quy trình ASD 21
Hình 3.1: Ví dụ về bản đổ luồng giá trị mô tả 1 quy trình sản suất phần mềm 27
Hình 3.2: Quy trình làm việc đƣợc trực quan trên bảng 28
Hình 3.3 Trực quan các giới hạn công việc đang làm sử dụng việc đánh số trên tiêu đề
cột. 30
Hình 3.4: Kéo và đẩy 31
Hình 3.5: Chính sách rõ ràng hiển thị trên bảng 33
Hình 3. 6: Ví dụ về sơ đồ luồng tích lũy 34

Hình 3.7 Ví dụ về biểu đồ Cycle time 36
Hình 3.8 Ví dụ về biểu đồ tỷ lệ lỗi 37
Hình 3.9: Ví dụ về biểu đồ các hạng mục bị chặn. 38
Hình 3.10: Trực quan hạng mục bị chặn với nhãn mầu hồng 38
Hình 3.11 : Trực quan các chính sách ƣu tiên trên bảng 40
Hình 3.12: Trực quan các lớp dịch vụ sử dụng các thẻ màu khác nhau 43
Hình 4.1 Biểu đồ trạng thái UML mô tả quy trình làm việc 50
Hình 4.2 Trực quan quy trình làm việc hiện tại của nhóm làm việc 51
Hình 4. 3 Gắn thẻ công việc vào bảng 52
Hình 4.4 Thông tin chi tiết một thẻ công việc 53
Hình 4. 5 Trực quan giới hạn WIP. 56
Hình 4.6 Trực quan chính sách trên bảng 57
Hình 4. 7 Tách giai đoạn phát triển 58

6
Hình 4.8 Mô hình ca sử dụng ở mức cao 58
Hình 4.9 Mô hình ca sử dụng “Cấp phép khắc dấu” 59
Hình 4.10 Mô hình ca sử dụng “Tổng hợp tình hình quản lý con dấu” 60
Hình 4. 11 Biểu đồ luồng tích lũy số công việc ở mỗi giai đoạn phát triển 60
Hình 4.12 Quy trình làm việc sau khi áp dụng Kanban 62
Hình 4.13 Biểu đồ Cycle time 63

DANH MỤC CÁC TỪ VIẾT TẮT
Từ viết tắt
Thuật ngữ
Tiếng việt
ASD
Adaptive Software Development
Phát triển phần mềm thích nghi
XP

Extreme Programming
Lập trình cực hạn
WIP
Work In Progress
Công việc đang làm
UML
Unified Modeling Language
Ngôn ngữ mô hình hóa thống nhất
CFD
Cumulative Flow Diagrams
Sơ đồ luồng tích lũy
KPI
Key Performance Indicator
Chỉ số thực thi quan trọng
COD
Cost of Delay
Chi phí trễ



7
Chƣơng 1. GIỚI THIỆU
1.1 Đặt vấn đề
Ở Việt Nam hiện nay, có rất nhiều công ty đang sử dụng một trong các quy trình phần
mềm của phƣơng pháp linh hoạt (agile method) sản xuất phần mềm. Các phƣơng pháp
linh hoạt điển hình đƣợc áp dụng ở Việt Nạm hiện này là Scrum và eXtreme
Programming. Đây là hai phƣơng pháp truyền thống của phƣơng pháp linh hoạt. Và
hiện nay cộng đồng phát triển phần mềm sử dụng phƣơng pháp linh hoạt đang hƣớng
tới một số phƣơng pháp phát triển phần mềm mới hơn nhƣ Crystal, Dynamic Systems
Development, Feature-Driven Development và thêm nữa là phƣơng pháp Kanban.

Kanban dịch từ tiếng Nhật có nghĩa là thẻ thông tin [9] . Còn đúng chính xác thuật ngữ
chuyên môn của môn "Quản lý công học" và kinh tế học thì phải là "Phƣơng pháp
quản lý Kanban " (Kanban method ). Đây là một thuật ngữ bắt nguồn từ công ty chế
tạo xe hơi Toyota. Nói đến công ty Toyota thì ngoài vấn đề kỹ thuật đặc sắc của họ
phải nói đến phƣơng pháp quản lý rất hiệu quả của họ mà ngƣời Nhật gọi là "Phƣơng
thức quản lý Toyota", một phƣơng thức quản lý xí nghiệp thông minh tạo đòn bẩy phát
triển kinh tế của Nhật bản và là tiêu chuẩn quản lý xí nghiệp của các tập đoàn sản xuất
lớn của Nhật hiện tại. Phƣơng thức quản lý Toyota gồm có 2 trụ cột đó là "Phƣơng
thức quản lý KANBAN" và "Tự động hóa" [9].
Phƣơng pháp Kanban tại Toyota là 1 phƣơng tiện báo có nhu cầu, mô
̣
t phiếu yêu cầu
có khô
̉
giấy cơ
̃
A6, trong đo
́
có ghi đi
̣
a điê
̉
m lấy hàng, đi
̣
a điê
̉
m nhâ
̣
n hàng, tên và mã
số chi tiết hoă

̣
c sản phâ
̉
m cần có, số “Kanban”, tô
̉
ng số phiếu “Kanban”, ngày xuất
phiếu, lô
̣
trình và số lƣơ
̣
ng chi tiết đƣơ
̣
c xếp trong mô
̣
t thùng chƣ
́
a.
Vì vậy, trong khi hệ thống Kanban là một khái niệm tƣơng đối mới trong công nghệ
thông tin, nó đã đƣợc sử dụng cách đây hơn 50 năm trong hệ thống sản xuất Tinh gọn
(Lean production systems) ở Toyota. Việc sử dụng Kanban trong phần mềm đƣợc đi
tiên phong bởi David Anderson, ngƣời mà đã có sự phối hợp chặt chẽ với Don
Reinertsen, đã nỗ lực mở rộng các hiều biết về sản xuất Tinh gọn và sử dụng Kanban
để trực quan và tối ƣu hóa quy trình làm việc (workflow) trong phát triển, bảo trì và
các hoạt động của công nghệ thông tin. Với sự tập trung nhất quán vào dòng chảy
(flow) và bối cảnh (context), Kanban cung cấp một cách tiếp cận ít quy tắc cho
Phƣơng pháp linh hoạt và trở thành một phần mở rộng phổ biến cho các phƣơng pháp
truyền thống của phƣơng pháp linh hoạt nhƣ Scrum và XP.

1.2 Hƣớng tiếp cận của đề ti

8
Đề tài sẽ tập trung vào việc nghiên cứu ứng dụng quy trình phần mềm Kanban và áp
dụng phát triển phần mềm quản lý con dấu – phần mềm quản lý công tác nghiệp vụ
của ngành Công an.
Trong quá trình làm việc tại Văn phòng Công an tỉnh Tuyên Quang tôi đã tham gia
phát triển một số dự án phần mềm với quy mô từ nhỏ tới trung bình với vai trò ngƣời
phát triển.
Dự án đầu tiên là Hệ thống quản lý Vũ khí và Công cụ hỗ trợ trên địa bàn tỉnh Tuyên
Quang. Khách hàng là Phòng quản lý Hành chính Công an Tỉnh Tuyên Quang. Dự án
bắt đầu năm 2008 và kết thúc năm 2010, nhƣng đến nay Khách hàng sử dụng vẫn bị
khiếm khuyết và đƣơc bảo trì nhiều lần.
Dự án thứ hai là Hệ thống Quản lý Vật liệu nổ trên địa bàn tỉnh Tuyên Quang. Khách
hàng là phòng Phòng cháy chữa cháy Công an tỉnh Tuyên Quang. Dự án này đã không
đƣợc áp dụng vào thực tế do quy trình quản lý và quy trình nghiệp vụ của phòng ban
thay đổi, do đó các chức năng phần mềm không còn phù hợp nữa.
Dự án thứ ba là Hệ thống Quản lý vi phạm An toàn giao thông. Khách hàng là phòng
Cảnh sát Giao thông Công an tỉnh Tuyên Quang. Đây là một dự án mức trung bình,
với mục tiêu là xây dựng hệ thống xử phạt vi phạm hành chính an toàn giao thông
đƣờng bộ. Dự án này đƣợc triển khai thực tế từ đầu năm 2012, đến này đã bảo trì 3
lần.
Qua một số dự án đã triển khai, theo tôi các dự án này chƣa thành công. Còn nhiều vấn
đề tồn tại trong việc phát triển phần mềm cũng nhƣ việc phân phối phần mềm tới
ngƣời sử dụng. Và nguyên nhân chính dẫn đến dự án không thành công nằm ở phía
ngƣời quản lý và ngƣời phát triển dự án. Ngƣời quản lý không đƣa ra đƣợc một quy
trình làm việc hợp lý nhƣ:
- Hệ thống làm việc quá tải dẫn đến chất lƣợng sản phẩm thấp. Khi nhu cầu làm
việc và lƣu lƣợng công việc không cần bằng, có thể tạo ra một số tắc nghẽn
trong hệ thống, để kịp đƣa ra sản phẩm đúng tiến độ, một số tắc nghẽn có thể bị

bỏ qua hoặc đƣợc giải quyết không triệt để dẫn đến chất lƣợng của phần mềm
thấp.
- Các chính sách làm việc không rõ ràng dẫn đến các rủi ro trong hệ thống nhƣ:
công việc bị tắc nghẽn, việc phát triển bị phụ thuộc vào ngƣời phát triển. Một
hệ thống sản xuất phần mềm bao gồm nhiều nhóm làm việc. Sản phẩm cuối
cùng đƣợc tạo ra bởi sự kết hợp đồng bộ các phần công việc của mỗi nhóm. Để
các phần công việc của mỗi nhóm là đồng bộ thì phải có các chính sách rõ ràng
cho mỗi nhóm và mỗi giai đoạn của quy trình sản xuất. Khi có sự thay đổi về
nhân sự, việc phát triển tiếp công việc sẽ không bị phụ thuộc vào ngƣời trƣớc
đó, hệ thống sẽ không bị tắc nghẽn vì lý do này.

9
- Không đƣa ra đƣợc các dự đoán cho quy trình làm việc ảnh hƣởng đến thời hạn
phát hành. Tạo niềm tin với khách hàng là rất quan trọng. Khách hàng luôn
muốn chúng ta đƣa ra lời hứa về thời gian phát hành sản phẩm, và thời gian này
phải là ngắn nhất có thể. Vì vậy một quy trình làm việc tốt thì có thể đƣa ra
đƣợc các dự báo nhƣ: điểm tắc nghẽn, điểm cần ƣu tiên, và thời gian có thể
hoàn thành xong một hạng mục công viêc. Từ các dự bào này ngƣời quản lý có
thể dự đoán đƣợc thời gian phát hành sản phẩm cho khách hàng.
- Quy trình làm việc không trực quan làm cho các bên liên quan nhƣ khách hàng,
chủ sở hữu sản phẩm, ngƣời phát triển… phối hợp với nhau không tốt. Trong
quá trình làm việc, ngƣời quản lý luôn phải biết nhân viên của mình có đang
làm việc hiệu quả không, các thành viên luôn phải kết hợp làm việc cùng nhau.
Và khách hàng luôn muốn biết sản phẩm có đúng nhƣ yêu cầu của mình không.
Khi quy trình làm việc luôn đƣợc nhìn thấy trƣớc măt (giả sử đƣợc ghi rõ trên
một tấm bảng), thì tất cả mọi ngƣời có thể nhìn thấy ai đang làm việc gì, việc đó
đang ở vị trì nào trong giai đoạn phát triển, chỗ nào bị tắc nghẽn.
Có thể rút ra đƣợc một số kinh nghiệm khi triển khai các dự án trên là:
- Việc liên hệ với khách hàng thƣờng xuyên là điều rất quan trọng, bởi khách
hàng là ngƣời am hiểu nghiệp vụ nhất, đồng thời họ biết những gì mà phần

mềm phải đáp ứng. Ngoài ra khách hàng đóng vai trò quan trọng trong việc
kiểm thử phần mềm, phát hiện lỗi cũng nhƣ các chức năng không phù hợp.
- Việc quản lý dự án phải đƣợc chú trọng. Để làm đƣợc điều này, ngƣời quản lý
cần có kinh nghiệm, khả năng lập kế hoạch tốt và nhanh nhạy trong việc xử lý
các tình huống.
- Cần phải có một quy trình phát triển phần mềm hiệu quả. Quy trình tốt sẽ làm
tăng khả năng làm việc của các thành viên trong nhóm, chuẩn hóa các tài liệu,
từ đó giảm bớt các tác động tiêu cực khi đội ngũ phát triển thay đổi.
Từ việc rút ra các điều trên, trong một dự án mà chúng tôi đang triển khai, tôi quyết
định thử nghiệm đƣa nhóm làm việc của mình vào một quy trình làm việc hoàn toàn
mới bằng cách áp dụng phƣơng pháp linh hoạt, mà cụ thể là phƣơng pháp Kanban vào
hệ thống phân phối phần mềm của chúng tôi.
Do đó đề tài sẽ tiếp cận theo hƣớng nghiên cứu quy trình phần mềm Kanban và áp
dụng phát triển phần mềm quản lý con dấu.
Đây là phần mềm quản lý việc cấp và sử dụng con dấu trên toàn bộ địa bàn của tỉnh
Tuyên Quang. Công tác quản lý con dấu của các cơ quan nhà nƣớc, tổ chức chính trị, tổ
chức chính trị - xã hội, tổ chức xã hội - nghề nghiệp, hội quần chúng, tổ chức kinh tế,
đơn vị vũ trang, cơ quan, tổ chức nƣớc ngoài v.v, đƣợc lực lƣợng chuyên trách của Công
an tiến hành bằng phƣơng pháp thủ công. Hệ thống hồ sơ này tuy đƣợc rà soát, bổ sung

10
thƣờng xuyên nhƣng qua quá trình công tác số lƣợng các hồ sơ, sổ sách này trải qua
nhiều thời kỳ, nhiều cán bộ theo dõi quản lý cho nên việc tìm kiếm các hồ sơ, ghi nhận
các thông tin về con dấu gây mất rất nhiều thời gian, độ chính xác chƣa cao. Trong thực
tế công tác luôn có những yêu cầu đặt ra đối với công tác quản lý con dấu nhƣ:
- Tra cứu tìm kiếm thông tin về toàn bộ hồ sơ hoặc thông tin của một con dấu cụ
thể;
- Thống kê xem cơ quan, tổ chức có bao nhiêu con dấu, đã huỷ, đổi bao nhiêu
lần; vấn đề cấp phép sử dụng cho các con dấu;
- Báo cáo, so sánh số liệu về con dấu của các cơ quan, tổ chức theo các mốc thời

gian khác nhau;
- Xem trực tiếp trích yếu các các mẫu dấu trong hồ sơ lƣu trữ.
- Vị trí hồ sơ con dấu của cơ quan tổ chức nằm ở đâu trong kho hồ sơ (phục vụ
việc tra cứu trực tiếp).
- Con dấu tại thời điểm sử dụng đã đã hết hạn hay chƣa (có trƣờng hợp dấu đã
hết hạn, đổi nhƣng không làm thủ tục huỷ theo quy định mà vẫn sử dụng).
- Truy nguyên nhanh mẫu dấu đang sử dụng có phải là con dấu đã đƣợc phép sử
dụng hay chƣa.
Khi gặp những yêu cầu nhƣ trên, nếu bằng phƣơng pháp quản lý thủ công nhƣ hiện
nay để tìm ra đƣợc câu trả lời nhanh chóng, chính xác sẽ mất rất nhiều thời gian để tìm
kiếm trong hệ thống hồ sơ đã lƣu trữ, thậm chí có thể không tìm ra đƣợc câu trả lời
chính xác bởi vì hồ sơ các con dấu rất nhiều, đƣợc lƣu trong nhiều sổ sách, dẫn đến
khó tìm kiếm hoặc tìm kiếm không chính xác. Từ đó yêu cầu một công cụ điện tử có
thể nhanh chóng đáp ứng những yêu cầu trên.
1.3 Nội dung của luận văn
Phần còn lại của luận văn sẽ bao gồm các chƣơng sau:
Chƣơng 2, trình bày tổng quan về phƣơng pháp phát triển phần mềm linh hoạt, và giới
thiệu chung nhất một số phƣơng pháp phát triển phần mềm truyền thống của phƣơng
pháp phát triển phần mềm linh hoạt. Các phƣơng pháp đƣợc giới thiệu bao gồm:
Extreme Programming, Scrum và Adaptive Software Development.
Chƣơng 3, trình bày chi tiết một phƣơng pháp phát triển phần mềm mới ra đời của
phƣơng pháp linh hoạt – Phƣơng pháp Kanban
Dựa trên những kiến thức nghiên cứu đƣợc trong chƣơng 3 đƣợc áp dụng thử nghiệm
phƣơng pháp Kanban để phát triển 1 phần mềm – Phần mềm quản lý con dấu tại Công
an tỉnh Tuyên Quang. Chƣơng này trình bày chi tiết các giai đoạn phát triển phần mềm
có áp dụng phƣơng pháp Kanban và kết quả đánh giá của quá trình thử nghiệm.

11
Cuối cùng là Chƣơng 5, đƣa ra kết luận cho toàn bộ quá trình nghiên cứu đề tài.

12
Chƣơng 2. MỘT SỐ KIẾN THỨC NỀN TẢNG
2.1 Phƣơng pháp phát triển phần mềm linh hoạt
2.1.1 Lịch sử
Phƣơng pháp linh hoạt là một sự đối lập với các phƣơng pháp truyền thống trong phát
triển phần mềm và “là sự cần thiết để thay thế cho quy trình hƣớng tài liệu, một hƣớng
nặng trong quy trình phát triển phần mềm” [3]. Trong việc thực hiện các phƣơng pháp
truyền thống, công việc bắt đầu với việc đặc tả các yêu cầu, tiếp theo là thiết kế kiến
trúc, phát triển, và kiểm thử. Bắt đầu vào những năm 1990, một vài nhà phát triển nhận
ra rằng những bƣớc phát triển ban đầu gây cản trở các bƣớc sau [11]. Ngành công
nghiệp và công nghệ phát triển quá nhanh, các yêu cầu thay đổi với “tốc độ làm quá tải
các phƣơng pháp truyền thống” [11], và các khách hàng ngày càng trở lên thiếu dứt
khoát với các yêu cầu của họ trong các lần gặp đầu tiên. Kết quả là, một số chuyên gia
tƣ vấn có các phƣơng pháp phát triển độc lập để đáp ứng với sự thay đổi tất yếu mà họ
đã trải qua. Các phƣơng pháp linh hoạt thực sự là một bộ sƣu tập các kỹ năng khác
nhau, chia sẻ các giá trị và các nguyên lý cơ bản. Ví dụ vào những năm 1975, một kỹ
thuật dựa trên vòng lập tăng cƣờng đƣợc sử dụng nhiều [21].
Việc cải tiến quy trình phần mềm là một sự tiến hóa trong đó việc xây dựng các quy
trình mới hơn dựa trên các thất bại và thành công của những cái đi trƣớc đó, vì vậy để
thực sự hiểu bƣớc đi linh hoạt, chúng ta cần xem xét các phƣơng pháp ra đời trƣớc nó.
Mô hình thác nƣớc [16] ra đời đầu tiên, là cách để đánh giá và xây dựng các nhu cầu
ngƣời sử dụng. Nó bắt đầu với một tập các phân tích đầy đủ các yêu cầu ngƣời sử
dụng. Qua vài tháng làm việc căng thẳng với ngƣời sử dụng và khách hàng, các kỹ sƣ
sẽ thiết lập một tập các yêu cầu chức năng và phi chức năng đầy đủ và dứt khoát
(không thêm bớt gì nữa). Các thông tin này đƣợc tài liệu cho các giai đoạn tiếp theo đó
là thiết kế, ở đó các kỹ sƣ phối hợp với những ngƣời khác, chẳng hạn nhƣ với các
chuyên gia cấu trúc dữ liệu và cơ sở dữ liệu, để tạo ra một kiến trúc tối ƣu cho hệ
thống. Tiếp theo các lập trình viên thực thi các các thiết kế đã đƣợc tài liệu này, và
cuối cùng, một hệ thống đƣợc thiết kế xong, hoàn hảo đƣợc kiểm thử và phát hành[4]
Quy trình này trên lý thuyết là tốt, nhƣng thực tế nó không luôn luôn là cách làm việc

hay nhƣ viết ở trên. Thứ nhất là, ngƣời sử dụng thay đổi các ý định của họ. Sau nhiều
tháng, hoặc thậm chí hàng năm, thu thập các yêu cầu và xây dựng các sơ đồ và mô
hình thử nghiệm, ngƣời dùng vẫn không chắc chắn về những gì họ muốn – Những cái
họ nhìn thấy đƣợc trong sản phẩm là nó không đƣợc tốt. Thứ hai là các yêu cầu có xu
hƣớng thay đổi khi đang phát triển giữa chừng và khi các yêu cầu đƣợc thay đổi, khó
thích nghi với các thay đổi.
Các kỹ thuật gia tăng và lặp tập trung vào việc phân rã chu kỳ phát triển thánh các
phần nhỏ hơn đƣợc tiến hóa từ mô hình thác nƣớc [4], lấy quy trình phía sau của mô

13
hình thác nƣớc và lặp đi lặp lại nó trong suốt vòng đời phát triển. Phát triển gia tăng
nhằm giảm thời gian phát triển bằng cách phân rã dự án thành các phiên bản gia tăng
gối lên nhau. Đối với mô hình thác nƣớc, tất cả các yêu cầu đƣợc phân tích trƣớc khi
phát triển bắt đầu; tuy nhiên, các yêu cầu này sau đó đƣợc chia thành các gia tăng của
các chức năng độc lập. Việc phát triển mỗi gia tăng có thể đƣợc chồng lên nhau, do đó
tiết kiệm đƣợc thời gian xử lý đồng thời trên toàn bộ dự án.
Trong khi phát triển gia tăng xem xét việc tiết kiệm thời gian, thì các phƣơng pháp tiên
tiến nhƣ phát triển lặp và mô hình xoắn ốc [6] nhằm mục tiêu xử lý các yêu cầu thay
đổi và quản lý rủi ro tốt hơn. Các mô hình này đánh giá các nhân tố quan trọng trong
cách lập kế hoạch và cấu trúc ở nhiều thời điểm trong quy trình hơn là cố gắng giảm
thiểu khi chúng xuất hiện trong dự án.
Phát triển lặp phân rã dự án thành các bƣớc lặp có độ dài thay đổi, mỗi lần sản xuất
một sản phẩm hoàn chỉnh và xây dựng trên mã và tài liệu của sản phẩm trƣớc đó.
Phiên bản đầu tiên bắt đầu với sản phẩm cơ bản nhất, và mỗi lần lặp tiếp theo sẽ thêm
vào các tập chức năng hợp lý. Mỗi phần nhỏ là một quy trình thác nƣớc của mình với
phân tích, sau đó là thiết kế, thực thi, và cuối cùng là kiểm thử. Phát triển lặp đối phó
tốt với sự thay đổi, nhƣ chỉ các dùng yêu cầu hoàn chỉnh cho phiên bản hiện tại. Mặc
dù các yêu cầu dự kiến cần phải trong phiên bản tiếp theo, chúng không cần có mặt
trọng phiên bản hiện tại cho đến giai đoạn phân tích tiếp theo. Cách tiếp cận này cho
phép thay đổi công nghệ hoặc khách hàng thay đổi dự định của mình với tác động nhỏ

nhất trên đà của dự án.
Tƣơng tự, mô hình xoắn ốc tránh việc chi tiết và xác định toàn bộ hệ thống trƣớc.
Không giống nhƣ phát triển lặp, trong mô hình này hệ thống đƣợc xây dựng từng phần
bằng cách ƣu tiên hóa từng phần theo chức năng, nó ƣu tiên các yêu cầu theo rủi ro.
Mô hình xoắn ốc và phát triển lặp cũng là một bƣớc nhảy vọt với sự linh hoạt thông
qua quy trình thác nƣớc, nhƣng một số ngƣời nghĩ rằng họ vẫn không đáp ứng đƣơc để
thay đổi linh hoạt cần thiết trong sự phát triển thế giới kinh doanh.
Một mô hình khác là mô hình trƣởng thành (CMM) [14], “một mô hình mức 5 mô tả
thực tiễn quản lý, kỹ thuật và quy định các ƣu tiên cải tiến cho tổ chức phần mềm”
[14]. Mô hình xác định 18 khu vực quan trọng của quy trình và 52 mục tiêu cho một tổ
chức để trở thành một tổ chức mức 5. Hầu hết mức độ trƣởng thành của các tổ chức
phần mềm là hỗn độn (CMM mức 1) và chỉ một vài tổ chức đƣớc “tối ƣu” (CMM mức
5). CMM tập trung chủ yếu vào các dự án lớn và các tổ chức lớn, nhƣng có thể đƣợc
thay đổi để phù hợp với các dự án vừa và nhỏ do thực tế nó đƣợc xây dựng một cách
chung phù hợp với nhu cầu của các tổ chức đa dạng. Mục tiêu của CMM là đạt đƣợc
quy trình thống nhất, có khả năng dự đoán, và có độ tin cậy [15].
Mặc dù CMM tập trung vào việc phát triển phần mềm thành quy trình có thể dự đoán,
xác định và có thể lặp đƣợc, nhƣng các nhà khoa học phát hiện ra rằng nhiều cái trong
quy trình thực tế phần lớn không dự đoán trƣớc và không thể lăp lại bởi vì [18]:

14
 Quy trình này chỉ mới bắt đầu đƣợc tìm hiểu
 Quy trình này quá phức tạp
 Quy trình đang biến đổi và không thể dự đoán đƣợc
Schwaber, ngƣời phát triển Scrum, nhận ra rằng để thực sự linh hoạt, một quy trình
cần phải chấp nhận thay đổi chứ không phải là khả năng dự đoán [18]. Các chuyên gia
nhận thấy rằng các phƣơng pháp đáp ứng đƣợc với sự thay đổi nhanh chóng là cần
thiết, và trong môi trƣờng năng động, “sự sáng tạo, là cách duy nhất để quản lý các
vấn đề của phát triển phần mềm phức tạp” [7].
Các chuyên gia nhƣ Mary Poppendieck và Bob Charette cũng bắt đầu tìm kiếm các

nguyên lý kỹ thuật khác cho quy trình, chuyển sang một trong những xu hƣớng công
nghiệp đổi mới lúc bấy giờ, đó là sản xuất Tinh gọn (Lean Manufacturing). Bắt đầu
sau chiến tranh thế giới thứ 2 bởi Toyoda Sakichi, nó không đƣợc phố biến cho đến
đầu những năm 1980. Trong khi các nhà máy sản xuất ở Mỹ chạy 100% công suất của
máy sản xuất và có một đống hàng tồn kho khổng lồ của cả sản phẩm và vật tƣ, thì
Toyota chỉ giữ đủ nguồn cung trong tay để chạy nhà máy trong một ngày, và chỉ sản
xuất đủ sản phẩm của đơn hàng hiện tại.
Năm 2000, dự án đầu tiên của Beck và Jeffries sử dụng phƣơng pháp eXtreme
Programming [11] ra đời và thu về thành công ngoài mong đợi.
Cũng vào năm 2000, Cockburn đã sử dụng những gì mà ông học đƣợc ở IBM để phát
triển phƣơng pháp Crystal [11].
2.2.2 Phƣơng pháp linh hoạt
Các phƣơng pháp phát triền linh hoạt đƣợc gọi với cái tên tiếng anh là Agile, có nghĩa
là nhanh nhẹn, linh hoạt, khéo léo trong hành động, là các phƣơng pháp dựa trên các
quy trình phát triển nhanh. Điều này đặc biệt cần thiết trong lĩnh vực Internet và truyền
thông di động đang phát triển nhanh chóng.
Các dự án phát triển theo các phƣơng pháp linh hoạt dựa trên các giá trị thƣơng mại,
quy trình thực hiện dự án đƣợc dựa trên việc đáp ứng thực tế hơn là theo kế hoạch.
Việc quản lý rủi ro đạt đƣợc bởi sự cộng tác chặt chẽ với khách hàng, giảm chu kỳ
phát hành và tập trung vào ƣu tiên các chức năng quan trọng trƣớc.
Tuyên ngôn của phƣơng pháp linh hoạt đƣợc đƣa ra bởi một nhóm hoạt động trong
lĩnh vực phần mềm vào năm 2001. Những ngƣời mà đại diện cho các phƣơng pháp
nhƣ Extreme Programming (XP), Scrum, Crystal và các phƣơng pháp khác cùng thống
nhất đƣa ra một bản tuyên ngôn. Nội dung bản tuyên ngôn có những điểm chính sau:

15
“Chúng ta dần phát hiện ra những cách phát triển phần mềm tốt hơn bằng cách thực
hiện nó và giúp ngƣời khác thực hiện nó. Qua công việc này, chúng ta thu đƣợc các
giá trị:
 Các cá nhân và sự tƣơng tác với nhau quan trọng hơn các quy trình và các

công cụ.
 Làm phần mềm quan trọng hơn việc lập tài liệu.
 Việc hợp tác với khách hàng quan trọng hơn việc ký kết hợp đồng.
 Đáp ứng thay đổi quan trọng hơn việc theo một kế hoạch.
Trong đó những thành phần bên phải là quan trọng, nhƣng chúng ta coi trọng những
thành phần bên trái hơn.” [3].
Tuyên ngôn này đã trở thành một phần quan trong cho phong trào các phƣơng pháp
linh hoạt, đặc trƣng của nó là các giá trị và các phƣơng pháp này khác với các phƣơng
pháp truyền thống nhƣ thế nào. Câu đầu tiên cho thấy, chúng ta không phải lúc nào
cũng có giải pháp cho mọi thứ, mà giải pháp nằm chính bên trong của công việc. Và
để tìm đƣợc giải pháp, thì không thể chỉ dựa vào các lý thuyết mà phải trực tiếp làm
công việc phát triển phầm mềm. Những câu sau gồm hai phần, phần bên phải có giá trị
ít hơn phần bên trái mặc dù điều này không có nghĩa là phần bên trái không quan
trọng. Chúng ta sẽ xem ý nghĩa của từng câu.
Giá trị 1 cho thấy những quy trình và công cụ là quan trọng. Sẽ không thể phát triển
một phần mềm tốt nếu không có quy trình và công cụ tốt, vì lẽ đó nên dùng công cụ tốt
nhất hiện có. Nhƣng điều mà bản tuyên ngôn muốn nhấn mạnh là vai trò của từng cá
nhân và mối quan hệ của các cá nhân với nhau trong đội ngũ phát triển phần mềm.
Đối với một dự án thành công, thì cần phải lập tài liệu một cách đầy đủ. Nhƣng bản
thân tài liệu sẽ không giúp đƣợc gì nếu không có sản phẩm thực sự. Vì thế, việc tạo ra
sản phẩm phần mềm quan 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.
Việc ký kết hợp đồng là quan trọng nhƣng không đủ. 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 giải pháp tốt nhất cho khách hàng. Các hợp
đồng định nghĩa những điều khoản ràng buộc mà trong đó cả hai phía đối tác đều phải
tuân theo, nhƣng những ngƣời phát triển cần hợp tác với khách hàng để có thể hiểu rõ
yêu cầu cũng nhƣ những gì cần phải đƣa ra.
Và cuối cùng, chúng ta thấy là việc lập kế hoạch là không thể thiếu. Kế hoạch giúp
công việc đƣợc định hƣớng tốt hơn. Tuy nhiên thực tế có rất nhiều thay đổi, và cứ nếu
nhất nhất tuân theo kế hoạch thì có thể sẽ dẫn đến thất bại. Do đó cần phải đáp ứng

những thay đổi để có thể điều chỉnh sao cho phù hợp.

16
Ở đây không có sự mâu thuẫn giữa các phƣơng pháp truyền thống và các phƣơng pháp
phát triển nhanh. Vấn đề làở chỗ nhữngđiều mà các phƣơng pháp phát triển nhanh và
các phƣơng pháp truyền thống chú trọng vào là khác nhau. Điểm chính của các
phƣơng phát phát triển nhanh là việc đáp ứng thay đổi trong khi các phƣơng pháp
truyền thống tập trung vào kế hoạch.
2.2 Một số phƣơng pháp phát triển phần mềm linh hoạt tiêu biểu
Hiện nay, đã có nhiều phƣơng pháp phát triển linh hoạt đƣợc đề xuất và áp dụng. Mỗi
phƣơng pháp có một cách tiếp cận khác nhau, đƣa ra những quy trình, các hƣớng dẫn
thực hiện riêng. Nhƣng chung nhất, các phƣơng pháp này đều có những tính chất đã
đƣợc tuyên bố trong bản tuyên ngôn về các phƣơng pháp phát triển nhanh nhƣ: tính
tƣơng tác cao, coi trọng vai trò khách hàng, khả năng đáp ứng thay đổi nhanh. Phần
này sẽ giới thiệu một số phƣơng pháp phát triển phần mềm tiêu biểu thuộc lớp các
phƣơng pháp phát triển linh hoạt, bao gồm ExtremeProgramming (XP), Scrum và
Adaptive Software Development (ASD). Các phƣơng pháp này là các phƣơng pháp
truyền thống của linh hoạt. Chúng đã đƣợc áp dụng nhiều ở Việt Nam, và có nhiều tài
liệu tham khảo. Do đó phần này chỉ giới thiệu qua quy trình của các phƣơng pháp trên
và tập trung vào nghiên cứu một phƣơng pháp Kanban – một phƣơng pháp linh hoạt
mới hơn vào chƣơng sau.
2.2.1 Extreme Programming
Extreme Programming (XP) là một trong những phƣơng pháp phát triển linh hoạt tiêu
biểu nhất. Phƣơng pháp này đƣợc đề xuất và áp dụng từ khi cách tiếp cận linh hoạt còn
chƣa phổ biến rộng rãi. XP ra đời từ thực tiễn muốn khắc phục các vấn đề gặp phải
trong các cách tiếp cận truyền thống có chu kỳ phát triển phần mềm dài nhƣ phần mềm
không đáp ứng yêu cầu khách hàng, khả năng áp dụng của sản phẩm thấp, hay không
đảm bảo tiến độ thực hiện. Dựa trên những kinh nghiệm thực tế đã có từ trƣớc, cộng
với những thành công qua quá trình áp dụng thử nghiệm, XP đã đƣợc tổng quát lên
thành lý thuyết với một loạt các nguyên lý và các bài học thực tiễn.

Theo mô tả của Beck’s [5] vòng đời quy trình XP gồm các giai đoạn: khảo sát, lập kế
hoạch, vòng lặp phát triển, đƣa ra sản phẩm, bảo trì và kết thúc dự án.
2.2.1.1 Giai đoạn khảo sát
Trƣớc khi bắt đầu việc phát triển, nhóm phát triển cần đánh giá và phải đảm bảo năng
lực thực hiện dự án, bao gồm những yếu tố nhƣ nhân lực, kỹ năng, công nghệ, thời
gian.
Trong giai đoạn này, các khách hàng viết ra các yêu cầu mà họ muốn có trong phiên
bản đầu tiên. Mỗi yêu cầu này tƣơng ứng với một chức năng của chƣơng trình. Tuy
nhiên việc này không phải lúc nào cũng diễn ra suôn sẻ. Việc chậm trễ thƣờng xuyên

17
xảy ra do khách hàng có thể biết những gì mà những ngƣời lập trình cần, nhƣng khó
biết đƣợc những gì mà ngƣời lập trình không cần.
Song song với đó, các thành viên dự án làm quen với các công cụ, công nghệ và cách
sẽ làm việc trong dự án. Cần xây dựng một mô hình nguyên mẫu cho hệ thống nhằm
kiểm tra công nghệ đƣợc sử dụng và khảo sát các kiến trúc có thể của hệ thống. Giai
đoạn khảo sát kéo dài từ vài tuần đến vài tháng, phụ thuộc nhiều vào mức độ quen
thuộc công nghệ của các lập trình viên.

Hình 2.1 Quy trình XP
2.2.1.2 Giai đoạn lập kế hoạch
Mục đích của giai đoạn lập kế hoạch là cho phép khách hàng và những ngƣời phát
triển thoả thuận một ngày đƣa ra những chức năng quan trọng nhất. Công việc phải
thực hiện là thiết đặt mức độ ƣu tiên cho các yêu cầu và thống nhất nội dung của phiên
bản đầu tiên. Đầu tiên, các lập trình viên sẽ ƣớc lƣợng công sức cần để giải quyết các
yêu cầu, sau đó thống nhất lịch trình làm việc. Thời gian cho lịch trình của phiên bản
đầu tiên trong khoảng từ hai đến sáu tháng. Việc lập kế hoạch kéo dài một vài ngày.
2.2.1.3 Các vòng lặp phát triển
Lịch trình đƣợc thiết lập trong giai đoạn lập kế hoạch đƣợc chia nhỏ thành một vài
vòng thời gian kéo dài từ một đến bốn tuần. Ở vòng lặp đầu tiên, cần tạo ra một hệ

thống có kiến trúc của hệ thống tổng thể. Việc này đƣợc thực hiện bằng cách chọn các
nhiệm vụ mà buộc phải xây dựng kiến trúc cho hệ thống tổng thể. Tại mỗi vòng lặp
khách hàng quyết định nhiệm vụ cho mỗi vòng lặp, và ở cuối mỗi vòng lặp, các kết
quả đƣợc đƣợc đƣa ra và đƣợc tiến hành kiểm thử chức năng.

18
Kết thúc vòng lặp cuối, hệ thống sẵn sàng chuyển sang giai đoạn đƣa ra sản phẩm đầu
tiên.
2.2.1.4 Giai đoạn đƣa ra sản phẩm
Ở giai đoạn này, các sản phẩm đƣợc kiểm thử song song, và có thể vẫn có những thay
đổi. Những thay đổi này đƣợc ghi nhận và áp dụng cho phiên bản hiện thời hoặc phiên
bản kế tiếp.
Ngoài ra, trong giai đoạn này cần phải tiến hành cải tiến hiệu năng, tối ƣu hoá chƣơng
trình. Và công việc chính đó là chuyển giao sản phẩm cho khách hàng và bắt đầu đƣa
vào vận hành.
2.2.1.5 Bảo trì
Sau khi phiên bản đầu tiên đƣợc chuyển giao cho khách hàng sử dụng, dự án XP phải
đồng thời duy trì hoạt động của sản phẩm và bắt đầu những vòng lặp mới. Để làm điều
này, giai đoạn bảo trì đòi hỏi công sức cho việc hỗ trợ khách hàng. Do đó, tốc độ phát
triển có thể chậm lại. Giai đoạn bảo trì có thể yêu cầu phải kết nạp thêm các thành viên
mới vào đội dự án và thay đổi cấu trúc đội.
2.2.1.6 Kết thúc
Khi khách hàng không còn nhiệm vụ nào cần thực hiện nữa. Các yêu cầu mà hệ thống
phục vụ khách hàng cần thoả mãn trên các phƣơng diện nhƣ tính năng, độ tin cậy
Trong giai đoạn này, cần hoàn thiện các tài liệu cần thiết về hệ thống khi không có
thêm sự thay đổi về kiến trúc, thiết kế hay mã nguồn. Ngoài ra, cũng có thể tiến hành
kết thúc khi hệ thống không đƣa ra đƣợc đầu ra mong muốn, hay sẽ rất tốn kém nếu
phát triển tiếp.
2.2.2 Scrum
Thuật ngữ “Scrum” đƣợc trình bày lần đầu tiên trong bài báo của Takeuchi và Nonaka

[20] về khả năng thích nghi, nhanh chóng, tính tự tổ chức trong việc phát triển phần mềm.
Scrum đƣợc biết đến nhƣ là một phƣơng pháp quản lý nâng cao, áp dụng cho các hệ
thống hiện có. Do đó, có thể áp dụng Scrum với các phƣơng pháp phát triển phần mềm
khác.
Ý tƣởng chính của Scrum là cho rằng việc phát triển một hệ thống cần phải quản lý
một loạt các đại lƣợng nhƣ các yêu cầu, thời gian, tài nguyên hay công nghệ dùng để
phát triển, mà những đại lƣợng này hoàn toàn có thể thay đổi trong quá trình phát
triển. Từ đó cho thấy quá trình phát triển dự án mang tính không ổn định, phức tạp,
khó dự đoán trƣớc. Do đó cần thiết phải có một quy trình phát triển có tính linh hoạt
cao để có thể đáp ứng đƣợc những thay đổi này, và sản phẩm đầu ra phải có tính ứng
dụng cao, đáp ứng đƣợc yêu cầu khách hàng

19
Scrum là một phƣơng pháp hƣớng quy trình. Quy trình Scrum chia thành ba giai đoạn,
giai đoạn bắt đầu và lập kế hoạch, giai đoạn phát triển, và giai đoạn kết thúc và đƣa ra
sản phẩm [18]

Hình 2.2 Quy trình Scrum
2.2.2.1 Giai đoạn bắt đầu v lập kế hoạch
Trƣớc khi dự án bắt đầu, tất cả các yêu cầu hệ thống đƣợc liệt kê và tập hợp dƣới dạng
các phiếu công việc, đƣợc gọi là các Backlog. Tập hợp các phiếu công việc của toàn
bộ sản phẩm đƣợc gọi là Product Backlog. Product Backlog cho ta cái nhìn tổng thể về
các chức năng của sản phẩm cuối cùng. Các yêu cầu này có thể thu đƣợc từ khách
hàng, từ bộ phần bán hàng hay từ những ngƣời phát triển phẩn mềm. Ngƣời tạo ra
Product Backlog đƣợc gọi là Product Owner (ngƣời sở hữu), thông thƣờng là khách
hàng, hoặc là ngƣời quản lý trong công ty. Tiếp theo, các yêu cầu này đƣợc xác định
độ ƣu tiên và ƣớc lƣợng nhân lực cần thiết để cài đặt các tính năng yêu cầu. Danh sách
này liên tục đƣợc cập nhật thêm các mục mới cũng nhƣ đƣợc xác định lại độ ƣu tiên
cho các công việc và ƣớc lƣợng nhân lực, tài nguyên sao cho chính xác hơn.
Trong giai đoạn này còn phải đƣa ra đƣợc nhóm dự án, các công cụ và tài nguyên cần

thiết, đánh giá rủi ro và tiến hành đào tạo nếu thấy cần thiết. Ngoài ra, thiết kế tổng
thể cũng phải đƣợc định nghĩa trong giai đoạn này.
Trƣớc khi tiến hành phát triển, ngƣời sở hữu chọn những công việc cần tiến hành trong
vòng lặp đầu tiên của giai đoạn phát triển. Các công việc này đƣợc tập hợp dƣới một
danh sách gọi là Sprint Backlog. Trong khi đó, nhóm phát triển chuẩn bị những gì cần
thiết và ƣớc lƣợng thời gian sao cho công việc có thể hoàn thành trong vòng 30 ngày,
là khoảng thời gian một vòng lặp đƣợc quy định bởi Scrum. Việc thống nhất kế hoạch
giữa ngƣời sở hữu và nhóm phát triển đƣợc tiến hành trong một cuộc họp.

20
Công việc cuối cùng là xác định mục tiêu phải hoàn thành trong vòng lặp, gọi là Sprint
Goal. Việc xác định mục tiêu này để cho đội phát triển thấy đƣợc lý do của những
công việc mình phải làm.
2.2.2.2 Giai đoạn phát triển
Toàn bộ giai đoạn phát triển đƣợc phân thành các vòng lặp, mỗi vòng lặp kéo dài 30
ngày, gọi là Sprint. Trong mỗi vòng lặp, các thành viên của dự án chọn các công việc
từ Sprint Backlog, làm việc sao cho đạt đƣợc mục tiêu đề ra trong Sprint Goal. Trong
vòng lặp, các công việc lại đƣợc chia thành các khoảng thời gian nhỏhơn:
 Phát triển – Tiến hành phân tích, thiết kế, cài đặt, kiểm thử và viết tài liệu cho
những chức năng đƣợc lựa chọn.
 Đóng gói – Tạo bộ cài đặt của sản phẩm đến thời điểm hiện thời.
 Xem lại – Tất cả các thành viên trong nhóm họp với nhau để cùng xem xét lại
để đƣa ra cách giải quyết những vấn đề gặp phải.
 Điều chỉnh – Tổng hợp các thông tin thu đƣợc từ cuộc họp và tiến hành điều
chỉnh.
Trong giai đoạn này, các thành viên gặp nhau trong cuộc họp hàng ngày. Cuộc họp
này nên kéo dài trong khoảng 15 phút. Trong cuộc họp, các thành viên trong nhóm
phải đƣa ra đƣợc:
 Những gì đã lm đƣợc từ lần họp trƣớc.
 Dự định lm gì cho tới lần họp tiếp theo.

 Có gặp vƣớng mắc gì không.
Việc tiến hành họp hàng ngày sẽ giúp cho việc nắm bắt rõ hiện trạng công việc, đồng
thời tăng cƣờng việc liên hệ giữa các thành viên trong nhóm.
Để giảm tác động của việc thay đổi, Scrum đƣa ra nguyên tắc là mọi thay đổi trong
một Sprint đƣợc ghi nhận nhƣng không đƣợc áp dụng ngay. Điều này có nghĩa là trong
một vòng lặp, các công việc chỉ ra trong Sprint Backlog đƣợc cố định. Mặc dù điều
này có vẻ không phù hợp với tiêu chí đáp ứng thay đổi nhanh của các phƣơng pháp
phát triển nhanh, nhƣng là cần thiết vì mọi thứ thay đổi liên tục, nếu thay đổi ngay lập
tức theo yêu cầu có thể dẫn đến tình trạng lộn xộn.
Cuối mỗi vòng lặp, các kết quả đƣợc thể hiện cho ngƣời sở hữu, ngƣời quản lý và
những ai quan tâm. Dựa vào đó, ngƣời sở hữu phải chuẩn bị để đƣa ra những tính năng
cần thiết phải cài đặt trong vòng lặp kế tiếp. Nếu toàn bộ các chức năng đã hoàn
thành, thì dự án bƣớc sang giai đoạn cuối là đƣa ra sản phẩm.

21
2.2.2.3 Giai đoạn kết thúc v đƣa ra sản phẩm
Khi sản phẩm đã sẵn sàng đƣợc phát hành, ngƣời quản lý sẽ tuyên bố đóng dự án và
tiến hành việc đƣa ra sản phẩm. Trong giai đoạn này, một số công việc khác cần phải
đƣợc chuẩn bị tiến hành nhƣ tập hợp tài liệu sử dụng, đào tạo ngƣời dùng, phát triển
kinh doanh.
2.2.3 Phƣơng pháp phát triển phần mềm thích nghi
Phƣơng pháp phát triển phần mềm thích nghi (Adaptive Software Development –
ASD) đƣợc phát triển bởi James A. Highsmith, là một trong những phƣơng pháp thuộc
lớp các phƣơng pháp phát triển nhanh. Phƣơng pháp này tập trung chủ yếu trong việc
giải quyết các vấn đề xuất hiện trong các hệ thống phức tạp, nhiều thay đổi.
Tƣ tƣởng chủ đạo của ASD cho rằng, trong môi trƣờng liên tục có những thay đổi bất
thƣờng thì việc thích nghi là rất quan trọng. Xuất phát từ quan điểm đó, ASD đƣa ra
một quy trình mang tính lặp lại, quá trình “học” đƣợc tiến hành qua mỗi vòng lặp để
tăng cƣờng khả năng thích nghi.
Một dự án phát triển theo ASD đƣợc tiến thành thông qua các vòng lặp, các vòng lặp

gồm ba giai đoạn: suy đoán, cộng tác và học. Tên của các giai đoạn đƣợc đặt nhƣ vậy
cho thấy một số đặc trƣng của phƣơng pháp này. Từ suy đoán (từ gốc trong tiếng Anh
là “Speculate”) đƣợc sử dụng thay cho từ lập kế hoạch (Plan) là bởi vì việc lập kế
hoạch thƣờng dựa trên những gìđã rõ ràng, chắc chắn, trong khi mọi thứ đều có thể
thay đổi. Từ cộng tác (Collaborate) đƣợc sử dụng cho quá trình phát triển nhằm nhấn
mạnh vai trò của việc cộng tác giữa các thành viên, và từ học (Learn) đƣợc sử dụng để
muốn nói đến việc rút ra những kiến thức, bài học để tránh gặp phải những lỗi đã gặp
phải.

Hình 2.3 Quy trình ASD
Việc đƣa ra quy trình nhƣ vậy còn khá trừu tƣợng và mơ hồ, tuy nhiên với những mô
tả kỹ hơn từng giai đoạn có thể giúp cho việc hiểu quy trình này đƣợc dễ dàng hơn.
2.2.3.1 Khởi động dự án v lập kế hoạch

22
ASD cho rằng, chúng ta không thể biết mọi thứ, cho nên chúng ta chỉ có thể lập kế
hoạch dựa trên những hiểu biết có hạn. Thêm vào đó, chúng ta phảiđƣa ra những giả
thiết cho những kiến thức còn hổng. Do việc lập kế hoạch chỉ dựa trên những kiến
thức có hạn, nên việc thay đổi kế hoạch là rất tự nhiên, khi mà chúng ta thu đƣợc
những kiến thức mới. Khởi động dự án và lập kế hoạch là giai đoạn đầu tiên, trong
đó các công việc sau đƣợc thực hiện [22].
Công việc đầu tiên cần thực hiện đó là định nghĩa nhiệm vụ của dự án. Nhiệm vụ này
đƣa ra một khung cơ bản cho sản phẩm cuối cùng, giúp định hƣớng cho quá trình phát
triển sản phẩm. Phạm vi dự án cũng phải đƣợc ƣớc lƣợng, đồng thời đội ngũ phát triển
cũng phải đƣợc định hình cơ bản. Mục tiêu của dự án là hoàn thành nhiệm vụ này,
mặc dù tại thời điểm bắt đầu, những yêu cầu có thể còn rất mơ hồ, nhƣng sẽ rõ ràng
hơn trong quá trình hực hiện dự án.
Công việc tiếp theo cần thực hiện là phải xác định thời gian thực hiện ho toàn bộ dự
án. Dựa vào khoảng thời gian này, khung thời gian cho mỗi vòng lặp đƣợc định nghĩa.
Các vòng lặp đƣợc lập kế hoạch, độ dài của một vòng lặp phụ thuộc vào kích cỡ dự án

và mức độ khả thi, nhƣng thƣờng trong khoảng từ 2 đến 8 tuần. Việc lập kế hoạch này
bao gồm cả việc gán các khung thời gian cho mỗi vòng lặp.
Tiếp theo là việc lên lịch trình thực hiện các vòng lặp. Trong bƣớc này, mỗi vòng lặp
đƣợc gắn với một “chủ đề”, là vấn đề chính cần đƣợc chú ý khi thực hiện vòng lặp.
Cuối cùng, các tính năng đƣợc gán cho các vòng lặp. Các khách hàng là ngƣời quyết
định dựa trên mức độ ƣu tiên của từng tính năng. Những ngƣời phát triển sẽ hỗ trợ cho
khách hàng bằng việc ƣớc lƣợng thời gian, rủi ro và các đại lƣợng khác.
2.2.3.2 Giai đoạn phát triển các tính năng
Trong giai đoạn này, các đặc tính của sản phẩm đƣợc phát triển. Giống nhƣ Scrum,
ASD không đƣa ra các hƣớng dẫn chi tiết trong việc làm thế nào để phát triển mà chỉ
đơn thuần đƣa ra một bộ khung phục vụ cho việc quản lý. Điều mà ASD muốn nhấn
mạnh, đó chính là việc hợp tác giữa các thành viên. Theo Highsmith, việc hợp tác đặc
biệt quan trọng, ông đƣa ra quan điểm rằng một cá nhân riêng lẻ không thể có toàn bộ
khả năng cần thiết cho một dự án [22]. Những ngƣời quản lý phải có nhiệm vụ tạo ra
một môi trƣờng cộng tác tốt, đồng thời các thành viên trong nhóm phải tăng cƣờng
trao đổi và hỗ trợ nhau trong công việc.
2.2.3.3 Đánh giá lại chất lƣợng công việc
Mọi ngƣời không ai là biết tất cả mọi thứ, và do đó cần phải học. Kiến thức thu đƣợc
sau khi suy ngẫm về một cái gì đó, rồi tiến hành thử nghiệm và đánh giá kết quả.
Trong giai đoạn này, những tính năng đƣợc phát triển trong giai đoạn trƣớc đƣợc trình
bầy với khách hàng. Những ngƣời phát triển học đƣợc rất nhiều từ những đánh giá

23
dƣới góc độ khách hàng hoặc ngƣời sử dụng. Nhiều khi, về mặt tính năng thì những
chức năng đã cài đặt là thoả mãn, nhƣng về mặt sử dụng, thuật ngữ, bố trí có thể cần
phải cải tiến đề thuận tiện hơn.
Ngoài ra, các thành viên trong nhóm cũng cần phải thảo luận về những vấn đề kỹ thuật
gặp phải, từ đó rút ra đƣợc những bài học để tránh mắc phải hoặc biết cách xử lý trong
trƣờng hợp tƣơng tự. ASD cho rằng, không thể có quan điểm luôn phải đúng, mà cho
rằng ai cũng có thể mắc lỗi, và điều quan trọng là phải học đƣợc những kinh nghiệm từ

những lỗi đó.
Để đánh giá lại chất lƣợng công việc, cần phải xem xét lại những tính năng đã làm có
hoạt động không, và nó hoạt động nhƣ thế nào, công việc của nhóm có vƣớng mắc gì
không. Cuối cùng, cần đánh giá hiện trạng của dự án, những gì đã làm đƣợc và chƣa
làm đƣợc và có kế hoạch cho những công việc tiếp theo.
2.3 Kết chƣơng
Trong chƣơng này, tôi đã giới thiệu tổng quan về phƣơng pháp phát triển phần mềm
linh hoạt, và trình bày lƣớt qua một số quy trình truyền thống của phƣơng pháp linh
hoạt.
Trƣớc tiên là ASD, phƣơng pháp này đƣa ra một mô hình khá chung, mang tính chất
định hƣớng, nên việc áp dụng ASD khá linh động, tính tuỳ biến cao. Tuy nhiên,
phƣơng pháp này không đƣa ra nhiều hƣớng dẫn cụ thể nên đòi hỏi những ngƣời quản
lý phải có kỹ năng quản lý tốt.
Scrum đƣa ra những tiêu chuẩn, hƣớng dẫn đủ chi tiết để có thể áp dụng đƣợc ngay,
mặc dù có thể là không dễ. Tuy nhiên, phƣơng pháp này thiếu những hƣớng dẫn cụ thể
về mặt kỹ thuật lập trình, nên có thể áp dụng kết hợp với một phƣơng pháp phát triển
phần mềm khác.
Và cuối cùng là XP, đƣa ra nhiều ý tƣởng khá hay và hiệu quả, nhƣ khách hàng cùng
làm việc hay lập trình theo cặp. XP không cứng nhắc việc áp dụng, mà chỉ mang tính
chất chỉ đạo, nên việc áp dụng XP dễ hơn. Chúng ta có thể áp dụng XP đầy đủ, nhƣng
cũng có thể sử dụng những gợi ý của phƣơng pháp này và kết hợp với các phƣơng
pháp khác để có thể thu đƣợc hiệu quả cao nhất.
Chƣơng tiếp theo sẽ trình bày chi tiết một phƣơng pháp linh hoạt hoàn toàn mới đƣợc
áp dụng vào sản xuất phần mềm – Phƣơng pháp Kanban.

24
Chƣơng 3. PHƢƠNG PHÁP KANBAN
Trong chƣơng 2 chúng ta đã có cái nhìn tổng thể về phƣơng pháp phát triển phần mềm
linh hoạt và mộ số quy trình của một số phƣơng pháp truyền thống của phƣơng pháp
này.

Trong chƣơng này trình bày một phƣơng pháp phát triền phầm mềm mới hơn đó là
phƣơng pháp Kaban.
3.1 Giới thiệu
Thuật ngữ Kanban trong tiếng Nhật có nghĩa là cái thẻ [10]. Một thẻ gắn vào một
phần của công việc. Mỗi thẻ hoạt động đƣợc bắt đầu. Một công việc mới bất kỳ phải
đợi trong một hàng đợi (queue) tới khi nào một thẻ trở nên sẵn sàng. Khi một vài việc
đƣợc hoàn thành, thẻ đƣợc bóc ra và tái chế. Với một thẻ rảnh rỗi, một phần mới của
công việc trong hàng đợi có thể đƣợc bắt đầu.
Cơ chế này đƣợc hiểu nhƣ một hệ thống kéo bởi vì công việc mới đƣợc kéo vào trong
hệ thống khi có khả năng xử lý nó, chứ không phải bị đẩy vào trong hệ thống dựa trên
nhu cầu. Một hệ thông kéo không thể bị quá tải nếu khả năng (dung lƣợng) cũng nhƣ
là việc xác định số các thẻ tín hiệu trong sự lƣu thông đã đƣợc thiết lập một cách hợp
lý. Có thể hình dung một hệ thống Kanban qua ví dụ sau:
Trong một công viên, công viên chính là hệ thống: khách thăm quan là công việc đang
làm (WIP), và dung lƣợng đƣợc giới hạn bởi số thẻ vào cửa đƣợc lƣu thông. Những
khách thăm quan mới đến đƣợc vào khi có vé sẵn sàng trên tay. Một ngày bình thƣờng
điều này không có vấn đề gì. Tuy nhiên, vào ngày đông đúc, ví dụ ngày nghỉ, khi tất cả
các vé đƣợc đƣa ra, khách thăm quan mới phải xếp hàng bên ngoài cổng và chờ đợi
thẻ đƣợc tái sử dụng từ các khách đã thăm quan xong khi họ rời đi. Hệ thống Kanan
cung cấp một phƣơng pháp đơn giản, rẻ tiền và dễ dàng thực hiện để kiểm soát kích
thƣớc của đám đông bằng cách giới hạn số ngƣời bên trong công viên. Điều này cho
phép ngƣời giám sát công viên duy trì hoạt động trong điều kiện tốt và tránh thiệt hại
gây ra bởi quá nhiều ngƣời tham gia và bị quá tải.
Trong phát triển phần mềm, một hệ thống Kanban ảo dùng để giới hạn công việc đang
tiến hành. Các thẻ Kanban này không làm chức năng thực sự nhƣ là tín hiệu để kéo
công việc thay vào đó, chúng đại diện cho các hạng mục do đó gọi là “ảo”, vì không
có thẻ tín hiệu vật lý. Tín hiệu để kéo công việc mới đƣợc suy ra từ định lƣợng trực
quan công việc đang làm từ một số chỉ số của giới hạn (dung lƣơng- công suất).
Theo David J. Anderson [10] sử dụng một hệ thống Kanban để giới hạn công việc
đang làm của nhóm đến khả năng chấp nhận đƣợc và để cân bằng nhu cầu trong nhóm

so với thông lƣợng công việc giao cho họ. Bằng cách này nhóm có thể đạt đƣợc tốc độ
ổn định của phát triển để tất cả các cá nhân có thể cân bằng đƣợc công việc và cuộc
sống cá nhân. Kanban cũng nhanh chóng phát hiện ra những vấn đề làm giảm hiệu