XP (Extreme Programming) là một cách tiếp cận mới (câu này viết ra năm 2000!), hạng nhẹ để phát triển phần mềm. XP sử dụng phản hồi nhanh và giao tiếp băng thông cao để tối đa hóa giá trị thu được, thông qua một khách hàng tại chỗ, một phương pháp lập kế hoạch cụ thể và quá trình kiểm thử liên tục.

Hãy cùng xem xét cách phát triển phần mềm kiểu truyền thống.

Nhóm người dùng (hay nhóm khách hàng) dàn xếp với nhóm phát triển để có một chuyên gia phân tích (business analyst) được chỉ định cho dự án. Trong nhiều tuần và tháng kế tiếp, chuyên gia phân tích gặp gỡ nhóm người dùng trong vài giờ mỗi tuần. Chuyên gia phân tích tạo ra một bộ tài liệu yêu cầu, có thể bao gồm những thứ như Tuyên bố về tầm nhìn hoặc Trường hợp sử dụng (Use cases). Người dùng và người quản lý dự án (và có lẽ cả nhóm lập trình nữa) xem xét các tài liệu này và đàm phán với nhau về một release. Các lập trình viên tiếp nhận các mô tả kỹ thuật (functional specifications document), và vài tháng sau đó tạo ra một hệ thống ít nhiều làm được những gì nó dự định phải làm. Cuối cùng thường là có một cuộc họp thân mật trong đó mọi người phát hiện ra rằng đã có những thứ họ đã bỏ lỡ và nhận ra có những thay đổi kể từ sau khi các tài liệu được viết ra. Cuối cùng, khách hàng đến để thực hiện kiểm thử nghiệm thu và sau đó hệ thống được phát hành. Thường thì toàn bộ quá trình truyền thống này mất nhiều thời gian hơn là mọi người mong đợi, một số tính năng bị thiếu và chất lượng phần mềm không được như người dùng muốn. Hơn nữa, các tài liệu không còn được cập nhật.

Nhóm dự án áp dụng phương pháp XP thì khái quát như sau.

Trong quá trình phát triển, development team tạo ra một release của hệ thống sau khoảng từ 6 đến 8 tuần. Trong trường hợp tốt nhất, công tác phân tích và phát triển tiến hành song song và hỗ trợ lẫn nhau. Cách tiếp cận của XP nhấn mạnh đến sự tham gia và thử nghiệm của khách hàng: Khách hàng liên hệ với nhóm phát triển XP để bắt đầu một dự án. Nhóm lập trình yêu cầu khách hàng ngồi với nhóm của họ trong quá trình phát triển. Một dự án XP có ba giai đoạn:

– giai đoạn lập kế hoạch phát hành – release planning phase, trong đó khách hàng viết các user story, lập trình viên ước lượng chúng và khách hàng chọn thứ tự phát triển user story;

– một giai đoạn các vòng lặp – iteration phase, trong đó khách hàng viết các bài test và trả lời các câu hỏi, trong khi các lập trình viên lập trình; và

– giai đoạn phát hành – release phase, nơi lập trình viên cài đặt phần mềm và khách hàng chấp thuận kết quả. Khách hàng trong XP có cơ hội thường xuyên để thay đổi hướng đi của nhóm nếu hoàn cảnh thay đổi: giai đoạn các iteration là cung cấp phần mềm sẵn sàng được phát hành cứ sau mỗi hai tuần. Bởi vì kiểm thử rất nổi bật và thường xuyên, khách hàng nhận thức được tình trạng thật của dự án sớm hơn nhiều trong chu trình phát triển.

Trong XP, có một sự phân chia cơ bản trong vai trò của Khách hàng và Lập trình viên. Cả hai đều ở cùng một đội, nhưng họ có những quyền quyết định khác nhau. Khách hàng sở hữu “những gì bạn sẽ nhận được” trong khi Lập trình viên sở hữu “những gì là chi phí thực hiện”. Điều này cho thấy ai sẽ đưa ra quyết định gì.

