Là thương lượng và đánh bại các nỗ lực về ước tính Scrum là phần hợp pháp của quy trình?

Tôi nhận thấy trong các cuộc họp scrum, rằng các nhà phát triển thường đưa ra ước tính thực tế về các câu chuyện. Tuy nhiên, ngay cả những câu chuyện khá đơn giản cũng cần rất nhiều nỗ lực để cấu hình, thiết lập các thành phần của bên thứ ba, thử nghiệm và xây dựng cuối cùng và hệ thống đã tích lũy được một số nợ kỹ thuật, do đó, ước tính thường xuất hiện quá cao đối với chủ sở hữu hoặc quản lý sản phẩm.

PO thường cố gắng đánh bại các ước tính như vậy, như: "Cái gì, bạn muốn 13 điểm câu chuyện [4 ngày] cho câu chuyện này, điều này không thể! Tôi không thể giải thích điều này với quản lý, ai đó sẽ có thể mã hóa điều này với 3 SP [trong 4 giờ]! ". Do đó, các nhà phát triển đã vặn vẹo cánh tay để cam kết ước tính 5 hoặc 8 điểm [1,5 đến 2 ngày] (ước tính Scrum vẫn được coi là cam kết, không chỉ là dự báo).

Tất nhiên, không có bất kỳ kế hoạch nào để loại bỏ kỳ vọng (chủ yếu là kiểm tra và chất lượng), những lần chạy nước rút này thường xuyên thất bại. Ước tính của các nhà phát triển là một sự trung thực, thực tế và đánh bại ước tính không đánh bại công việc thực tế cần thực hiện.

Người ta có thể nói: "Bạn không nên đưa ra một cam kết bất khả thi, chỉ vì ai đó thúc ép bạn làm!" Nhưng theo tôi, công việc của một nhà phát triển là thiết kế phần mềm và mã hóa, không mặc cả hay đứng lên chống lại áp lực! Có thể có các lỗ hổng của tất cả các giao dịch, điển hình là các giao dịch trực tiếp với khách hàng bên ngoài, nhưng đây không phải là phần lớn các nhà phát triển văn phòng!

Đối với tôi, cách làm này chỉ khiến các lập trình viên trông giống như những kẻ ngốc, gây ra những thất bại nước rút liên tục và ngăn chặn những ước tính thực tế, cũng như tìm kiếm những cải tiến thực tế.

Các hướng dẫn Scrum nói gì về chủ đề này, hoặc họ có nói gì về nó không?

EDIT: thay thế lần bởi điểm câu chuyện. Tôi đã đề cập đến giai đoạn ước tính ban đầu với Planning Poker và các điểm câu chuyện, không phải là kế hoạch chi tiết nhiệm vụ. Tôi chỉ đặt ngày / giờ ở đó, bởi vì đôi khi đó là một cuộc đối thoại điển hình như thế này, cũng với thời gian thay vì điểm. Xin lỗi vì sự nhầm lẫn! Các ví dụ điểm câu chuyện đại diện cho khoảng thời gian dài hơn so với các ví dụ thời gian.

EDIT 2 Hiện tại không có chủ scrum chuyên dụng và PO đảm nhận vai trò đó, khi nói đến các cuộc họp ước tính. Vì vậy, có lẽ xung đột vai trò làm cho thương lượng không phù hợp này trở nên tồi tệ hơn, vì anh ta xuất hiện như một người có thẩm quyền, thay vì một bậc thầy scrum trung lập hoặc nhà phát triển. Có lẽ, điều này có thể được khắc phục bằng cách đưa anh ta như một người tham gia thiên vị thay vì một "bậc thầy", miễn là không có sẵn.

Tình huống bạn mô tả là độc hại. Kiểu thương lượng này bỏ qua thực tế và chuyên môn của nhóm, nó cố tình che giấu thông tin từ nhóm và tổ chức, và nó ngăn cản nhóm cải thiện theo thời gian.

Nếu bạn muốn thành phố http://www.scrumguides.org/scrum-guide.html với tư cách là người có thẩm quyền tôi sẽ nêu bật:

Chỉ Nhóm Phát triển mới có thể đánh giá những gì nó có thể đạt được trong Sprint sắp tới.

và

Scrum dựa vào tính minh bạch. Các quyết định để tối ưu hóa giá trị và rủi ro kiểm soát được đưa ra dựa trên trạng thái cảm nhận của các vật phẩm. Trong phạm vi mà tính minh bạch được hoàn thành, các quyết định này có cơ sở hợp lý. Trong phạm vi các cổ vật không hoàn toàn minh bạch, các quyết định này có thể bị sai sót, giá trị có thể giảm và rủi ro có thể tăng lên.

Chủ sở hữu sản phẩm của bạn có thể mong muốn rằng một nhiệm vụ có thể thực hiện được chỉ trong 4 giờ. Đó thậm chí có thể là một mục tiêu hợp lý. Một phản ứng lành mạnh có thể là chấp nhận ước tính của nhóm, đo lường nếu chính xác và hỏi "chúng ta cần thay đổi gì để có thể hoàn thành loại nhiệm vụ này nhanh hơn?" Đàm phán phạm vi công việc liên quan đến nhiệm vụ cũng có thể hợp lý và làm nổi bật một sự khác biệt quan trọng trong cách các nhà phát triển và chủ sở hữu sản phẩm hiểu công việc đó trong tầm tay. Yêu cầu nhóm thay đổi ước tính của họ mà không có thông tin mới chỉ đảm bảo ước tính không chính xác.

Có nhiều chiến lược mà nhóm phát triển có thể sử dụng để cố gắng thay đổi mô hình này nhưng khi bạn đưa ra phản hồi ví dụ về "Tôi không thể giải thích điều này cho ban quản lý", tôi rất lo lắng. Có vẻ như chủ sở hữu sản phẩm của bạn không có sự tin tưởng của ban quản lý (các ước tính không chính xác mà họ đang sản xuất có thể không giúp ích gì) và có thể không sẵn sàng minh bạch về các thất bại của quy trình hiện tại.

Theo tôi, một trong những thành tựu lớn nhất của SCRUM là phát triển các điểm câu chuyện, với mục đích rõ ràng là thể hiện để tránh các vấn đề thương lượng được đề cập ở đây. Toàn bộ điểm của câu chuyện là để tránh kết nối trực tiếp giữa một nhiệm vụ và mất bao nhiêu ngày. Thay vào đó, hai khái niệm đó được kết nối bởi ý tưởng về vận tốc.

Nếu tôi là một nhà phát triển, và tôi bị vặn vẹo khi gọi một câu chuyện 13 điểm là một câu chuyện 8 điểm, tôi sẽ vui vẻ bắt buộc. Đó là khả năng ước tính của họ, họ đang tác động. Tôi chỉ đơn giản sẽ mở rộng tất cả những khó khăn của tôi để phù hợp. Cuối cùng, vận tốc của nhóm sẽ giảm về điểm số câu chuyện mỗi tuần để phù hợp với sự sẵn sàng "loại bỏ" điểm câu chuyện của ban quản lý. Các con số được giao cho quản lý phải khớp: "Chúng tôi đã giảm thành công số điểm công việc cần thiết để hoàn thành cột mốc 50%. Tuy nhiên, chúng tôi đã thấy tốc độ giảm tương ứng giảm 50%, vì vậy hiệu ứng ròng là chúng tôi sẽ hoàn thành chính xác những gì chúng ta sẽ hoàn thành trong chính xác lượng thời gian nó sẽ mất. " Khái niệm vận tốc tồn tại để chống lại suy nghĩ mong muốn của quản lý cấp trên.

Bây giờ có hai thái cực mà tôi nghĩ là đáng xem xét. Một là thất bại hoàn toàn của quản lý và hai là thực sự là một mối quan tâm rất hợp lệ để quản lý quan tâm. Trường hợp đầu tiên là bản án tử hình đối với SCRUM, khi các nhà phát triển được thông báo "bạn không đủ năng suất. Bạn cần tạo ra nhiều công việc đáng giá hơn." Nếu điều đó xảy ra, bạn không thực sự sử dụng SCRUM, bạn là một Cookoo, người đã đuổi SCRUM ra khỏi tổ và đang cố gắng để được chim mẹ cho ăn tiếp theo.

