Điều gì có thể là một hoạt động xây dựng nhóm tốt để cải thiện kỹ năng ước tính? [đóng cửa]

9

Đã đóng cửa . Câu hỏi này dựa trên ý kiến . Nó hiện không chấp nhận câu trả lời.

Bạn muốn cải thiện câu hỏi này? Cập nhật câu hỏi để có thể trả lời bằng sự kiện và trích dẫn bằng cách chỉnh sửa bài đăng này .

Đóng cửa 6 năm trước .

Tôi sẽ tập hợp một bài thuyết trình để gửi đến một số đồng đội của mình (tất cả các nhà phát triển) và tôi muốn bao gồm một hoạt động xây dựng nhóm ngắn tập trung vào việc cải thiện các kỹ năng ước tính. Có ai có bất kỳ đề xuất hoặc biết về bất kỳ hoạt động xây dựng đội nhóm nào tôi có thể sử dụng không?

estimation team-building

— Cướp
nguồn

2

Cải thiện dự toán không phải là điều có thể được thực hiện với một hoạt động ngắn. Nó phải là một nỗ lực lâu dài để theo dõi các ước tính của bạn, thời gian thực tế và một số loại hậu họa để xác định lý do tại sao ước tính và thời gian thực tế khác nhau. Đó cũng là một kỹ năng phát triển theo thời gian - bạn sẽ tốt hơn bằng cách ước tính và học hỏi từ những sai lầm của mình thông qua phân tích.

— Thomas Owens

Bạn đã có một vấn đề? Làm thế nào chính xác là ước tính của bạn và bạn nên dành thời gian để cải thiện chúng?

— JeffO

@Thomas Owens, tôi biết rằng đó không phải là điều có thể làm được với một hoạt động ngắn. Tôi chỉ đang cố gắng tăng cường nhận thức về tầm quan trọng của việc phát triển các kỹ năng ước lượng tốt. Tôi nên đã được cụ thể hơn trong câu hỏi của tôi.

— Cướp

2

@Jeff O, không có vấn đề gì - đây là những nhân viên mới, một số ít kinh nghiệm và tôi muốn giúp họ làm việc về dự toán nói chung.

— Cướp

8

Hãy xem Lập kế hoạch dựa trên bằng chứng của Joel On Software , đây là một cách khá đơn giản để mọi người tìm ra cách ước tính chính xác hơn.

Cách tốt nhất để học cách ước tính là có yêu cầu tốt, thực hành, thực hành và thực hành. Dạy cho họ những thứ như Lập kế hoạch dựa trên bằng chứng sẽ giúp thực hành hiệu quả hơn, nhưng không có gì có thể thay thế thực hành thực tế.

— Malfist
nguồn

Tôi yêu tôi một số EBS (Tôi là một người dùng FogBugz cuồng nhiệt). Tôi đã không nghĩ về việc sử dụng nó như một ví dụ, mặc dù - gợi ý tốt. Tôi sẽ lấy một số cảm hứng từ nó.

— Cướp

6

Trình bày một vấn đề ví dụ bằng cách sử dụng Minecraft.

Khách hàng cần một kim tự tháp bước màu nâu là 20x20 khối. Kim tự tháp cũng cần một con hào rộng tối thiểu 10 khối.

Cung cấp cho họ 3 phút để phác thảo một WBS đơn giản và ước tính.

2 phút sau, nói rằng khách hàng đã thay đổi ý định và họ cần một kim tự tháp 30x30 ngay bây giờ. Nói với họ để sửa đổi ước tính của họ trong phút còn lại.

Cuối cùng, hãy bảo họ đặt bút chì xuống và bây giờ nói rằng các nhà phát triển bắt đầu làm việc với dự án nhưng khách hàng bối rối vì không có cây cầu nào đi qua hào nước.

Nói với họ rằng cây cầu sẽ mất X giờ để phát triển và yêu cầu mọi người đánh giá thấp phải đứng lên.

Điều này sẽ lái xe điểm nhà.

— phong_shaft
nguồn

2

Tôi thích điều này, nhưng nếu bạn không quen thuộc với Minecraft, tôi không chắc làm thế nào bạn có thể đưa ra một ước tính có ý nghĩa. Làm thế nào bạn sẽ định lượng thời gian cần thiết để xây dựng một kim tự tháp bước nâu?

— Cướp

1

@Thomas Owens, tôi nghĩ rằng điểm maple_shaft là để gây ấn tượng với các nhà phát triển về tầm quan trọng của việc khám phá các loại yêu cầu đó. Là một chuyên gia tư vấn, cá nhân tôi đã thấy nhiều ví dụ về những điều hiển nhiên lố bịch mà người dùng nên yêu cầu, nhưng không, vì họ không nhận ra đó là những gì họ cần. Bản thân tôi và các nhà phát triển của tôi đều là những chuyên gia tư vấn, và trong tình hình hiện tại của chúng tôi, chúng tôi không có những kỹ sư yêu cầu tốt, đó là lý do tại sao tôi cố gắng giúp họ hỏi những câu hỏi khám phá của khách hàng để giúp cải thiện ước tính của họ .

