extreme programming

BÁO CÁO NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Sinh viên thực hiện : Nguyễn Thanh Dũng

Lớp : 11CNTN

MSSV : 1112056

Thành phố Hồ Chí Minh

5/2013

Tổng quan về Extreme Programming

Khoa CNTT – Đại học KHTN thành phố Hồ Chí Minh 1

Mục lục

Mục lục................................................................................................................ 1

I Định nghĩa ........................................................................................................... 2

II Lịch sử ................................................................................................................. 2

III Các giá trị cơ bản của Extreme Programming .................................................... 3

IV Đặc điểm ............................................................................................................. 4

V Nền tảng của quy trình phát triển phần mềm ...................................................... 4

VI Các nguyên tắc và biện pháp............................................................................... 6

VII Những vấn đề khi sử dụng Extreme Programming............................................. 8

Các khái niệm liên quan ...................................................................................... 9

Tham khảo ......................................................................................................... 10



I – Định nghĩa :

Extreme Programming (XP) là 1 phương pháp

phát triển phần mềm thuộc nhóm các phương

pháp phát triển phần mềm nhanh (Agile

Programming). Nó giúp cải thiện các sản

phẩm phần mềm theo 5 giá trị chính : giao

tiếp, đơn giản, phản hồi, tôn trọng, dũng cảm.

Phương pháp này được thực hiện dựa trên việc

tập hợp cả nhóm lập trình tham gia vào quá

trình phát triển, với các phản hồi được đưa ra

kịp thời để giúp nhóm phát triển biết họ đang

ở đâu trong quá trình và điều chỉnh lại phương

pháp dựa theo tình huống cụ thể.

II – Lịch sử :

1. Hình thành :

Extreme Programming được phát triển bởi Kent Beck trong khi ông ta đang làm việc cho

một dự án của tổ chức Chrysler Comprehensive Compensation System (C3). Beck trở

thành người chủ nhiệm dự án của C3 vào năm 1993 và bắt đầu chỉnh sửa lại phương pháp

phát triển phần mềm mà mình đã sử dụng trong dự án để viết một cuốn sách về phương

pháp này, cuốn Extreme Programming Explained được xuất bản vào tháng 10 năm 1999.

Sau đó Chrysler hủy dự án C3 vào năm 2000 sau khi công ti được nắm giữ bởi Daimler-

Benz.

Mặc dù phương pháp XP là mới, tuy nhiên các biện pháp được sử dụng trong nó đã được

thực hiện từ lâu. Phương pháp sau đó nâng các biện pháp lên một mức độ tột cùng, tạo

nên Extreme Programming. Ví dụ, biện pháp chuẩn bị các test trước khi phát triển đã

được sử dụng từ sớm bởi dự án sao Thủy của NASA vào đầu thập kỉ 1960.

2. Quá trình phát triển :

Việc phát triển phần mềm vào giai đoạn thập niên 90 chia ra làm 2 nhóm chính :



- Phát triển bên trong (internally) : lập trình hướng đối tượng thay thế cho lập trình

thủ tục như là một mô hình lập trình được ưa thích trong công nghiệp phần mềm.

- Phát triển bề ngoài (externally) : sự trỗi dậy của Internet và sự bùng nổ kinh doanh

trên mạng và việc phát triển của các công ti như là một phần của việc cạnh tranh

trong kinh doanh.

Các yêu cầu thay đổi nhanh chóng đòi hỏi một chu trình phát triển sản phẩm ngắn hơn, và

trở nên không hòa hợp với các phương pháp phát triển truyền thống. Điều này đòi hỏi

một phương pháp mới giúp việc phát triển phần mềm nhanh chóng và hiệu quả hơn. C3

được thành lập với mục tiêu tìm ra một cách tốt nhất, sử dụng hệ thống thanh toán tại

Chrysler như là 1 đối tượng để nghiên cứu, với ngôn ngữ sử dụng là Smalltalk, và lớp dữ

liệu truy cập là GemStone.

Beck tham gia vào dự án trên và sau đó trở thành trưởng dự án. Ông mời Ron Jeffries

