Scrum master có thể phân bổ nhiệm vụ không?

Chúng tôi đang theo dõi scrum trong dự án của chúng tôi. Tôi thấy hầu hết các lần chủ scrum phân bổ các nhiệm vụ cho chúng tôi. Tuy nhiên, tôi đã đọc từ nhiều cuốn sách scrum rằng scrum hoạt động theo cách khác (cách tiếp cận 'kéo') và các thành viên trong nhóm nhận các nhiệm vụ hoặc tính năng. Là chủ scrum giao nhiệm vụ là cách tiếp cận chính xác hay nó đi ngược lại ý thức hệ nhanh nhẹn?

Theo Điều khoản Wikipedia về Scrum , các nhiệm vụ của Sprint không được ScrumMaster chỉ định:

Nhiệm vụ trên tồn đọng nước rút không bao giờ được giao; thay vào đó, các nhiệm vụ được đăng ký bởi các thành viên trong nhóm khi cần thiết, theo mức độ ưu tiên đã đặt và các kỹ năng của thành viên trong nhóm. Điều này thúc đẩy việc tự tổ chức nhóm và mua nhà phát triển.

Hơn nữa, định nghĩa của ScrumMaster là anh ấy / cô ấy là người chịu trách nhiệm đảm bảo mọi người tuân theo các quy tắc của quy trình Scrum.

ScrumMaster Người chịu trách nhiệm về quy trình Scrum, đảm bảo nó được sử dụng đúng cách và tối đa hóa lợi ích của nó.

ScrumMaster không phân công nhiệm vụ, đơn giản và đơn giản. Nhóm tự tổ chức và quyết định ai sẽ làm việc theo quyết định của nhóm.

Đây là Scrum đúng. Tuy nhiên, nhiều tổ chức có thể sử dụng các biến thể của điều này.

Đó là cách nó hoạt động, nhưng như với tất cả những thứ hoạt động tuyệt vời trên lý thuyết ... nó không thực sự luôn hoạt động.

Có sự phụ thuộc, khách hàng muốn và trình điều khiển từ bên ngoài. Một số thứ chỉ cần được thực hiện trước khi bạn có thể làm việc trên tiện ích ưa thích mà mọi người muốn làm việc.

Có khả năng nhà phát triển cơ bản lái xe từ bên trong. Một số thứ chỉ khó và một số người chỉ tốt hơn. Chắc chắn, khi làm việc trong một dòng thời gian vô hạn tôi chỉ có thể cho phép bạn tìm ra nó; nhưng khi một việc gì đó phải hoàn thành thì giao cho người được đặt tốt nhất để hoàn thành công việc nhanh nhất và tốt nhất là người đó sẽ nhận được công việc.

Và sau đó là các vấn đề về tính cách như Scrum Master và / hoặc nhà phát triển kiểm soát quá mức, những người không thể tự buộc giày mà không được thông báo. Đội của tôi, ví dụ, có cả hai. Đơn giản chỉ cần làm việc tốt hơn cho mọi người bỏ qua thực tế nhỏ này về Scrum trong những trường hợp như vậy.

Nói cách khác, đừng chỉ làm điều đó vì quy trình nói lên. Làm những gì hoạt động. Vít phần còn lại.

Tất nhiên, sau đó còn có một thực tế cơ bản khác về sự tồn tại của con người .... có thể bạn thậm chí không biết Scrum Master thực sự là ai. Có lẽ đó không phải là người có danh hiệu đó. Có lẽ bạn thậm chí không có.

Không bao giờ.

Scrum hoàn toàn rõ ràng về điều này. Nhóm phát triển, với tư cách là một nhóm, chịu trách nhiệm hoàn thành các mục trong hồ sơ tồn đọng của Sprint. Họ cũng hoàn toàn kiểm soát cách họ tiến hành phát triển và không ai được phép nói với họ cách thực hiện.

Là một huấn luyện viên, Scrum Master thực sự có vai trò trong việc chỉ ra điều đó khi anh ta thấy Đội có nguy cơ bỏ lỡ các mục tiêu của Sprint vì bất kỳ lý do gì. Nhưng sau đó anh ta cần yêu cầu họ tìm ra cách họ sẽ đối phó với nó, và sau đó tránh ra.

Một cách tiếp cận khác có thể là để Nhóm hoàn thành Sprint, chịu trách nhiệm cho họ về việc thiếu kết quả và sau đó để nó được thảo luận trong Hồi cứu Sprint.

Giống như bất kỳ hệ tư tưởng nào, có những lúc cuốn sách quy tắc cần phải được vứt đi, hoặc cẩn thận bỏ qua.

Sử dụng một số đánh giá như những gì có vẻ thích hợp. Chỉ cần cẩn thận về việc ai đó trở thành người quản lý dự án thực tế - hoặc tệ hơn là bắt nạt mọi người làm những việc nhất định.

Có một sự khác biệt lớn giữa phân bổ nhiệm vụ bằng cách ra lệnh (bạn SALL làm X) và phân bổ theo thảo luận và thỏa thuận. Đôi khi thỏa thuận có thể ấm áp.

Sau đó, một lần nữa, có lẽ nhóm cần chỉ đạo ... thật khó để biết.

Tuy nhiên, tôi lo ngại về bất kỳ quy trình nào, khẳng định rằng bạn phải tuân theo quy trình để thư không có chỗ để ngọ nguậy hoặc phán xét. Quá trình như vậy là một thay thế cho suy nghĩ.

Theo ý kiến ​​của tôi, kẻ lừa đảo không nên làm điều đó, các thành viên trong nhóm nên tự mình nhận nhiệm vụ. Nếu người kiểm tra chỉ làm việc quản trị như trường hợp trong nhóm của chúng tôi thì không có vấn đề gì. Chủ scrum của chúng tôi đảm bảo bảng scrum giấy luôn đồng bộ với tệp excel. Vai trò của chủ scrum phải là một điều kiện thuận lợi cho chúng tôi, anh ấy / cô ấy đảm bảo rằng bạn có thể thực hiện công việc của mình mà không bị cản trở. Đây là cách chúng tôi làm việc. Bạn có biết tại sao máy chà sàn của bạn làm điều này? Có phải anh ấy là một người quản lý dự án sợ trở nên lỗi thời? Có phải anh ấy sợ đội sẽ không tự nhận nhiệm vụ? Nó có thể là một ý tưởng tốt để thảo luận về điều này trong quá trình hồi cứu.

Tôi đã là một bậc thầy trong cả hai loại môi trường (nơi tôi đã đẩy các nhiệm vụ đến các cá nhân và nơi các cá nhân thực hiện các nhiệm vụ).

Trong nhóm Push, các tài nguyên phát triển không thể thay thế cho nhau. Công việc Windows Client phải chuyển đến nhà phát triển windows và công việc web cho nhà phát triển web. Vì vậy, tôi đã có thể đẩy các nhiệm vụ đến các nguồn lực trong các phiên lập kế hoạch. Tôi cũng có thể lập kế hoạch năng lực cá nhân để biết khi nào nên ngừng đẩy.

Phương pháp kéo hoạt động tốt trên một nhóm trong đó bất kỳ nhiệm vụ nào có thể được chọn bởi bất kỳ tài nguyên nào. Nhưng, tôi không thể lập kế hoạch năng lực cá nhân trong phiên lập kế hoạch, thay vào đó tôi phải phụ thuộc vào vận tốc trung bình để biết khi nào là đủ. (Phải mất ~ 3-4 lần chạy nước rút trước khi chúng tôi có một ý tưởng tốt về vận tốc).

Tôi đã xem qua một bài viết thú vị phác thảo những ưu / nhược điểm của Push vs. Pull.