Ai nên xác định, phân công, thực hiện và làm theo các nhiệm vụ trong Scrum?

10

Các vai trò trong scrum là Chủ sở hữu sản phẩm, Scrum Master và Nhóm Scrum. Một câu chuyện người dùng cũng nên chia thành các phần nhỏ hơn được gọi là nhiệm vụ. Một nhiệm vụ dường như có bốn giai đoạn, cụ thể là định nghĩa, phân công, thực hiện và sau đây.

Ai nên làm những gì trong Scrum về nhiệm vụ? Đây có phải là trách nhiệm của chủ scrum khi cập nhật số giờ còn lại của một nhiệm vụ hay là trách nhiệm của nhà phát triển (nhóm scrum)? Các nhà phát triển nên giao nhiệm vụ cho chính họ hay đó là trách nhiệm của chủ scrum đi kèm với chủ sở hữu sản phẩm?

— Saeed Neamati
nguồn

12

Agile tuân theo một số nguyên tắc. Một trong số đó là: Trao quyền cho mọi người. Do đó, các nhiệm vụ nên được xác định bởi nhóm và các nhiệm vụ nên được lựa chọn bởi các thành viên trong nhóm. Nhiệm vụ không nên được giao cho thành viên nhóm. Nhóm nên tự tổ chức và do đó phân phối các nhiệm vụ khó / dễ / thú vị / nhàm chán nên đồng đều.

Scrum master cần đảm bảo rằng nhóm tuân theo các nguyên tắc Scrum. Ông không phải là người quản lý dự án.

Đây là lý thuyết và nó hoạt động cho các đội trưởng thành. Đối với người mới bắt đầu Scrum đôi khi có thể khó khăn nhưng ít nhất bạn nên nhấn mạnh rằng các thành viên trong nhóm sẽ tự chọn nhiệm vụ thay vì chỉ định chúng.

cập nhật số giờ còn lại của một nhiệm vụ

Theo tôi ước tính nhiệm vụ và duy trì thời gian còn lại là lãng phí. Bạn đã cam kết về tập hợp các câu chuyện của người dùng, do đó, mỗi nhiệm vụ sẽ mất bao lâu. Điều quan trọng duy nhất là liệu câu chuyện của người dùng sẽ được hoàn thành hay không.

— Ladislav Mrnka
nguồn

3

Tôi không đồng ý rằng việc ước tính các nhiệm vụ và duy trì thời gian còn lại là một sự lãng phí. Tôi thấy rằng "thời gian còn lại" là dấu hiệu cảnh báo sớm tốt nhất bạn có thể nhận được khi mọi thứ bắt đầu bất ngờ. Nó không phải là siêu chính xác, nhưng chủ Scrum cần lưu ý nếu ước tính là A) không thay đổi hoặc B) tăng. Điều này thường có thể xảy ra nếu có một trở ngại ẩn (ngay cả đối với nhà phát triển). Trong một nhóm scrum mới, điều này cũng giúp cho tính minh bạch và giúp ngăn chặn "Tôi đã làm x ngày hôm qua, hôm nay tôi sẽ làm nhiều hơn x".

— Brook

@Brook: Đó là lý do tại sao Scrum sử dụng biểu đồ Burndown. Nếu bạn sử dụng biểu đồ phát sinh để hiển thị các câu chuyện của người dùng đã hoàn thành (với độ phức tạp được xác định bởi các điểm câu chuyện), bạn vẫn sẽ có phản hồi như vậy. Theo kinh nghiệm của tôi, phản hồi sẽ còn tốt hơn nữa vì bạn sẽ không kết thúc (ví dụ) với 10 giờ không hoàn thành công việc, điều đó có nghĩa là 10 câu chuyện của người dùng với mỗi 1 giờ bị thiếu.

— Ladislav Mrnka

Nếu tôi có thể tôi sẽ đưa ra câu trả lời này +10. Tại chỗ, hoàn toàn chính xác.

— wolfgangsz

@Ladislav Mrnka: Bạn sẽ nhận được dữ liệu tương tự từ việc ghi lại, nhưng công việc còn lại mang lại cho bạn chi tiết tốt hơn và có thể cảnh báo bạn sớm hơn. Đó là một điểm cần thiết nếu tất cả các nhiệm vụ của bạn mất <ngày, nhưng đôi khi khi một nhiệm vụ mất> 1 ngày, công việc còn lại có thể đưa ra một chỉ báo nhanh về việc có nên lo lắng hay không. Tôi thường không yêu cầu mọi người cung cấp cho nó rất nhiều suy nghĩ, bất kể ruột của họ là gì, vì vậy nó không quá phức tạp để thêm vào một số liệu.

— Brook

Sớm hơn? Nước rút nên "ngắn" - bạn nên được cảnh báo sớm hơn như thế nào? Tôi đã sử dụng quy tắc rất đơn giản. Nếu chúng tôi không có ít nhất 1/3 câu chuyện của người dùng (điểm câu chuyện) được thực hiện ở một nửa số lần chạy nước rút, rất có thể chúng tôi sẽ không thể cung cấp mọi thứ chúng tôi cam kết. Nó hoạt động khá tốt và chúng tôi không phải ước tính bất cứ điều gì. Với nước rút mất 2 hoặc 3 tuần, bạn không cần nhiều hơn nữa.

— Ladislav Mrnka

6

