Làm thế nào để xử lý 50% tồi tệ hơn nước rút trung bình?


14

Nếu tôi hiểu chính xác Scrum, đây là cách tôi xác định công việc mà nhóm của tôi có thể đảm nhận trong lần chạy nước rút tiếp theo:

  1. Tôi trung bình số điểm hoàn thành trong nhiều lần chạy nước rút.

  2. Số lượng này là vận tốc trung bình của chúng tôi. Chạy nước rút tiếp theo, chúng tôi có nhiều điểm câu chuyện.

Đây là một mức trung bình , vì vậy nếu lịch sử lặp lại, lần chạy nước rút này có khả năng 50% là chúng ta đang đảm nhận quá ít điểm câu chuyện và 50% có khả năng chúng ta đang đảm nhận quá nhiều điểm câu chuyện.

Trong trường hợp 50%, chúng tôi đã thực hiện quá nhiều điểm câu chuyện có thể:

  • Không hoàn thành chạy nước rút. Điều này có nghĩa là chúng tôi sẽ không đáp ứng cam kết nước rút của chúng tôi một nửa thời gian.

  • Làm thêm để bắt kịp. Vấn đề là cái ratchets này chỉ có một cách. Chúng tôi sẽ hoàn thành chạy nước rút, và số điểm câu chuyện hoàn thành sẽ phản ánh điều đó. Vì chúng tôi luôn hoàn thành, theo thời gian, trung bình của chúng tôi sẽ có xu hướng tăng lên đến mức chúng tôi luôn hoàn thành một số lượng lớn các điểm câu chuyện và ở lại muộn.


Sự hiểu biết của tôi về các cam kết vận tốc và chạy nước rút trung bình có đúng không?

Nếu vậy, chúng ta nên làm gì cho 50% nước rút mà chúng ta đứng sau mức trung bình?

Nếu không, tôi đã nhận được những gì sai?


10
Về mặt lý thuyết, theo định nghĩa, 50% mọi thứ sẽ dưới mức trung bình. (Chà, một trong những định nghĩa về "trung bình", ít nhất.) Điều này được mong đợi, và không phải là điều đáng lo ngại. Đó chỉ là một vấn đề nghiêm trọng để lo lắng nếu bạn kém dưới mức trung bình.
Mason Wheeler

8
Tôi đồng ý với @MasonWheeler. Những gì bạn nên làm cho nước rút dưới mức trung bình một chút là ... tiếp tục với cuộc sống. Đó không phải là một vấn đề cần giải quyết. Tôi cũng không giống như thuật ngữ "thất bại trong nước rút" và "cam kết chạy nước rút". Cam kết nước rút là bạn sẽ hoàn thành công việc nhiều nhất có thể . Chỉ vì bạn không hoàn thành 100% số điểm ước tính không có nghĩa là bạn "không chạy nước rút".
Eric King

1
Vâng, những gì @EricKing đã nói, đặc biệt là trong thực tế nổi tiếng mà mọi người mút tay khi ước tính.
Mason Wheeler


1
@MasonWheeler: Việc 50% dưới mức trung bình không thực sự phụ thuộc vào định nghĩa trung bình mà phụ thuộc vào phân phối xác suất, cụ thể nó luôn đúng khi phân phối đối xứng. Theo định nghĩa, 50% dưới đây được gọi là trung vị.
Michael Borgwardt

Câu trả lời:


12

Sự hiểu biết của tôi về các cam kết vận tốc và chạy nước rút trung bình có đúng không?

Vâng, bạn có ý chính của nó.

Nếu không, tôi đã nhận được những gì sai?

Điều bạn bỏ qua là điểm câu chuyện là những điều bạn làm được . Không phải ai cũng có thể làm việc với những câu chuyện cho đến hết giai đoạn nước rút. Nếu bạn đang làm đúng, hầu hết các nhà phát triển của bạn sẽ "nhàn rỗi" trong vài ngày trong khi các câu chuyện đang được thử nghiệm (và những người thử nghiệm của bạn ở giữa giai đoạn nước rút khi sự phát triển đang hoàn tất).

