Nghiên cứu phương pháp lập trình cực hạn áp dụng cho các dự án thuê ngoài

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


NGUYỄN OEN


NGHIÊN CỨU PHƯƠNG PHÁP LẬP
TRÌNH CỰC HẠN ÁP DỤNG CHO CÁC DỰ
ÁN THUÊ NGOÀI




LUẬN VĂN THẠC SĨ







Hà Nội - 2011

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


NGUYỄN OEN

NGHIÊN CỨU PHƯƠNG PHÁP LẬP
TRÌNH CỰC HẠN ÁP DỤNG CHO CÁC DỰ
ÁN THUÊ NGOÀI


Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10


LUẬN VĂN THẠC SĨ


NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. Đỗ Trung Tuấn


Hà Nội - 2011
i


LỜI CẢM ƠN
Tôi xin đƣợc gửi lời cảm ơn sâu sắc tới Trung tâm Đào tạo Sau đại học và
các thầy cô giáo trong Khoa Công Nghệ Thông Tin, Trƣờng Đại học Công
Nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy và truyền đạt những kiến
thức, những kinh nghiệm quý báu trong suốt 2 năm học Cao học.
Tôi xin bày tỏ lòng cảm ơn chân thành tới tất cả các bạn bè, các thầy cô giáo,
các đồng nghiệp Khoa Công Nghệ Thông Tin, Trƣờng Đại học Công Nghệ, Đại
học Quốc Gia Hà Nội đã động viên, tạo điều kiện cho tôi trong suốt thời gian
thực hiện luận văn này.
Đặc biệt, tôi xin gửi lời cảm ơn sâu sắc nhất tới PGS.TS. Đỗ Trung Tuấn,

Khoa Toán Cơ Tin học, Trƣờng Đại học Khoa học Tự nhiên, Đại học Quốc Gia
Hà Nội, ngƣời thầy đã định hƣớng đề tài và tận tình hƣớng dẫn chỉ bảo tôi trong
suốt quá trình thực hiện luận văn cao học này.
Cuối cùng tôi xin dành một tình cảm biết ơn tới Bố, Mẹ và gia đình, những
ngƣời đã luôn luôn ở bên cạnh tôi, động viên, chia sẻ cùng tôi trong suốt thời
gian học cao học cũng nhƣ quá trình thực hiện luận văn cao học.
Hà Nội, ngày 10 tháng 05 năm 2011
Nguyễn Oen

ii


LỜI CAM ĐOAN
Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi. Các kết quả nêu
trong bản luận văn này là trung thực 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, ngày 10 tháng 05 năm 2011
Nguyễn Oen

iii


MỤC LỤC
LỜI CẢM ƠN i
LỜI CAM ĐOAN ii
MỤC LỤC iii
DANH MỤC KÝ HIỆU, TỪ VIẾT TẮT vi
DANH MỤC HÌNH VẼ vii
PHẦN MỞ ĐẦU 1
0. 1. Tính cấp thiết của đề tài 1

0. 2. Mục đích nghiên cứu 2
0. 3. Đối tƣợng và phạm vi nghiên cứu 3
0. 4. Phƣơng pháp nghiên cứu 4
0. 5. Cơ sở lý luận và thực tiễn 4
0. 6. Đóng góp của đề tài 4
0. 7. Kết cấu đề tài 5
Chƣơng 1 TỔNG QUAN PHƢƠNG PHÁP LẬP TRÌNH CỰC HẠN 6
1. 1. Khái niệm phƣơng pháp lập trình cực hạn 6
1. 2. Các nguyên tắc của XP: 7
1.2.1. Nguyên tắc trao đổi 7
1.2.2. Nguyên tắc phản hồi 8
1.2.3. Nguyên tắc đơn giản 8
1.2.4. Nguyên tắc tôn trọng 8
1.2.5. Nguyên tắc dũng cảm 8
1. 3. Các phƣơng pháp thực hành 9
1.3.1. Khách hàng cùng tham gia 9
1.3.2. Lập kế hoạch liên tục 10
1.3.3. Phát hành từng phần 10
1.3.4. Lập trình theo cặp 11
1.3.5. Phát triển định hƣớng kiểm thử 12
1.3.6. Tích hợp liên tục 13
1.3.7. Tái cấu trúc hệ thống 14
1.3.8. Sở hữu tập thể 15
1.3.9. Thiết kế đơn giản 16
iv


1.3.10. Hệ thống ký pháp 17
1.3.11. Làm việc lâu bền 17
1.3.12. Chuẩn hóa mã nguồn 18

1. 4. Vòng đời phƣơng pháp phát triển XP 19
1.4.1. Khám phá yêu cầu 19
1.4.2. Pha lập kế hoạch 21
1.4.3. Pha lặp để phát hành 24
1.4.4. Pha xuất xƣởng 24
1.4.5. Pha bảo trì 25
1.4.6. Pha kết thúc 25
1. 5. Đội dự án XP 25
1.5.1. Đại diện khách hàng 25
1.5.2. Ngƣời quản lý sản phẩm 26
1.5.3. Các chuyên gia nghiệp vụ 27
1.5.4. Ngƣời thiết kế giao diện 27
1.5.5. Lập trình viên 27
1.5.6. Ngƣời kiểm thử 28
1.5.7. Quản lý dự án/Hƣớng dẫn viên 28
1.5.8. Các thành viên khác 28
1. 6. Điều kiện để áp dụng 29
Chƣơng 2 PHẦN MỀM THUÊ NGOÀI VÀ XP 31
2. 1. Dịch vụ thuê ngoài 31
2.1.1. Khái niệm dịch vụ thuê ngoài 31
2.1.2. Lợi thế của dịch vụ thuê ngoài 31
2.1.3. Phát triển phần mềm thuê ngoài 33
2.1.4. Phát triển phần mềm thuê ngoài với XP 36
2. 2. Tổ chức phát triển phần mềm thuê ngoài với XP 37
2.2.1. Tổ chức khách hàng 37
2.2.2. Tổ chức đội phát triển thuê ngoài 38
2.2.3. Phân tách các nhóm trong dự án 40
2.2.4. XP tổ chức nhóm phát triển thuê ngoài 42
2. 3. Truyền thông trong dự án thuê ngoài 42
v

2.3.1. Truyền thống với khách hàng 43
2.3.2. Truyền thông giữa các nhóm 45
2.3.3. Truyền thông trong nhóm 48
2.3.4. Công cụ truyền thông 49
2. 4. Quản lý cấu hình cho XP 51
2.4.1. Tiến trình thƣờng nhật 52
2.4.2. Tiến trình tìm giải pháp 52
2.4.3. Tiến trình tái cấu trúc 52
2.4.4. Tiến trình phát hành 53
2. 5. Các vấn đề khác 54
2.5.1. Biến đổi văn hóa doanh nghiệp 54
2.5.2. Bổ xung thêm nhóm mới 55
2.5.3. Viết tài liệu dự án 55
Chƣơng 3 ỨNG DỤNG XP TRONG DỰ ÁN THUÊ NGOÀI 57
3. 1. Môi trƣờng áp dụng 57
3. 2. Mô hình tổ chức 57
3. 3. Các dự án thực nghiệm 59
3.5.1. Dự án tƣơng tác liên chi nhánh InterBranch 59
3.5.1. Dự án bảng khai báo công việc TimeSheet 64
3.5.2. Dự án lập kế hoạch toàn hàng VIB_Planing 69
3.5.3. Dự án ngân hàng điện tử VIB4U 73
3. 4. Đánh giá chung 78
KẾT LUẬN 81
TÀI LIỆU THAM KHẢO 82
Tiếng việt 82
Tiếng anh 82

