Phòng planning thường im đi ở cùng một khoảnh khắc. Một story được mở trên màn hình, ai đó hỏi story này bao nhiêu điểm, và cả team bắt đầu đi tìm một con số không gây rắc rối về sau. Developer thấy nó nhỏ. Tester nhớ ra ba edge case. Product Owner hy vọng nó vừa sprint này. Con số nghe có vẻ đơn giản, nhưng mọi người đều biết nó đang mang nhiều thứ hơn là kích thước.
Chính sự căng nhẹ đó làm Agile Estimating and Planning vẫn đáng đọc. Mike Cohn không cố biến software thành thứ có thể dự đoán như máy móc. Ông giúp việc lập kế hoạch trung thực hơn. Cuốn sách nhắc đi nhắc lại rằng estimate không phải lời hứa khắc lên bàn. Nó là một cuộc trò chuyện có cấu trúc về quy mô, rủi ro, tri thức và trade-off.
Bài viết này là reflection cá nhân từ Agile Estimating and Planning của Mike Cohn, do Prentice Hall / Addison-Wesley Professional xuất bản năm 2005. Mình không tóm tắt toàn bộ sách theo từng chương. Mình giữ lại những ý vẫn giúp team phần mềm nói chuyện về estimate, velocity và planning mà không biến con số thành áp lực trình diễn.
Planning quan trọng hơn bản plan
Một ý rất sạch trong sách là planning là một hoạt động, không phải một tài liệu. Bản plan chỉ là ảnh chụp niềm tin của team ở một thời điểm. Planning là thói quen cập nhật niềm tin đó khi team học thêm. Nghe đơn giản, nhưng nó đổi hẳn cảm giác khi nói về estimate.
Trong nhiều team, estimate đầu tiên âm thầm biến thành hợp đồng. Một feature được đoán là 8 ngày vào tháng Một, rồi tới tháng Ba mọi người cư xử như thể con số đó đến từ vật lý. Agile planning đề nghị một cách bình tĩnh hơn: giữ estimate nhìn thấy được, giữ assumption nhìn thấy được, và replan khi thực tế dạy team điều mới.
Ví dụ team đang tích hợp với một hệ thống định danh khách hàng cũ. Trước khi đụng vào code, team có thể nghĩ story nhỏ: gọi một API, map vài field, xong. Sau một spike, team phát hiện API chạy khác nhau theo tenant, error message không nhất quán, và test data rất khó tạo. Công việc không lớn lên vì team cẩu thả. Nó rõ hơn vì team đã học thêm.
Một lần replan hữu ích có thể rất nhỏ. Team giữ story gốc, nhưng tách thêm một spike để ghi lại hành vi theo tenant, một lát cắt read-only sync, và một lát cắt write-back có xử lý lỗi. Cuộc trò chuyện đổi từ “vì sao estimate lớn lên?” thành “assumption nào đã đổi, và lát cắt nào cho mình bài học kế tiếp?”
Tách size khỏi duration
Cách Cohn tách size và duration là một thói quen rất đáng giữ. Story points estimate quy mô: effort, complexity và risk gom lại. Duration đến sau, thông qua velocity thật của team. Cách này tránh một lỗi planning quen thuộc: giả vờ rằng mọi người, mọi tuần và mọi ngày không bị gián đoạn đều giống nhau.
Một story đăng nhập và một story cập nhật hồ sơ đều có thể nghe nhỏ. Nhưng nếu đăng nhập đụng tới security, audit log, reset password, rate limiting và hành vi nhiều thiết bị, quy mô của nó khác. Story points giúp team so sánh tương đối trước khi giả vờ biết chính xác lịch. Câu hỏi trở thành: việc này giống story trước không, hay nặng gấp hai, gấp ba lần?
| Lối tắt khi planning | Điều nó che khuất | Cuộc trò chuyện tốt hơn |
|---|---|---|
| “Cái này 2 ngày.” | Giả định không bị gián đoạn, không discovery và chỉ nhìn từ context của một người. | “Nó giống story 3 điểm trước, nhưng risk testing cao hơn.” |
| “Velocity phải là 40.” | Biến velocity thành target thay vì dữ liệu đo được. | “Ba iteration gần nhất là 28, 31 và 30. Mình plan quanh range đó.” |
| “Tách UI, API, DB ra.” | Tạo task kỹ thuật thay vì lát cắt có giá trị cho người dùng. | “Lát cắt nhỏ nhất mà user hoặc PO accept được là gì?” |
| “1 ideal day là 1 calendar day.” | Bỏ qua họp, support, review, incident và context switching. | “Việc này cần bao nhiêu effort tập trung, và năng lực thật của team là bao nhiêu?” |
Phần tự sửa sai của velocity rất quan trọng. Nếu team estimate tất cả story hơi nhỏ hơn thực tế, velocity đo được cũng sẽ thấp hơn kỳ vọng. Kế hoạch tự điều chỉnh qua velocity quan sát được. Điều đó khỏe hơn việc ép team liên tục bảo vệ từng con số đã đoán ban đầu.
Planning poker hữu ích vì assumption lộ ra
Planning poker không có giá trị vì bộ bài vui. Nó có giá trị vì assumption ẩn được đưa ra ánh sáng. Khi mọi người lật số cùng lúc, khoảng cách giữa estimate cao nhất và thấp nhất nói cho team biết nên thảo luận ở đâu.
Giả sử story là “người dùng có thể export lịch sử giao dịch”. Một engineer chọn 3 vì nghĩ chỉ cần CSV từ query có sẵn. Một người khác chọn 13 vì biết export phải có permission check, file lớn, timezone, masking dữ liệu cá nhân và audit event. Con số không quan trọng bằng cuộc trò chuyện sau đó. Khoảng cách giữa 3 và 13 cho team thấy điều chưa ai nói ra.
Đây cũng là lý do planning poker không nên trôi thành buổi thiết kế dài. Vài phút làm rõ là tốt. Một cuộc họp kiến trúc kéo dài trong lúc estimate thường nói rằng story còn quá mơ hồ, quá lớn hoặc chứa quá nhiều rủi ro. Khi đó, spike hoặc tách story nhỏ hơn thường tốt hơn một estimate anh hùng.
Ideal days hữu ích cho tới khi bị hiểu nhầm thành ngày trên lịch
Cuốn sách đối xử khá công bằng với ideal days. Nó dễ hiểu với stakeholder hơn story points vì vẫn là đơn vị ngày. Nhưng ideal days trở nên nguy hiểm khi ai đó âm thầm dịch một ideal day thành một ngày trên calendar.
Một ngày làm việc thật không phải một căn phòng kín. Nó có code review, câu hỏi support, họp ngắn, kiểm tra deployment, nhiễu production, giúp teammate và những gián đoạn nhỏ không bao giờ hiện trong estimate. Một task cần 2 ideal days tập trung có thể không xong trong 2 ngày lịch. Điều đó không có nghĩa engineer chậm. Nó nghĩa là calendar chứa nhiều thứ hơn task.
Ví dụ một story nặng QA. Coding có thể là 1 ideal day, nhưng team còn cần test data, acceptance examples, regression check và có thể phải phối hợp với support. Nếu những thứ này không được nhìn thấy, plan sẽ hiệu quả trên giấy và căng trong đời thật.
Velocity là dữ liệu của team, không phải bảng xếp hạng
Velocity hữu ích khi được đối xử như evidence. Nó gây hại khi bị biến thành KPI. Velocity thuộc về một team cụ thể, với codebase, domain, con người, gián đoạn, tooling và definition of done của team đó. So sánh hai team bằng velocity giống như so sánh hai căn bếp bằng số đĩa họ bê, mà không hỏi họ đang nấu món gì.
Quy tắc all-or-nothing giúp giữ ý nghĩa này. Một story chỉ đóng góp vào velocity khi nó done, được test và được accept. Điều này có thể nghiêm, nhưng nó bảo vệ nghĩa của done. Một story code xong 90% nhưng chưa được accept không tạo ra 90% giá trị cho khách hàng. Team có thể đang rất gần, nhưng sản phẩm chưa nhận được giá trị.
Individual velocity thì đi ngược hướng. Khi từng người bị đo bằng số point cá nhân, collaboration trở nên rủi ro. Giúp teammate, review kỹ, pair debug một lỗi khó hoặc hỗ trợ QA có thể làm output nhìn thấy của một người giảm, trong khi delivery thật của team tốt hơn. Một metric planning mà phạt teamwork là metric đang đo sai thứ.
Thay vì nói “team commit xong toàn bộ 50 points”, hãy thử nói: “Dựa trên ba iteration gần nhất, team đang plan quanh 28 đến 32 points. Hai story này có risk cao, nên nếu chúng lớn lên, story ưu tiên thấp này là ứng viên đầu tiên để chuyển ra.”
Nếu đưa vào team, mình sẽ bắt đầu thế nào
Mình sẽ bắt đầu nhỏ. Đầu tiên, chọn vài reference stories mà team hiểu rõ: một bug fix rất nhỏ, một thay đổi CRUD bình thường, một integration qua service khác, và một story rủi ro từng cần discovery. Gán point chung cho chúng. Những story này trở thành viên đá đo của team.
Thứ hai, giữ assumption đi cùng estimate. Nếu story phụ thuộc vào sandbox của vendor, rule permission chưa rõ hoặc data migration, hãy viết điều đó bên cạnh estimate. Khi assumption đổi, plan đổi mà không cần drama.
Thứ ba, dùng velocity như một range sau vài iteration. Một iteration còn nhiễu. Hai hoặc ba iteration tốt hơn. Từ bốn iteration trở lên, pattern bắt đầu có ích. Mục tiêu không phải làm team nhanh hơn bằng cách đòi con số lớn hơn. Mục tiêu là làm cuộc trò chuyện release bớt phụ thuộc vào trí nhớ và áp lực.
Những điều đọng lại
- Planning là việc lặp lại. Bản plan là ảnh chụp; planning là cách team cập nhật hiểu biết.
- Story points estimate size, không estimate lịch. Duration nên đi qua velocity quan sát được.
- Planning poker làm assumption lộ ra. Khoảng cách giữa các estimate là nơi team học thêm.
- Ideal days cần dùng cẩn thận. Nó mô tả effort tập trung, không phải ngày làm việc thật đầy gián đoạn.
- Velocity là dữ liệu của team. Nó nên hỗ trợ planning, không nên thành bảng xếp hạng hay target quản lý.
Giá trị âm thầm của Agile Estimating and Planning là nó cho team một ngôn ngữ trung thực hơn. Không phải ngôn ngữ xóa bỏ bất định, mà là ngôn ngữ giúp mọi người nói về bất định mà không giấu nó. Một estimate tốt không làm tương lai ngoan ngoãn hơn. Nó giúp team thấy mình biết gì, đang giả định gì, còn cần học gì, và quyết định nào là hợp lý ở thời điểm này.