Làm thế nào để SCRUM quản lý một môi trường nơi các thành viên trong nhóm được chia sẻ?

Vâng, các câu hỏi tự nói. Ở nơi làm việc của tôi, những trường hợp đó xảy ra, nhưng cũng có nhiều cuốn sách Agile thúc đẩy làm việc trong cùng một nơi làm việc và tập trung vào dự án hiện tại để trở nên nhanh hơn trong tiến độ công việc.

Có thể tôi không được thông báo về chủ đề này, có thể không nghiêm ngặt nhưng, đó là lý do tại sao tôi muốn biết Agile đề xuất những gì trong những trường hợp như thế.

Có ai không

Trong phương pháp Scrum, nó chỉ ảnh hưởng đến ước tính.

Bạn sẽ chỉ định yếu tố tập trung cho người đó dựa trên việc phân bổ thời gian của họ cho từng dự án.

Vì vậy, nếu tôi đang làm việc trên Dự án A và Dự án B như nhau, Dự án A sẽ tính toán các tài nguyên như vậy:

Dự án A - Hệ số tập trung nhóm 70%
Sam - 10 ngày, phân bổ 100% (7 sau yếu tố tập trung)
Joe - 10 ngày, phân bổ 100% (7 sau yếu tố tập trung)
Tôi - 10 ngày, phân bổ 50% (3,5 sau hệ số tập trung )
Tổng cộng: 25 ngày * 70% hệ số tập trung = 17,5 vận tốc dự kiến

Bạn cũng có thể tính toán yếu tố tập trung một cách riêng biệt cho các thành viên nhóm toàn thời gian và cho các thành viên nhóm bán thời gian thay vì một lần cho toàn nhóm, do hiệu quả giảm từ các dự án chia tách. Trong trường hợp này, bạn sẽ sử dụng hệ số tập trung dự án của tôi là 50% và nhân nó với phân bổ cá nhân là 50% cho 25% hoặc 2,5 ngày vận tốc dự kiến .

Điều này hoạt động tốt như thế nào trong thực tế, sẽ là một yếu tố giúp bạn biết trước được bao nhiêu thời gian mà một tài nguyên được chia sẻ sẽ dành cho mỗi dự án và Scrum hoạt động tốt như thế nào cho bạn theo những cách khác.

Theo kinh nghiệm của tôi về Scrum, vận tốc chỉ có thể được dự đoán nếu dự án & nhóm vẫn như cũ và tận tâm. Nếu một trong những điều này thay đổi, thì bạn thực sự không thể sử dụng các tính toán vận tốc từ các lần chạy nước rút trước để thực hiện ước tính của mình. Bạn có thể thử, nhưng bạn sẽ nghỉ nhiều hơn bạn thường làm.

Nói chung, bạn chắc chắn nên cố gắng giữ cho nhóm giống nhau và tận tâm tại LEAST trong suốt một lần chạy nước rút, nhiều hơn nếu bạn có thể.

Theo tôi điều này sẽ ảnh hưởng rất xấu đến tất cả các dự án. Nó không chỉ là vấn đề ước tính hoặc lập kế hoạch. Có, bạn có thể nói rằng nếu các thành viên trong nhóm được phân bổ cho ba dự án và họ có 33% phân bổ cho mỗi dự án bạn biết mọi thứ bạn cần và bạn đã hoàn thành nhưng điều đó không đúng.

Chuyển đổi bối cảnh là rất tốn kém. Ngoài ra, việc duy trì cam kết đầy đủ cho nhiều dự án song song là không thể, vì vậy 33% phần trăm thời gian dành cho nhà phát triển khác xa với 33% khi nhà phát triển chỉ được giao cho một dự án duy nhất.

Một nơi khác mà điều này hoàn toàn thất bại là giao tiếp. Điều gì xảy ra nếu một thành viên trong nhóm hiện đang làm việc trong dự án A phải giao tiếp với một thành viên trong nhóm làm việc trong dự án A ngày hôm qua nhưng hiện đang làm việc trong dự án B? Đó là trở ngại cho cả hai vì người đầu tiên cần thông tin nhưng người thứ hai tập trung vào dự án hoàn toàn khác nhau và bất kỳ câu hỏi nào cho dự án A chỉ làm anh ta bối rối. Scrum master từ dự án A muốn nhà phát triển của mình lấy thông tin nhanh nhất có thể và Scrum master từ dự án B không muốn thành viên trong nhóm của mình bị làm phiền bởi bất cứ điều gì không liên quan đến dự án B. Nếu bạn muốn tránh điều này, bạn phải lập kế hoạch tất cả các nhà phát triển từ nhóm làm việc trên cùng một dự án trong cùng một ngày - đó là một sự phức tạp lớn đối với toàn bộ quá trình lập kế hoạch và điều gì đó nên tránh hoàn toàn.

