Cách ước tính một nhiệm vụ lập trình nếu bạn không có kinh nghiệm về nó [đã đóng]

Tôi đang gặp khó khăn khi quản lý yêu cầu ước tính về các tác vụ lập trình đang sử dụng các điều khiển của bên thứ ba mà tôi chưa có kinh nghiệm trước đó.

Tôi chắc chắn hiểu tại sao họ muốn ước tính, nhưng tôi cảm thấy như thể bất kỳ ước tính nào tôi đưa ra sẽ a) quá ngắn và khiến tôi trông xấu hoặc b) quá dài và khiến tôi trông xấu.

Tôi có thể đưa ra ước tính hoặc câu trả lời nào để quản lý loại bỏ họ để tôi có thể tiếp tục làm việc của mình!

Câu trả lời tốt nhất bạn có thể đưa ra là yêu cầu thời gian để tạo ra một nguyên mẫu nhanh chóng để cho phép bạn đưa ra ước tính chính xác hơn. Nếu không có một số kinh nghiệm với một công cụ hoặc một vấn đề, bất kỳ ước tính nào bạn đưa ra về cơ bản là vô nghĩa.

Ngoài ra, rất hiếm khi có vấn đề với việc đưa ra một ước tính quá dài. Các vấn đề không lường trước xảy ra, ưu tiên thay đổi và các yêu cầu được "cập nhật". Ngay cả khi bạn không sử dụng hết thời gian bạn yêu cầu, bạn sẽ có nhiều thời gian thử nghiệm hơn, hoặc có thể giải phóng "sớm".

Tôi luôn tỏ ra quá lạc quan trong những ước tính của mình, và điều đó có thể gây ra rất nhiều áp lực cho cuộc sống của bạn, đặc biệt khi bạn là một lập trình viên trẻ không có kinh nghiệm và sự tự tin để nói với sếp những sự thật khó chịu.

Tôi sẽ cho bạn biết một bí mật. Ngay cả khi bạn là một chuyên gia với công nghệ đó, ước tính của bạn có khả năng không chính xác cao. Đó là bản chất của con quái vật khi làm một việc gì đó vốn dĩ là một nhiệm vụ R&D. Thật không may, ban lãnh đạo thường cố gắng áp dụng một mô hình sản xuất và yêu cầu ước tính chính xác. Để minh họa quan điểm của tôi, hãy xem xét khó khăn trong việc ước tính chính xác hai nỗ lực sau:

A) Sản xuất một chiếc ô 11K khác giống hệt với chiếc ô 2K mà bạn đã sản xuất vào tháng trước. B) Thiết kế một loại ô mới và chế tạo chiếc ô đầu tiên.

Phát triển phần mềm là B, nhưng họ đang yêu cầu ước tính giả sử A.

Điều tốt nhất bạn có thể làm là chia nhiệm vụ thành các phần nhỏ nhất có thể (mỗi phần không quá 1/2 ngày) và sau đó nhân ba con số cuối cùng mà bạn nghĩ ra. (Phương pháp Spolsky)

Thay vào đó, Steve McConnell có cả một cuốn sách (có thể nói là nhiều cuốn) về khía cạnh này của kỹ thuật phần mềm. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (và những người khác) nói về hình nón của sự không chắc chắn . Về cơ bản, bạn cung cấp một ước tính trông giống như sau:

Công việc sẽ mất từ ​​3 đến 9 tuần trong đó nhiều khả năng là 4 tuần.

Khi dự án tiến triển, bạn có thể tinh chỉnh ước tính của mình. Khi bạn thực hiện nhiều công việc hơn và hiểu rõ hơn về nỗ lực cần thiết, bạn có thể tinh chỉnh ước tính của mình để chính xác hơn.

Nó có hiệu quả với tôi, nhưng nó có thể đòi hỏi một số nỗ lực để các bên liên quan khác trong dự án hiểu được quy trình.

Bạn có thể muốn xem xét đưa ra cả ước tính và mức độ tin cậy, tức là 50/50 rằng sẽ mất 3-6 tháng hoặc 6-9 tháng hoặc 75% cơ hội được thực hiện trong 9 tháng và 90% là bạn sẽ thực hiện trong một năm.

