Scrum có cho vay chính nó trong môi trường nhiều dự án không?

Tôi sẽ chuyển nơi làm việc trong tương lai gần và tôi tin rằng họ sẽ rất quan tâm đến trải nghiệm của tôi về Scrum và làm thế nào nó có thể liên quan đến việc kinh doanh của họ. Tôi đang cố gắng để hiểu nếu nó sẽ làm việc trong môi trường của họ.

Nơi làm việc hiện tại của tôi, chúng tôi có 2 sản phẩm / 2 hồ sơ tồn đọng / 2 nhóm riêng biệt. Những tồn đọng này rõ ràng được ưu tiên dựa trên những gì doanh nghiệp nghĩ rằng nó cần nhất cho một nền tảng mà chúng tôi phát triển. Tuy nhiên, nơi tôi sẽ chuyển đến có rất nhiều dự án cùng lúc với (2/3 cá nhân làm việc trên mỗi), một số lượng nhỏ công việc đến và được cố định hàng ngày và tôi tưởng tượng tất cả các sản phẩm của khách hàng gần như là quan trọng như nhau.

Vì vậy, tôi tự hỏi nếu có ai có kinh nghiệm về Scrum trong một môi trường tương tự, bạn có ví dụ thực tế nào về những thứ đã hoạt động? Điều gì đã không làm việc? Cần cân nhắc những gì để Scrum hoạt động trong tình huống này?

Có một vài khía cạnh mà tôi không chắc làm thế nào sẽ diễn ra tốt đẹp:

1. Tôi tin rằng mọi người trong các nhóm sẽ làm việc trong các dự án và do đó có khả năng qua các nhóm scrum nếu bị phá vỡ.
2. Làm thế nào để bạn đi về việc xử lý ưu tiên trên rất nhiều bộ phận chuyển động có thể thay đổi thường xuyên và có thời gian riêng của họ?
3. Nếu bạn có một nhóm scrum hoạt động trên một số dự án (một số dự án chỉ yêu cầu 1 Dev) thì làm thế nào để bạn hiểu bối cảnh của stand-up?

Tôi làm việc với tư cách là Giám đốc phát triển trong chính xác môi trường này và đã thực hiện Scrum cực kỳ thành công với một nhóm 4 người trong năm qua, từ một mớ hỗn độn khủng khiếp. Phải mất một chút thời gian để đến nơi chúng ta đang ở, nhưng nó hoạt động rất tốt. Tôi sẽ cố gắng tóm tắt những hành động quan trọng nhất, nhưng hãy hỏi thêm.

1. Tôi đóng vai trò là Chủ sở hữu sản phẩm và Scrum Master. Tôi đã làm việc để tạo ra một hồ sơ tồn đọng cho mỗi sản phẩm, với các bên liên quan.

2. Sau đó, tôi đã ưu tiên trên TẤT CẢ các hồ sơ tồn đọng, vì vậy tôi hoàn toàn có các dự án kéo dài tồn đọng của riêng mình. Điều này đã sử dụng Fogormsz, vì vậy tôi có thể lọc từng dự án để các bên liên quan làm việc với tôi và xáo trộn các mục.

3. Lập kế hoạch chạy nước rút từ điều này, gói gọn tất cả các dự án và tất cả các thành viên trong nhóm, vì vậy một số thành viên trong nhóm sẽ làm việc với các nhiệm vụ cụ thể của riêng họ, nhưng khuyến khích làm việc và học tập đa chức năng. Tất cả các cuộc thảo luận đứng lên đều hữu ích, bởi vì nếu ai đó đang nói về điều gì đó mà không ai biết, họ phải giải thích đủ để chúng ta hiểu. Điều này hỗ trợ việc học tập.

   • Tại thời điểm này, nhóm đã thiếu sự gắn kết, nhưng ít nhất chúng tôi đã hoàn thành mọi việc trên tất cả các dự án, giữ cho doanh nghiệp hài lòng và cải thiện chất lượng bằng cách thêm kiểm tra nguồn / kiểm tra tự động. Đó là một cải tiến lớn của mớ hỗn độn trước đây, nhưng cũng khó duy trì sự tập trung, không có mục tiêu nào khác ngoài việc hoàn thành nước rút. Chúng tôi cũng không có bản demo vì chúng sẽ không liên quan đặc biệt đến bất kỳ một bên liên quan nào. Bởi vì tôi là cả PO và SM, tôi tương đối nhẹ nhàng khi kết hợp đội quá nhiều. Điều đáng chú ý là chúng tôi vẫn đang cung cấp RẤT NHIỀU hơn trước khi tôi đến.

4. Sau đó, tôi đã cố gắng từ từ chuyển trọng tâm của chạy nước rút nhiều hơn sang một sản phẩm, vì vậy chúng tôi sẽ có một cuộc chạy nước rút nói 60% cho một sản phẩm, nhưng vẫn với các nhiệm vụ khác. Cuối cùng, chạy nước rút được tập trung 90% vào một nhiệm vụ và các bên liên quan đã học cách 'chờ đến lượt mình' - sau tất cả, chúng tôi vẫn đạt được nhiều hơn bao giờ hết. Điều này làm cho Demo có thể cho một sản phẩm tại một thời điểm.

5. Khi nước rút được tập trung, tôi bắt đầu đào tạo các bên liên quan trong Scrum và biến một số trong số họ thành Chủ sở hữu sản phẩm. Đây là giai đoạn tôi đang ở hiện tại, tôi làm việc với 3 chủ sở hữu sản phẩm và vẫn có 2 sản phẩm tôi sở hữu một cách hiệu quả. Sprint có thể có 1 hoặc 2 nhiệm vụ cho các dự án 'khác', nhưng chúng tôi có đủ trọng tâm cho bản demo chạy nước rút với các bên liên quan chính của lần chạy nước rút chỉ thể hiện các tính năng mới của sản phẩm.

