Phương pháp luận agile và ứng dụng trong phát triển hệ thống thông tin hướng đối tượng

Agile methodology - 1 -




ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA CÔNG NGHỆ THÔNG TIN





BỘ MÔN
HỆ THỐNG THÔNG TIN HƯỚNG ĐỐI TƯỢNG


ĐỀ TÀI
Phương pháp luận agile và ứng dụng
trong phát triển hệ thống thông tin
hướng đối tượng





GV
: TS. Phạm Nguyễn Cương
Nhóm học viên thực hiện
:

Nguyễn Minh Đăng 10 12 006
Nguyễn Tấn Khánh 11 11 024
Lê Thanh Sang 11 11 042



TP.HCM - 12/2012




Agile methodology - 2 -


Mục lục

1. Tổng quan về Agile
3
1.1 Sự cần thiết của một mô hình phát
triển
phần mềm
m
ớ
i
3
1.2 Phương pháp Agile 6
1.3 So sánh Agile và các phương pháp hiện tại 17
2. Mô hình hóa với Agile 19
2.1 Các giá trị của mô hình hóa Agile 19
2.1 Các nguyên tắc cốt lõi của mô hình hóa agile 22

2.2 Các phương pháp thực hành của mô hình hóa agile 24
2.3 Phát triển phần mềm theo hướng mô hình hóa agile 26
2.4 Tài liệu hóa theo hướng agile 27
3. Quy trình Scrum 28
3.1 Tổng quan về Scrum 28
3.2 Scrum và Waterfall 28
4. Quy trình XP 31
4.1 Tổng quan về XP 31
4.1 Các đặc điểm của XP 32
5. Phát triển hướng vào tính năng (Feature Driven Development) 37
5.1 Quy trình 37
5.2 Các vai trò và trách nhiệm 40
5.3 Kiểm chứng thực tiễn (Practices) 43
5.4 Sự chấp nhận và kinh nghiệm 44
5.5 Phạm vi sử dụng 44
5.6 Nghiên cứu hiện tại 44
6. The Rational Unified Process 45
6.1 Quy trình 45
6.2 Các vai trò và trách nhiệm 48
6.3 Kiểm chứng thực tiễn 49
6.4 Sự chấp nhận và kinh nghiệm 49
6.5 Phạm vi sử dụng 50
6.6 Nghiên cứu hiện tại 51
7. Tài liệu tham khảo 51

Agile methodology - 3 -



1. Tổng quan về Agile
1.1 Sự cần thiết của một mô hình phát
triển
phần mềm
m
ớ
i

- Chúng ta đã viết phần mềm được 30 năm nhưng những gì chúng ta đã
làm được còn rất ít. Thành công của chúng ta được thúc đẩy bởi sự tưởng
tượng, sáng tạo của con người. Chúng ta càng viết ra nhiều phần mềm thì sự
đòi hỏi, yêu cầu của con người càng nhiều. Chính vì vậy, những nhà quản
lý và phát triển phần mềm tiếp tục tìm kiếm phương thức phát triển phần
mềm tốt hơn.
- So với 30 năm trước chúng ta đã có những chiếc máy tính rẻ hơn, nhanh
hơn, nhiều ngôn ngữ lập trình mạnh mẽ ra đời, số lượng nhiều hơn cần thiết
những công cụ hỗ trợ, sự đào tạo tốt hơn và có những hiểu biết sâu hơn về
lý thuyết phần mềm. Internet đã thay đổi cách con người giao tiếp với nhau,
thúc đẩy sự trao đổi thông tin và thay đổi một cách triệt để sự kỳ vọng của
con người về cách thức phần mềm làm việc. Chúng ta cũng có số lượng
đáng kể những phương pháp khác nhau giúp xác định con đường phát triển
phần mềm tốt nhất và đó chính là khía cạnh của việc phát triển phần mềm
mà chúng ta sẽ tập trung vào trong thời gian tới.
1.1.1 Những hạn chế của mô hình phát

triển
phần mềm
truyền
t
h
ố
n
g

- Đã có rất nhiều mô hình phát triển phần mềm được tạo ra trong những năm
qua. Có thể kể đến như:
o Pure waterfall
o Code-and-Fix
o Spiral
o Modifed Waterfalls
o Evolutionary Prototyping
o Staged Delivery
o Evolutionary Delivery
o Design-to-Schedule
o Design-to-Tools
o Commercial Off-the-shelf Software

Agile methodology - 4 -


- Khi xây dựng các phương pháp truyền thống người ta đã cố gắng trang bị
cho chúng khả năng dự đoán trước. Với khả năng này ta có thể tạo ra một
bản kế hoạch tại thời điểm đầu của dự án và xác định được thời gian hoàn
thành dự án dựa theo bản kế hoạch này. Và vấn đề cố hữu trong quá trình
thực hiện dự án vẫn là “sự thay đổi yêu cầu của người dùng”. Thông

