Scrum cho người mới bắt đầu - Phần cuối: Các sự kiện trong Scrum

Trước tiên, ở phần này mình sẽ dẫn lại liên kết của 3 phần trước để cho mọi người tiện theo dõi nhé :

• Scrum cho người mới bắt đầu - Phần 1: Tổng quan về Agile
• Scrum cho người mới bắt đầu - Phần 2: Scrum cơ bản
• Scrum cho người mới bắt đầu - Phần 3: Nhóm scrum

Oki, ở phần này nội dung chúng ta sẽ đi là các sự kiện trong Scrum. Chúng ta sẽ cùng nhau tìm hiểu về các nội dung như sau:

• Sprint
• Lập kế hoạch Sprint
• Scrum Daily
• Tổng kết sprint
• Cải tiến sprint

Các sự kiện trong Scrum hình thành theo một thứ tự lặp đi lặp lại các công việc nhằm xây dựng một thói quen làm việc hiệu quả. Mỗi sự kiện Scrum là cơ hội để cộng tác nhóm. Các sự kiện này đều có giới hạn thời gian tối đa (time boxed). Điều này đảm bảo thời lượng vừa đủ để tránh láng phí thời gian không cần thiết cho sự kiện. Hãy nhìn vảo bảng sơ lược các sự kiện trước khi đi sâu vào nó nhé. bảng

Sprint

Sprint là gì ? Là trái tim của Scrum. Sự kiện này có time box không vượt quá 1 tháng. Thông thường thì một Sprint có thể kéo dài từ 1 tuần tới 2 tuần. Các nhóm phải quyết định độ dài ổn định cho nhóm của mình dựa trên điều kiện thực tế. Các phần tăng trưởng của sản phẩm có thể phát hành được sản xuất gói gọn trong khung thời gian này. Trong suốt quá trình phát triển sản phẩm, Sprint được khuyến nghị giữ khung thời gian cố định. Một Sprint mới bắt đầu ngay khi một Sprint kết thức. Một sprint sẽ chứa các sự kiện còn lại của scrum như lập kế hoạch sprint, daily meating, tổng kết, cải tiến sprint. Khi một sprint đã bắt đầu, chúng ta cần lưu ý những điều sau:

• Không cho phép bất kì sự thay đổi nào ảnh hưởng tới mục tiêu của Sprint
• Thành phần Nhóm phát triển được giữ nguyên.
• Mục tiêu chất lượng không được cắt giảm.

Tuy vậy, sprint có thể bị huỷ khi kết thúc khung thời gian. Chỉ có PO mới đủ thầm quyền kết thúc Sprint. Một sprint có thể bị huỷ nếu mục tiêu của sprint không còn phù hợp nữa. Điều này xảy ra khi công ty chuyển hướng kinh doanh hoặc khi tình thế công nghệ có sự thay đổi. Nhìn chung, Sprint có thể bị huỷ nếu nó không còn mang lại điều gì có ích. Thế nhưng, do thời gian mỗi Sprint tương đối ngắn, nên việc huỷ một Sprint không mất mấy khi xảy ra. Khi sprint bị huỷ, các phầm sản phẩm đã hoàn chỉnh được xem xét lại. Các hạng mục trong 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. Việc huỷ sprint sẽ gây lãng phí tài nguyên, do mọi người phát mất thời gian công sức lên kết hoạch cho sprint mới. Việc huỷ đó đôi khi còn gây tâm lý cho Nhóm phát triển ít nhiều nữa. Thực tế thì mình đã được trải nghiệm việc huỷ sprint, tất cả công việc dừng lại và đem đưa lại về backlog. Cả tuần của sprint đó gần như cả team không làm gì mà chờ đợi kế hoạch được lên, rất là chán luôn ._.

Lập kế hoạch sprint