Bây giờ có một trường hợp mà tôi nghĩ rằng quản lý nêncó thể tham gia vặn tay như thế này. Sẽ hợp lý khi khách hàng nói "Tôi không đủ khả năng 50 điểm câu chuyện để hoàn thành nhiệm vụ này nếu vận tốc của bạn là 20 điểm / tuần. Tôi cần bạn hoàn thành nó trong 30 điểm câu chuyện", nếu khách hàng đó sẵn sàng để đàm phán lại nội dung của những câu chuyện đó để giảm phạm vi của họ xuống 40%. SCRUM không phải là một bữa ăn miễn phí cho các nhà phát triển để làm bất cứ điều gì họ muốn, nó là một công cụ giao tiếp để giúp họ và quản lý công khai trò chuyện về những gì cần phải làm. Nó cũng có giá trị đối với một khách hàng áp dụng nhà phát triển và nói "thực hiện nhiệm vụ trong 30 điểm" nếu họ sẵn sàng chấp nhận rủi ro vốn có mà công việc đơn giản sẽ không được hoàn thành kịp thời gian. Khi thời hạn bị bỏ lỡ, nếu các nhà phát triển có thể nói " và sau đó chấp nhận bất cứ điều gì thực sự đã được thực hiện. Tôi nghĩ có nhiều cách tốt hơn để đo năng suất của một đội, nhưng tôi phải thừa nhận rằng đó là một quá trình hiệu quả. và sau đó chấp nhận bất cứ điều gì thực sự đã được thực hiện. Tôi nghĩ có nhiều cách tốt hơn để đo năng suất của một đội, nhưng tôi phải thừa nhận rằng đó là một quá trình hiệu quả.

Đối với một, PO không nên cung cấp thông tin nhiệm vụ cho quản lý. Các ước tính nhiệm vụ là đúng cho lợi ích của nhóm. Điều duy nhất mà bất cứ ai ngoài nhóm cần biết là những câu chuyện họ đang làm việc, giá trị điểm của họ là gì và vận tốc trung bình của đội là gì. T

Thứ hai, trừ khi PO là nhà phát triển cấp cao có kiến ​​thức sâu về phần mềm, ý kiến ​​của họ về ước tính nhiệm vụ không nên mang nhiều trọng lượng. Các nhà phát triển là những người có kiến ​​thức về hệ thống và là những người đang thực hiện công việc. Trừ khi tất cả họ đều mới ra trường với các kỹ năng ước tính bằng không, các ước tính của họ nên được loại trừ.

Điều đó không có nghĩa là đôi khi không thể đặt câu hỏi. Nếu vậy, điều này cần phải xảy ra theo cách tích cực. Ví dụ: "bạn đã nghĩ rằng chúng tôi đã hoàn thành một nửa công việc cho" x "" hay "bạn có nhớ bao gồm thời gian để làm Y không?".

Điểm mấu chốt: các nhà phát triển nên cảm thấy an toàn để đưa ra bất kỳ ước tính nào họ muốn, miễn là họ thực hiện một nỗ lực thiện chí là chính xác. Nếu họ nói một cái gì đó mất bốn giờ, bạn phải chấp nhận điều đó.

Các hướng dẫn Scrum nói gì về chủ đề này, hoặc họ có nói gì về nó không?

Họ không nói gì cả. Ước tính nhiệm vụ không phải là một phần của scrum. Với scrum, ước tính dừng lại ở điểm câu chuyện. Ước tính nhiệm vụ chỉ đơn thuần là một công cụ giúp các nhóm làm tốt hơn việc ước tính điểm câu chuyện bằng cách đảm bảo rằng họ đã nghĩ qua tất cả các công việc cần thiết để hoàn thành một câu chuyện.

