eXtreme Programming

eXtreme Programming — thường gọi tắt là XP — là thành viên đòi hỏi khắt khe nhất của họ agile. East Agile Tracker được xây dựng cho XP trước tiên; mọi thứ khác đều bắt nguồn từ đó.

Trang này trình bày XP là gì, vì sao nó hiệu quả, và cách thực hành nó với tracker làm bề mặt lập kế hoạch của bạn.

XP là gì

XP được tạo ra bởi Kent Beck vào cuối thập niên 1990. Cuốn sách đầu tiên — Extreme Programming Explained: Embrace Change — được xuất bản năm 1999. Nó bắt đầu, như nhiều điều khác, với một đội ngũ thất vọng đang cố gắng phát hành một hệ thống tính lương tại Chrysler.

Niềm tin của XP là cách đúng đắn để xử lý sự bất định trong phần mềm là làm những điều có hiệu quả, và làm chúng thường xuyên hơn. Kiểm thử? Kiểm thử mọi lúc. Tích hợp? Tích hợp hàng giờ. Trò chuyện? Trò chuyện liên tục. Lập kế hoạch? Lập kế hoạch mỗi iteration, và lập kế hoạch lại khi bạn học hỏi được điều mới.

“XP là một phương pháp luận nhẹ cho các đội ngũ nhỏ đến trung bình phát triển phần mềm trước những yêu cầu mơ hồ hoặc thay đổi nhanh chóng.” — Kent Beck

Năm giá trị

XP nêu tên năm giá trị mà mọi thứ khác đều dựa vào:

Giao tiếp (Communication) — Đội ngũ trò chuyện. Hàng ngày. Về công việc, về thiết kế, về các trở ngại. Trực tiếp khi có thể. Các silo là kẻ thù.
Đơn giản (Simplicity) — Làm điều đơn giản nhất có thể hoạt động được. Bạn có thể thêm độ phức tạp sau nếu bạn thực sự cần. Bạn có lẽ sẽ không cần.
Phản hồi (Feedback) — Từ mã (các bài kiểm thử), từ đội ngũ (lập trình theo cặp, đánh giá), từ người dùng (release thường xuyên). Lấy nó nhanh.
Dũng cảm (Courage) — Nói thật về tiến độ, ước lượng, và thiết kế. Vứt bỏ mã không hoạt động. Tái cấu trúc những gì đang cản trở bạn.
Tôn trọng (Respect) — Mọi người trong đội — và giờ đây, mọi agent trong đội — đều đóng góp giá trị. Hãy đối xử với nhau tương xứng.

Các thực hành

XP nổi tiếng với mười hai thực hành nguyên bản, được tổ chức thành bốn lĩnh vực:

Lập kế hoạch

Planning Game — Đội ngũ và khách hàng lập kế hoạch cùng nhau: việc gì sẽ đến tiếp theo, theo thứ tự nào, mỗi mảnh lớn cỡ nào.
Small Releases — Phát hành thường xuyên. Theo ngày, không phải theo tháng. Nhận phản hồi về một thứ cụ thể.
User Stories — Yêu cầu là các cuộc trò chuyện, được ghi lại thành các story ngắn từ góc nhìn của người dùng. “Là một người dùng, tôi muốn X, để Y.”

Thiết kế

Simple Design — Thiết kế đơn giản nhất vượt qua các bài kiểm thử và thể hiện mọi khái niệm cần thiết. Không hơn.
Refactoring — Cải thiện thiết kế của mã đã hoạt động. Liên tục.
System Metaphor — Một câu chuyện chung về cách hệ thống hoạt động, được dùng để khiến các quyết định thiết kế nhất quán.

Viết mã

Pair Programming — Hai nhà phát triển, một bàn phím. Một người lái, một người dẫn đường. Đổi vai thường xuyên.
Collective Code Ownership — Bất kỳ ai cũng có thể cải thiện bất kỳ mã nào. Không có lãnh địa riêng.
Continuous Integration — Tích hợp và kiểm thử mã nhiều lần mỗi ngày. Bắt lỗi hỏng ngay lập tức.
Coding Standards — Phong cách thống nhất để mã đọc như thể một người viết.

Kiểm thử

Test-Driven Development (TDD) — Viết bài kiểm thử thất bại trước, rồi viết mã làm nó vượt qua.
Acceptance Tests — Khách hàng định nghĩa, dưới dạng mã hoặc dạng thực thi được, “xong” nghĩa là gì cho mỗi story.

Vì sao XP hiệu quả

