Bảng nhiệm vụ Sprint là gì

---

Bảng nhiệm vụ Sprint là gì?

Hộp nhiệm vụ Sprint là một khoảng thời gian cố định. Mỗi sprint có ngày bắt đầu và ngày kết thúc, trong đó một tập hợp các câu chuyện người dùng đã chọn phải được hoàn thành và xác nhận. Hình ảnh dưới đây cho bạn thấy các yếu tố chính của một sprint, bao gồm một tập hợp các câu chuyện người dùng, các thành viên Scrum tham gia, phân công công việc, thời lượng và ngày kết thúc (góc trên bên phải).

Vào đầu mỗi sprint, người sở hữu sản phẩm, các bên liên quan và đội phát triển họp lại để ưu tiên và sau đó chọn các câu chuyện người dùng cần hoàn thành trong sprint. Vì các bên khác nhau có những sở thích, cân nhắc và lo lắng khác nhau về dự án và lịch trình dự án, mục đích của cuộc họp là tạo cơ hội cho các thành viên tham gia lắng nghe và thấu hiểu quan điểm của nhau, từ đó đưa ra một tập hợp các câu chuyện người dùng được tất cả các bên đồng thuận.

Thời lượng của Sprint

Giao hàng nhanh chóng các công việc chất lượng là một trong những lý do khiến các đội phần mềm muốn áp dụng các phương pháp luận phần mềm linh hoạt. Do đó, mặc dù không có lựa chọn phù hợp với mọi trường hợp cho thời lượng sprint, nhưng thường được đồng thuận rằng thời lượng nên càng ngắn càng tốt. Nhưng ngắn đến mức nào là hợp lý?

Mặc dù thời lượng sprint dài không được ưa chuộng, nhưng thời lượng sprint quá ngắn một cách không hợp lý có thể làm giảm động lực của đội phát triển trong việc hoàn thành các công việc quan trọng, hoặc thậm chí dẫn đến chất lượng sản phẩm giao nộp kém.

Do đó, việc lựa chọn thời lượng sprint là kết quả của cuộc thảo luận giữa toàn đội – người sở hữu sản phẩm, người điều phối Scrum và các thành viên Scrum như các nhà thiết kế cơ sở dữ liệu, lập trình viên, nhà thiết kế UX, người kiểm thử, nhà phân tích, v.v. Nhưng cuối cùng, ai đó phải đưa ra quyết định. Vào thời điểm đó, người điều phối Scrum thường là người sẽ đưa ra câu trả lời.

Theo truyền thống, một sprint kéo dài từ ba tuần đến một tháng, nhưng hiện nay ngày càng nhiều đội đã thành công với các sprint hai tuần. Dù sao đi nữa, vẫn chưa có lựa chọn cố định nào cho thời lượng sprint. Một người điều phối Scrum giỏi cần có kỹ năng hợp tác và hỗ trợ trong việc xác định thời lượng sprint, nhằm đảm bảo công việc được hoàn thành như mong đợi. Dưới đây là một số yếu tố mà người điều phối Scrum có thể cân nhắc:

1. Lịch trình dự án đã được thống nhất
2. Sự sẵn sàng của khách hàng/đối tác/người sở hữu sản phẩm (người có thể làm rõ những thắc mắc tiềm ẩn)
3. Văn hóa làm việc của khách hàng
4. Năng lực của đội Scrum
5. Kinh nghiệm Scrum

Một khi đội đã đạt được sự đồng thuận, tất cả các sprint trong tương lai sẽ tuân theo cùng một thời lượng sprint mà không thay đổi thường xuyên từ sprint này sang sprint khác. Tuy nhiên, việc đội Scrum thường xuyên đánh giá hiệu quả của sprint và tìm ra thời lượng sprint tối ưu phù hợp nhất với tất cả mọi người là một thói quen tốt.

Xác nhận các công việc (câu chuyện người dùng) trong Sprint

