Loại bài về Scrum kì 3

Trong các bài trước chúng ta đã đến các khái niệm cần biết trước khi triển khai làm việc bằng Scrum.

Trong kì này hãy cùng tôi tìm hiểu về Scrum Events (Các sự kiện của Scrum) nhé.

Sprint là một tổ hợp các sự kiện khác. Mỗi sự kiện của Scrum là một cơ hội chính thức để nghiên cứu và tiếp thu các giá trị của Scrum. Những sự kiện này được thiết kế theo cách riêng để giúp ta đạt được sự minh bạch cần thiết. Không thực hiện bất kỳ sự kiện nào theo quy định dẫn đến mất cơ hội kiểm tra và thích ứng. Các sự kiện được dùng trong Scrum nhằm tạo ra thói quen và giảm đến tối thiểu nhu cầu cho những cuộc họp không được định nghĩa trong Scrum. Tối ưu nhất là tất cả các sự kiện được diễn ra cùng lúc và cùng chỗ để giảm độ phức tạp. Sprint là nhịp tim của Scrum nơi mà ý tưởng trở thành giá trị. Chúng là những sự kiện có chiều dài cố định trong vòng 1 tháng trở xuống để tạo ra sự liên tục. 1 Sprint mới bắt đầu ngay khi có sự kết luận của Sprint trước. Tất cả các công việc cần để đạt được Achieve Goal bao gồm Sprint Planning (Lên kế hoạch Sprint), Daily Scrums (Scrum thường nhật), Sprint Review (đánh giá Sprint), Sprint Retrospective (Nhìn lại Sprint), sẽ được tiến hành Sprints.

Bạn cần ghi nhớ chính đoạn sau:

Xuyên suốt Sprint : 
● Những thay đổi có thể gây hại cho Sprint Goal sẽ không được thực hiện
● Chất lượng ko giảm;
● Product Backlog được tinh chỉnh đúng theo yêu cầu
● Scope (lượng công việc) sẽ được làm rõ và có thể được đàm phán lại với Product Owner một khi phát hiện ra nhiều thông tin hơn.

Nguyên văn:

● No changes are made that would endanger the Sprint Goal; 
● Quality does not decrease;
● The Product Backlog is refined as needed; and, 
● Scope may be clarified and renegotiated with the Product Owner as more is learned.

Sprint giúp chúng ta dự đoán tốt hơn bằng cách đảm bảo sự điều tra và sự thích ứng của quá trình dành cho ít nhất một Product Goal một tháng. Khi giới hạn (horizon) của Sprint quá dài Sprint Goal có thể trở nên không hiệu quả và sự phức tạp cùng với rủi ro sẽ tăng lên. Các Sprint ngắn hơn có thể được dùng để tạo ra nhiều vòng học tập (learning cycle) và giới hạn nguy cơ về mặt giá thành + công sức (effort) trong một khung thời gian nhỏ hơn. Mỗi Sprint có thể xem như 1 dự án ngắn hạn. Có nhiều phương pháp khác nhau tồn tại để báo trước các quá trình, như burn-down (làm từ trên xuống), burn-ups (làm từ dưới lên), hay tích lũy dần (cumulative flow). Những cách làm này tuy rằng đã được chứng minh là có ích, vẫn kh6ong thể thay thế sự quan trọng của chủ nghĩa kinh nghiệm. Trong những môi trường phức tạp, người ta vẫn không thể biết trước được sẽ xảy ra cái gì.

Chỉ có những điều đã xảy ra mới có thể dùng được cho việc tiên liệu các quyết định. Một Sprint có thể bị hủy nếu Sprint Goal trở nên lỗi thời. Chỉ có Product Owner mới có quyền hạn để hủy Sprint.

Lời bàn: Khi lập kế hoạch trên Backlog/ Redmine hẳn bạn không còn lạ gì khái niệm 1 Sprint đúng không? Tùy theo đặc thù dự án, mà một Sprint có thể kéo dài một đến hai tuần. Sau khi học về khái niệm Sprint này, bạn hãy thử đánh giá với dự án mình một vài yếu tố sau:

1. Độ dài Sprint dự án đang dùng có hợp lý?
2. Việc triển khai Sprint đã đảm bảo đạt được Sprint Goal, cũng như tạo ra nhiều vòng học tập (learning cycle) cho dự án bạn hay chưa?

Chúc các bạn thành công với việc áp dụng mô hình Scrum vào dự án. Và đừng quên đón xem bài tiếp theo nhé.