Một điều khác bạn có thể muốn xem xét là sử dụng phương pháp tiếp cận " sự khôn ngoan của đám đông ". Đi xung quanh và hỏi 25-50 người họ nghĩ sẽ mất bao lâu và tính trung bình các ước tính của họ. Mike Cohn's Planning Poker , tôi nghĩ, rất giống với điều này, mặc dù rất khó để lập kế hoạch chỉ với một nhà phát triển.

Chia nhỏ ước tính của bạn thành:

• Những điều đã biết ; bao lâu sẽ làm được những gì bạn biết cách làm. Bạn sẽ có thể đưa ra ước tính này với mức độ tin cậy cao.
• Những ẩn số đã biết ; bạn nghĩ sẽ mất bao lâu để thực hiện điều mà bạn không biết phải làm. Bạn có thể sử dụng một phương pháp như của dacracot để đưa ra các mức độ tin cậy khác nhau về ước tính này.
• Những ẩn số chưa biết ; đây là lỗ đen thời gian thực. Đây là những thứ sẽ xuất hiện vào những thời điểm không thích hợp nhất và cắn bạn vào mông. Cung cấp một phạm vi cho ước tính với sự biện minh dựa trên những rủi ro bạn dự đoán.

Đề nghị điều chỉnh ước tính và các mốc nhất định trên đường đi. Bất kỳ ẩn số nào chưa biết sẽ trở thành ẩn số đã biết, ẩn số đã biết sẽ trở thành ẩn số đã biết khi bạn tích lũy kinh nghiệm và ước tính của bạn đã biết có thể được điều chỉnh dựa trên tiến trình cho đến nay. Bạn có thể ước tính ban đầu, sau đó ước tính lại khi bạn hoàn thành khoảng 25%, sau đó lại ở mức 50%, sau đó lại ở mức 85%. Tại mỗi cột mốc, ước tính của bạn sẽ bắt đầu tập trung vào thời gian thực tế mà các nhiệm vụ sẽ thực hiện.

Tôi sử dụng một hệ thống ghi nhãn xác định cho các ước tính của mình ... lớp A, lớp B và lớp C.

Ước tính lớp C là ước tính đầu tiên họ nhận được. Nó được công khai là cộng hoặc trừ 50% do chưa biết. Nếu họ muốn tôi tiếp tục cho họ hạng B thì tôi cần tiền để nghiên cứu.

Loại B được cộng hoặc trừ 25%. Đôi khi điều này là đủ tốt và họ cho tôi tiền để xây dựng. Nếu không, ít tiền hơn và nhiều nghiên cứu hơn.

Hạng A được cộng hoặc trừ 10%, hạng cuối cùng và đi hoặc không. Nếu đó là một chuyến đi và tôi đi quá xa so với ước tính, tôi thú nhận thường xuyên và sớm.

Tôi nghĩ rằng nếu bạn xóa cụm từ "đang sử dụng các kiểm soát của bên thứ ba mà tôi không có kinh nghiệm trước đó", bạn có thể có mô tả tốt hơn về vấn đề lớn hơn của mình.

Nếu "Agile" đã dạy cho chúng ta bất cứ điều gì, thì đó là, nếu ban quản lý mong đợi bạn, trên cơ sở liên tục, ước tính các dự án theo cách đó và bạn sẽ "trông tệ" nếu bạn nói rằng nó không thể được cung cấp bởi vì bạn không có đủ thông tin, bạn đang trên đường đến THẤT BẠI.

Vấn đề lớn nhất sẽ là những vấn đề mà bạn không kiểm soát được và thậm chí bạn chưa xác định được. Bao lâu bạn nhìn lại và tự nói với chính mình "Chà, tôi đã đạt được ước tính của mình ngay trên nút - vào lần thử thứ ba, sau khi tôi tìm ra điều đó ... và rằng tôi cần phiên bản ... và dba sẽ được bật đi nghỉ một tuần và Giám đốc dự án sẽ cần tôi ... trong một tuần và vợ tôi đang mang thai và ... ".

Tôi rất cố gắng để nói rằng, "Tôi có thể xác định các yếu tố rủi ro quan trọng và đưa ra danh sách kiểm tra các sản phẩm được phân phối để kiểm tra chúng trong xx ngày. Tại thời điểm đó, tôi sẽ cung cấp cho bạn một ước tính gia tăng khác."

