Loạt bài về Scrum kì 4

Chào các bạn.

Chúng ta lại quay về với loạt bài dịch từ forum Scrum nhé. Trong bài trước, chúng ta đã biết rằng các Sprint là 1 tổ hợp các Scrum event. Vậy quá trình lên kế hoạch và thực hiện 1 Scrum sẽ cần những gì? Hãy cùng tìm hiểu trong bài này nhé.

Sprint Planning (Lên kế hoạch Sprint)

Việc lên kế hoạch cho Sprint khởi tạo Sprint bằng cách liệt kê ra các công việc cần làm trong Sprint. Kế hoạch trong bước này được tạo ra bằng công việc chung tay bởi cả Scrum Team. Product Owner đảm bảo rằng những người tham gia được chuẩn bị để bàn luận những mục quan trọng nhất trong Product Backlog và cách họ liên kết nó với Product Goal.

Scrum Team cũng có thể mời những người khác tham gia Sprint Planning để cung cấp lời khuyên. Sprint Planning trình bày những chủ đề sau:

Chủ đề 1: Tại sao Sprint này có giá trị? Product Owner đề xuất về cách mà sản phẩm có thể tăng giá trị và ích lợi của nó trong Sprint này. Cả Scrum Team sẽ hợp sức để định nghĩa một Sprint Goal có thể nói lên tại sao Sprint có giá trị cho các bên liên quan. Sprint Goal phải được chốt lại trước khi kết thúc giai đoạn Sprint Planning.

Chủ đề 2: Có thể làm những gì trong Sprint này?

Thông qua bàn luận với Product Owner, những nhà phát triển chọn ra các mục trong Product Backlog để nhét vào Sprint hiện tại. Scrum team có thể tinh lọc các mục này trong quá trình này, qua đó tăng thêm sự thấu hiểu và tự tin. Việc chọn bao nhiêu (mục) có thể hoàn thành trong 1 Sprint là một việc có khả năng gây khó khăn. Tuy nhiên, các Nhà phát triển biết càng nhiều về performance trong quá khứ, hạn mức sắp tới, và Định nghĩa hoàn thành, thì họ càng tự tin về dự báo cho Sprint.

Chủ đề 3: Cách hoàn thành những việc đã chọn.

Với mỗi mục trong Product Backlog được chọn, các nhà phát triển lên kế hoạch cho những việc cần làm để tạo nên sự gia tăng mà đáp ứng được Định nghĩa hoàn thành. Việc này thường được làm bằng cách phân tách các mục của Product Backlog thành các đầu mục công việc nhỏ hơn trong 1 ngày (hoặc ngắn hơn). Cách hoàn thành những việc này dựa vào sự cân nhắc của các nhà phát triển. Không ai khác có thể nói với họ về cách biến những đề mục Product Backlog thành sự gia tăng giá trị.

Mục tiêu của Sprint, các hạng mục của Product Backlog được chọn vào Sprint, cùng với kế hoạch bàn giao chúng được xem như Sprint Backlog.

Việc lên kế hoạch cho Sprint được tính theo các đơn vị thời gian có độ dài tối đa 8 tiếng (nguyên văn: timebox) cho 1 Sprint dài 1 tháng. Với các Sprint ngắn hơn, những sự kiện trong đó sẽ ngắn hơn.

Đoạn gạch dưới ở trên, tác giả dùng từ Timebox. Các bạn nên lưu ý từ này.

Mình có tra cứu thêm, thì Timebox là : In Agile principles, timeboxing allocates a fixed and maximum unit of time to an activity, called a timeboxing, within which planned activity takes place.

(Trong các nguyên tắc Agile, việc timebox chỉ định 1 đơn vị thời gian cố định và tối đa cho 1 hoạt động, mà trong đó các công việc đã được lên kế hoạch sẽ diễn ra).

Daily Scrum (Scrum hằng ngày)

Mục đích của Scrum hằng ngày là điều tra quá trình của Sprint Goal và tiếp nhận Sprint Backlog cũng như điều chỉnh những công việc được đưa vào kế hoạch sắp tới. Daily Scrum là 1 hoạt động 15 phút cho các nhà phát triển team Scrum. Để giảm độ phức tạp, nó được tiến hành cùng lúc cùng chỗ mỗi ngày làm việc trong Sprint. Nếu Product Owner hay Scrum Master đang làm việc cho các mục trong Sprint Backlog, họ cũng sẽ tham gia với với tư cách là Developers.

Hoạt động này có quen thuộc không nhỉ? Ở Sun* nó kết thúc bằng Wasshoi mỗi buổi sáng đấy.

