Tại sao và vì lý do gì mà các nhà phát triển có thể không thích Scrum hàng ngày? [đóng cửa]

Có những lợi thế trong việc giữ scrum hàng ngày, như:

1. Đội được phối hợp với nhau
2. Mọi người đều biết số lượng nhiệm vụ đã được thực hiện
3. Biểu đồ Burndown ngày càng hoàn thiện
4. Bảng nhiệm vụ được cập nhật
5. Nó không kéo dài đến thế, 15 phút sẽ không giết ai

Tuy nhiên, gần đây (sau 6 tháng triển khai và sử dụng scrum), tôi cảm thấy rằng các nhà phát triển của chúng tôi không thích scrum hàng ngày nhiều như vậy nữa. Mọi người chỉ cập nhật bảng nhiệm vụ, mà không giải thích đủ và có vẻ như họ đã chán nó. Tôi thấy rằng vì bất kỳ lý do gì, chúng tôi không giữ nó, họ sẽ trở nên cực kỳ hạnh phúc.

Tôi chỉ không biết những gì có thể sai với điều này. Có bất kỳ lý do được đề cập ở đâu đó cho những bất lợi mà "scrum hàng ngày" có thể có cho một nhóm không? Điều gì có thể là lý do cho các nhà phát triển mệt mỏi với scrum hàng ngày?

Tôi đã có kinh nghiệm tham gia vào một nhóm "SCRUM" với một số nhà tuyển dụng. Tôi nhận thấy rằng các nhà quản lý lấy "cuộc họp scrum hàng ngày" làm điểm chính của SCRUM và đặt nó làm mục tiêu, thay vì đặt nó cho mục đích của nó: nghĩa là để đạt được chu kỳ phát triển hiệu quả hơn .

Rất nhanh chóng, các cuộc họp 15 phút đã trở thành cuộc họp 45 phút, các cập nhật không hiệu quả vì mọi người sẽ bận ngáp và nghĩ "khi nào chúng ta có thể đi" thay vì lắng nghe người khác, và nó cũng sẽ phá vỡ thói quen của mọi người (ví dụ như tôi một người cú, và làm việc lúc 9 giờ sáng cho cuộc họp ngu ngốc này mỗi ngày là một lý do đủ tốt để tôi từ bỏ công việc).

Khi các nhà quản lý đưa ra một số ý tưởng có thể tốt nếu được áp dụng một cách chính xác và đưa nó đến mức cực đoan - họ sẽ nhận được điều ngược lại hoàn toàn với kết quả mà họ mong đợi. Cá nhân tôi nghĩ rằng tôi càng tham gia nhiều cuộc họp - tôi càng làm ít việc hơn. Tôi có 2 cuộc họp định kỳ một tuần trong lịch của mình và tôi thường bỏ qua một trong số chúng. Các cuộc họp là dành cho các nhà quản lý, hãy để các nhà phát triển thực hiện công việc của họ.

Tôi chắc chắn sẽ có rất nhiều người đam mê SCRUM sẽ nói "Nhưng nó thật tuyệt vời" - tốt, hãy lưu lại, tôi đã nghe tất cả.

Tôi sẽ thấy hàng ngày đứng lên nhàm chán và vô dụng nếu tôi cảm thấy có rất ít hoặc không có giá trị trong đó. Có một vài điều có thể làm giảm tiện ích của việc đứng lên hàng ngày.

• Thông tin được chia sẻ không bao giờ liên quan hoặc ảnh hưởng đến tôi dưới bất kỳ hình thức nào.
• Sự vắng mặt của quyền sở hữu đội và mọi người luôn làm việc trên các dự án của riêng họ.
• Sự vắng mặt của giao tiếp nhóm bên ngoài standup.
• Thiếu tiến bộ có thể nhìn thấy hoặc truyền đạt.
• Thiếu thông tin để chia sẻ.

Đây chỉ là trên đỉnh đầu của tôi, nhưng luôn có nhiều lý do có thể.

Có lẽ bạn chỉ nên hỏi thẳng các nhà phát triển tại sao họ dường như không quan tâm? Nếu bạn muốn giao tiếp nhiều hơn / tốt hơn thì nên bắt đầu với bạn.