thường khách hàng không thay đổi yêu cầu của họ bởi vì họ biết rằng chi
phí để thay đổi rất đắt. Tuy nhiên phần mềm không phải là thứ hữu hình.
Khách hàng không chỉ khó để xác định một cách chính xác cái gì là cần thiết
mà cũng khó để hiểu tại sao việc thay đổi lại khó khăn như vậy. Họ mong
đợi một phần mềm phải có tính mềm dẻo. Những phương pháp truyền
thống đã đưa ra những thủ tục nhằm ngăn chặn sự thay đổi yêu cầu từ
phía khách hàng. Điều này giúp duy trì bản kế hoạch dự án đã xây dựng
ban đầu nhưng lại không đảm bảo rằng kết quả cuối cùng là những gì mà
khách hàng mong muốn. Khả năng dự đoán trước có thể là điều ước ao
nhưng ta chỉ có thể đạt được điều đó với giá phải trả là sự giảm sút chất
lượng phần mềm không thỏa mãn được đòi hỏi của khách hàng.
- Với những hạn chế như vậy của những phương pháp phát triển phần mềm
truyền thống, ta thắc mắc rằng tại sao chúng lại được sử dụng và nếu chúng
đã được sử dụng trong quá khứ thì lại từ bỏ chúng bây giờ? Phải chăng
một vài thứ đã thay đổi. Trong suốt thập niên 80 những thay đổi cơ bản đã
xảy ra và kết quả là hình thành nên “thế giới nhanh” – thế giới của sự
toàn cầu hóa và “thế giới chậm” của những ai tự tách mình ra khỏi quá trình
toàn cầu hóa. Sự phát triển phần mềm diễn ra trong thế giới nhanh và sự
thay đổi diễn ra đồng thời ở công nghệ, tài chính, thông tin và đi kèm với
chúng là sự dỡ bỏ những hàng rào chính trị được duy trì suốt thời kỳ chiến
tranh lạnh. Mọi việc diễn ra nhanh hơn. Những đối thủ xuất hiện, sự thành
công hay thất bại chỉ là ranh giới mong manh. Vòng đời của sản phẩm ngắn
hơn và người dùng thì hay thay đổi. Không có gì là ngạc nhiên khi những
phương pháp phù hợp với thập niên 70 lại thất bại trong thập niên 80 và 90.

1.1.2 Sự nổi lên của phương pháp Agile
- Trong thậ
p kỉ 90 nhiều người đã nhận ra mọi thứ đã thay đổi bằng cách này
hay cách khác. Những người này đã quan tâm tới phương pháp phát triển

Agile methodology - 5 -


phần mềm linh hoạt hơn, phù hợp hơn với môi trường làm việc luôn luôn
vận động. Mặc dù chi tiết những phương pháp này là khác nhau nhưng
chúng đều có chung một số nguyên tắc và trong một phạm vi nào đó những
phương pháp này thường được nhóm lại với nhau dưới tên gọi “những
phương pháp linh hoạt – agile methodologies”.
- Phát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile)
là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát
triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative)
và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông
qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thường sử
dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và
chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh
hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Ngày
nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển
phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản
xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales,
marketing, giáo dục v.v.
- 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. Theo khảo sát của hãng nghiên cứu thị trường
Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp
nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi
(xem Hình 1). Hơn thế, một số phương pháp Agile có xuất xứ và được sử
dụng hiệu quả ngoài phạm vi phát triển phần mềm.

Agile methodology - 6 -



Hình 1: Mức độ phổ biến của các phương pháp (Nguồn: Forrester Research)
1.2 Phương pháp 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ẹ”.
- Vào tháng Hai năm 2001, mười bảy nhà phát triển phần mềm đã 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át triển phần mềm linh
hoạt. Đây là cột mốc quan trọng của agile. Dù trước đó, các phương pháp
agile như XP, Scrum, v.v. đã được sử dụng thành công ở rất nhiều nơi,
nhưng phải tới khi có s
ự xuất hiện của “Tuyên ngôn Agile”, cùng với sự ra đời
của các hiệp hội chuyên ngành agile như Agile Alliance hay Scrum Alliance,
các phương pháp agile mới có một sự phát triển vượt bậc. Văn bản này rất
ngắn, dễ hiểu, và rất quan trọng vì nó đưa ra các giá trị cốt lõi nhất mà toàn bộ
các nhà lý thuyết cũng như những người thực hành Agile tuân thủ; mặc dù
các phương pháp họ đề xuất hoặc sử dụng trong thực tiễn có th
ể rất khác
nhau.

Agile methodology - 7 -


1.2.1 Tuyên ngôn Agile
- “Chúng tôi đã phát hiện ra 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.”
Qua công việc này, các nhà sáng tạo Agile đã đi đến việc đánh giá cao:
- Cá nhân và sự tương tác hơn là quy trình và công cụ
- Phần mềm chạy tốt hơn là tài liệu đầy đủ:
- Cộng tác với khách hàng hơn là đàm phán hợp đồng:
- Phản hồi với các thay đổi hơn là bám sát kế hoạch:
- “Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn
các mục ở bên trái.”
- Mười hai nguyên tắc phía sau tuyên ngôn Agile:
- “Chúng tôi tuân theo các nguyên tắc sau đây”
o Ưu tiên cao nhất của chúng tôi 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ị.
o Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá 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.
o 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.
o
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.
o 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ọ để hoàn
thành công việc.
o 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.

o Phần mềm chạy tốt là thước đ
o chính của tiến độ.
o 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.
o 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.
o 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.
o 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.
o Nhóm phát triển 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.

Agile methodology - 8 -


- Các nguyên lý này, cùng với năm điểm cốt lõi trong "Tuyên ngôn Agile" sẽ
dẫn đường cho các nhà thực hành agile (agile practictioner) vận dụng tốt các
phương pháp agile vào thực tiễn. Các nguyên lí này được Jeff Sutherland
diễn giải chi tiết như sau:
1.2.1.1 Cá nhân và Sự tương tác
- Cá nhân và sự tương tác giữa họ là cốt yếu để nhóm đạt được hiệu suất
cao. Các nghiên cứu về “bão hòa truyền thông” trong một dự án cho thấy
rằng, khi không có vấn đề trong truyền thông, nhóm có thể thực hiện công
việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình. Để tạo
điều kiện cho truyền thông, các phương pháp linh hoạt thường xuyên sử
dụng chu trình thanh-tra-và-thích-nghi. Chu trình này có thể diễn ra hằng

phút với lập trình cặp (pair-programming), hằng giờ với tích hợp liên tục
(continuos integration), hằng ngày với standup metting (đứng họp), hằng
phân đoạn với các buổi họp sơ kết và cải tiến.
- Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ
các vấn đề về truyền thông. Chu kỳ thanh-tra-và-thích-nghi làm việc tốt chỉ
khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:
- Tôn trọng giá trị của mỗi cá nhân
- Trung thực trong truyền thông
- Minh bạch về dữ liệu, hoạt động, và quyết định
- Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm
- Cam kế
t với nhóm và các mục tiêu của nhóm
- Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi
trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các
thành viên của nhóm phải thể hiện chúng. Chỉ khi đó nhóm mới có thể phát
huy được hết tiềm năng của mình.
- Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng.
Hầu hết các nhóm tránh lé s
ự thật, sự minh bạch, và tin tưởng vào các
chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột
xuất phát từ truyền thông trung thực trước đây. Để chống lại những khuynh
hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những
xung đột tích cực. Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà
còn đem lại các lợi ích khác:

Agile methodology - 9 -


- Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở
ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và

sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ưu tiên.
- Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tưởng mâu thuẫn lẫn nhau,
một hiện tượng được nghiên cứu và viết thành tài liệu bởi Takeuchi và
Nonaka, những người cha đỡ đầu của Scrum.
- Việc hướng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt và giải
quyết các vấn đề về xung đột.
- Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi người đồng ý với mục
tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng như
nhóm.
- Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng. Đó là khi mà các
cá nhân và các nhóm được cam kết mà họ cảm thấy có trách nhiệm với
việc cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát
triển phần mềm. Các phương pháp linh hoạt tạo điều kiện cho việc cam kết
bằng cách khuyến khích các nhóm đưa ra một danh sách các công việc
được ưu tiên hóa, để họ tự quản lý công việc của mình, và tập trung vào
cải tiến về cách thực hiện các công việc đó. Thực hành là nền tảng của tự-
tổ-chức (self-organization), đó là động lực để đạt được kết quả trong một
nhóm agile.
- Để tạo ra các nhóm có hiệu suất cao, các phương pháp linh hoạt coi trọng
cá nhân và sự tương tác hơn là quy trình và công cụ. Thực tế cho thấy
rằng, tất cả các phương pháp linh hoạt tìm kiếm sự gia tăng trong truyền
thông và cộng tác thông qua việc kiểm tra thường xuyên các chu trình
thanh-tra-và-thích-nghi. Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt
khi mà các nhà lãnh đạo agile khuyến khích các cuộc xung đột tích cực, thứ
cần thiết để xây dựng một nền tảng vững chắc cho sự trung thực, tính minh
bạch, lòng tin, sự tôn trọng, và cam kết từ các nhóm agile của họ.
1.2.1.2 Phần mềm Chạy tốt hơn là Tài liệu Đầy đủ
- 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 Tuyên ngô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.

Agile methodology - 10 -


- 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”, cái thường được biết như là định nghĩa hoàn thành. Ở mức độ
cao, một phần của chức năng hoà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ử và có thể được vận hành bởi người dùng
cuối. Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị (unit
test) và kiểm thử hệ thống. Các nhóm tốt nhất còn bao gồm việc kiểm thử
tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong
định nghĩa hoàn thành đối với một phần chức năng. Thông qua nguồn dữ
liệu phong phú từ các dự án, một công ty CMMI Cấp độ 5 cho thấy việc xác
định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính
năng và theo độ ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi
tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi
tốc độ sản xuất và giảm các sai sót đến 40%. Điều này có được từ một
công ty có tỷ lệ sai sót thấp nhất thế giới.
- Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau
một khoảng thời gian nhất định. Đồng thuận với định nghĩa hoàn thành là
một trong những cách thực tế để nhóm agile mang lại hiệu suất và chất
lượng cao, cái cần thiết để hoàn thành mục tiêu này.
1.2.1.3 Cộng tác với Khách hàng hơn là Thương thảo Hợp đồng
- Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên
toàn thế giới. Đi
ều này được cho là vì các dự án nhỏ hơn và mức độ
chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin
phản hồi về phần mềm hoạt động một cách đều đặn hơn. Các tác giả của
bản Tuyên ngôn đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để

khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết
để dẫn tới thành công.
- Các phương pháp phát triển linh ho
ạt đã thúc đẩy giá trị này bằng cách đưa
vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát
triển. Lấy một ví dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng.
Sẽ là không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình
phát triển sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, được
gọi là Product Owner (chủ sản phẩm), để đại diện cho không chỉ tất cả
khách hàng trong trường hợp này mà còn bao gồm cả quản lý, dịch vụ

Agile methodology - 11 -


khách hàng, và các bên liên quan khác. Chủ sản phẩm có trách nhiệm cập
nhật danh sách yêu cầu về sản phẩm sau mỗi bốn tuần thời điểm mà nhóm
Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực tế
cùng phản hồi của khách hàng và các bên liên quan. Điều này cho phép
khách hàng có thể giúp định hình sản phẩm phần mềm đang được tạo ra.
- Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ. Họ có thể có
sẵn người sử dụng đầu cuối của công ty trong nhóm làm việc với họ hàng
ngày. Khoảng 10% thời gian, các tư vấn viên và nhóm nội bộ có thể tìm
được một người dùng cuối có thể làm việc với nhóm từng ngày. 90% thời
gian còn lại, họ phải cử ra người đại diện cho khách hàng. Người này,
được nhóm XP gọi là Customer (khách hàng), làm việc trực tiếp với người
dùng cuối để cung cấp một danh sách các tính năng rõ ràng cùng độ ưu
tiên cho phép đội phát triển có thể thực hiện.
- Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hàng
ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công
nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp

đôi so với các dự án truyền thống tính trung bình trên toàn thế giới. Các
phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã
tạo ra một vị trí đặc biệt trong đội hình phát triển để dành riêng cho vị khách
hàng đại diện này.
1.2.1.4 Phản hồi với Thay đổi hơn là Bám sát Kế hoạch
- Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài
lòng khách hàng cũng như mang lại những giá trị kinh doanh. Dữ liệu
ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án
bị thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án
truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng
theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ
thấy không thật sự đúng như những gì họ muốn. Luật Humphrey nói rằng
khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần
mềm hoạt động. Nếu khách hàng không nhìn thấy phần mềm hoạt động
cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin
phản hồi của họ ở thời điểm này. Các phương pháp phát triển linh hoạt tìm

Agile methodology - 12 -


kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông
tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển.
- Tất cả các phương pháp phát triển linh hoạt đều được tích hợp sẵn những
tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa
trên những thông tin phản hồi từ phía khách hàng cũng như bên đại diện
của khách hàng. Các kế hoạch được thiết kế để sao cho luôn cung cấp giá
trị kinh doanh cao nhất trước hết. Bởi vì 80% giá trị nằm trong 20% các tính
năng, một dự án phát triển linh hoạt chạy tốt có xu hướng kết thúc sớm,
trong khi hầu hết các dự án truyền thống thường kết thúc trễ. Kết quả là,
khách hàng thì vui vẻ hơn, và các nhà phát triển thì thích thú với công việc

của họ hơn. Các phương pháp phát triển linh hoạt dựa trên những hiểu biết
đó, để thành công hơn chúng phải có kế hoạch để thay đổi. Đó là lý do tại
sao chúng thiết lập các quy trình, chẳng hạn như Sơ kết và Cải tiến, được
thiết kế đặc biệt để thay đổi các ưu tiên thường xuyên dựa trên thông tin
phản hồi của khách hàng và giá trị kinh doanh.
1.2.1.5 Nền tảng 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. Kể từ thời điểm đó, Lean cũng đã nổi
lên như là một phương pháp linh hoạt có giá trị do vậy cũng được đưa vào
trong chiếc ô của các phương pháp Agile trong hình minh họa dưới đây.

Hình 2: Agile là chiếc ô – Các phương pháp được triển khai dưới chiếc ô này

- 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 nhau
để thực hiện các giá trị cốt lõi trong tuyên 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

Agile methodology - 13 -


đối tượng theo những cách khác nhau. Một cuộc khảo sát gần đây cho thấy
rằng, khoảng 50% học viên theo học phương pháp phát triển linh hoạt nói
rằng đội của họ đang làm Scrum, 20% khác nói rằng họ đang làm Scrum
với các thành phần của XP. Khoảng 12% nói rằng họ chỉ áp dụng XP. Do
có hơn 80% áp dụng phát triển linh hoạt trên toàn thế giới là sử dụng
Scrum và XP, nên bản MSF cho phát triển phần mềm linh hoạt phiên bản
5.0 tập trung vào quy trình cốt lõi và thực tiễn áp dụng của Scrum và XP.
- Scrum là một khung làm việc (framework) cho các quy trình phát triển linh

hoạt. Nó không bao gồm các vấn đề thực hành, kỹ thuật cụ thể. Ngược lại,
XP lại tập trung vào các kỹ thuật thực hành cụ thể nhưng không có một bộ
khung làm việc tổng thể cho quá trình phát triển. Điều đó không có nghĩa
rằng Scrum khuyên bạn không nên áp dụng các phương pháp thực hành
cụ thể hay là XP thì không có quy trình. Ví dụ, ban đầu Scrum áp dụng tất
cả các phương pháp thực hành mà bây giờ được biết đến như là XP. Tuy
nhiên, khung làm việc Scrum cho việc phát triển phần mềm được thiết kế
để có được một nhóm nghiên cứu bắt đầu trong hai ba ngày, trong khi thực
hành kỹ thuật phải mất nhiều tháng để thực hiện. Vì vậy, nó để lại câu hỏi
khi nào (hay không) để thực hiện các thực hành cụ thể đối với mỗi đội. Hai
đồng tác giả của Scrum là Jeff Sutherland và Ken Schwaber khuyến nghị
rằng Nhóm Scrum bắt đầu ngay lập tức và tạo ra danh sách các trở ngại và
kế hoạch cải tiến quy trình. Khi việc thực hành về kỹ thuật được xác định là
trở ngại, nhóm nên xem xét các phương pháp thực hành của XP như là
một cách để cải tiến. Các nhóm tốt nhất sử dụng Scrum bổ sung với thực
hành XP. Scrum giúp XP về mặt quy mô, XP giúp Scrum làm việc tốt hơn.
- Bảng sau cho thấy những thuật ngữ quan trọng tương ứng giữa Scrum và
XP.
Scrum XP
Chủ sản phẩm (Product Owner) Khách hàng (Customer)
Scrum Master Huấn luyện viên XP (XP coach)
Nhóm Nhóm
Sprint Phân đoạn (iteration)
Họp Kế hoạch Sprint (Sprint
Planning)
Trò chơi lập kế hoạch (Planning
Game)