Các nhà phát triển nên giao nhiệm vụ cho chính họ hay đó là trách nhiệm của chủ scrum đi kèm với chủ sở hữu sản phẩm?

Tôi đặt những nơi tôi đã làm việc đã theo Scrum, chúng tôi đã thực hiện cả hai, mặc dù các nhà phát triển lý tưởng nên chọn nhiệm vụ của riêng họ. Cuối cùng, nó không thành vấn đề miễn là tất cả các nhiệm vụ được thực hiện.

Có những ưu và nhược điểm đối với từng phương pháp.

Để đội tự chọn:

ưu - nhóm cảm thấy quyền sở hữu của nhiệm vụ, họ chọn những người họ cảm thấy họ có thể làm tốt công việc. Quyền sở hữu là một khía cạnh quan trọng của sự phát triển mà rất nhiều người bỏ qua.
Nhược điểm - một số nhiệm vụ được để lại cho đến khi kết thúc khi chúng được thực hiện tốt hơn trước.

Có nhiệm vụ được giao:

ưu - tất cả các nhiệm vụ được coi là như nhau và không có gì có thể bị bỏ lại.
Nhược điểm - các thành viên trong nhóm không nhất thiết phải cảm thấy quyền sở hữu của nhiệm vụ.

Trong cuộc sống thực, bạn cần có một cách tiếp cận thực tế. Sẽ có lúc các nhiệm vụ phải được chỉ định, nhưng những điều này nên có ít.

— ChrisF
nguồn

+1 - cho ai đó có tiếng nói cuối cùng. Có người phải chịu trách nhiệm.

— JeffO

2

Tôi đánh giá cao rằng một chủ nghĩa thực dụng nhất định là một điều hữu ích, nhưng giao nhiệm vụ cho các nhà phát triển chắc chắn KHÔNG phải là cách làm của Scrum.

— wolfgangsz

@ChrisF: Bạn có thể làm rõ nơi Scrum nói rằng ScrumMaster có quyền kiểm soát và những người khác được phép phân công nhiệm vụ cho các nhà phát triển không?

— Martin Wickman

@Martin - không tôi không thể. Chủ yếu là vì đã được một thời gian kể từ khi tôi làm việc với Scrum. Tuy nhiên, người thực dụng trong tôi nói rằng đến một lúc nào đó sẽ có người phải đưa ra quyết định.

— ChrisF

Một chút muộn trong trò chơi, nhưng 2 của tôi - Tôi nghĩ rằng nếu một số nhiệm vụ còn lại đến cuối cùng thì chúng nên được thực hiện trước, điều đó có nghĩa là Scrum Master (và Chủ sở hữu sản phẩm) của bạn không nhấn mạnh đủ vào các nhiệm vụ đó.

— Wayne Werner

2

Trong quy trình scrum của chúng tôi, chúng tôi làm như sau:

Các tác vụ được xác định bởi nhóm các nhà phát triển, những người rất có thể sẽ thực hiện câu chuyện người dùng.

Ít nhất hai nhà phát triển chịu trách nhiệm triển khai câu chuyện của người dùng, do đó họ sẽ tự động được giao nhiệm vụ (nếu họ có thể làm việc song song, họ sẽ thực hiện một nhiệm vụ phù hợp nhất với họ theo kiến thức và sở thích cá nhân của họ. sẽ ghép chương trình).

— Benni
nguồn

2

Ai cập nhật số giờ còn lại của một nhiệm vụ?

Chỉ các nhà phát triển có thể biết bao nhiêu công việc còn lại, vì vậy họ cung cấp thông tin. Chính xác những người cập nhật giờ không quan trọng.

Các nhà phát triển có nên giao nhiệm vụ cho chính họ?

Đúng. Hành động chọn nhiệm vụ cho bản thân rất mạnh mẽ vì nó khiến bạn cam kết hoàn thành nó theo cách không thể nếu người khác giao việc đó cho bạn.

— Martin Wickman
nguồn

2

Hướng dẫn về Scrum

Mọi việc phải làm với các nhiệm vụ là trách nhiệm của nhóm trong Scrum. Nhóm nghiên cứu nói chung sẽ đưa ra một phân tách các câu chuyện thành các nhiệm vụ trong nửa sau của cuộc họp lập kế hoạch nước rút nhưng các nhiệm vụ mới có thể được đưa ra hoặc các nhiệm vụ có thể được loại bỏ bất cứ lúc nào trong giai đoạn nước rút khi thông tin mới được đưa ra ánh sáng. Theo tôi, vòng phản hồi hàng ngày này là một phần quan trọng của Scrum.

ScrumMaster không phải là trưởng nhóm hoặc người quản lý của nó. Vai trò của ScrumMaster là tạo điều kiện thuận lợi cho quá trình Scrum và loại bỏ các trở ngại. ScrumMaster không phân công nhiệm vụ cho nhà phát triển. Chủ sở hữu sản phẩm không giao nhiệm vụ cho nhà phát triển. Nhóm cung cấp giá trị cho chủ sở hữu produt (và bằng cách mở rộng khách hàng) bằng cách thực hiện các câu chuyện của người dùng.

Nhóm chịu trách nhiệm cho tất cả các ước tính. Vì vậy, nó sở hữu các ước tính cho các nhiệm vụ (và câu chuyện) trên bảng.

— Guy Sirton
nguồn