Và sẽ rất tuyệt nếu bạn có thể gợi ý rằng họ nên "Hãy nhấn mạnh rằng tôi không bao giờ cố gắng cung cấp cho bạn một ước tính đáng tin cậy về kiểu đó trong tương lai. Hãy sa thải tôi nếu tôi cố gắng."

(Nói quá, nhưng chỉ một chút thôi.)

Thậm chí đừng cố gắng ước tính. Không có cách nào ước tính của bạn chính xác. Sau khi tất cả chỉ là một ước tính.

Thay vào đó, tôi khuyên bạn nên chia tính năng thành các phần nhỏ (không quá 1-2 ngày) và cố gắng cung cấp các phần này dưới dạng mã hoạt động, hoàn chỉnh, có thể kiểm tra và có giá trị cho khách hàng / người quản lý. Bằng cách đó, anh ấy sẽ tự nhìn thấy sự tiến bộ của bạn hàng ngày. Điều này cũng có nghĩa là anh ta trên thực tế có thể quyết định ngừng phát triển khi đã hài lòng và coi như nó đã hoàn thành, mặc dù nó có thể chưa đạt được tất cả các mục tiêu.

Hãy xem các thực hành nhanh "Lập kế hoạch phát hành" và "Lập kế hoạch lặp lại" để biết thêm thông tin chuyên sâu về cách tiếp cận này.

Hãy nhớ rằng nếu bạn yêu cầu ước tính thời gian lớn hơn nhưng thực hiện không đúng thời hạn, sẽ tốt hơn so với ước tính thiếu và phải yêu cầu gia hạn.

Tôi sẽ cố gắng bắt chước một nguyên mẫu để bạn có ý tưởng tốt hơn về thời gian nó sẽ mất. Hãy trung thực với cấp quản lý của bạn để họ có thể dự trù cho những trường hợp chậm trễ bất ngờ trong lộ trình học tập.

BIÊN TẬP: Bạn cũng có thể xem liệu bạn có thể nhận được thời hạn "lặp lại" nhiều hơn hay không. Trong "Tư duy thực dụng và học hỏi", Andy Hunt đã chỉ ra một điểm tốt rằng mọi người là chuyên gia dự án ở gần cuối dự án và ít hiểu biết nhất ngay từ đầu. Sẽ không có nhiều ý nghĩa khi thực hiện tất cả thiết kế và ước tính thời gian của bạn ngay từ đầu khi mọi người đều ít hiểu biết nhất về dự án. Nếu bạn "lặp đi lặp lại" các thời hạn và giải quyết vấn đề theo từng phần nhỏ, bạn sẽ thành công hơn.

Ước lượng chính xác rất nhiều là kiến ​​thức của bản thân. Nếu bạn đã viết rất nhiều mã, nếu bạn phải học nhiều API, bạn sẽ bắt đầu cảm thấy những câu hỏi như:

• Tôi mất bao lâu để học một API mới?
• Tôi mất bao lâu để học một ngôn ngữ mới?
• Tôi mất bao lâu để học một bộ công cụ mới (trình biên dịch / liên kết / IDE)?
• Tôi mất bao lâu để thực hiện một nhiệm vụ điển hình?
• Tôi mất bao lâu để kiểm tra công việc của mình?
• Tôi mất bao lâu để triển khai công việc của mình?

Trong suốt quá trình đó, bạn nên hiểu những điều như:

• Có bao nhiêu lỗi điển hình bạn tạo ra và cách chúng được phân loại (ví dụ: dễ, khó, không thể)
• Có bao nhiêu phức tạp được đưa vào (ví dụ: cần phải cấu trúc lại vì thiếu API của bên thứ 3 hoặc API có lỗi; cần thiết kế lại vì hiểu sai về khả năng; các công cụ / quy trình xây dựng không chuẩn)
• Mất bao nhiêu thời gian do gián đoạn / các vấn đề bên ngoài

Dựa trên tất cả những điều này, bạn sẽ có thể phát triển một thứ gì đó sẽ mất bao lâu và có thể nêu các giả định của bạn ("Giả sử API là lành mạnh ...") ngay cả khi đối mặt với thông tin không đầy đủ một cách đáng tiếc.

