Scrum hoạt động như thế nào khi bạn có nhiều dự án? [đóng cửa]

Tôi đọc khá rõ về các lợi ích và quy trình của Scrum. Tôi lấy ý tưởng về công việc tồn đọng, biểu đồ tổng hợp, lặp lại, sử dụng câu chuyện của người dùng và các khái niệm khác nhau về "khuôn khổ" Scrum.

Như đã nói ... Tôi làm việc cho một công ty phát triển web quản lý nhiều dự án cùng một lúc, với sáu thành viên trong nhóm tạo thành "nhóm sản xuất".

Scrum hoạt động như thế nào khi có nhiều dự án? Bạn vẫn chỉ lập lịch lặp lại cho một dự án trong một khoảng thời gian nhất định và toàn bộ nhóm làm việc trên đó, sau đó bạn chuyển sang dự án tiếp theo với một lần lặp mới khi quá trình lặp đó hoàn thành? Hoặc có cách nào "nhanh nhẹn" trong việc quản lý nhiều dự án với các lần lặp lại của riêng chúng với chỉ một nhóm cùng một lúc không?

Scrum thực sự không ra lệnh rằng bạn phải làm việc trên một sản phẩm độc lập. Nó chỉ đơn giản nói rằng có rất nhiều thứ cần phải hoàn thành (sản phẩm tồn đọng), có một lượng thời gian phát triển nhất định có sẵn trong lần lặp tiếp theo (được thực hiện theo tốc độ dự án) và có các mục do khách hàng lựa chọn / doanh nghiệp có mức độ ưu tiên cao nhất từ ​​nhóm các vấn đề / nhiệm vụ này sẽ được thực hiện trong lần lặp tiếp theo (tồn đọng nước rút).

Không có lý do gì mà product backlog và sprint backlog phải từ một dự án - ngay cả trong một dự án duy nhất sẽ có các đơn vị công việc rời rạc giống như các dự án riêng biệt - giao diện người dùng, lớp nghiệp vụ, lược đồ cơ sở dữ liệu, v.v. Phát triển phần mềm doanh nghiệp nói riêng là như vậy, nơi bạn có một số cơ sở mã mà tất cả đều phải tiến triển. Quy trình Scrum - các cuộc họp, câu hỏi, ghi lại biểu đồ, v.v. - tất cả đều hoạt động cho dù đó là một dự án hay nhiều dự án.

Phải nói rằng, trong thực tế, mỗi lần lặp lại thường có một chủ đề chính - "thực hiện mô-đun báo cáo" hoặc "giao diện với API của hệ thống XYZ" - vì vậy rất nhiều vấn đề đến từ một dự án hoặc khu vực và tại kết thúc lần lặp, bạn có thể trỏ đến một phần lớn công việc và đánh dấu vào nó.

Tôi nghĩ câu trả lời phụ thuộc vào việc " ai sẽ là người ưu tiên các hạng mục tồn đọng " (tức là quyết định việc gì cần làm trước). Nếu đây là một người duy nhất, thì người này là Product Owner cho các dự án của bạn và bạn có thể có một công việc tồn đọng duy nhất cho tất cả các hạng mục cho tất cả các dự án - hoặc một công việc tồn đọng cho mỗi dự án - và bạn chọn các hạng mục tồn đọng từ tất cả các dự án khi bạn lập kế hoạch một Sprint. Trong trường hợp này, Scrum "hoạt động" tốt.

Nếu mọi dự án đều có trách nhiệm của nó, thì bạn có thể gặp phải một số rắc rối mà mỗi người chịu trách nhiệm - ít nhiều sẽ có ý thức - cố gắng ủng hộ (các) dự án của mình. IMHO, bạn sẽ chỉ cần có một Chủ sở hữu sản phẩm có thẩm quyền giải quyết các ưu tiên bằng trọng tài.

Một quy tắc sẽ được tuân theo trong bối cảnh như vậy là không bao giờ thay đổi nội dung Sprint trong suốt Sprint . Nếu cần, bạn có thể rút ngắn thời gian lặp lại còn hai hoặc ba tuần để giảm nguy cơ phải thêm một mục khẩn cấp trong Sprint hiện tại.

Tôi phải không đồng ý. Tôi nghĩ rằng điều quan trọng của quá trình là có một nhóm tập trung vào một dự án duy nhất trong thời gian chạy nước rút. Nếu bạn có một số chuyên gia không thể đóng góp vào toàn bộ quá trình phát triển (tác giả nội dung, nhân viên đồ họa, nhà phân tích quy trình kinh doanh, v.v.), tôi sẽ loại họ khỏi nhóm khi họ không thể đóng góp nữa. Hoặc tốt hơn, hãy huấn luyện họ về một số nhiệm vụ khác nhau để họ có thể đóng góp vào những việc như thử nghiệm.