Nhiệm vụ của Scum Master là đảm bảo quy trình scrum được tuân thủ. Điều này bao gồm đảm bảo rằng nhóm không (nhất quán) quá quan tâm đến số lượng công việc mà họ có thể hoàn thành trong một lần chạy nước rút.
Một mặt, điều đó có nghĩa là cai trị một đội quá nhiệt tình, nhưng mặt khác cũng đẩy lùi Chủ sở hữu sản phẩm nếu anh ta gây áp lực cho đội.

Một cách tốt để giữ cho cam kết / dự báo thực tế là nhìn vào những câu chuyện đã được thực hiện trong vài lần chạy nước rút gần đây. Đó là những gì nhóm đã chứng minh rằng họ có thể hoàn thành, vì vậy không có lý do gì để kéo thêm nhiều công việc đáng kể vào giai đoạn nước rút, vì nó sẽ không được hoàn thành.

Như các câu trả lời khác cũng chỉ ra, việc mặc cả các ước tính do nhóm đưa ra không phải là một phần của quy trình Scrum. Nhóm này là người quen thuộc nhất với phần mềm, vì vậy họ nên biết rõ nhất công việc đó là bao nhiêu.

Những gì có thể được mặc cả là phạm vi của một câu chuyện. Nếu Chủ sở hữu sản phẩm nghĩ rằng một câu chuyện được ước tính là lớn hơn hoặc nhỏ hơn so với dự kiến ​​hợp lý, thì họ có thể yêu cầu làm rõ từ nhóm để xem liệu quan điểm về công việc cần được thực hiện phù hợp giữa các bên.
Nếu câu chuyện thực sự nhiều việc, Chủ sở hữu sản phẩm có thể quyết định chia nó thành nhiều câu chuyện nhỏ hơn và phân phối chức năng cho những câu chuyện nhỏ hơn đó.

Nhóm chịu trách nhiệm cung cấp chất lượng và điều đó không bao giờ nên mở để mặc cả.

Có và không.

Có, nhóm chạy nước rút nên thương lượng với chủ sở hữu sản phẩm về những gì được đưa vào nước rút.

Không, chủ sở hữu sản phẩm không nói gì trong thời gian mọi thứ sẽ diễn ra. Bạn là chuyên gia, không phải họ.

Hãy nhìn xem, bạn không cần phải xử lý loại rác đó - người quản lý hoặc trưởng nhóm của bạn sẽ có mặt để giúp bạn thành công. Điều đó có nghĩa là giao dịch với Thủ tướng (hoặc ông chủ của họ) để bạn sẽ thành công. Điều đó nói rằng, nó không khó.

"Không."

Họ định làm gì vậy? Tự viết mã?

Cho phép hành vi này là một thất bại của Scrum Master. Công việc của cô, trước hết và quan trọng nhất là bảo vệ đội bóng. PO, vì những lý do được mô tả ở trên, đang bị cận thị. Scrum Master nên bước vào và, theo một cách tích cực, điều chỉnh lại bối cảnh của cuộc thảo luận.

Tất nhiên, áp lực như vậy sẽ dẫn đến áp lực giảm tốc độ, điều mà OP đã trích dẫn. Nếu các đội liên tục không hoàn thành các lần chạy nước rút của mình, Scrum Master sẽ lại bước vào và hỏi tại sao điều này có thể xảy ra. Trong môi trường thực sự độc hại, các thành viên trong nhóm có thể không cảm thấy trung thực trong Hồi tưởng. Nhưng trong tình huống đó, Scrum Master có trách nhiệm gọi ra hành vi xấu và bảo vệ đội.

Nếu bạn thấy mình trong một tình huống mà Scrum Master của bạn không thể hoặc sẽ không làm những điều này, thì có lẽ bạn cần một Scrum Master khác. PO đang phản ứng với áp lực điển hình. Nhóm nghiên cứu, trong hang động, cũng phản ứng như con người thường làm. Đó là công việc của Scrum Master để thấy điều này là gì và dừng lại ở đó. Trách nhiệm của OP ở đây là đưa vấn đề này lên trong Hồi cứu và, nếu cần thiết, cho các nhà lãnh đạo và quản lý. Nếu điều đó vẫn không giải quyết được, hãy cập nhật hồ sơ LinkedIn của bạn và tìm những người tốt hơn để làm việc cùng.

