Scrum: Điều gì xảy ra nếu Chủ sở hữu sản phẩm có nhiệm vụ?

Tôi mới bắt đầu làm việc với một nhóm đã chọn một số khía cạnh của Scrum (thời gian hai tuần) nhưng không phải là nhóm khác (nhóm hiện không đồng ý với tất cả các ước tính hoặc số điểm trong một lần chạy nước rút, nhưng tôi sẽ thay đổi điều này sớm.) Chủ sở hữu sản phẩm cũng là một tài nguyên kỹ thuật (nhà khoa học) với một số nền tảng phát triển.

Có phù hợp không khi các nhiệm vụ của chủ sở hữu sản phẩm (chủ yếu liên quan đến nghiên cứu) được trộn lẫn với các nhiệm vụ của nhóm (một số trong đó là nghiên cứu và phát triển).

Các chuyên gia về Scrum rất chắc chắn khi nói rằng Chủ sở hữu sản phẩm và Scrum Master phải là hai người khác nhau. Tuy nhiên, không có quy tắc nào như vậy ngoại trừ từ Nhóm phát triển. Lưu ý trong Hướng dẫn Scrum :

Quy mô nhóm phát triển

Kích thước nhóm phát triển tối ưu đủ nhỏ để duy trì sự nhanh nhẹn và đủ lớn để hoàn thành công việc quan trọng. Ít hơn ba thành viên Nhóm phát triển làm giảm sự tương tác và dẫn đến tăng năng suất nhỏ hơn. Các nhóm phát triển nhỏ hơn có thể gặp phải các hạn chế về kỹ năng trong Sprint, khiến Nhóm phát triển không thể cung cấp Phần tăng có thể tin cậy được. Có hơn chín thành viên đòi hỏi quá nhiều sự phối hợp. Các nhóm phát triển lớn tạo ra quá nhiều phức tạp cho một quy trình thực nghiệm để quản lý. Vai trò của Chủ sở hữu sản phẩm và Scrum Master không được bao gồm trong số này trừ khi họ cũng đang thực hiện công việc của Sprint Backlog.

Hệ quả của dòng cuối cùng đó là, nếu Chủ sở hữu sản phẩm đang thực hiện công việc của Sprint Backlog, anh ấy hoặc cô ấy được tính là thành viên của Nhóm phát triển.

Điều đó nói rằng, làm bất cứ việc gì để hoàn thành tốt công việc của bạn.

Chủ sở hữu sản phẩm chịu trách nhiệm tối đa hóa giá trị sản phẩm và lợi tức đầu tư. Điều này có vẻ đơn giản nhưng thường là vai trò toàn thời gian và rất khắt khe - được cho là khó khăn nhất trong Scrum. Nó liên quan đến nhiều công việc chiến lược cấp cao cũng như các nhiệm vụ cấp thấp hơn, từ phân tích cơ hội thị trường và tư vấn cho các bên liên quan và người sử dụng sản phẩm để đưa ra quyết định đúng đắn, giữ cho lộ trình sản phẩm và tồn đọng luôn được đánh bóng, tham gia lập kế hoạch và xem xét các hoạt động, làm cho bản thân sẵn sàng để nhóm trả lời câu hỏi của họ, v.v.

Nếu PO phụ trách các nhiệm vụ khác ngoài điều đó, tôi chỉ xem chúng là cận biên trong hầu hết các trường hợp. Vì vậy, câu trả lời của tôi sẽ là có, hãy tạo các nhiệm vụ cho PO nếu bạn thực sự phải làm và nếu chúng đóng góp trực tiếp vào việc tăng phần mềm chạy nước rút, nhưng tôi không thấy điều đó xảy ra thường xuyên trong dự án Scrum trung bình của bạn.

Scrum là đầu tiên và quan trọng nhất về giao tiếp, và thực hiện công việc có liên quan và kịp thời. Bất cứ điều gì để tiếp tục mục tiêu đó là ổn nếu đó là những gì cho phép nhóm của bạn làm việc hiệu quả nhất.

Thật khó để làm tốt, tuy nhiên. Bây giờ tôi đang ở vị trí đó và tôi thấy thật khó để dành một khoảng thời gian thích hợp làm chủ sở hữu sản phẩm trong khi vẫn dành thời gian để phát triển. Tuy nhiên, sự sắp xếp hoạt động tốt cho nhóm cụ thể tại thời điểm này. Chúng tôi sẽ xem xét lại quyết định của tôi để thực hiện nhiệm vụ kép khi hiệu suất của chúng tôi giảm xuống, nhưng cho đến lúc đó chúng tôi sẽ tiếp tục làm việc theo cách này.

Vì vậy, hãy thử nó. Làm hồi tưởng để bạn có thể liên tục cải thiện quy trình của bạn. Đừng để dính vào một số phương pháp trước đây cản trở năng suất của nhóm bạn.