Một điều cần lưu ý nữa là việc chạy các dự án song song sẽ giết chết lịch trình của bạn. Hãy xem xét điều này: vì mục đích đơn giản, giả sử chúng ta có 5 dự án sử dụng cùng một nhóm và bắt đầu vào cùng một ngày. Mỗi dự án cần 3 một tháng nỗ lực, Trong trường hợp tốt nhất là chạy song song, bạn sẽ hoàn thành tất cả chúng cùng một lúc và sẽ mất 15 tháng. Vận tốc của bạn sẽ trở nên khó khăn vì bạn chỉ có thể hoàn thành 1/5 nỗ lực của một tháng trong một lần chạy nước rút. Bạn cũng sẽ thực hiện 5 cuộc họp demo cùng một lúc. Vì vậy, trường hợp tốt nhất, bạn giao 5 dự án của mình trong 15 tháng và đối thủ cạnh tranh của bạn sẽ tuyên bố rằng họ có thể làm công việc tương tự trong 3. Nhóm của bạn ước tính sự trưởng thành sẽ bị ảnh hưởng bởi vì họ sẽ chỉ có thể xem xét 20% lao động hiện có của họ. Bạn có thể thấy rằng bạn thực sự không thể thực hiện một số nhiệm vụ trong một lần chạy nước rút. Nếu bạn phải thay đổi số lượng dự án đang thực hiện từ 5, nhóm của bạn sẽ phải điều chỉnh thói quen ước tính của họ, điều này sẽ làm hỏng hiệu quả của nhóm. Ngoài ra, nhóm của bạn sẽ gặp khó khăn trong việc tự tổ chức khi việc phân công lại một nhiệm vụ đơn giản có thể yêu cầu tạo ra một môi trường phát triển mới trước khi công việc có thể bắt đầu.

Nếu bạn chạy cùng 5 dự án nối tiếp nhau, bạn sẽ giao dự án thứ 5 trong cùng 15 tháng, nhưng bạn sẽ thông báo cho khách hàng của mình rằng nhóm của bạn có nhu cầu đến mức bạn có 12 tháng tồn đọng và bạn có thể sử dụng thời gian đó để tinh chỉnh các mục tiêu dự án của bạn. Hoặc nếu bạn có một công việc tồn đọng liên tục, bạn biết rằng đã đến lúc bắt đầu thuê một đội khác. Tuy nhiên, dự án tốt nhất của bạn sẽ hoàn thành sau 3 tháng với một khách hàng đã có những cải thiện nhanh chóng trong thời gian hoạt động. Bạn có thể hoàn thành dự án đó sớm hơn một năm và có thể đưa nó vào sơ yếu lý lịch của mình. Tốc độ chạy nước rút của bạn sẽ ổn định trong khoảng thời gian đó và bạn có thể thấy rằng tốc độ đạt được sau một hoặc hai dự án và có thể hoàn thành nhiều hơn trong một nước rút nhất định.

Tôi nghĩ rằng việc điều hành các dự án nối tiếp nhau là một trong những trở ngại lớn nhất mà một tổ chức đang cố gắng chấp nhận những khuôn mặt thiếu sót. Đó là một sự thay đổi văn hóa lớn liên quan đến việc giải cấu trúc vai trò người quản lý dự án, nhưng lợi ích của quy trình scrum là rất lớn.

Hãy nhớ rằng MỌI NGƯỜI không cần phải là thành viên đầy đủ của nhóm. Họ có thể thu hút khách hàng của bạn trong phòng chờ, chuẩn bị cho quá trình phát triển. Tôi giữ các nhà phân tích kinh doanh, kiến ​​trúc sư mạng và thiết kế đồ họa của mình làm chuyên gia miền và chỉ gắn họ vào một nhóm khi cần thiết. Hãy để chúng chạy với sprint 0. Bạn sẽ ngạc nhiên làm việc trên giao diện và quy trình làm việc hấp dẫn như thế nào. Cũng tốt khi chuẩn bị cho khách hàng của bạn hiểu rằng khi sự phát triển bắt đầu một cách nghiêm túc, mức độ tham gia của họ có thể thực sự tăng lên và điều quan trọng là họ phải sẵn sàng. Hãy cho họ biết lịch trình để họ có nhiều thời gian giải quyết trước những việc như kỳ nghỉ và ngày lễ.

