ĐẠ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


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

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


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

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ế

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?

á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

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

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.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

̣
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

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

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ộ

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