Tôi đặt dấu ngoặc kép vì các nhà phát triển của bạn không ngồi xem video về mèo, họ đang sửa lỗi, đánh bóng một số bài kiểm tra mã / đơn vị, thêm một số tài liệu xung quanh các quy trình, suy nghĩ về thiết kế cho các câu chuyện tồn đọng hoặc một trong những hàng tá những điều hữu ích khác mà nhóm phát triển có thể hưởng lợi nhưng không phù hợp với câu chuyện.

Vì vậy, trong khi bạn sẽ đoán quá 50% thời gian và đoán dưới 50% thời gian, điều đó không có nghĩa là bạn sẽ thất bại trong việc chạy nước rút hoặc phải làm thêm giờ . Điều đó có nghĩa là bạn sẽ không có nhiều thời gian để làm công việc linh tinh này (trừ khi bạn thực sự bỏ lỡ ước tính của mình). Nhưng đó không phải là vấn đề lớn, vì công việc linh tinh không nhạy cảm với thời gian và mọi thứ thậm chí sẽ diễn ra trong thời gian dài.


Nếu tôi hiểu bạn một cách chính xác, liệu có thể hoàn thành tất cả các câu chuyện chỉ 50% thời gian không?
Paul Draper

@PaulDraper - không, tôi đang nói rằng bạn nên hoàn thành tất cả các câu chuyện của mình 100% thời gian ... hãy để tôi chỉnh sửa và xem liệu tôi có thể hữu ích hơn không.
Telastyn

1
@PaulDraper - điều quan trọng tôi đang nói là không mất đủ 10 ngày để hoàn thành tất cả các điểm câu chuyện đó. Luôn có một bộ đệm giữa khi công việc kết thúc và nước rút kết thúc. Đó là một bộ đệm sẽ chứa một số thời gian công việc của bạn mất nhiều thời gian hơn dự kiến.
Telastyn

Tôi ước tôi có thể trích dẫn câu trả lời này vài năm trước khi nhóm của tôi không hiểu chính xác phải làm gì trong ngày cuối cùng hoặc mỗi lần chạy nước rút. Vâng đặt. Cảm ơn.
MetaFight

3
AAAAGH! KHÔNG! "Nếu bạn đang làm đúng, các nhà phát triển của bạn sẽ không hoạt động trong khi thử nghiệm được thực hiện" là không chính xác! Bây giờ bạn đang làm thác nước nhỏ! Trong các nhóm hiệu suất cao, các nhà phát triển chia câu chuyện thành các phần chức năng nhỏ hơn có thể hoàn thành sau 1-3 ngày. Bạn muốn mã chức năng chảy ra để thử nghiệm và phê duyệt càng sớm càng tốt. KHÔNG CÓ EXCUSE cho "nhà phát triển nhàn rỗi". VẬY, bạn có các bài kiểm tra Đơn vị, Tích hợp, AUAT, tải / hiệu suất tự động tối ưu 100% không? Bạn có bản dựng tự động, triển khai tự động, mô hình Dev-Ops và CICD hoàn hảo? Nếu không, có rất nhiều để làm việc!
Curtis Reed

3

Sự hiểu biết của tôi về các cam kết vận tốc và chạy nước rút trung bình có đúng không?

Thật không may, bạn đã hiểu sai về một số điều liên quan đến Lập kế hoạch Sprint trong Scrum. Đầu tiên, Nhóm phát triển (DT) là

... được cấu trúc và trao quyền bởi tổ chức để tổ chức và quản lý công việc của chính họ. - Hướng dẫn về Scrum