Một số vấn đề gặp phải với các cuộc họp SCRUM hàng ngày:

• những người kéo dài quá lâu. Bạn không muốn bất kỳ anh chàng quản lý nào hàng ngày vì họ là nguyên nhân sâu xa của loại vấn đề này. Xem cách họ thường là những người sử dụng ghế (vâng, phải đứng lên vì những điều đó là để lôi kéo mọi người nhanh chóng)
• phải nghe về ai đó (hoặc 2 hoặc 3 nhà phát triển) mô tả bất kỳ vấn đề riêng lẻ nào mà anh ta gặp phải thay vì anh ta quyết định lên lịch một cuộc họp thực sự khác sau đó để thảo luận với những người liên quan
• giờ ngu ngốc. Những cuộc họp đó không cần phải diễn ra vào buổi sáng: bạn không nói về những gì bạn đã làm ngày hôm qua và quyết định những gì bạn sẽ làm hôm nay; bạn đang nói về những gì bạn đã làm giữa ngày cuối cùng và điều này và quyết định những gì bạn sẽ làm cho đến lần tiếp theo.
• thiếu quyền sở hữu ứng dụng cho các nhà phát triển. SCRUM hoạt động nếu các nhà phát triển không được coi là khỉ mã. Dấu hiệu đầu tiên của quá trình trở nên sai lầm là khi các nhà phát triển không phải là người đánh giá thời gian sẽ làm một cái gì đó.
• giờ ngu ngốc nữa. Nếu một phần của nhóm đã bắt đầu làm việc với một số thứ và "ở trong khu vực" khi hàng ngày xảy ra, nó sẽ trở thành một vấn đề. Một thời điểm tốt để có những thứ đó hàng ngày là khi không ai nên làm việc (ví dụ sau bữa ăn trưa, hoặc ngay trước khi bắt đầu một số cuộc thảo luận để có trong bữa trưa).

Thời gian là kẻ giết người đối với nhiều người. Các lập trình viên thích mã muộn, ngủ muộn và đến sau buổi sáng vội vã. Phải ở trong văn phòng vào một thời điểm cố định - quá sớm đối với họ. Và quá muộn cho những người khác có thể đến sớm hơn và bắt đầu làm việc.

Dòng chảy là một vấn đề khác. Một lập trình viên với một số tính năng sẽ làm việc đến tận đêm khuya, về nhà và trở lại sạc và sẵn sàng tiếp tục. Phải ngồi qua một cuộc họp với hầu hết các vấn đề không liên quan có thể khiến anh ta mất tập trung.

Quan sát của tôi là quá thường xuyên những cuộc họp này là để các nhà quản lý nhìn và cảm thấy như họ thực sự đang làm một cái gì đó chứ không phải là chúng hữu ích cho nhóm và dự án.

Ví dụ, một nhóm được chỉ định thực hiện một loạt các sửa lỗi ngắn trên các dự án khác nhau. Họ thực sự không làm việc theo nhóm mà là cá nhân. Tuy nhiên, vì chính sách của công ty / bộ phận bắt buộc, nên trưởng nhóm / quản lý sẽ tổ chức một cuộc họp hàng ngày. Tất cả những gì đã hoàn thành là dành ra hơn 15 phút cho một cuộc họp vô ích và giải quyết 15-30 phút mất tập trung và thiếu năng suất trước và sau cuộc họp.

Bây giờ, tôi đã thấy scrum được thực hiện tốt trong một dự án có thời hạn chặt chẽ và đòi hỏi rất nhiều sự phối hợp giữa những người làm việc trên nhiều lĩnh vực khác nhau. Trong bối cảnh đó, nó là một hệ thống tuyệt vời. Nhưng, trong bối cảnh "Chúng tôi đang có một cuộc họp bởi vì chúng tôi là một cửa hàng nhanh nhẹn và nhanh nhẹn và đó là những gì chúng tôi cho là sẽ làm" thực sự hấp dẫn.

Hãy chắc chắn rằng không ai độc quyền cuộc họp.