Các nhà phát triển có thể chọn bất kỳ cấu trúc và kỹ thuật nào họ muốn, miễn là Scrum Hằng ngày của họ tập trung vào tiến độ hướng tới Mục tiêu Sprint và đưa 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ý. Scrums hàng ngày cải thiện thông tin liên lạc, xác định các trở ngại, thúc đẩy việc ra quyết định nhanh chóng và do đó loại bỏ nhu cầu cho các cuộc họp khác. Scrum Hằng ngày không phải là lần duy nhất Nhà phát triển được phép điều chỉnh kế hoạch của họ. Họ thường gặp nhau 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 của Sprint.

Sprint Review ( Xem lại Sprint) Mục đích của Sơ kết Sprint là để kiểm tra kết quả của Sprint và xác định các điều chỉnh trong tương lai. Nhóm Scrum trình bày kết quả công việc của họ cho các bên liên quan chính và tiến trình hướng tới Mục tiêu Sản phẩm sẽ được thảo luận. Trong sự kiện này, Nhóm Scrum và các bên liên quan xem xét những gì đã đạt được 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ự cộng 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. Đánh giá Sprint là một phiên làm việc và Nhóm Scrum nên tránh giới hạn nó trong một bài thuyết trình. Sơ kết Sprint là sự kiện thứ hai đến cuối cùng của Sprint và có thời gian tối đa là bốn giờ cho Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.

Sprint Retrospective

Có lẽ không ít lần bạn được leader gọi vào “họp rề trô” rồi đúng không? Vâng, “rề trô” ấy chính là cách nói của từ retrospective (theo từ điển là “nhìn lại hoặc giải quyết các tình huống, sự kiện trong quá khứ”.)

Mục đích của Sprint Retrospective là hoạch định các cách thức để tăng chất lượng và hiệu quả. Nhóm Scrum kiểm tra Sprint cuối cùng 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 về việc hoàn thành của họ. Các yếu tố được kiểm tra thường thay đổi theo lĩnh vực công việc. Các giả định khiến họ lạc lối được xác định và khám phá nguồn gốc của chúng. Nhóm Scrum thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề mà nó gặp phải và cách những vấn đề đó đã được giải quyết (hoặc không). Nhóm Scrum xác định những thay đổi hữu ích nhất để cải thiện hiệu quả của nhóm. Những cải tiến có tác động nhất đượ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 kết thúc Sprint. Nó có hộp thời gian tối đa là ba giờ cho một Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.

Điểm khác biệt giữa Review và Retro??

Sprint review là nói về sản phẩm trong khi Retro là về team của bạn. 
Review giúp bạn đạt yêu cầu của khách hàng trong khi retro giúp team bạn nâng  cao tinh thần, làm việc hiệu quả và thậm chí hạnh phúc hơn.

Scrum Artifacts (tạo tác Scrum)

Ở bài trước, mình có dịch Scrum Artifact là “kết quả được lưu trữ”, nay sửa lại thành “tạo tác” vì xét vê về mặt ý nghĩa, từ “tạo tác” sẽ chính xác và gọn hơn.

Các tạo tác của Scrum đại diện cho công việc hoặc giá trị. Chúng được thiết kế để tối đa hóa tính minh bạch của thông tin quan trọng. Vì vậy, tất cả mọi người kiểm tra chúng đều có cơ sở như nhau để thích ứng. Mỗi tạo tác chứa một cam kết đảm bảo cung cấp thông tin nâng cao tính minh bạch và tập trung vào đó có thể đo lường tiến độ:

● Đối với Product Backlog, đó là Mục tiêu của Sản phẩm.
● Đối với Sprint Backlog, đó là Mục tiêu Sprint.
● Đối với Phần tăng thêm, đó là Định nghĩa Hoàn thành.

Nguyên văn:

● For the Product Backlog it is the Product Goal. ● For the Sprint Backlog it is the Sprint Goal. ● For the Increment it is the Definition of Done.

Những cam kết này tồn tại để củng cố chủ nghĩa kinh nghiệm và các giá trị Scrum cho Nhóm Scrum và các bên liên quan của họ.

Vậy là chúng ta đã đi qua bài về quá trình của 1 Sprint. Nếu là 1 người có tham gia lên kế hoạch hoạch cho Sprint, hẳn bạn đã từng gặp các khái niệm trong bài này rồi. Hi vọng bài viết có thể giúp bạn hiểu rõ chi tiết hơn. Hẹn gặp lại các bạn trong các bài sau nhé.