Từ này là tự tổ chức. Điều này bao gồm công việc dự báo công việc sẽ được thực hiện trong một Sprint nhất định. DT không được cho biết những gì nó sẽ hoạt động trên mỗi lần chạy nước rút, nó được trao quyền để lựa chọn công việc của riêng mình. DT có thể cần thông tin như vận tốc lịch sử, tồn đọng Sản phẩm được tinh chỉnh tốt và khả năng DT của Sprint tiếp theo để tạo dự báo. Cuối cùng, đó là quyết tâm của DT về những gì có thể và không thể thực hiện được trong một Sprint sẽ chiếm ưu thế trong dự báo của họ; họ không nên nói họ sẽ làm bao nhiêu công việc.

Cũng thông báo, dự báo và không cam kết. Từ c đã bị xóa khỏi Hướng dẫn Scrum vì nó đang được sử dụng để lạm dụng Nhóm phát triển. Dự báo là thuật ngữ ưa thích.

Về khả năng bỏ lỡ dự báo Sprint ở cấp thấp hoặc cấp cao, tôi không thấy đó là tầm quan trọng. Tại một số điểm, phân tích nhiều hơn không mang lại độ chính xác tốt hơn và tôi nghĩ rằng chúng ta vượt quá thời điểm đó.

Ngoài ra, một Sprint chỉ có thể được "Hủy bỏ;" nó không bao giờ có thể thất bại. Một Sprint chỉ bị hủy khi mục tiêu chạy nước rút trở nên hoàn toàn lỗi thời và không liên quan. Điều này rất hiếm khi xảy ra. Nếu dự báo không chính xác, bạn chỉ cần giữ bình tĩnh và tiếp tục Scrum. Có bạn hồi tưởng. Sprint tiếp theo, dự báo của bạn sẽ tốt hơn :).


3

Đầu tiên, vận tốc của bạn là từ lần chạy nước rút trước đó của bạn, hoặc đôi khi từ mức trung bình của một vài Sprint gần đây (Thời tiết hôm qua), và không phải là trung bình của tất cả các lần chạy nước rút trước đây. Tất nhiên, nếu bạn không có dữ liệu lịch sử từ nhóm hoặc công ty của mình, bạn cần đưa ra một giá trị hợp lý cho lần chạy nước rút đầu tiên của mình. Ở lần chạy nước rút thứ hai, bạn lấy điểm câu chuyện đã hoàn thành vào giai đoạn nước rút. Nếu bạn đã vẽ biểu đồ này, bạn có thể thấy các biến thể trong một vài lần chạy nước rút đầu tiên (ví dụ: 17 trong lần chạy nước rút đầu tiên, 22 trong lần thứ hai, 26 trong lần thứ ba, 24 trong lần thứ tư). Đó là điều được mong đợi khi bạn bình thường hóa quy trình làm việc và ước tính nhóm của mình, cùng với việc hiểu rõ hơn về dự án (công nghệ, tên miền).

Điều đó không có nghĩa là bạn không điều chỉnh. Ví dụ: nếu bạn có một tuần là một tuần lễ, hãy chắc chắn tính đến kỳ nghỉ nơi công việc bị đóng cửa. Nếu bạn biết rằng các thành viên trong nhóm đang đi nghỉ, hãy lên kế hoạch cho ít người làm việc hơn. Tất nhiên, các sự kiện ngoài ý muốn cũng xảy ra, nhưng bạn có thể giải thích những sự kiện đó trong quá trình hồi tưởng nước rút và bạn có thể quyết định mức độ ảnh hưởng đến số điểm câu chuyện mà bạn đưa vào lần chạy nước rút tiếp theo.

Theo như những gì cần làm, "không hoàn thành chạy nước rút" khác với "chúng tôi đã không hoàn thành tất cả các câu chuyện". Đối với tôi, thất bại trong lần chạy nước rút có nghĩa là cuối cùng bạn không sản xuất một sản phẩm có thể chuyển đổi được - không có câu chuyện nào của bạn hoàn thành, bạn không có bản dựng, bạn không thể chứng minh bất kỳ giá trị gia tăng nào cho khách hàng hoặc người dùng.

