Các sự kiện trong Scrum - Secomus Technology
November 16, 2020 secomus_admin

Các sự kiện trong Scrum

Các sự kiện Scrum bao gồm:

  • Sprint
  • Lập kế hoạch Sprint
  • Scrum hằng ngày
  • Sơ kết Sprint
  • Cải tiến Sprint

1. Sprint

Sprint là phân đoạn mà mọi việc làm của nhóm Scrum được diễn ra, cụ thể như: lập kế hoạch, thực thi, cộng tác, tháo gỡ khó khăn, tổng kết, cải tiến đều được diễn ra trong một khung thời gian có độ dài xác định để hoàn thành một mục tiêu cụ thể là chuyển giao giá trị ở cuối chu kỳ.

Cơ chế thu nhỏ phạm vi công việc trong vòng một Sprint giúp Nhóm Scrum có khả năng liên tục chuyển giao giá trị, nhận về các phản hồi từ phía khách hàng (hoặc người dùng cuối) để điều chỉnh hướng đi cho thời gian tiếp theo. 

Mỗi Sprint có thể được coi là một dự án nhỏ với độ dài từ 1 – 4 tuần, phụ thuộc vào bối cảnh, đặc trưng của dự án và yêu cầu về thông tin phản hồi. Cụ thể, một dự án có nhiều biến động thì có xu hướng có Sprint ngắn hơn. Ngược lại, một dự án thuộc dạng “khó đoán” và không bị sức ép về tiến độ phát hành sản phẩm thì có thể lựa chọn độ dài lớn hơn.

Sprint càng ngắn thì áp lực thường lớn và việc quản lý thông qua các tương tác trong các sự kiện thường chiếm tỷ lệ lớn hơn.

Mỗi Sprint có một mục tiêu rõ ràng và phải xây dựng trong Sprint, việc có trước bản thiết kế và kế hoạch linh hoạt sẽ điều hướng cho quá trình xây dựng đó.

Về mặt nội bộ, việc lặp đi lặp lại một kỉ luật gồm nhiều việc quan trọng dưới dạng một tập hợp các sự kiện bắt buộc có cấu trúc rõ ràng giúp nhóm xây dựng, duy trì và cải tiến khả năng cộng tác nội bộ và với khách hàng, để ngày càng gia tăng sự hiệu quả.

Hủy một Sprint

Một Sprint có thể bị hủy nếu Mục tiêu Sprint không còn phù hợp nữa, nói cách khác là nó không mang lại giá trị, thường xảy ra trong trường hợp công ty chuyển hướng kinh doanh hoặc tình thế công nghệ có sự thay đổi. 

Sprint có thể bị hủy trước khi kết thúc khung thời gian. Chỉ có Product Owner mới đủ thẩm quyền dừng Sprint.

Thế nhưng, do thời gian mỗi Sprint tương đối ngắn. Việc hủy Sprint sẽ gây lãng phí tài nguyên, do mọi người phải mất thời gian, công sức để lên kế hoạch cho một Sprint Mới. Việc hủy Sprint thường gây tổn hại nhất định cho Development Team và rất ít khi xảy ra.

Khi Sprint bị hủy, các phần sản phẩm đã hoàn chỉnh được xem xét lại. Nếu phần nào đó của công việc có thể chuyển giao được, thì Product Owner có thể chấp nhận chúng. Các hạng mục Product Backlog chưa hoàn tất sẽ được ước lượng lại và trả về Product Backlog để phát triển tiếp. Các phần việc đã thực hiện trên đó sẽ nhanh chóng hết tác dụng và phải thường xuyên được ước lượng lại. 

2. Lập kế hoạch Sprint 

Thời điểm: Bắt đầu Sprint.

Thời gian:  2 giờ tương ứng với 1 tuần làm việc của Sprint. Chẳng hạn, với Sprint 1 tháng  thì khung thời gian là khoảng 8h. Thời gian dành cho hai phần của sự kiện là bằng nhau.

Product Owner có thể vắng mặt nhưng phải luôn sẵn sàng hỗ trợ Development Team để làm rõ các hạng mục khi cần thiết.

Lập kế hoạch Sprint chia làm hai phần:

Phần thứ nhất: Lựa chọn các công việc cần làm trong Sprint

Phần thứ hai: Quyết định cách thức hoàn thành toàn bộ công việc đã lựa chọn trước đó

Phần thứ nhất: Lựa chọn các công việc cần làm trong Sprint

Kết quả của việc lựa chọn các công việc cần làm trong Sprint là:

+ Mục tiêu Sprint:


Mục tiêu Sprint là một đoạn mô tả ngắn về kết quả kỳ vọng đạt được sau khi Sprint kết thúc, đóng vai trò định hướng Development Team trong suốt quá trình diễn ra Sprint và đồng thời giúp nhóm đưa ra những quyết định hợp lý nhằm đạt được mục tiêu này.  

+ Danh sách các hạng mục Product Backlog được lựa chọn để phát triển trong Sprint. 

Quá trình:

  • Product Owner trình bày mục tiêu mong muốn đạt được trong Sprint này. 
  • Product Owner làm rõ thêm các hạng mục ở phần trên của Product Backlog (những hạng mục có độ ưu tiên cao nhất) để cả nhóm hiểu kỹ về hơn các hạng mục này. Product Owner cần làm rõ số lượng hạng mục Product Backlog nhiều hơn số lượng mà Development Team có thể hoàn thành trong cho một Sprint (con số này dựa vào các Sprint trước đó hoặc dựa trên kinh nghiệm).
    Ví dụ, nếu ước lượng thấy nhóm có khả năng làm khoảng 5 hạng mục thì ít nhất cả nhóm phải hiểu rõ khoảng 8 hạng mục hoặc hơn thế. Việc đó giúp nhóm có đầy đủ thông tin để đưa ra các quyết định lựa chọn một cách chính xác cho Sprint này. Thông thường, những hạng mục này đã được phân tích kỹ và làm rõ từ một vài Sprint trước thông qua việc làm mịn Product Backlog, do đó công việc trong phần này không tốn quá nhiều thời gian. 
  • Cả nhóm sẽ hợp tác để tìm hiểu công việc phải làm trong Sprint. 
  • Căn cứ vào Mục tiêu Sprint và năng lực hiện có, Development Team lựa chọn những hạng mục mà họ tin là có thể hoàn thành trong Sprint này, bắt đầu từ những hạng mục đứng đầu trong Product Backlog. Development Team sử dụng tốc độ sản xuất trung bình của mình trong quá khứ và khả năng của nhóm trong Sprint hiện tại để quyết định những hạng mục nào của Product Backlog sẽ triển khai trong Sprint này.
    Trường hợp Development Team cần thảo luận với Product Owner nếu muốn lựa chọn một vài hạng mục có độ ưu tiên thấp ở phía dưới của Product Backlog (thường xảy ra khi có sự phụ thuộc hoặc phù hợp với các hạng mục khách đã lựa chọn).
  • Kết thúc, Development Team và Product Owner thống nhất lại mục tiêu Sprint và danh sách các hạng mục sẽ chuyển giao trong Sprint này. 

Phần thứ hai: Làm sao để hoàn thành công việc đã chọn

Phần hai của buổi Lập kế hoạch Sprint  với mục đích trả lời cho câu hỏi: Làm sao để hoàn thành việc đã chọn? Kết quả của phần này đó là Sprint Backlog.

Sprint Backlog là bảng công việc được Development Team sử dụng trong suốt Sprint, bao gồm các hạng mục Product Backlog đã lựa chọn và danh sách công việc tương ứng với từng hạng mục Product Backlog đó.

Development Team bắt đầu thiết kế hệ thống và lên danh sách các công việc cần làm. Đối với mỗi hạng mục trong danh sách đã lựa chọn, nhóm sẽ tách thành các công việc cụ thể và ước lượng nỗ lực (bằng giờ hoặc point và được Development Team điều chỉnh thường xuyên trong quá trình triển khai) để hoàn thành từng công việc. Các công việc này thường đủ nhỏ để hoàn thành trong một ngày hoặc ít hơn.

Tổng nỗ lực cho tất cả các hạng mục trên Sprint Backlog được nhóm sử dụng để theo dõi tiến độ Sprint. Giá trị này được cập nhật ngay vào Sprint Backlog và đồng thời cũng được sử dụng để tạo biểu đồ Sprint Burndown nhằm vào theo dõi tiến độ Sprint. Sau mỗi ngày làm việc, các thành viên sẽ cập nhật đồng thời Sprint Backlog và biểu đồ Burndown với các giá trị mới.

Ví dụ: Burndown Chart trong Sprint 5 của team LAI AliExpress Review: Khối lượng công việc được hoàn thành nhiều hơn dự kiến ban đầu.

Trong trường lớp lượng công việc quá nhiều hoặc quá ít thì Development Team có thể trao đổi với Product Owner để loại bỏ bớt hoặc chọn thêm các hạng mục khác. Trong phần 2, Development Team có thể cần thêm sự hỗ trợ từ bên ngoài nhóm để phân tích, ước lượng công việc tốt hơn.

Lập kế hoạch dài hơi hơn 