Khi một sprint bắt đầu, thì buổi Planing Meeting sẽ được thực hiện để xác định mục tiêu và chọn ra các task cần làm. Sự kiện này chia làm hai phần, phần một tất nhiên là chọn task và phần 2 là quyết định cách thức hoàn thành các task đó. Trong buổi planing meeting chúng ta sẽ lần lượt trả lời các câu hỏi sau:

• Mục tiêu của Sprint này là gì ?
• Sprint này phải chuyển giao cái gì ?
• Làm sao để đạt được điều đó

Toàn bộ nhóm Scrum bắt buộc phải tham gia phần thứ nhất của sự kiện. ở phần thứ 2 PO có thể vắng mặt nhưng phải luôn sẵn sàng hỗ trợ nhóm phát triển làm rõ các hạng mục khi cần thiết. Buổi planing meeting kéo dài thường 2 giờ đồng hồ. Thời gian dành cho 2 này được chia đều cho nhau, mỗi phần chiếm một nửa.

Phần 1: Làm gì trong Sprint này?

Đáp án của câu hỏi này chính là mục tiêu và danh sách các backlog được lựa chọn cho sprint. Phần này bắt đầu bằng việc PO trình bày mục tiêu momg muốn đạt được trong Sprint này. Sau đó PO làm rõ thêm các hạng mục ở phần trên của Product backlog để cả nhóm hiểu kỹ về các mục đó. Trong trường hợp, số lượng backlog ở sprint này so với sprint trước khác nhau, PO phải có trách nhiệm làm rõ. Căn cứ vào mục tiêu sprint và năng lực hiện có, nhóm phát triển sẽ lựa chọn những mục mà họ tin 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 - nói cách khách, họ bắt đầu với những hạng mục có độ ưu tiên cao do PO sắp xếp. Đây là cách làm chủ chốt trong Scrum: nhóm phát triển quyết định có bao nhiêu hạng mục sẽ được hoàn thành, thay vì được giao bởi PO. Điều này sẽ giúp nhóm phát triển đưa racacs dự báo tin cậy hơn do họ làm việc đó căn cứ vào những phân tích và lập kế hoạch của chính bản thân họ.

Để quyết định những hạng mục nào của Product Backlog sẽ triển khai trong Sprint này. Nhóm phát triển xem xét tốc độ trung bình của mình trong các sprint trước kết hợp với những yếu tố bất ngờ ở sprint này để tính đưa ra số lượng backlog cho sprint này. Ví dụ: Trong sprint trước, nhóm phát triển 7 người đã hoàn thành 80 point. Mà trong sprint này có người xin nghỉ phép 3 ngày. Vậy khả năng của nhóm không thể đạt được 80 point như trước. Do đó chỉ lựa chọn số lượng hạng mục đủ làm với tổng point là nhỏ hơn 80.

Ở đây phần trên chúng ta có nói đến việc tốc độ của sprint (velocity). Tốc độ đó được tính bằng số lượng đơn vị được hoàn thành trong mỗi Sprint. Nếu bạn dùng đơn vị là point, thì tốc độ chính là số điểm mà nhóm hoàn thành sau mỗi Sprint. Qua thời gian, tốc độ của nhóm có thể tương đối ổn định. Đó là tiền đề quan trọng có thể phỏng đoán được khối lượng công việc của nhóm trong mỗi Sprint.

Nếu nhóm phát triển 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 họ cần thảo luận với PO. Điều này thường xảy ra khi có sự phụ thuộc giữa các hạng mục hoặc nhóm cảm thấy mục đó có độ ưu tiên thấp nhưng phù hợp để phát triển cùng với các mục khác đã lựa chọn. Kết thúc phần 1, nhóm phát triển và PO thống nhất lại mục tiêu và danh sách backlog . Mục tiêu của 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. Mục tiêu của sprint đóng vai trò định hướng nhóm Phát triển trong suốt quá trình diễn ra Sprint và đồng thời giúp nhóm đưa ra được những quyết định hợp lý nhằm đạt được mục tiêu này. Một ví dụ về Mục tiêu Sprint là :"Xây dựng chức năng mua hàng bao gồm: Xem danh sách sản phẩm, thêm sản phẩm vào giỏ hàng, xem giỏ hàng, loại bỏ sản phẩm khỏi gior hàng, hiển thị thanh toán".

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