Dù bạn làm gì, bạn không nên làm việc muộn hoặc quá nhiều theo thời gian. Đây được gọi là tốc độ bền vững ( Liên minh Agile , Liên minh Scrum ).

Các chỉ số có thể có vấn đề là:

  • Nhóm của bạn không làm việc một tốc độ bền vững. Bạn cần phải làm thêm giờ để hoàn thành các điểm câu chuyện được lên kế hoạch cho một lần chạy nước rút. Làm cho nước rút của bạn nhỏ hơn để hoàn thành đúng thời gian mà không có áp lực thêm.
  • Vận tốc của bạn không bình thường hóa theo thời gian. Không ai mong đợi vận tốc sẽ không bao giờ thay đổi, nhưng nếu bạn nhận thấy gai hoặc dao động, hãy đối phó với những người trong quá trình chạy nước rút của bạn. Tìm hiểu những gì gây ra chúng và giải quyết các nguyên nhân gốc rễ.

1

Phương pháp nhanh nhẹn khác nhau giữa các công ty, trong một lần thực hiện, nó có thể khác rất nhiều so với phương pháp khác. Tôi đã làm việc dưới Agile với hai công ty. Trong công ty đầu tiên tôi tham gia, họ rất coi trọng số liệu của họ, ở công ty thứ hai thì không thực sự như vậy. Vì vậy, đối với tất cả các bạn biết không ai chú ý đến số liệu của bạn.

Tất cả những gì đã nói, có vẻ như bạn quan tâm đến việc không đáp ứng các mục tiêu chạy nước rút của bạn hoặc điều gì xảy ra khi bạn có ước tính không chính xác. Tôi nghĩ loại quan tâm và triển vọng này là phổ biến, nhưng nó không đặc biệt quan trọng. Agile, trên hết, là một hệ thống phát triển phần mềm thực hiện một số điều:

  1. Giữ cho các nhà phát triển di chuyển
  2. Tăng tính minh bạch
  3. Cho phép phản ánh và cải tiến quy trình dần dần

Vào cuối ngày, nếu bạn ước tính sai một lần chạy nước rút hoặc không chạy nước rút, thì đó không thực sự là vấn đề lớn. Những người ở trên nhóm của bạn trong công ty của bạn có thể quan tâm nhiều hơn rằng nhóm của bạn luôn di chuyển và các dự án đang được hoàn thành hợp lý.

Là một cá nhân thuộc Agile, bạn nên quan tâm nhất đến việc bạn hoàn thành hiệu quả bao nhiêu công việc có liên quan đến phần còn lại của nhóm. Nếu bạn là người mới, bạn sẽ không thể làm việc quá hiệu quả, nhưng tại một số thời điểm trong nhiệm kỳ của bạn, bạn nên ở ngang tầm với ít nhất một số nhóm của bạn. Nếu bạn không xuất xưởng, bạn không thực sự làm việc của mình.


0

Sự hiểu biết của tôi về các cam kết vận tốc và chạy nước rút trung bình có đúng không?

Vận tốc trung bình của bạn là tại chỗ. Theo kinh nghiệm của tôi, điều này rất hữu ích cho các ước tính hoàn thành dài hạn - giả sử bạn có lượng tồn đọng lớn; nhưng không hữu ích cho các cam kết lập kế hoạch nước rút.

Quá trình tôi đã thấy theo kế hoạch chạy nước rút là kéo các câu chuyện từ đầu của hồ sơ tồn đọng và để nhóm quyết định xem họ có thể đạt được chúng hay không. Các nhóm đã quyết định điều này dựa trên cảm giác ruột, phá vỡ các nhiệm vụ 1/2 ngày, áp lực từ Chủ sở hữu sản phẩm, liên kết với mục tiêu chạy nước rút, dự đoán tốt nhất (dựa trên vận tốc) hoặc kết hợp tất cả chúng.