vi


DANH MỤC KÝ HIỆU, TỪ VIẾT TẮT


BPO
Business process
outsourcing
Quy trình kinh doanh thuê ngoài
CM
Configuration
Management
Quản lý cấu hình
RFP
Request For Proposal
Yêu cầu đề xuất
SOW
Statement Of Work
Đề xuất các bƣớc công việc
XP
eXtreme Programming
Lập trình cực hạn hay lập trình cƣờng độ cao
VIB
Việt Nam International
Bank
Ngân Hàng Quốc Tế VIB
OTP
One Time Password

Mã số đƣợc dùng 1 lần duy nhất
RUP
Rational Unified
Process
Quy trình phát triển phần mềm thống nhất
vii


DANH MỤC HÌNH VẼ
Hình 0-1 Tiêu chí thành công của dự án phần mềm 3
Hình 1-1 Các phƣơng pháp thực hành trong XP 19
Hình 1-2: Vòng đời dự án theo XP 19
Hình 1-4 Pha khám phá yêu cầu 20
Hình 1-5 Pha lập kế hoạch 22
Hình 1-6 Lên kế hoạch phát hành 23
Hình 1-7 Lên kế hoạch bƣớc lặp 24
Hình 2-1 Tổ chức khách hàng áp dụng thuê ngoài 37
Hình 2-2 Mô hình từ xa 38
Hình 2-3 Mô hình tại chỗ 39
Hình 2-4 Phân tách nhóm trong XP 41
Hình 2-5 Truyền thông trong XP 43
Hình 2-6: Vấn đề tích hợp 53
Hình 3-1 Mô hình tổ chức chuyên trách dự án 57
Hình 3-2 Mô hình tổ chức theo chức năng 58
Hình 3-3 Mô hình tổ chức theo dạng ma trận 59
Hình 3-4 Biểu đồ đánh giá kết quả dự án 79

1

PHẦN MỞ ĐẦU
0. 1. Tính cấp thiết của đề tài
Trong những năm gần đây, khi công nghệ thông tin càng ngày càng phát
triển, phần mềm thực sự trở thành một phần không thể thiếu trong các doanh
nghiệp. Mỗi bộ phận trong mỗi doanh nghiệp đều phụ thuộc vào phần mềm để
hỗ trợ việc phát triển, sản xuất, quảng cáo và tiếp thị các sản phẩm và dịch vụ
của họ. Với tốc độ phát triển đến chóng mặt của lĩnh vực công nghệ thông tin và
truyền thông trên cả các hệ thống phần cứng và phần mềm nhằm đáp ứng nhu
cầu ngày càng phức tạp của công việc cũng nhƣ cuộc sống đòi hỏi phải có
những phƣơng pháp phát triển tốt hơn nhằm đảm bảo cho sự thành công của các
dự án công nghệ thông tin.
Theo thống kê của Standish Group, Mỹ (2000) [6]: Trên 350 công ty với hơn
8000 dự án phần mềm có: 31% dự án phần mềm bị huỷ bỏ trƣớc khi đƣợc hoàn
thành. Với các công ty lớn, chỉ có khoảng 9% tổng số các dự án hoàn thành
đúng tiến độ và trong ngân sách dự án (với các công ty nhỏ, tỷ lệ này vào
khoảng 16%).
Báo cáo của Ngân hàng thế giới cho biết, 85% các dự án tin học hoá quản lý
hành chính ở các nƣớc đang phát triển đã thất bại hoặc một phần hoặc hoàn
toàn. Ở Việt Nam, điển hình là đề án 112 – đề án tin học hóa công tác quản lý
nhà nƣớc đã gặp thất bại hoàn toàn. Và còn rất nhiều các dự án tin học khác
cũng gặp thất bại, chậm triển khai, không đạt đƣợc mục tiêu đề ra[4].
Việc phát triển phần mềm thỏa mãn chất lƣợng, tiến độ, và kinh phí là rất
khó, đòi hỏi rất nhiều yếu tố trong đó việc áp dụng một phƣơng pháp phát triển
thích hợp là một trong những nhân tố mang tính quyết định đến thành công của
dự án. Hiện nay có rất nhiều các phƣơng pháp phát triển dự án đang đƣợc áp
dụng trong các doanh nghiệp phát triển phần mềm ở Việt Nam từ phƣơng pháp
phát triển hạng nặng đƣợc thiết lập trên các tiêu chuẩn ISO9001, mô hình trƣởng
thành về năng lực - CMMI, quy trình phát triển phần mềm thống nhất (Rational
Unified Process) đến các phƣơng pháp phát triển hạng nhẹ nhƣ phƣơng pháp lập
trình cực hạn – XP, phát triển phần mềm có khả năng thích nghi, Trong xu thế

phát triển phần mềm thuê ngoài ngày càng nhiều, việc áp dụng các phƣơng pháp
phát triển hạng nặng đang trở nên khó khăn khi phát triển phần mềm thuê ngoài
hƣớng tới hình thức dịch vụ - các yêu cầu đƣợc thay đổi liên tục theo nhu cầu
của khách hàng – làm cho vấn đề giá thành cho sự thay đổi bị đội lên rất cao.
2


Trƣớc vấn đề đó, việc áp dụng các phƣơng pháp phát triển hạng nhẹ cho các
dịch vụ phát triển phần mềm thuê ngoài nhằm giải quyết vấn đề thay đổi liên tục
của yêu cầu ngƣời dùng đang nhận đƣợc sự quan tâm của đông đảo các nhà phát
triển, các doanh nghiệp phần mềm trong nƣớc. Đặc biệt là phƣơng pháp lập trình
cực hạn đã nhận đƣợc sự quan tâm nhiều nhất vì nó đã đề ra hai mục tiêu rất rõ
ràng và cần thiết cho việc phát triển công nghệ phần mềm:
 Một là phát triển sản phẩm một cách nhanh chóng: Với sự phát triển
hiện nay của nền kinh tế dựa trên tri thức, doanh nghiệp nào đƣa sản
phẩm ra thị trƣờng nhanh nhất sẽ chiếm đƣợc thị phần có lợi nhất. Phƣơng
pháp lập trình cực hạn sẽ giúp cho các nhà phát triển phần mềm rút ngắn
thời gian phát triển sản phẩm.
 Hai là phát triển sản phẩm đúng theo yêu cầu của khách hàng: Thực
tế cho thấy rằng nhiều sản phẩm phần mềm tuy đƣợc phát triển một cách
công phu nhƣng lại không đáp ứng đƣợc nhu cầu của ngƣời sử dụng.
Phƣơng pháp lập trình cực hạn đã đƣa ra các cơ chế cho phép sản phẩm
phát triển luôn phù hợp với yêu cầu của ngƣời sử dụng.
Tuy nhiên việc áp dụng phƣơng pháp lập trình cực hạn vào việc phát triển
phần mềm thuê ngoài vẫn có những trở ngại làm cho các nhà phát triển, doanh
nghiệp phần mềm nghi ngại. Nắm bắt tính cấp bách của việc áp dụng phƣơng
pháp lập trình cực hạn trong việc phát triển phần mềm thuê ngoài đã thôi thúc
em chọn đề tài: “Nghiên cứu phƣơng pháp lập trình cực hạn áp dụng cho các dự
án thuê ngoài” nhằm nghiên cứu sâu hơn về phƣơng pháp lập trình cực hạn và
tìm cách áp dụng vào việc phát triển phần mềm thuê ngoài.