tham gia vào để giúp phát triển và chỉnh sửa các phương pháp nói trên. Jeffries sau đó trở

thành trưởng nhóm C3.

Beck sau đó xuất bản một loạt sách về XP, bắt đầu với cuốn Extreme Programming

Explained, thể hiện ý tưởng của ông rộng hơn, tốt hơn. Tác giả của loạt sách đưa ra nhiều

khía cạnh của XP và các phương pháp thực hiện nó. Trong loạt sách còn có một quyển

viết về cách thực hiện cụ thể của XP.

XP tạo nên một cơn sốt nhỏ vào cuối những năm 1990 – đầu những năm 2000, tạo nên

một số các biến thể riêng so với bản gốc. Mặc dù các phương pháp phát triển nhanh khác

không bao giờ đứng yên mà luôn phát triển, XP vẫn phát triển và bổ sung vào nó các biện

pháp thực hiện được áp dụng trong thực tế để làm phong phú thêm cho bản thân. XP vẫn

là một phương pháp phát triển phần mềm được ưa chuộng cho đến thời điểm này.

III – Các giá trị cơ bản của Extreme Programming :

1. Sự đơn giản (Simplicity) : Chúng ta chỉ làm những gì cần làm và được yêu cầu

làm, không hơn. Chúng ta sẽ chọn những bước nhỏ, đơn giản để đạt được mục

đích và giảm thiểu các rủi ro có thể có.

2. Giao tiếp (Communication) : Tất cả mọi người đều là một phần của quy trình phát

triển và chúng ta sẽ giao tiếp với nhau hàng ngày. Tất cả đều làm chung từ việc

tiếp nhận yêu cầu đến lập trình. Các giải pháp tốt nhất để xử lí các vấn đề đều

được thực hiện chung.

3. Phản hồi (Feedback) : Chúng ta mô tả và đưa ra các sản phẩm sớm, từ đó lắng

nghe các phản hồi một cách cẩn thận và đưa ra các thay đổi nếu có thể.



4. Sự tôn trọng (Respect) : Tất cả mọi người đều cần phải tôn trọng và được tôn

trọng với tư cách là một thành viên của dự án. Tất cả đều đóng góp công sức như

nhau.

5. Sự can đảm (Courage) : Chúng ta phải trung thực về quy trình và việc đánh giá.

Chúng ta không biện hộ cho thất bại vì chúng ta đều hướng tới sự thành công.

Chúng ta không sợ gì cả vì không ai làm việc một mình. Hãy sẵn sàng để thay đổi

bất cứ khi nào vấn đề xuất hiện.

IV – Đặc điểm :

1. Mục tiêu :

- Tạo ra những sản phẩm chất lượng cao hiệu quả hơn.

- Giảm chi phí khi thay đổi yêu cầu bằng cách có đồng thời nhiều chu trình lập trình

ngắn thay vì một chu trình dài.

2. Điều làm cho XP khác biệt so với các phương pháp phát triển khác :

- Sử dụng trong các dự án nhỏ, từ 2-8 lập trình viên.

- Nhanh, cụ thể, các phản hồi được trả về liên tục từ các chu trình ngắn.

- Là phương pháp tiếp cận các kế hoạch gia tăng trong vòng đời của dự án.

- Thay đổi kế hoạch thực hiện các chức năng linh hoạt, tùy theo sự thay đổi của

công việc cần đến.

- Phụ thuộc vào các test tự động được viết bởi lập trình viên và khách hàng để điều

chỉnh quá trình phát triển, giúp cho hệ thống phát triển và bắt được các lỗi sớm.

- Phụ thuộc vào quá trình tiến hóa của quy trình thiết kế.

- Phụ thuộc vào sự kết hợp chặt chẽ giữa lập trình viên và các kĩ năng cơ bản.

- Phụ thuộc vào việc thực hiện các quy trình ngắn hạn của lập trình viên và dài hạn

của dự án.

V – Nền tảng của quy trình phát triển phần mềm :

