Danh mục kiểm tra của Scrum Master

 
Công việc hàng ngày

  • Nhóm của bạn có ở trạng thái tốt không?
    • Mục tiêu rõ ràng (những kỳ vọng và quy định phải rõ ràng, và mục tiêu có thể đạt được, phù hợp với kĩ năng và khả năng của mỗi người).
    • Tập trung và có trọng điểm, tập trung cao độ vào một lĩnh vực nhất định cần được chú ý.
    • Không có cảm giác tự ti, đề cao hành động và nhận thức.
    • Phản hồi trực tiếp và ngay lập tức (nhanh chóng nhìn thấy các thành công và thất bại của một chuỗi hoạt động, nhờ thế có thể điều chỉnh hành vi nếu cần thiết).
    • Cân bằng giữa cấp độ khả năng và thử thách (hoạt động đưa ra không quá khó cũng không quá dễ).
    • Mỗi người đều có khả năng tự kiểm soát trong mỗi tình huống hay hoạt động.
    • Mỗi hoạt động đều hiển nhiên đem lại kết quả, vì thế không cần quá nhiều cố gắng trong hành động.
  • Các thành viên có thích nhau không, có thư giãn cùng nhau không, và có vui mừng trước thành công của những thành viên khác không?
  • Các thành viên nhóm có cùng nhau giữ cho mỗi người đều phải đạt được những tiêu chuẩn cao, và thúc đẩy mỗi người đều phát triển?
  • Có vấn đề hoặc cơ hội nào mà nhóm đang không thảo luận cùng nhau vì những vấn đề hoặc cơ hội đó có thể gây ra tình trạng quá khó chịu trong nhóm không?
  • Nhóm có tập trung liên tục vào các mục tiêu Sprint không? Có thể bạn nên thực hiện một bước kiểm tra giữa Sprint để có thể tái rà soát các tiêu chuẩn chấp thuận của các hạng mục trong Product Backlog đã cam kết hoàn thành trong Sprint hiện tại.
  • Bảng phân công nhiệm vụ của Sprint có phản ánh đúng những công việc mà nhóm đang thực sự làm không? Cần nhận thức rõ “vấn đề tiềm ẩn” của những công việc không được nêu ra và những nhiệm vụ có thể tốn hơn một ngày mới có thể hoàn thành. Những công việc không liên quan đến những cam kết trong Sprint sẽ là những trở ngại cho việc hoàn thành các cam kết đó.
  • Bảng phân công nhiệm vụ của nhóm bạn có cập nhật không?
  • Các thành viên nhóm có biết về các công cụ tự quản lí của nhóm không, các công cụ đó có tiện dụng không?
  • Những công cụ quản lí có được những người ngoài nhóm tôn trọng đúng mức không? Sự giám sát quá mức đối với các hoạt động thường nhật của những người bên ngoài nhóm có thể hủy hoại sự minh bạch và cơ chế tự quản lí trong nhóm.
  • Các thành viên nhóm có tự nguyện nhận nhiệm vụ không?
  • Sự cần thiết của việc hoàn trả nợ kĩ thuật, việc dần dần sẽ giúp cho việc lập trình trở nên dễ chịu hơn, đã được ghi nhận rõ ràng trong khái niệm hoàn thành chưa?
  • Các thành viên nhóm có đang cùng nhau chịu trách nhiệm về mọi khía cạnh của sản phẩm chung (kiểm thử, tài liệu cho người dùng, v.v.) mà không quan tâm đến chức danh của mỗi người không?

Công việc theo sprint

  • Product Backlog có được sắp xếp theo hiểu biết mới nhất của nhóm không?
    Các yêu cầu và mong muốn từ tất cả các bên liên quan có được ghi nhận trong Product Backlog không? Ghi nhớ: backlog là quan trọng.
  • Khối lượng của Product Backlog có thể quản lí được không? Để duy trì số lượng hạng mục trong giới hạn có thể quản lí được, hãy giữ những hạng mục chi tiết ở trên cùng, còn các hạng mục trừu tượng nói chung ở dưới. Sẽ phản tác dụng nếu chúng ta phân tích quá sâu vào những hạng mục ở phía dưới của Product Backlog. Những yêu cầu đặt ra sẽ thay đổi trong những cuộc trao đổi liên tục giữa sản phẩm đang phát triển và các bên liên quan
    hoặc khách hàng.
  • Có yêu cầu nào (đặc biệt là những yêu cầu ở phía trên cùng của Product Backlog) có thể được thể hiện tốt hơn bằng những user story độc lập, có thể thương lượng được, có thể đánh giá được, có thể ước lượng được, nhỏ, và có thể kiểm thử được?
  • Bạn đã giải thích cho Product Owner của bạn về nợ kĩ thuật và cách để tránh nó chưa?
  • Một trong những giải pháp có thể là thêm việc viết kiểm thử tự động và tái cấu trúc vào định nghĩa ‘hoàn thành” cho mỗi hạng mục.
  • Backlog có phải là một biểu đồ thông tin, mà các bên liên quan có thể lập tức nhận thấy được không?
  • Nếu bạn đang sử dụng một công cụ tự động trong quản lí backlog, mọi người có biết cách để sử dụng nó dễ dàng không? Các công cụ quản lí tự động cũng dẫn tới nguy cơ trở thành sự tắc nghẽn thông tin nếu thiếu đi sự truyền tải thông tin chủ động từ ScrumMaster.
  • Bạn có thể giúp truyền tải thông tin bằng các bản in cho mỗi người không?
  • Bạn có thể giúp truyền tải thông tin bằng cách tạo ra các biểu đồ to và rõ ràng không?
  • Bạn đã giúp Product Owner sắp xếp các hạng mục backlog vào các thời điểm phát hành thích hợp hoặc trong những nhóm ưu tiên chưa?
  • Có phải mỗi người trong nhóm đều nhận thức được liệu kế hoạch phát hành còn phù hợp với thực tế không? Bạn có thể thử cho mọi người xem biểu đồ tương quan sản phẩm phát hành với thời gian thực hiện sau khi các hạng mục đã được xác nhận “hoàn thành” trong mỗi cuộc họp Sơ kết Sprint. Biểu đồ thể hiện tỉ lệ các hạng mục Product Backlog đã được hoàn thành và những hạng mục mới được thêm vào để cho phép phát hiện sớm những biến động trong quy mô hoặc kế hoạch thực hiện.
  • Product Owner của bạn đã điều chỉnh kế hoạch phát hành sau buổi họp Sơ kết Sprint gần nhất chưa? Chỉ có số ít Product Owner đã bàn giao sản phẩm được kiểm thử đầy đủ đúng hạn sắp xếp lại kế hoạch phát hành mỗi Sprint. Điều này có thể sẽ khiến cho một vài sản phẩm cần được phát hành sau vì có những việc quan trọng hơn được phát hiện ra.
  • Bạn đã từng thử nhiều cách thức và địa điểm cho các buổi họp Cải tiến Sprint chưa?

Nguồn: hocvienagile