2009-06-26 27 views
81

Tôi có một khởi động khá nhỏ và chúng tôi bắt đầu sử dụng một hình thức của một chu kỳ phát triển Scrum/Agile.Có thể xảy ra sự kiệt sức khi chạy liên tục Scrum không?

Bằng nhiều cách tôi thích Scrum. Chúng tôi có chạy nước rút tương đối ngắn (2 tuần) và tôi thích Burn Down Chart để theo dõi tiến độ của đội. Tôi cũng thích Hội đồng năng lực nên tôi luôn biết tôi nên làm gì tiếp theo. Nó cảm thấy tốt lấy xuống thẻ của một tính năng từ hội đồng quản trị, hoàn thành nó và sau đó đặt nó trong đống ghi xuống.

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

Đối với những người làm việc trong 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ì đó? Có thời gian bình thường trong một môi trường Scrum chưa được gán/không được sửa lại để hoàn thành một số điều nhỏ nhặt và để xóa đầu của bạn?

+0

Tôi sẽ xem xét kỹ hơn nội dung của lần chạy nước rút nhiều hơn phương pháp. Phát triển thuần túy (không thử nghiệm, đột biến, đánh giá mã) có thể giết người sau một thời gian. Ngoài ra, chủ nhân scrum nên bảo vệ đội chống lại lộ trình không hợp lý, ước tính thời gian từ đội ngũ ... Trong quá trình tính sẵn có, hãy đảm bảo bạn chiếm 10-20% thời gian không cam kết để giải quyết các cuộc họp đột xuất, phá vỡ phòng tắm, phiền nhiễu, v.v. Sau đó lên kế hoạch cho bất kỳ và mọi thứ trong các buổi lễ. Tất cả đều cân bằng cuối cùng. – Sinaesthetic

+11

nếu điều này không mang tính xây dựng, nơi nào trong hệ sinh thái Stackexchange tốt nhất nên được đặt? –

+2

Có thể http://programmers.stackexchange.com ... không chắc chắn. –

Trả lời

62

Điều này tương đối bình thường và đôi khi có thể là khiếu nại của các thành viên trong nhóm 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 đến ở đâ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 bạn trong thời gian dài, điều đó thật tuyệt vời - bạn đã đạt được mức độ siêu năng lực mà tất cả các đội Scrum đang phấn đấu. Ngoài ra, nếu bạn thấy rằng bạn đánh giá quá cao công việc bạn thực sự có thể thực hiện 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 tưởng của bạn. Số lượng thời gian sản xuất trong một ngày mà một nhóm chọn để nhận ra khi lập kế hoạch dung lượng cho chạy nước rút được gọi là yếu tố trọng tâm .

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

Các “mặc định” yếu tố trọng tâm tôi sử dụng cho độ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ì có vẻ như bạn đang nói về chỉ đơn giản là động lực không ngừng nghỉ của chạy nước rút sau khi nước rút, không nhất thiết năng suất của bạn trong một ngày. Dưới đây là một số đề xuất về những điều chúng tôi đã cố xử lý:

  • Kết thúc chạy nước rút vào sáng thứ Sáu. Hãy xem xét và hồi tưởng chạy nước rút của bạn vào buổi sáng và để cho nhóm làm việc trên một cái gì đó khác trong phần còn lại của ngày để xóa đầu của họ. Bắt đầu với kế hoạch Sprint vào thứ Hai.
  • Chúng tôi đã giới thiệu khái niệm "ngày làm việc". Đây là toàn bộ ngày mà nhóm được đưa ra khỏi dự án và họ dành cả ngày làm việc để cải thiện kỹ năng kỹ thuật của mình thông qua nghiên cứu với nhau và cộng 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 có gì để làm với dự án cụ thể và cho phép các thành viên trong nhóm suy nghĩ về các chủ đề nhẹ hơn.
+3

Kniberg tự nói: "yếu tố tiêu điểm là một trong những điều tôi muốn tách ra khỏi cuốn sách. Ngưng sử dụng nó ngay sau khi viết cuốn sách ..." - https://twitter.com/henrikkniberg/status/207853426967715841 – MPV