Tôi đã ở trong tình huống chính xác này.

Nếu bạn có một chủ sở hữu sản phẩm trong các dự án thì Phillipe hoàn toàn chính xác; Một sprint với một nhóm sẽ hoạt động tốt.

Nếu bạn có nhiều chủ sở hữu sản phẩm, thì lý tưởng nhất là phía doanh nghiệp cần chọn một 'người ưu tiên' duy nhất được giao trách nhiệm lên lịch công việc. Đây chắc chắn là giải pháp tốt nhất.

Nếu (có lẽ là trong trường hợp này) doanh nghiệp không muốn thay đổi cách họ muốn sắp xếp thứ tự ưu tiên (điều đó sẽ quá thuận tiện) thì bạn có thể chia nhóm, và chạy hai lần chạy nước rút đồng thời. Tuy nhiên với một đội sáu người, tôi sẽ không chia nó thành nhiều hơn 3 đội (tôi không muốn chia nó ra chút nào, nhưng tôi nghĩ rằng 2-3 đội sẽ khả thi). Việc tách ra xa hơn như Kenny gợi ý, và có các nhóm của một người duy nhất đối với tôi dường như hơi vô nghĩa, vì khi đó bạn không còn có một nhóm nữa, chỉ là các lập trình viên riêng lẻ.

Nếu bạn đang tách nhóm, tôi không tìm thấy nhiều giá trị trong việc hợp nhất các nhóm đứng, trừ khi bạn có các sprint riêng biệt làm việc trên rất nhiều cơ sở mã giống nhau, nhưng đó có thể là một lý lẽ để hợp nhất các nhóm đó với mục đích chạy nước rút.

Có một ý kiến ​​khác mà tôi đã đọc gần đây, đó là trong môi trường Agile, khái niệm Dự án có thể phản tác dụng và có thể bị loại bỏ. Theo dòng suy nghĩ này, thay vào đó , tổ chức nên tập trung vào Phát hành . Điều này là do Dự án là những hộp công việc nhân tạo không tạo ra giá trị gì cho đến khi chúng hoàn thành. Chúng đi ngược lại với mục tiêu của Agile là thường xuyên cung cấp giá trị có thể chuyển đổi. Bản phát hành phù hợp hơn với Agile vì nó hướng tới việc cung cấp giá trị và vì phạm vi của nó có thể được giảm bớt hoặc mở rộng dựa trên những gì mà nhóm có thể cung cấp trước Bản phát hành tiếp theo .

Có một nền tảng trung gian tiềm năng, trong đó những gì trước đây được gọi là Dự án trong công ty của bạn hiện được đóng gói lại dưới dạng Chủ đề hoặc Tính năng Agile thông thường . Lợi ích của cách tiếp cận này là Chủ đề hoặc Tính năng giờ đây có thể được triển khai theo từng phần giá trị, khi chủ sở hữu sản phẩm thấy phù hợp.

Vẫn còn đó câu hỏi về một nhóm làm việc trên nhiều Sản phẩm và đó là một câu hỏi vì những lo ngại chính đáng về kiến ​​thức miền và kỹ năng kỹ thuật có thể có. Nhưng các Sản phẩm được xây dựng bằng Agile, thậm chí nhiều Sản phẩm được xây dựng bởi một nhóm duy nhất, liên tục tích lũy giá trị Có thể phát hành . Ngược lại, các Dự án không có giá trị gì cho đến khi chúng hoàn thành (và nhiều dự án thì không).

Đôi điều suy nghĩ...

Tôi nghĩ anopres đã đúng: cách tốt nhất là tránh nhiều dự án cùng một lúc với scrum. Làm mọi thứ để kết luận rằng chạy song song quá nhiều là không hiệu quả.

Chúng ta hãy giả định 5 dự án, mỗi dự án khoảng 3 tháng cho nhóm 5 người.

Cách tiếp cận 1: mỗi người làm việc trong một dự án trong nhóm

• Tốc độ giao hàng 1/5 cho mỗi dự án cho 15 tháng giao nhà cho tất cả các dự án
• Mỗi người đều là chuyên gia nhưng chỉ trong dự án của riêng mình
• Không có tinh thần đồng đội

Tiếp cận sprint 2: 1 cho mỗi dự án, chuyển đổi các dự án

