Làm thế nào để bạn đưa ra một ước tính thời gian hợp lệ cho một cái gì đó bạn chưa bao giờ thực hiện?

Question

Là một nhà phát triển mới là người duy nhất trong đội ngũ nhân viên, tôi đã phải đối mặt với một vài thách thức nhưng có thể khó khăn nhất là ước tính thời gian. Tôi strugle mỗi khi tôi phải đưa ra một dự toán dự án.

Câu hỏi của tôi sau đó là; Nếu tôi không có bất kỳ kinh nghiệm nào và tôi không có một người bạn đồng hành trong môi trường của tôi, làm cách nào để cung cấp một ước tính vững chắc? Tôi đã đọc bài viết của Joel Spolsky trên Evidence Based Scheduling nhưng làm thế nào điều đó có thể áp dụng nếu tôi không có bất kỳ bằng chứng nào ?

Tôi đánh giá cao mọi lời khuyên về chủ đề này.

Answer 1

Bạn không cung cấp ước tính chắc chắn. Bạn đưa ra câu trả lời hay nhất có thể và giải thích rằng nó là chỉ là một ước tính rất sơ bộ và lý do tại sao nó quá thô.

Nếu bạn thực hiện nó rất rõ ràng rằng:

• Bạn không thể đưa ra một ước tính chính xác
• Đó là hoàn toàn hợp lý mà bạn không thể đưa ra một ước tính chính xác bởi vì nó là một công việc khác với những gì bạn đã làm trước
• bạn sẽ cập nhật các ước tính như thời gian đi về và bạn làm quen với chủ đề tốt hơn

tôi nghĩ rằng bạn sẽ không sao. Bạn cần phải thực hiện những điều đó rất mặc dù rõ ràng bằng văn bản, do đó bạn không bị giữ lại ước tính sơ bộ sau này.

Answer 2

Bạn được phép nói "Tôi không biết, tôi không có đủ bằng chứng"

Sau đó, hãy tạo một số mẫu để lấy một số bằng chứng.

Sau đó trả lời câu hỏi.

Vì vậy, trên thực tế, bạn có thể ước tính thời điểm bạn có thể đưa ra ước tính.

Answer 3

Tôi lần đầu tiên dựa trên ước tính về độ phức tạp của vấn đề. Vấn đề lớn đến mức nào. Có bao nhiêu miếng có thể chạm vào hoặc yêu cầu. Điều này mang lại cho tôi một hướng dẫn chung. Sau đó, tôi luôn luôn đảm bảo rằng tôi thêm một yếu tố fudge 15-25% bởi vì bạn sẽ bỏ lỡ một cái gì đó.

Cuối cùng, bạn hãy nêu rõ rằng đây là ước tính sơ bộ dựa trên sự hiểu biết của bạn về vấn đề và cách bạn có thể giải quyết vấn đề.

Cũng không đưa ra bất kỳ ước tính sơ bộ nào theo từng bước chính xác. 4,5 giờ không phải là một ước tính sơ bộ. Nửa ngày là một ước tính sơ bộ.

Answer 4

IMO Joel là cách, cách tắt trong bài viết của mình, và kết luận và đề xuất của ông không dựa trên bất kỳ thực tế nào. (Xin lỗi, Joel) Về cơ bản, anh ấy nói rằng bạn sẽ có thể lên lịch công việc của mình cho tới các đơn vị thời gian hoặc ít hơn trước khi bạn bắt đầu. Nhưng thực tế là bạn không biết những gì các đơn vị công việc tất cả sẽ được (trong các hệ thống không tầm thường) trước khi bạn nhận được vào mã. Vì vậy, bạn không thể đến với một sự cố từng giờ về những gì bạn sẽ làm trước khi bạn thậm chí bật mui xe và có sự cố đó phản ánh những gì thực sự xảy ra với bất kỳ độ chính xác nào.