7

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ỉ có hai tiếng rưỡi chạy nước rút, phần còn lại trong ngày tập trung vào nhiều hoạt động khác: hỗ trợ, giảm nợ kỹ thuật, nghiên cứu, v.v. được thiết lập cho phù hợp.

Điều đó có vẻ hơi khắc nghiệt, nhưng nếu tôi không nhầm thì đó là một công ty có lợi nhuận cho đến khi cú sốc kinh tế lan rộng gần đây.

+0

Tôi nghĩ rằng ngay bây giờ chúng tôi được thiết lập tại 6 giờ chạy nước rút mỗi ngày. Có lẽ đó chỉ là một chút quá nhiều. – mmcdole

+0

Nó có thể không giống như rất nhiều, nhưng tôi thấy rằng nó là một sợi dây khá chặt chẽ để đi bộ. Nếu không có vấn đề thực sự xảy ra trong ngày bạn có thể duy trì nó tốt, nhưng nếu bạn nhấn một snag nó phá hủy vận tốc của bạn cho ngày hôm đó. – mmcdole

+0

Nhóm của tôi lập kế hoạch trên cơ sở 5 giờ làm việc mỗi ngày. Và TBH Tôi nghĩ rằng 4,5 giờ có lẽ sẽ phù hợp với chúng ta tốt hơn. Vì vậy, tôi nghĩ rằng 6 giờ sản xuất mỗi ngày * là * rất nhiều. –

9

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

4

Bạn đang ở nước rút thứ 18 của mình !?

Xem xét 2 tuần cho mỗi lần chạy nước rút, có nghĩa là 36 tuần không ngừng hoạt động trên cùng một dự án. Bạn cũng bình luận rằng công 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ề phương pháp nhanh (mặc dù chúng tôi đang thực sự sử dụng Scrum trong dự án hiện tại), nhưng có nguyên tắc về giờ làm việc của bạn (ý tôi là, lượng thời gian bạn thực hiện công việc) nên 60% ~ 70%. Bây giờ, làm lại con số, nếu ngày lao động của bạn dài 8 giờ, và bạn dành 6 giờ làm việc, bạn thực sự dành khoảng 75% thời gian lao động của bạ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 để hoàn thành, chạy nước rút phải lớn hơn, không phải 2 tuần, nhưng không phải một tháng. Hãy xem xét một đường cong xuống trên biểu đồ cháy của bạn: Bắt đầu chạy nước rút của bạn với một nhiệm vụ thường xuyên đốt cháy, và giảm hoạt động của bạn trên 2 hoặc 3 ngày qua trước khi chạy nước rút kết thúc. Agile không phải là một hòn đá với khắc: "làm việc nhanh hơn/mạnh hơn/tốt hơn/khó hơn", nó giống như một bầu trời xanh với những đám mây trắng đọc: "làm việc tốt đẹp, đẹp hơn hiệu quả". (một chút lol vào cuối lịch sự của daft punk + radiohead).

2

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

Có vẻ như bạn cần thay đổi đối với chuỗi chạy nước rút bất 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 số lần chạy nước rút X, một thành viên trong nhóm (hoặc cặp) có thể xoay vòng một đội. Trong vòng quay của bạn, bạn có thể hỗ trợ nhóm điều hành, tham gia lớp học, tập trung vào một nhóm các lượt tăng đột biến, đi nghỉ mát, v.v.

Nếu nhóm có 5 cặp và bạn xoay người ra khỏi đường, Một người có thể một vòng quay tắt 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 phải được lãnh đạo và đối tác kinh doanh của bạn giải quyết. Nhưng rõ ràng, có một số thời gian để "làm sắc nét cưa" sẽ mang lại lợi ích cho đội do đó dự án. Giữ cho đội bóng mới mẻ và tập trung là một điều rất tốt. Nhưng chúng ta phải nhớ, chúng ta đang được trả tiền và chúng ta cần mang lại giá trị cho đồng đô la chúng ta kiếm được.

+2

Có lẽ họ không nên gọi nó là Sprint sau đó, eh? Họ nên gọi nó là Lập. –

12