• Mỗi sprint thứ 6 làm việc trên dự án
• Thời gian quá dài giữa các công việc của dự án - không phải là giá trị gia tăng thường xuyên cho dự án (đối với sản phẩm tồn đọng có), dễ quên, cần nỗ lực để khôi phục ngữ cảnh,
• Dự án đầu tiên được giao sau khoảng 12-13 tháng (giả sử 2 tuần chạy nước rút)

Tiếp cận dự án 3: 5 trong một lần chạy nước rút

• Yêu cầu phân chia quá nhiều nhiệm vụ chi tiết chỉ để phù hợp với chạy nước rút
• Rất ít xây dựng gia tăng cho mỗi dự án
• Giao dự án đầu tiên sau khoảng 12-15 tháng

Phương pháp tiếp cận 4: được đề xuất - Công việc theo thứ tự

• Nhóm làm việc hết dự án này đến dự án khác
• Dự án đầu tiên khởi công và giao nhà sau 3 tháng
• Dự án thứ hai khởi công sau tháng thứ 3, giao nhà sau tháng thứ 6
• ...
• Dự án thứ 5 khởi công sau tháng thứ 12, giao nhà sau tháng thứ 15
• Nhóm tập trung cao độ vào dự án, nghiên cứu chuyên sâu và cộng tác với khách hàng
• Toàn bộ nhóm có kiến ​​thức chung tốt về tất cả các dự án
• Không lãng phí thời gian chuyển đổi ngữ cảnh
• Yêu cầu hợp tác nhóm tốt (xung đột có thể làm chậm quá trình giao hàng).

Như bạn thấy, giải pháp 4 thường tốt hơn vì các dự án được thực hiện nhanh hơn nhiều, nhóm làm việc cùng nhau và hiệu quả. Các cách tiếp cận khác bao gồm lãng phí thời gian do chuyển đổi ngữ cảnh, không có sự cộng tác đầy đủ của nhóm, tổng thời gian phân phối của tất cả các dự án rất dài, v.v.

Và những gì về chải chuốt tồn đọng? Nếu nhóm làm việc trên một dự án cùng một lúc thì điều đó đơn giản - mọi người sẽ tham gia. Nếu có nhiều dự án, chúng tôi có thể cần phải ủy quyền cho những người đơn lẻ tham gia các phiên chải chuốt riêng biệt (không tham gia đầy đủ nhóm).

Điều quan trọng là phải thuyết phục khách hàng rằng bắt đầu dự án thứ 2 sau 3 tháng sẽ vẫn giao hàng nhanh hơn (sau tháng thứ 6) hơn là nếu chúng tôi bắt đầu nó ngay lập tức với tất cả những người khác. Đó là một ảo tưởng mà các nhà quản lý nhìn thấy - chúng tôi bắt đầu 5 dự án cùng một lúc, chúng tôi làm việc chăm chỉ và giao từng chút một. Tuy nhiên, cuối cùng điều này không hiệu quả.

Đó là lý do tại sao tôi không tin rằng scrum hiệu quả cho nhiều dự án song song, rất khó để ghép nó vào khuôn khổ và hoạt động theo các quy tắc của scrum. Đôi khi có thể tốt khi có 2 dự án để giữ tất cả mọi người ở lại, nhưng chúng ta càng thêm nhiều dự án vào thì sẽ càng kém hiệu quả. Có lẽ kanban là một giải pháp thay thế chỉ để xem tiến độ và làm việc nhóm (không quá mạnh như trong nhóm Scrum)?

Trân trọng, Adam

Như @Chris đã nói, một dự án bình thường có các dự án con bên trong. Bạn chỉ có một công việc tồn đọng.

Suy nghĩ trong công việc tồn đọng với tất cả các dự án của bạn. Vấn đề đầu tiên: bạn có đang phân công ưu tiên cho các nhiệm vụ hay dự án không? Tôi thích một tồn đọng cho mỗi dự án. Ít nhất phải có các ưu tiên rõ ràng mà chủ sở hữu sản phẩm có.

Có các chủ sở hữu sản phẩm khác nhau và do thực tế là các chủ sở hữu sản phẩm đó sẽ không thống nhất về thời gian họ nên dành cho mỗi dự án. "Ai đó" sẽ phải đưa ra quyết định về cách quản lý các ưu tiên của liên dự án. Lưu ý: các nhà phát triển không nên làm điều đó.

Ở đây, người quản lý dự án "S" của chúng tôi sẽ cân bằng giữa nguồn lực mà chủ sở hữu sản phẩm cần và thời gian mà các thành viên trong nhóm có thể cung cấp. Chủ sở hữu sản phẩm A đã trả tiền cho một tháng làm việc, nhưng chủ sở hữu sản phẩm B luôn cập nhật dự án của mình (và cũng trả lương cao cho bạn). Có một số cách bạn sẽ cân bằng nhóm của mình để A có một tháng (thời gian dành cho nhà phát triển) và không ngăn B làm đầy túi của bạn.

