PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT AGILE

MỤC LỤC
MỤC LỤC 2
MỞ ĐẦU 3
CHƯƠNG I. CƠ SỞ LÍ LUẬN CỦA ĐỀ TÀI 6
7
8
10
11
13
CHƯƠNG II. PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT
AGILE 16
CHƯƠNG III: LẬP TRÌNH CỰC HẠN – XP 30
Theo mô tả của Beck’s (1999b), hình…, dự án phần mềm phát triển bằng
phương pháp XP có những pha cơ bản sau: 33
i.Khảo sát (Exploration phase) 33
XP không dành riêng một khoảng thời gian cố định ban đầu cho việc thu
thập yêu cầu. Đại diện khách hàng sẽ ngồi làm việc chung với đội dự án,
người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là
người hiểu rõ các yêu cầu của sản phẩm. Người đại diện khách hàng sẽ viết
ra các yêu cầu về sản phẩm vào “user stories”. Mỗi “user stories” sẽ mô tả
một đặc trưng của chương trình. Trong khi đó, nhóm phát triển sẽ giới thiệu
những công cụ, công nghệ, những công việc mà họ sẽ sử dụng trong dự án
đó. Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester
tạo ra những ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ
họa, đại diện khách hàng cùng đội dự án sử dụng các công cụ để tạo ra các
bản phác thảo trước khi bắt tay vào lập trình. Một số dự án thuê người thiết
kế giao diện riêng 33
ii.Lập kế hoạch 33
34
CHƯƠNG IV. SỬ DỤNG PHƯƠNG PHÁP XP ĐỂ XÂY DỰNG PHẦN
MỀM TẠO MÁY RÚT TIỀN TỰ ĐỘNG ATM 41

43
44
45
47
48
49
Phương pháp phát triển phần mềm linh hoạt Agile
KẾT LUẬN VÀ KIẾN NGHỊ 51
TÀI LIỆU THAM KHẢO 53
PHỤ LỤC 54
MỞ ĐẦU
1. Tính cấp thiết của vấn đề nghiên cứu
Lịch sử phần mềm phát triển từ khoảng cuối thập niên 40 của thế kỷ trước,
nhờ công nghệ thông tin con người tạo ra những phần mềm từ dạng bé nhất bằng
cách đục lỗ, cho đến những phần mềm xử lý tính toán phức tạp với kích thước
hàng triệu dòng code, tạo ra nhiều ứng dụng trong mọi mặt của đời sống kinh tế -
xã hội. Cùng với sự phát triển như vũ bão của Công nghệ thông tin nói chung và
ngành công nghệ phần mềm nói riêng, việc phát triển phần mềm ngành ngày nay
được hỗ trợ bởi nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm nhanh
chóng và hiệu quả hơn Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn
về thời gian và chi phí, cho dù các quy trình sản xuất phần mềm ngày càng chặt
chẽ và khoa học cũng khó có thể đáp ứng yêu cầu ngày càng cao từ phía người sử
dụng. Chính vì thế, đặt ra một câu hỏi lớn: Có phương pháp phát triển phần mềm
nào giải quyết được những hạn chế trên hay không?
Từ trước đến nay đã có nhiều phương pháp phát triển phần mềm được sử
dụng. Tuy nhiên, với các phương pháp truyền thống đòi hỏi trong quá trình tạo ra
sản phẩm các yêu cầu ít thay đổi hoặc nếu chấp nhận thay đổi thường phải thiết kế
lại toàn bộ cấu trúc phần mềm sao cho phù hợp. Sự phát triển không ngừng của
nền kinh tế - xã hội làm cho các phương pháp phát triển phần mềm truyền thống
không thể đáp ứng được yêu cầu tạo ra phần mềm như khách hàng mong muốn. Vì

vậy nó không phù hợp và không còn được sử dụng rộng rãi.
Để khắc phục những hạn chế này, hiện nay các nhà phát triển phần mềm đã
tìm đến phương pháp phát triển phần mềm mới, cho phép các phần mềm có khả
năng biến đổi, sửa chữa ngay cả khi dự án đã bắt đầu. Đó là phương pháp phát
triển phần mềm linh hoạt Agile.
3
Phương pháp phát triển phần mềm linh hoạt Agile
Tuy nhiên, phương pháp này chưa thật sự được biết đến rộng rãi trên toàn thế
giới. Một số nhà lập trình chưa hiểu hết hoặc hiểu sai vì thế chưa vận dụng được
phương pháp này trong việc tạo ra các phần mềm.
Trước thực tế trên đã thôi thúc tôi chọn đề tài: "Tìm hiểu phương pháp
phát triển phần mềm linh hoạt Agile” nhằm giúp mọi người nói chung và các
nhà lập trình nói riêng hiểu đúng và vận dụng tốt phương pháp này để tạo ra các
phần mềm một cách nhanh chóng và hiệu quả.
2. Mục đích nghiên cứu
Trên cơ sở tìm hiểu phương pháp phát triển phần mềm linh hoạt Agile, từ đó
đưa ra các giải pháp giúp các nhà lập trình biết cách vận dụng nó để tạo ra các
phần mềm có khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không
cần phải làm lại từ đầu. Hay nói cách khác tạo ra một phần mềm thật đơn giản đáp
ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào
ngày mai.
3. Khách thể và đối tượng nghiên cứu
3.1. i t ng nghiên c uĐố ượ ứ
Phương pháp phát triển phần mềm linh hoạt Agile.
3.2. Khách th nghiên c u.ể ứ
Công nghệ phần mềm.
4. Nhiệm vụ nghiên cứu
4.1. Nghiên cứu các vấn đề lý luận làm cơ sở cho đề tài.
4.2. Tìm hiểu phương pháp phát triển phần mềm linh hoạt Agile.
4.3. Đề xuất giải pháp để đưa phương pháp phát triển phần mềm linh hoạt

Agile thực sự được áp dụng rộng rãi trong việc tạo ra các phần mềm.
5. Giả thuyết khoa học
Sự hiểu biết cũng như cách vận dụng phương pháp phát triển phần mềm linh
hoạt Agile trong việc tạo ra các sản phẩm phần mềm hiện nay còn nhiều hạn chế.
4
Phương pháp phát triển phần mềm linh hoạt Agile
Chính vì vậy, nếu hiểu đúng và áp dụng tốt thì phương pháp này chính là chìa
khóa thành công giúp các nhà lập trình hoàn thành nhiệm vụ một cách nhanh
chóng và hiệu quả nhất.
6. Các phương pháp nghiên cứu
6.1. Phương pháp nghiên cứu tài liệu.
6.2. Phương pháp điều tra.
6.3. Phương pháp quan sát.
6.4. Phương pháp phỏng vấn.
6.5. Phương pháp thống kê toán học.
5
Phương pháp phát triển phần mềm linh hoạt Agile
CHƯƠNG I. CƠ SỞ LÍ LUẬN CỦA ĐỀ TÀI
1.1. Vài nét về lịch sử vấn đề nghiên cứu.
1.1.1. n c ngoài.Ở ướ
Agile không bắt nguồn từ phần mềm – nó bắt đầu sản xuất vào những năm
1950 (đọc lên trên WE Deming). Agile là lý do mà người Nhật làm cho những
chiếc xe chất lượng cao giá cả phải chăng. Agile là làm thế nào các công ty Nhật
Bản lớn như Honda và Toyota có thể nhanh chóng quy mô xuống và đối phó với
khủng hoảng tín dụng hiện hành[1].
Phương pháp phát triển phần mềm linh hoạt được đưa ra vào đầu 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 - Agile”[2].
1.1.2. Vi t NamỞ ệ
Trước năm 2011, Agile ở Việt Nam chưa được quan tâm nhiều. Các công ty
khó tìm kiếm các chuyên gia am hiểu Agile để phát triển các sản phẩm của riêng
họ, hoặc đáp ứng yêu cầu của khách hàng về mặt phương pháp luận.
Tính đến thời điểm hiện tại, Agile mới chỉ xuất hiện trong một cộng đồng
hẹp dân CNTT tại Việt Nam và hiện vẫn còn là một “ẩn số” với đại đa số giới
CNTT trong nước. Một số công ty phần mềm sử dụng phương pháp này như công
ty Swiss IT bridge, Công ty TNHH Phần mềm FPT (FPT Software), …
6
Phương pháp phát triển phần mềm linh hoạt Agile
1.2. Lịch sử các phương pháp phát triển phần mềm.
1.2.1. Mô hình thác n c (Waterfall) ướ
Mô hình thác nước ra đời vào những năm 1970, là một mô hình cổ điển và
được áp dụng trong quy trình phát triển phần mềm tại phần lớn các công ty. Mô
hình này là một chuỗi quy trình phát triển như một luồng đều đặn từ trên xuống
hoạt động như một thác nước, bao gồm các giai đoạn: phân tích yêu cầu khách
hàng, thiết kế, cài đặt, kiểm tra, tích hợp và bảo trì.
Hình 1: Mô hình thác nước
Các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ
không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của
giai đoạn trước sẽ trở thành đầu vào của giai đoạn sau.
Ưu điểm:
Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Mô hình này
cơ bản dựa trên tài liệu. Sản phẩm phần mềm được hình thành thông qua chuỗi các
hoạt động xây dựng phần mềm theo trình tự rõ ràng. Dễ quản lý.
Nhược điểm:
Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự
án.

7
Phương pháp phát triển phần mềm linh hoạt Agile
Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai
đoạn trung gian từ thiết kế cho đến kiểm thử.
Quá cứng nhắc và thiếu thực tế, bởi việc thay đổi ở bất kỳ phần nào của quy
trình cũng là không thể vì việc làm lại các giai đoạn ban đầu thường mất rất nhiều
công sức và phá vỡ cấu trúc phần mềm, chi phí để sửa chữa có thể rất cao.
Điều kiện áp dụng:
Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi,
thường xuất phát từ sản phẩm đã đạt mức ổn định.
Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ
đầu dự án.Dự án được xác định hầu như không có rủi ro.
Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có
nhiều kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.
1.2.2. Mô hình làm b n m uả ẫ
Hình 2: Mô hình bản mẫu
Mô hình làm bản mẫu thực hiện các bước như sau:
B1: Xác định các yêu cầu của người sử dụng
8
Phương pháp phát triển phần mềm linh hoạt Agile
Chuyên viên phân tích thiết kế hệ thống làm việc với người sử dụng để nắm
được thông tin cơ bản cần cho việc tạo ra bản mẫu.
B2: Phát triển bản mẫu đầu tiên
Người thiết kế tạo nhanh một bản mẫu bằng cách sử dụng một công cụ phát
triển phần mềm thích hợp.
B3: Sử dụng bản mẫu làm việc với người sử dụng
Bản mẫu được sử dụng để trình diễn hay cho người sử dụng thử nghiệm.
Người sử dụng biết được bản mẫu đáp ứng yêu cầu của họ như thế nào và đưa ra
đề nghị để bổ sung và cải tiến.
B4: Hoàn thiện và tăng cường bản mẫu

