Câu trả lời ngắn gọn là có.
Ngay cả các nhóm phát triển thuần túy cũng có xu hướng tự tổ chức thành các đặc sản hoặc chủ sở hữu của các hệ thống phụ cụ thể (trừ khi bạn có xu hướng buộc họ xoay công việc, nhưng đó là chủ đề cho một vấn đề khác). Vì vậy, bạn sẽ được ước tính các câu chuyện với một số lượng đáng kể các thành viên trong phòng có ít kiến thức về công việc hệ thống con được kết hợp với câu chuyện.
Ước tính câu chuyện được cho là nhiều hơn về so sánh quy mô phức tạp/công việc. Nó này hai lần, bốn lần, tám lần (hoặc quy mô tương tự) làm việc nhiều hơn so với điểm cơ sở được xác định. Hoặc, nó là tương tự với mặt hàng khác mà chúng tôi đánh giá ở tám. Ít nhất đó là mục tiêu. Ở cấp độ chạy nước rút (so với tổng thể tồn đọng), tôi thấy các đội muốn ước tính với nhiều thang đo cụ thể hơn (tức là giờ).
Đối với những người thuộc các ngành cụ thể, bạn có thể hoặc không muốn họ được đưa vào quy trình ước tính. Nếu những cá nhân đó có một sự hiểu biết hợp lý về sự phức tạp của nhiệm vụ, có ước tính có thể tốt như một thành viên khác. Nếu không, thì họ không nên đưa ra ước tính.
Một lợi ích của việc bao gồm ước tính của họ vì nó thường tạo ra các ước tính xa hơn (quá cao hoặc thấp). Khi chúng tôi có một mục với các ước tính bên ngoài một phong bì hợp lý, nó là một kích hoạt để có một cuộc thảo luận ngắn, nhưng sâu hơn về công việc. Thông thường, cuộc thảo luận đó buộc một nhóm phát hiện ra công việc/phức tạp không rõ ràng từ mô tả câu chuyện và tiêu chí chấp nhận.
Nguồn
2009-12-02 11:33:54
các đội khoảng 7-10. Vì vậy, bạn đang nói rằng các nhóm đa dạng này là tốt? Điều gì về các cuộc họp ước tính, nơi các lập trình viên cho thấy thẻ ước tính về nhiệm vụ thiết kế và ngược lại. Điều đó có đúng không? – jacob
Bạn đang đề cập đến các phiên chỉ dẫn câu chuyện ... trong đó các thành viên lấy câu chuyện tự nguyện sau khi được chỉ ra. Đối với phiên chỉ trỏ ... thì onus là trên các thành viên; một sức mạnh tổng hợp có thể được mong đợi giữa một nhà phát triển và người thử nghiệm trong ước tính ... của một nói một thành phần phần mềm không có giao diện người dùng. Qua đó thành viên UX không cản trở việc chỉ ra câu chuyện cụ thể đó. Hơn nữa, nguyên nhân gốc rễ chính là thành phần nhóm, nơi sự lựa chọn của 7 thành phần đó phải được thực hiện một cách thông minh bởi chủ nhân Scrum –
Bạn nhận được giới hạn 7-10 này từ đâu? Rất nhiều người khuyên bạn nên có các đội nhỏ trong các dự án nhanh nhẹn, dưới 10, nhưng đó không phải là giới hạn. Chúng tôi đã làm việc với hơn 15 nhóm nhanh nhẹn với nhiều thành công. –