Scrum Guide 2020 – Bản dịch tiếng Việt – Phần 3/4

*******

Lưu ý: để đảm bảo về nghĩa, một số thuật ngữ sẽ được giữ nguyên nhé các bạn, tìm hiểu về thuật ngữ trước khi đọc Scrum Guide nhé. Các bạn tham khảo Tại đây 

********

SPRINT

Sprint là nhịp đập (heartbeat) của Scrum, nơi mà các ý tưởng được biến thành giá trị.

Sprint có độ dài cố định từ một tháng trở xuống để tạo sự nhất quán. Một Sprint mới bắt đầu NGAY SAU khi Sprint trước đó kết thúc.

Tất cả các công việc cần thiết để đạt được Product Goal, bao gồm Lập kế hoạch Sprint (Sprint Planning), Scrums hàng ngày (Daily Scrums), Sơ kết Sprint (Sprint Review) và Cải tiến Sprint (Sprint Retrospective) đều diễn ra trong Sprint.

Trong Sprint:

  • Không có thay đổi nào được thực hiện mà có thể gây nguy hiểm cho Sprint Goal
  • Chất lượng không giảm
  • Product Backlog được tinh chỉnh khi cần thiết
  • Phạm vi có thể được làm rõ và đàm phán lại với Product Owner khi nhiều thông tin được học hơn.

Sprint cho phép khả năng dự đoán bằng việc đảm bảo thanh tra và thích nghi hướng tới Product Goal diễn ra ít nhất mỗi tháng một lần. Khi thời hạn của Sprint quá dài, Sprint Goal có thể trở nên không hợp lệ, sự phức tạp có thể tăng lên, và rủi ro có thể tăng lên. Sprint ngắn hơn có thể được sử dụng để tạo ra nhiều chu kỳ học hơn và hạn chế rủi ro về chi phí và nỗ lực trong một khung thời gian nhỏ hơn. Mỗi Sprint có thể được coi là một dự án ngắn.

Có nhiều phương pháp khác nhau để dự báo tiến độ, chẳng hạn như burn-down, burn-up hoặc các luồng tích lũy (cumulative flows). Mặc dù đã được chứng minh là hữu ích, nhưng những điều này không thay thế được tầm quan trọng của chủ nghĩa thực nghiệm. Trong các môi trường phức tạp, điều gì sẽ xảy ra là điều chưa biết được. Chỉ những gì đã xảy ra mới có thể được sử dụng để đưa ra quyết định hướng tới tương lai.

Một Sprint có thể bị hủy bỏ nếu Sprint Goal trở nên lỗi thời. Chỉ Product Owner mới có quyền hủy bỏ Sprint.

LẬP KẾ HOẠCH SPRINT (SPRINT PLANNING)

Sprint Planning bắt đầu Sprint bằng cách sắp xếp công việc sẽ được thực hiện cho Sprint. Kết quả kế hoạch này được tạo ra bởi công việc cộng tác của toàn bộ Scrum Team.

Product Owner đảm bảo rằng những người tham dự sẵn sàng thảo luận về các hạng mục quan trọng nhất trong Product Backlog và cách chúng ánh xạ tới Product Goal. Scrum Team cũng có thể mời những người khác tham dự để được họ đưa ra các lời khuyên.

Sprint Planning hướng tới các chủ đề sau:

Chủ đề thứ nhất: Tại sao Sprint này có giá trị?

Product Owner đề xuất cách để sản phẩm có thể tăng giá trị và tiện ích của nó trong Sprint hiện tại. Sau đó, toàn bộ Scrum Team sẽ hợp tác để xác định Sprint Goal nhằm truyền đạt lý do tại sao Sprint lại có giá trị đối với các bên liên quan.

Sprint Goal phải được hoàn thiện trước khi kết thúc Sprint Planning.

Chủ đề thứ hai: Điều gì có thể hoàn thành trong Sprint này?

Thông qua thảo luận với Product Owner, Developers chọn các hạng mục từ Product Backlog để đưa vào Sprint hiện tại. Scrum Team có thể tinh chỉnh các hạng mục này trong quá trình này giúp làm tăng sự hiểu biết và sự tự tin.

Việc chọn số lượng có thể hoàn thành trong Sprint là bao nhiêu có thể là một thách thức. Tuy nhiên, Developers càng biết nhiều về hiệu suất trong quá khứ, năng lực sắp tới và Định nghĩa Hoàn thành thì họ sẽ càng tự tin hơn trong các dự báo Sprint.

Chủ đề thứ ba: Công việc đã chọn sẽ được thực hiện như thế nào?