Người thiết kế phải thay đổi bản mẫu để đáp ứng đòi hỏi của người sử dụng
và làm mịn hơn bản mẫu một cách phù hợp trên cơ sở sử dụng các thông tin khác.
Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu được "vi chỉnh" thoả mãn nhu
cầu của khách hàng trong khi đồng thời lại làm cho người phát triển hiểu được kĩ
hơn cần phải thực hiện nhu cầu nào.
Ưu điểm:
Người sử dụng sớm hình dung ra chức năng và đặc điểm hệ thống.
Nhược điểm:
Mô hình này thường làm nhanh, thậm chí vội vàng theo kiểu: "thực hiện -
sửa" nên có thể thiếu sự phân tích đánh giá một cách cẩn thận.
Vẫn chưa cải thiện được khoảng cách giữa yêu cầu và ứng dụng cuối cùng
dẫn đến phản ứng không tốt từ phía khách hàng.
Điều kiện áp dụng:
Hệ thống có rủi ro cao: Yêu cầu chưa chắc chắn, giao diện chưa rõ
Khách hàng, nhất là người sử dụng cuối không thể xác định rõ ràng yêu cầu.
9
Phương pháp phát triển phần mềm linh hoạt Agile
1.2.3. Mô hình xo n cắ ố
Mô hình xoắn ốc (spiral model) được Berry Boehm đưa ra năm 1988. Nó
dựa trên ý tưởng là tối thiểu hóa rủi ro, bằng viêc phân tích yếu tố rủi ro ở mỗi
bước lặp và sử dụng phương pháp làm bản mẫu. Quá trình phát triển được chia
thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc lập kế hoạch, phân tích rủi
ro, rồi tạo bản mẫu, hoàn thiện và phát triển hệ thống, duyệt lại, và cứ thế tiếp tục.
Nội dung gồm 4 hoạt động chính:
Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc.
Phân tích rủi ro: phân tích các phương án, xác định và giải quyết rủi ro.
Kỹ nghệ: phát triển sản phẩm “mức tiếp theo”.
Đánh giá của khách hàng: khẳng định kết quả của kỹ nghệ.
Hình 3: Mô hình xoắn ốc
Với mỗi lần lặp vòng xoắn ốc (bắt đầu từ tâm), các phiên bản được hoàn

thiện dần. Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiến hành
tiếp hay dừng” . Nếu rủi ro quá lớn, thì có thể đình chỉ dự án hay thay đổi yêu cầu
đặt ra cho thích hợp.
Ưu điểm:
10
Phương pháp phát triển phần mềm linh hoạt Agile
Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi
“spiral” để tăng mức độ tin cậy của dự án.
Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”.
Nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát
triển phần cứng.
Thích hợp để phát triển các hệ thống quy mô lớn
Nhược điểm:
Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro.
Cần có kỹ năng tốt về phân tích rủi ro.
Quy mô dự án phải đủ lớn để trả chi phí cho chuyên gia phân tích rủi ro.
Điều kiện áp dụng:
Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự
đảm bảo nhất định; những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ
trợquyết định
Đội ngũ thực hiện dự án có khả năng phân tích rủi ro.
1.2.4. Mô hình ch V.ữ
Hình 4: Mô hình chữ V
11
Phương pháp phát triển phần mềm linh hoạt Agile
Mô hình chữ V giống hệt mô hình thác nước, pha sau được thực hiện khi pha
trước thực hiện xong. Điều mấu chốt là phần coding nằm ở dưới đáy chữ V và đi
ngược lại lên trên. Điểm đặc biệt là kết hợp giữa kiểm thử và các pha trước nó. Có
thể coi đây là mô hình mở rộng của mô hình thác nước.
Còn với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai

đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp
với một giai đoạn kiểm thử tương ứng.
Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến
hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt
động phát triển.
Ưu điểm:
Mô hình này khuyến khích các hoạt động liên quan đến kế hoạch kiểm thử
được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai
đoạn hiện thực.
Nhược điểm:
Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự
án.
Pha sau thực chỉ được thực hiện khi pha trước kết thúc, không thể quay
ngược trở lại pha trước.
Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai
đoạn trung gian từ thiết kế cho đến kiểm thử.
Điều kiện áp dụng:
Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi,
thường xuất phát từ sản phẩm đã đạt mức ổn định.
Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có
nhiều kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.
Dự án được xác định hầu như không có rủi ro.
12
Phương pháp phát triển phần mềm linh hoạt Agile
1.2.5. Mô hình hi n đ i 4GTệ ạ
Mô hình 4GT đối với công nghệ phần mềm tập trung vào khả năng xác định
phần mềm bằng việc dùng các khuôn mẫu ngôn ngữ đặc biệt hay kí pháp đồ họa
vốn mô tả cho vấn đề cần được giải quyết dưới dạng khách hàng có thể hiểu được.
Hình 5: Mô hình 4GT
Mô hình 4GT bắt đầu từ bước thu thập yêu cầu. Một cách lý tưởng, khách