Phần 2 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 công việc đã chọn? Kết quả của phần này đó là Sprint Backlog - tức là bằng công việc được Nhóm phát triển sử dụng trong suốt sprint, bao gồm các task trong Backlog đã lựa chọn và danh sách công việc tương tứng với từng hạng mục đó. Nhóm phát triển 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ể. Các công việc này phải đảm bảo đủ nhỏ để hoàn thành trong vài giờ. Mộ số loại công việc thường được thấy là: design mockup, viết test, nghiên cứu kĩ thuật, triển khai tính năng v.v...Tất cả các công việc này đều phải được nhóm ước lược thời gian để hoàn thành. Thường được tính qua đơn vị point và được quyết định qua Planing Poker( một loại bài để quyết định số point cho một task). Những point này sẽ được cập nhập trong Sprint Backlog đồng thời cũng được sử dụng để tạo biểu độ Sprint Burndown nhằm 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ập đồng thời Sprint Backlog và biểu đồ với các giá trị mới. Nếu nhóm thấy rằng lược công việc quá nhiêu hay quá ít so với khả năng của nhóm họ có thể trao đổi với PO để loại bỏ bới các hạng mục.

Daily Scum

Sau khi một sprint bắt đầu thì cũng có một sự kiện bắt đầu theo đó là daily scrum. Đây là sự kiện quan trọng diễn ra hàng ngày trong suốt quá trình phát triển. Thời lượng là 15p cho mỗi buổi nhằm mục đích trao đổi tiến độ công việc giữa các thành viên trong nhóm, lên kết hoạch cho công việc trong ngày hôm nay. Nó còn có một tên gọi khác quen thuộc hơn đó là daily meeting. Trong buổi này mỗi thành viên sẽ trả lời 3 câu hỏi:

• Tôi đã làm được gì vào hôm qua ?
• Tôi sẽ làm gì trong hôm nay ?
• Tôi đang gặp những khó khăn gì ?

Để đảm bảo không "cháy" time box mỗi thành viên nên chỉ trả lời 3 câu hỏi trên và không lan man thảo luận sâu khi phát hiện ra vấn đề nào đó. Và Daily meeting khuyến nghị người tham gia đứng thay vì ngồi để tăng sự tập trung.

Tổng kết Sprint

Buổi tổng kết sprint sẽ được tiến hành khi thời gian triển khai sprint đã hết. Đây là hoạt động thanh tra và thích nghi đối với sản phẩm đang được xây dựng. Kết thúc buổi này, lộ trình sản phẩm và Product Backlog có thể được điều chỉnh để phù hợp với tình hình phát triển. Tham sự buổi này gôm có nhóm phát triển, PO, SM. Ngoài ra PO có thể mời thêm khách hàng để có thể đưa đánh giá. Tất cả những người tham dự đều hoàn toàn tự do trong việc đặt câu hỏi và đong góp. Khung thời gian cho sự kiện này thường là 1 giờ - 2 giờ. Nội dung trong buổi này là nhóm phát triển và PO trao đổi với nhau để tìm hiểu về tình hình và ghi nhận các khuyến nhị của nhau. Đây là cơ hội để PO lắm được sản phẩm. Còn với nhóm phát triển đây là cơ hội để tìm hiểu và nắm tình hình của PO và thị trường. Nội dung củ tổng kết sprint sẽ gồm:

• PO trình bày mục tiêu Sprint
• Nhóm phát triển trình bày kết quả đã hoàn thành
• Trực tiếp sử dụng sản phẩm và đưa đóng góp.