— Cướp

2

@ unlorgiven3 Tuy nhiên, điều đó không liên quan gì đến ước tính. Công việc của kỹ thuật yêu cầu có thể thuộc về một nhà phát triển, nhưng bạn chỉ có thể dựa trên ước tính của mình về các yêu cầu đã biết. Cải thiện khả năng phân tích, xác minh, xác thực và khám phá các yêu cầu của bạn là không phù hợp với việc cải thiện khả năng của bạn để ước tính thời gian cần thiết để thực hiện một nhiệm vụ. Yêu cầu thay đổi, ước tính do đó thay đổi, nhưng không thể ước tính những gì bạn không biết và bạn không nên cố gắng.

— Thomas Owens

1

@Thomas Owens, tôi đồng ý không thể ước tính những gì bạn không biết - đó chính xác là quan điểm của tôi - bạn cần khám phá các yêu cầu cho một tính năng và xác thực các giả định về nó như một điều kiện tiên quyết để tạo ước tính hợp lý. Mặc dù vậy, tôi đồng ý, sau khi xem xét, rằng việc cải thiện khả năng ước tính của một người - có lẽ việc tập trung vào hoạt động khám phá các yêu cầu sẽ hữu ích hơn ngay lập tức so với hoạt động ước tính. Điểm tốt - họ chắc chắn khiến tôi nghĩ rằng có lẽ tôi đang tập trung vào kỹ năng sai để cải thiện.

— Cướp

1

@ unlorgiven3 Một kỹ sư giỏi nên luôn nỗ lực cải thiện cả hai. Tôi đã ở trong một vị trí mà tôi không được giao nhiệm vụ yêu cầu kỹ thuật, nhưng tôi đã được trao một thông số kỹ thuật có những gì tôi thấy là vấn đề trong đó. Có kỹ năng nhìn thấy những điều đó và đặt câu hỏi đúng là điều cần thiết cho bất kỳ ai phát triển phần mềm và nó cần phải được thực hiện. Tuy nhiên, khi tôi ước tính, tôi luôn dựa trên ước tính của mình về thông số kỹ thuật, ngay cả khi có câu hỏi. Tôi chỉ để lại một cửa sổ lớn hơn cho lỗi (cho 75% cơ hội thay vì 85%, hoặc cho một cửa sổ lớn hơn một chút).

— Thomas Owens

1

Tôi đề nghị một trình tạo / giải mê cung cho các điểm sau:

Đó là niềm vui để làm
Bạn không thể nghĩ về tất cả các trường hợp lần đầu tiên
Các công cụ tạo và giải quyết khá bổ sung
Điều này bao gồm từ back-end với lưu dữ liệu đến front-end với tải dữ liệu
Nhiều điểm có thể được gán cho mọi người: đặc tả tệp, hiển thị, tạo, giải quyết, tối ưu hóa, thử nghiệm, v.v.

— Râu
nguồn

1

Bạn có thể chơi "Bạn sẽ mất bao lâu để viết bài này?" trò chơi. Tương tự như một nhóm người khoe khoang về cách họ có thể lái xe đến Las Vegas trong X giờ (trong đó số X thường giảm với mỗi người khoe khoang cho đến khi ai đó tuyên bố họ có thể làm điều đó trong vòng một giờ). Vì vậy, đối với các lập trình viên: Hãy đưa ra một mục tiêu đơn giản và xem mỗi cá nhân nói gì và nếu có sự đồng thuận của nhóm hoặc ý kiến nổi bật. Mất bao lâu để bạn viết lời chào thế giới? "Viết" nghĩa là gì, điều đó có nghĩa là "chạy" và "kiểm tra" quá? Nó đòi hỏi một môi trường mô phỏng đầu tiên? Trên nền tảng nào và trình biên dịch chéo nào và các công cụ đã được cài đặt và sẵn sàng chưa? v.v. "Xin chào thế giới" có thể mất 4 ngày để "viết" trên nền tảng nhúng (cài đặt công cụ, sẵn sàng cho nền tảng,

Sau khi nhóm hoàn thành quyết định mục tiêu có thể mất bao lâu, sau đó đo thời gian thực sự mất (có lẽ không phải cho mục tiêu được đề xuất mà là cho mục tiêu tương tự trong thế giới thực) hoặc nhớ lại một dự án trước đó với mục tiêu rất giống nhau. So sánh ước tính với thực tế. Tự nhiên phóng đại lỗi giữa ước tính và thực tế và công bố kết luận cho tất cả.

— Jonathan Cline IEEE
nguồn