Có thể kiệt sức khi thực hiện Scrum sprint liên tục không? [đóng cửa]

Tôi với một công ty khởi nghiệp nhỏ và chúng tôi bắt đầu sử dụng một dạng của chu trình phát triển Scrum / Agile.

Theo nhiều cách, tôi thích Scrum. Chúng tôi có những chặng nước rút tương đối ngắn (2 tuần) và tôi thích Biểu đồ Burn Down để theo dõi sự tiến bộ của đội. Tôi cũng thích Bảng tính năng vì vậy tôi luôn biết mình nên làm gì tiếp theo. Cảm giác thật tuyệt khi gỡ thẻ của một tính năng khỏi bảng, hoàn thành nó và sau đó đặt nó vào đống ghi.

Tuy nhiên, hiện tại chúng tôi đang bước vào chu kỳ phát hành Sprint thứ 18 của mình và tôi bắt đầu cảm thấy hơi kiệt sức. Không phải tôi không thích công việc hay đồng nghiệp của mình, mà chỉ là những pha chạy nước rút này ... à , nước rút . Từ đầu đến cuối, tôi thực sự cảm thấy như đang chạy đua với đồng hồ để duy trì tốc độ phát triển của chúng tôi. Khi hoàn thành sprint, chúng tôi dành một ngày để lập kế hoạch cho bộ tính năng và ước tính của sprint tiếp theo, sau đó chúng tôi bắt đầu lại.

Đối với những người làm việc trong một quy trình phát triển Agile / Scrum trưởng thành, điều này có bình thường không? Hay chúng ta đang thiếu một cái gì đó? Thông thường có thời gian nào trong môi trường Scrum không được chỉ định / không được kiểm soát để hoàn thành một số việc nhỏ và giải tỏa đầu óc của bạn không?

Điều này là tương đối bình thường và đôi khi có thể là phàn nàn của các thành viên trong nhóm của chúng tôi nếu các dự án tiếp tục trong một thời gian dài.

Chìa khóa cho những gì chúng ta đang nói ở đây là tốc độ bền vững . Nếu bạn và nhóm của bạn có thể duy trì tốc độ của mình trong thời gian dài, điều đó thật tuyệt vời - bạn đã đạt được siêu năng suất mà tất cả các nhóm Scrum đang phấn đấu.

Ngoài ra, nếu bạn nhận thấy rằng bạn đánh giá quá cao số lượng công việc bạn thực sự có thể hoàn thành trong một ngày, thì bạn có thể cần phải đánh giá lại điều đó trong quá trình hồi cứu của mình. Lượng thời gian làm việc hiệu quả trong một ngày mà một nhóm chọn để ghi nhận khi lập kế hoạch năng lực cho một cuộc chạy nước rút được gọi là yếu tố trọng tâm .

Henrik Kniberg có điều này để nói:

Hệ số tập trung "mặc định" mà tôi sử dụng cho các đội mới thường là 70%, vì đó là nơi mà hầu hết các đội khác của chúng tôi đã kết thúc theo thời gian.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Tuy nhiên, những gì nghe có vẻ như bạn đang nói chỉ đơn giản là động lực chạy nước rút không ngừng sau khi chạy nước rút, không nhất thiết là năng suất của bạn trong một ngày. Dưới đây là một số gợi ý về những điều chúng tôi đã cố gắng giải quyết vấn đề đó:

• Kết thúc nước rút vào sáng thứ sáu. Hãy xem xét và kiểm tra lại sprint của bạn vào buổi sáng và để nhóm làm việc khác vào phần còn lại của ngày để giải phóng đầu của họ. Bắt đầu với kế hoạch Sprint vào thứ Hai.
• Chúng tôi đã đưa ra khái niệm "ngày phòng thí nghiệm". Đây là toàn bộ những ngày mà nhóm không phải là dự án và họ dành cả ngày để cải thiện kỹ năng kỹ thuật của riêng họ thông qua nghiên cứu với nhau và hợp tác về các chủ đề kỹ thuật cụ thể. Hầu hết thời gian họ hoàn toàn không liên quan gì đến dự án cụ thể và cho phép các thành viên trong nhóm nghĩ về những chủ đề nhẹ nhàng hơn.

Từ Wikipedia về kiệt sức: "kiệt sức phần lớn là một vấn đề tổ chức gây ra bởi thời gian dài, thời gian ngừng hoạt động ít và liên tục giám sát ngang hàng, khách hàng và cấp trên"

Họ cũng có thể có một hình ảnh biểu tượng của Scrum bên cạnh định nghĩa của kiệt sức.