hàng sẽ mô tả các yêu cầu và các yêu cầu đó sẽ được dịch trực tiếp thành một bản
mẫu vận hành được. Nhưng điều này không thực hiện được. Khách hàng có thể
không chắc chắn mình cần gì, có thể có sự mơ hồ trong việc xác định các sự kiện
đã biết, có thể không có khả năng hay không sẵn lòng xác định thông tin theo cách
thức mà công cụ 4GT có thể giải quyết được. Bởi lí do này, đối thoại khách hàng/
người phát triển được mô tả cho các mô hình tiến trình khác vẫn còn là phần bản
chất của cách tiếp cận 4GT.
Ngày nay môi trường 4GT đã được mở rộng để đề cập tới hầu hết các loại
ứng dụng phần mềm. Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước
thu thập yêu cầu sang cài đặt bằng công cụ 4GT hay một mô hình bao gồm một
mạng các biểu tượng đồ hoạ.
13
Phương pháp phát triển phần mềm linh hoạt Agile
Để biến đổi một cài đặt 4GT thành một sản phẩm, người phát triển phải tiến
hành việc kiểm thử toàn diện, xây dựng các tài liệu có ý nghĩa và thực hiện mọi
hoạt động tích hợp giải pháp khác vốn cần tới trong các mô hình kĩ nghệ phần
mềm khác. Bên cạnh đó, phần mềm được phát triển theo 4GT phải được xây dựng
theo cách làm cho việc bảo trì có thể được tiến hành một cách chóng vánh.
Ưu điểm:
Làm giảm đáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệu
suất của người xây dựng phần mềm.
Nhược điểm:
Có những công cụ 4GT hiện tại khó dùng hơn các ngôn ngữ lập trình.
Chương trình gốc do các công cụ 4GT tạo ra là "không hiệu quả," và tính bảo
trì cho các hệ thống phần mềm lớn được phát triển bằng cách dùng 4GT vẫn còn là
vấn đề mở.
1.2.6. Ph ng pháp phát tri n ph n m m linh ho tươ ể ầ ề ạ
Agile
Được ra đời vào đầu những năm 90. Là phương pháp phát triển phần mềm
chú trọng vào sự tiến hóa, phát triển của nó theo thời gian (xây dựng bồi đắp thêm,

mở rộng thêm) với sự kế thừa tối đa, hiệu chỉnh lại cho phù hợp và tránh phải bắt
đầu làm một thành phần nào đó lại từ đầu.
Agile là một triết lý cho việc phát triển phần mềm. Nói cách khác, đó là một
cách “tư duy” về các dự án phần mềm. Các triết lý của Agile được cụ thể hóa bởi
một số phương pháp phát triển phần mềm, chẳng hạn như Extreme Programming
(XP) hay Scrum, gọi tắt là phương pháp Agile.
1.3. Kết luận lịch sử các phương pháp phát triển phần mềm
Lịch sử phần mềm đã trải qua nhiều phương pháp phát triển, mỗi phương
pháp đều có ưu và nhược điểm nhất định tuy nhiên phương pháp sau bao giờ cũng
kế thừa nhiều nhất những ưu điểm và cố gắng khắc phục những hạn chế của
phương pháp trước. Trong khi đưa ra yêu cầu, có thể khách hàng không thể lường
14
Phương pháp phát triển phần mềm linh hoạt Agile
trước được mọi tình huống mà nó sẽ tự phát sinh trong quá trình tạo ra sản phẩm.
Với các phương pháp truyền thống, tiêu biểu là mô hình thác nước lại ngăn chặn
sự thay đổi này vì nó phá vỡ cấu trúc phần mềm đã được tạo ra. Trong khi đó
phương pháp phát triển phần mềm phương pháp Agile khuyến khích sự thay đổi từ
phía khách hàng, mặt khác trong một thời gian ngắn lại đưa ra được sản phẩm cho
người sử dụng. Vì vậy, với xu thế phát triển hiện nay, phương pháp Agile là một
lực chọn đúng đắn cho các nhà phát triển phần mềm.

15
Phương pháp phát triển phần mềm linh hoạt Agile
CHƯƠNG II. PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH
HOẠT AGILE
2.1. Tổng quan về phương pháp Agile.
2.1.1. Ph ng pháp Agile là gì?ươ
Agile là một triết lí (philosophy) cho việc phát triển phần mềm. Nói cách
khác, đó là một cách “tư duy” về các dự án phần mềm.
Bản chất của Agile chính là đáp ứng những sự thay đổi yêu cầu theo thời