XP gây khó chịu. Lập trình theo cặp buộc bạn phải suy nghĩ thành lời. TDD buộc bạn phải biết thành công trông như thế nào trước khi viết mã. Tích hợp liên tục giết chết những nhánh dài-tuổi-thọ ưa thích của bạn. Các release nhỏ nghĩa là bạn không thể trốn sau một lộ trình sáu tháng.

Nó hiệu quả vì tất cả những điều này đều rút ngắn các vòng lặp phản hồi. Bạn càng sớm phát hiện ra mình đã sai, việc sửa chữa càng rẻ. XP, về cơ bản, là về việc làm cho vòng lặp phản hồi chặt chẽ nhất có thể.

Nó cũng là về lòng dũng cảm và sự tôn trọng. Bạn chỉ có thể làm XP trong một đội ngũ tin tưởng lẫn nhau đủ để sai một cách công khai.

Mô hình story có kỷ luật

East Agile Tracker mã hóa một lý thuyết cụ thể về lập kế hoạch. Hãy coi mục này là sách hướng dẫn vận hành cho vì sao mô hình dữ liệu trông như vậy — và là cẩm nang thực địa cho những gì nên làm (và không nên làm) trong thực tế.

Vì sao bốn loại story quan trọng

Mọi thứ đều là story, nhưng có bốn loại, và sự phân biệt đó chính là điểm cốt lõi:

Feature mang điểm và là thứ duy nhất “tính” vào velocity. Điều này buộc bạn phải cắt nhỏ công việc thành giá trị mà người dùng có thể quan sát được.
Bug không có điểm (số không). Lỗi không kiếm được điểm, điều này khiến chi phí làm lại hiển thị thay vì được tưởng thưởng.
Chore cũng không có điểm — công việc cần thiết nhưng không có giá trị trực tiếp cho người dùng (hạ tầng, tái cấu trúc, thiết lập). Giữ chúng ở mức không tạo áp lực buộc đội ngũ gói chúng vào trong feature bất cứ khi nào có thể để khung định hướng giá trị luôn trung thực.
Release là các dấu mốc không điểm dùng để neo các cột mốc và cho phép công cụ dự báo một mốc ngày.

Hiệu ứng hành vi mới là điều quan trọng: khi bug và chore không tính điểm, một đội ngũ tự nhiên sẽ hướng tới việc thể hiện công việc dưới dạng chức năng hướng tới người dùng, và đội ngũ trở nên nhạy bén sâu sắc với chi phí của lỗi. Đó là một kỷ luật lập kế hoạch được mã hóa vào trong mô hình dữ liệu.

Backlog có thứ tự duy nhất

Ba vùng, một quy tắc.

Icebox là hồ chứa ý tưởng chưa được ưu tiên.
Backlog là một danh sách được sắp xếp nghiêm ngặt, ưu tiên đơn — không đồng hạng, không có chuyện “P1/P1/P1.”
Vùng Current chứa (các) iteration đang hoạt động.

Product owner sở hữu thứ tự từ trên xuống dưới, và tính bất biến là phần đỉnh của backlog luôn là phần quan trọng nhất và được đặc tả tốt nhất, với độ rõ ràng giảm dần một cách chính đáng khi bạn đi xuống. Một story gần đỉnh với tiêu chí chấp nhận mơ hồ là một lỗi lập kế hoạch. Icebox được phép trở thành một nghĩa địa; Backlog thì không.

Lập kế hoạch tự động dựa trên velocity

Đây là phần mà hầu hết các đội ngũ tái triển khai một cách tệ hại ở nơi khác. Lập kế hoạch kiểu tracker tính toán một velocity trung bình trượt từ các điểm được chấp nhận gần đây và tự động kéo bấy nhiêu điểm của các story vào iteration tiếp theo — bạn không “cam kết” thủ công vào một sprint, dữ liệu thực nghiệm làm điều đó cho bạn. Hai hệ quả đáng được gìn giữ:

Bạn chỉ ước lượng feature, sử dụng điểm tương đối (Fibonacci 1/2/3/5/8 hoặc thang chặt chẽ hơn của chúng tôi 0/1/2/3), không phải giờ. Ước lượng là một cuộc trò chuyện về kích thước, không phải một lời hứa.
Bạn không gian lận velocity. Thổi phồng điểm để “trông có vẻ nhanh,” hay gán điểm cho chore, sẽ phá vỡ dự báo — thứ làm cho toàn bộ hệ thống trung thực. Velocity là một dụng cụ đo lường, và bạn không can thiệp vào dụng cụ của chính mình.