Nếu 4 của các nhà phát triển có được bài diển văn của họ ra khỏi con đường trong vòng 5 phút, và 10 phút tiếp theo được dành nghe các nhà lãnh đạo nhóm nghiên cứu chi tiết tất cả các tuyệt vời , tuyệt vời phát triển mới anh ấy thực hiện, hầu hết trong số đó là không phải như tuyệt vời cũng như tuyệt vời như anh ấy nghĩ, mọi người sẽ rất nhanh chán.

Đứng lại một lát và suy nghĩ về đội của bạn:

• Họ có làm việc hiệu quả không?
• Các nhiệm vụ đã hoàn thành đúng hạn?
• Là mã mạnh mẽ và được viết tốt?
• Đội có đảm bảo rằng không có gì rơi qua các vết nứt?
• Đội có tự phối hợp để họ không làm việc trùng lặp hoặc giẫm lên ngón chân của nhau không?

Nếu câu trả lời của bạn cho tất cả những điều này là "Có", có lẽ bạn nên xem xét lý do tại sao bạn muốn buộc công việc bận rộn như các cuộc họp hàng ngày, biểu đồ phát sinh và bảng nhiệm vụ trong nhóm của bạn. Nó có giá trị gì? Bạn có muốn tạo dữ liệu quan liêu chỉ để hưởng thụ hoặc bạn đang cố gắng làm cho nhóm làm việc hiệu quả hơn?

Đã có sự suy giảm năng suất kể từ khi các scrum hàng ngày dừng lại, hoặc mọi thứ đều ổn định như trước đây? Nếu không có gì thay đổi, tại sao tiếp tục các cuộc họp?

15 phút. Liệu 15 phút đó (cộng với thời gian chuẩn bị cho nó) có truyền tải đủ thông tin mới và hữu ích giữa các thành viên trong nhóm để cải thiện năng suất của đội cho ngày tới hơn 15 phút không? Nếu không có lượng nội dung scrum hữu ích mỗi ngày, các thành viên trong nhóm có thể nghĩ rằng họ sẽ tiến bộ hơn nhiều so với các mục tiêu nếu họ rời khỏi cuộc họp này càng sớm càng tốt và trở lại làm việc.

Nếu bạn chỉ muốn cập nhật bảng và biểu đồ thường xuyên, hãy đặt các bản sao nháp lên wiki.

Tôi đề nghị nếu bạn tổ chức cuộc họp Hồi cứu để xem "Điều gì diễn ra tốt đẹp" và "Điều gì không diễn ra tốt đẹp" và xem liệu các nhà phát triển có liệt kê cuộc họp Stand-up hàng ngày như một sự lãng phí thời gian không. Sau đó, bạn sẽ cần phải tổ chức lại nó một chút.

Kinh nghiệm cá nhân của tôi:

• Mục đích là để biết những gì chúng ta đang làm hôm nay và chúng ta đã ở đâu ngày hôm qua. Thay vì bám sát chương trình nghị sự, nó đi sâu vào một cuộc thảo luận kỹ thuật về các công cụ chặn giữa 2 người và 15 người còn lại trở nên nhàm chán. Xác định vấn đề nhưng thảo luận bên ngoài
• Mọi người không vào phòng họp đúng giờ và điều này trở thành một chu kỳ được thực hiện bởi một số người có chủ đích. Vì vậy, Scrum Master cần có một cuộc thảo luận lặng lẽ với họ bên ngoài cuộc họp để đảm bảo họ bắt đầu và kết thúc đúng giờ.
• Chúng tôi đã cập nhật các biểu đồ phát sinh bên ngoài cuộc họp Scrum để đó không phải là mục đích chính của việc đứng lên hàng ngày.