Agile methodology - 14 -


1.2.2 Đặc trưng của Agile
- Có rất nhiều phương pháp agile với các hướng tiếp cận rất khác nhau. Bên
cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp
agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù
như công cụ tích hợp liên tục (continuous integration), kiểm thử đơn vị, mẫu
thiết kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng
hành vi (BDD), hay lập trình theo cặp v.v. để đảm bảo và gia tăng tính linh
hoạt. Tuy vậy các phương pháp này chia sẻ nhiều đặc trưng giống nhau
cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp
ứng cao trong suốt vòng đời của dự án.
1.2.2.1 Tính lặp (Iterative)
- 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
(được gọi là Iteration hoặc Sprint) 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. Có phương pháp như Scrum
thậm chí sử dụng phương pháp lập kế hoạch just-in-time trong quá trình
phát triển. Khi đó, thậm chí công việc lập kế hoạch, làm mịn kế hoạch được
thực hiện liên tục trong suốt quá trình làm việc.

Hình 3: Các phân đoạn lặp đi lặp lại trong agile
1.2.2.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)
- 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 (gọi là potentially
shippable product increment of functionality). 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

Agile methodology - 15 -


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. Khác
với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các
chức năng tại thời điểm kết thúc dự á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.
1.2.2.3 Tính thích ứng (hay thích nghi – adaptive)
- 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 quá trình
phát triển (yê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 . Ví dụ, trong
Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển
sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu
mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có
thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp
theo. Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi.
1.2.2.4 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(cross-functionality) và tự tổ
chức(self-organizing)
. 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). Nhóm tự tổ chức có
nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển
phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản
lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất.
1.2.2.5 Quản lý tiến trình thực nghiệm (Empirical Process Control)
- 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
toán lý thuyết hay các tiền giả định (prescription). 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. Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life
cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các

Agile methodology - 16 -


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
soát được tiến trình, và nâng cao năng suất lao động.
1.2.2.6 Giao tiếp trực diện(face-to-face communication)
- Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ,
từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ
thống v.v. Agile không phản đối công dụng của công việc tài liệu hóa,
nhưng đá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 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ỏ (ít hơn mười hai người, một nhóm lớn
thường được phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông
lượng giao tiếp tối đa) để đơ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 dự án lớn muốn dùng agile thường phải phân thành
nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung.
Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức
ưu tiên giữa các nhóm.
- Các nhóm phát triển thường tạo ra các thói quen và cơ chế 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, Daily Scrum, standup
meeting). Tại đây, tất cả các thành viên được yê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 quá trình làm việc. Khi cơ chế này được thực hiện hiệu quả,
nhóm luôn luôn 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.



Agile methodology - 17 -


1.2.2.7 Phát triển dựa trên giá trị (value-based development)
- 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í dụ, một
nhóm thấy rằng có thể không cần phải viết ra tất cả các thiết kế của hệ
thống, mà họ chỉ cần phác thảo các thiết kế này lên bảng, rồi cùng nhau
triển khai các chức năng của hệ thống. Nhưng nếu như chủ sản phẩm
quyết định rằng, khi chuyển giao sản phẩm, nhóm phát triển phải kèm theo

thiết kế chi tiết của hệ thống vì chúng chiếm 20% giá trị của dự án theo yêu
cầu của khách hàng, và vì khách hàng cần nó để chứng minh tính đúng
đắn của các chức năng, và để phát triển tiếp các phân hệ tiếp theo của sản
phẩm; thì nhóm phát triển sẽ phải thực hiện việc tài liệu hóa đầy đủ.
- Để 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 sớm nhất có thể 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.
1.3 So sánh Agile và các phương pháp hiện tại
- Phương pháp phát triển linh hoạt đôi khi bị đánh giá là thiểu tính kỉ luật.
Những nhận xét như vậy gây ra sự hiểu lầm. Để hiểu vấn đề một cách đ
úng
đắn, ta có thể hình dung rằng những phương pháp phát triển phần mềm hiện
có nằm trên một trục đi từ “khả năng thích ứng” tới “khả năng dự đoán trước”
thì phương pháp phát triển linh hoạt nằm về phía “khả năng thích ứng”.
- Những phương pháp nằm về phía “khả năng thích ứng” có thể thích
nghi nhanh chóng với những thay đổi của thực tế. Khi mà những yêu cầu
củ
a dự án thay đổi, nhóm thực hiện cần phải có những điều chỉnh thích hợp.
Họ sẽ gặp khó khăn để mô tả chính xác những gì sẽ xảy ra trong tương lai.
Tương lai càng xa thì sự khó khăn đó càng lớn. Nhóm thực hiện có thể báo
cáo chính xác công việc sẽ được tiến hành trong tuần tới nhưng chỉ có thể
báo cáo những tính năng nào sẽ được xây dựng trong tháng tới. Và khi được
hỏi về phiên bản phần mềm trong 6 tháng tiếp theo thì họ chỉ có thể đưa ra
được những tính năng chung nhất hoặc đưa ra kinh phí dự kiến.