Đôi khi, Chủ sở hữu sản phẩm đã cho phép bỏ qua một vài mục để có thể thêm nhiều hơn.

Đôi khi, nhóm và chủ sở hữu sản phẩm đồng ý trước các mặt hàng kéo dài để di chuyển lên.


0

Đây là một câu hỏi xuất sắc và rất quan trọng để các đội cải thiện. Chủ đề là lừa đảo và được hiểu lầm rộng rãi. Mục đích ban đầu của việc chỉ ra câu chuyện là tìm ra một phương pháp nhanh chóng và chính xác để ước tính Mức độ nỗ lực (LOE) cần thiết để hoàn thành chức năng được xác định trong các câu chuyện. Mục tiêu tổng thể: cung cấp cho các nhóm một phương pháp DỰ BÁO hoặc dự đoán sẽ mất bao lâu để hoàn thành một nỗ lực (chẳng hạn như một dự án). Sự hiểu biết của bạn về Velocity là đúng: đó là điểm AVERAGE cho mỗi Sprint hoàn thành (thực sự XONG). Vì vậy, nếu bạn có một dự án để phân phối, và nó là 250 điểm và nhóm của bạn trung bình 25 điểm cho mỗi lần chạy nước rút, dự án sẽ mất khoảng 10 lần chạy nước rút, cộng hoặc trừ một số thời gian đệm.

Một số ngôi sao sáng, chẳng hạn như Ken Schwaber, cho rằng vận tốc và điểm chỉ được sử dụng để dự báo trung hạn đến dài hạn. Họ đề nghị sử dụng giờ làm việc như một "kiểm tra vệ sinh" thứ hai về những gì thực sự có thể được thực hiện trong một lần chạy nước rút. Vì vậy, số lượng điểm trong mỗi lần chạy nước rút có thể khác nhau tùy thuộc vào năng lực. Những người khác (bao gồm cả tôi), tin rằng một nhóm trưởng thành sẽ giải quyết thành một mô hình kích thước rất phù hợp có thể dự đoán chính xác năng lực, và cuối cùng giờ làm việc trở thành gánh nặng thêm vô ích. (Điều quan trọng là phải thực hiện cho các đội mới trong ít nhất 6 đến 12 lần chạy nước rút, IMHO, cho đến khi sự hiểu biết của đội về điểm và kích thước câu chuyện là chính xác.)

Lỗi nhỏ đầu tiên của bạn là bạn nói rằng nhóm nên biết vận tốc và mang lại nhiều điểm câu chuyện. Trên thực tế, các huấn luyện viên khuyến khích các đội khấu trừ 10% đến 20% và thay vào đó cam kết * với mức đó. Vì vậy, nếu nhóm của bạn có xu hướng hoàn thành 25 điểm mỗi lần chạy nước rút, đừng lấp đầy nước rút đến 25 điểm, mà thay vào đó, hãy dừng lại ở mức 20 đến 22 điểm. Hãy nhớ rằng: nó hoàn toàn TUYỆT VỜI khi mang đến những câu chuyện khi công việc khác hoàn thành. Vì vậy, bạn có thể "cam kết" đến 22 điểm và hoàn thành 28. Điều đó thật tuyệt. Chỉ cần cẩn thận để không khuyến khích nhóm "bao cát" và liên tục theo cam kết. Không có gì sai với việc kéo dài để xem liệu chúng ta có thể làm nhiều hơn nữa không.

Bây giờ, theo quan điểm của bạn về phương sai giữa các lần chạy nước rút. Đây là một mẫu rất phổ biến (nhưng KHÔNG TỐI ƯU) để thấy một đội hoàn thành 20 điểm một lần chạy nước rút, sau đó 50, rồi 22, rồi 45, rồi 15, sau đó 60. Nếu bạn tính độ lệch, nó có thể hiển thị dao động 50% đến 100% nước rút sau khi chạy nước rút. Tại sao các đội hoàn thành chỉ 15 điểm trong một lần chạy nước rút, và sau đó 60 điểm trong lần tiếp theo?