Bạn sẽ bị 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 con người! Scrum không có mặt ở đó để giúp bạn làm việc chăm chỉ hơn, ở đó để giúp bạn làm việc một cách nhất quán hơn và có khả năng dự đoán cao hơn. Tôi thường thấy mọi người bối rối các triệu chứng của quản lý dự án bình 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 (tức là "khách hàng tiếp tục thay đổi yêu cầu - đó phải là lỗi của Scrum!").Đó là một sự khác biệt quan trọng mặc dù bởi vì không xác định nguyên nhân bạn không thể điều trị các triệu chứng. Cá nhân tôi đang tìm cách để giảm sự kiệt sức như kỹ thuật quản lý căng thẳng. Có rất nhiều thông tin trên mạng về cách thành công trong một môi trường căng thẳng.

8

Nhóm mà tôi hiện đang làm việc để giải quyết vấn đề này thực sự độc đáo. Sau ba lần chạy nước rút, chúng tôi có một tuần mà mỗi nhà phát triển có thể làm việc theo những gì anh ta muốn. Những dự án phụ đó phải đượ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 chúng tôi phát triển để 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, thư giãn hơn.

Điều này chắc chắn sẽ giúp tôi không bị đốt cháy.

11

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

Nhóm của bạn có tiến hành xem xét 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à một ScrumMaster, tôi thường xuyên yêu cầu Nhóm đánh giá cách Đội thực hiện 'cảm thấy', và nếu họ đang vui vẻ. 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 thích (lên đến giới hạn) 'áp lực' mà cột mốc Sprint hạn chế. Điều quan trọng là để tiếp cận, nhưng không vượt quá, khu vực đó. Khi cần thiết, hiệu chỉnh vùng đó là một điểm kiểm tra chính trong một hồi cứu. Đối với "... thời gian trong một môi trường Scrum chưa được gán/không được thực hiện để thực hiện một số điều nhỏ nhặt và làm rõ đầu của bạn", giữ cho Đội cam kết ở mức x% công suất khả dụng (điểm, tốt nhất là, nhưng giờ có thể được sử dụng nếu cần, trong cả hai trường hợp tôi tìm thấy thứ gì đó trong khoảng 60-70% có vẻ là chuẩn) là chìa khóa để phát triển bền vững bên trong Sprint và thỉnh thoảng 'ngày mã miễn phí' hoạt động tốt cho Sprints bên ngoài.

+17

Có lẽ họ không nên gọi nó là Sprint sau đó, eh? Họ nên gọi nó là Lập. –

+3

Tôi tin rằng họ gọi nó là Sprint để ngăn những người bên ngoài nhóm can thiệp. Một Sprint nghe có vẻ như bạn không nên ngắt lời. –

+0

Một vòng đua không có nghĩa là mục tiêu, nó chỉ là một trong nhiều hơn nữa, một chạy nước rút xác định một 'chạy đến một mục tiêu' mà một 'chạy nước rút' cuối cùng là. Thuật ngữ âm thanh IMHO – Jakub

18

Từ Wikipedia trên kiệt sức: "kiệt sức phần lớn là một vấn đề tổ chức do đầu tư thời gian dài, ít thời gian xuống, và ngang liên tục, khách hàng, và giám sát cao cấp"

Họ cũng có thể có một hình ảnh biểu tượng của Scrum tiếp theo với định nghĩa của sự kiệt sức.

Nếu bạn nghĩ rằng bạn có thể gửi một người nào đó lên một thứ khác để chuyển hướng ngắn gọn để khắc phục tình trạng kiệt sức, rõ ràng bạn không nghĩ đến điều đó. Bao giờ đi nghỉ sau khi bị đốt cháy và trở lại làm việc suy nghĩ, Wow! Bây giờ tôi đã được làm mới và sẵn sàng cho 6 tháng tra tấn này cho đến khi tôi cuối cùng đượ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 hút. Bây giờ tôi thực sự có thể thấy cách quản lý vi mô của người quản lý ngu ngốc của tôi, quá trình phát triển chỉ là một cách để nhận được nhiều hơn của tôi vì ít hơn và cuộc sống quá ngắn cho điều này ... Tôi nên tìm một việc khác để làm hoặc thay đổi công việc .

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

+2

Điều này là vô lý FUD, Scrum chắc chắn không phải là về việc có người bị đốt cháy, chạy nước rút ngắn không phải là về làm việc 80 mỗi tuần. –

