Pragmatic Programmer – Topic 48: The Essence of Agility — Cách làm
Mở đầu
Có một thời mình làm ở chỗ mua hẳn một "gói Agile" về: thuê tư vấn, thêm hai tầng quản lý, thêm mấy chức danh nghe rất kêu. Kết quả: sprint dài hơn, release chậm hơn, mình họp nhiều hơn ngồi code. Đọc Topic 48 của Pragmatic Programmer mình mới thấy cảnh đó được tả gần như nguyên văn — những người "cầm clipboard và đồng hồ bấm giây". Topic này nói vì sao đi tìm "quy trình agile" là sai ngay từ đầu.
Ảnh: zheng liang — Pexels
Agility là tính từ, không phải danh từ
Tip 83 nói gọn: agile không phải danh từ, agile là cách mình làm việc. Agility là phong cách của mình, không phải cái nhãn dán lên team.
Hệ quả kéo theo: không bao giờ có thứ gọi là "quy trình agile". Ai nói "cứ làm theo bộ bước này là agile rồi" thì sai — sai theo định nghĩa. Agility nằm ở chỗ phản ứng với cái chưa biết sau khi đã xuất phát.
Bốn giá trị của Tuyên ngôn là thước đo để tự soi: con người hơn quy trình công cụ, phần mềm chạy được hơn tài liệu cho đủ, hợp tác khách hàng hơn đàm phán hợp đồng, phản ứng thay đổi hơn bám kế hoạch. Ai bán cho mình thứ khiến mấy cái sau nặng ký hơn hẳn thì không coi trọng cùng những giá trị đó.
Không có kế hoạch nào sống nổi với bất định
Con linh dương chạy trốn không đi một đường thẳng. Vận động viên thể dục chỉnh hàng trăm lần mỗi giây để ứng với sàn, với đà, với lỗi nhỏ của bàn chân. Code cũng vậy — ba trong bốn giá trị Tuyên ngôn là chuyện thu thập và phản hồi tín hiệu.
Mấy giá trị đó không nói phải làm gì; chúng nói nên nhìn vào đâu khi tự quyết. Mà quyết định luôn phụ thuộc ngữ cảnh: mình là ai, team ra sao, app này là gì, khách hàng nghĩ gì. Kế hoạch tĩnh không sống nổi với chừng đó biến số.
Thay cho quy trình, sách đưa đúng ba bước:
- Xác định mình đang ở đâu.
- Bước nhỏ nhất có ý nghĩa về phía mình muốn tới.
- Xem lại chỗ vừa tới, sửa cái mình làm vỡ.
Lặp ba bước này, đệ quy ở mọi cấp — từ tên biến tới quy trình cả team.
Vòng lặp nhỏ cũng làm thiết kế tốt lên
Ví dụ trong sách rất đời: viết let user = accountOwner(accountID), thấy user vô nghĩa, đổi thành owner, rồi thấy hơi dư, tự hỏi mình đang thật sự làm gì — hoá ra chỉ cần email để gửi: emailOfAccountOwner(accountID). Một vòng phản hồi ở cấp thấp nhất mà thiết kế đã tốt hơn: code không còn dính vào chuyện quản lý tài khoản.
Cấp cao hơn cũng vậy: có dự án đi đúng một bước thì nhận ra việc sắp làm không cần thiết, giải pháp tốt nhất không cần phần mềm. Đây là lý do topic này gắn với Topic 8: thước đo thiết kế tốt là dễ thay đổi. Bước 3 bắt mình sửa cái mình làm vỡ — sửa mà đau thì mình sẽ nhủ "thôi kệ", code mục dần, agility chỉ còn trên giấy. Thiết kế tốt là điều kiện để làm agile, không phải phần thưởng sau khi làm.
Ảnh: cottonbro studio — Pexels
Chỗ khó khi áp dụng
Nói thật, topic này dễ làm mình bực hơn thấy hay vì nó không cho gì để copy. Vòng lặp chết không phải vì thiếu kỹ thuật mà vì tổ chức không cho phép sửa: deadline chốt cứng, tín hiệu phát hiện sớm bị gạt sang một bên. Còn bước nhỏ nhất phụ thuộc chất lượng code đang có — hệ thống đã rối nặng thì bước nhỏ nhất cũng ngốn cả tuần, và thứ không phù hợp khi đó là cục code khó sửa, không phải agile.
Bài học rút ra
- Agile là tính từ: cách mình làm việc, không phải thứ mua về cài lên team.
- Không có "quy trình agile": ai cam kết "làm theo bộ bước này là agile" thì sai theo định nghĩa.
- Ba bước, lặp đệ quy: biết mình đang ở đâu → bước nhỏ nhất có ý nghĩa → sửa cái mình làm vỡ. Áp ở mọi cấp.
- Sửa phải rẻ thì vòng lặp mới chạy: thiết kế tốt (dễ thay đổi) là điều kiện sống còn.
- Team không tự thử nghiệm quy trình của mình thì chưa agile, dù họp đủ loại ceremony.
Bớt mấy tầng báo cáo đi, giữ lại vòng lặp.
Team bạn lần cuối cùng thay đổi cách làm việc của chính nó là khi nào — việc gì khiến mọi người chịu đổi?