XP mô tả có 4 hoạt động nền tảng được thực hiện trong quá trình phát triển phần mềm,

đó là lập trình (coding), kiểm thử (testing), lắng nghe (listening) và thiết kế (designing).

Bạn lập trình vì nếu không, bạn không hoàn thành bất kì thứ gì. Bạn kiểm lỗi bởi nếu

không, bạn không biết khi nào đã lập trình xong. Bạn lắng nghe, bởi nếu không thì bạn

không biết lập trình cái gì, kiểm tra cái gì. Và bạn thiết kế để có thể lập trình, kiểm tra và

lắng nghe vô thời hạn. Đó chính là 4 hoạt động cần có trong một quy trình phát triển phần

mềm.

1. Lập trình (Coding) :



Chỉ khi lập trình, bạn mới thật sự làm một thứ gì đó trong quy trình phát triển. Nếu không

lập trình, sẽ không có sản phẩm nào hoàn thành,

Khi bạn lập trình 1 thứ gì đó, bạn sẽ có cơ hội hiểu rõ hơn về kiến trúc tốt nhất cho sản

phẩm. Có những dấu hiệu nhất định trong các đoạn mã cho chúng ta thấy rằng những

phần kiến trúc quan trọng nào mà chúng ta vẫn chưa hiểu rõ.

Lập trình cũng đưa đến 1 cơ hội để giao tiếp một cách rõ ràng và chính xác. Nếu bạn có

một ý kiến và giải thích ra, người khác có thể sẽ hiểu nhầm. Nhưng nếu chúng ta lập trình

cùng nhau, chúng ta có thể thấy và hiểu được chính xác những gì mà cộng sự muốn thể

hiện.

Cuối cùng, lập trình là thứ không thể thiếu trong quá trình phát triển. Kể cả khi sản phẩm

đã được đưa ra, chúng ta vẫn cần phải giữ lấy mã nguồn của nó. Có mã nguồn, chúng ta

có thể thực hiện được rất nhiều mục đích.

2. Kiểm thử (Testing) :

Việc kiểm tra giúp cho chương trình tồn tại được lâu hơn. Lập trình khi có bộ test đã có

sẵn cũng thú vị hơn khi không có. Lập trình và kiểm thử song hành với nhau sẽ nhanh

hơn so với việc chỉ lập trình đơn thuần. Tuy nhiên, nếu bộ test kém sẽ khiến cho người

lập trình mất đi sự tự tin, bởi vì hệ thống chạy tốt khi tất cả các bộ test đều chạy. Nếu bộ

test bị lỗi, mà hệ thống chạy tốt trên bộ test đó, có xác suất rằng hệ thống sẽ có lỗi. Nếu

chúng ta bỏ qua điều đó và tiếp tục cài đặt các bộ phận khác của hệ thống, có nghĩa rằng

chúng ta đã để lại một cái bẫy ngầm ở trong hệ thống và có thể dẫn tới những hệ lụy

không mong muốn.

Có 2 loại test :

- Test cơ sở : được viết bởi lập trình viên để thuyết phục chính họ rằng chương trình

làm việc đúng theo cái cách mà họ nghĩ nó sẽ làm.

- Test chức năng : được viết (hoặc được chỉ ra) bởi khách hàng để thuyết phục bản

thân rằng hệ thống làm việc theo cách mà họ mong muốn cả hệ thống sẽ làm.

3. Lắng nghe (Listening) :

Lập trình viên không biết bất kì thứ gì về công việc, về những yêu cầu mà khách hàng

cần và nghĩ rằng nó thú vị. Tuy nhiên, nếu những người kinh doanh mà biết lập trình thì

họ sẽ chẳng cần đến lập trình viên.



Lập trình viên phải lắng nghe khách hàng muốn hệ thống làm gì, công việc cần gì. Họ

phải hiểu những yêu cần đó đủ tốt để có thể phản hồi lại khách hàng về khía cạnh kĩ thuật

rằng vấn đề đó có thể được giải quyết hay không. Lập trình viên phải giúp khách hàng

