Ngày đầu đi làm, chúng ta được phổ biến: "Bên mình làm Agile nhé."
Mình gật đầu tự tin. Mình đã đọc Scrum Guide. Mình biết Sprint là gì, Daily Standup là gì, Retrospective là gì.
Tuần đầu tiên, mình nhận ra mình chưa biết gì cả.
Không phải vì Agile sai. Mà vì Agile ngoài đời thật trông khác hoàn toàn so với Agile trong sách, và không ai nói với mình điều đó trước.
Vỡ mộng số 1, Sprint Planning
Trong sách: team cùng nhau estimate story points, chọn item từ backlog đã được chuẩn bị kỹ, cam kết Sprint Goal trong khoảng 2 tiếng.
Ngoài đời thật: sếp đã quyết định làm gì từ tuần trước. Sprint Planning chỉ là buổi họp để ghi lại quyết định đó. Backlog chưa được refined, Dev phải đặt câu hỏi ngay trong buổi planning, kéo dài 4 tiếng mà vẫn chưa xong.
BA cần làm gì? Refined backlog ít nhất 2 ngày trước Sprint Planning. Mỗi User Story phải có Acceptance Criteria rõ ràng trước khi bước vào phòng họp. Đây là trách nhiệm của BA, không phải của ai khác.
Vỡ mộng số 2, Daily Standup
Trong sách: 15 phút, 3 câu hỏi, đúng giờ, đúng format, team ra về biết việc cần làm trong ngày.
Ngoài đời thật: 45 phút. Người thì report xong rồi ngồi im nhìn điện thoại. Người thì bắt đầu kể chi tiết bug từ hôm qua, giải thích cách fix, ai đó góp ý, thành cuộc họp kỹ thuật không có hồi kết.
BA cần làm gì? Khi thấy discussion đang đi quá sâu vào chi tiết kỹ thuật, hãy chủ động ghi chú lại và đề nghị tách ra thành một cuộc họp riêng ngay sau standup. Đây không phải việc của Scrum Master, BA hoàn toàn có thể làm điều này mà không cần chức danh.
Vỡ mộng số 3, Sprint Review và Retrospective
Trong sách: Review là buổi demo thật cho stakeholder để nhận feedback thật. Retrospective là không gian an toàn để team nói thẳng vấn đề và tìm cách cải thiện.
Ngoài đời thật: Review bị cancel vì stakeholder bận họp khác. Retrospective chỉ nói điều tốt, "What went well" thì đầy, "What can be improved" thì im lặng vì không ai muốn làm phật lòng đồng nghiệp.
BA cần làm gì? Nếu stakeholder vắng mặt ở Review, record lại demo và gửi kèm tóm tắt. Trong Retrospective, BA là người có nhiều quan sát nhất về cả hai phía kỹ thuật và nghiệp vụ, hãy chủ động nêu vấn đề về communication hoặc requirement thay vì chờ người khác lên tiếng trước.
Vỡ mộng số 4, thay đổi requirement giữa Sprint
Trong sách: Sprint backlog không thay đổi trong Sprint. Yêu cầu mới vào backlog, được prioritize cho Sprint sau.
Ngoài đời thật: Sếp nhắn tin lúc 2h chiều thứ Ba: "Thêm tính năng này vào Sprint này nhé, client yêu cầu gấp." Không ai dám từ chối, cả team gật đầu rồi làm thêm giờ cả tuần.
BA cần làm gì? Đây chính xác là thời điểm BA phải lên tiếng, không phải im lặng theo. Câu cần nói rất đơn giản: "Nếu thêm Story này vào Sprint, chúng ta cần bỏ Story nào ra để đảm bảo Sprint Goal? Anh chị quyết định nhé."
Câu đó không từ chối ai. Nhưng nó đặt quyết định đúng chỗ, ở đúng người có thẩm quyền, và buộc mọi người đối mặt với trade-off thay vì giả vờ không có gì xảy ra.
Vỡ mộng số 5, "done" nghĩa là gì
Trong sách: team có Definition of Done rõ ràng, code reviewed, tested, deployed to staging, acceptance criteria passed.
Ngoài đời thật: Dev nói "done" nghĩa là code chạy được trên máy local của họ. BA hiểu "done" là pass acceptance criteria. Tester hiểu là pass test case. Client hiểu là sẵn sàng đưa lên production. Cuối Sprint, không ai thống nhất được tính năng đó "xong" hay chưa.
BA cần làm gì? BA là người phải định nghĩa "done" từ đầu, bằng Acceptance Criteria cụ thể, đo được, không mơ hồ. Đừng viết "hệ thống hoạt động bình thường." Hãy viết "người dùng hoàn thành giao dịch trong vòng 30 giây, nhận thông báo xác nhận qua email trong vòng 1 phút."
Khi "done" được định nghĩa rõ ràng, mọi tranh cãi cuối Sprint đều biến mất.
Bạn cần hiểu trước khi đi làm:
Agile không phải bộ quy tắc cứng nhắc. Đó là một tập hợp nguyên tắc, và mỗi team áp dụng theo cách riêng của mình, tốt có, xấu có, hỗn hợp có.
Công ty nói "chúng tôi làm Agile" không có nghĩa là họ làm đúng Agile. Và điều đó không nhất thiết là xấu, miễn là team vẫn deliver được giá trị cho người dùng.
Nhiệm vụ của BA không phải là enforce Scrum như một cảnh sát quy trình. Nhiệm vụ của BA là làm cho team hoạt động hiệu quả hơn trong bất kỳ môi trường nào họ đang có, kể cả khi môi trường đó không hoàn hảo.
Và để làm được điều đó, bạn cần biết khoảng cách giữa lý thuyết và thực tế trông như thế nào.