Phần thưởng là dự báo ngày phát hành trở thành một phép tính thay vì một cuộc thương lượng, và cuộc trò chuyện với các bên liên quan chuyển từ “anh có cam kết X vào thứ Sáu không” thành “với velocity hiện tại, release này rơi vào khoảng ngày Y — đây là sự đánh đổi phạm vi/ngày tháng.”

Vòng đời story và vòng lặp chấp nhận

Cỗ máy trạng thái là Start → Finish → Deliver → Accept / Reject. Trạng thái then chốt là Deliver: một kỹ sư đánh dấu story đã được giao, nhưng nó vẫn chưa xong cho đến khi product owner chấp nhận nó một cách tường minh dựa trên các tiêu chí chấp nhận của nó — hoặc từ chối nó, đẩy nó trở lại. Điều này đưa một vòng lặp phản hồi của khách hàng vào trong từng story một, thay vì trì hoãn việc chấp nhận đến buổi demo cuối sprint.

Tiêu chí chấp nhận phải nằm trên story trước khi nó được bắt đầu, lý tưởng nhất là theo dạng Given/When/Then để chúng ánh xạ trực tiếp sang các bài kiểm thử chấp nhận. INVEST là phép kiểm tra tỉnh táo về việc một story đã được định hình tốt hay chưa:

Independent (Độc lập) — có thể phát hành mà không cần các story khác.
Negotiable (Thương lượng được) — nắm bắt ý định, không phải một đặc tả đông cứng.
Valuable (Có giá trị) — đối với một người dùng hoặc bên liên quan.
Estimable (Ước lượng được) — đội ngũ có thể định cỡ nó.
Small (Nhỏ) — vừa vặn thoải mái trong một iteration.
Testable (Kiểm thử được) — có các tiêu chí chấp nhận có thể được thực thi.

Nhịp độ (Cadence)

Các nghi thức lập kế hoạch nhẹ và đều đặn:

Một Buổi họp lập kế hoạch Iteration hàng tuần để gán điểm cho các story mới và chốt chặt các tiêu chí chấp nhận ở phần đỉnh của backlog.
Một buổi standup hàng ngày ngắn tập trung vào luồng và các blocker.
Một buổi nhìn lại (retrospective) mỗi iteration để điều chỉnh quy trình.

Iteration thường là một hoặc hai tuần — đủ ngắn để một ước lượng tồi rẻ tiền để phát hiện ra.

Các thực hành kỹ thuật làm cho việc lập kế hoạch hiệu quả

Lập kế hoạch kiểu tracker là nửa hữu hình của XP; nó sụp đổ nếu thiếu nửa kỹ thuật.

Kiểm thử trước / TDD và một bộ kiểm thử chấp nhận (acceptance-test) thực thụ là những gì làm cho “delivered” có ý nghĩa.
Tích hợp liên tục và các release nhỏ, thường xuyên giữ cho cycle time ngắn để velocity ổn định thay vì thất thường.
Lập trình theo cặp (hoặc đánh giá mạnh) giữ cho công việc đang dở ở mức thấp — hoàn thành trước khi bạn bắt đầu — đó là đòn bẩy lớn nhất duy nhất đối với cycle time.
Một product owner luôn sẵn sàng là thứ giữ cho vòng lặp chấp nhận/từ chối không bị đình trệ.

Các phản mẫu cần để mắt

Những thất bại lặp đi lặp lại:

Coi Backlog như một bãi đỗ xe thay vì một thứ tự ưu tiên thực sự.
Ước lượng bug và chore để khiến velocity trông đẹp hơn.
Mang theo những story khổng lồ không thể hoàn thành trong một iteration. Tách cho đến khi mỗi cái có thể giao độc lập.
Để các story chất đống trong Delivered vì không ai chấp nhận.

Bất kỳ điều nào trong số này đều âm thầm biến một hệ thống thực nghiệm trở lại thành kế hoạch mơ mộng. Tracker không thể ngăn bạn làm chúng; nó chỉ có thể khiến chúng hiển thị. Hãy nhìn vào cột Delivered của bạn vào cuối mỗi iteration — nếu nó đang tăng lên, đó là tín hiệu của bạn.

XP với East Agile Tracker

Tracker là bề mặt lập kế hoạch mà các đội ngũ XP đã mong muốn kể từ thời Pivotal Tracker. Mọi khái niệm đều ánh xạ trực tiếp:

User Story → Story

User story của XP là các story trong East Agile Tracker. Viết chúng ở loại Feature. Dùng phần mô tả cho cuộc trò chuyện; dùng bình luận cho thảo luận đang diễn ra. Tiêu chí chấp nhận thuộc về phần mô tả.

Planning Game → Board