Ước tính thời gian bạn cần để tìm hiểu đủ để ước tính tốt hơn, ví dụ: "Tôi không biết: Tôi chưa bao giờ làm việc với điều này trước đây. Có thể tôi sẽ đưa ước tính của bạn vào đây để tìm ra những gì bạn cần phải tìm hiểu về nó mà tôi phải biết trước khi tôi có thể cung cấp cho bạn một ước tính tốt về việc sử dụng nó để hoàn thành dự án của bạn . "

Khi lập trình, tôi luôn lấy những gì tôi thực sự nghĩ rằng nó sẽ lấy và nhân nó với 3 để đưa ra một ước tính. Nếu tôi nghĩ rằng tôi có thể làm một công việc trong 1 tuần, tôi nói với khách hàng sẽ mất 3 - nếu tôi nghĩ thực sự sẽ mất 3 tuần, tôi nói với khách hàng là 9 tuần.

Bằng cách làm này, tôi tự đặt cho mình "dưới hứa hẹn, giao quá mức" - nếu bạn làm được điều này thành công, cuộc sống của bạn sẽ tốt hơn nhiều và khách hàng của bạn sẽ vô cùng hạnh phúc.

Trong trường hợp của bạn, chắc chắn bạn sẽ muốn hiểu ít nhất MỘT SỐ hiểu biết về những gì bạn đang nghiên cứu trước khi đưa ra một ước tính. Có thể bạn thậm chí cần cung cấp ước tính về thời gian sẽ mất để đưa ra ước tính. Nhân với 3 giúp khách hàng hài lòng.

Hãy chia nhỏ nó thành những thứ mà bạn có chút kinh nghiệm. Hành động cắt nhỏ nó sẽ cho bạn ý tưởng tốt hơn về những gì bạn biết và những gì bạn không biết.

Một khi các mảnh đủ nhỏ để chúng có thể được xem như là các nhiệm vụ được xác định đơn lẻ, một vài trong số chúng sẽ hoàn toàn không thể ước lượng được. Đối với những người đó, có thể là nguyên mẫu trước, hoặc chỉ để cho bạn một khoảng thời gian hợp lý, tùy thuộc vào kích thước của mảnh. Nếu bạn nhận thấy rằng bạn có những mảnh lớn hơn không thể ước tính được sau 2-4 tuần làm việc, hãy quay lại cắt chúng trước.

Cuối cùng, bạn sẽ nhận được một số giải pháp công nghệ rất kỳ lạ (mà bạn nghĩ nên hoạt động, nhưng không biết chắc chắn), và rất nhiều việc phải làm để sao lưu những thứ đó, một khi nó hoạt động. Sẽ có một vài phần thiết kế bị thiếu, vì vậy tốt nhất bạn nên chọn một số thư viện nổi tiếng hoặc một thuật toán rất đơn giản cho phiên bản đầu tiên.

Nếu bạn không thể chia nhỏ các nhiệm vụ, thì bạn nên thuê một người có đủ kinh nghiệm có thể (vì sự thiếu kinh nghiệm của bạn cũng sẽ ám ảnh bạn theo những cách khác). Nếu bạn không thể thuê ai đó, thì bạn chỉ nên mặc cả trong một khoảng thời gian dài ngẫu nhiên (6 tháng đến 2 năm) và tiến thẳng vào một nguyên mẫu lộn xộn (cho đến khi bạn đã có đủ kinh nghiệm để biết điều gì là đúng và điều gì Sai lầm). Tuy nhiên, nếu cuối cùng bạn không muốn làm điều đó, điều quan trọng là không nên đùa cợt bản thân và nghĩ rằng bạn đang làm đúng "cách". Nguyên mẫu có nghĩa là bị vứt bỏ. Hy vọng rằng khi quá trình đếm ngược nguyên mẫu hoàn thành, bạn đã sẵn sàng để xây dựng nó thành hiện thực.

Paul.

Bạn chỉ cần đoán một con số bên ngoài và đánh giá ngay lập tức, cho họ biết rằng thông tin trong tương lai có thể ảnh hưởng đến ước tính của bạn, nhưng bạn sẽ cập nhật chúng.