0. 2. Mục đích nghiên cứu
Đề tài đƣợc đƣa ra nhằm mục đích chính là làm sao có thể áp dụng phƣơng
pháp lập trình cực hạn vào các dự án thuê ngoài thành công. Theo quan niệm
truyền thống, một dự án phần mềm đƣợc coi là thành công khi sản phẩm đƣợc
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.
Trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chí này nhƣng rút cuộc 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. Do đó,
ngoài các yếu tố truyền thống nói 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.
3



Hình 0-1 Tiêu chí thành công của dự án phần mềm
 Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm làm
việc say mê, phát triển khả năng cá nhân, mong muốn đóng góp công sức
và trí tuệ cho nhóm và tổ chức.
 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. Thành công về kỹ thuật cũng làm tăng chất lƣợng sản phẩm, tăng
hiệu quả phát triển sản phẩm.
 Thành công ở mức công ty đƣợc bảo đảm nhờ các thành công mà các
nhóm mang lại cho công ty. Ở mức này, thành công của công ty là sự
đóng góp của tất cả các thành viên vào sự phát triển của công ty.
Do đó, đề tài sẽ tập trung trả lời các câu hỏi:
 Đặc trƣng của phƣơng pháp lập trình cực hạn là gì?
 Tại sao áp dụng phƣơng pháp lập trình cực hạn cho các dự án thuê ngoài?
 Làm sao để phát triển thành công các dự án dự án thuê ngoài theo phƣơng
pháp lập trình cực hạn?

0. 3. Đối tƣợng và phạm vi nghiên cứu
Nhằm áp dụng thành công phƣơng pháp lập trình cực hạn vào các dự án thuê
ngoài, đề tài xác định đối tƣợng chính cần nghiên cứu là phƣơng pháp phát triển
phần mềm cực hạn trong phạm vi các dự án thuê ngoài. Bằng cách đặt vào môi
trƣờng phát triển một dự án phần mềm cụ thể giúp cho phạm vi nghiên cứu đƣợc
cụ thể hơn, rõ ràng hơn nhƣng chúng ta hoàn toàn có thể áp dụng cho các dự án
phần mềm phát triển phần mềm thuê ngoài khác bằng cách tổng quát hóa và
lƣợc bỏ đi các chi tiết riêng biệt mang tính môi trƣờng doanh nghiệp.
4


0. 4. Phƣơng pháp nghiên cứu
Dựa trên việc ứng dụng các lý luận phát triển phần mềm vào thực tiễn và đúc
rút ra các cách thức và kinh nghiệm nhằm chia sẻ cho cộng đồng cách thức phát
triển phần mềm thích hợp trong các dự án cụ thể nhằm giúp các nhà phát triển,
các doanh nghiệp phần mềm có những cách thức giải quyết những vƣớng mắc
trong quá trình áp dụng phƣơng thức phát triển phần mềm cực hạn cho các dự án
thuê ngoài.
0. 5. Cơ sở lý luận và thực tiễn
Về cơ sở lý thuyết, phƣơng pháp lập trình cực hạn dựa trên triết lý phát triển
phần mềm linh hoạt và hệ thống công cụ hỗ trợ ngày càng phát triển, phƣơng
pháp lập trình cực hạn đã phát triển thành một phƣơng pháp hoàn thiện, nhận
đƣợc sự quan tâm lớn của các nhà phát triển cũng nhƣ các tổ chức phát triển
phần mềm. Và thực tế cũng đã chứng minh những thành công của phƣơng pháp
lập trình cực hạn với việc phát triển các phần mềm có chất lƣợng tốt, đạt đƣợc
sự hài lòng cao của khách hàng.
Với đặc điểm của việc phát triển phần mềm thuê ngoài là phát triển các tính
năng phù hợp nhất với các yêu cầu của khách hàng mà các yêu cầu của khách
hàng thƣờng xuyên thay đổi thì việc áp dụng phƣơng pháp lập trình cực hạn
dƣờng nhƣ là một giải pháp hết sức hợp lý. Và thực tế là qua các dự án bƣớc đầu

áp dụng phƣơng pháp lập trình cực hạn, mặc dù còn gặp một vài khó khăn
vƣớng mắc nhƣng đã gặp hái đƣợc khá nhiều thành công, đƣa ra đƣợc những sản
phẩm phù hợp với yêu cầu của khách hàng đƣợc khách hàng và đƣợc khách
hàng đánh giá cao.
0. 6. Đóng góp của đề tài
Việc áp dụng phƣơng pháp lập trình cực hạn thành công vào việc phát triển
phần mềm thuê ngoài thực sự là một đóng góp quan trọng cho các tổ chức thuê
ngoài và cung ứng dịch vụ thuê ngoài. Điều này giúp cho khách hàng có đƣợc
phần mềm đúng nhƣ mong muốn, giúp cho tổ chức áp dụng đƣợc một phƣơng
thức phát triển phần mềm tốt, góp phần đảm bảo thành công cho việc phát triển
phần mềm, giúp cho lập trình viên phát triển đƣợc các kỹ năng chuyên môn và
tăng cƣờng khả năng giao tiếp không chỉ trong đội mà cả với khách hàng.
Hơn nữa, việc áp dụng thành công phƣơng pháp lập trình cực hạn vào việc
phát triển phần mềm thuê ngoài còn mở ra tiềm năng áp dụng phƣơng pháp lập
5


trình cực hạn vào các dự án phát triển phần mềm phân tán, nhiều nhóm cùng
phát triển hoặc phát triển các phần mềm mã nguồn mở.
0. 7. Kết cấu đề tài
Kết cấu của đề tài gồm các phần sau:
Phần 1: Tổng quan phƣơng pháp lập trình cực hạn
Phần 2: Phần mềm thuê ngoài và XP
Phần 3: Ứng dụng XP trong dự án thuê ngoài
6


Chƣơng 1 TỔNG QUAN PHƢƠNG PHÁP LẬP TRÌNH CỰC HẠN
1. 1. Khái niệm phƣơng pháp lập trình cực hạn
Phƣơng pháp lập trình cực hạn (XP) là một phƣơng pháp phát triển phần