gian. Vì vậy, Agile chia dự án thành các giai đoạn nhỏ, mỗi giai đoạn có thể được
hoàn tất trong một khoảng thời gian ngắn thông thường từ một đến bốn tuần, mỗi
một giai đoạn sẽ tập trung phát triển một phần mềm hoàn chỉnh, bao gồm: Lập kế
hoạch, phân tích yêu cầu, thiết kế, lập trình, kiểm thử và bàn giao sản phẩm.
Trong Agile, việc giao tiếp giữa các thành phần tham gia dự án được coi
trong hơn là việc viết tài liệu dự án… Nhất là giao tiếp giữa đội phát triển dự án
với khách hàng.
Vào tháng 12 năm 2001, 17 nhà phát triển phần mềm
[3]
đã gặp gỡ nhau ở
Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn
nhẹ và linh hoạt. Họ đã cùng nhau công bố "Tuyên ngôn phát triển phần mềm linh
hoạt" ("Manifesto for Agile Software Development" - gọi tắt là "Tuyên ngôn
Agile") để định nghĩa cách hiểu về phương pháp phát triển phần mềm linh hoạt
[4]
.
a) Tuyên ngôn 4 điểm của Agile:
“Chúng tôi đang khám phá những phương pháp tốt hơn để phát triển phần
mềm bằng cách tự tay phát triển và giúp những người khác làm việc đó. Qua công
việc này chúng tôi thống nhất đánh giá cao và nhấn mạnh các điểm sau:
• Vai trò các cá nhân và sự tương tác hơn là qui trình và công cụ
[Coi trọng vai trò cá nhân và sự tương tác hơn là qui trình và công cụ] …phía
sau các mệnh đề khác cũng viết lại theo kiểu này cho cô…Coi trọng …. Hơn là…
• Phần mềm hoạt động được hơn là các tài liệu đầy đủ.
16
Phương pháp phát triển phần mềm linh hoạt Agile
[Coi trọng khả năng hoạt động của phần mềm hơn là…]
• Cộng tác của khách hàng hơn là việc thương lượng hợp đồng
• Đáp ứng các thay đổi hơn là tuân thủ kế hoạch
[Coi trọng việc đáp ứng các thay đổi yêu cầu hơn là…]

Điều này có nghĩa là, mặc dù những điểm nằm ở vế phải có giá trị, nhưng
chúng tôi đánh giá cao vế bên trái hơn.”
Thứ nhất: Trong phương pháp Agile các thành viên tham gia dự án chia sẻ
thông tin chứ không chú trọng một quy trình hay công cụ nào đó.
Thứ hai: Mục tiêu chính là hoàn tất phần mềm, không quá chú ý đến việc
thu thập thông tin tổng thể; nghĩa là ít nhấn mạnh việc thu thập tư liệu và tập trung
nhiều hơn cho việc hoàn tất công việc.
Thứ ba: Agile tập trung vào việc khuyến khích khách hàng cùng tham gia
vào dự án tránh việc viết hợp đồng xong khách hàng không tham gia đóng góp cho
dự án.
Thứ tư: Nhóm phát triển luôn sẵn lòng đón nhận thay đổi; không quá rập
khuôn theo kế hoạch dự án (có trước), vì thay đổi luôn diễn ra và cả kế hoạch dự
án cũng sẽ thay đổi khi yêu cầu thay đổi.
[5]
b) Các nguyên lý phía sau tuyên ngôn Agile:
[6]
- Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản
phẩm sớm và liên tục.
- Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai
đoạn cuối.
- Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì càng ngắn
càng tốt.
- Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau
hàng ngày.
- Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng họ.
17
Phương pháp phát triển phần mềm linh hoạt Agile
- Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp.
- Các chức năng đã hoạt động là thước đo chính cho tiến độ dự án.
- Lập trình viên, người dùng, nhà quản lí…phải có khả năng tham gia dự án

một cách liên tục.
- Liên tục cải tiến chất lượng thiết kế và mã nguồn.
- Tính đơn giản giữ vai trò cốt yếu.
- Những yêu cầu và thiết kế tốt nhất được xuất phát từ những nhóm làm việc
tự chủ.
- Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến
hiệu quả công việc.
2.1.2. T m quan tr ng c a ph ng pháp Agile.ầ ọ ủ ươ
Một dự án phần mềm thành công là khi phần mềm giao đúng hạn, trong
ngân sách cho phép và làm đúng yêu cầu của khách hàng. Tuy nhiên trên thực tế
có nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng vẫn bị coi là thất bại bởi
phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi
ích cho các cá nhân, tổ chức sử dụng chúng.
Ngoài các yếu tố trên, một dự án phần mềm chỉ được coi là thành công khi
thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và
thành công ở mức công ty. Thành công ở mức cá nhân giúp kích thích các thành
viên trong nhóm. Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của
sản phẩm. Vị trí của nhóm sẽ được bảo đảm nhờ các thành công mà nhóm mang
lại cho công ty. Các phương pháp Agile giúp cho dự án phần mềm đạt được ba
thành công này.
Cụ thể:
a) Thành công ở mức công ty.
Agile tạo ra giá trị cho công ty trong khi làm giảm chi phí. Đồng thời, Agile
giúp sớm xác định các kì vọng đối với sản phẩm đang được phát triển. Nhờ đó,
18
Phương pháp phát triển phần mềm linh hoạt Agile
những dự án không mang lại giá trị như mong đợi sẽ được phát hiện sớm, tiết
kiệm chi phí cho công ty.
Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc
trực tiếp cùng với đội dự án. Các chức năng quan trọng nhất của sản phẩm được

tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể. Các phiên
bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào.
Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm.
Chất lượng mã nguồn được cải tiến liên tục. Tiến độ dự án cũng được xem xét và
đánh giá một cách thường xuyên.
b) Thành công về mặt kĩ thuật.
Trong Extreme Programming, một phương pháp tuân theo triết lí Agile, các
lập trình viên làm việc cùng nhau. Nhờ vậy, các chi tiết quan trọng sẽ không bị bỏ
sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người. Các lập trình viên liên
tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép một phiên bản mới
của phần mềm được “ra lò”. Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một
chức năng trước khi chuyển sang chức năng tiếp theo. Bởi vậy, tiến độ công việc
được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những
thay đổi từ phía khách hàng.
Ngoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo ra các
thiết kế và các đọan mã tốt. Chẳng hạn, quy tắc “phát triển dựa trên kiểm thử”
(test-driven development) trợ giúp lập trình viên viết các chương trình thực hiện
đúng chức năng mong muốn.
c) Thành công về mặt cá nhân
Mỗi thành viên trong dự án Agile, dù ở bất kì cương vị nào, cũng đều cảm
nhận được một cách rõ ràng sự thành công của bản thân. Các lập trình viên nhận
thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của mình đối với dự án được nâng
cao, chẳng hạn trong việc ước lượng và lập kế hoạch. Quyền tự chủ của đội dự án
cũng được tăng cường. Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng
sản phẩm, đồng thời giảm được các công việc lặp lại một cách nhàm chán. Nhà
19
Phương pháp phát triển phần mềm linh hoạt Agile
quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự án thực hiện đúng
các cam kết và làm thỏa mãn khách hàng.
Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì

điều kiển được hướng đi của dự án và các ý kiến được lắng nghe.
Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợi nhuận
lớn cho công ty.
2.1.3. Cách áp d ng ph ng pháp Agile.ụ ươ
Khi phát triển phần mềm, tùy vào đặc trưng của từng dự án có thể lựa chọn
các phương pháp, quy trình cho phù hợp. Cũng giống các phương pháp đã biết,
Agile không phù hợp với mọi loại hình dự án, đặc biệt là các dự án nhằm mục tiêu
tăng năng suất lao động của các thành viên. Theo tài liệu….Agile có thể phù hợp
với các dự án có đặc điểm sau đây:
Không phải dự án nào cũng nên áp dụng Agile. Nếu mục tiêu của bạn là tăng
năng suất lao động, làm cho các lập trình viên làm việc nhanh hơn thì Agile có thể
không phù hợp bởi các quy tắc của nó không nhằm tăng năng suất của đội dự án.
Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu
hỏi: liệu Agile có giúp bạn thành công hơn hay không?
Các d án có đ c đi m sau đây có th phù h p v iự ặ ể ể ợ ớ
Agile:
• Mức độ rủi ro thấp.
• Thành viên trong nhóm có kinh nghiệm.
• Yêu cầu thay đổi thường xuyên.
• Kích thước nhóm nhỏ., các thành viên làm việc trong tcùng một địa
điểm.
• Văn hóa công ty ưa thích sự “không trật tự”.
20
Phương pháp phát triển phần mềm linh hoạt Agile
Trái l i, nh ng đi u ki n sau đây là v t c n cho vi cạ ữ ề ệ ậ ả ệ
áp d ng Agile:ụ
• Kích thước nhóm lớn (hơn 20 thành viên bao gồm lập trình viên, tester,
…).
• Các thành viên phân tán về mặt địa lí (ví dụ các dự án outsource).
• Văn hóa công ty làm việc theo mệnh lệnh.

2.2. Quy trình thực hiện trong phương pháp Agile
2.2.1. L p k ho ch (planning)ậ ế ạ
Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên. Đại diện
của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng
trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình
phát triển cho từng phần tăng trưởng. Kế hoạch tổng thể sẽ được điều chỉnh tùy
theo tình hình tiến triển của dự án.
Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào
đầu mỗi vòng lặp. Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công
việc.
2.2.2. Phân tích yêu c u (requirements analysis)ầ
Agile không dành riêng một khoảng thời gian cố định ban đầu cho việc phân
tích yêu cầu. Đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án.
Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu
rõ nhất các yêu cầu cho sản phẩm. Khi cần thông tin, các lập trình viên chỉ việc
đến trao đổi trực tiếp với người này.
Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo
ra những ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ họa, đại
diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập
trình. Có một số dự án lại thuê người thiết kế giao diện riêng.
21
Phương pháp phát triển phần mềm linh hoạt Agile
2.2.3. Thi t k và l p trình (design)ế ế ậ
Trong một dự án, thiết kế của sản phẩm được cải tiến liên tục. Hoạt động này
được thực hiện nhờ phương pháp phát triển dựa trên kiểm thử (test-driven
development hay TDD). TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và
kiểm thử. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các
dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình.
Các lập trình viên tích hợp mã nguồn (code) vài giờ một lần và đảm bảo rằng
phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng. Mã

