Làm thế nào để bạn bao gồm Hỗ trợ trong Sprint của bạn?

Công ty chúng tôi đã chuyển sang Scrum gần đây trên một sản phẩm gần như được mã hóa bởi một người duy nhất (Joe). Chúng tôi có hỗ trợ để làm với các khách hàng hiện tại của chúng tôi mà chúng tôi cố gắng tích hợp trong quy trình của chúng tôi.

Bây giờ chúng tôi đã thử cách tiếp cận sau:

• Chúng tôi thực hiện một vòng quay trên một người phụ trách mỗi tuần.
• Người phụ trách trong tuần có thể dành tới 8 giờ cho hỗ trợ.

Nhưng chúng tôi đã không làm cho nó hoạt động:

• Joe luôn luôn hỗ trợ vì anh ta biết mã tốt hơn và anh ta luôn làm điều đó nhanh hơn là giải thích nó.
• Chúng tôi (phần còn lại của chúng tôi) có xu hướng tập trung vào những gì trên bảng Sprint hay những câu chuyện mới thay vì các nhiệm vụ hỗ trợ.
• Joe có quá nhiều công việc, anh ấy không thể tự mình xử lý tất cả sự hỗ trợ vì anh ấy cũng phải làm những việc bên ngoài Sprint.

Bạn đã phải đối mặt với tình huống tương tự? Làm thế nào bạn quản lý để thoát khỏi nó?

Lưu ý: Chúng tôi không thể dành một người duy nhất cho hỗ trợ ngay bây giờ. Chúng tôi hy vọng trong tương lai.

Chúng tôi đã thực hiện một cách tiếp cận tương tự bằng cách chỉ định một "Lập trình viên hỗ trợ" xoay quanh các nhà phát triển cơ sở hơn (hoặc mới nhất) trong nhóm. Họ được khuyến khích cố gắng hết sức để tìm ra vấn đề trước khi hỏi các nhà phát triển khác ngay cả khi nó sẽ nhanh hơn để giải quyết vấn đề đó cho nhà phát triển biết mã tốt nhất. Bằng cách này, họ buộc phải học codebase và bạn tránh được việc đánh bật mọi người ra khỏi "khu vực" và phá hủy năng suất. Ngoài ra, bạn phải xây dựng một số cơ chế để ngăn mọi người kết thúc với các lập trình viên không hỗ trợ để thực hiện công việc này.

Một điểm quan trọng là nhóm cần phải hiểu rằng những gì có thể là cách nhanh nhất để đóng các vấn đề hỗ trợ không phải lúc nào cũng là cách sử dụng hiệu quả nhất thời gian của nhóm. Hãy chắc chắn rằng toàn bộ nhóm biết rằng mục tiêu của cấu trúc này là giảm thiểu sự gián đoạn cho những người ở chế độ sản xuất đó bằng mọi giá.

Điều đó nói rằng, lập trình viên hỗ trợ không dành riêng 100% cho các cuộc gọi hỗ trợ. Họ đã làm việc trong các trường hợp trong giai đoạn nước rút, nhưng được cho là làm việc với các mục ưu tiên thấp nhất để nếu họ gác máy với nhiều vấn đề hỗ trợ thì thực tế là họ không hoàn thành vụ việc của mình sẽ không phải là mối quan tâm lớn .

Làm thế nào để bạn bao gồm đi vào phòng tắm trong Sprint của bạn? Làm thế nào để bạn bao gồm các nhà phát triển dành thời gian ở nhà chơi với con của họ? Bao gồm cả thời gian ngủ?

Tất nhiên tôi đang mỉa mai, câu trả lời là IMHO bạn không nên bao gồm thời gian hỗ trợ trong kế hoạch chạy nước rút của mình. Thời gian duy nhất nên được bao gồm trong kế hoạch chạy nước rút của bạn là các nhiệm vụ liên quan trực tiếp đến việc phân phối nước rút.

Nếu một tài nguyên dành nhiều thời gian để hỗ trợ thì bạn có ít giờ tài nguyên có sẵn từ nhà phát triển đó, chạy nước rút. Bộ tính năng bao gồm trong lần chạy nước rút đó sẽ phản ánh thực tế này.

Tôi nghĩ rằng điều đơn giản nhất để làm là thêm trực tiếp các hoạt động hỗ trợ của bạn vào danh sách các mục có trong lần chạy nước rút của bạn. Nếu các hoạt động hỗ trợ này là sửa lỗi, thì chúng sẽ được ưu tiên trong hồ sơ tồn đọng của bạn theo cách tương tự như bạn làm để cải tiến. Nếu chúng dựa trên thời gian (như chạy báo cáo cuối tháng) - chúng cũng dễ dàng được lên lịch. Đây là những gì chúng tôi làm và nó hoạt động tốt.

Trong tâm trí tôi, có hai loại công việc "hỗ trợ" khác nhau. Loại đầu tiên là một trường hợp khẩn cấp phải được khắc phục NGAY BÂY GIỜ. Đó thực sự là công việc kiểu hoạt động nhiều hơn, công cụ chữa cháy không thực sự được lên kế hoạch và ước tính như một phần của cuộc đua nước rút. Loại thứ hai là một báo cáo lỗi, được ước tính, ưu tiên và lên kế hoạch chạy nước rút. Nó được đối xử như bất kỳ câu chuyện nào khác. Thông thường, loại thứ nhất sẽ dẫn đến loại thứ hai; bạn sẽ dập lửa và tạo một báo cáo lỗi để khắc phục thực sự để nó không xảy ra lần nữa. Đối với phần còn lại của bài đăng này, tôi đang nói về vấn đề trước đây: công việc khẩn cấp, không có kế hoạch phải được thực hiện NGAY BÂY GIỜ.

Dành thời gian rời khỏi Đội để làm công việc hỗ trợ làm giảm vận tốc của Đội. Bạn nên sử dụng vận tốc lịch sử của mình để xác định năng lực cho lần chạy nước rút tiếp theo. Việc chuyển đổi ngữ cảnh cần thiết để chuyển từ công việc phát hành sang hỗ trợ công việc có nghĩa là có một số chi phí, nhưng vì công việc bạn bỏ ra để chạy nước rút nên tính đến số lượng công việc bạn đã thực hiện trong một lần chạy nước rút, thời gian điển hình bạn đưa vào hỗ trợ và chi phí chuyển đổi ngữ cảnh sẽ tự động được tính.

Tôi không coi đây là công việc chạy nước rút. Nó riêng biệt, và nên được ưu tiên trên công việc chạy nước rút. Do đó, nó ăn vào vận tốc của đội và được "lên kế hoạch" bằng cách sử dụng vận tốc giảm đó khi quyết định số lượng công việc có thể hoàn thành trong lần chạy nước rút tiếp theo.