Scrum
Khung làm việc nhẹ gồm 3 accountability, 5 event và 3 artifact, giúp nhóm nhỏ chia việc thành chu kỳ ngắn, làm ra thứ dùng được rồi nhìn lại và điều chỉnh.
Định nghĩa
Scrum là bộ khung nhẹ để một nhóm nhỏ xử lý vấn đề phức tạp: chia việc thành chu kỳ ngắn, mỗi chu kỳ làm ra thứ dùng được, rồi nhìn lại và chỉnh hướng. Nó cố tình để trống rất nhiều chỗ. Scrum Guide 2020 chỉ dài chừng 13 trang và không hề bắt bạn viết user story, không nhắc tới Jira, cũng không nói team phải estimate bằng story point.
Scrum không dạy bạn làm cho đúng. Nó bày ra đủ thứ để cái sai lộ ra sớm, còn sửa hay không là chuyện của team.
Bộ khung gồm những gì
Ba accountability: Product Owner, Scrum Master, Developers. Từ "Development Team" đã bị bỏ khỏi bản 2020 — giờ chỉ còn Developers, và họ nằm chung một Scrum Team với PO và Scrum Master thay vì là một nhóm con bên trong. Scrum Team thường 10 người trở xuống.
Năm event: Sprint là khung chứa, bên trong có Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Sprint dài tối đa một tháng. Sprint này kết thúc là sprint sau bắt đầu ngay, không có tuần nghỉ giữa hiệp.
Ba artifact, mỗi cái kèm một cam kết:
| Artifact | Là gì | Cam kết đi kèm |
|---|---|---|
| Product Backlog | Danh sách mọi thứ cần làm cho sản phẩm, đã sắp thứ tự | Product Goal |
| Sprint Backlog | Sprint Goal, các item đã chọn và kế hoạch thực hiện | Sprint Goal |
| Increment | Phần sản phẩm dùng được tạo ra trong sprint | Definition of Done |
Cam kết ở đây có nghĩa là mỗi artifact đều phải trả lời được câu "cái này phục vụ mục tiêu nào". Thiếu cam kết thì Product Backlog tụt xuống thành danh sách việc vặt, còn Increment thành đống code chưa ai dám bật lên.
Nền tảng phía dưới
Scrum dựa trên empiricism, tức ra quyết định dựa trên cái đã quan sát được, qua ba trụ: minh bạch, thanh tra, thích ứng. Kèm theo năm giá trị: cam kết, tập trung, cởi mở, tôn trọng, dũng cảm. Nghe như khẩu hiệu dán tường, nhưng nó có sức nặng thật vào cái ngày bạn phải đứng trước khách nói rằng sprint này không kịp.
Ví dụ thực tế
Chuỗi bán lẻ 43 cửa hàng, kiểm kê cuối tháng ngốn của mỗi cửa hàng gần 6 tiếng và luôn rơi vào đêm chủ nhật. Product Goal quý này của team làm module kho cho ERP nội bộ: kéo con số đó xuống dưới 2 tiếng. Sáu người, sprint 2 tuần.
Sprint 3 có Sprint Goal là "nhân viên kho quét mã bằng điện thoại thay vì đối chiếu giấy". Team chọn 5 item, làm xong 4. Ở Sprint Review, một quản lý cửa hàng thử ngay trên máy và phát hiện app không quét được mã in mờ — loại mã chiếm khoảng một phần ba hàng tồn cũ. Cái đó không nằm trong bất kỳ tài liệu nào. Nó chỉ lộ ra vì có người dùng thật cầm điện thoại thật trong 20 phút. Item xử lý mã mờ được thêm vào Product Backlog ngay chiều đó.
Lỗi hay gặp
- ScrumFall. Vẫn phân tích hết, thiết kế hết, rồi mới chia sprint để code. Sprint chỉ còn là cách chia lịch.
- Test dồn sang sprint sau. Increment cuối sprint chưa test thì chưa Done, và chưa Done thì không tính là Increment.
- Không có Definition of Done. Mỗi người hiểu "xong" một kiểu, cuối cùng cãi nhau ở lúc release.
- Scrum Master kiêm luôn chấm KPI. Team không dám nói thật ở retro nữa.
- "Scrum but". Kiểu "bọn mình làm Scrum, nhưng không có retro, và PO là ba người". Bỏ bớt cấu phần thì phần còn lại vẫn chạy được, chỉ là mất luôn cơ chế phát hiện vấn đề.
Mẹo khi đi làm
Nếu công ty bạn mới chuyển sang Scrum và mọi thứ còn lộn xộn, đừng tranh cãi về việc có đúng chuẩn hay không trong hai tháng đầu. Chọn giữ ba thứ trước: sprint có độ dài cố định, Definition of Done viết ra giấy, và retro thật sự diễn ra. Ba thứ đó tạo ra vòng phản hồi, phần còn lại sẽ tự lộ ra chỗ cần sửa.