hiểu được thứ gì khó, thứ gì dễ. Những phản hồi từ lập trình viên sẽ giúp khách hàng hiểu

về những vấn đề của họ tốt hơn.

4. Thiết kế (Designing) :

XP đòi hỏi sự đơn giản, thế thì chỉ cần coding, testing và listening là đã đủ rồi? Tại sao

lại cần đến designing? Trên lí thuyết, nếu 3 điều trên thực hiện tốt thì hệ thống sẽ được

vận hành tốt. Tuy nhiên thực tế thì không như thế.

Dù sớm hay muộn, một hệ thống không có thiết kế tốt sớm hay muộn cũng sẽ bị trục trặc.

Cách duy nhất để tránh điều này đó là phải thiết kế. Thiết kế tạo một kiến trúc thể hiện

mức tổ chức logic của hệ thống.

Một thiết kế tốt sẽ giúp cho khi thay đổi một phần của hệ thống sẽ không ảnh hưởng đến

các phần còn lại. Thiết kế tốt đảm bảo sự mở rộng hệ thống sẽ chỉ ảnh hưởng tại một

điểm duy nhất. Thiết kế tồi thì ngược lại.

VI – Các nguyên tắc và biện pháp :

1. Lên kế hoạch (The planning game) :

Quá trình lên kế hoạch của XP cho phép khách hàng định nghĩa các tính năng

mong muốn, và ước lượng chi phí của nó được cung cấp bởi nhóm lập trình, từ đó

chọn ra những thứ gì cần phải thực hiện và những thứ gì cần phải hoãn lại. Giá trị

của việc lên kế hoạch là nó giúp định hướng được quy trình từ đó đưa đến thành

công.

2. Phát hành các phiên bản nhỏ (Small Releases) :

Nhóm XP tung ra các hệ thống đơn giản thành các sản phẩm rất sớm, và cập nhật

nó thường xuyên thông qua các chu trình phát triển ngắn.

3. Thiết kế đơn giản (Simple design) :

XP sử dụng thiết kế đơn giản nhất có thể để đáp ứng được các yêu cầu. Các yêu

cầu có thể thay đổi vào ngày mai, cho nên chúng ta chỉ cần đáp ứng các yêu cầu

vào hôm nay là đủ.

Thiết kế trong XP không phải là thiết kế 1 lần mà là thiết kế trong toàn bộ thời

gian phát triển. Trong quá trình phát triển chúng ta sẽ phải thiết kế lại trong rất

nhiều giai đoạn của quy trình.



4. Ẩn dụ (Metaphor) :

Nhóm XP phát triển một danh sách các tên hệ thống chung và các mô tả chung để

thuận lợi cho việc phát triển và giao tiếp.

Nhóm XP sử dụng các tên chung này để chắc chắn rằng tất cả mọi người đều hiểu

hệ thống hoạt động thế nào và nơi nào để tìm kiếm các chức năng cần thiết, hoặc

để tìm nơi thích hợp để đặt các các chức năng muốn thêm vào.

5. Kiểm tra liên tục (Continuous testing) :

Nhóm sử dụng XP tập trung vào việc phần mềm chạy tốt trong suốt quá trình. Lập

trình viên phát triển phần mềm bằng việc viết các bộ test trước, sau đó lập trình để

thỏa mãn các bộ test đó. Khách hàng cung cấp các bộ test để chắc chắn rằng

chương trình thỏa mãn các tính năng mà họ đưa ra.

6. Cấu trúc lại hệ thống (Refactoring) :

Nhóm làm việc cải thiện thiết kế của hệ thống thông qua toàn bộ quá trình phát

triển. Điều này được thực hiện bằng cách giữ cho phần mềm sạch sẽ : không có

việc trùng lặp, có sự giao tiếp tốt, đơn giản và đã hoàn tất.

7. Lập trình theo cặp (Pair programming) :

Tất cả sản phẩm được viết bởi 2 lập trình viên làm việc tại cùng 1 máy tính. Hình