Ở trong buổi này, chúng ta chú ý không trình bày những tính năng chưa hoàn thành. Những phản hổi nhận được có thể được đánh giá lại độ ưu tiên cho các backlog. Tổng kết không hoàn toàn chỉ là demo sản phẩm, mà demo sản phẩm chỉ là một nội dung trong buổi này. Nếu tập chung cho việc demo sẽ bỏ qua đi những nội dung quan trọng khác đến việc thảo luận và cộng tác giữa các thành viên tham gia. Từ đó gây hiểu nhầm và thực hiên sai mục tiêu thực sự của buổi tổng kết.

Và sau khi tiến hành tổng kết xong, chúng ta sẽ có buổi cải tiến sprint. Mục đích của sự kiện này là thanh tra và thi thích quy trình làm việc. Nói cách khác là tìm cách để sprint sau tốt hơn. Nhóm phát triển và SM bắt buộc phải tham gia buổi này. PO có thể có, có thể không. Thời gian đối đa cho buổi này là 2 tiếng. Ở buổi này, cần có một người đứng ra làm vai trò hỗ trợ và đó là SM. Hoạt động chính là:

• Liệt kê những điểm đã làm tốt
• Liệt kê những điểm đã làm chưa tốt
• Đưa ra một vài hành động cải thiện
• Kế hoạch cải thiện cho sprint sau Có rất nhiều kĩ thuật có thể dùng cho buổi này nhưng đơn giản và phổ biến nhất là Glad-Sad-Mad. Glad-Sad-Mad là một kĩ thuật để thực hiện buổi cải tiến dựa trên việc phân loại các ý kiến của thành viên thành 3 nhóm: Glad (vui) - Sad( buồn) - Mad( tức giận). Những hạng mục nào mà thành viên cảm thấy hài lòng thì sẽ phân loại vào Glab. Những task họ cảm thấy chưa hài lòng và có thể cải tiến được thì đưa vào mục Sad. Những hạng mục nào gây cản trở nghiêm trọng và mình móng muốn loại bỏ nó ngay thì đưa vào mục MaD. Cụ thể cách tiến thành nó như sau:

1. Chuẩn bị

• Để bắt đầu cần chuẩn bị một tấm bảng đủ lớn được chia thành 3 cột.
• Những mẩu giấy nhớ và bút

1. Thu nhập dữ liệu Sm yêu cầu thành viên ghi tất cả những quan sát của mình vào mảnh giấy nhớ. Mỗi ý kiên trên từng mảnh riêng biệt, sau đó dán lên các cột tương ứng. Hoạt động này cần sử dụng từ 10- 15p
2. Tổng hợp thông tin Người hỗ trợ gom các ý kiến trùng nhau lại thành một hoặc loại bỏ, sau đó , các thành viên sẽ bỏ phiếu để lựa chọn ra những hạng mục mà mình muốn thảo luận. Cách phổ biến nhất là bỏ phiếu chấm, tức là mỗi thành viên lựa chọn tối đa 3 hạng mục bằng cách ghi một dấu châm vào tờ giấy của mình. Người hỗ trợ sẽ sắp xếp lại trật tư các tờ giấy dựa trên kết quả dấu chấm đó.
3. Thảo luận và đưa ra hành động cải tiến Sau đó, cả nhóm sẽ lần lượt thảo luận từng hạng mục cho đến khi không còn hạng mục nào nữa, hoặc đã hết thời gian đóng khung. Việc thảo luận nên tập trung vào việc đưa ra hành động cải tiển trong thời gian tới.

Ở bài viết này, chúng ta đã cùng đi tìm hiểu về các sự kiện trong Scum cũng như có thể áp dụng cho những dự án nhỏ hiện tại. Ở mức beginner thì mình nghĩ 4 bài viết của mình đã là đủ. Tuy rằng nội dung có hơi khô khan, nhưng đưa cho mọi người các nhìn theo mình là chuẩn về Scrum. Và mình sẽ dừng chuỗi bài viết đó tại đây, để chuyển sang những chủ đề khác vào lần sau. Cảm ơn mọi người đã đón nhận 4 bài viết vừa qua.