Tôi hy vọng điều này có ích, đây là hành trình tôi đã đi với chủ nhân hiện tại của tôi và cho đến nay nhóm Dev, đơn vị kinh doanh và (quan trọng nhất) ông chủ của tôi rất hạnh phúc.

Tôi hiện đang làm việc như một phần của nhóm scrum 4 người chịu trách nhiệm, ở mức độ này hay mức độ khác, đối với mọi sản phẩm của công ty chúng tôi. Tổng cộng có khoảng 16 sản phẩm, cộng với một mớ hỗn độn bán kết nối một lần, tôi có thể nói với bạn từ kinh nghiệm rằng scrum không tự tạo ra môi trường đa dự án. Như đã nêu ở trên, thật khó để xây dựng sức mạnh tổng hợp của nhóm khi bạn liên tục làm việc cá nhân trên những thứ khác nhau. Hơn nữa, thật khó để liên quan chéo đến các chi tiết làm việc trong các nhiệm vụ của đồng đội, vì trọng tâm của bạn là một nhiệm vụ hoàn toàn khác, trong một dự án hoàn toàn khác.

Ngoài ra, phân tích 'yêu' hoặc thậm chí không được chỉ định với một sản phẩm cụ thể là gần như không thể do tỷ lệ doanh thu chuyển nhượng, có thể dẫn đến thối mã, trong số những thứ khác.

Nếu bạn thấy mình ở một vị trí mà bạn không thể thoát khỏi nhiều dự án được giao cho nhóm của mình, tôi sẽ không đề xuất SCRUM.

Câu trả lời được chấp nhận giải quyết câu hỏi khá, nhưng cho phép tôi chia sẻ kinh nghiệm của mình. Tôi đã ở hai tình huống khác nhau khi các thành viên của nhóm SCRUM phải xử lý nhiều dự án. Một nhóm SCRUM có thể xử lý nhiều dự án, nhưng chỉ trong một số điều kiện nhất định.

Trong trường hợp đầu tiên, nhiều dự án đưa ra một thách thức đáng kể. Chủ nhân của tôi vẫn chưa áp dụng các phương pháp Agile nói chung. Tôi là một phần của một phi công nơi chúng tôi đã sử dụng SCRUM cho một dự án duy nhất.

Vấn đề là đội ngũ quản lý dự án ủng hộ việc có nhiều dự án đồng thời, chạy dài hơn các dự án ngắn, tập trung. Kết quả là, nhóm của tôi liên tục được giao nhiều dự án hơn chúng tôi có các nhà phát triển; đó là điển hình cho nhóm bốn người đang tung hứng sáu đến mười dự án! Điều này đã trở nên trầm trọng hơn bởi thực tế là chúng tôi cũng phải xử lý một số lượng đáng kể trách nhiệm vận hành và hỗ trợ.

Những gì chúng tôi tìm thấy là vì nhóm chỉ dành một phần nhỏ thời gian dành cho nhóm SCRUM, chúng tôi không thể thiết lập vận tốc đáng tin cậy và đã giới hạn số lượng công việc cho mỗi Sprint vì sợ không thực hiện các cam kết Sprint của chúng tôi. Việc kết hợp tất cả các công việc từ các dự án khác vào kế hoạch của chúng tôi có thể giúp ích, nhưng các dự án đó có ngày và phạm vi cố định, khiến chúng tôi không thể thực hiện SCRUM đúng cách.

Trong trường hợp thứ hai, toàn bộ công ty từ lâu đã chấp nhận Agile và đã phát triển một phương tiện để nhiều dự án có thể được giải quyết bởi một nhóm SCRUM. Nó hiệu quả đến nỗi, với tư cách là một Kỹ sư, tôi thậm chí còn không biết một nửa dự án là gì! Chủ sở hữu sản phẩm sẽ làm việc với Người quản lý dự án để xác định công việc cần thiết; sử dụng các ước tính do chúng tôi cung cấp Các kỹ sư và vận tốc do nhóm thiết lập, Chủ sở hữu sản phẩm có thể đưa ra dự đoán hợp lý về việc khi nào một mặt hàng cụ thể sẽ được hoàn thành. Miễn là nhóm luôn đáp ứng các cam kết của họ, chúng tôi không cần phải lo lắng về ngày đáo hạn để giao hàng nhiều nhất.

Mặc dù vậy, nó đã giúp tất cả chúng ta đều làm việc trên cùng một bộ ứng dụng nhỏ. Các nhóm được liên kết với các sản phẩm, giúp dễ dàng hiểu được những gì đồng nghiệp của bạn đang làm cũng như giúp dễ dàng chuyển trọng tâm từ dự án này sang dự án tiếp theo khi cần thiết.

Nói tóm lại, SCRUM có thể dễ dàng được điều chỉnh để xử lý nhiều quy trình đồng thời, nếu kế hoạch và tổ chức phù hợp được thực hiện.

Tôi không chắc là tôi hiểu, nếu bạn có "2/3 cá nhân làm việc trên mỗi" thì không giống như có nhiều nhóm, mỗi nhóm làm việc trong một dự án.

Họ có thể thay đổi dự án thường xuyên, thay vì có một "sản phẩm" mà họ liên tục làm việc, nhưng điều đó không có nhiều khác biệt. Một số nơi thậm chí còn mong đợi các nhóm làm việc trên các phần khác nhau của sản phẩm và thay đổi để làm việc khác sau khi hoàn thành mỗi dự án - chủ yếu là để đảm bảo truyền bá kiến ​​thức tốt.