Điều đó có nghĩa là nhóm thực sự không biết họ có thể làm gì. (Này, chúng tôi đã hoàn thành 50 điểm nước rút cuối cùng, chúng tôi có thể làm lại lần chạy nước rút này).

HOẶC, điều đó có thể chỉ ra rằng chủ sở hữu sản phẩm đang buộc nhóm phải cam kết quá mức hoặc đang thêm công việc sau khi bắt đầu chạy nước rút, v.v ... Đây chỉ là một số trong những BỆNH NHÂN có thể gây ra sự thay đổi đột ngột ở những điểm đã hoàn thành.

Biện pháp Dự đoán này là một biện pháp quan trọng để các bậc thầy scrum quan sát và mang đến sự chú ý của đội. Làn sóng làm việc không hoàn thành Thông thường, lý do họ hoàn thành một vài điểm trong một lần chạy nước rút, và sau đó nhiều điểm trong lần chạy nước rút tiếp theo là cái mà tôi gọi là "ROLLING WAVE OF INCOMPLETE WORK". Đây là một mô hình rất phổ biến:

Chủ sở hữu sản phẩm chịu áp lực để đáp ứng một ngày. Vì vậy, nhóm cảm thấy cần phải cố gắng để hoàn thành rất nhiều công việc. Họ bắt đầu như một đội mới và không chắc chắn những gì họ thực sự có thể làm được.

Vì vậy, chạy nước rút 1, họ lập kế hoạch chạy nước rút và khi họ đang trong giai đoạn Hình thành, không thể hoàn thành tất cả công việc. Trong thực tế, họ có nhiều công việc không hoàn thành hơn công việc được thực hiện. Công việc không hoàn thành là BẮT ĐẦU nhưng TUYỆT VỜI. Nó được chuyển sang lần chạy nước rút tiếp theo, và lần này họ đã hoàn thành công việc nhiều hơn là không hoàn thành. Đến lần chạy nước rút tiếp theo, khối lượng lớn công việc chưa hoàn thành đó rơi vào DONE và sự tự tin của nhóm tăng vọt.

Chủ sở hữu sản phẩm rất phấn khích và vì vậy họ tăng tải trở lại. Vào cuối giai đoạn nước rút này, họ có một lượng lớn công việc chưa hoàn thành và một lượng công việc DONE đáng thất vọng.

Tại đây bạn bắt đầu thấy WAVES của Xong so với chạy nước rút xen kẽ sau khi chạy nước rút. Nếu các đội không nhận ra điều gì đang xảy ra, mô hình này có thể tiếp tục trong nhiều tháng. Nhưng trung bình, họ hoàn thành khoảng 24 điểm mỗi lần chạy nước rút. Vì vậy, những gì xảy ra khi họ bỏ cam kết quá mức?

Bạn sẽ lưu ý rằng họ VẪN hoàn thành 24 đến 26 điểm, nhưng công việc tiếp tục bị giảm. Bây giờ, thay vì quá tải khi cố gắng hoàn thành một khối lượng công việc không thể, điều này cũng phá hủy tinh thần của đội, nhóm có thể bắt đầu cải thiện quy trình của họ.

Theo thời gian, vận tốc sẽ bắt đầu tăng lên, không có sự thay đổi lớn trong công việc Done-vs-Chưa hoàn thành.

Nếu bạn không cho phép nhóm "nghỉ ngơi", họ sẽ KHÔNG BAO GIỜ có thời gian để thực hiện công việc giúp họ gầy hơn, nhanh hơn, tốt hơn. Dev-Ops, ví dụ, không thể xảy ra. Kiểm tra tự động hóa - Ai có thời gian cho việc đó!? Nhưng đây chính xác là những điều mà các đội cần phải làm việc để họ có thể tăng vận tốc.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.