Agile methodology - 18 -

- Trong khi đó những phương pháp nằm về phía “khả năng dự báo trước”
trong hợp đồng với khách hàng, tập trung vào xây dựng một kế hoạch chi tiết
cho tương lai. Nhóm thực hiện dự án có thể báo cáo chính xác những tính
năng và công việc cần thực hiện trong toàn bộ quy trình phát triển phần mềm.
Bản kế hoạch được tối ưu hoá cho những mục tiêu đã đặt ra lúc đầu và sự
thay đổi có thể khiến cho công việc đã hoàn thành trở nên vô nghĩa. Nhóm
phát triển dự án sẽ xây dựng một bảng kiểm soát những thay đổi để đảm bảo
rằng chỉ những thay đổi có giá trị mới được xem xét đến.
1.3.1 Phân biệt với mô hình thác
n
ư
ớ
c

- Phương pháp phát triển linh hoạt có vài điểm chung nhỏ với mô hình thác
nước. Hiện nay mô hình thác nước vẫn được sử dụng phổ biến. Nó được
lên kế hoạch trước và được tiến hành lần lượt qua các bước nắm bắt yêu
cầu, phân tích, thiết kế, viết code và kiểm thử một cách nghiêm ngặt. Vấn đề
của mô hình thác nước là sự phân chia cứng nhắc dự án thành các giai
đoạn riêng biệt và do đó rất khó khăn khi muốn thay đổi yêu cầu. Chi phí để
thực hiện lại rất đắt. Điều đó có nghĩa là mô hình thác nước không thích
hợp khi mà không thể xác định chính xác, rõ ràng yêu cầu của khách
hàng hoặc những yêu cầu có thể thay đổi trong quá trình tiến hành dự
án. Phương pháp phát triển linh hoạt, trong hợp đồng, sẽ nhanh chóng
đưa ra sản phẩm hoạt động ổn định với những tính năng cơ bản giúp khách
hàng sớm được s
ử dụng sản phẩm phục vụ mục đích của họ. Sau đó
nhóm phát triển tiếp tục nâng cấp sản phầm trong suốt thời gian tiến hành
dự án, hàng tuần hoặc tháng sẽ bổ sung những tính năng được được phát

triển và kiểm thử toàn diện.
- Theo khía cạnh này, những người chỉ trích phương pháp linh hoạt có thể
quả quyết rằng những tính năng này không được xem xét trong quy mô toàn
dự án. N
ếu người tài trợ dự án lo ngại về thời gian hoàn thành toàn bộ dự
án đã được định trước hay ngân sách đầu tư cho dự án thì phương pháp
linh hoạt có thể không thích hợp. Tuy nhiên lời chỉ trích này gặp phải sự
phản đối của cộng đồng phát triển phần mềm linh hoạt. Họ cho rằng với
SCUM (một phương pháp phát triển linh hoạt sẽ được tìm hiểu kĩ hơn ở
phần sau), nhóm phát tri
ển có thể đấy nhanh tiến độ thực hiện và liên tục cải
thiện kế hoạch chiến lược.

Agile methodology - 19 -


- Vài nhóm phát triển phần mềm linh hoạt sử dụng mô hình thác nước với
quy mô nhỏ trong các giai đoạn của dự án.
1.3.2 Phân biệt với “Cowboy
co
d
i
n
g
”

- Khi những thành viên trong nhóm làm bất cứ điều gì họ cho là đúng, không
tuân thủ kỷ luật, nguyên tắc thì người ta gọi đó là “Cowboy coding”.
Sự thường xuyên đánh giá lại các kế hoạch của phương pháp phát triển linh
hoạt, sự chú trọng vào giao tiếp mặt đối mặt trực tiếp và vấn đề tài liệu

hướng dẫn đi kèm khá ít đôi khi khiến cho người dùng lầm tưởng nó với
“cowboy coding”. Tuy nhiên thực tế là nhóm phát triển phần mềm linh hoạt
luôn làm việc theo một quy trình đã được vạch rõ ( và thường rất kỷ luật và
nghiêm ngặt).
- Giống như tất cả các phương pháp phát triển phần mềm, kỹ năng và kinh
nghiệm của người sử dụng quyết định để mức độ thành công hoặc thất bại
của sản phẩm. Càng có nhiều hệ thống kiểm soát khắt khe được nhúng vào
trong quy trình phát triển thì trách nhiệm của người sử dụng càng được nâng
cao.
2. Mô hình hóa với Agile
2.1 Các giá trị của mô hình hóa Agile
2.1.1 Trao đổi thông tin
- Việc trao đổi thông tin một cách hiệu quả đóng một vài trò cực kì quan trọng
đối với nhóm phát triển cũng như đối với các bên liên quan

Agile methodology - 20 -



Hình 4: Một buổi họp nhóm hằng ngày theo quy trình Scrum
2.1.2 Tính đơn giản
- Nhóm phát triển cần cố gắng tìm ra các giải pháp đơn giản nhất có thể nhằm
thỏa các yêu cầu đã đề ra.

Agile methodology - 21 -



Hình 5: Cách mô hình hóa UI cho một ứng dụng bằng các thẻ và bảng trắng
2.1.3 Sự phản hồi

- Cần thu nhận các phản hồi thường xuyên và sớm nhất có thể.

Hình 6: Các thức phản hồi trong một Sprint của Scrum
2.1.4 Tính can đảm
- Nhóm phát triển cần can đảm áp dụng tất cả các kỹ thuật mới nhất trong việc
đưa ra quyết định cho một giải pháp.

