Extreme Programming trong Agile

Extreme Programming (XP), còn được viết tắt là XP, là một trong những phương pháp phát triển phần mềm phổ biến nhất thuộc khuôn khổ Agile. XP được Kent Beck phát minh vào đầu những năm 1990. Đó là một nguyên tắc phát triển phần mềm “gọn nhẹ” dành cho nhóm nhằm giúp các tổ chức sản xuất phần mềm chất lượng cao. 

Các vai trò trong Extreme Programming (XP)

– Sponsor: Người tài trợ cho dự án và là bên liên quan rất quan trọng của dự án. 

– Coach: Chịu trách nhiệm hướng dẫn, chỉ dẫn, và huấn luyện đội nhóm của mình theo cách triển khai của XP. Vai trò gần giống như Scrum Master ở Scrum. 

– Onsite Customer/Customer: Chịu trách nhiệm cung cấp yêu cầu và độ ưu tiên của yêu cầu. Vai trò gần giống như Product Owner ở Scrum. 

– Programmer/Developers: Lập trình viên, có vai trò triển khai sản phẩm.

– Tester: Kiểm thử viên, có vai trò kiểm tra sản phẩm đã được triển khai đúng như yêu cầu chưa và đảm bảo chất lượng sản phẩm. (Hai vai trò Programmer & Tester có thể hiểu tương tự chức năng của Development Team trong Scrum, nhưng XP tách ra hai vai trò riêng biệt).

– Tracker: Vai trò XP Tracker hỗ trợ đo lường và truyền đạt tiến trình của nhóm. Một vài thông tin mà XP Tracker có thể hỗ trợ theo dõi có thể liệt kê dưới đây nhưng không phải toàn bộ: 

• Kế hoạch và báo cáo releases 
• Kế hoạch và báo cáo Sprint/Iteration
• Kế hoạch và kết quả Acceptance Test

12 Practices của Extreme Programming (XP)

Có 2 cấp độ kế hoạch trong XP:

• Release: Nhóm và các bên liên quan/khách hàng cùng nhau quyết định những yêu cầu và tính năng cho từng cột mốc releases cụ thể. Việc này được thực hiện dựa trên mức độ ưu tiên, năng lực, ước tính và yếu tố rủi ro của nhóm thực hiện.
• Iteration/Sprint: Nhóm sẽ chọn những mục có giá trị nhất từ ​​danh sách tính năng sản phẩm (Product Backlog) và chia chúng thành các nhiệm vụ, sau đó ước tính. 

Trong XP, nhóm sẽ không thực hiện trước các thiết kế và kiến ​​trúc phức tạp hoặc quá lớn. Thay vào đó, nhóm sẽ bắt đầu với một thiết kế đơn giản, sau đó cải thiện và điều chỉnh liên tục thông qua các Sprint. Công việc (hay các đoạn mã trong lập trình) thường xuyên được tái cấu trúc để có thể dễ dàng bảo trì, nâng cấp và không mắc “nợ kỹ thuật”. Những thiết kế đơn giản giúp cho việc ‘định nghĩa việc đã hoàn thành’ trở nên dễ dàng hơn.

Trong XP, team thường sẽ viết các kịch bản kiểm thử đơn vị (Unit Test) trước khi bắt đầu công việc lập trình. Lợi ích chính của TDD là các lập trình viên chỉ phải lập trình các đoạn mã để vượt qua các kịch bản kiểm thử đã được xác định trước. Các bước cơ bản của TDD: 

• Viết các trường hợp/kịch bản kiểm thử đơn vị đầu tiên (Unit Test Cases)
• Viết số lượng mã tối thiểu để vượt qua các kịch bản kiểm thử.
• Tái cấu trúc các đoạn mã bằng cách thêm tính năng và chức năng cần thiết, đồng thời liên tục đảm bảo các đoạn mã này vượt qua các kịch bản kiểm thử.

Tổ chức muốn các lập trình viên của mình tuân theo một số phong cách mã hóa tiêu chuẩn và được mô tả rõ ràng được gọi là tiêu chuẩn mã hóa. Các tiêu chuẩn này là kim chỉ nam cho nhóm phát triển XP. Các tiêu chuẩn mã hóa rất hữu ích để tạo sự nhất quán về mã, kiểu, chuyển đổi đặt tên, xử lý ngoại lệ và sử dụng các tham số,… Các tiêu chuẩn này phải được xác định và thống nhất trước khi nhóm bắt đầu viết mã. Bằng việc áp dụng tiêu chuẩn mã, mã trở nên đơn giản, dễ hiểu và giúp phát hiện vấn đề hoặc các vấn đề một cách nhanh chóng, đồng thời cũng làm tăng hiệu quả của phần mềm.

