Khi người quản lý của tôi nói với nhóm rằng " bây giờ trở đi câu chuyện người dùng thành công sẽ được xem xét để thẩm định! "
Chúng tôi ngồi đó trong khi bị sốc và đó là một trong những khoảnh khắc hàm rơi mà anh ấy dành cho chúng tôi :-)
Chúng tôi cảm thấy đó là ý tưởng ngu ngốc, vì điều này sẽ phá hỏng tất cả các khái niệm và mục tiêu của phương pháp phát triển nhanh.
Hãy cho tôi biết những gì bạn nghĩ? và làm thế nào chúng ta có thể thuyết phục anh ta?
Câu trả lời:
Sandy, thật không may, tuyên bố của người quản lý của bạn là một sự hiểu lầm kinh điển về scrum nói riêng và nhanh nhẹn nói chung.
Cách tiếp cận đề xuất giết chết sự hợp tác và phản ánh nguyên tắc sở hữu mã tập thể . Câu chuyện của người dùng nhanh nhẹn (nếu đó là một người nhanh nhẹn thực sự) hiếm khi được hoàn thành trước khi được nhiều người chạm vào. Ngoài ra, thỉnh thoảng bạn sẽ có những câu chuyện của người dùng cần tràn ngập để được hoàn thành trong vòng lặp. Làm thế nào bạn sẽ nhận được tất cả khi các ưu đãi riêng lẻ được căn chỉnh 180 độ theo hướng ngược lại?
Bản năng đội của bạn là chính xác. Những nguồn nào tôi sẽ đề xuất trong thời gian ngắn để bạn đọc khi bạn động não phản ứng với người quản lý của bạn? Nhìn vào blog của các chuyên gia nhanh nhẹn nổi tiếng như Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby và một số người khác và tìm kiếm các bài viết về tổ chức nhóm nhanh nhẹn.
Phản đối chính của tôi đối với phương pháp đánh giá này là nó có thể là một trở ngại cho sự hợp tác giữa các nhà phát triển. Tôi nghĩ rằng một phần quan trọng trong năng suất của một nhóm phát triển là sự sẵn lòng của các thành viên trong nhóm để giúp đỡ lẫn nhau. Theo tôi hiểu sơ đồ được đề xuất, nó có thể dẫn đến các nhà phát triển gắn bó với các nhiệm vụ được giao của riêng họ và bỏ qua các thành viên khác trong nhóm đang bị mắc kẹt và có thể dễ dàng bị gỡ bỏ bởi một chút trợ giúp.
Chúng tôi luôn tìm kiếm sự đóng góp của lập trình viên cho nhóm và doanh nghiệp.
Đây là ngang bằng để đo các dòng mã, hoặc số lỗi - nhưng tinh vi hơn một chút.
Thoạt nhìn không có gì sai với phép đo, nhưng khi bạn nghĩ về nó, bạn bắt đầu đưa ra ý kiến phản đối:
là điều rõ ràng nhất nảy ra trong đầu - tôi chắc chắn có những người khác.
Người quản lý của bạn rõ ràng nghĩ rằng đây là một ý tưởng tốt, vì vậy bạn cần cẩn thận rằng khi bạn đưa ra phản đối, bạn cũng có thể trình bày các giải pháp. Giải pháp này có thể phải là một sửa đổi cho sơ đồ của anh ta hơn là một sơ đồ mới.
Vì vậy, ví dụ bạn có thể muốn chỉ ra rằng ai đó chỉ làm việc trên những câu chuyện "dễ dàng" sẽ hoàn thành nhiều hơn một người làm việc với một câu chuyện "khó khăn" hơn và điều này có thể dẫn đến sự tập trung vào các khía cạnh ít quan trọng của sự phát triển. Vì vậy, một giải pháp có thể là xem xét số lượng điểm câu chuyện thay vì chỉ số lượng câu chuyện.
Tôi đồng ý với ChrisF rằng điều này trở lại cùng một vấn đề với bất kỳ phép đo nào. Những gì bạn khen ngợi là những gì bạn nhận được. Luôn luôn có những người chơi trò chơi hệ thống, bất kể hệ thống đó sẽ là gì.
Phương pháp hiệu quả thực sự duy nhất mà tôi tìm thấy để thưởng cho lập trình viên đi kèm với ba bước.
Toàn bộ chìa khóa là các lập trình viên không phải là một bánh răng trong một cỗ máy có thể được 'điều chỉnh' bằng cách xem số liệu thống kê. Những người thực sự cần được kiểm tra và cải thiện toàn bộ và nhóm cần có thể dựa vào nhau trong một hợp tác xã, và không phải là một cách cạnh tranh.
Những người biểu diễn kém trong đội được trao mọi cơ hội để cải thiện và làm giàu trước khi họ bị coi là buông tay. Cuối cùng, những lập trình viên giỏi sẽ phát triển mạnh trong môi trường này và những lập trình viên nghèo, những người từ chối được cải thiện, sẽ được cho đi.
Hầu hết thời gian, Câu chuyện của người dùng được hoàn thành trong một nỗ lực tập thể. Điều này làm cho hầu như không thể căn cứ đánh giá cá nhân trên số liệu này.
Bản thân số liệu có thể dễ dàng thao tác vì quy trình lập kế hoạch cũng là một nỗ lực của nhóm và thậm chí sớm hơn sau đó, toàn bộ hệ thống đã bị gian lận. Đó chắc chắn là những gì bạn không muốn trong một quá trình tập trung vào con người.
Tôi nghĩ rằng hiệu suất tốt phải được công nhận bởi một số loại hệ thống tiền thưởng dựa trên thành công của nhóm, nhưng Câu chuyện của người dùng không phải là một chỉ số tốt về thành công.