0

Event #7: Tóm lược

 

Hanoi Scrum xin tóm lược lại nội dung buổi tọa đàm như sau:

 

1. Vấn đề đầu tiên được đưa ra trong buổi thảo luận này là “Họp Scrum Hằng ngày” (Daily Scrum). Một thành viên đưa ra vấn đề cụ thể của công ty mình, đó là Product Owner ở Châu Âu, lệch xa về múi giờ làm việc với Việt Nam, PO thường không thể tham dự buổi Họp Scrum Hằng ngày của Nhóm, do đó vào mỗi buổi chiều Scrum Master lại phải làm việc trực tuyến với PO để thông báo tình trạng công việc. Câu hỏi mà thành viên này đưa ra là: Trong trường hợp như vậy thì có phải là nhóm của anh đang thực hiện hai buổi Họp Scrum Hằng ngày hay không?

Mọi người tham gia buổi thảo luận đều đi đến thống nhất đó là PO không nhất thiết phải có mặt trong buổi Họp Scrum Hằng ngày, Nhóm sẽ làm việc với PO khi họ thực sự cần sự trợ giúp từ anh ta. Họp Scrum Hằng ngày là buổi họp nội bộ của Nhóm, việc PO có hay không tham dự buổi họp không phải là vấn đề.

Cùng với vấn đề nêu trên, một số thành viên tham dự cũng đưa ra những gợi ý về thời điểm hợp lý trong ngày để tiến hành Họp Scrum Hẳng ngày. Thời điểm được cho là đẹp đó là đầu ngày làm việc, thường là 8h00 -9h00 sáng.

 

2. Vấn đề thứ hai được đưa ra bàn thảo luận đó là “Ước tính” (Estimate). Một số điểm đáng lưu ý xung quanh vấn đề này:

  • Ước tính của Nhóm sẽ tốt dần qua từng Sprint
  • Nếu do ước tính không chính xác dẫn tới kết thúc Sprint mà vẫn còn những hạng mục công việc chưa giải quyết thì vẫn phải đảm bảo khung thời gian của Sprint. Các công việc chưa được giải quyết có thể được đẩy sang Sprint tiếp theo. Tuy nhiên Sprint sẽ được đánh giá thành công hay thất bại dựa vào việc có đạt được Mục tiêu Sprint (Sprint Goal) hay không?
  • Sprint chưa kết thúc nhưng không còn hạng mục công việc nào phải triển khai, vấn đề là do đâu?
    • Nhóm quá cầu toàn trong việc ước tính?
    • PO quá thoải mái?

Một số ý kiến đưa ra để hạn chế tình huống trên đó là Nhóm nên căn cứ vào số điểm (Story Point) mà nhóm hoàn thành được ở Sprint trước.

  • Một thành viên đưa ra việc không thống nhất xảy ra trong Nhóm của mình khi tiến hành ước tính. Giải pháp được đưa ra như sau:
    • Yêu cầu những thành viên có ước tính khác biệt phải giải thích với các thành viên khác.
    • Tham vấn ý kiến của chuyên gia về lĩnh vực đó.
    • Quyết định theo số đông.
    • Trong trường hợp đặc biệt, có thể quyết định theo ý kiến cá biệt của thành viên đó và để anh ta thực thi hạng mục đó theo ước tính của mình. Về ý kiến này còn có nhiều bàn luận về tính hiệu quả của nó?

 

3. Vấn đề cũng thu hút được sự quan tâm của các thành viên tham dự đó là về “Chất lượng của sản phẩm”. Các ý kiến đưa ra để bàn luận về chất lượng:

  • Mỗi ngày, Nhóm dành một khoảng thời gian (thường là cuối ngày) để tập trung xem xét, rà soát các công việc đã triển khai trong ngày. Sau đó cùng nhau giải quyết nếu phát hiện ra các vấn đề trong các công việc đã triển khai. Tuy nhiên, nhiều người tham gia không đồng ý với hành động này vì có thể việc làm tập trung như vậy sẽ tốn kém tài nguyên (thời gian, công sức).
  • Để đảm bảo chất lượng sản phẩm, một vài thành viên khuyến cáo nên áp dụng một số kỹ thuật như: Lập trình cặp (pair programming), làm bản mẫu (prototype), Phát triển Hướng-Kiểm-thử (TDD) hay Tích hợp Liên tục.
  • Vài thành viên còn gợi ý việc đưa thêm Tester chuyên nghiệp vào tham gia một số quy trình. Tuy nhiên ý kiến này cũng gặp phải một số phản hồi trái chiều, do việc thực hiện nó có thể mất đi tính “liên chức năng” của Nhóm.

 

4. Bug gặp phải trong Sprint là vấn đề lớn thứ tư được đưa ra. Một câu hỏi được đặt ra “Trong một Sprint, Nhóm sẽ xử lý như thế nào nếu gặp một bug rất khó giải quyết?”. Các ý kiến đưa ra như sau:

  • Nếu bug đó không ảnh hưởng tới Mục tiêu Sprint, thì có thể cô lập nó và chuyển qua danh sách các trở ngại. Nhóm cần tập trung vào các hạng mục hướng tới Mục tiêu Sprint.
  • Nếu bug đó trực tiếp quyết định sự thành bại của Sprint, Nhóm cần phải giải quyết nó kể cả việc tập trung giải quyết có thể dẫn tới Nhóm không hoàn thành hết các hạng mục công việc đề ra cho Sprint này.
  • Một số còn đưa ra khuyến nghị đó là nên tham vấn PO?

 

5. Điều hành công việc trong Nhóm được một thành viên đưa ra bàn thảo khi nhóm của anh xuất hiện tình trạng “người làm chưa hết việc, người ngồi chơi”. Thành viên này đưa ra tình huống đã gặp trong Nhóm của mình: “Một thành viên nhận công việc A, anh ta triển khai công việc xong trước thời gian ước tính, sau đó ngồi chơi mặc dù các thành viên khác vẫn đang bù đầu với công việc của họ”. Mọi người đưa ra nhiều gợi ý giải quyết cho tình huống này:

  • Scrum Master đến và gợi ý anh ta chọn một hạng mục nào đó chưa được triển khai trên Sprint Backlog.
  • Scrum Master nhờ anh ta trợ giúp thành viên khác bằng cách pair-programming
  • Trong một số trường hợp hãn hữu, Scrum Master cần làm theo cách “truyền thống” đó là gán cho anh ta một công việc
  • Một vài thành viên còn cho rằng cần phải xem xét tính sẵn sàng của anh này với Scrum?

 

6. Nội dung khép lại buổi thảo luận “Giải quyết thế nào khi sản phẩm phình to hơn so với hợp đồng ban đầu với khách hàng?”. Xét về mặt cơ bản, đây không phải là vấn đề của Nhóm Scrum, do đó cũng ít ý kiến đưa ra để giải quyết vấn đề này.

 

Xin cảm ơn sự tham gia và đóng góp nhiệt tình của các thành viên.