Trong XP, qua một khoảng thời gian, nhóm tạo ra rất nhiều mã hoạt động và điều đó làm tăng độ phức tạp cũng như góp phần tạo ra nợ kỹ thuật. Để tránh điều này, team XP xem xét các điểm dưới đây bằng cách áp dụng Refactoring: 

• Đảm bảo mã hoặc chức năng không bị trùng lặp.
• Đảm bảo tất cả các biến trong phạm vi, được xác định và sử dụng.
• Không có hàm hoặc phương thức dài.
• Loại bỏ những thứ và biến không cần thiết.
• Sử dụng đúng cách các công cụ sửa đổi truy cập, v.v.

Bằng cách tái cấu trúc, các lập trình viên tìm cách cải thiện chất lượng mã tổng thể và làm cho các đoạn mã này dễ đọc hơn mà không thay đổi hành vi của nó.

Lập trình đôi bao gồm hai lập trình viên hoạt động trên cùng một đoạn mã, trên cùng một hệ thống (một màn hình và một bàn phím). Một lập trình viên đóng vai trò thí điểm và tập trung vào triển khai đoạn mã. Người thứ hai đóng vai trò là người điều hướng, tập trung vào bức tranh tổng thể cũng như đánh giá, phản hồi mã để cải tiến hoặc tái cấu trúc. Vai trò này có thể được luân phiên với nhau trong suốt quá trình lập trình. 

Bằng cách tuân theo các phương pháp lập trình đôi, nhóm XP luôn có quyền sở hữu chung về mã. Thành công hay thất bại là nỗ lực của tập thể và không có trò đổ lỗi cho người khác (blamming game). 
 
8. Continuous Integration – CI (Tích hợp liên tục)

CI là tích hợp liên tục. Trong XP, Programmers/Developers thực hiện lập trình theo cặp trên các phiên bản mã cục bộ. Việc tích hợp được thực hiện vài giờ một lần hoặc hàng ngày để tránh mọi nguy cơ lan truyền lỗi và các vấn đề khác với thời gian ngừng hoạt động tối thiểu. Nhóm có thể sử dụng các công cụ tự động CI như Jenkins, Shippable, Integrity, Azure DevOps Pipelines,…

Một nhóm đa chức năng trong XP thường xuyên phát hành sản phẩm khả dụng tối thiểu (MVP). Các bản release liên tục cũng giúp chia nhỏ các mô-đun phức tạp thành một đoạn mã nhỏ. Điều này giúp nhóm phát triển cũng như khách hàng tập trung vào số lượng công việc tối thiểu, có mức độ ưu tiên và mang lại giá trị cao nhất.

Kỹ thuật này chủ yếu liên quan đến yêu cầu hay câu chuyện của người dùng (User Story). Các yêu cầu phải đủ đơn giản để người dùng và nhà phát triển dễ hiểu. Phương pháp chuyển đổi đặt tên được sử dụng trong thiết kế và mã để có sự hiểu biết chung giữa các nhóm (nhóm kinh doanh và nhóm kỹ thuật). 

Ví dụ: 

Nếu bạn đang xây dựng hệ thống trang web thư viện, bạn có thể sử dụng phép ẩn dụ về thư viện vật lý như: Sách, kệ, danh mục, cho mượn và trả lại. Phép ẩn dụ này có thể giúp bạn đặt tên cho các lớp, phương thức, biến và giao diện (kỹ thuật) một cách nhất quán.

Đây là vai trò tương tự như Product Owner trong Scrum. Onsite Customers chịu trách nhiệm xây dựng tầm nhìn, xác định yêu cầu (User Story) và tiêu chí chấp nhận, xác định kế hoạch thực hiện và releases. Onsite Customers là những chuyên gia hiểu biết về domain và biết cách tạo ra lợi tức đầu tư (ROI) bằng cách cung cấp sản phẩm khả dụng tối thiểu (MVP).
  
Từ “onsite” ngụ ý rằng khách hàng hoặc người đại diện của họ ngồi cùng với những người còn lại trong nhóm để đảm bảo quá trình giao tiếp diễn ra suôn sẻ.

Đây là một thực hành lấy con người làm trung tâm. XP duy trì tốc độ bền vững bằng cách duy trình tinh thần đội nhóm, tạo môi trường làm việc an toàn, hạn chế làm việc quá giờ, … để toàn team có thể duy trì động lực, tinh thần, thể chất một cách tốt nhất và hoàn thành các mục tiêu dự án.

Masterskills Trainer – Lâm Thu Nguyên

PMI-ACP® GAPS

PMI-ACP Guide – Hướng dẫn pass PMI-ACP on the first try

Product Roadmap là gì?