Đối với mỗi hạng mục trong Product Backlog đã chọn, Developers lập kế hoạch công việc cần thiết để tạo Phần tăng trưởng đáp ứng Định nghĩa Hoàn thành. Điều này thường được thực hiện bằng cách phân tách các hạng mục trong Product Backlog thành các hạng mục công việc nhỏ hơn có thể hoàn thành trong một ngày hoặc ít hơn. Việc này được thực hiện như thế nào là tùy theo quyết định của Developers. Không một ai khác có thể nói cho họ biết cách biến các hạng mục trong Product Backlog thành các Phần tăng trưởng giá trị.

Sprint Goal, các hạng mục trong Product Backlog được lựa chọn cho Sprint, cộng với kế hoạch phân phối được gọi chung là Sprint Backlog.

Sprint Planning được đóng khung thời gian tối đa là 8 giờ cho Sprint một tháng. Đối với Sprint ngắn hơn thì thời gian diễn ra sự kiện này thường ngắn hơn.

SCRUM HÀNG NGÀY (DAILY SCRUM)

Mục đích của Daily Scrum là thanh tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog khi cần thiết, điều chỉnh công việc sắp tới đã lên kế hoạch.

Daily Scrum là một sự kiện kéo dài 15 phút dành cho Developers của Scrum Team. Để giảm bớt sự phức tạp, nó được tổ chức tại cùng một thời điểm và cùng địa điểm của mỗi ngày làm việc của Sprint. Nếu Product Owner hoặc Scrum Master đang tham gia trên các hạng mục trong Sprint Backlog, họ sẽ tham gia với tư cách là Developers.

Developers có thể chọn bất kỳ cấu trúc và kỹ thuật nào họ muốn, miễn là Daily Scrum của họ tập trung vào tiến độ hướng tới Sprint Goal và tạo ra một kế hoạch khả thi cho ngày làm việc tiếp theo. Điều này tạo ra sự tập trung và cải thiện khả năng tự quản lý.

Daily Scrum giúp cải thiện thông tin giao tiếp, xác định các trở ngại, thúc đẩy quá trình ra quyết định nhanh chóng và do đó loại bỏ nhu cầu tổ chức các cuộc họp khác.

Daily Scrum không chỉ là thời gian duy nhất mà Developers được phép điều chỉnh kế hoạch. Họ thường trao đổi suốt cả ngày để thảo luận chi tiết hơn về việc điều chỉnh hoặc lập kế hoạch lại phần còn lại của công việc trong Sprint.

SPRINT REVIEW

Mục đích của Sprint Review là kiểm tra kết quả của Sprint và xác định các điều chỉnh trong tương lai. Scrum Team trình bày kết quả công việc cho các bên liên quan chính và tiến độ hướng tới Product Goal được mang ra thảo luận.

Trong sự kiện này, Scrum Team và các bên liên quan xem xét những gì đã hoàn thành trong Sprint và những gì đã thay đổi trong môi trường của họ. Dựa trên thông tin này, những người tham dự hợp tác về những việc cần làm tiếp theo. Product Backlog cũng có thể được điều chỉnh để đáp ứng các cơ hội mới. Sprint Review là một phiên làm việc và Scrum Team nên tránh việc chỉ giới hạn nó trong một bài thuyết trình.

Sprint Review là sự kiện áp chót của Sprint và được đóng khung thời gian tối đa là 4 giờ cho một Sprint kéo dài một tháng. Đối với Sprint ngắn hơn, thời gian diễn ra sự kiện thường ngắn hơn.

SPRINT RETROSPECTIVE

Mục đích của Sprint Retrospective là lập kế hoạch các cách để tăng chất lượng và hiệu quả. Scrum Team thanh tra Sprint trước diễn ra như thế nào liên quan đến các cá nhân, tương tác, quy trình, công cụ và Định nghĩa Hoàn thành. Các yếu tố được thanh tra thường thay đổi theo lĩnh vực công việc.

Các giả định khiến họ lạc đường được xác định và nguồn gốc của chúng được khám phá. Scrum Team thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề gặp phải và những vấn đề đó đã (hoặc chưa) được giải quyết như thế nào.

Scrum Team xác định những thay đổi hữu ích nhất để nâng cao hiệu quả. Các cải tiến có tác động nhất phải được giải quyết càng sớm càng tốt. Chúng thậm chí có thể được thêm vào Sprint Backlog cho Sprint tiếp theo.

Sprint Retrospective là hoạt động kết thúc Sprint. Nó được đóng khung thời gian tối đa là 3 giờ cho Sprint một tháng. Đối với Sprint ngắn hơn, thời gian diễn ra sự kiện thường ngắn hơn.

Bản gốc Tiếng Anh Scrum Guide 2020, các bạn có thể tải về Tại đây.

Ezami

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *