Một số thành viên trong nhóm không tích cực tham gia lập kế hoạch Sprint

15

Một số thành viên trong nhóm chỉ cần đợi cho đến khi những câu chuyện mà họ có khả năng làm việc nhất sẽ được thảo luận và chỉ sau đó họ tham gia. Nếu không, họ chỉ chơi với điện thoại của họ và không nghe.

Theo một cách nào đó tôi hiểu vị trí này. Tại sao nghe một cuộc thảo luận về một tính năng mà bạn không thể giúp phát triển trong Sprint hoặc bao giờ?

Bạn nghĩ gì chúng ta nên làm gì?

agile scrum

— Eugene
nguồn

9

Đội này lớn cỡ nào?

— JeffO

8

@JeffO đánh vào đầu đinh - đây là một vấn đề kinh điển của đội quá khổ. Đội ngũ quá khổ = thẩm quyền / trách nhiệm cá nhân quá nhỏ = tham gia cá nhân quá nhỏ. Một đội có kích thước phù hợp sẽ có nghĩa là tất cả mọi thứ mà các bạn nói về hiệu ứng của mọi người trong phòng. Ngoài ra, bạn đang im lặng trách nhiệm quá nhiều - tại sao lại nghe một sự bất đồng về một tính năng mà bạn không thể giúp đỡ? Một nhóm có kích thước phù hợp, không có trách nhiệm về silo nên mọi người đều có khả năng làm việc trên mọi tính năng.

— Jimmy Hoffa

7

Điện thoại tắt, không có ngoại lệ. Cuộc họp đơn giản thông thường.

— user1019696

5

@ user1019696 để công bằng, tôi có thể nhận được một cuộc gọi từ vợ tôi rằng con tôi bị gãy chân bất cứ lúc nào. Có một sự khác biệt lớn giữa "tắt điện thoại" và "không được **** với điện thoại của bạn ở giữa cuộc họp, vì đơn giản là nó thiếu tôn trọng."

— Jimmy Hoffa

4

@jwenting bạn nói về một thời đại khi có thư ký công ty, không có người nào như vậy tại một công ty tôi đã làm việc trong nhiều năm - họ không có gì để làm. Và không, nó không thể chờ đợi. Đặc biệt không phải vì công việc, xin lỗi mà là gia đình> công việc. Điều đó nói rằng, tôi có thể nhận được một cuộc gọi vào giữa 1 trong 30 hoặc 40 cuộc họp (có thể ??) trong đó tôi có thể trả lời 1 trong 30 hoặc 40 ... Không khó để không bị giật điện thoại. Nếu mọi người cần họ vô hiệu hóa hoặc loại bỏ khỏi người của họ để tránh bị giật, có thể người đó chỉ là một kẻ ngốc.

— Jimmy Hoffa

32

Dừng quyền sở hữu mã. Làm cho nó có khả năng như nhau cho bất cứ ai trong một nhóm làm việc trên bất kỳ nhiệm vụ nhất định.

Gần như chắc chắn sẽ có một vài cú hích về điều đó, bởi vì các nhà phát triển cảm thấy thoải mái với một khu vực mã cụ thể và với những người khác không nhìn qua vai họ. Ngoài ra, quản lý sẽ thấy một vấn đề với công việc mất nhiều thời gian hơn bình thường, bởi vì luôn có một đường cong học tập.

Nhưng nó thực sự là lợi ích tốt nhất của mọi người. Không thể thiếu là con dao hai lưỡi. Bắt đầu trở nên khó khăn hơn để có thời gian nghỉ ngơi, vào buổi tối, cuối tuần hoặc nghỉ lễ. Và quyền sở hữu mã là không tốt cho một công ty bởi vì, khi ai đó rời đi, nó sẽ tốn nhiều thời gian hơn bạn đã từng tiết kiệm được khi chuyển giao kiến thức nhỏ.

— pdr
nguồn

4

+1 Hoàn toàn. Có một ấn tượng sai về hiệu quả khi bạn nghĩ rằng các lập trình viên chỉ là một phần khác của dây chuyền lắp ráp và sau đó tự hỏi tại sao một dự án được đặt lại bởi vì một trong những bánh răng cần phải được thay thế.

— JeffO

3

@JeffO, đó là khá nhiều tiêu chuẩn trong quản lý công ty phát triển phần mềm theo kinh nghiệm của tôi, coi các nhà phát triển là các bộ phận giống hệt nhau trong một máy có thể được trao đổi ngay lập tức cho một đơn vị carbon khác ...

— jwenting

3

@jwenting mà làm cho họ hoàn toàn phù hợp để được thuê ngoài, quá. Tôi không thấy lý do tại sao các nhà phát triển hỗ trợ trong thái độ này.

— GrandmasterB

1

@jwenting Đó là điểm nhanh nhẹn. Để thay đổi quan điểm này về mọi thứ.

— Euphoric

1

@Euphoric theo kinh nghiệm của tôi, kết quả cuối cùng là ngược lại, các nhà quản lý nhìn thấy mọi người thậm chí nhiều hơn như tài sản có thể được trao đổi ngay lập tức, như yêu cầu ...

— jwenting

15

Bạn có mời đúng người vào các cuộc họp của bạn? Nếu bạn đã chia hệ thống thành các khu vực chịu trách nhiệm cho các nhóm phụ, tại sao lại mời tất cả các nhóm phụ cho mọi cuộc họp? Lý tưởng nhất là mọi người nên làm việc trên tất cả mọi thứ, nhưng trong thực tế, điều đó thường không thực tế trừ khi hệ thống của bạn thực sự nhỏ và đơn giản, dẫn đến mọi người đều biết rõ mọi phần của nó. Trong thực tế, nhiều hệ thống đủ lớn để mong mọi thành viên trong tổ chức của bạn có đủ kiến thức về một nhiệm vụ được lên kế hoạch để có thể cung cấp đầu vào hợp lệ trong các phiên lập kế hoạch (chứ đừng nói là làm việc hiệu quả như nhau trên mọi bộ phận của hệ thống) chỉ là không thực tế.
Ví dụ: nếu bạn có một nhóm frontend và một nhóm phụ trợ, hãy giữ các phiên lập kế hoạch cho công việc frontend cho các thành viên của nhóm frontend. Có thể mời ai đó từ nhóm phụ trợ làm liên lạc trong trường hợp nhiệm vụ vượt qua ranh giới nhóm (nhưng nếu điều đó xảy ra thường xuyên, bạn có thể muốn đánh giá lại sự phân chia trách nhiệm giữa các nhóm của mình).

— jwent
nguồn

12

Sự không quan tâm của họ chỉ là một triệu chứng. Vấn đề là bạn không phân phối công việc đều cho tất cả các thành viên trong nhóm của bạn. Lý tưởng nhất là mọi thành viên trong nhóm nên chọn bất kỳ vé mới nào không bị giới hạn trong các khu vực dự án nhất định.

— Tom Squires
nguồn

3

Đó là lý thuyết tốt đẹp. Trong thực tế, đặc biệt là đối với các dự án lớn, hệ thống có thể đủ lớn để mọi thành viên trong nhóm có đủ kiến thức về mọi phần của nó để có hiệu quả khi làm việc với nó.

— jwenting

@jwenting - có vẻ như nhóm này rất chắc chắn họ sẽ không bao giờ được yêu cầu làm việc trên các phần khác. Mặc dù một người không thể biết tất cả mọi thứ, điều đó không có nghĩa là họ nên học ít nhất có thể.

— JeffO

@JeffO đúng, nhưng họ không thể mong đợi có thể tham gia tích cực vào việc lên kế hoạch cho những lĩnh vực mà họ không có kiến thức. Nghe và học, nhưng hãy im miệng. Và có thể sử dụng điện thoại di động của bạn để tạo một số hình ảnh của bảng kế hoạch :)

— jwenting

1

@jwenting trong thực tế trên các dự án lớn bạn cần phân phối công việc nhiều hơn! Không phải ai cũng có kiến thức giống nhau, nhưng họ có khả năng làm việc như nhau trên bất kỳ lĩnh vực cụ thể nào. Cho phép các lý do làm cho các thành viên trong nhóm có nhiều khả năng không chấp nhận các lĩnh vực mới.

— Dave Hillier

5

Nghe có vẻ như một vấn đề động lực - tại sao một số người không quan tâm đến dự án họ đang làm việc? Có lẽ đó là vì đội được chia thành 'ban tổ chức' và 'bên trái'.

Vì vậy, liên quan đến tất cả mọi người, thay vì 1 hoặc 2 người phụ trách các phiên lập kế hoạch, bạn thu hút tất cả mọi người - khiến những người khác nhau chịu trách nhiệm về mỗi phiên, tốt nhất là khiến những người khác nhau chịu trách nhiệm trong phiên. Xoay nó xung quanh. Tôi biết điều này có vẻ khó khăn bởi vì luôn có ai đó muốn làm phiền và tổ chức mọi người nhưng họ là vấn đề ở đây.

Đây là một ý tưởng: khi lập kế hoạch chọn một người ngẫu nhiên để chịu trách nhiệm cho mỗi câu chuyện. Ngẫu nhiên. Ghi lại người chịu trách nhiệm cho việc lập kế hoạch của nó, vì vậy lần chạy nước rút tiếp theo bạn có thể biết liệu họ có làm tốt công việc nhận được sự đồng thuận tốt về ước tính và phân chia nhiệm vụ hay không. Điều đó sẽ khiến họ chú ý và cũng sẽ cho họ một lý do để tham gia vào dự án.

Hãy nhớ rằng, vấn đề không phải là họ, đó là bạn và cách các phiên lập kế hoạch của bạn được thực hiện. Vì vậy, khi người khác tiếp quản một kế hoạch câu chuyện, họ sẽ chọn cách đi về nó nên có cách tiến hành chính thức. (tức là không ngồi lại và tiếp tục buộc tổ chức của bạn theo họ bằng proxy)

— gbjbaanb
nguồn

Ý tưởng tốt. Hy vọng mọi người sẽ không coi đây là sự lãng phí thời gian của họ.

— Eugene

1

Thời gian chạy nước rút của bạn là gì?

Thời gian chạy nước rút dài hơn dẫn đến

Nhiều công việc hơn để lập kế hoạch trong nước rút, dẫn đến
Các cuộc họp lập kế hoạch dài hơn, dẫn đến
Khó khăn cao hơn cho các thành viên trong nhóm để tập trung, ...
Các thành viên trong nhóm chán

Vì vậy, nếu thời gian chạy nước rút của bạn là hơn hai tuần, hãy thử làm việc trong những lần chạy nước rút ngắn hơn.

Nếu khó có thể khiến các bên liên quan cam kết chạy nước rút ngắn hơn, thì bạn có thể bỏ qua một số cuộc họp chính thức, ví dụ: chỉ có đánh giá nước rút sau mỗi 2 lần chạy nước rút, thay vì sau mỗi lần chạy nước rút.

— Pete
nguồn