nguồn được coi là sở hữu tập thể. Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do
ai gây ra.
2.2.4. Ki m th (test)ể ử
Kiểm thử nhằm mục đích đảm bảo chất lượng cho sản phẩm, và vấn đề này
thuộc trách nhiệm của tất cả các thành viên trong dự án. Các lập trình viên thực
hiện quá trình kiểm thử đơn vị (unit test) và kiểm thử tích hợp (integration test).
Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng cách
kiểm thử chấp nhận (customer test). Khi đội kiểm thử (tester) tìm ra lỗi, cả đội
cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi
tái diễn. Tất cả các kiểm thử hồi quy (regression test) đều được thực hiện tự động
(bởi code mới được tích hợp vào hệ thống một cách liên tục) và được thực hiện
bởi các lập trình viên khi họ tích hợp code mới vào hệ thống. Lập trình theo cặp
góp phần làm tăng chất lượng công việc.
2.2.5. Bàn giao s n ph m (release)ả ẩ
Hệ thống được tích hợp hàng tuần và được bàn giao cho khách hàng theo kế
hoạch đã định trước hoặc theo nhu cầu của khách hàng.
2.3. So sánh phương pháp Agile với các phương pháp truyền thống.
2.3.1. Gi ng nhau.ố
- Đều là các phương pháp phát triển phần mềm.
22
Phương pháp phát triển phần mềm linh hoạt Agile
- Đều cho phép thực hiện phân khu, cụ thể trong phương pháp truyền thống
việc phân khu được thực hiện vào mỗi giai đoạn. Đối với phương pháp Agile, mỗi
module đã được mã hóa đều có thể được phân bổ cho những nhóm lập trình khác
nhau. Điều này cho phép nhiều phần trong dự án được hoàn thành cùng lúc thế nên
việc phân khu được sử dụng hiệu quả hơn trong phương pháp Agile.
2.3.2. Khác nhau.
Tiêu chí Phương pháp phát triển truyền
thống
Phương pháp phát triển Agile

- Nhấn mạnh kết quả mà không phải
là những hoạt động tạo ra kết quả đó.
- Không nhấn mạnh việc gặp mặt trao
đổi hàng ngày.
- Nhấn mạnh việc làm hàng
ngày.
- Nhấn mạnh việc gặp mặt trao
đổi hàng ngày.
Tiêu chí
thành
công.
Sản phẩm giao đúng hạn, trong ngân
sách cho phép và làm đúng yêu cầu
của khách hàng
Sản phẩm thỏa mãn 3 tiêu chí:
Thành công ở mức cá nhân,
thành công về mặt kĩ thuật và
thành công ở mức công ty.
Yêu cầu
thay đổi
Ngăn chặn sự thay đổi yêu cầu từ
phía khách hàng
Hoan nghênh mọi sự thay đổi từ
phía khách hàng.
Sản
phẩm tạo
ra
Tạo ra các phần mềm có tính cứng
nhắc
Tạo ra các phần mềm có tính

mềm dẻo, có thể thay đổi được.
Xử lý khi
có yêu
cầu mới
Phần lớn phải viết lại code Chỉnh sửa lại code, mở rộng tính
năng mà không phải code lại từ
đầu.
Về rủi ro Kiểm thử được thực hiện 1 lần vào
cuối mỗi dự án. Nếu dự án phát sinh
lỗi, hoặc có sự thay đổi về yêu cầu
của người sử dụng thì chi phí để sửa
lỗi và đáp ứng yêu cầu mới rất lớn
Kiểm thử được thực hiện một
cách thường xuyên vì cuối mỗi
giai đoạn thử nghiệm đều có thể
đưa ra kết quả. Giảm thiểu tối đa
rủi ro, tiết kiệm được thời gian
cũng như chi phí sửa lỗi.
Dự án
phù hợp
Phù hợp những dự án yêu cầu rõ
ràng, thời gian phát triển tương đối
dài.
Phù hợp với những dự án yêu
cầu chưa rõ ràng, thời gian phát
triển nhanh chóng.
23
Phương pháp phát triển phần mềm linh hoạt Agile
Tính linh
hoạt và

phù hợp
Tất cả các yêu cầu đến từ khách hàng
từ trước khi ký kết hợp đồng
Yêu cầu có thể được bổ sung
trong quá trình phát triển dự án.
Nguồn
nhân lực
Các cá nhân chỉ quan tâm đến một
khâu mà họ đảm nhiệm.
Mỗi cá nhân phải biết tất cả các
khâu để hoàn thành dự án đó.
2.4. Một số phương pháp phát triển phần mềm trong phương pháp
Agile
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, và một số phương pháp khác…
- Lập trình Cực hạn (eXtreme Programming - XP): Phương pháp này đặt
nặng về yếu tố thích nghi - tương thích, và thường hữu ích đối với các dự án chưa
xác định được mong muốn của sản phẩm cuối cùng.
- Scrum (Phương pháp phát triển trong Hỗn độn): Phương pháp này
nhấn mạnh sự lặp lại của việc kiểm các chức năng sản phẩm và phát triển tịnh tiến
vì các yêu cầu của sản phẩm luôn thay đổi.
2.4.1. C th các ph ng pháp phát tri n Agileụ ể ươ ể
2.4.1.1. L p trình c c h n - Extreme programmingậ ự ạ
(XP)
XP là một phương pháp xây dựng phần mềm mới, được Kent Beck mô tả
bằng các tài liệu có liên quan do Martin Flower và Ron Jeffries đề xướng[7],
phương pháp này nhấn mạnh vào sự cộng tác, tạo ra phần mềm một cách nhanh
chóng, và phát triển mở rộng trong quá trình thực hiện. Nó được cô đọng trong
bốn nguyên tắc: sự trao đổi (communication), đơn giản hóa (simplicity), sự phản
hồi (feedback), và sự dũng cảm (courage)