Khi bạn đánh giá, hãy thông báo cho họ - thông qua tài liệu được xuất bản trên web hoặc bản cập nhật hàng tuần, nhưng luôn bao gồm "ngày kết thúc ước tính" được cập nhật và lý do (nếu có) cho các phần mở rộng.

Hầu hết các nhà quản lý nên hiểu rằng - bằng cách yêu cầu ngày kết thúc, họ thực sự nói rằng "hãy cho chúng tôi một số ý tưởng về cách chúng tôi có thể lập kế hoạch lịch trình của mình" và "đừng chỉ diễn ra mãi mãi".

Nếu cuối cùng bạn phải kéo dài hơn một hoặc hai lần, hãy đánh giá lại toàn bộ lịch trình của bạn dựa trên kiến ​​thức mới mà bạn thu hút được khi ước tính.

Tôi muốn thêm vào những gì RB đã nói, khi tôi thấy mình ở trong tình huống này, tôi ước tính sẽ mất bao lâu với các công cụ mà tôi quen thuộc và sau đó nhân đôi ước tính đó để xây dựng trong một số đường cong học tập.

Phần quan trọng được giao để quản lý ước tính là một phỏng đoán , nếu họ nhấn cho một ước tính chính xác hơn hoặc nếu họ cố gắng - Thiên Chúa thân yêu - bán bạn trong một thời gian giới hạn (chắc chắn nó sẽ chỉ mất bạn 2 ngày để xây dựng Starship Doanh nghiệp, bạn là bạn tốt) BẤM VÀO SÚNG CỦA BẠN , không thỏa hiệp ước tính của bạn hoặc thực tế là nó không đáng tin cậy.

Nếu ban quản lý ghi đè lên bạn và hộp thời gian nhiệm vụ, ví dụ như "Chà, nó phải được hoàn thành trong 2 ngày", hãy cho họ biết đó là ước tính của họ , chính xác cũng đáng tin cậy như ước tính của bạn.

Nhận tất cả những điều này bằng văn bản.

Tôi xử lý khá nhiều ước tính trong công việc của mình và đó là một thử thách thực sự. Một trong những thách thức lớn nhất của tôi là ước tính mất bao lâu để một nhà phát triển khác hoàn thành một nhiệm vụ mà không biết nhà phát triển đó sẽ có kỹ năng như thế nào.

Mặc dù bạn có thể thấy một số thành công ban đầu với phương pháp "hứa ​​hẹn, giao quá nhiều", bạn sẽ thấy rằng theo thời gian, bạn sẽ bị những người khác theo trường phái tư tưởng "hứa ​​quá, giao dưới" trả giá cao hơn. Thiếu chính xác sẽ quay lại cắn bạn theo cách nào đó. Độ chính xác gắn liền nhiều với kinh nghiệm và hạn chế số lượng ẩn số với công nghệ.

Một điều tôi muốn đề xuất là có một số ý tưởng về loại ngân sách mà bạn ước tính sẽ hoạt động theo. Nếu bạn có ngân sách nhỏ, đừng phát cuồng với công nghệ không quen thuộc và gắn bó với những gì bạn biết. Nếu ngân sách của bạn linh hoạt hơn một chút, thì bạn có thể đủ khả năng để thử nghiệm một chút.

Cũng nhận ra rằng sẽ có một số nhiệm vụ mà tất cả những gì bạn có thể cung cấp là một Wild Ass Guess (WAG). Đối với những điều này, bạn nên đặt thời gian tối thiểu cho ước tính của mình và nói rõ rằng bạn không biết giá thầu tối đa là bao nhiêu. Thông thường, loại ước tính này là lý do đủ để ban quản lý cắt bỏ một số tính năng / yêu cầu nhất định.

Đó là một kỹ năng không thể thiếu mà cả người quản lý dự án và lập trình viên có thể có (và tất nhiên có thể thành thạo!), Tôi đã tìm thấy một bài báo, Ước tính các nhiệm vụ phát triển phần mềm được thực hiện (một chút) Dễ dàng hơn , mà tôi hy vọng sẽ giúp ước tính tốt hơn các nhiệm vụ của dự án.

Tất cả các câu trả lời trên đã bao gồm khá nhiều thứ liên quan đến việc tự đưa ra ước tính.