Một nhóm phát triển sản phẩm (bao gồm tất cả mọi người từ chủ sở hữu sản phẩm, đến nhà phát triển, người thử nghiệm) có thể tuân theo quy trình nhanh nhẹn và nhận được kết quả tốt khi có người có năng lực hợp lý và kỳ vọng thực tế.

Hoặc họ có thể làm theo một quy trình rất giống với quy trình nhanh nhẹn.

PO đó có thể nghĩ rằng anh ta sẽ nhận được kết quả tốt hơn bằng cách cố gắng để có được ước tính thời gian thấp hơn cho các nhiệm vụ. Tất nhiên là nó không hoạt động. Nếu một cái gì đó mất ba ngày, bạn cho tôi rất nhiều tiền mặt và tôi sẽ ước tính rằng tôi có thể làm điều đó trong một giờ. Nó vẫn sẽ mất ba ngày. Nếu bạn đến và hét vào mặt tôi vì nó chưa kết thúc sau một giờ như đã hứa, sẽ mất năm ngày.

Tất cả những gì anh ta đạt được là phá vỡ quy trình nhanh nhẹn và từ bỏ tất cả các kết quả tích cực mà anh ta có thể nhận được. Bậc thầy scrum nên có kinh nghiệm, sức mạnh và sự can đảm để ngăn chặn điều này. Nếu quản lý làm cho ai đó làm chủ scrum, người không có kinh nghiệm hoặc không cung cấp cho chủ scrum sức mạnh để ngăn chặn điều này, thì đó là lỗi của họ khiến họ nhanh chóng phá vỡ. Nếu chủ scrum không có can đảm, thì anh ta chia sẻ sự đổ lỗi với Thủ tướng.

Tôi muốn nói rằng nó phụ thuộc rất nhiều vào động lực ở đây. Mục tiêu bao trùm của ước tính là để có được ý tưởng về việc nhóm có thể đạt được bao nhiêu trong bất kỳ lần chạy nước rút nào, sau đó cho phép dự báo công việc trong tương lai dựa trên vận tốc đó. Ví dụ: nếu nhóm hoàn thành 30 điểm câu chuyện mỗi lần chạy nước rút và có khoảng 60 điểm câu chuyện trước Mục X trên hồ sơ tồn đọng, thì Chủ sở hữu sản phẩm có thể nói rằng Mục X sẽ hoàn thành trong khoảng 6 tuần (dựa trên một chạy nước rút tiêu chuẩn hai tuần).

Để làm cho ước tính này chính xác nhất có thể, không có gì phải bàn cãi về việc có bao nhiêu câu chuyện về một mục cụ thể. Scrum thực sự khuyến khích nó. Sự bất đồng đó đôi khi có thể được làm nóng. Tuy nhiên, mục tiêu cuối cùng phải là ước tính chính xác độ phức tạp của PBI, chứ không phải làm giảm nỗ lực một cách giả tạo để bạn có thể cố gắng nhồi nhét thêm PBI vào một vận tốc nhất định.

Đây thực sự là cách lập kế hoạch hoạt động poker, về nguyên tắc. Mọi người đưa ra ước tính của họ. Scrum Master, sau đó lấy ước tính cao và thấp và hỏi tại sao thành viên trong nhóm nghĩ rằng nó phải cao / thấp như vậy. Điều này mang lại cho nhóm một cơ hội để nghe các quan điểm thay thế của công việc liên quan và hiểu rõ hơn về mức độ phức tạp của nhiệm vụ thực sự. Sau khi thảo luận, mọi người ném lại ước tính của họ. Quá trình này được rửa sạch và lặp lại cho đến khi có sự đồng thuận chung về sự phức tạp.

Nói cách khác, không sai khi thách thức ước tính của bạn, cho rằng người thách thức có lý do tại sao họ không đồng ý, ngoài việc họ chỉ muốn nó thấp hơn. Sau đó, trách nhiệm của bạn là thuyết phục nhóm của bạn rằng ước tính của bạn là chính xác, nếu bạn cảm thấy nó vẫn còn.