Các hoạt động phát triển được xây dựng xung quanh các câu chuyện người dùng sau khi sprint bắt đầu, và ngày càng nhiều câu chuyện người dùng được triển khai khi sprint tiến triển. Tuy nhiên, việc triển khai hoàn chỉnh một câu chuyện người dùng không phải là kết thúc của câu chuyện. Vẫn còn một bước quan trọng cần đi qua – xác nhận.

Để xác nhận một câu chuyện người dùng là thử nghiệm tính năng đã triển khai và quyết định xem tính năng đó có được triển khai như mong đợi hay không. Việc đánh giá phải dựa hoàn toàn vào các tiêu chí đã được xác định khi chi tiết hóa câu chuyện người dùng, được viết dưới dạng các mục xác nhận. Trong quá trình xác nhận, người sở hữu sản phẩm sẽ được cung cấp môi trường kiểm thử hoặc thiết bị để kiểm thử công việc đã triển khai. Người sở hữu sản phẩm sẽ lần lượt đi qua từng mục xác nhận được ghi trên câu chuyện người dùng. Nếu tất cả các mục đều được xác nhận là hoàn thành, thì câu chuyện người dùng được coi là đã được xác nhận. Nếu bất kỳ mục nào được phát hiện chưa hoàn thành hoặc không hoạt động như mong đợi, người sở hữu sản phẩm sẽ yêu cầu đội phát triển sửa chữa. Quy trình sửa chữa và xác nhận sẽ lặp lại cho đến khi câu chuyện người dùng được xác nhận hoàn toàn.

Khi nào cần xác nhận?

Sprint, và thực tế là Agile, là một quy trình giao hàng liên tục. Thay vì xác nhận các câu chuyện người dùng vào cuối sprint, việc xác nhận nên được thực hiện ngay sau khi hoàn thành mỗi câu chuyện người dùng. Tuy nhiên, nếu người sở hữu sản phẩm không thể tham gia vào việc xác nhận liên tục, bạn có thể tổ chức các cuộc họp hàng tuần kéo dài từ 1 đến 2 giờ. Trong cuộc họp, người sở hữu sản phẩm sẽ làm việc cùng đội để xác nhận các câu chuyện người dùng đã hoàn thành. Cuộc họp cũng bao gồm một phiên thảo luận nhằm làm rõ những thắc mắc phát sinh khi triển khai các câu chuyện người dùng khác trong sprint.

Việc xác nhận không tương đương với kiểm thử

Như đã nói, mục đích của việc xác nhận là đảm bảo câu chuyện người dùng được triển khai đúng cách. Việc đánh giá dựa trên các mục đã được xác định là mục xác nhận trong quá trình chi tiết hóa câu chuyện người dùng, không nhiều hơn và không ít hơn. Phạm vi kiểm tra là quá nhỏ để đảm bảo tính năng sẵn sàng sử dụng trong môi trường sản xuất. Vậy khi nào cần thực hiện một ‘kiểm thử thực sự’?

Các đội khác nhau có những cách thức khác nhau trong việc kiểm thử phần mềm. Một số đội ưa chuộng kiểm thử theo từng sprint, bao gồm việc thực hiện các loại kiểm thử như kiểm thử tích hợp và kiểm thử hồi quy vào cuối mỗi sprint. Một số đội khác ưa chuộng thiết lập một sprint ổn định, như tên gọi của nó, để kiểm thử và sửa lỗi. Không có hoạt động phát triển mới nào sẽ được thực hiện trong sprint đó.

Dù bạn chọn phương pháp nào, hãy luôn nhớ rằng lựa chọn này không phải là lựa chọn của một người nào đó, mà là lựa chọn của tất cả mọi người.

Visual Paradigm cung cấp tất cả các công cụ bạn cần trong phát triển phần mềm linh hoạt, bao gồm công cụ sơ đồ Use Case UML, (agile) truyện người dùng, sprint, bảng truyện và bản phác thảo cho thiết kế UX, công cụ quản lý nhiệm vụ, v.v.