Đưa ra ước tính dự án là rất khó nếu bạn muốn ước tính đó có giá trị bất kỳ. Việc đưa ra các ước tính chính xác rất khó cho các lập trình viên bởi vì rất thường bạn không khám phá ra tất cả những phức tạp của dự án cho đến khi bạn nhận được dưới mui xe.

Vì vậy, giải pháp cho điều này là để có được dưới mui xe khi đưa ra các ước tính. Đối với các dự án nhỏ hơn, & sửa các lỗi này khá đơn giản:

• Tái tạo lỗi trên máy của bạn.
• Tìm mã đang gây ra lỗi.
• Tìm hiểu cách viết mã sẽ khắc phục lỗi.
• Ước tính thời gian bạn sẽ viết mã đó.

Khi tìm mã bạn phải viết, bạn nhất thiết phải khám phá phần lớn hoặc tất cả những phức tạp có thể đã loại bỏ ước tính của bạn.

Điều thú vị về phương pháp này là thời gian cần để tạo ước tính thường là 90% tổng thời gian để thực sự thực hiện công việc. Bạn thực tế phải làm công việc để đưa ra ước tính. Với các bản sửa lỗi đặc biệt, giải pháp thường dựa trên thứ tự của một dòng mã, vì vậy ước tính của bạn sẽ kết thúc sau 5 phút. Đó là tiền phạt bởi vì thời hạn có thể được thiết lập xung quanh ước tính như thế.

Khi bạn thực hành với điều này, bạn sẽ ngày càng tốt hơn khi "biết" sẽ mất bao lâu. Lúc đầu, bạn sẽ chỉ có thể "chỉ biết" các dự án nhỏ nhất sẽ mất bao lâu. Nhưng theo thời gian, bạn sẽ có thể ước tính các dự án lớn hơn &.

Answer 5

Cá nhân, tôi tưởng tượng một ước tính như một bản phân phối thống kê - và cố gắng truyền đạt những ý tưởng về độ lệch chuẩn với nó:

10 là 'nó có một cơ hội 50% là từ 8 đến 12'

Thật khó để có được chính xác hơn nhiều so với dự toán tổng thể dự án. Nó là hoàn toàn có thể để có được chính xác hơn (chia thành các câu chuyện độc lập cá nhân, chung ước tính mỗi, và thực hành nhanh nhẹn khác) - nhưng nó có một chi phí.

(Ngoài ra, ước tính nên không thể là một sự tham gia của trên phân phôi - nếu không nó được đệm đến chết và trở nên vô dụng)

Answer 6

Mặc dù nó là rất khó khăn, tôi ước tính trên dòng mã. Tham số này, có ý nghĩa về năng suất gần bằng không, vẫn mang đến cho bạn ý tưởng về sự phức tạp của một dự án.

Đo lường thực tế là trung bình, nhà phát triển có thể viết khoảng 200, tối đa 300 dòng mã mỗi ngày. Giữ vào tài khoản đó chỉ dành riêng cho mã hóa của một người đàn ông quân đội duy nhất:

• Một dự án nhỏ của 1000 dòng (logic) mã có thể được thực hiện trong một hoặc hai tuần
• Một dự án phức tạp trung bình 10.000 dòng (logic) mã có thể được hoàn thành trong hai hoặc ba tháng.
• Dự án lớn là 100.000 dòng mã (logic) yêu cầu ít nhất một vài năm

Để mã logic, bạn phải thêm kiểm tra, đã được bao gồm trong các ước tính trước đó. Để có một đầu mối về sự phức tạp, GIMP là 600.000 dòng mã, một dãy hạt nhân trong triệu hoặc nhiều hơn.

