Một ngày mới lại bắt đầu, tôi tỉnh dậy trong căn nhà nhỏ cách xa Hà Nội. Một không gian tĩnh lặng của khu trung cư bao chùm, trong đầu chợt nghĩ về những ngày đầu bước chân vào công ty. Có một câu hỏi mà lúc ấy tôi tốn kha khá thời gian để tìm hiểu đó là SM là gì, SM làm công việc gì ?
Menu
SM là gì?
SM là viết tắt của Scrum Master, SM không phải là gì, mà là người có trách nhiệm đảm bảo cho Scrum team vận hành theo các giá trị của phương pháp Scrum và thực thi nó. Scrum Master được xem như người hướng dẫn team, giúp đội làm tốt nhất công việc của đội.
Scrum Master làm tất cả khả năng để giúp team hoạt động hiệu quả nhất có thể. Nó bao gồm việc xóa các rào cản, tổ chức tốt các sự kiện và làm các công việc khác, như làm việc với Product owner để đảm bảo product backlog được định hình tốt và sẵn sàng cho sprint kế tiếp.
Sau những một vài năm đúc kết kinh nghiệm tôi đã được thử sức tôi với role SM. Thông qua dự án, đội dự án của tôi đã nhìn ra được rất nhiều vấn đề và bản thân tôi cũng rút ra được những bài học đáng giá. Đây là một vài kinh nghiệm tôi muốn chia sẻ cùng với mọi người.
Cách xử lý khi đội bỏ qua quy trình.
Một trong những bài học rất là đắt giá mà đội tôi phải trải qua là đã bỏ qua quy trình của chính đội đề ra. Khi những anh em Developer quá bận bịu với công việc coding. Mọi người đã không để ý đến việc sắp xếp câu lệnh where trong câu truy vấn => index của table hoàn toàn vô dụng. Việc này dẫn đến việc khách hàng đã claim đội một cách rất đau đớn.
Đội đã phải kaizen và đưa ra cách thực hiện quy trình nghiêm ngặt hơn rất là nhiều . Nếu review không qua check list sẽ không được tạo pull request và phải có evident rõ ràng. Và khách hàng đã không phải claim về vấn đề này thêm bất kỳ lần nào nữa.
Kaizen trong buổi restrospective.
Một sự kiện vô cùng quan trọng là restrospective phải được diễn ra thường xuyên sau mỗi sprint . Đội hay áp dụng phương pháp 5whys để tìm ra nguyên nhân gốc rễ của một vấn đề tồn đọng và cùng nhau giải quyết.
Cùng một vấn đề trên, team đã luôn đặt câu hỏi :
- Tại sao khách luôn claim về code ? => Vì team không review theo checklist ?
- Tại sao team lại không review theo checklist ? => Vì coi nhẹ việc việc review chéo.
Cả đội đã thống nhất lại là phải review chéo một cách chặt chẽ trước khi đẩy sang test. Và mọi chuyện đã được cải thiện hơn rất nhiều.
Mọi người có thể tham khảo qua link phương pháp 5whys:
https://hocvienagile.com/agipedia/5-whys/
Bảo vệ đội
Dù thế nào đi nữa, giá trị của đội phát triển lúc nào cũng rất quan trọng. Mỗi khi bị ép tiến độ anh em cũng sẽ rất áp lực. Việc của tôi lúc này là đảm bảo những task từ phía khách hàng và PO luôn được chuyển giao một cách hợp lý nhất.
Những lúc team đang rất nhiều việc và khách đẩy thêm tính năng mới không nằm trong sprint, gây ảnh hưởng đến tiến độ của sprint hiện tại. Tôi cùng anh em cố gắng trao đổi về tiến độ nếu có thể đẩy nhanh và làm kịp task mới thì tôi sẽ chấp nhận cho anh em làm. Còn nếu không tôi sẽ nhờ PO trao đổi lại với khách hàng vì mnh không muốn anh em phải OT một chút nào cả.
Tầm quan trọng của sprint review
Trên phương diện cá nhân tôi thấy sự kiện sprint review đang bị bỏ qua rất nhiều. Đây là một trong những lý do khiến gây ra những bug miss requriment hoặc bug khách hàng.
Dù cho công việc bù đầu nhưng tôi nghĩ nên đảm bảo sự kiện sprint review được diễn ra đầy đủ. Cả đội mới nhìn thấy phần tăng trưởng của sản phẩm đội làm ra, cũng hiểu hơn về sản phẩm đội đang làm và hơn nữa có cái nhìn xa hơn về sản phẩm.
Kiểm soát tiến độ
Ngoài sử dụng các tool như burndown chart, buổi daily hàng ngày.
Việc kiểm soát tiến độ của cả đội tôi có thêm một buổi daily review lúc 16 giờ hoặc sớm hơn. Việc làm như vậy giúp sẽ có task done được trong ngày để có thể chuyển sang bên QA.
Đây là một vài kinh nghiệm tôi đúc kết được sau khi quan sát, thực hành và cải tiến. Chia sẻ với anh em mong có thể giúp nhau tiến bộ, có thể có những cách hay hơn giúp giải quyết những vấn đề xảy ra trong đội.