Nếu bạn nghĩ rằng bạn có thể cử ai đó làm việc khác để chuyển hướng ngắn gọn để khắc phục tình trạng kiệt sức, thì rõ ràng là bạn chưa nghĩ kỹ. Hãy từng đi nghỉ sau khi kiệt sức và quay lại làm việc với suy nghĩ, Chà! Bây giờ tôi đã khỏe lại và sẵn sàng cho 6 tháng tra tấn nữa cho đến khi cuối cùng tôi được nghỉ ngơi một lần nữa. Không, những gì xảy ra là bạn nhận ra, Wow! Công việc của tôi tệ quá. Bây giờ tôi thực sự có thể thấy cách quản lý vi mô, quá trình phát triển của người quản lý ngu ngốc của tôi chỉ là một cách khác để giúp tôi tận hưởng nhiều hơn với chi phí thấp hơn và cuộc sống quá ngắn ngủi cho điều này ... Tôi nên tìm việc khác để làm hoặc thay đổi công việc sang một thứ gì đó ít căng thẳng hơn .

IMHO, Scrum ngắn 2 tuần nên bị cấm trừ với liều lượng nhỏ, không quá 4-8 liên tiếp. Sử dụng nó như một công cụ cho những việc đặc biệt hoặc quan trọng, không phải liên tục. Sử dụng suy nghĩ thông thường.

Bạn đang dần kiệt sức sau 36 tuần làm việc chăm chỉ; đó không phải là Scrum, đó là bản chất của con người! Scrum không ở đó để khiến bạn làm việc chăm chỉ hơn mà ở đó để giúp bạn làm việc ổn định hơn và có khả năng dự đoán cao hơn. Tôi thường thấy mọi người nhầm lẫn các triệu chứng của quản lý dự án thông thường với những gì họ nhận thấy là các triệu chứng của phương pháp nhanh nhẹn (nghĩa là “khách hàng liên tục thay đổi yêu cầu - đó phải là lỗi của Scrum!”). Đó là một điểm phân biệt quan trọng vì nếu không xác định được nguyên nhân thì bạn không thể điều trị các triệu chứng. Cá nhân tôi đang xem xét các cách để giảm kiệt sức chẳng hạn như các kỹ thuật quản lý căng thẳng. Có rất nhiều thông tin về cách thành công trong một môi trường căng thẳng.

Nhóm mà tôi hiện đang làm việc giải quyết vấn đề này thực sự tuyệt vời. Sau ba lần chạy nước rút, chúng tôi có một tuần để mỗi nhà phát triển có thể làm việc theo những gì mình muốn. Những dự án phụ đó nên được liên kết với giá trị kinh doanh, nhưng không có áp lực để hoàn thành nó. Đó là một biện pháp cho phép các nhà phát triển chúng tôi khám phá các công nghệ mới, nhưng nó cũng cung cấp cho chúng tôi một tuần làm việc thoải mái và vui vẻ hơn.

Điều này chắc chắn giúp tôi không bị kiệt sức.

Bất kể bạn đang sử dụng quy trình phát triển nào, nếu nhóm đang bị kiệt sức thì điều gì đó không ổn. Nó có thể đơn giản là mọi người không dành thời gian nghỉ phép mà họ cần, hoặc nó có thể nằm ở chi tiết cách bạn xử lý những vấn đề khó khăn của mình. Các nhóm hoạt động hiệu quả về lâu dài vì mọi người đều nhận được phần còn lại mà họ cần trong suốt quá trình.

Sprint không phải là một đường gạch ngang 100 yard; nó là một (ngẫu nhiên) dặm trong cuộc chạy marathon, tức là một tốc độ mà bạn có thể duy trì vô thời hạn.

Nhóm của bạn có đang tiến hành điều tra lại vào cuối mỗi Sprint không? Đây là cơ hội của Nhóm để "kiểm tra và điều chỉnh" quy trình của họ? Với tư cách là ScrumMaster, tôi thường xuyên yêu cầu Nhóm đánh giá xem Nhóm như thế nào với tư cách là một thực thể 'cảm thấy' và họ có vui vẻ không. Chúng tôi khám phá lý do tại sao hoặc tại sao không và thử nghiệm với các điều chỉnh và lựa chọn thay thế.

Theo kinh nghiệm của tôi, các thành viên trong Nhóm tận hưởng (tối đa một giới hạn) 'áp lực' mà hộp thời gian Sprint hạn chế. Điều quan trọng là phải tiếp cận, nhưng không vượt quá khu vực đó. Khi cần thiết, việc hiệu chỉnh vùng đó là một điểm kiểm tra chính trong quá trình hồi cứu.