+1

Xin lỗi vì đã đến trễ. Nhưng chính xác. –

+0

Theo tôi, Scrum thực sự làm giảm cơ hội của tôi cho một kiệt sức. Chỉ vì nhóm tự tổ chức và tự quản lý, nhóm chịu trách nhiệm về các ước tính và công việc mà kế hoạch chạy nước rút. Tôi không bỏ lỡ những ngày mà 'các nhà quản lý' ưu tiên các yêu cầu của họ ở trên bất kỳ ai khác. Hoặc nơi 'các nhà quản lý' yêu cầu tôi làm 'điều nhỏ nhặt' này cho họ. Ngoài ra, Scrum định nghĩa một ngày làm việc bình thường phải là 7 đến 8 giờ cho một 'nhà phát triển' và không ai nên 'quản lý' nhóm hoặc theo dõi tiến độ của nhóm (ngoại trừ chính nhóm đó). Scrum buộc các 'nhà quản lý' (hay các bên liên quan) thực sự ưu tiên. – Nullius

5

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 mình đồng ý rằng tốc độ luôn là vấn đề khi mọi người bị đốt cháy bởi quá trình này. Mặc dù theo dõi tất cả các tiến bộ của bạn là một điều tốt, nó cũng có thể là một yếu tố căng thẳng (và không theo dõi có thể là tốt), không chỉ vì ông chủ của bạn/PM sẽ được vào bạn nếu họ thấy một cái gì đó sẽ không theo kế hoạch, nhưng cho chính mình. Chỉ cần có thông tin đăng nhập này là một cái gì đó S W làm cho hầu hết mọi người làm việc chăm chỉ hơn một chút so với bình thường thì TẤT CẢ THỜI GIAN và tôi không chắc chắn đặt nhiều thời gian hơn vào ước tính thời gian của bạn sẽ khắc phụ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 đồ ghi của bạn) luôn luôn là 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ẽ làm như vậy. Không có một cách làm việc nào S fit phù hợp với tất cả. Sẽ không bao giờ, theo ý kiến ​​của tôi.

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

Hiệu quả/năng suất luôn đi kèm với một số loại giá, theo ý kiến ​​của tôi. Nó không bật lên từ hư không chỉ bằng cách sử dụng các phương pháp ma thuật (nếu bạn nhận được quan điểm của 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 khôn ngoan) và làm ít việc hơn là làm cho người khác làm công việc hoặc bằng cách tự động hóa nó.

Theo ý kiến ​​của tôi, người ta phải luôn xem lại các quy trình đó và xem những gì có thể được tự động hóa và dành thời gian tự động hóa quy trình của bạn thay thế. Tự động hóa đi kèm với giá làm thêm công việc thay vì làm "công việc thực sự" nhưng không có vấn đề làm thế nào nhỏ nhiệm vụ tự động bạn sẽ luôn luôn lợi nhuận trong thời gian dài. LUÔN LUÔN! Nếu không phải một ngày, trong hai ngày. Không một tháng, hai. Không 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 việc trên 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 mặc dù. Nhưng có lẽ bạn có thể thuyết phục chủ nhân của bạn có được thời gian để tự động hóa quy trình của bạn và công việc này có thể là "ngoài tầm kiểm soát chạy nước rút" để cho phép thời gian bạn đang nói "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 cảm thấy hơi sợ khi mọi người nói những phương pháp này không có ở đây để làm cho chúng ta 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 những gì bạn đang làm bạn sẽ nghỉ ngơi khi cơ thể của bạn nói với bạn. Khi "mọi thứ" bạn làm là truy tìm, bạn sẽ tự đẩy mình. Hoặc tôi sửa bản thân mình, hầu hết mọi người làm việc theo cách này, một số sẽ nghỉ ngơi.

2

Tôi nghĩ bạn đang thiếu điều 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 là thước đo hiệu suất năng lực mà nó dự định), tập trung quá nhiều vào khối lượng điểm câu chuyện được giao.”

I ' d đoán đó là những gì đang xảy ra với nhóm của bạn. Tôi khuyên bạn nên đọc bài đăng chủ đề IMHO của Highsmith này: Velocity is Killing Agility!

Các vấn đề liên quan