Trong Scrum cơ chế lập kế hoạch theo Sprint quá ngắn, không đủ tốt cho việc hoạch định.

Việc lập kế hoạch có thể diễn ra ở nhiều cấp độ khác nhau. Lập kế hoạch Sprint dành cho Development Team, đây là một nét mới. 

Ngoài ra, các công tác lập kế hoạch dài hơi hơn, như: Lập kế hoạch Phát hành, Lập kế hoạch Danh mục Sản phẩm (Portfolio) hay Chiến lược sản phẩm vẫn cần được thực thi hiệu quả ở các cấp cao hơn trong tổ chức.

Công việc lập kế hoạch cho sản phẩm thường được giao cho Product Owner. Kế hoạch này sẽ phải dựa nhiều vào việc ước tính kích thước các hạng mục Product Backlog, tính toán tốc độ hoàn thành công việc của Development Team, cũng như xem xét các ưu tiên kinh doanh đối với sản phẩm đang phát triển. Khi công việc ước tính cho từng hạng mục đã được hoàn tất, nhóm căn cứ vào tốc độ của mình mà dự đoàn là đến khi nào thì có thể có được một bản phát hành có ý nghĩa.

Để cho kế hoạch không quá cứng nhắc, có thể Product Owner sẽ cần phân loại các tính năng Phải có, Nên có và Có thể có khi lựa chọn các tính năng sẽ hiện diện trong bản phát hành sắp tới. Tập hợp những phần Phải có để có thể tạo thành một bộ tính năng thuộc dạng MVP (Minimum Viable Product – sản phẩm hữu dụng tối thiểu) có thể chuyển giao giá trị cơ bản tới người dùng cuối.

Tốc độ ước tính là con số dự báo, và trong quá trình hướng đến mục tiêu phát hành, nhóm có thể gặp phải những vấn đề không tính trước. Vì thế , kế hoạch phát hành cũng phải được hiệu chỉnh thường xuyên sau mỗi Sprint. Biểu đồ Release Burndown theo dõi tiến độ đạt được mục tiêu phát hành qua các Sprint.

Việc hoạch định luôn bao gồm hai phần: Mục tiêuViệc cần làm . Một số nhóm Scrum có thể dùng phương pháp SMART để xác định mục tiêu phát hành , một số nhóm khác dùng phương pháp OKR để thiết lập mục tiêu. 

3. Scrum Hằng ngày

Scrum Hằng ngày diễn ra đều đặn hàng ngày, tại 1 địa điểm và khung thời gian cố định, là 1 buổi trao đổi ngắn không kéo dài quá 15 phút.

Mục đích giúp Development Team đồng bộ công việc và lập kế hoạch cho ngày làm việc tiếp theo. 

Vai trò của các thành viên trong Scrum Hằng ngày:

  • Các thành viên Development Team phải tham gia đầy đủ và trả lời 3 câu hỏi:

  1. Tôi đã làm được những gì từ buổi Scrum Hằng ngày trước cho tới bây giờ để giúp Nhóm phát triển đạt được Mục tiêu Sprint?
  2. Tôi sẽ làm gì từ bây giờ tới hôm sau để giúp Nhóm phát triển tiến tới mục tiêu Sprint?
  3. Tôi đang gặp những khó khăn gì cản trở cả nhóm đạt được Mục tiêu Sprint này?

  1. Đảm bảo điều kiện thuận lợi Development Team tiến hành sự kiện như: địa điểm, khung thời gian, đảm bảo sự phối hợp đồng bộ trong công việc thay vì sa đà vào các vấn đề khác.
  2. Quan sát trong suốt buổi họp để cảm nhận không khí và các vấn đề tiềm ẩn. Các vấn đề này sẽ được ghi lại và có thể quản lý trong Danh sách trở ngại và giải quyết dần.
  • Product Owner và một số người khác có thể tham dự nhưng không đóng bất cứ vai trò nào trong sự kiện này.

4. Sơ kết Sprint

Sơ kết Sprint là một hoạt động thanh trathích nghi đối với sản phẩm đang được xây dựng. Kết thúc Sơ kết, lộ trình sản phẩm và Product Backlog có thể được điều chỉnh phù hợp hơn với tình hình phát triển mới.

Thời điểm: Sau khi kết thúc triển khai Sprint.

Thời gian: 1 giờ tương ứng với 1 tuần làm việc của Sprint

Mục đích: Kiểm tra phần tăng trưởng đạt được trong Sprint vừa qua

Tất cả những người tham dự đều hoàn toàn tự do trong việc đưa ra các câu hỏi và đóng góp ý kiến của mình.Thành phần tham dự bao gồm:

  • Development Team
  • Product Owner
  • Scrum Master
  • Thành viên khác: Khách hàng, người dùng, các bên liên quan,…

