Làm cách nào để phối hợp thời gian của nhà phát triển giữa hai dự án khác nhau trong Scrum?

Tôi đã trở thành bậc thầy của một nhóm mới thành lập, chịu trách nhiệm tạo ra một phần mềm VÀ duy trì ứng dụng được triển khai khác. Vì vậy, về cơ bản mỗi thành viên trong nhóm có nhiệm vụ phát triển và hoạt động.

Tôi đã quan sát cách họ làm việc trong vài tuần qua và tôi nhận thấy rằng nhóm đang gặp khó khăn trong việc điều phối các nhiệm vụ này. Khi một nhà phát triển đang tập trung vào mã hóa, anh ta bị gián đoạn để khắc phục một vấn đề được đưa ra trong sản xuất và thật khó để anh ta tập trung trở lại vào nhiệm vụ trước đó.

Tôi đã cố gắng phân bổ% thời gian của nhà phát triển cho các hoạt động nhưng dường như điều này không giải quyết được vấn đề. Tôi muốn nghe từ những bậc thầy scrum đã gặp tình huống này trước đây, bạn đã quản lý nó như thế nào và những đề xuất của bạn là gì?

Vấn đề này là cũ như scrum. Có một giải pháp, nhưng bạn sẽ không thích nó.

• Đặt nhiệm vụ mới vào backlog.
• Đừng làm gián đoạn các nhà phát triển.
• Chờ nước rút tiếp theo.

Đưa các nhà phát triển của bạn vào nhiều hơn một scrum, có hai tồn đọng riêng biệt hoặc chỉ gán một phần trăm thời gian của họ cho chạy nước rút tất cả đều chống lại những gì scrum đang cố gắng đạt được, tức là một dòng hoàn thành các nhiệm vụ hoàn thành.

Nếu bạn thử những kiểu đó về cơ bản, bạn sẽ quay trở lại phương pháp phát triển 'hỗn loạn' hoặc 'JFDI' với tất cả các vấn đề liên quan đến nó, ví dụ

• Nhà phát triển có mười nhiệm vụ khi đang di chuyển bất cứ lúc nào. Không ai biết những gì họ đang làm việc hoặc khi nào nó sẽ được hoàn thành.
• Không biết thời gian để hoàn thành dự án, bởi vì nó phụ thuộc vào những gì các dự án khác đang xảy ra cùng một lúc.
• Không có quan điểm nhất quán về ưu tiên dự án. Các nhà quản lý khác chuyển hướng các nhà phát triển đến các dự án thú cưng của họ.

Tất nhiên, câu trả lời thông thường cho lời khuyên này là "Nhưng tôi không thể làm điều đó! Doanh nghiệp cần những lỗi sản xuất đó để được sửa chữa càng sớm càng tốt!"

Nhưng điều đó không thực sự đúng.

Nếu bạn thực sự có nhiều lỗi thực tế đang ảnh hưởng đến doanh nghiệp đến mức này thì bạn cần phải chuyên nghiệp và cải thiện thử nghiệm của mình. Chỉ cần làm việc trên các lỗi và kiểm tra tự động cho đến khi bạn đã sửa tất cả. Thuê một nhóm QA và thử nghiệm tất cả các bản phát hành mới.

Những gì có nhiều khả năng mặc dù là một trong những điều sau đây:

• Các lỗi là vấn đề hoạt động, hết dung lượng đĩa, không DR, không sao lưu, không chuyển đổi, vv Nhận một nhóm OPS.

• Các lỗi là người dùng không hiểu hệ thống nên hoạt động như thế nào "Điều này đã xảy ra! Đây có phải là một lỗi không?". Nhận trợ giúp và đào tạo người dùng của bạn, viết tài liệu.

• Sợ rollback. Bạn đã khởi chạy một tính năng mới và nó đã phá vỡ một cái gì đó, đừng cố gắng sửa chữa. Quay trở lại phiên bản trước và đưa các lỗi vào backlog.

Chỉ cần cố gắng để suy nghĩ bên ngoài hộp ở đây.

Vì có thể không thể khiến chủ sở hữu sản phẩm thấy mọi thứ theo cách của bạn. Vẫn có thể có những lỗi nghiêm trọng mà đơn giản là không thể chờ đợi, gặp gỡ khách hàng khi cần hỗ trợ nhà phát triển, v.v ... khi bạn cần đưa một nhà phát triển ra khỏi nước rút trong một thời gian.

Tại sao không thử dự đoán điều này và sử dụng nó cho lợi thế của bạn?

Bạn sẽ cần một nhóm 5+ để nó trở nên thực tế.

Nhưng tại sao không đưa một nhà phát triển ra khỏi mọi lần chạy nước rút (luân phiên giữa các nhà phát triển, mỗi người sẽ đến lượt mình).

Vì rất có thể không đủ lỗi để sử dụng một nhà phát triển đầy đủ để sửa lỗi, có những vấn đề hoặc nhiệm vụ khác có thể được thực hiện.

• Chạy thử nghiệm để xác định tắc nghẽn hiệu suất hoặc các vấn đề về khả năng mở rộng
• Duy trì hệ thống xây dựng
• Các cuộc họp với khách hàng
• Nghiên cứu các khung / thư viện mới
• Khám phá các tính năng ngôn ngữ bạn muốn sử dụng
• Đọc về các vấn đề bảo mật
• Bảo trì cơ sở dữ liệu
• Sự bảo trì máy chủ

Vận tốc nhóm có thể tăng lên, căng thẳng có thể giảm, xung đột với quản lý có thể giảm, bạn thực sự có thời gian để cải thiện kiến ​​thức của bạn.

Một giải pháp hiệu quả để quản lý nỗ lực của nhà phát triển cho các vấn đề sản xuất thực sự thiết yếu mà tôi đã sử dụng là "phương pháp Batman".

Khía cạnh đắt đỏ của trách nhiệm hỗ trợ sản xuất trong khi phát triển chức năng mới là chuyển đổi ngữ cảnh, vì vậy bạn nên đặt mục tiêu hạn chế điều đó.

Với việc nhóm mua vào, tạo một danh sách các thành viên trong nhóm và duyệt qua nó, để mỗi ngày, một người mới được tuyên bố là "Người dơi" tại cuộc họp đứng lên và sẽ trả lời các vấn đề sản xuất thiết yếu vào ngày hôm đó. Phần còn lại của nhóm có thể tập trung vào phát triển mà không phải chuyển đổi ngữ cảnh và mọi người đều có một phần công bằng về nỗi đau của sự hỗ trợ. Với nhóm 5 người, đó là một ngày một tuần trong đó nhà phát triển có thể bị gián đoạn và 4 ngày không bị gián đoạn, thời gian phát triển có thể dự đoán được.

Điều này có lợi ích về kiến ​​thức / kinh nghiệm được chia sẻ giữa các nhóm, vì vậy bạn không có một người chịu trách nhiệm khắc phục các vấn đề cụ thể và trở thành một điểm thất bại duy nhất và phân chia công bằng các vấn đề hỗ trợ.