Agile methodology - 22 -


2.1.5 Tính khiêm tốn
- Mỗi thành viên trong nhóm phát triển cần khiêm tốn và chấp nhận rằng một
cá nhân không thể nắm bắt tất cả mọi thứ. Vì vậy mỗi thành viên trong nhóm
đều có một giá trị quan trọng trong việc phát triển dự án.

Hình 7: Mô hình các nhóm liên chức năng
2.1 Các nguyên tắc cốt lõi của mô hình hóa agile
2.1.1 Mô hình hóa có mục đích
- Sẽ là không cần thiết nếu tạo một mô hình mà mô hình đó không thể xác
định được lý do cần tạo và đối tượng sử dụng.
2.1.2 Sử dụng vốn đầu tư của các bên liên quan với hiệu quả cao nhất
- Các bên liên quan cần có sản phẩm phần mềm phù hợp với nhu cầu của họ
bởi họ là đối tượng đã đầu tư tài nguyên (thời gian, tiền bạc, công cụ, v.v )
và dự án. Chính vì vậy họ đáng được hưởng một sản phẩm tốt dựa trên
nguyên tắc sử dụng hợp lý, hiệu quả tài nguyên và tránh việc phung phí tài
nguyên.
2.1.3 Sẵn sàng đối mặt với các thay đổi
- Sẽ là hoàn toàn bình thường nếu như nhóm phát triển nhận được một yêu
cầu mới. Nhóm phát triển sẽ xem điều đó như một bước tiến hóa của hệ
thống và xem xét đến độ ưu tiên cho các thay đổi.

2.1.4 Thay đổi theo hướng tiếp cận tăng trưởng
- Trong việc đối mặt với các thay đổi, cần chia công việc ra thành từng phần
nhỏ, đánh giá độ ưu tiên và sắp xếp trong các khoảng thời gian hợp lý thay
vì dồn hết tất cả lại trong một lần bàn giao sản phẩm.
2.1.5 Áp dụng đa mô hình
- Mỗi mô hình có điểm mạnh và điểm yếu riêng của nó và sẽ phù hợp với
một hoàn cảnh nhất định. Các phần mềm hiện nay có cúc trúc rất phức tạp

Agile methodology - 23 -


và không một công cụ mô hình hóa nào có thể đáp ứng được cho tất cả
các trường hợp mô hình hóa. Chính vì vậy để việc mô hình hóa được hiệu
quả chúng ta cần sử dụng kết hợp nhiều mô hình để mô hình hóa các hệ
thống phần mềm. Mỗi mô hình sẽ đóng một vai trò trong việc diễn tả một
khía cạnh của hệ thống.
2.1.6 Gọn nhẹ đến mức tối thiểu
- Mô hình hóa theo kiểu gọn nhẹ đến mức tối thiểu nghĩa là chúng ta cần tạo
một số lượng mô hình và tài liệu vừa đủ.
- Việc tạo và lưu trữ quá nhiều mô hình, tài liệu không cần thiết cũng đồng
nghĩa với việc chúng ta sẽ phải tốn thời gian cho việc cập nhật các mô
hình, tài liệu đó theo thời gian.
2.1.7 Phần mềm chạy tốt là mục tiêu chính
- Coi phần mềm chạy được là mục tiêu chính là một nguyên tắc cốt lõi là bởi
vì mục tiêu chính của toàn bộ quá trình phát triển phần mềm chính là sản
xuất ra những phần mềm chất lượng cao phù hợp với yêu cầu của các bên
liên quan theo một cách thức hiệu quả nhất. Chính vì vậy việc mô hình hóa
cần bám sát mục tiêu này. Bất kì hoạt động mô hình hóa nào không trực
tiếp đóng góp vào thành quả nhằm sản xuất ra các sản phẩm có chất lượng
cần được cân nhắc loại bỏ ra khỏi quá trình phát triển.

2.1.8 Mục tiêu thứ hai là sẵn sàng nguồn lực cho các giai đoạn kế tiếp
- Một sự án có thể đi đến bờ vực thất bại thậm chí nhóm phát triển đã bàn
giao một hệ thống hoạt động ổn định cho người dùng, thỏa tất cả các yêu
cầu mà các bên liên quan đặt ra.
- Lý do chính của sự thất bại là hệ thống không đủ mạnh để đáp ứng được
sự nâng cấp lặp đi lặp lại theo thời gian. Chính vì vậy cần chuẩn bị đầy đủ
các mô hình, tài liệu cho việc sẵn sàng phát triển hệ thống trong những chu
kỳ tiếp theo.
2.1.9 Chất lượng trong công việc
- Sự luộm thuộm trong công việc sẽ dẫn đến việc khó khăn trong nâng cấp
ứng dụng cũng như sự không hài lòng từ phía khách hàng bởi vì hệ thống
có khả năng dễ sụp đổ. Chính vì vậy việc tạo ra các mô hình, tài liệu có
chất lượng, độ ổn định cao đóng một vài trò hết sức quan trọng.
2.1.10 Sự phản hồi nhanh chóng

Agile methodology - 24 -