[8]
.
Đối với các dự án khách hàng thường xuyên thay đổi các yêu cầu và mong
muốn sớm nhận được sản phẩm từ ngời phát triển thì XP có vẻ phù hợp.
Nếu bạn làm việc với những dự án khách hàng thường xuyên thay đổi yêu
cầu và mong muốn sớm nhận được sản phẩm thì nên xem xét XP. Phương pháp
24
Phương pháp phát triển phần mềm linh hoạt Agile
XP khuyến khích các nhóm làm việc với nhau; bàn giao các phiên bản phần mềm
chất lượng cao hơn các phiên bản phương pháp truyền thống.
XP bao gồm một tập hợp các quy tắc và công việc giúp người lập trình mô tả
chi tiết các hoạt động. Vòng đời của XP gồm có các pha: Khảo sát (Exploration),
Lập kế hoạch (Planning), Các bước lặp để phát hành (Iteration to Release), Sản
xuất (Productionizing), Bảo trì và kết thúc (Maintenance and Death)
[9]
.
2.4.1.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 (1986) 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. Thuật ngữ “Scrum” có nguồn gốc từ một chiến thuật trong
môn bóng bầu dục ám chỉ việc đưa bóng vào cuộc
[10]
.
Kent Schwaber lần đầu tiên mô tả về phương pháp Scrum vào năm 1996, là
một quá trình chấp nhận và phát triển các yêu cầu chưa được xác định trước
[11]
.
Nguyên tắc của phương pháp Scrum là phát triển một phần mềm bằng việc
gia tăng dần các yêu cầu phát triển. Với việc bàn giao thường xuyên (thông thường
4 tuần) khách hàng sẽ nhận được phần mềm với nhiều tính năng và hoạt động tốt

hơn. Phương pháp Scrum dựa trên việc phát triển các yêu cầu với tốc độ không đổi
trong khoảng từ 2 đến 4 tuần.
a) Các thành viên trong Scrum
[12]
- Product owner: Chủ sở hữu sản phẩm là người chịu trách nhiệm cho dự
án, quản lý, kiểm soát và thống kê các yêu cầu chưa được thực hiện của cầu sản
phẩm. Product owner được lựa chọn bởi các ScrumMaster, Customer và managent.
- ScrumMaster: Người lãnh đạo nhóm là người hỗ trợ đắc lực cho dự án,
làm việc chặt chẽ với người chủ sở hữu sản phẩm . Kiểm tra công việc của các
thành viên đảm bảo đội hoạt động và có năng suất hiệu quả với Scrum.
- ScrumTeam: Quy mô từ 4 đến 10 người, đội sản xuất tập trung các thành
viên có kinh nghiệm và có vai trò cần thiết trong một dự án. Có quyền quyết định
những hoạt động cần thiết để đạt được mục tiêu Sprint.
25
Phương pháp phát triển phần mềm linh hoạt Agile
- Customer: Tham gia vào các nhiệm vụ liên quan đến công việc chưa được
thực hiện để sản phẩm phát triển và nâng cao hơn.
- Management: Quyết định kết quả cuối cùng. Tham gia vào việc thiết lập
các yêu cầu.
b) Các hình th c h p bàn trong Scrumứ ọ
[13]
- Sprint Planning (Lập kế hoach cho Sprint):
Đội sản xuất sẽ gặp gỡ với chủ sở hữu sản phẩm, người quản lí, khách hàng
để lên kế hoạch làm việc cho một Sprint. Các công việc như là: chọn lựa các yêu
cầu cần 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 công việc. Scrum sử dụng phương 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.
- Daily Scrum (Buổi họp hằng ngày):
Mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để

tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm nay
và kiểm tra các tình huống có thể cản trở công việc trong ngày hôm nay.
- Sprint Review (Buổi họp đánh giá):
Cuối Sprint, đội sản xuất cùng với Product Owner sẽ rà soát lại các công việc
đã hoàn thành 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.
- Sprint Retrospective (Buổi họp cải tiến):
Dưới sự chỉ đạo của Scrum Master, Đội sản xuất sẽ rà soát lại toà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ư sản phẩm.
c) Cách th c cài đ t đ s d ng Scrumứ ặ ể ử ụ
[14]
Bước 1: Thu nhập các đặc điểm của sản phẩm (product backlog) trong đơn
đặt hàng. Đây là bước quan trọng nhất. Lập nên các đội làm việc, có thể tách thành
các đội nếu cần thiết và thảo luận với nhau về nghiệp vụ cần làm. Sau đó bổ nhiệm
26