Một điều tôi muốn nhấn mạnh là hãy theo dõi ước tính của bạn (một bảng tính Excel nhỏ a la Joel hoặc thậm chí là một tài liệu Notepad nếu nó rất đơn giản) và vào cuối mỗi ngày, hãy cập nhật điều này với số liệu chính xác nhất mà bạn có thể cung cấp. . Ngay cả khi bạn không cần phải chuyển lại điều này cho sếp của mình, việc cập nhật thông tin này sẽ giúp bạn có ý tưởng tốt hơn về cách mọi thứ đang tiến triển và quan trọng hơn là bạn sẽ hiểu rõ lý do tại sao. ước tính của bạn thay đổi khi công việc tiến triển .

Làm điều này sẽ giúp bạn ước tính tốt hơn trong tương lai, cho cả công nghệ cụ thể này và những công nghệ khác mà bạn chưa sử dụng trước đây, đơn giản vì nó yêu cầu bạn ở một mức độ nào đó phải nhận thấy khi kỳ vọng của bạn thay đổi đều đặn và tìm ra lý do tại sao điều đó xảy ra .

Ước tính thời gian diễn ra một thứ gì đó là một phần công việc của bạn. Vì vậy, miễn là nó được hiểu là một ước tính chứ không phải là thời hạn, bạn sẽ không có gì phải lo lắng. Không có ai tốt hơn để cung cấp một ước tính hơn người sẽ viết mã. Nếu bạn không thể cung cấp một ước tính tốt thì bạn cần thông báo cho ban quản lý về rủi ro đi kèm với ước tính xấu của bạn để họ có thể xem xét lại liệu có đáng để chấp nhận rủi ro khi lập trình chống lại các kiểm soát của bên thứ 3 không xác định này hay không.

Đó là một tình huống rất phổ biến: sự cần thiết phải đối phó với những điều chưa biết. Một cách hữu ích để giải quyết vấn đề này là nhận ra rằng bên cạnh các nhiệm vụ lập trình thực tế, bạn còn phải học một số công việc - và ban quản lý nên nhận thức được điều đó.

Khi bạn ở trong tình huống như thế này, dự án đột nhiên trở thành dự án R&D và thời gian dài hơn bình thường sẽ không khiến bạn trông tệ, vì bạn đang học và sản xuất chương trình. Tôi không biết bạn đang học nhanh đến mức nào hoặc bạn có nguồn lực nào để giải quyết bất kỳ vấn đề nào bạn có thể tìm thấy (Stack Overflow là một trong những tùy chọn bạn có).

Tôi muốn nói rằng bạn nên ước lượng như bình thường và sau đó nhân với 1,5 (nếu bạn là người học nhanh và có quyền truy cập vào các nguồn để giải quyết câu hỏi của mình) hoặc với 2,5 nếu bạn là người học trung bình và chỉ dựa vào bản thân.

Tôi hi vọng cái này giúp được!

Cố gắng hết sức để chia nhiệm vụ thành các phần có thể quản lý được. Với một số may mắn, có những nhiệm vụ cụ thể liên quan đến thành phần bên thứ 3 có liên quan và những nhiệm vụ khác ít kết hợp hơn (và do đó dễ ước tính hơn). Cung cấp cho ban quản lý các ước tính tách rời và chỉ ra vị trí của các ước tính không chắc chắn nhất.

Tôi hoàn toàn đồng ý với bất cứ ai đề xuất chơi xung quanh và tạo mẫu một số. Đặt một hộp thời gian cố định cho hoạt động tạo mẫu. ("Trước tiên, tôi cần hai ngày để làm tốt hơn phần ước tính này.")

Bạn có thể đưa ra một phạm vi? 40-60 giờ, đại loại như vậy?

Các nhiệm vụ càng nhỏ thì càng khó, nếu bạn có thể nhóm chúng lại, bạn sẽ có một chút "cẩu thả" hơn vì các lỗi có thể cân bằng vào cuối dự án.

Nhìn vào bất kỳ lĩnh vực nào bạn có kinh nghiệm và sử dụng nếu như hướng dẫn. "Lần trước cần tạo một tính năng thay đổi cơ sở dữ liệu, tôi đã lấy X". Chúc may mắn.