Ai nên tham gia dự toán thời gian?

Trong một dự án CNTT:

1. Ai nên tham gia dự toán thời gian? Nhà phát triển, trưởng nhóm, chủ scrum và vv?
2. Phiếu bầu của ai nên được tính nhất?

Đó không phải là quá nhiều về những người liên quan như các kỹ năng cần phải có mặt:

• Một sự hiểu biết tốt về miền vấn đề - điều này đặc biệt quan trọng khi các yêu cầu không rõ ràng hoặc mức độ cao. Là một lập trình viên chưa bao giờ làm việc trong du lịch để ước tính công việc liên quan đến các lớp vé trên máy bay và họ sẽ cho rằng có 3 hoặc 4 (kinh tế, kinh doanh, đầu tiên, v.v.) nhưng nếu bạn làm việc trong du lịch, bạn sẽ biết có hàng tá Điều này có thể có nghĩa là Người phân tích nghiệp vụ hoặc người dùng chuyên gia có liên quan, mặc dù theo thời gian, chính các nhà phát triển sẽ xây dựng loại kiến ​​thức này.

• Một sự hiểu biết về công nghệ và công việc sẽ tham gia - thường là một nhà phát triển mặc dù một người quản lý có kinh nghiệm gần đây, người có niềm tin của nhóm thường có thể thực hiện công việc. Lý tưởng nhất là bạn có được người thực sự sẽ thực hiện công việc theo cách mà họ đã mua vào dự toán.

• Một sự hiểu biết về quá trình ước tính - đây là chìa khóa. Cần có một sự hiểu biết về cách thực hiện một ước tính hợp lý, làm thế nào để đảm bảo nó đúng, kiểm tra mức độ dự phòng thích hợp, kiểm tra đếm kép hoặc đệm quá nhiều. Thông thường, một PM, người quản lý phát triển hoặc nhà phát triển cao cấp sẽ mang đến điều này, mặc dù trong một số quy trình, một mẫu ước tính vững chắc có thể cung cấp hướng dẫn cần thiết.

Những kỹ năng đó có thể ở một người, mặc dù đôi khi họ sẽ cần ba hoặc nhiều hơn, nhưng điều quan trọng là phải đảm bảo rằng những kỹ năng đó có mặt, chứ không phải những người cụ thể có mặt.

Điều đó nói rằng, nói chung, mặc dù tôi sẽ tìm kiếm nhiều hơn hai người vì bạn muốn sự đảm bảo bổ sung mà hai hoặc nhiều người kiểm tra lẫn nhau làm việc mang lại.

Xét về số phiếu bầu được tính nhiều nhất, nó không hoạt động như vậy. Đó là một cuộc thảo luận và một cuộc đàm phán. Nếu một người quản lý nghĩ rằng các nhà phát triển ước tính quá cao, anh ta cần phải giải thích lý do và thách thức (không phải áp lực) nhà phát triển để biện minh cho điều đó và họ cần phải đạt được sự đồng thuận. Trong trường hợp bạn không thể đạt được thỏa thuận đó, tôi sẽ nói hai điều từ kinh nghiệm:

(a) Đừng đi theo con số bạn "muốn", nó chỉ yêu cầu sự cố và những gì bạn muốn không có tác động lớn đến việc công việc có thể được thực hiện nhanh như thế nào.

(b) Trong hầu hết mọi trường hợp tôi từng thấy nhà phát triển bị phán quyết theo ước tính, con số cuối cùng đã xuất hiện gần hơn với những gì nhà phát triển nghĩ so với bất kỳ ai cai trị họ - phần lớn là do họ bỏ qua điểm (a) ở trên.

(Điều đó nói rằng nhanh nhẹn tôi tin, và chắc chắn trong XP, quy tắc là các nhà phát triển kiểm soát các ước tính và đó là cuối cùng. Nếu người dùng muốn hạ thấp các ước tính, họ phải thay đổi yêu cầu cho một cái gì đó đơn giản hơn.)

Tôi không biết có câu trả lời nào phù hợp cho câu hỏi này không. Nơi tôi làm việc, thường có hai kỹ sư của nhóm sẽ thực hiện tính năng / sửa lỗi cung cấp ước tính. Vì vậy, hai kỹ sư mỗi người cung cấp một ước tính "tối thiểu", "tối đa" và "mong đợi". Chúng ta thường mong đợi cả hai ước tính đều nhất quán một cách hợp lý, vì vậy nếu chúng cực kỳ khác nhau, thì có thể cần phải thảo luận thêm (có lẽ một kỹ sư đã đưa ra giả định rằng người kia không, v.v.).