Planning Game trong XP là một cuộc trò chuyện giữa bộ phận kinh doanh và đội ngũ về độ ưu tiên và kích thước. Trong East Agile Tracker:

Người làm sản phẩm viết các story trong Backlog và sắp xếp chúng theo độ ưu tiên.
Đội ngũ ước lượng feature bằng điểm (thang Fibonacci hoặc East Agile).
Hệ thống tự lập kế hoạch các iteration dựa trên velocity.
Đội ngũ bắt đầu các story từ phần đỉnh của cột Current.

Chỉ vậy thôi. “Trò chơi” sống trong cuộc trò chuyện; tracker chỉ ghi lại tỉ số.

Small Releases → Release (loại story)

XP nói hãy phát hành thường xuyên. Release là một trong bốn loại story trong East Agile Tracker. Tạo một release cho mỗi cột mốc phát hành; kéo nó vào iteration nơi nó được phát hành. Release bỏ qua Started/Finished/Delivered và đi thẳng đến Accepted khi bạn phát hành.

Continuous Integration → Cỗ máy trạng thái story

Cỗ máy trạng thái bản thân nó không phải là CI — đó là hệ thống build của bạn — nhưng con đường Finished → Delivered → Accepted phản chiếu vòng lặp chấp nhận của khách hàng mà XP mô tả. Hoàn thành công việc, giao nó cho khách hàng, chấp nhận khi nó được xác nhận hoạt động.

Velocity → “Thời tiết hôm qua”

XP gọi đó là thời tiết hôm qua (yesterday’s weather): lượng bạn hoàn thành được iteration vừa rồi là dự đoán tốt nhất cho lượng bạn sẽ hoàn thành iteration này. East Agile Tracker tính velocity tự động — trung bình của các iteration gần đây, chiến lược có thể cấu hình — và dùng nó để tự lập kế hoạch sức chứa cho iteration tiếp theo.

Acceptance Tests → Review

Các đánh giá story trong tracker ánh xạ sang việc chấp nhận. Gán một người đánh giá (khách hàng, product owner, hoặc thậm chí một agent đóng vai trò đó). Họ chấp nhận hoặc từ chối. Bị từ chối sẽ gửi story trở lại Started.

Pair Programming → Đồng sở hữu

Các đội XP làm việc theo cặp trên mã. Trong tracker, điều này thể hiện dưới dạng nhiều owner trên một story. Gán cả hai người của cặp vào story; cả hai cái tên xuất hiện trên card.

XP với agent — thực hành mới

XP được viết trước khi các AI agent có thể đóng góp một cách có ý nghĩa vào phần mềm. Chúng tôi nghĩ đây là bản cập nhật quan trọng nhất đối với XP trong hai mươi lăm năm.

Trong thực hành của chúng tôi — và là điều tracker được xây dựng cho — một agent là một thành viên đội XP có tên. Nó có vai trò riêng, người làm cặp riêng (con người hoặc agent), và dấu vết kiểm toán riêng. Nó có thể làm bất cứ điều gì một thành viên con người làm được trong bề mặt lập kế hoạch: ước lượng, sở hữu story, bình luận, chuyển đổi, chấp nhận đánh giá.

Các giá trị XP vẫn đúng. Giao tiếp: agent giao tiếp bằng cách đọc luồng sự kiện và đăng bình luận. Đơn giản: agent bị giới hạn trong các vai trò bạn cấp cho chúng. Phản hồi: mọi hành động của agent đều ở trong audit log, có thể đánh giá ngay lập tức. Dũng cảm: hãy trung thực về những gì agent của bạn làm đúng và những gì chúng làm chưa đúng. Tôn trọng: các đồng đội agent đóng góp giá trị — hãy ghi nhận điều đó.

Chúng tôi không đặt agent vào bên trong tracker để viết mã. Chúng tôi trao bề mặt lập kế hoạch cho con người và agent làm việc cùng nhau. Bạn mang đến coding agent — Claude Code, Codex, của riêng bạn — và kết nối nó với tracker qua API. Agent nhận story, làm việc, bình luận, chuyển đổi. Bạn xem lại dấu vết và chấp nhận.

Đây là Lập kế hoạch Agile Bao trùm (Inclusive Agile Planning). Đó là XP, với chính đội ngũ mà nó thực sự có.

Đọc thêm

Extreme Programming Explained — Cuốn sách nền tảng của Kent Beck, 1999.
Tuyên ngôn Agile — Nơi cả họ này bắt đầu.
Phát triển Agile — Bức tranh rộng hơn.
Hướng dẫn vận hành — Hướng dẫn thực hành về tracker.
Hướng dẫn API — Cắm coding agent của bạn vào.