Cuộc kháng chiến diễn ra khi: 1) Chúng được sử dụng để buộc mọi người phải xông vào trong 9 giờ sáng. Căng thẳng thêm khi tàu trễ. 2) Lãnh đạo scrum kém. Người lãnh đạo nên nói với mọi người hãy bỏ qua mọi thứ thay vì để mọi người đứng xung quanh lắng nghe những điều không ảnh hưởng đến họ. 3) Nội dung vô giá trị. Đây lại là một vấn đề lãnh đạo scrum. Nó được cho là một diễn đàn để giải quyết các nút thắt, vấn đề quỹ đạo và sự hợp tác tiềm năng. Điều thực sự xảy ra là mọi người chỉ nói những gì họ mong đợi sẽ làm việc vào ngày đó mà không có ích gì cho bất kỳ ai khác. 4) Đứng. Tôi sẽ không đứng cho đứng. Logic đằng sau chỗ đứng là nó khuyến khích mọi người ngắn gọn. Mọi người thực sự chỉ rầm rộ trên bất kể.

Tôi đã quản lý và là một phần của các nhóm scrum nhiều lần. Lý do chính khiến các nhà phát triển không thích scrum là:

• Bởi vì chúng được điều hành bởi một bậc thầy scrum rất kém, nếu nó biến thành 45 phút, chủ scrum của bạn cần cải thiện việc kiểm soát scrum.
• Lý do lớn nhất và cho đến nay Lý do trung thực nhất tại sao họ không thích nó là bởi vì rất khó để che giấu trong một đạo đức công việc tồi tệ, tức là, một cách trắng trợn hơn, nó cho thấy những người lười biếng. Một số nhà phát triển mà tôi đã làm việc rất sốc, họ mất nhiều ngày để thực hiện các nhiệm vụ nên là công việc 30 phút. Một PM tốt sẽ loại bỏ các rào cản cho các nhà phát triển, điều đó có nghĩa là họ sẽ có thể cày xới các nhiệm vụ của mình trong giai đoạn nước rút. Các nhà phát triển không thích điều đó bởi vì họ phải đứng lên mỗi ngày và chứng minh sự tiến bộ mà họ đã đạt được. Nó gây ra sự lo lắng khi họ không thể chứng minh sự tiến bộ vì lý do gì. Nếu đó là do một vấn đề hợp lệ, một chủ scrum tốt sẽ giải quyết vấn đề đó càng sớm càng tốt.

Vấn đề xảy ra khi các bậc thầy scrum không có thẩm quyền, kỹ năng hoặc khả năng để giải quyết các vấn đề chặn. Trong thực tế, tôi đã thấy một số vấn đề chỉ chôn vùi với hy vọng rằng chúng sẽ biến mất. Điều này thật tai hại.

Thành thật mà nói, trong 99% các cuộc họp scrum hàng ngày tôi đã tham gia, gần như tất cả các cuộc thảo luận / câu hỏi / câu trả lời có thể đã được khắc phục bằng một vài email.

Tôi thành thật nghĩ rằng chúng ta cần đưa ra những lý do hợp lệ hơn để KHÔNG có cuộc họp. Xây dựng môi trường khi đến lúc phải trực tiếp đưa mọi người vào phòng, đó là lý do chính đáng và được tổ chức để tối đa hóa hiệu quả thời gian.

Tôi ghét các cuộc họp nói chung, và thích sử dụng hội nghị video, điện thoại, email, bất cứ điều gì cho phép tôi tham gia hoặc ở lại làm việc mà không phải thức dậy và làm gián đoạn dòng năng suất của tôi.

Cá nhân tôi nghĩ rằng nếu bạn có nhiều hơn bốn cuộc họp trong khoảng thời gian 8 giờ thì các dự án sẽ không được quản lý tốt.

Có nhiều yếu tố góp phần vào sự căng thẳng trong các cuộc họp. Hãy xem xét những điều này như một số lý do quan trọng tại sao các cuộc họp có thể khiến bạn tốn kém hơn giá trị của chúng:

• Tập trung - phần mềm so với các cuộc họp
• Quản lý - quản lý cần đo lường
• Tính cách - Người hướng nội so với Người hướng ngoại
• Thời gian - gián đoạn, thời gian Maker và Manager
• Mục tiêu, ưu tiên

Mỗi yếu tố được giải thích dưới đây,

Tập trung - Tôi thích phát triển phần mềm và bao gồm suy nghĩ về các thách thức (vấn đề), tạo giải pháp, xây dựng phần mềm và các cuộc họp làm mất tập trung vào các nhiệm vụ xây dựng phần mềm. Có một trạng thái gọi là " Dòng chảy " nơi một nhà phát triển đắm mình trong thử thách (vấn đề), đã xây dựng một mô hình tinh thần của giải pháp và hoàn toàn tập trung vào việc xây dựng giải pháp. Một nhà phát triển có thể làm việc đến nửa đêm, chỉ để ăn và ngủ, sau đó trở về trạng thái gần nơi họ rời đi.

Các nhà phát triển cần tránh phiền nhiễu, và nhiều người nhận thấy rằng có những lợi thế để mã hóa vào đêm khuya (họ tránh tiếng ồn, các cuộc gọi điện thoại, văn phòng bận rộn và các đồng nghiệp không phải là nhà phát triển làm gián đoạn công việc của họ). Và khi bạn đã làm việc đến 10, 11 hoặc 12 giờ tối thì không phải là không có lý khi đến làm việc muộn hơn (10, 11, trưa?). Có hợp lý không khi mong đợi các nhà phát triển làm việc từ 9 giờ sáng đến nửa đêm?

Các cuộc họp Scrum (và bất kỳ) nào làm phân tâm nhà phát triển khỏi mục đích chính của họ, đó là xây dựng phần mềm.

Quản lý - Người quản lý cần đo lường để thành công, do đó cần có lịch trình, việc giao hàng, thời gian biểu, ưu tiên và các cuộc họp để đo lường và báo cáo tiến độ, và phơi bày sự phụ thuộc, chậm trễ và các khu vực rủi ro. Thách thức với Scrum là người quản lý cần những thứ này, nhưng nhà phát triển cần tập trung. Các cuộc họp phục vụ người quản lý và cung cấp một cách để người quản lý có được, đo lường và theo dõi tình trạng và tiến trình, nhưng các cuộc họp hiếm khi cung cấp tiện ích cho các nhà phát triển. Hãy xem xét rằng các nhà quản lý cung cấp nhiều giá trị hơn khi họ xử lý các phiền nhiễu, loại bỏ các rào cản và cho phép các nhà phát triển tập trung vào việc xây dựng phần mềm.

Có giải pháp cho nhu cầu họp. Người quản lý có thể truy cập nhà phát triển của họ, yêu cầu báo cáo trạng thái, áp dụng giao thức khi các gián đoạn ít xâm phạm hơn hoặc áp dụng chính sách mà nhà phát triển thông báo cho họ về tiến trình khi nhà phát triển bị gián đoạn. Xem các cuộc thảo luận về thời gian tại sao điều này là quan trọng.

Tính cách - Hãy xem xét rằng một số người là người hướng nội và những người khác là người hướng ngoại. Người hướng ngoại thích các tương tác xã hội và được họ sạc lại. Người quản lý thường là người hướng ngoại (vì người hướng ngoại thường tốt hơn với các tương tác xã hội), mặc dù người hướng nội có thể thành công với tư cách là người quản lý. Người hướng nội có thể tận hưởng và thậm chí nổi trội ở các tương tác xã hội, nhưng được nạp lại bằng sự cô độc. Các nhà phát triển thường là người hướng nội và làm việc thành công một mình (hoặc trong các nhóm nhỏ) vì họ không "cần" các tương tác xã hội; họ có thể vui vẻ làm việc một mình trong các vấn đề (mặc dù người hướng ngoại cũng có thể là nhà phát triển). Các cuộc họp scrum hàng ngày có thể trở thành các cuộc tụ họp xã hội, tốt cho người hướng ngoại, nhưng không tốt cho người hướng nội.

Thời gian - Nhà phát triển không thể viết mã khi họ đang họp. Họ cũng không thể nghĩ về những vấn đề khó khăn (trừ khi họ đang động não), trong khi bị phân tâm bởi các cuộc họp. Các nhà phát triển cần khối lớn thời gian không bị gián đoạn để tập trung vào xây dựng phần mềm. Các cuộc họp là sự gián đoạn làm mất tập trung từ những nỗ lực của họ. Khi bạn mải mê giải quyết vấn đề trong nhiều giờ, gần xong, và ai đó nói "thời gian dành cho scrum", bạn bị gián đoạn và mất có lẽ hàng giờ làm việc trong khi "chuyển bánh răng". Hoặc bạn đã ở lại làm việc đến 11:00 tối, nghỉ làm, về nhà, ngủ với vấn đề, thức dậy, trở lại làm việc để sẵn sàng giải quyết vấn đề, và sau đó bị gián đoạn sau một giờ làm việc với một vấn đề, bởi vì nó là "thời gian cho scrum".

Paul Graham có một bài viết tuyệt vời về Thời gian sản xuất so với Thời gian quản lý, giải thích vấn đề này tốt hơn nhiều so với tôi. Đủ để nói rằng một cuộc họp bị gián đoạn, cho dù có kế hoạch hay không có kế hoạch đều có thể phá vỡ dòng chảy và buộc nhà phát triển từ thời gian của Nhà sản xuất vào thời gian của Người quản lý. Hãy tin tôi, bạn muốn các nhà phát triển về thời gian của Maker.

Mục tiêu, ưu tiên - Nhà phát triển và nhà quản lý có các mục tiêu và ưu tiên khác nhau. Các nhà quản lý có trách nhiệm theo dõi lịch trình, giảm thiểu chi phí, đảm bảo rằng các báo cáo của họ có trách nhiệm và họ thực hiện. Các nhà phát triển có mục tiêu xây dựng phần mềm giải quyết các thách thức / vấn đề. Những mục tiêu này không có xung đột, nhưng chính cơ chế truyền thông tạo ra sự căng thẳng. Các cuộc họp phục vụ nhu cầu của người quản lý và tối ưu hóa thời gian của người quản lý, nhưng họ mâu thuẫn với nhu cầu của nhà phát triển. Các cuộc họp của Scrum loại bỏ quy tắc đầu tiên của các cuộc họp, "có một chương trình nghị sự" và có xu hướng đi lang thang nhiều hơn. Và các cuộc họp được sử dụng để tối ưu hóa giao tiếp (cho người quản lý), nhưng chúng làm mất thời gian của nhà phát triển (gián đoạn, mất lưu lượng, v.v.).

Mục tiêu là gì? Để xây dựng phần mềm đáp ứng nhu cầu, nhanh chóng và có chất lượng, trong khi các hạn chế là (chất lượng, thời gian, chi phí, quy trình). Scrum và các phương pháp nhanh nhẹn khác nhận ra ràng buộc quy trình và cố gắng giảm thiểu yếu tố đó và đã thành công vì chúng giảm thiểu ràng buộc đó. Nhưng việc thêm các cuộc họp làm tốn thời gian và sự gián đoạn khiến nhà phát triển tốn nhiều thời gian hơn so với thời gian của cuộc họp.

Sửa đổi cuộc họp để đảm bảo nó mang lại lợi ích:

1. Lịch trình tại một thời điểm cung cấp một số thuận tiện. Tại sao không thể là 30 phút sau khi công việc bắt đầu để mọi người có thể xem lại email và sắp xếp suy nghĩ của họ cho cuộc gặp gỡ. Brevity có kế hoạch. Sự không chuẩn bị có thể lan man mãi mãi.
2. Xác định các vấn đề có thể tránh được có một vấn đề đã được truyền đạt trong cuộc họp. Mọi người cần phải hiểu điểm là gì.
3. Làm bất cứ điều gì cần thiết để giữ cho đầu vào của mọi người ở mức tối thiểu. Đây không phải là nơi để tranh luận. Khuyến khích mọi người lên lịch riêng cho các cuộc họp bên ngoài cuộc họp hàng ngày tập trung vào một chủ đề cần thảo luận. Quy tắc: chỉ một người nói chuyện tại một thời điểm.

Tất cả những người khiếu nại cần đảm bảo rằng họ không góp phần vào vấn đề. Nếu bạn có thể hoàn thành mục tiêu của mình cho scrum hàng ngày mà không cần phải có một cách ít đau đớn hơn, chúng tôi muốn nghe điều đó.