mềm tuân thủ triết lý phát triển phần mềm linh hoạt (Agile). XP là phƣơng thức
lấy ngƣời lập trình làm trung tâm, nhấn mạnh đến các phƣơng pháp kỹ thuật
phát triển phần mềm. XP sử dụng nhóm nhỏ làm việc kết hợp bao gồm những
ngƣời lập trình, khách hàng, và các nhà quản trị để phát triển phần mềm có chất
lƣợng cao trong khoảng thời gian nhanh chóng.
Thƣớc đo đầu tiên của phƣơng pháp lập trình cực hạn là một chƣơng trình
chạy đƣợc. Từ thƣớc đo này, XP xây dựng năm nguyên tắc cần thiết cho sự
thành công là: sự giao tiếp, sự phản hồi, đơn giản hóa, sự tôn trọng và sự dũng
cảm. Có thể diễn giải các nguyên tắc trên nhƣ sau: “Một chƣơng trình chạy đƣợc
và cung cấp ngay cho khách hàng để nhận đƣợc các phản hồi cũng nhƣ các đề
xuất thay đổi từ phía khách hàng, ngƣời phát triển sẵn sàng, dũng cảm nhận các
thay đổi về yêu cầu, môi trƣờng và công nghệ để phát triển ra sản phẩm phù hợp
nhất với yêu cầu ngƣời dùng. Để làm đƣợc điều này, ngƣời phát triển phải luôn
luôn giao tiếp với khách hàng cũng nhƣ đồng đội của họ để đảm bảo mọi ngƣời
đều hiểu công việc cần làm là nhƣ nhau và kết quả mong muốn là giống nhau.
Đồng thời, họ phải thiết kế sao cho thật đơn giản và rõ ràng để dễ dàng truyền
đạt lại việc mình đang làm và sẽ làm cho đồng đội, ngƣời dùng hiểu đƣợc. Một
điều hết sức quan trọng nữa là việc tôn trọng những giá trị thu đƣợc dù là nhỏ
nhất. Áp dụng XP đòi hỏi đội dự án phải tôn trọng ý kiến đánh giá phản hồi của
ngƣời dùng; ngƣời dùng phải tôn trọng những giá trị mà đội dự án cung cấp vì
đó chƣa phải là sản phẩm cuối cùng nhƣng nó hàm chứa những cố gắng và nỗ
lực phát triển của đội dự án.” Trong phần “1.2 Các nguyên tắc của XP” tôi sẽ đi
sâu hơn vào từng nguyên tắc.
Để đạt đƣợc các giá trị mà những nguyên tắc ở trên đã đề ra cũng nhƣ đảm
bảo cho việc phát triển thành công dự án, XP đã xây dựng các phƣơng pháp thực
hành. Các phƣơng pháp thực hành đơn giản và hiệu quả kết hợp linh hoạt với
nhau đảm bảo đội dự án phát triển đúng hƣớng, giữ đƣợc các giá trị mà các
nguyên tắc đã đề ra. Trong phần “1.3 Các phƣơng pháp thực hành” tôi sẽ đề cập
đến từng phƣơng pháp thực hành cụ thể của XP.
Phƣơng pháp lập trình cực hạn hoạt động theo mô hình lặp, tăng trƣởng. Sản

phẩm đƣợc chia ra thành các phần tăng trƣởng nhỏ, mỗi phần đƣợc phát triển
7


trong vòng một hoặc vài tuần gọi là một vòng lặp. Với mỗi phần tăng trƣởng,
đội dự án thực hiện tất cả các hoạt động: tìm hiểu yêu cầu, lập kế hoạch, phân
tích, thiết kế, lập trình, kiểm thử và phát hành. Các hoạt động này gọi là các pha.
Mỗi pha chỉ kéo dài từ vài ngày đến một vài tuần. Với tiến trình hoạt động này,
đội dự án sẽ nhanh chóng nhận đƣợc phản hồi của khách hàng cũng nhƣ áp dụng
những thay đổi cần thiết trong các lần tăng trƣởng tiếp theo. Trong phần “1.4
Vòng đời của phƣơng pháp phát triển XP” tôi sẽ đề cập sâu hơn về vòng đời
phát triển của XP.
Trong một dự án phần mềm, những hiểu biết về sản phẩm luôn đƣợc nắm giữ
bởi nhiều cá nhân. XP thừa nhận thực tế này bằng cách tạo ra một nhóm làm
việc hỗn hợp với đầy đủ các vai trò cần thiết. Một đội dự án XP thƣờng đƣợc lập
và hoạt động theo kiểu tự tổ chức dựa trên các giai đoạn và công việc khác nhau.
Tôi sẽ đề cập về vấn đề này trong phần “1.5 Đội dự án XP”.
1. 2. Các nguyên tắc của XP:
XP phát triển dựa trên các quy tắc. Nhƣng XP không là một bộ quy tắc mà là
một cách để làm việc hài hòa với các giá trị cá nhân và doanh nghiệp. Bắt đầu
với các nguyên tắc đƣợc liệt kê ở dƣới đây, sau đó tùy từng dự án mà đội dự án
có thể thêm các nguyên tắc riêng bằng cách thể hiện những nguyên tắc của XP
trong những thay đổi theo nguyên tắc của dự án[1].
1.2.1. Nguyên tắc trao đổi
Phƣơng pháp lập trình cực hạn chú trọng việc trao đổi thông tin một cách
“trong suốt” giữa các thành viên trong nhóm phát triển. Đề cao việc trao đổi trực
tiếp, giảm việc trao đổi gián tiếp hay hình thức thông qua các văn bản. Việc trao
đổi trực tiếp đƣợc yêu cầu rất cao, đặc biệt là trong các lần trao đổi với khách
hàng, giữa các đội. Trong XP, việc trao đổi trực tiếp đƣợc diễn ra liên tục, với
các lập trình viên là từng giây, từng phút họ làm việc cùng nhau nhƣ đƣợc nêu

trong phần “1.3.4 Lập trình theo căp”.
Với phƣơng pháp lập trình cực hạn, khách hàng tham gia trực tiếp vào việc
thực hiện dự án với tƣ cách là một thành viên chính thức của nhóm phát triển.
Khách hàng sẽ giúp nhóm phát triển hiểu và nắm bắt đƣợc và kịp thời các yêu
cầu của ngƣời sử dụng (cũng nhƣ sự thay đổi về yêu cầu) trong suốt quá trình
thực hiện dự án. Đồng thời, tất cả các thành viên đều tham gia vào mọi hoạt
8


động trong quá trình phát triển phần mềm. Điều này sẽ nâng cao tính năng động
của toàn bộ nhóm phát triển.
1.2.2. Nguyên tắc phản hồi
Phản hồi sớm và liên tục từ khách hàng cũng nhƣ từ nhóm phát triển giúp
cho dự án luôn đi theo đúng hƣớng. Phƣơng pháp lập trình cực hạn đều đặn giao
sản phẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể 'làm mịn' và
hoàn thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể. Với sự trợ giúp của
khách hàng, các nhà phát triển theo phƣơng pháp lập trình cực hạn xây dựng
một tập các phép thử phục vụ cho việc kiểm thử nghiệm thu một cách liên tục
trong suốt quá trình phát triển phần mềm.
Nguyên tắc trao đổi và nguyên tắc phản hồi là hai nguyên tắc tƣơng trợ lẫn
nhau. Từ việc trao đổi trực tiếp giúp cho đội dự án cũng nhƣ khách hàng hiểu
nhau hơn, nắm đƣợc yêu cầu và công việc đang tiến hành và từ đó đƣa ra đƣợc
các phản hồi tích cực giúp cho đội dự án hiểu công việc mình cần làm hơn.
1.2.3. Nguyên tắc đơn giản
Phƣơng pháp lập trình cực hạn đảm bảo chỉ phát triển những chức năng cần
thiết và những chức năng mà khách hàng yêu cầu. Phần thiết kế và mã nguồn
đƣợc thiết lập một cách đơn giản nhất, cho phép có đƣợc đặc tính mở cao nhằm
đáp ứng với các thay đổi liên tục và luôn duy trì đƣợc một tốc độ phát triển
nhanh trong suốt quá trình phát triển phần mềm.
1.2.4. Nguyên tắc tôn trọng