Để làm điều này, hãy thêm thực tế là nếu bạn đang làm việc thác nước, thời gian bạn cần phát triển mã thực sự là một phần nhỏ thời gian cần thiết để phát triển thông số kỹ thuật và thiết kế. Tôi ước tính thời gian 2/3 là dành cho thông số kỹ thuật + thiết kế và 1/3 còn lại sẽ được viết mã, thậm chí có thể nhiều hơn trên phần thiết kế + thông số kỹ thuật. Nó thực sự tốn thời gian. Vì vậy, theo dõi ước tính của bạn từ sự phức tạp, đến dòng mã, xem xét nhân lực bạn có và bao nhiêu họ có thể làm việc song song, và thêm chi phí của thông số kỹ thuật + thiết kế, bạn sẽ nhận được một ước tính rất sơ sài.

Tôi đề nghị bạn the mythical man month. Đó là một cuốn sách tuyệt vời về vấn đề này.

Answer 7

Nếu bạn từ chối đưa ra ước tính về điều gì đó bạn chưa bao giờ làm, có thể bạn sẽ làm điều đó trong suốt cuộc đời của mình. Trước tiên, hãy chia nhiệm vụ càng nhiều càng tốt, điều này sẽ giúp bạn làm rõ cách bạn sẽ làm điều đó. Có nhiều cơ hội hơn bạn sẽ có thể so sánh một mảnh của nhiệm vụ với một cái gì đó bạn đã làm trước đây. Đừng ngần ngại giao tiếp bằng cấp độ của bạn với người quản lý của bạn.

Answer 8

Đối với một lập trình viên có kinh nghiệm, ít nhất biết hệ thống và có một bộ yêu cầu hợp lý trước mặt họ, "tôi không biết" không phải là câu trả lời hợp lệ. Nếu bạn nói bạn không biết PHB của bạn sẽ tắt và áp dụng 1337 h4x0r sk1lz của họ và ước tính theo thứ tự "có vẻ như một miếng bánh, khoảng 1 giờ".

Bạn sẽ có thể chia nhỏ sự cố thành một loạt các sự cố nhỏ hơn mà bạn đã giải quyết trước đây và đưa ra một số lượng hợp lý cho từng phần. Chỉ ra rằng nó là rất thô và có thể thổi ra đáng kể một khi bạn nhận được để phân tích đầy đủ của vấn đề.

Chúng được gọi là 'ước tính' vì chúng thô ráp. Bạn có thể ước tính tốt hơn bằng cách thực hiện nó nhiều hơn và học cách rút kinh nghiệm quá khứ càng nhiều càng tốt. Nhớ yếu tố dự phòng (gián đoạn, chuyển đổi nhiệm vụ, khả năng bị bệnh, có thể làm lại, vv). Thông thường, thêm 50% làm cho ước tính gần hơn với nhãn hiệu.

Answer 9

Cung cấp ước tính sơ bộ và thực sự rõ ràng về điều đó.

Xác định chiến lược về cách bạn sẽ giải quyết dự án. Đặc biệt xác định các phần của hệ thống mà bạn có thể phân phối dưới dạng bản phát hành trung gian làm việc. Đặc biệt chú ý ở gần nhất trong số này bạn sẽ có thể phát hành đầy đủ chức năng, và nếu có thể đưa phần còn lại ra khỏi phạm vi (giữ một danh sách những điều này và bất cứ điều gì mà đi lên, được lên kế hoạch như một dự án tiếp theo).

Sử dụng lặp lại ngắn. Xem xét/phân tích cách các bản phát hành trung gian phù hợp với các lần lặp 2-6 tuần. Hãy xem xét các bài học về tài khoản này cho bạn và điều chỉnh ước tính tổng thể.

Tiếp tục với lần lặp đầu tiên và áp dụng những gì bạn tìm hiểu về các giả định bạn đã thực hiện. Làm thế nào bạn đang ở trong vòng lặp đầu thường chỉ đến một vấn đề trong các ước tính. Chống lại sự cám dỗ xem xét độ lệch trong phần ước tính của chi phí ban đầu, vì bạn có thể sẽ trì hoãn thời điểm mà bạn nhận ra các ước tính ở đâu. Lưu ý rằng tôi hiểu/đồng ý rằng vận tốc của dự án tăng theo thời gian, nhưng suy nghĩ về điều đó có xu hướng che giấu/trì hoãn các vấn đề.

