EN |
VN
Trong một vài trường hợp, việc thiết lập Sprint Goal không phải là điều dễ dàng. Và việc xây dựng Sprint Goal tốt lại càng khó hơn. Điều này được chứng minh rõ nhất với những nhóm ở giai đoạn ban đầu. Đã có một số bài blog viết về chủ đề này rất hay, tôi khuyến nghị bạn nên tìm kiếm và đọc thêm sau khi đọc xong bài chia sẻ này. Theo kinh nghiệm đào tạo và thực tiễn của mình, tôi vẫn thường nghe những câu đại loại như “Trong trường hợp của chúng tôi, việc xác định Sprint Goal là điều không thể vì các lý do ABC…”.
Tôi có vài gợi ý cho bạn đây, các Scrum Master. “Sprint Goal giống như một con chim hoàng yến trong mỏ than.” Nó báo hiệu rất sớm nếu có điều gì đó không ổn liên quan đến việc cung cấp giá trị. Nếu bạn nghe được điều này từ Product Owner, một Developer hay chính bạn nhận thấy thì có nghĩa là, bạn đã nhận ra các vấn đề có thể xảy ra trong khi chuyển giao giá trị. Vì vậy hãy điều chỉnh lại từ “Sprint Goal này không phù hợp với chúng ta” thành “Sprint Goal này chưa phù hợp với chúng ta”. Thay vì nói rằng “không thể xác định Sprint Goal vì các lý do ABC…”, bạn có thể nói “chưa thể xác định Sprint Goal vì cần giải quyết các vấn đề XYZ…”.
Là một Scrum Master, bạn cần hỗ trợ để nhóm và tổ chức của mình giải quyết vấn đề này. Đây có thể là cơ hội giúp bạn tìm thấy bài học quý giá đang tiềm ẩn trong cách sử dụng Scrum của mình. Từ đó, bạn cũng có thể lường trước những thách thức mà bạn sẽ hiếm khi gặp phải khi áp dụng Scrum. Bên cạnh đó bạn còn có thể trải nghiệm nhiều sự kiện hấp dẫn cũng như nhận được nhiều sự chú ý và sự cam kết của tất cả thành viên tham gia. Đừng chỉ nghe vào lý thuyết tôi nói mà hãy thử áp dụng nó ngay. Khi bạn phát hiện ra các vấn đề có thể xảy ra để giải quyết, chúng thường nằm trong các trường hợp sau đây:
Team của bạn không thực sự lấy khách hàng làm trung tâm.
Bạn không cung cấp cho khách hàng các tính năng toàn diện. Thay vào đó, bạn giao cho một bộ phận khác phụ trách xây dựng một phần của hệ thống. Sau đó lại có một nhóm khác làm nhiệm vụ tổng hợp toàn bộ các phần. Nói cách khác, nhóm của bạn là một nhóm thành phần trong một tổng thể lớn. Vì vậy thật khó để đề ra một mục tiêu đủ hiệu quả trong một bộ phận kỹ thuật. Lúc này, cấu trúc vận hành của nhóm bạn là vấn đề cần giải quyết, bạn nên trao đổi vần đề này với ban quản lý.
Product Owner của bạn không có mục tiêu rõ ràng cho Sprint.
Có nhiều các bên liên quan (stakeholder) với những yêu cầu khác nhau và rất nhiều áp lực từ bộ phận kinh doanh liên quan đến việc chuyển giao giá trị. Thật khó để từ chối với bộ phận kinh doanh, vì mọi thứ đều thực sự cần thiết và khẩn cấp. Nói cách khác, người chỉ đạo hướng đi nên là Product Owner đang trực tiếp đưa ra yêu cầu thay vì Product Owner ban đầu. Lúc này, vấn đề cần giải quyết là sự ủy thác gián tiếp hoặc thiếu tầm nhìn cũng như một chiến lược rõ ràng.
Product Backlog của bạn có quá nhiều dự án, đề mục, đề tài và các thành phần khác nhau của một sản phẩm, mà hầu như chúng không có bất kỳ điểm chung nào.
Phía trên cùng của Product Backlog có công việc cho X stakeholder khác nhau và Y tính năng khác nhau. Điều quan trọng là bạn buộc phải hoàn thành tiến độ của tất cả các yếu tố này. Nói cách khác, bạn tập trung vào việc hoàn thành tiến độ và luôn trong tình trạng bận rộn. Bạn phải bắt đầu làm việc từ rất sớm và xong việc lúc đã tối muộn. Thông thường, những thứ làm chúng ta cảm thấy nhanh chóng thì thực chất đang khiến chúng ta chậm lại. Lúc này, vấn đề cần giải quyết có thể là cấu trúc và trật tự của Product Backlog.
Nhóm của bạn cần phân phối nhiều mục trong nhiều Sprint để tạo ra một giải pháp trọn vẹn.
Trước tiên, bạn cần thực hiện một số phân tích trong Sprint, sau đó bạn có thể tạo ra các câu chuyện cho người dùng (user story) để phát triển thêm. Đối với sản phẩm, đầu tiên bạn cần lập nên cơ sở dữ liệu và sau đó là chuyển giao chúng một cách logic. Cuối cùng, bạn cần kiểm tra chấp nhận người dùng (User Acceptance Testing – UAT) để hoàn thiện tính năng. Nói cách khác, bạn đang mổ xẻ vấn đề theo chiều ngang. Có thể cách mà bạn chia nhỏ công việc theo từng giai đoạn và thành phần là vấn đề cần giải quyết.
Sẽ có nhiều thách thức khác đang chờ nhóm của bạn cũng như các sản phẩm cần được chuyển giao và các trường hợp được kể trên chưa phải là một danh sách đầy đủ. Tuy nhiên, hy vọng bạn có thể áp dụng câu hỏi “Vấn đề bạn cần giải quyết khi không đạt được Sprint Goal là gì?” để tìm ra giải pháp cho vấn đề của bạn. Nếu vấn đề nằm ở cấu trúc vận hành thì giải pháp có thể là yêu cầu thay đổi cấu trúc. Tôi luôn khuyến khích bạn nên liên tục thử nghiệm và học hỏi từ kết quả thu được.
Ngoài ra, vẫn còn những điều khác có thể giúp bạn cải thiện dần. Bạn và Product Owner sẽ nhận ra những điều này khi bắt đầu làm việc trực tiếp với nhau. Thành quả sẽ đến dễ dàng hơn khi ta tập trung nhiều hơn vào Product Backlog. Về bản chất, bạn phải bắt đầu giảm số lượng công việc làm song song với nhau:
- Hãy làm việc cho ít stakeholders hơn trong cùng một thời điểm, điều này giúp bạn thấy mình đang tiến bộ.
- Chỉ thực hiện song song một số ít các đề mục, dự án và tính năng.
- Trong cùng một thời điểm, nên bắt đầu với ít nội dung hoặc danh mục trong Sprint hơn.
- Cùng nhau thực hiện một số hạng mục có liên quan với nhau thay vì tùy ý làm từng hạng mục riêng lẻ của mỗi người.
- Ngừng làm song song các nhiệm vụ không liên quan, chỉ vì trông chúng có vẻ giống nhau hoặc vì bạn vẫn chưa hoàn thành các nhiệm vụ khác. Hãy bắt đầu hoàn thành nhiệm vụ và giải quyết các nút thắt của bạn.
Bằng cách giới hạn lại số lượng những công việc khác nhau bạn cần làm ở tất cả các cấp, bạn sẽ có được sự tập trung. Tập trung vào hoàn thành công việc, hợp tác với các bên liên quan và tạo ra kết quả. Hãy coi đây là một bước tiến lớn để tạo ra một Sprint gắn kết hơn và từ đó tạo ra một Sprint Goal phù hợp.
Nguồn: Struggling with Sprint Goals – Tác giả: Bjorn Van Den Einden
Bjorn Van Den Einden là một huấn luyện viên Agile đồng thời là một chuyên gia đào tạo Scrum. Với mong muốn đơn giản hóa các tổ chức và việc phát triển sản phẩm của họ, Einden chia sẻ những kinh nghiệm của mình trong việc cải thiện, tìm niềm vui trong công việc và chuyển giao nhiều giá trị hơn đến thế giới phức tạp hiện nay.
Vai trò, quyền và trách nhiệm của đội Disciplined Agile Delivery
08 điều ta học được về nhóm trong một năm khó khăn
Tạo ra bảng công việc của riêng bạn: Cách duy trì quy trình quản lý dự án từ xa