Trong tình huống của chúng tôi, không có "phiếu bầu" nào được tính như vậy. Chúng tôi thường chỉ tính trung bình hai ước tính (hãy nhớ rằng, nếu chúng chưa có trong cùng một sân bóng, thì chúng tôi sẽ từ chối cả hai và bắt đầu lại với các cuộc thảo luận, vì vậy, lấy trung bình không phải là một bước nhảy vọt). Các ước tính chỉ là ước tính, vì vậy chúng không cần phải chính xác .

Theo kinh nghiệm của tôi, việc ước tính có xu hướng được thực hiện bởi người có khả năng sẽ tự thực hiện nhiệm vụ. Các nhóm SCRUM nên cố gắng hoạt động chéo, nhưng sau một thời gian, một số loại nhiệm vụ nhất định thường được thực hiện bởi cùng một người.

Tầm quan trọng quan trọng là có được sự chấp nhận từ nhóm trên tất cả các ước tính. Nếu một nhà phát triển cảm thấy họ sở hữu một ước tính, họ sẽ làm việc để đáp ứng nó. Nếu các nhà phát triển nhận được một ước tính rằng họ không tự làm và không có đầu vào hoặc ảnh hưởng, họ sẽ không cảm thấy cùng trách nhiệm với nó và thấu chi sẽ được giải thích với "Tôi đã nói với bạn rằng sẽ mất nhiều thời gian hơn".

Một dự án có yêu cầu kinh doanh và thời hạn đến từ trên xuống. Đó là những "ước tính đã cho" cho lần lặp đầu tiên.

Các yêu cầu này phải được phân vùng cho các tác vụ lớn nhất có chi phí đã biết 100% (như "bật ghi nhật ký" = 2 giờ = "tải xuống log4j / SLF4J và cắm vào").

Việc ước tính nên được thực hiện ở mức cao nhất có thể đã có đủ chuyên môn kỹ thuật để thực hiện.

Các ước tính đã sửa phải đi ngược lại dưới dạng "tính năng hiển thị doanh nghiệp" = "lượng thời gian này" cho đến khi chúng đến được chủ doanh nghiệp ở mức phù hợp, có thể bỏ / thay đổi yêu cầu hoặc thư giãn thời hạn. Rồi lại xuống. Cho đến khi hội tụ cuối cùng. Trong thực tế, mọi người có xu hướng bỏ qua giai đoạn này hoặc đơn giản hóa nó, điều này có thể tạo ra rủi ro liên quan đến thời hạn và cơ hội bị bỏ lỡ.

Ai hoặc ai nên tham gia dự toán thời gian? Nhà phát triển, trưởng nhóm, chủ scrum và vv?

Tôi thích tất cả để có mặt trong ước tính thời gian và chúng tôi làm tương tự ở đây

Ai hoặc ai nên bỏ phiếu nhiều nhất?

Nhà phát triển nhưng vẫn là tất cả về nhóm làm việc lại

CÁC NHÀ PHÁT TRIỂN ĐƯỢC GIẢI QUYẾT VỚI THỰC HIỆN DỰ ÁN! KHÔNG AI KHÁC!

Các nhà phát triển thực hiện công việc thực tế và các nhà lãnh đạo nhóm phát triển là những người duy nhất có khả năng ước tính đúng thời gian thực sự sẽ mất bao nhiêu thời gian. Chỉ những lập trình viên quen thuộc với cơ sở mã thực tế mới có thể hiểu được những khó khăn và cạm bẫy tiềm ẩn có thể gặp phải trong quá trình phát triển. Mọi người khác là một "khán giả".

Ngoài ra, cách duy nhất để các nhà phát triển có thể tin tưởng để đưa ra ước tính chính xác là khi người kinh doanh tin tưởng họ và dựa vào chuyên môn của họ để nhà phát triển biết họ sẽ không bị phạt nếu ước tính của họ không đáp ứng mong đợi của doanh nghiệp.

Nguyên tắc chung: sẽ mất ít nhất 3 lần miễn là ước tính của bất kỳ người quản lý dự án hoặc doanh nhân nào không quen thuộc với những thách thức của sự phát triển và cơ sở mã được đề cập.

Là một người đã làm việc với tư cách là nhà phát triển cả tự do và là nhân viên trong các tập đoàn lớn trong gần 20 năm, tôi nói điều này với sự chắc chắn và lợi ích của rất nhiều kinh nghiệm cay đắng.