Mọi ngƣời cho và cảm nhận đƣợc sự tôn trọng xứng đáng với những gì họ đã
cống hiến. Tất cả mọi ngƣời đóng góp giá trị ngay cả khi nó chỉ đơn giản là sự
nhiệt tình. Các nhà phát triển tôn trọng chuyên môn của khách hàng và ngƣợc
lại. Nhà quản lý tôn trọng quyền nhận trách nhiệm của nhà phát triển và trao
quyền để họ thực hiện công việc của chính họ.
1.2.5. Nguyên tắc dũng cảm
Phƣơng pháp lập trình cực hạn cho rằng phải có lòng dũng cảm thì mỗi thành
viên mới thực hiện đƣợc các nguyên tắc kể trên. Lòng dũng cảm có nghĩa là dám
thay đổi, dám đề xuất cái mới, khi làm việc nhóm hay lập trình cặp đôi thì phải
chỉ ra cái sai, sửa lỗi ngay lập tức. Sẽ là hoàn toàn thất bại nếu áp dụng phƣơng
pháp lập trình cực hạn mà các thành viên không dám đề xuất cái mới, ngại
9


ngùng, cả nể không chỉ ra các lỗi phát sinh trong quá trình làm việc. Lòng dũng
cảm cũng là nói thật về tiến độ thực hiện và các dự toán về chi phí, thời gian,
nguồn lực để thực hiện. Dựa trên các nguyên tắc trao đổi, phản hồi và tôn trọng
lẫn nhau, mọi thành viên trong đội dự án sẽ dũng cảm nhận trách nhiệm và thực
hiện cùng nhau công việc của mình (không có một quyết định đơn độc và thực
hiện công việc một cách đơn độc, mọi thành viên trong đội dự án luôn đƣợc hỗ
trợ bởi các thành viên khác).
Cũng cần chú ý rằng, tuy phƣơng pháp lập trình cực hạn không chỉ ra một
cách rõ ràng, nhƣng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan
trọng để thực hiện có hiệu quả phƣơng pháp phát triển phần mềm cực hạn.
1. 3. Các phƣơng pháp thực hành
Dựa trên phƣơng pháp luận của phƣơng pháp phát triển linh hoạt và bốn
nguyên tắc ở trên, phƣơng pháp lập trình cực hạn đƣa ra các phƣơng pháp thực
hành, và điểm mạnh của phƣơng pháp lập trình cực hạn chính là đã kết hợp một
cách hợp lý các phƣơng pháp này. Mỗi một phƣơng án tuy đơn giản nhƣng rất
cần thiết phải nắm vững. Sau đây tôi xin đi vào từng phƣơng pháp thực hành [7]:

1.3.1. Khách hàng cùng tham gia
Chúng ta mong muốn khách hàng và nho
́
m phát triển làm việc chung với
nhau để họ hiểu các vấn đề của nhau và cùng giải quyết các vấn đề đó . Vâ
̣
y ai là
khách hàng? Khách hàng của một nhóm phát triển theo phƣơng pháp lập trình
cực hạn là một hoặc một nhóm ngƣời định nghĩa và xác định độ ƣu tiên của
chức năng hệ thống (hay sản phẩm). Đôi khi khách hàng là nhóm nhà phân tích
nghiệp vụ hoặc chuyên gia phát triển thị trƣờng làm việc cùng một công ty phần
mềm với nhóm phát triển. Đôi khi khách hàng là một đại diện của ngƣời dùng.
Đôi khi khách hàng cũng chính là ngƣời trả tiền. Nhƣng trong một dự án áp
dụng phƣơng pháp lập trình cực hạn, bất kể khách hàng là ai thì họ cũng là một
thành viên của nhóm phát triển.
Trong quá trình phát triển, khách hàng sẽ tham gia cách trực tiếp trong suốt
quá trình phát triển phần mềm. Sự tham gia này sẽ giúp cho nhóm phát triển có
điều kiện tham khảo trực tiếp ý kiến của khách hàng, trao đổi về hệ thống cần
đƣợc phát triển, tránh đƣợc nhầm lẫn trong cách hiểu về hệ thống cần phát triển.
Tình huống tốt nhất là khách hàng làm việc với nhóm phát triển trong cùng
một phòng. Hoặc chí ít là làm việc ở nơi nào đó cách độ một trăm bƣớc chân so
10


với phòng làm việc của nhóm phát triển. Khoảng cách càng xa thì càng khó thỏa
mãn điều kiện khách hàng là một thành viên trong nhóm phát triển. Nếu khách
hàng làm việc trong môt tòa nhà khác hoặc ở một quốc gia khác thì càng khó mà
yêu cầu họ tham gia cùng với nhóm. Nếu khách hàng không thể ở gần nhóm
phát triển thì hãy tìm ai đó sẵn lòng làm việc chung và có thể đứng ở vai trò của
một khách hàng thực thụ.

1.3.2. Lập kế hoạch liên tục
Trong XP, việc lập kế hoạch là một quá trình liên tục bao gồm 2 mức: lập kế
hoạch phát hành và lập kế hoạch lặp dựa tính năng và thứ tự ƣu tiên mà khách
hàng đƣa ra và ƣớc lƣợng công sức của nhóm phát triển. Tức là khách hàng xác
định giá trị, nhóm phát triển xác định chi phí cần bỏ ra.
Mục tiêu của kế hoạch phát hành là xác định các tính năng cần thiết cho lần
phát hành tiếp theo. Về cơ bản kế hoạch phát hành thực hiện nhƣ sau:
- Khách hàng xác định một danh sách các tính năng mong muốn hệ thống
đáp ứng;
- Nhóm phát triển ƣớc tính công sức cần bỏ ra để thực hiện danh sách các
tính năng mà khách hàng đã đƣa ra.
- Khách hàng sẽ quyết định xem thứ tự ƣu tiên cho việc thực hiện phát triển
các tính năng đó và đƣa ra kế hoạch phát hành tổng thể.
Mục tiêu của việc lập kế hoạch lặp cũng tƣơng tự nhƣ việc lập kế hoạch phát
hành, khách hàng sau khi xác định đƣợc yêu cầu cho một lần lặp mới sẽ trình
bầy cho nhóm phát triển, nhóm phát triển sẽ ƣớc lƣợng và phân chia công việc
để thực hiện.
1.3.3. Phát hành từng phần
Theo phƣơng pháp thực hành này, đội phát triển sẽ phát triển dần dần phần
mềm, từ đơn giản đến phức tạp, từ tập các tính năng hữu dụng nhỏ nhất. Từng
phần sẽ đƣợc chuyển giao sớm và thƣờng xuyên cho khách hàng để có đƣợc
ngay sự phản hồi từ phía khách hàng. Từ đó sẽ có thể điều chỉnh ngay đƣợc sản
phẩm cho phù hợp với yêu cầu của khách hàng. Khách hàng cũng có điều kiện
để bổ sung hay thay đổi yêu cầu phần mềm.
Việc phát hành sớm và thƣờng xuyên giúp cho khách hàng có thể sử dụng
đƣợc ngay các tính năng cần thiết mà không phải chờ cho đến khi có đầy đủ các
11


