Làm việc theo Agile: một sprint thật sự diễn ra thế nào

Trước đây mình chủ yếu làm ở team nhỏ và dự án freelance: việc đến đâu làm đến đó, trao đổi qua chat, deploy khi xong. Khi vào One Tech Stop Vietnam, mình lần đầu làm trong một quy trình Agile đầy đủ: chia việc theo sprint, có backlog, có các buổi họp cố định, có demo với khách hàng. Ban đầu thấy hơi nhiều nghi thức, nhưng sau vài sprint mình hiểu vì sao mỗi bước lại tồn tại.

Bài này ghi lại một sprint thật sự diễn ra thế nào, mỗi vai trò làm gì, và một developer nên làm gì để cả team chạy nhanh hơn.

Agile và Scrum, nói ngắn gọn#

Agile là một tư duy: chia sản phẩm thành những phần nhỏ, giao sớm, lấy phản hồi, điều chỉnh liên tục, thay vì lên kế hoạch cả năm rồi giao một lần. Scrum là cách phổ biến nhất để áp dụng tư duy đó, với nhịp làm việc cố định gọi là sprint, thường dài 1 đến 2 tuần.

Mỗi sprint có một mục tiêu rõ ràng. Hết sprint, team phải có thứ chạy được để cho khách xem, không phải một bản báo cáo tiến độ.

Ai làm gì trong team#

Không phải team nào cũng đủ người cho từng vai trò; có người kiêm nhiều việc. Nhưng hiểu rõ ai chịu trách nhiệm điều gì giúp mình biết hỏi đúng người: hỏi nghiệp vụ thì tìm BA hoặc PO, hỏi ưu tiên thì tìm PO, bị chặn thì báo Scrum Master.

Một sprint diễn ra thế nào#

Backlog refinement ──▶ Sprint planning ──▶ Daily stand-up (mỗi ngày)
                                                  │
                                                  ▼
         Retrospective ◀── Sprint review / Demo ◀── làm việc trong sprint
               │
               └──────────▶ sprint tiếp theo

1. Backlog refinement. PO, BA và dev cùng đọc các story sắp tới: yêu cầu đã rõ chưa, tiêu chí chấp nhận là gì, có phụ thuộc kỹ thuật nào không. Story nào đủ rõ mới được coi là sẵn sàng (Definition of Ready) để đưa vào sprint. Đây là buổi dev nên hỏi nhiều nhất: một câu hỏi ở đây rẻ hơn nhiều so với một ngày code sai hướng.

2. Sprint planning. Team chọn các story từ đầu backlog, ước lượng bằng story point (thường dùng dãy Fibonacci: 1, 2, 3, 5, 8, 13) và cam kết một khối lượng vừa với năng lực. Story quá lớn (13 trở lên) nên được tách nhỏ. Story point đo độ phức tạp và rủi ro, không phải số giờ.

3. Daily stand-up. Mười lăm phút mỗi sáng, mỗi người trả lời ba câu: hôm qua làm gì, hôm nay làm gì, có đang bị chặn không. Mục đích không phải báo cáo cho sếp, mà để cả team thấy chỗ nào đang kẹt và ai cần giúp. Vấn đề cần bàn sâu thì hẹn riêng sau stand-up.

4. Làm việc trong sprint. Mỗi story đi qua các cột trên board:

To do → In progress → Code review → Ready for QA → In QA → Done

5. Sprint review / Demo. Cuối sprint, team demo những gì đã xong cho PO và khách hàng, trên môi trường thật, với dữ liệu thật nếu có thể. Khách phản hồi ngay, và phản hồi đó quay lại backlog cho sprint sau.

6. Retrospective. Team nhìn lại chính mình: điều gì tốt, điều gì chưa tốt, sprint sau thử thay đổi gì. Mỗi lần chỉ nên chọn một vài hành động cụ thể, có người phụ trách, và kiểm tra lại ở retro kế tiếp.

"Xong" nghĩa là gì#

Một trong những thay đổi lớn nhất với mình là khái niệm Definition of Done. Code chạy trên máy mình chưa phải là xong. Một story chỉ xong khi:

• Code đã được review và merge.
• Có test cho phần logic quan trọng, pipeline CI chạy xanh.
• Đã deploy lên môi trường kiểm thử, QA xác nhận đạt tiêu chí chấp nhận.
• Tài liệu hoặc ghi chú cần thiết đã được cập nhật.

Khi cả team dùng chung một định nghĩa "xong", những câu kiểu "xong rồi, chỉ còn test thôi" biến mất, và tiến độ trên board phản ánh đúng thực tế.

Một ngày của developer trong sprint#

1. Đọc kỹ story và tiêu chí chấp nhận trước khi mở editor. Chỗ nào chưa rõ thì hỏi ngay trên ticket để câu trả lời được lưu lại.
2. Chia nhỏ việc thành các bước có thể merge riêng. Pull request nhỏ được review nhanh hơn và ít lỗi hơn.
3. Cập nhật board theo thời gian thực. Kéo ticket sang đúng cột, ghi chú khi bị chặn. Board là nơi cả team nhìn vào, không ai phải hỏi "cái này tới đâu rồi".
4. Review code của người khác mỗi ngày. Một PR nằm chờ review hai ngày làm chậm cả team hơn là mình code chậm đi một giờ.
5. Báo sớm khi có rủi ro. Nếu thấy story không kịp trong sprint, nói ngay ở stand-up thay vì để tới ngày cuối.
6. Làm việc gần với QA. Hỏi QA định test thế nào trước khi code xong, và tự test theo tiêu chí chấp nhận trước khi chuyển ticket.

Velocity và cách làm team nhanh hơn#

Velocity là tổng story point team hoàn thành trong một sprint. Sau vài sprint, con số này giúp team ước lượng thực tế hơn: nếu trung bình là 30 điểm thì đừng cam kết 50.

Velocity không phải KPI để so sánh giữa các team hay giữa các cá nhân. Ép velocity tăng bằng cách thổi phồng story point chỉ làm con số mất ý nghĩa. Thứ thật sự làm team nhanh hơn là bớt thời gian chờ và bớt làm lại:

• Yêu cầu rõ trước khi code nhờ refinement tốt, nên ít phải làm lại.
• Review nhanh, PR nhỏ, nên ticket không nằm chờ.
• CI/CD tự động, nên không ai mất nửa ngày để deploy hay chạy test tay.
• Ít việc dang dở cùng lúc. Hoàn thành một story trước khi nhận story mới thay vì mở năm story một lúc.
• Gỡ vướng nhanh. Bị chặn quá nửa ngày thì nói ra, đừng ngồi một mình.

Làm việc với khách hàng#

Dự án mình tham gia là phần mềm doanh nghiệp cho một khách hàng nước ngoài, nên giao tiếp với khách là một phần quan trọng của quy trình:

• Demo là lúc xây dựng niềm tin. Chuẩn bị kịch bản, dữ liệu mẫu, và chạy thử trước buổi demo. Một demo trơn tru có giá trị hơn nhiều email cập nhật tiến độ.
• Phản hồi đi vào backlog, không đi thẳng vào code. Khi khách muốn đổi gì đó giữa sprint, ghi lại thành story để PO sắp xếp ưu tiên, thay vì âm thầm sửa và làm vỡ cam kết của sprint.
• Viết rõ ràng, có ngữ cảnh. Làm việc khác múi giờ thì tin nhắn phải tự đứng được: vấn đề là gì, đã thử gì, cần khách quyết định điều gì.

Kết#

Agile không phải là họp nhiều hơn hay dùng Jira cho đúng cột. Nó là một nhịp làm việc giúp cả team, kể cả khách hàng, nhìn thấy cùng một bức tranh: đang làm gì, vì sao làm, và đã thật sự xong chưa. Với mình, thay đổi lớn nhất sau vài sprint là thói quen hỏi sớm, chia nhỏ, và báo sớm. Ba thói quen đó giúp ích ở bất kỳ team nào, kể cả khi không có ai gọi nó là Agile.