Trong trường hợp phần mềm nội bộ (một công ty, một nghìn dự án). Các chủ sở hữu sản phẩm khác nhau nên đồng ý về thời gian cho họ. Họ không sống biệt lập mà ở cùng thuyền với bạn (quản lý dự án "S"). Họ sẽ làm cho cuộc sống của bạn dễ dàng hơn có thể trì hoãn một số nhiệm vụ, nhưng đồng thời bạn không bao giờ được quên nhu cầu của họ.

Tôi vẫn đang cố gắng tìm ra cách tốt nhất để làm điều này. Nhưng đây là những gì chúng tôi đang thúc đẩy ngay bây giờ. Tôi hy vọng nó sẽ giúp.

Các thành viên trong nhóm có thể phân chia thời gian của họ giữa các dự án scrum, nhưng sẽ hiệu quả hơn nhiều nếu các thành viên trong nhóm hoàn toàn chuyên tâm. Các thành viên trong nhóm cũng có thể thay đổi từ nước rút này sang nước rút tiếp theo, nhưng điều đó cũng làm giảm năng suất của nhóm. Các dự án với các nhóm lớn hơn được tổ chức dưới dạng nhiều cuộc kiểm tra, mỗi cuộc tập trung vào một khía cạnh khác nhau của việc phát triển sản phẩm, với sự phối hợp chặt chẽ của những nỗ lực của họ.

Tôi khuyên bạn nên chạy một Sprint cho mỗi Dự án và có 1 cuộc họp dự phòng hàng ngày để xử lý tất cả các Springs / dự án đang hoạt động.

Tôi muốn đóng góp. Đây là cách tôi làm điều đó:

• Có một chủ sở hữu sản phẩm và một sản phẩm tồn đọng cho mỗi nhóm. Chủ sở hữu sản phẩm không nhất thiết phải là một người duy nhất, nhưng "pháp nhân" chủ sở hữu sản phẩm này chịu trách nhiệm về việc tồn đọng sản phẩm.
• Sản phẩm tồn đọng có các câu chuyện người dùng của mọi dự án (tất cả các dự án ở đây). Mỗi câu chuyện của người dùng đều có điểm nỗ lực / câu chuyện (trách nhiệm của nhóm) và giá trị kinh doanh (trách nhiệm của chủ sở hữu sản phẩm).
• Chúng tôi có cuộc họp "xử lý công việc tồn đọng sản phẩm" mỗi nước rút. Trước cuộc họp này, chủ sở hữu sản phẩm đã cập nhật các giá trị kinh doanh của các câu chuyện (nếu họ cần một số thay đổi vì bất kỳ lý do kinh doanh nào- mà chúng tôi không và không nên quan tâm-) và bao gồm một số câu chuyện mới. Trong cuộc họp này, những câu chuyện mới được giải thích và những nỗ lực cũng được cập nhật. Cuộc họp này kéo dài khoảng một giờ (trừ lần đầu tiên, khoảng 4 giờ).
• Khi chúng tôi định lên kế hoạch cho một cuộc chạy nước rút mới, chúng tôi mở phần tồn đọng của sản phẩm, sắp xếp các câu chuyện theo ROI (đây là giá trị / nỗ lực kinh doanh) và lập kế hoạch cho các câu chuyện cho đến khi hết thời gian.

Và đó là nó. Tôi có thể nói điều này hoạt động khá tốt. Chúng tôi sử dụng một vài bảng tính của google (sản phẩm tồn đọng và những bảng tính tồn đọng của sprint, cả với biểu đồ và nội dung) để thực hiện việc này và xác định lại (với một ngữ nghĩa cụ thể) cho một tổ chức trực tuyến mỗi ngày: thời gian, tiến độ nhiệm vụ, v.v.

Vấn đề với cách tiếp cận này là tôi đã sao chép các nhiệm vụ trong bảng tính tồn đọng của sprint và thực hiện lại. Nhưng tôi không tìm thấy bất kỳ công cụ trực tuyến nào để thực hiện việc này hoàn toàn trực tuyến. Tôi bỏ lỡ một sản phẩm tồn đọng trong redmine (không có tác phẩm ngữ nghĩa nào khác cho tôi), một bảng duy nhất ở jira, nhiều câu chuyện hơn ở taiga, etcetera