Bạn cũng phải lên kế hoạch cho tất cả các cuộc họp để không va chạm. Bạn cũng phải hiểu rằng cuộc họp thực sự lãng phí và do đó nên có số lượng cuộc họp yêu cầu tối thiểu càng ngắn càng tốt để vẫn kiểm soát quá trình. Nhưng nếu bạn có thành viên trong nhóm làm việc trong ba dự án, anh ta phải tham gia vào tất cả các cuộc họp cho ba dự án đó => gấp ba lần cuộc họp mà nhà phát triển không tạo ra bất kỳ giá trị kinh doanh nào.

Vì kết luận nhanh cũng là về việc giảm chất thải (vâng, đó là từ cách tiếp cận Lean) và chia sẻ các thành viên trong nhóm giữa các nhóm là một trong những thất bại tồi tệ nhất trong việc giới thiệu chất thải và giảm năng suất. Tôi đoán rằng giá trị doanh nghiệp được phân bổ cho phân bổ 33% cho một dự án sẽ bằng với giá trị doanh nghiệp được phân phối từ 10-16% phân bổ toàn thời gian. Điều đó có nghĩa là nhà phát triển sẽ không chỉ tham gia 1/3 thời gian vào dự án mà trong thời gian đó năng suất của anh ta sẽ nằm trong khoảng từ 1/3 đến 1/2.

SCRUM dựa trên việc có một nhóm cam kết không có thành viên chung, do đó bạn cũng có thể hỏi:

Cho rằng chúng ta đã được bảo rằng chúng ta phải làm cho đúng == false, làm thế nào để chúng ta làm x

Nếu nó không phải là SCRUM, đừng gọi nó là SCRUM!

Câu hỏi chính là về cam kết của thành viên trong nhóm đối với dự án. Lý tưởng nhất, một thành viên trong nhóm nên hoàn toàn cam kết cho sự thành công của dự án. Điều này không có nghĩa là thời gian của anh ấy hoàn toàn dành cho dự án, nhưng anh ấy sẵn sàng làm bất cứ nhiệm vụ nào được yêu cầu cho dự án khi làm việc trong dự án.

Thông thường với nhân sự chỉ là bán thời gian cho một dự án, họ chỉ tham gia vào một phạm vi cam kết hạn chế. Chẳng hạn, bạn có thể có một người chỉ tối ưu hóa cơ sở dữ liệu.

Trong trường hợp đó, tốt nhất nên coi người đó là "tài nguyên" thay vì là thành viên trong nhóm. Nhóm quyết định số lượng tài nguyên mà họ sẽ muốn trong một Sprint cụ thể và cung cấp cho họ một nhóm nhiệm vụ rất cụ thể để hoàn thành cho Sprint. Đôi khi, tốt nhất là nếu Nhóm có một thành viên nhóm cụ thể chịu trách nhiệm về tài nguyên đó và họ sẽ thực hiện cập nhật trạng thái và báo cáo trở ngại cho tài nguyên đó trong Scrum hàng ngày.

Tôi tin rằng một trong những khía cạnh cốt lõi của Scrum là giữ cho nhóm tập trung vào mọi thứ tại một thời điểm (một dự án, một câu chuyện, một nhiệm vụ ...)

Bạn đã hỏi "Agile đề xuất gì" trong tình huống bạn không thể phân bổ tài nguyên cho một dự án ... Bạn có thể cân nhắc thử một trong:

• Giữ một bảng Kanban lớn kéo dài nhiều dự án. Là một dự án có nhu cầu, nó được thêm vào hội đồng quản trị, vì mọi người có năng lực, họ kéo những câu chuyện quan trọng. Vấn đề là tất cả các dự án được quản lý cùng nhau làm giảm khả năng dự đoán chung cho bất kỳ một dự án nào. Điều đó nói rằng, các yếu tố câu chuyện / Kanban riêng lẻ sẽ được kéo và phát triển bởi một người hoặc nhóm tập trung. (Bạn có thể thử tạo các nhóm 4-5 người nhỏ hơn để lấy từ bảng Kanban
• Chỉ giao tài nguyên cam kết. Giữ một nguồn tài nguyên chuyên dụng cho một dự án. Chúng được bảo vệ như một đội và sự gián đoạn được giữ gần bằng không. Ngoài ra, hãy giữ một "nhóm phản hồi nhanh" không tồn đọng và không tập trung vào dự án / sản phẩm. Khi sự gián đoạn xuất hiện, nhóm phản ứng nhanh xử lý các gián đoạn. Khi họ không bị gián đoạn, họ có thể tập trung vào việc cải thiện hệ thống xây dựng, thêm vào khung kiểm tra tự động hóa, v.v. Ngoài ra, họ có thể giúp đánh giá mã / đánh giá thiết kế và khắc phục các lỗi khó khăn / khó chịu phát sinh. Quản lý sự phát triển như thể nhóm này không tồn tại. Tất cả những gì họ có thể làm là kéo giao hàng. Xoay người qua nhóm này để "giữ cho nó tươi" (mọi người dường như thích / ghét việc ở trong nhóm phản ứng nhanh ...)

hi vọng điêu nay co ich!