- Cần có sự liên kết chặt chẽ với khách hàng nhằm nắm bắt sự phản hồi liên
tục từ phía khách hàng. Sự phản hồi nhanh chóng sẽ giúp phát hiện ra
nhiều vấn đề trước lúc nó trở nên nghiêm trọng hơn.
- Trong việc mô hình hóa, cùng làm việc với khách hàng sử dụng các kĩ thuật
"mô hình hóa chia sẻ" như bảng trắng, thẻ CRC, thẻ ghi chú sẽ giúp hỗ trợ
việc ghi nhận các phản hồi một cách nhanh chóng.
2.2 Các phương pháp thực hành của mô hình hóa agile
2.2.1 Sự tham gia tích cực của các bên liên quan
- Một dự án thành công cần sự hỗ trợ ở mức cao bởi các bên liên quan. Sự
quản lý cấp cao yêu cầu hỗ trỡ cả trong lẫn ngoài đối với dự án, các nhân
viên hỗ trợ và vận hành hệ thống cần làm việc một cách chủ động với nhóm
phát triển để làm cho môi trường vận hành sản phẩm thực có thể sẵn sàng

để cài đặt sản phẩm trên nó, các nhóm phát triển các hệ thống khác cần nỗ
lực trong việc hỗ trợ tích hợp, các nhà phát triển chuyên nâng cấp, bảo
dưỡng cần phải thông thạo công nghệ và kĩ thuật được dùng trong dự án.
2.2.2 Dùng các công cụ đơn giản nhất
- Rất nhiều mô hình có thể được vẽ trên bảng, trên giấy. Bất cứ khi nào chúng
ta muốn lưu trữ một lược đồ, chỉ cần chụp lại lược đồ với một máy ảnh số
hay vẽ trên giấy.
- Giá trị của một lược đồ là để làm rõ một vấn đề nào đó, và một khi vấn đề đã
được giải quyết, lược đồ sẽ không cần nhiều giá trị nữa. Chính vì vậy không
nên áp dụng nhiều công cụ mô hình hóa phức tạp.
2.2.3 Cộng tác trong việc mô hình hóa
- Mục tiêu của mô hình hóa là làm rõ một vấn đề hoặc để diễn đạt các ý tưởng
cho những người khách trong nhóm. Vì vậy hóm phát triển cần làm việc
cùng nhau để tạo một bộ các mô hình cơ bản cho dự án.
2.2.4 Chứng minh mô hình bằng mã nguồn
- Mô hình là một thực thể trừu tượng và nên phản ánh chính xác một khía
cạnh của sản phẩm thực. Vì vậy để biết được mô hình có thực sự hoạt động
hay không, cần kiểm nghiệm đó với chính các mã lệnh được viết ra từ nó.
2.2.5 Sử dụng các artifact một cách thích hợp
- Artifact là các sản phẩm phụ được tạo ra trong quá trình phát triển phần
mềm.

Agile methodology - 25 -


- Mỗi artifact chẳng hạn như sơ đồ trạng thái của UML, ca sử dụng "use
case", mã nguồn, lược đồ luồng DFD có điểm mạnh và điểm yếu riêng của
nó. Chính vì vậy mỗi artifact chỉ thích hợp trong một ngữ cảnh cụ thể nào đó.
2.2.6 Tạo nhiều mô hình song song
- Không có một mô hình đơn lẽ nào có thể phù hợp với tất cả các yêu cầu mô

hình hóa vì mỗi mô hình có điểm mạnh và điểm yếu riêng. Cần tạo song
song nhiều mô hình để các mô hình có thể có sự hỗ trợ lẫn nhau trong việc
làm rõ vấn đề và hơn nữa là một mô hình có thể được dùng để tạo nên một
mô hình khác.
2.2.7 Lặp lại việc thiết kế với artifact khác
- Bất kì khi nào gặp khó khăn trong việc diễn đạt ý tưởng thông qua một mô
hình, cần chuyển qua sử dụng một mô hình khác và lặp lại liên tục như vậy
cho đến khi tìm ra giải pháp. Bằng cách thay đổi góc nhìn, chúng ta có thể
thấy được nguyên nhân chúng ta gặp khó khăn trong việc tạo những mô
hình phía trước.
2.2.8 Mô hình hóa theo hướng tiếp cận tăng trưởng với độ tăng trưởng nhỏ.
- Việc mô hình hóa từng phần nhỏ giúp chúng ta có thể bàn giao sản phẩm
đến tay khách hàng nhanh hơn và vì thế có thể nhận được phản hồi từ phía
khách hàng nhanh hơn.
- Việc mô hình hóa được đặt trong nguyên tắc chung là mô hình hóa một phần
nhỏ, viết mã một phần nhỏ, kiểm thử mộts phẩn nhỏ, và bàn giao một phần
nhỏ. Sẽ không có một thiết kế lớn ngay từ đầu, cụ thể hơn là sẽ không có
một giai đoạn mô hình hóa nào kéo dài tới vài tuần hay vài tháng.
2.2.9 Sự sở hữu tập thể
- Tất cả mọi người trong nhóm phát triển đều có thể làm việc với bất kỳ mô
hình nào được tạo ra bởi nhóm. Điều này giúp tạo ra sự hiệu quả trong việc
truyền tải ý tưởng giữa các thành viên trong nhóm và cũng giúp phát hiện
sớm những sai sót trong quá trình mô hình hóa.
2.2.10 Tạo mô hình với nội dung đơn giản
- Cần tạo mô hình với nội dung đơn giản, giữ lại những nội dung thực sự cần
thiết mà vẫn đảm bảo mô hình được tạo mô tả đầy đủ các yêu cầu của các
bên liên quan.
2.2.11 Trình bày mô hình một cách đơn giản