Khách hàng được quyết định:

• Phạm vi: hệ thống phải làm gì
• Ưu tiên: điều gì là quan trọng nhất
• Thành phần của các bản phát hành: những gì phải có trong một bản phát hành mới có ích cho khách hàng
• Ngày phát hành: khi nào cần phát hành.

Các lập trình viên có quyền quyết định:

• Thời gian dự kiến ​​để thêm một tính năng
• Hậu quả kỹ thuật: Lập trình viên giải thích hậu quả của các lựa chọn kỹ thuật, nhưng Khách hàng đưa ra quyết định lựa chọn
• Quy trình: nhóm sẽ làm việc như thế nào
• Lịch trình công việc chi tiết (trong từng iteration)

Vấn đề về hậu quả kỹ thuật xuất hiện ở đây vì khách hàng phải sống với kết quả. Ví dụ: cơ sở dữ liệu hướng đối tượng có thể cho phép team làm việc nhanh hơn, nhưng khách hàng vẫn có thể thích cơ sở dữ liệu quan hệ vì những lý do như quản lý rủi ro và giảm thiểu gián đoạn quá trình hỗ trợ của họ. Các nhà phát triển có thể đúng 100%: sẽ nhanh hơn để phát triển theo cách đó, nhưng thời gian phát triển không phải là điều duy nhất khách hàng xem xét. Các thực tiễn của XP giúp thực thi sự phân chia giữa trách nhiệm của khách hàng và lập trình viên. Sự phân công lao động này giúp cho cả nhóm luôn nhìn ra các hậu quả của các quyết định rất rõ ràng. Ví dụ: nếu khách hàng muốn phần mềm tạo ra một báo cáo mới trong tuần này, nhóm phát triển sẵn lòng cung cấp nó. Họ sẽ báo cáo rủi ro kỹ thuật (nếu có) và ước tính chi phí sẽ là bao nhiêu. Sau đó, khách hàng sẽ chọn những user story sẽ được bỏ ra khỏi backlog để dành thời gian cho sự phát triển báo cáo mới. Điều gì xảy ra nếu có một xung đột? Điều gì sẽ xảy ra nếu khách hàng muốn các tính năng này sẵn sàng vào một ngày cụ thể, nhưng các lập trình viên ước tính rằng làm chúng sẽ mất nhiều thời gian hơn thế? XP cung cấp một số tùy chọn: khách hàng có thể chấp nhận phạm vi nhỏ hơn, khách hàng có thể chấp nhận một ngày phát hành muộn hơn, khách hàng có thể dành thời gian hoặc tiền bạc để khám phá nghiên cứu một giải pháp thay thế, hoặc khách hàng có thể tìm thấy một nhóm lập trình khác. XP không cho phép bạn nói: “Hãy cứ thử làm đi xem thế nào, chúng ta sẽ cố gắng bắt kịp tiến độ mong muốn sau.”

Phương pháp XP giống như là một củ hành nhiều lớp vỏ

Bạn có thể nghĩ về XP như một củ hành tây nhiều lớp vỏ. Lớp trong cùng là các thực hành lập trình. XP sử dụng một phong cách lập trình cụ thể, có thể sử dụng được ngay cả bởi một nhà phát triển solo. (Nhưng XP không khuyến khích phát triển solo.) Lớp giữa bao gồm một tập các thực hành của nhóm. Lớp bên ngoài xác định quy trình mà một nhóm lập trình tương tác với khách hàng của mình.

XP là một tập hợp mười hai thực hành (12 practices)

Một cách nhìn khác xem XP là một tập hợp các thực hành. Trong “Extreme Programming Explained”, Kent Beck đưa ra một bộ mười hai thực hành cốt lõi đóng vai trò là điểm khởi đầu cho một nhóm dự án XP. Chúng tôi sẽ ánh xạ các thực hành đó đến các lớp như thế này:

• Lập trình: Thiết kế đơn giản, thử nghiệm, refactoring, tiêu chuẩn mã hóa (Simple design, testing, refactoring, coding standards)
• Thực hành nhóm: Sở hữu tập thể, tích hợp liên tục, ẩn dụ, tiêu chuẩn mã hóa, tuần 40 giờ, lập trình cặp, phát hành nhỏ. (Collective ownership, continuous integration, metaphor, coding standards, 40-hour week, pair programming, small releases)
• Quy trình: Khách hàng tại chỗ, kiểm thử, phát hành nhỏ, trò chơi lập kế hoạch. (On-site customer, testing, small releases, planning game). Lưu ý có một số chồng chéo của một vài loại thực hành.

Bạn cần hiểu rõ các thực hành này là sự phản ánh bốn giá trị cốt lõi của XP: đơn giản, giao tiếp, phản hồi và can đảm. (Simplicity, Communication, Feedback, Courage)

XP là về một phương pháp thực hành lập trình

Các lập trình viên XP viết mã thông qua các vòng lặp test-first development: viết và chạy unit test, sau đó coding chỉ vừa đủ để làm cho unit test được pass. Luôn phải có trước một bài unit test để kiểm tra cho bất kỳ đoạn mã mới nào được viết. XP cố gắng giữ cho toàn bộ hệ thống linh hoạt bằng cách giữ cho nó đơn giản nhất có thể. Refactoring (tái cấu trúc) cải thiện code trong khi đảm bảo nó vẫn vượt qua tất cả các thử nghiệm.

XP là về các thực hành của nhóm

Hãy xem xét các thực hành nhóm và một số lựa chọn thay thế: quyền sở hữu mã, tích hợp, làm thêm giờ, không gian làm việc, lịch phát hành và tiêu chuẩn mã hóa. Pair programming (lập trình theo cặp) cung cấp thiết kế tại chỗ và đánh giá cho từng dòng code được viết ra. Nhiều nhóm dự án phải vật lộn để có thể áp dụng Pair programming, nhưng XP coi Pair programming là một cơ chế chính để đảm bảo chất lượng và học tập nhóm. XP không nhấn mạnh vào vấn đề kiến ​​trúc như là một cơ chế điều khiển chủ đạo, nhưng các chương trình phát triển theo XP là có kiến ​​trúc. Tổ hợp của metaphor (phép ẩn dụ), thiết kế và quy trình phát triển góp phần tạo nên kiến ​​trúc chương trình XP. Ẩn dụ cung cấp một khung khái niệm cho một hệ thống. Hãy cùng khám phá cách các phép ẩn dụ có thể thúc đẩy việc khái niệm hóa và hiện thực hóa một vài loại hệ thống khác nhau.

XP là về quy trình

Kiểm thử chấp nhận tự động (automated acceptance tests) và khách hàng tại chỗ (on-site customer) là các khía cạnh quan trọng của XP. Một khách hàng ngồi cùng nhóm phát triển toàn thời gian để viết các kiểm thử acceptance test, trả lời câu hỏi và đặt thứ tự ưu tiên. Có khách hàng đi cùng với nhóm dự án là rất quan trọng vì sẽ giúp nhóm đi nhanh nhất có thể. Tôi đã từng làm việc với một nhóm đa chức năng đã chuyển vào một phòng lớn cho một dự án trọng điểm. Một người quản lý của phòng Marketing nói rằng trải nghiệm này rất tuyệt, rằng anh ấy đã trả lời các câu hỏi ngay khi nhóm phát triển đưa ra và anh ấy có thể thấy tiến trình công việc nhờ các câu trả lời của mình. Anh ta nói rằng khi trở lại môi trường văn phòng, anh ta nhận được một thư thoại nhưng ngâm không trả lời trong một hoặc hai ngày. Trong khi đó, các lập trình viên buộc phải hoặc đưa ra dự đoán riêng hoặc làm việc với một yêu cầu ít quan trọng. Phải mất nhiều cân nhắc và quyết định được đưa ra trong quá trình phát triển phần mềm. Nếu một nhóm dự án có thể nhận được câu trả lời hoặc quyết định của mình trong vài phút thay vì hàng giờ hoặc vài ngày, tốc độ làm việc của nhóm sẽ cao hơn nhiều.