Answer 10

Tôi làm việc này mọi lúc.Hầu hết mọi thứ tôi làm là lần đầu tiên. Làm cách nào để ước tính? Tôi đoán! Và sau đó tôi đoán lại. Và tôi tiếp tục làm điều đó mỗi khoảng thời gian delta mà một lịch trình được làm lại, bởi vì các kế hoạch dự án là lặp đi lặp lại và bạn chỉ là những gì bạn biết khi bạn đang làm nó. Tôi đoán là khá tho vì tôi có, sau nhiều năm, đã tìm ra những gì 'trông' dễ dàng và những gì 'trông khó'

Answer 11

Hãy thử Function Point Analysis. Đối với công cụ CRUD nó mang lại cho con số ballpark tốt. Đó là lợi thế chính là nó dựa trên những gì bạn sẽ thực hiện, nhưng trên những gì người dùng đã yêu cầu. Tuy nhiên, bạn sẽ cần tìm ra năng suất FP của bạn. Bạn có thể sử dụng các dự án trước đây trong cùng một ngôn ngữ để làm điều đó.

Bạn có thể sử dụng năng suất trung bình cho ngôn ngữ đích nếu bạn không thể xây dựng tập dữ liệu lịch sử. Nó sẽ cung cấp cho bạn một cái gì đó, không nhất thiết phải tiếp cận thực tế, nhưng ít nhất sẽ cho phép bạn so sánh các nỗ lực cho các dự án khác nhau.

Bây giờ, hãy nhớ rằng FPA không tốt về phần mềm nặng về mặt thuật toán và dựa trên AVERAGES, có nghĩa là bạn có thể đánh giá quá cao hoặc đánh giá thấp từng dự án.

Answer 12

đồng nghiệp của tôi luôn nói, trước tiên ước tính thời lượng dự án, sau đó nhân với hai cộng 1 và sau đó thêm các đơn vị cao nhất tiếp theo. vì vậy nếu câu trả lời của bạn là 3 ngày, sau đó bạn sẽ nói 7 tuần. đó là một trò đùa nửa, một ý tưởng sẽ là ước tính đầu tiên của dự án và sau đó khi kết thúc của nó thấy cách xa bạn, có lẽ bạn đang liên tục tắt bởi một bội số của 2 hoặc 3, hoặc bất cứ điều gì.

Answer 13

Mọi nhiệm vụ hoặc công việc không xác định luôn có thứ gì đó được biết đến ở một mức độ nhất định và dễ ước tính. Tôi chia tay và tôi đưa ra những ước tính ngay lập tức cho những điều tôi biết và những điều tôi cảm thấy tôi biết. Phần còn lại là trung thực được tuyên bố là một điểm mỏng và sau đó chúng tôi bắt đầu "mặc cả". Nếu người làm việc tin tưởng vào thẩm quyền của tôi, anh ta sẽ trừ những ước tính và rủi ro thô bạo của tôi - chúng tôi làm việc cùng nhau. Nó không bao giờ là một thất bại, đơn giản bởi vì tôi sẽ không bao giờ thực hiện một nhiệm vụ mà tôi không thể nhấc lên hoặc chạy xuống đất (cảm giác ruột?). Nếu người làm việc không tin tôi, tôi luôn khuyên bạn nên hỏi ai và tìm nơi nào để có lựa chọn tốt hơn. Sau đó chúng ta làm việc cùng nhau hay không. Hầu hết thời gian chúng tôi làm, nhưng mọi người đều ở bên an toàn. Tôi làm công việc của mình, "chuyên gia điểm mỏng" bị cắt giảm, các nhà quản lý rất vui và hài lòng của khách hàng. Có lẽ đó là một chút ngây thơ, nhưng nó hoạt động cho tôi :)