thức này đảm bảo tất cả mã nguồn được kiểm tra kĩ lưỡng ngay khi đang viết và

dẫn đến thiết kế tốt hơn, kiểm thử tốt hơn và lập trình tốt hơn.

8. Quyền sở hữu mã tập thể (Collective code ownership) :

Không có một cá nhân nào sở hữu một mô-đun. Bất kì người phát triển nào cũng

có thể làm việc trên bất kì phần nào của hệ thống tại bất cứ lúc nào.

9. Tích hợp liên tục (Continuous integration) :

Tất cả thay đổi đều được tích hợp vào hệ thống ít nhất là theo từng ngày. Các test

cơ sở (unit test) phải chạy tốt trên hệ thống trước và sau khi tích hợp.

10. Thời gian làm việc theo chuẩn 40 giờ/tuần (40-hour work week) :

Lập trình viên làm việc đúng giờ, ít phải làm quá giờ quy định. Trong giai đoạn

làm việc gấp gáp, có thể cho phép làm quá giờ nhưng không quá 1 tuần. Nhiều

tuần liên tục làm việc thêm giờ sẽ là dấu hiệu cho thấy có sự bất ổn của quá trình

phát triển và trong việc lập kế hoạch.



11. Khách hàng tham gia vào nhóm phát triển (On-site customer) :

Nhóm phát triển liên tục tiếp cận khách hàng, những người thực sự sử dụng hệ

thống. Trong phần lớn trường hợp, một đại diện của phía khách hàng (có thể là

người quản lí chất lượng sản phẩm) sẽ được chỉ định tham gia vào nhóm phát

triển.

12. Chuẩn lập trình (Coding standards) :

Tất cả mọi người đều lập trình theo 1 chuẩn cho trước. Chi tiết của chuẩn này

không cần quá quan tâm, tuy nhiên điều cần quan tâm là tất cả các lập trình viên

đều lập trình tương đối giống nhau, hỗ trợ cho việc thu thập quyền sở hữu.

VII – Những vấn đề khi sử dụng Extreme Programming :

- Việc lập trình theo cặp gây khó chịu đối với nhiều lập trình viên.

- Khách hàng tham gia vào nhóm phát triển như là 1 phần quan trọng đôi khi gây ra

rủi ro về vấn đề bảo mật của mã nguồn.

- Đối với phần lớn dự án, XP quá nhỏ và quá nhiều rủi ro.

- Phức tạp.

- Dựa vào nhiều thứ để thực hiện.



Các khái niệm liên quan

Test tự động (Automated test)

Các test case được chạy mà không có sự can thiệp của con người. Các test kiểm tra

xem hệ thống cho ra các giá trị có đúng với mong đợi hay không.

Test chức năng (Functional test)

Test được viết từ góc nhìn của khách hàng.

Test cơ sở (Unit test)

Test được viết từ góc nhìn của lập trình viên.

Lập trình theo cặp (Pair programming)

Kĩ thuật lập trình trong đó 2 lập trình viên sử dụng chung 1 máy tính, 1 bàn phím,

1 con chuột. Trong XP cặp lập trình thông thường thay đổi theo ngày.

Lập kế hoạch (Planning Game)

Quy trình phát triển của XP.

Lên kế hoạch (Refactoring)

Sự thay đổi đến hệ thống tuy nhiên không làm thay đổi các hành vi của nó, mà

thêm vào một số giá trị phi chức năng – đơn giản, linh hoạt, dễ hiểu và chạy tốt.



Tham khảo

1. Kent Beck. “Extreme Programming Explained (1st Edition).

2. Lowell Lindstrom, Ron Jeffries. “Extreme Programming and Agile Software

Development methodologies”

3. Wikipedia. “http://en.wikipedia.org/wiki/Extreme_programming”

4. Extreme Programming : a gentle introduction.

“http://www.extremeprogramming.org/”

5. Ganesh Sambasivam. “Extreme Programming”

6. Mike Grant. “Introduction to eXtreme Programming”

7. Ian Sommerville. “Software Engineering (9th

Edition)”

extreme programming

Documents