XP không phải là phương pháp duy nhất nhận ra giá trị của khách hàng tại chỗ. Tom Peters đã tuyên bố rằng: “Hãy biến khách hàng thành một phần không thể thiếu trong mỗi nhóm dự án” và “Nếu khách hàng không cung cấp cho bạn các nhân sự toàn thời gian và chất lượng hàng đầu, hãy từ chối nhận dự án. Vì khách hàng không nghiêm túc.”

Kiểm thử

XP sử dụng kiểm thử theo hai cách: khách hàng phát triển các acceptance tests để xác định hành vi chung của hệ thống và lập trình viên tạo các unit tests trong khi lập trình. Nên nhớ chúng tôi bao gồm unit test vào trong phần lập trình! Khách hàng tạo các acceptance tests cho mỗi user story họ yêu cầu. Các nhóm XP đo lường tiến trình phát triển phần mềm bằng cách chạy các bài kiểm thử này. Các bài kiểm thử tạo thành một bằng chứng cho khả năng validate và chấp nhận nghiệm thu các tính năng được yêu cầu.

Cuối cùng, nhóm phát triển nên cố gắng áp dụng tự động kiểm thử (test automation). Điều này có thể nghĩa là khách hàng sẽ phải dành một phần thời gian phát triển để xây dựng cơ sở hạ tầng thử nghiệm, nhưng nó đáng giá. Các thử nghiệm tự động không cần phải có một giao diện đẹp đẽ, mà chỉ cần một công cụ để xác định đầu vào và kết quả mong đợi. Một số nhóm dự án đã áp dụng thành công một bảng tính Excel cho việc tự động hóa kiểm thử: người dùng có giao diện Excel quen thuộc để viết test cases và các lập trình viên có thể viết một chương trình nhỏ để đọc file Excel của người dùng và chạy các test case từ file đó một cách tự động.

Planning game – Trò chơi lập kế hoạch

XP sử dụng khái niệm trò chơi lập kế hoạch để lên kế hoạch phát hành (release plan, từ vài tuần đến vài tháng) và để lập kế hoạch iteration (iteration plan, từ một đến ba tuần). Trò chơi lập kế hoạch sử dụng hai loại người chơi, Khách hàng và Lập trình viên và xác định loại người chơi nào có thể thực hiện loại hoạt động dịch chuyển gì. Theo cách lập kế hoạch này quy trình phát triển duy trì được sự phân công lao động quan trọng: Khách hàng xác định giá trị, Lập trình viên xác định chi phí.

Trong trò chơi lập kế hoạch phát hành, mục tiêu là xác định tập hợp các tính năng cần thiết cho lần phát hành tiếp theo. Nó tập trung vào user stories. Khách hàng viết user stories, lập trình viên ước lượng các user stories và Khách hàng lên kế hoạch phát hành tổng thể. Chúng ta sẽ thảo luận về quy trình lập kế hoạch phát hành và đưa ra các ví dụ về những user stories mà khách hàng có thể viết. Trò chơi lập kế hoạch cho iteration cũng tương tự như vậy. Khách hàng chọn các user stories cho iteration và Lập trình viên ước lượng và chấp nhận các nhiệm vụ tương ứng. Quá trình này được mô tả như một trò chơi của hội đồng quản trị. Cuối cùng, chúng ta sẽ mô tả các hoạt động mà khách hàng, lập trình viên và người quản lý dự án sẽ tham gia trong công việc hàng ngày của một iteration.

Theo William Wake

Extreme Programming Explored