Các nghi thức Agile (Agile Ceremonies)
1. Lập kế hoạch Sprint (Sprint Planning)
Mục tiêu (Goals)
- Buổi lập kế hoạch tuân thủ các nguyên tắc Đa dạng và Hòa nhập (Diversity and Inclusion), mang lại cơ hội bình đẳng cho mọi thành viên.
- Xác định rõ công việc sẽ được hoàn thành như thế nào trong suốt sprint.
- Các User Story vừa vặn trong một sprint, đã được thiết kế kiến trúc và đạt trạng thái sẵn sàng (Ready) trước buổi lập kế hoạch.
Lưu ý: Việc các thành viên tự nhận việc (self-assignment) thoạt nhìn có vẻ tạo cảm giác công bằng. Tuy nhiên trên thực tế, điều này đôi khi tạo lợi thế cho những tiếng nói lớn nhất hoặc những người có nhiều kinh nghiệm nhất nhóm. Ngoài ra, các cá nhân có xu hướng ở mãi trong vùng an toàn của mình, điều này không có lợi cho sự phát triển lâu dài của bản thân họ.
Lưu ý khi làm việc với công cụ AI: Một số nhóm điều chỉnh nhịp độ lập kế hoạch sprint để thích ứng với tốc độ làm việc nhanh hơn mà các công cụ AI mang lại — ưu tiên các buổi lập kế hoạch ngắn gọn, nhẹ nhàng hoặc lập kế hoạch liên tục khi điều này giúp vòng lặp phản hồi và bàn giao diễn ra nhanh hơn. Hãy sử dụng các công cụ hỗ trợ AI (như Copilot hoặc trợ lý lập kế hoạch) để phác thảo kế hoạch hoặc tiêu chí chấp nhận (acceptance criteria), nhưng luôn phối hợp cùng toàn đội để kiểm chứng và điều chỉnh kết quả.
Mục tiêu Sprint (Sprint Goal)
Hãy cân nhắc xác định một mục tiêu sprint rõ ràng (hoặc danh sách các mục tiêu cụ thể) cho mỗi sprint. Một mục tiêu sprint hiệu quả thường là danh sách các gạch đầu dòng ngắn gọn. Mục tiêu có thể được đặt ra trước để làm căn cứ lựa chọn các Story đưa vào sprint, hoặc được đúc kết từ danh sách các Story đã chọn.
Mục tiêu Sprint có thể được sử dụng:
- Vào cuối mỗi buổi họp Stand-up hàng ngày, như chiếc "kim chỉ nam" giúp toàn đội lùi lại một bước để nhìn vào bức tranh lớn.
- Trong buổi Sprint Review ("Chúng ta đã đạt được mục tiêu chưa?", "Nếu chưa, nguyên nhân do đâu?").
Mẹo: Cách đơn giản nhất để xác định mục tiêu sprint là tạo một User Story trong sprint backlog có tên
"Mục tiêu Sprint XX", và đưa các gạch đầu dòng mục tiêu vào phần mô tả.
Phân bổ User Story
Ví dụ 1: Chuẩn bị từ trước
- Dev Lead và Product Owner dành thời gian chuẩn bị trước sprint backlog trước khi buổi họp diễn ra.
- Dev Lead vận dụng kinh nghiệm (từ các dự án trước và dự án hiện tại) cùng với điểm ước lượng (estimation) để ước lượng số lượng story phù hợp cho sprint.
- Dev Lead đề nghị toàn đội xem trước bản dự thảo sprint backlog.
- Dev Lead chỉ định story cho các lập trình viên cụ thể sau khi đã thảo luận và xác nhận với họ.
- Trong buổi họp Sprint Planning, toàn đội xem lại mục tiêu sprint và các story. Mọi người cùng xác nhận đã hiểu rõ kế hoạch và cảm thấy khả thi.
Ví dụ 2: Xây dựng backlog ngay trong buổi họp
- Product Owner đảm bảo các hạng mục ưu tiên cao nhất của Product Backlog đã được làm mịn (refine) và ước lượng theo đúng quy trình của đội.
- Trong buổi họp, Product Owner trình bày từng story theo thứ tự ưu tiên từ cao xuống thấp.
- Với mỗi story, Dev Lead và toàn đội xác nhận đã hiểu rõ yêu cầu và đưa story đó vào sprint backlog.
- Đội tiếp tục xem xét các story tiếp theo cho đến khi cùng đồng thuận rằng dung lượng sprint đã đầy (dựa trên ước lượng, kinh nghiệm trong quá khứ và vận tốc thực tế của dự án).
- Phân công story trong buổi họp:
- Lựa chọn 1: Dev Lead đưa ra gợi ý ai phù hợp làm story nào. Các kỹ sư đồng thuận hoặc trao đổi nếu cần.
- Lựa chọn 2: Toàn đội xem xét từng story và kỹ sư xung phong nhận story mình muốn làm.
(Lưu ý: Lựa chọn 2 có thể gặp vấn đề về cơ hội bình đẳng: Ai sẽ được làm việc hay, việc khó? Trách nhiệm cuối cùng thuộc về Dev Lead trong việc đảm bảo mỗi kỹ sư đều có cơ hội phát triển năng lực cá nhân).
Chia nhỏ thành các Task (Công việc cụ thể)
Một số cách tiếp cận để tạo và phân chia task:
- Dev Lead chia nhỏ story thành các task từ trước và phân công cho các kỹ sư trước/trong buổi planning.
- Giao story cho các kỹ sư có kinh nghiệm (senior), họ sẽ chịu trách nhiệm chia nhỏ thành các task.
- Toàn đội cùng nhau chia nhỏ story thành các task ngay trong buổi Sprint Planning.
Gợi ý: Tùy thuộc vào trình độ chuyên môn của đội, hãy cân nhắc chia nhỏ task trước buổi planning. Điều này giúp kết thúc buổi planning với toàn bộ công việc đã được giao cụ thể, đồng thời tăng sự rõ ràng cho các bạn junior.
Tài nguyên tham khảo về Sprint Planning
- Tiêu chuẩn sẵn sàng (Definition of Ready)
- Sprint Goal Template (Mẫu mục tiêu Sprint)
- Sprint Planning (Hướng dẫn Scrum Guide)
- Làm mịn Backlog (Diligent Backlog Refinement)
- Sách: User Stories Applied (Áp dụng User Story trong phát triển phần mềm)
2. Ước lượng (Estimation)
Mục tiêu (Goals)
- Việc ước lượng củng cố tính dự đoán được về khối lượng công việc và tiến độ bàn giao của đội.
- Củng cố tinh thần trách nhiệm (accountability) của từng thành viên trước toàn đội.
- Quy trình ước lượng được cải tiến liên tục qua thời gian và được thảo luận định kỳ.
- Quá trình ước lượng mang tính hòa nhập, ghi nhận góc nhìn của nhiều thành viên khác nhau.
Việc ước lượng sơ bộ thường dựa trên năng lực của một lập trình viên cấp trung tiêu chuẩn (mid-level developer) hoặc dựa trên vận tốc lịch sử (historical velocity) của nhóm.
Ví dụ 1: Kích cỡ áo thun (T-shirt Sizes)
- Đội sử dụng kích thước áo thun (S, M, L, XL) và thống nhất trước kích thước nào vừa vặn trong một sprint. Ví dụ: S, M vừa trong một sprint; L, XL quá lớn và bắt buộc phải chia nhỏ / làm mịn thêm.
- Dev Lead cùng đội ngũ ước lượng sơ bộ số lượng story cỡ S và M có thể hoàn thành trong các sprint đầu tiên.
- Ước lượng thô này sẽ được tinh chỉnh dần theo thời gian, làm dữ liệu đầu vào cho các buổi lập kế hoạch tương lai và dự báo ngày hoàn thành dự án.
Ví dụ 2: Chỉ số đơn lẻ (Single Indicator)
- Đội chỉ dùng một tiêu chí duy nhất: "Story này có thể làm xong trong một sprint không?". Nếu không, bắt buộc phải chia nhỏ.
- Dev Lead cùng đội ước tính sơ bộ trung bình làm được bao nhiêu story mỗi sprint.
- Con số trung bình này dùng làm đầu vào cho kế hoạch sprint tiếp theo và điều chỉnh dự báo ngày kết thúc dự án.
Ví dụ 3: Planning Poker (Đánh bài Poker ước lượng)
- Đội tổ chức Planning Poker và ước lượng bằng điểm số (Story Points).
- Story point dùng để ước lượng lượng việc có thể hoàn thành trong sprint tiếp theo.
- Dev Lead và Technical Program Manager (TPM) dựa vào vận tốc thực tế qua các sprint để cập nhật dự báo tiến độ dự án.
Các lưu ý khác (Other Considerations)
- Việc dùng Story Point cho các dự án quy mô nhỏ không phải lúc nào cũng mang lại giá trị như ở các dự án lớn.
- Tránh quy đổi Story Point hoặc cỡ áo thun sang số ngày/giờ làm việc.
Đo lường độ chính xác của ước lượng
- Thu thập dữ liệu để theo dõi độ chính xác của ước lượng và tỷ lệ hoàn thành sprint qua thời gian để thúc đẩy cải tiến.
- Sử dụng Mục tiêu Sprint (Sprint Goal) để đánh giá ước lượng có chuẩn xác hay không. Nếu đạt được mục tiêu sprint, các con số khác không còn quá quan trọng!
Thực hành Scrum chuyên nghiệp
Mặc dù Scrum không quy định cứng nhắc cách đo kích thước công việc, nhưng Scrum chuyên nghiệp luôn hướng tới ước lượng tương đối (relative sizing) thay vì ước lượng tuyệt đối (giờ, điểm chức năng, ngày lý tưởng).
- Planning Poker: Kỹ thuật cộng tác để gán kích thước tương đối (sử dụng story points, cỡ áo thun, v.v.).
- PBI đồng kích cỡ ('Same-Size' PBIs): Chia nhỏ mọi hạng mục sao cho chúng có kích cỡ tương đương nhau. Vận tốc lúc này được tính đơn giản bằng số lượng PBI hoàn thành.
- PBI đúng kích cỡ ('Right-Size' PBIs): Chia nhỏ công việc vừa đủ để chắc chắn bàn giao được giá trị trong chu kỳ (hoàn thành trước khi hết sprint).
Tài nguyên tham khảo về Ước lượng
3. Họp cải tiến (Retrospectives)
Mục tiêu (Goals)
- Đưa ra các hành động cụ thể (action items) giúp nâng cao thực hành kỹ thuật của đội ngũ. Các hạng mục này phải được đưa vào backlog, chỉ định người phụ trách và ấn định hạn chót hoàn thành (thường là trước buổi retro tiếp theo).
- Là nơi dám đặt ra những câu hỏi thẳng thắn, khó khăn khi cần thiết ("Chúng ta thường không làm xong những gì đã lập kế hoạch, hãy thẳng thắn bàn về vấn đề này").
Gợi ý thực hành
- Cân nhắc thử nghiệm các format retro khác ngoài Mad Sad Glad:
- Thu thập dữ liệu (Gather Data): Triple Nickels, Timeline, Mad Sad Glad, Team Radar.
- Tìm kiếm hiểu biết sâu (Generate Insights): 5 Whys (5 câu hỏi Tại sao), Biểu đồ xương cá (Fishbone), Nhận diện mô hình và sự dịch chuyển (Patterns and Shifts).
- Đặt ra trọng tâm cụ thể cho từng buổi retro (Retro focus area).
- Sắp xếp đủ thời gian để có những cuộc thảo luận chất lượng nhằm tạo ra kế hoạch hành động đúng đắn.
- Mời một người điều phối trung lập (neutral facilitator) cho các buổi retro tổng kết dự án hoặc sau một giai đoạn khó khăn.
Kỹ thuật "5 Whys" (5 câu hỏi Tại sao)
Khi nhóm gặp một vấn đề phức tạp và chưa rõ nguyên nhân gốc rễ, bài tập 5 Whys sẽ giúp đào sâu tận đáy vấn đề. Ví dụ: Nếu nhóm liên tục không đạt trạng thái Done mỗi sprint, viết vấn đề đó lên đầu bảng. Nhóm hỏi "Tại sao vấn đề này xảy ra?" và ghi câu trả lời xuống dưới. Tiếp tục hỏi "Tại sao?" cho chính câu trả lời vừa nhận được. Lặp lại quá trình này (thường trong vòng 5 bước) là nguyên nhân gốc rễ thực sự sẽ lộ diện.
Quy trình, Công cụ, Con người, Tương tác và Định nghĩa Hoàn thành
Cách tiếp cận này khuyến khích toàn đội suy nghĩ rộng hơn. Đề nghị các thành viên chỉ ra những gì đang vận hành tốt và những ý tưởng cải tiến theo 4 nhóm: Quy trình (Processes), Công cụ (Tools), Con người & Tương tác (Individuals/Interactions), và Định nghĩa Hoàn thành (Definition of Done). Sau đó, bỏ phiếu chọn ra các ý tưởng cải tiến trọng tâm cho sprint tới.
Kỹ thuật Tiêu điểm (Focus)
Kỹ thuật này gắn liền với tư duy định hướng tầm nhìn (visioning). Hãy hỏi các thành viên: "Đội ngũ chúng ta muốn trở thành như thế nào sau 4 tuần nữa?". Sau đó xác định những rào cản nào đang ngăn cản mục tiêu đó và cách tháo gỡ.
Tài nguyên tham khảo về Retrospective
4. Buổi Demo Sprint (Sprint Demo / Sprint Review)
Mục tiêu (Goals)
- Mỗi sprint kết thúc bằng buổi demo minh họa mục tiêu sprint đã đạt được như thế nào và đóng góp ra sao vào mục tiêu chung của toàn bộ dự án.
Gợi ý thực hành
- Không nhất thiết phải quay video demo trước. Bạn có thể demo trực tiếp và ghi âm/ghi hình lại buổi họp để lưu trữ.
- Buổi demo không nhất thiết lúc nào cũng phải chạy code. Đó có thể là buổi giới thiệu tài liệu kiến trúc vừa được hoàn thành.
Tài nguyên tham khảo về Sprint Demo
5. Họp nhanh hàng ngày (Stand-Up / Daily Scrum)
Mục tiêu (Goals)
- Buổi họp diễn ra ngắn gọn, hiệu quả.
- Giúp toàn đội nắm bắt: Đã làm xong gì? Sẽ làm gì tiếp theo? Có khó khăn, vướng mắc (blockers) nào không?
- Giúp toàn đội đánh giá xem có khả năng đạt được mục tiêu sprint hay không.
Gợi ý thực hành
- Giữ buổi họp ngắn gọn và đúng trọng tâm. Tạm gác các cuộc thảo luận chuyên sâu vào phần "bãi đỗ xe" (Parking Lot) hoặc lên lịch trao đổi riêng sau đó.
- Công thức lý tưởng: 15 phút standup chính thức + 15 phút thảo luận chuyên sâu (parking lot).
- Nếu ai đó vắng mặt đột xuất: Yêu cầu họ gửi bản cập nhật bằng văn bản trước giờ họp.
- Standup cần có sự tham gia của mọi bên liên quan trong dự án, bao gồm cả đại diện khách hàng.
- Tránh các dự án có múi giờ quá chênh lệch nếu có thể. Nếu bắt buộc, hãy điều chỉnh hình thức standup sao cho phù hợp với quỹ thời gian của tất cả thành viên.