tính năng khác mới sử dụng đƣợc. Hơn nữa, do nhận đƣợc các bản phát hành

sớm, khách hàng có thể thấy đƣợc các yêu cầu cần thay đổi, các yêu cầu cần
thêm mới và đặc biệt là các yêu cầu đã lỗi thời để loại bỏ đi. Điều này sẽ tiết
kiệm rất lớn cho khách hàng về chi phí cũng nhƣ giúp đội dự án không phải phát
triển các tính năng đã lỗi thời, không cần thiết.
Việc phát hành từng phần nghĩa là nhóm dự án sẽ cố gắng để đƣa hệ thống
vào sản xuất càng sớm càng tốt và thậm chí cả trƣớc khi nó đã giải quyết toàn bộ
vấn đề. Họ cũng làm phát hành rất thƣờng xuyên, có thể đƣợc bất cứ nơi nào từ
một ngày đến một cơ sở hàng tháng. Những gì đƣợc phát hành không phải là
một bản giới thiệu để nhận xét rồi sau đó đặt sang một bên, mà là (một phần
của) một hệ thống thực tế mà khách hàng đƣa vào sử dụng sản xuất. Lý do là
điều này sẽ cung cấp lợi ích sớm và thƣờng xuyên cho khách hàng trong việc
cung cấp giá trị kinh doanh thực sự. Nó cũng sẽ cung cấp thông tin phản hồi
sớm và thƣờng xuyên đến các nhà phát triển để họ có thể tìm hiểu những gì
khách hàng muốn.
1.3.4. Lập trình theo cặp
Lập trình theo cặp nghĩa là tất cả mã nguồn sản phẩm đƣợc viết bởi các cặp
lập trình viên làm việc với nhau trên cùng một máy tính. Một thành viên của một
cặp sẽ giữ bàn phím và đánh mã nguồn. Thành viên còn lại của cặp sẽ quan sát
mã nguồn đƣợc đánh và tìm kiếm lỗi và cải tiến mã . Cả hai tƣơng tác với nhau
một cách liên tu
̣
c va
̀
cả hai cùng bận rộn cho công việc viết phần mềm . Vai trò
đƣợc thay đổi thƣờng xuyên . Ngƣời giữ phím sẽ mệt mỏi và dâ
̃
n đến dễ sai lầm .
Ngƣời còn lại (trong cặp) sẽ nhận lại bàn phím và điều khiển nó. Bàn phím đƣợc
hoán đổi nhiều lần giữa hai ngƣời trong một giờ . Mã nguồn kết quả đƣợc thiết
kế và đƣơ

̣
c viết bơ
̉
i cả hai ngƣơ
̀
i. Công sức của cả hai là nhƣ nhau.
Mối quan hệ theo cặp sẽ đƣợc thay đổi ít nhất một lần trong ngày để mỗi lập
trình viên đƣợc làm việc ít nhất với hai ngƣời trong ngày. Xuyên suốt một bƣớc
lặp của phƣơng pháp lập trình cực hạn, mỗi thành viên của nhóm phát triển phải
làm việc với mọi thành viên khác trong nhóm. Và họ chỉ làm những công việc
của trong nội dung của bƣớc lặp đó mà thôi. Điều này tăng cƣờng sự trãi rộng
kiến thức cho toàn nhóm. Trong khi kỹ thuật đặc trƣng vẫn còn nguyên vẹn và
các công việc yêu cầu kỹ thuật đặc trƣng vẫn thƣờng đƣợc giao cho các chuyên
gia thì các chuyên gia này làm việc với hầu hết các thành viên còn lại trong
12


nhóm . Điều này sẽ trải rộng kiến thƣ
́
c cho toàn nhóm để các thành viên khác có
thể thay thế cho chuyên gia trong các trƣờng hợp khẩn cấp.
1.3.5. Phát triển định hƣớng kiểm thử
Các lập trình viên sẽ viết các đơn vị kiểm nghiệm trƣớc khi viết mã nguồn
(thiết kế kiểm thử đầu tiên). Tất cả các đơn vị kiểm nghiệm đều đƣợc thực hiện
thƣờng xuyên trong quá trình phát triển sản phẩm trong từng khối mã nguồn của
từng lập trình viên. Các lập trình viên có thể thay đổi một cách linh hoạt vì quy
trình thử nghiệm có thể mắc lỗi hay sai so với thiết kế ban đầu.
Tất cả các mã nguồn sản phẩm đƣợc viết để làm cho các đơn vị kiểm thử
thành công. Đầu tiên, chúng ta viết một đơn vị kiểm thử chạy sai bởi vì chức
năng dự định kiểm thử vẫn chƣa tồn tại. Sau đó chúng ta viết mã để đơn vị kiểm

thử này thực hiện thành công . Thời gian lặp lại giữa viết kiểm thử rồi viết mã
nguồn xảy ra rất nhanh , trong khoảng một vài phút . Các bô
̣
kiểm thử và ma
̃

nguồn cùng tăng trƣởng , trong đó bô
̣
kiểm thử luôn dẫn trƣớc ma
̃
mộ t khoảng
cách rất ngắn.
Kết quả là các bô
̣
kiểm thử phát triển cùng lúc với mã nguồn sản phẩm .
Những bộ kiểm thử này cho phép các lập trình viên kiểm tra chƣơng trình (đang
phát triển) có chạy hay không. Nếu một cặp nào đó thƣc hiện một thay đổi nhỏ,
họ có thể chạy lại các bộ kiểm thử để chắc chắn rằng họ không làm hỏng các
đoạn mã nguồn khác.
Khi bạn viết mã để các bộ kiểm thử thành công, thì mã nguồn đó đƣợc gọi là
mã khả kiểm. Ngoài ra, còn có một mục tiêu rất quan trọng là bạn có thể tách
bạch các khối mã nguồn sao cho chúng có thể đƣợc kiểm thử một cách độc lập.
Nhƣ vậy, bản thiết kế theo hƣớng này cho kết quả là mã nguồn ít bị trùng lặp
nhất. Các nguyên lý thiết kế hƣớng đối tƣợng đóng vai trò là công cụ mạnh mẽ
giúp bạn tránh đƣợc mã trùng lặp.
Chi tiết về yêu cầu ngƣời dùng đƣợc thu thập trong dạng thức của các bộ
kiểm thử nghiệm thu đƣợc đặc tả bởi khách hàng. Các bộ kiểm thử nghiệm thu
của một yêu cầu đƣợc viết ngay trƣớc hoặc cùng lúc với việc cài đặt yêu cầu đó.
Chúng đƣợc viết theo một ngôn ngữ kịch bản bất kỳ nào cho phép chúng chạy tự
động và có thể lặp lại. Ngôn ngữ của bộ kiểm thử nghiệm thu đƣợc phát triển và

tiến hóa cùng với hệ thống. Khách hàng có thể thuê nhóm phát triển tạo một hệ
thống thực thi kịch bản đơn giản hoặc có thể họ có bộ phận kiểm soát chất lƣợng
13


