Scrum hoặc kanban có thực sự hữu ích cho các đội SRE không?

Các thực hành nhanh nhẹn như scrum và kanban được thiết kế chủ yếu để phát triển phần mềm.

Công việc gián đoạn và không có kế hoạch là một thành phần quan trọng của hầu hết các nhóm SRE ( Kỹ thuật Độ tin cậy Trang web ) hoặc nhóm DevOps làm. Mặc dù việc sử dụng một hệ thống theo dõi như Jira để quản lý công việc luôn hữu ích, nhưng chạy nước rút hoặc kanban có thực sự hiệu quả với các nhóm SRE không?

Các ràng buộc tôi thấy là:

• Công việc rất tự nhiên, với các ưu tiên thay đổi hàng ngày. Bởi vì điều này, thời gian chạy nước rút trong hai tuần có vẻ rất tích cực và nó thêm chi phí không cần thiết.
• Những người đang trong cuộc gọi thêm một khía cạnh khác cho vấn đề. Đôi khi, nhiều thành viên trong nhóm có thể tham gia vào các nhiệm vụ gọi / khám nghiệm tử thi.
• Nhóm không có một "sản phẩm" duy nhất và do đó, nó không mang lại quy trình lập kế hoạch chung
• Các cuộc họp chờ hàng ngày có thể không có nhiều ý nghĩa vì thiếu sự chồng chéo giữa các nhiệm vụ
• Nhóm có thể đang thực hiện các nhiệm vụ liên quan đến nhiều nhóm đối tác và do đó trải rộng trên nhiều dự án Jira. Vì một bảng chạy nước rút hoặc kanban chỉ cho phép một dự án Jira, nên nó có thể không phù hợp với tất cả các công việc.

Từ những gì tôi nghe được từ nhiều SRE mà tôi đã nói chuyện, kế hoạch chạy nước rút hoàn toàn không hiệu quả với họ. Tôi muốn nghe từ cộng đồng ở đây kinh nghiệm của họ với nước rút và kanban là gì.

Tôi cũng đã hỏi câu hỏi này trên scrum.org:

Scrum có thể được sử dụng hiệu quả bởi các nhóm SRE?

Chúng tôi không sử dụng Agile cho nhóm DevOps, nhưng chúng tôi tích hợp với các Nhóm Scrum bình thường. Khi nhóm cần từ DevOps cần một cái gì đó, chẳng hạn như tối ưu hóa máy chủ xây dựng, nhóm liên quan sẽ đặt PBI trong hồ sơ tồn đọng của họ với nhãn 'DevOps'. Khách hàng tiềm năng của chúng tôi có bảng điều khiển tùy chỉnh ở Jira với tất cả các vấn đề được gắn nhãn 'DevOps'. Họ làm việc với Scrum Master để được ưu tiên và sau đó một trong các Kỹ sư DevOps được giao nhiệm vụ là thành viên đặc biệt của Nhóm Scrum trong suốt cuộc đời của vấn đề đó. Điều này giúp chúng tôi ưu tiên công việc dựa trên các ưu tiên "của khách hàng", gắn kết nỗ lực của chúng tôi với nước rút và cho phép chúng tôi có được "tín dụng" cho công việc chúng tôi đang làm.

Trước đó, chúng tôi đã sử dụng Kanban trên Jira chỉ cho một danh sách việc cần làm. Thật không may, đôi khi chúng tôi sẽ phải ngừng làm việc trên một cái gì đó chúng tôi đã lên kế hoạch để làm việc vì một trong các đội cần một cái gì đó. Bây giờ, trừ khi đó là trường hợp khẩn cấp, về cơ bản, họ yêu cầu tài nguyên DevOps (người / thời gian) thông qua hồ sơ tồn đọng của họ và Scrum Master truyền đạt nhu cầu đó cho Trưởng nhóm của chúng tôi.

Agile hoạt động rất tốt cho loại môi trường hỗn loạn này. Tuy nhiên, vì những lý do bạn nêu bật, Scrum trong sách giáo khoa thuần túy có thể không phù hợp lắm. Là một Scrum Master, người thực hiện một số lượng DevOps khá lớn, tôi đã sử dụng bảng Kanban trong Jira để theo dõi công việc.

Ưu điểm của Kanban

• Hình dung về công việc mà nhóm đang làm.
• Xác định cổ chai cho đội.
• Giúp giữ cho nhóm tập trung vào việc di chuyển công việc cùng.
• Cho phép công việc được thêm vào bất cứ lúc nào.
• Cung cấp khả năng hiển thị cho công việc đang được thực hiện cho các nhóm khác đang dựa vào SRE.
• Có thể chung chung để bao gồm nhiều loại công việc.

Mặc dù cách đứng truyền thống có thể không có lợi, hãy xem xét sửa đổi nó. Một cuộc họp tốt đứng lên làm nổi bật các trình chặn mà một thành viên trong nhóm có thể phải đối mặt mà một thành viên khác trong nhóm biết cách giải quyết.

IMO: Có, Scrum có thể được sử dụng hiệu quả bởi các nhóm SRE. Tôi chưa bao giờ nghe hoặc đọc rằng các thành viên trong nhóm chỉ có thể làm việc trên các bài tập chạy nước rút, vì vậy đó là một quan niệm sai lầm rằng bạn cần tính đến tất cả thời gian và nỗ lực của bạn trong phạm vi chạy nước rút; Ngoài ra, tôi cảm thấy có một quan niệm sai lầm rằng tất cả các công việc của bạn là áp dụng cho nước rút. Vì vậy, hội tụ, bạn nên quản lý một số công việc với Scrum và một số bên ngoài nó.

Scrum, ở cốt lõi của nó, là một khung (với các tạo tác và sự kiện) linh hoạt và được sử dụng để cải tiến liên tục về tính chất công việc được nhóm chấp nhận (hoặc áp dụng cho công việc đó).

Những gì bạn cần làm là cân bằng giữa thời gian và công sức bạn có thể cung cấp cho công việc chạy nước rút được lên kế hoạch, được chấp nhận mà bạn và nhóm của bạn có thể thực hiện và thời gian và nỗ lực để giải quyết công việc ngoài kế hoạch ngoài nước rút.

Có một thước đo mức độ nghiêm trọng và ưu tiên cho tất cả các workitem. Nếu bạn đang xem xét Scrum, bạn nên chấp nhận làm việc với mức độ nghiêm trọng cụ thể. Bạn cũng nên xem xét công việc có thể làm giảm mức độ nghiêm trọng của công việc sắp tới (nếu có thể). Tôi cũng khuyên bạn nên bắt đầu chạy nước rút với khoảng một nửa công suất (điều này rất khó xác định vì thời gian và nỗ lực liên quan đến thời trang công suất lúc ban đầu là) - hãy xem nhẹ. Mục tiêu của nhóm bạn phải luôn là cung cấp những gì công việc mà nhóm của bạn chấp nhận, vì vậy hãy kén chọn và đừng quá mức.

Tôi nghĩ rằng bản chất công việc của bạn thực sự có thể so sánh với công việc sửa lỗi sản xuất cho các nhóm phát triển. Do đó, bạn có thể muốn tham khảo các nhóm bảo trì sản xuất về việc áp dụng và thành công Scrum của họ và Không nhất thiết phải tự giới hạn kinh nghiệm của DevOps Engineers trong quản lý chương trình và dự án.