Đối với "... thời gian trong môi trường Scrum không được chỉ định / không được giám sát để hoàn thành một số việc nhỏ và để giải tỏa đầu óc của bạn", hãy giữ cam kết của Nhóm ở mức x% khả năng hiện có (tốt nhất là điểm, nhưng có thể dùng giờ nếu cần; trong cả hai trường hợp, tôi nhận thấy điều gì đó trong phạm vi 60-70% dường như là tiêu chuẩn) là chìa khóa cho sự bền vững bên trong Sprint và thỉnh thoảng 'ngày viết mã miễn phí' hoạt động tốt cho các Sprint bên ngoài.

Một giải pháp là giảm số giờ trong ngày dành cho chạy nước rút.

Tôi biết một số người có ngày làm việc chỉ vỏn vẹn hai tiếng rưỡi chạy nước rút, thời gian còn lại trong ngày tập trung vào nhiều hoạt động khác: hỗ trợ, giải tỏa nợ kỹ thuật, nghiên cứu, v.v. Tốc độ phát triển của họ đã được thiết lập tương ứng.

Điều đó có vẻ hơi cực đoan, nhưng nếu tôi không nhầm thì đó là một công ty có lãi cho đến khi cú sốc kinh tế lan rộng gần đây xảy ra.

Bạn đang ở nước rút thứ 18 !?

Xem xét 2 tuần cho mỗi sprint, điều đó có nghĩa là 36 tuần làm việc không ngừng nghỉ cho cùng một dự án. Bạn cũng nhận xét rằng làm việc khoảng 6 giờ mỗi ngày. Đó là rất nhiều âm thanh!

Tôi không biết nhiều về các phương pháp luận nhanh nhẹn (mặc dù chúng tôi đang thực sự sử dụng Scrum trong dự án hiện tại của mình), nhưng có một nguyên tắc về giờ làm việc của bạn (ý tôi là, lượng thời gian bạn dành để thực hiện một nhiệm vụ) phải là 60%. ~ 70%. Bây giờ, hãy làm những con số một lần nữa, nếu một ngày lao động của bạn dài 8 giờ và bạn dành 6 giờ làm việc, thì bạn thực sự đang tiêu tốn khoảng 75% thời gian lao động của mình. Điều này có thể là một chút sai lệch cuối cùng đã khiến bạn có cảm giác đó.

OTOH, tôi tin rằng nếu dự án của bạn sẽ mất nhiều thời gian để thực hiện, thì thời gian chạy nước rút nên lớn hơn, không phải 2 tuần mà không phải một tháng. Xem xét một đường cong đi xuống trên biểu đồ kiệt sức của bạn: Bắt đầu chạy nước rút của bạn với việc ghi nhiệm vụ thường xuyên và giảm hoạt động của bạn vào 2 hoặc 3 ngày cuối cùng trước khi nước rút kết thúc.

Agile không phải là một viên đá có khắc: "làm việc nhanh hơn / mạnh mẽ hơn / tốt hơn / chăm chỉ hơn", nó giống như bầu trời xanh với những đám mây trắng có ghi: "làm việc tốt đẹp, năng suất cao hơn". (một chút lol ở cuối lịch sự của daft punk + radiohead).

Tôi hoàn toàn hiểu những gì bạn đang nói. Đối với những người bạn nói rằng "tốc độ của bạn quá nhanh", tôi không chắc tôi đồng ý rằng tốc độ luôn là vấn đề khi mọi người bị kiệt sức bởi quá trình này. Mặc dù việc theo dõi tất cả tiến trình của bạn là điều tốt, nhưng bản thân nó cũng có thể là một yếu tố gây căng thẳng (và việc không theo dõi cũng có thể xảy ra), không chỉ vì sếp / PM của bạn sẽ theo dõi bạn nếu họ thấy điều gì đó không ổn. theo kế hoạch, nhưng cho chính bạn. Chỉ cần có thông tin được ghi lại này là điều SẼ khiến hầu hết mọi người làm việc chăm chỉ hơn bạn bình thường một chút MỌI LÚC và tôi không chắc việc đặt thêm thời gian vào ước tính thời gian của bạn sẽ khắc phục được điều này cho mọi người. Tôi không nghĩ rằng một động lực (như biểu đồ đốt cháy của bạn) luôn tích cực.

Một số người sẽ không cảm thấy như vậy, những người khác sẽ như vậy. Không có MỘT CÁCH LÀM VIỆC SẼ phù hợp với tất cả. Theo tôi thì sẽ không bao giờ.