Tại Sơ kết Sprint:

+ Development Team và Product Owner trao đổi với nhau để tìm hiểu về tình hình, ghi nhận các khuyến nghị của nhau.

+ Product Owner tìm hiểu và nắm tình hình của sản phẩm và của Development Team.

+ Development Team tìm hiểu và nắm tính hình của Product Owner và của thị trường.

Nội dung của Sơ kết Sprint:

  1. Product Owner trình bày Mục tiêu Sprint
  2. Nhóm Phát triển trình bày kết quả đã hoàn thành
  3. Trực tiếp sử dụng sản phẩm

* Lưu ý:

– Không trình bày những tính năng chưa “hoàn thành”.

– Các phản hồi được đưa ra – Product Backlog có thể được đánh giá lại độ ưu tiên.

– Product Owner nên sử dụng kỹ thuật kiểm thử chấp nhận để đánh giá các tính năng.

– Demo sản phẩm là một nội dung của buổi Sơ kết Sprint. Ngoài ra có một nội dung không kém phần quan trọng là thảo luận và cộng tác giữa các thành viên tham gia.

5. Cải tiến Sprint

Thời điểm: Cuối Sprint, ngay sau buổi sơ kết Sprint và trước phiên Lập kế hoạch Sprint tiếp theo.

Thời gian: 45 phút tương ứng với 1 tuần làm việc của Sprint. Chẳng hạn, với Sprint 2 tuần thì khung thời gian là khoảng 1 giờ 30 phút.

Mục đích (theo Tài liệu hướng dẫn Scrum):

  • Thanh tra Sprint vừa rồi đã diễn ra như thế nào trên phương diện con người, quan hệ, quy trình và công cụ.
  • Nhận diện trình tự và sắp xếp các thứ đã làm tốt và những thứ cần phải cải tiến.
  • Lập kế hoạch cải tiến cách làm việc của Nhóm Scrum.

Thành phần tham dự:

  • Development Team và Scrum Master bắt buộc phải tham gia.
  • Product Owner có thể tham gia hoặc không.
  • Những người được Scrum Master mời đến đóng góp ý kiến cho nhóm.

Scrum Master cố gắng hướng dẫn nhóm thực hiện đúng từng bước của nhóm trong hoạt động họp cải tiến, có được phương án cụ thể, và đưa ra một kế hoạch cải tiến thật SMART.

Cần có 1 người giữ vai trò hỗ trợ cho buổi Cải tiến Sprint, người này có thể là Scrum Master hoặc 1 người bên ngoài nhóm (cách khá phổ biến là trao đổi chéo giữa các Scrum Master).

Thực tiễn, các buổi Cải tiến Sprint nên được đặt vào một chu kỳ khép kín Plan – Do – Check – Act (Lập kế hoạch – Thực thi – Kiểm tra – Thích ứng) vốn là quy trình cải tiến liên tục Kaizen). Cụ thể, sau khi có được kế hoạch cải tiến, Nhóm Scrum cần đưa vào thực thi trong Sprint tiếp theo, sau đó theo dõi xem cải tiến đó có hiệu quả hay không, kiểm tra trong Sprint tới và thích ứng. Cho nên, một trong các trọng tâm của buổi họp cải tiến là phải kiểm tra lại xem kế hoạch cải tiến lần trước có hiệu quả không, và phải chỉnh sửa thế nào. Để thực hiện được việc này, Nhóm Scrum có thể duy trì cho mình một Bản ghi Cải tiến (Kaizen Kog) để theo dõi mức độ hiệu quả của từng cải tiến qua thời gian. Tài liệu này Scrum Master  nên duy trì, cập nhật thường xuyên và có thể đóng vai trò như là đầu vào cho các cải tiến mang tính hệ thống hơn và nhân rộng ra các nhóm khác.

Trong một tổ chức có hệ quản trị tri thức hiệu quả, các cải tiến này có thể được phân loại và chia sẻ rộng rãi (dưới dạng wiki, blog hoặc tin tức nội bộ) để lan truyền sáng kiến ở quy mô lớn hơn.

Hoạt động cải tiến liên tục đạt hiệu quả cao nhất khi trở thành thói quen của từng cá nhân và nhóm và trở thành văn hóa của tổ chức.

Các kĩ thuật cải tiến Sprint:

  • Glad – Sad – Mad (được sử dụng phổ biến nhất)
  • SpeedBoat
  • Start – Stop – Continue
  • 5whys
  • Lean Coffee
* Nguồn tham khảo: Cẩm nang Scrum