riêng để phát triển nó . Nhiều khách hàng nhờ bộ phận kiểm soát chất lƣợng phát
triển công cụ cho việc kiểm tra đô
̣
thỏa mãn của sản phẩm và trực tiếp viết các
bản kiểm thử nghiệm thu.
Mỗi khi một bản kiểm thử nghiệm thu thành công, nó đƣợc thêm vào nhóm
của những bản kiểm thử nghiệm đã thành công trƣớc đó, và không bao giờ đƣợc
phép thất bại. Nhóm kiểm thử nghiệm tăng trƣởng lên và sẽ đƣợc chạy nhiều lần
trong ngày, hoặc chạy mỗi khi xây dựng hệ thống. Nếu nhƣ các bản kiểm thử
nghiệm thu thất bại thì bản xây dựng này đƣợc báo cáo là hỏng . Nhƣ vậy mỗi
khi một yêu cầu đƣợc gọi là cài đặt xong thì nó sẽ không bao giờ bị vỡ . Hệ
thống chuyển từ trạng thái cũ sang trạng thái mới mà không bao giờ đƣợc phép
không làm việc (nghĩa là phải thỏa mãn các yêu cầu cũ lẫn mới) lâu hơn vài giờ.
1.3.6. Tích hợp liên tục
Nhóm phát triển phải luôn luôn đƣợc làm việc trên các phiên bản mới nhất
của phần mềm. Do các thành viên nhóm khác nhau có thể có các phiên bản đƣợc
lƣu cục bộ với nhiều thay đổi và cải tiến, họ nên cố gắng để tải lên phiên bản
hiện tại của họ để vào trong kho mã nguồn mỗi giờ, hoặc khi một tạo ra một
điểm chốt quan trọng trong quá trình phát triển các tính năng vừa thành công.
Tích hợp liên tục sẽ tránh sự chậm trễ do vấn đề tích hợp, tránh đƣợc các vấn đề
mâu thuẫn phát sinh mà đến lúc tích hợp mới phát hiện ra đƣợc.
Bằng việc sử dụng các công cụ lƣu giữ mã nguồn, các lập trình viên đẩy mã
nguồn làm đƣợc lên kho chứa mã nguồn và tích hợp nhiều lần trong ngày. Qui
luật rất đơn giản, ngƣời đầu tiên sẽ đẩy mã nguồn lên, những ngƣời sau thì hợp
nhất mã nguồn của mình với ngƣời đẩy lên trƣớc và đẩy mã nguồn đã hợp nhất

lên. Phƣơng pháp lập trình cực hạn sử dụng công cụ quản lý mã nguồn cho phép
nhiều ngƣời đƣợc lấy mã nguồn xuống và phát triển một lúc. Điều này có nghĩa
là các lập trình viên đƣợc phép lấy mã nguồn ở bất kỳ một khối mã nguồn nào
đó vào bất kỳ thời điểm nào đó. Khi anh ta đẩy khối mã nguồn đã đƣợc chỉnh
sửa, anh ta phải chuẩn bị hợp nhất với các thay đổi do một lập trình viên bất kỳ
trƣớc đó thƣc hiện. Để tránh phải hợp nhất quá nhiều trong 1 lúc, các thành viên
nên đẩy mã nguồn mình mới thực hiện đƣợc lên kho chứa mã nguồn thƣờng
xuyên. Một cặp sẽ làm một nhiêm vụ trong khoảng một hay hai giờ. Họ tạo các
bộ kiểm thử và mã nguồn cho sản phẩm.Vào một thời điểm thích hợp, có thể là
trƣớc khi nhiệm vụ đó đƣợc hoàn thành, họ sẽ quyết định đẩy các các đoạn mã
nguồn lên kho chứa mã nguồn. Trƣớc tiên, họ phải làm cho các bộ kiểm thử đều
14


thành công. Sau đó, họ mới tích hợp phần mã nguồn mới vào phần đã có. Nếu
cần thì hợp nhất chúng lại. Hoặc nếu cần, họ sẽ hỏi ý kiến lập trình viên đã đẩy
mã nguồn lên trƣớc đó. Một khi các thay đổi đã đƣợc tích hợp, họ xây dựng lại
hệ thống. Họ chạy lại tất cả các bộ kiểm thử trong hệ thống, bao gồm cả việc
kiểm thử nghiệm thu. Nếu họ làm hỏng bất cứ thứ gì, họ phải sửa ngay. Nếu các
bộ kiểm thử đều thành công, lúc này họ mới đƣợc gọi là hoàn thành xong một
lần đẩy mã nguồn của mình lên kho chứa mã nguồn.
Tích hợp liên tục là các đoạn mã lệnh mới đƣợc tích hợp ngay vào chƣơng
trình khi một nhiệm vụ hay một yêu cầu đƣợc hoàn thành. Nhƣ là một phần của
quy trình tích hợp đầu tiên bạn tích hợp mã chƣơng trình mới nhất vào những
thay đổi của riêng bạn, sau đó bạn phải chạy tất cả các kiểm thử một lần nữa để
đảm bảo rằng tất cả các trƣờng hợp kiểm thử đề vẫn hoạt động tốt và đoạn mã
mới của bạn (hoặc thay đổi đƣợc thực hiện bởi những ngƣời khác) không phá vỡ
chƣơng trình đã phát triển. Sau đó bạn có thể tích hợp mã của bạn vào chƣơng
trình và công bố cho các thành viên khác trong nhóm. Việc kiểm thử nhƣ trên sẽ
đƣợc thực hiện trong một môi trƣờng "sạch" (có thể tích hợp trên một máy riêng

biệt) và xây dựng từ đầu để tránh bị "nhiễu" từ các tập tin có thể tạm thời và để
đảm bảo rằng những gì bạn sẽ tích hợp sau này cũng là những gì bạn thực sự
đang kiểm thử. Trong trƣờng hợp những lập trình viên khác đã "phát hành"
những thay đổi của họ vào mã nguồn chƣơng trình chung sau khi bạn tích hợp
nó vào không gian làm việc của bạn, bạn sẽ phải bắt đầu tích hợp lại vào môi
trƣờng kiểm thử của bạn và kiểu thử lại. Tuy nhiên, các bản "phát hành" sẽ đƣợc
đẩy lên thƣờng xuyên và lập trình viên sẽ chỉ tốn một khoảng thời gian ngắn để
chạy các trƣờng hợp kiểm thử, do đó, trƣờng hợp này rất hiếm khi xẩy ra. Việc
tích hợp liên tục giúp tất cả mọi ngƣời luôn làm việc trên mã mới nhất, và giúp
cho các đoạn mã lệnh trở nên thống nhất hơn, tránh đƣợc các xung đột khi tích
hợp các đoạn mã mới của các cặp lập trình viên lên mã chung của cả đội.
1.3.7. Tái cấu trúc hệ thống
Bởi vì phƣơng pháp lập trình cực hạn ủng hộ phƣơng pháp chỉ lập trình
những gì cần thiết trong hiện tại, và thực hiện nó một cách đơn giản nhất có thể
tại thời điểm này có thể dẫn đến những khó khăn có thể phát sinh trong việc phát
triển hệ thống về sau. Một trong những vấn đề phát sinh là sự cần thiết để bảo trì
kép các phiên bản: thay đổi chức năng bắt đầu đòi hỏi phải thay đổi nhiều bản
sao của mã nguồn tƣơng tự nhƣ nhau. Một vấn đề khác là những thay đổi trong
một phần của mã này ảnh hƣởng đến rất nhiều bộ phận khác.
15


Nguyên nhân là do sau một thời gian phát triển để phục vụ một tính năng nào
đó, các đoạn mã nguồn thƣờng đƣợc viết ra để phục vụ việc đáp ứng ngay đƣợc
yêu cầu đó, vì vậy, phƣơng pháp lập trình cực hạn khuyến khích tổ chức lại
chƣơng trình một cách đều đặn để nâng cao tính sáng sủa của chƣơng trình, dễ
bổ sung các chức năng mới, nâng cao hiệu suất của chƣơng trình. Việc tổ chức
lại chƣơng trình là rất khả thi do phƣơng pháp lập trình cực hạn có quy trình thử
nghiệm tự động bắt lỗi do đó việc tổ chức lại chƣơng trình sẽ không quá tốn
công sức. Hơn nữa, việc tổ chức lại chƣơng trình giúp ta nhìn nhận lại toàn bộ

chƣơng trình, tổ chức lại mã nguồn cho phù hợp với yêu cầu hơn (do đã phát
triển và rất hiểu yêu cầu) và giúp tối ƣu hơn các đoạn mã nguồn. Qua đó cũng
mở rộng và nâng cao kiến trúc thiết kế lên và làm cho nó đơn giản hơn.
Sau phiên bản ban đầu, kiến trúc và thiết kế chung đƣợc đặt ra, mọi thứ đều
tập trung vào việc thực hiện các yêu cầu của khách hàng và thực hiện các nhiệm
vụ để đạt đƣợc các yêu cầu đó. Trong XP, đầu tiên, các lập trình viên sẽ tập
trung vào việc viết các đoạn mã lệnh rồi sau đó sẽ thiết kế lại chƣơng trình đã
viết. Sau một nhiệm vụ hay một yêu cầu ngƣời dùng đƣợc hoàn thành, trƣớc khi
nó đƣợc phát hành các đoạn mã vào kho mã nguồn chung, các đoạn mã mới này
sẽ đƣợc biến đổi để đơn giản hóa cả về thiết kế lẫn đoạn mã lệnh. Mục đích là để
giữ cho các mã càng đơn giản càng tốt và cải thiện thiết kế trong khi vẫn duy trì
các chức năng. Tái cấu trúc nên đƣợc thực hiện nhƣ một loạt các bƣớc hồi phục
đƣợc, vì vậy bạn luôn có thể trở lại nếu một tái cấu trúc không hoạt động. Đối
với mỗi bƣớc trong quá trình tái cấu trúc của bạn chắc chắn rằng mã chuyển đổi
không phá vỡ bất cứ trƣờng hợp kiểm thử nào. Bằng cách này các lập trình viên
có thể thay đổi thiết kế ngay khi cần thiết, và do đó nhóm dự án không bị khóa
chặt trong các quyết định thiết kế ban đầu.
1.3.8. Sở hữu tập thể
Tất cả mã nguồn đều thuộc quyền sở hữu của mọi thành viên trong nhóm
phát triển. Theo đó, một cặp có quyền lấy mã nguồn về và chỉnh sửa, cải tiến
một khối mã nguồn bất kỳ. Không một lập trình viên nào chịu trách nhiệm cá
nhân với một khối mã nguồn bất kỳ hoặc một kỹ thuật bất kỳ. Mọi ngƣời cùng
làm việc với giao diện ngƣời dùng. Mọi ngƣời cùng làm việc với phần mềm lớp
giữa. Mọi ngƣời cùng làm việc với cơ sở dữ liệu. Không ai có nhiều quyền lực
hơn ngƣời khác về một kỹ thuật hay một khối mã nguồn nào đó. Do Bất kỳ
ngƣời nào trong đội dự án đều có quyền thay đổi mã trong quá trình làm việc với
khách hàng chỉ cần tuân theo tiêu chuẩn lập trình và phải đảm bảo thực hiện thử
16

nghiệm lại toàn bộ sau khi hoàn tất công việc sửa đổi . Điều này sẽ loại bỏ các
vấn đề nhƣ là sai lệch về cấu trúc chƣơng trình, … có thể xảy ra khi một cá nhân
lập trình độc lập.
Điều này không có nghĩa là phƣơng pháp lập trình cực hạn phản đối việc
chuyên môn hóa. Nếu bạn có kỹ năng về lập trình giao diện ngƣời dùng, hẳn bạn
thích các nhiệm vụ liên quan đến giao diện ngƣời dùng, nhƣng bạn sẽ đƣợc yêu
cầu bắt cặp với các nhiệm vụ ở lớp điều khiển (lớp logic) hoặc ở mức cơ sở dữ
liệu. Nếu bạn quyết định học một chuyên môn thứ hai, bạn có thể đăng ký các
nhiệm vụ và làm việc với chuyên gia ở chuyên môn đó. Họ sẽ dạy bạn và bạn sẽ
không bị "giam giữ" trong chuyên môn của mình.
Theo XP, tất cả mọi ngƣời sở hữu tất cả các đoạn mã lệnh mà nhóm viết ra.
Toàn bộ nhóm nghiên cứu sở hữu tất cả đoạn mã lệnh và đƣợc gọi chung là chịu
trách nhiệm về nó. Nếu một cặp lập trình viên làm việc trên một yêu cầu cụ thể
cảm thấy cần phải thay đổi một số đoạn mã lệnh khác để thỏa mãn yêu cầu cụ
thể của họ, họ đƣợc tự do để làm nhƣ vậy bất kỳ lúc nào mà không cần phải hỏi
và chờ đợi cho ngƣời khác để làm điều đó cho họ. Trong thực tế, họ đƣợc
khuyến khích để thay đổi hoặc tái cấu trúc lại bất cứ khi nào họ thấy rằng nó có
thể đƣợc cải thiện. Nếu họ cần thêm thông tin để thực hiện các thay đổi, họ có
thể tìm các cặp lập trình viên đã thực hiện các đoạn mã lệnh này đầu tiên và thảo
luận về nhƣng thay đổi với họ. Bởi vì, nếu cặp lập trình viên yêu cầu ngƣời khác
để thực hiện việc thay đổi mà họ cần có nghĩa là họ sẽ phải chờ đợi điều đó xảy
ra và có thể họ sẽ không nhận đƣợc sự thay đổi hoàn toàn đúng theo những điều
mà cặp lập trình viên này mong muốn. Khi một cặp lập trình viên sửa các đoạn
mã lệnh để thực hiện những yêu cầu của khách hàng mà họ đảm nhận, họ sẽ
luôn tìm thấy cái gì có thể cần đƣợc cải thiện và nó là trách nhiệm của cặp lập
trình viên này dù họ không phải là tác giả gốc của đoạn mã lệnh này. Khi một
cặp lập trình viên hoàn thành một nhiệm vụ hay một yêu cầu, họ phát hành mã
nguồn lên kho mã nguồn để đoạn mã nguồn đó có sẵn cho tất cả các thành viên
khác trong nhóm. Nhƣ một hệ quả của phƣơng pháp thực hành sở hữu tập thể sẽ
có mã đƣợc thực hiện song song do hai hoặc nhiều cặp cùng thay đổi một đoạn

mã lệnh cùng một lúc.
1.3.9. Thiết kế đơn giản
Phƣơng pháp lập trình cực hạn khuyến khích tìm kiếm giải pháp đơn giản khi
thiết kế phần mềm. Chỉ thiết kế phần mềm thoả mãn yêu cầu hiện tại của khách