Ngoài ra, nếu bạn nói rằng các phương pháp nhanh và nước rút này không trở nên hiệu quả / năng suất hơn, tại sao bạn lại sử dụng nó? Bạn nghĩ tại sao các công ty lại muốn sử dụng những phương pháp này? Không phải vì họ vui ...

Theo tôi, hiệu quả / năng suất luôn đi kèm với một số mức giá. Nó không xuất hiện từ đâu chỉ bằng cách sử dụng các phương pháp ma thuật (nếu bạn hiểu ý tôi).

Cách duy nhất để bạn trở nên hiệu quả hơn (công việc và áp lực) và làm ít công việc hơn là nhờ người khác làm công việc hoặc bằng cách tự động hóa công việc đó.

Theo ý kiến ​​của tôi, người ta nên luôn xem xét các quy trình đó và xem những gì có thể được tự động hóa và thay vào đó dành thời gian để tự động hóa các quy trình của bạn. Tự động hóa đi kèm với cái giá phải trả là làm thêm công việc thay vì làm "công việc thực sự" nhưng cho dù nhiệm vụ tự động nhỏ đến đâu thì bạn sẽ luôn thu được lợi nhuận về lâu dài. LUÔN LUÔN! Nếu không phải một ngày, trong hai. Không phải một tháng, hai. Không phải một năm, trong hai năm. Bạn có được ý tưởng.

Tuy nhiên, tôi thích ý tưởng có thời gian nghỉ để làm các dự án cá nhân. Hầu hết các công ty sẽ không bao giờ cho phép điều này. Nhưng có lẽ bạn có thể thuyết phục nhà tuyển dụng dành thời gian này để tự động hóa các quy trình của bạn và công việc này có thể "nằm ngoài tầm kiểm soát của nước rút" để cho phép thời gian bạn đang nói đến "nghỉ ngơi" và lấy lại năng lượng cho một cuộc chạy nước rút mới.

Đó chỉ là 2 xu của tôi. Tôi hơi lo sợ khi mọi người nói rằng những phương pháp này không giúp chúng tôi hiệu quả hơn và làm việc chăm chỉ hơn. Tất nhiên họ! Khi bạn không có dấu vết của việc bạn đang làm, bạn sẽ nghỉ ngơi khi cơ thể yêu cầu. Khi "mọi thứ" bạn làm được truy nguyên, bạn sẽ thúc đẩy bản thân. Hoặc tôi tự sửa lại, hầu hết mọi người đều làm việc theo cách này, một số sẽ nghỉ ngơi.

Tốc độ bền vững là nguyên lý chính của nhanh nhẹn. Khi thực hiện các phương pháp quản lý (SCRUM) cùng với các phương pháp kỹ thuật (XP), một nhóm có thể thực hiện sprint sau sprint vô thời hạn. Tuy nhiên, bởi vì một có thể không có nghĩa là một nên.

Có vẻ như bạn cần một sự thay đổi so với chuỗi nước rút vô tận mà bạn thấy trước mắt. Một số tùy chọn có thể được cung cấp. Mỗi X số lần chạy nước rút, một thành viên trong nhóm (hoặc một cặp) có thể thay đổi nhóm. Trong quá trình luân phiên của mình, bạn có thể hỗ trợ nhóm chạy, tham gia một lớp học, tập trung vào một nhóm gai, đi nghỉ, v.v.

Nếu đội có 5 cặp và bạn luân phiên một người ra khỏi hàng, Một người có thể thực hiện luân phiên sau mỗi lần chạy nước rút thứ 10 (nếu một người) hoặc mỗi lần lặp thứ 5 (nếu một cặp). Các vấn đề về ngân sách và lợi tức đầu tư cho các hoạt động của bạn sẽ cần được lãnh đạo và hoặc đối tác kinh doanh của bạn giải quyết. Nhưng rõ ràng, có chút thời gian “mài cưa” sẽ mang lại lợi ích cho đội như vậy dự án. Giữ cho đội luôn tươi mới và tập trung là một điều rất tốt. Nhưng chúng ta phải nhớ rằng, chúng ta đang được trả tiền và chúng ta cần mang lại giá trị cho số tiền chúng ta kiếm được.

Tôi nghĩ rằng bạn đang thiếu một cái gì đó, nhưng bạn không phải là người duy nhất. Như Jim Highsmith nói: “Vận tốc đang ngày càng được sử dụng như một thước đo năng suất (không phải thước đo hiệu chuẩn năng lực như dự định) tập trung quá nhiều vào khối lượng các điểm câu chuyện được phân phối.”

Tôi đoán đó là những gì đang xảy ra với đội của bạn. Tôi khuyên bạn nên đọc bài đăng trên IMHO của Highsmith: Vận tốc là sự nhanh nhẹn giết người!