Đánh giá các ước tính phần mềm: các dấu hiệu chắc chắn của các số liệu không thực tế?

Question

Trong khi trả lời “Dealing with awful estimates” được đăng bởi Ash Tôi đã chia sẻ một số mẹo mà tôi đã học và sử dụng cá nhân để phát hiện các ước tính yếu. Nhưng tôi chắc chắn phải có nhiều hơn nữa!

Điều gì để sử dụng trong kịch bản khi cần đánh giá nhanh dự toán phần mềm do bên thứ ba biên soạn (đồng nghiệp, đối tác kinh doanh hoặc công ty bên ngoài)?

Dấu hiệu rõ ràng và không rõ ràng của các ước tính phần mềm yếu có thể được phát hiện mà không có nhiều kiến ​​thức chi tiết về nhiệm vụ trong tầm tay?

Answer 1

• Một người đã thực hiện ước tính, thay vì sử dụng ước tính dựa trên sự đồng thuận (để hiểu đầy đủ phạm vi yêu cầu ngụ ý) chẳng hạn như Wideband Delphi.
  • Đặc biệt đúng nếu người thực hiện ước tính không phải là người thực hiện việc triển khai !! - Tôi từng làm việc trên một dự án được ước tính bởi một người khác là 60 ngày trước khi bất kỳ yêu cầu nào đã được đưa ra. Cho phép chỉ nói rằng tôi không phải là một chú thỏ hạnh phúc
• Không có thời gian cho tài liệu.
• Không có thời gian cho đoạn đường nối (về mặt học tập và quy mô nhóm).
• Không có danh sách rủi ro và tác động của chúng đến khoảng thời gian.
• Không có bộ đệm cho những điều bất ngờ - về các yêu cầu phá vỡ muộn và rủi ro.

Answer 2

Một phương pháp phỏng đoán tốt là xem thời gian thử nghiệm có xấp xỉ cùng thời gian phát triển hay không. Đó là một dấu hiệu tốt cho ước tính.

Nếu họ không thể cung cấp cho bạn chi tiết về ước tính thì đó là điều xấu. Thường là một dấu hiệu của rất nhiều điều nhỏ có thể đã bị lãng quên. Họ không cần phải cung cấp sự cố ban đầu hoàn chỉnh, chỉ là một sự cố như:

• yêu cầu
• phát triển
• thử nghiệm
• đóng gói và triển khai
• , vv

họ nên sử dụng mẫu chuẩn để tính toán ước tính của chúng. Họ không cần một số trong mỗi cột, nhưng họ làm mẫu để liệt kê tất cả các nhiệm vụ có thể. Bằng cách đó, các mẫu có thể được sử dụng để chạy bộ tâm trí của người dân khi làm việc trên các ước tính.

Nếu ước tính quá chính xác, ví dụ: 0,25 giờ gia tăng, sau đó, đối với tôi, là một mùi hôi.

Nếu thiếu những thứ như yêu cầu chụp, thử nghiệm, triển khai và bàn giao cho bất kỳ nhóm Ops nào? Nếu bất kỳ cái nào trong số đó bị thiếu, đó là thứ sẽ quay trở lại và cắn bạn.

Chỉnh sửa: Một điều khác cần lưu ý là các tác vụ "hoàn thành vĩnh viễn 90%" cũ. Bạn nhận được cập nhật tiến độ sau khi cập nhật tiến trình liệt kê một nhiệm vụ là "hoàn thành 90%". Điều đó không tốt!

HTH

cổ vũ

Answer 3

Ước tính có dạng 3, 6, hoặc 12 tháng (về cơ bản bất kỳ vòng số) khói đoán. Thông thường khi bạn đoán bạn chọn một số vòng tròn lớn hơn bạn nghĩ rằng nó sẽ mất - quý, nửa năm, vv - là những nghi phạm thông thường. Tôi thích các ước tính về các bước lặp phát triển thực tế (bất kể kích thước của chúng).

Answer 4

Có hai loại ước tính: ước tính tác vụ và ước tính dự án. Bạn có thể xem chúng như những hình ảnh lớn và nhỏ.

dự án được cấp thiết cao (granularity không nhỏ hơn ngày thường) và phải bao gồm những thứ như:

• kiến ​​trúc cấp cao;
• Thời gian để thử nghiệm;
• Tăng thời gian lên;
• Lỗi quy trình;
• Thời gian cho tài liệu;
• Đào tạo có liên quan;
• Giả định;
• Phụ thuộc (ví dụ: nhóm A không thể làm những gì họ cần cho đến khi đội B cung cấp giai đoạn 1);
• Đường dẫn quan trọng (phần nào có khả năng xác định xem dự án có trượt hay không); và
• Rủi ro.

Càng nhiều thứ bị thiếu, ước tính không thực tế hơn (hoặc nguy hiểm).

Loại thứ hai của ước tính công việc, thường là mức thấp hơn nhiều. Đối với loại ước tính này, nó chỉ đơn giản là một phân tích công việc (không có nhiệm vụ nào lớn hơn 5 ngày).

Những điều này không có xu hướng giải quyết các mục trên nhưng một số có thể có liên quan, chẳng hạn như các giả định về các quyết định chưa được đưa ra (ví dụ như phần cứng sản xuất). Nó cũng có thể là giá trị xác định những người có thể và không thể làm nhiệm vụ do kinh nghiệm có liên quan, kiến ​​thức cơ bản hoặc kỹ năng (như người đó hoặc những người có thể sẽ bị overcommitted).

Các bài đăng khác đã đề cập đến thời gian thử nghiệm phải bằng hoặc vượt quá thời gian dev. Tôi mạnh mẽ không đồng ý với điều này. Tôi đã nhìn thấy 8 giờ dev nhiệm vụ kết quả trong thời gian thử nghiệm hơn 100 giờ và 80 giờ dev nhiệm vụ dẫn đến ít hơn 2 giờ thử nghiệm. Trong cả hai trường hợp, thời gian thử nghiệm là hoàn toàn hợp lý. Không có mối tương quan tuyệt đối giữa hai. Tốt nhất, có một kết nối lỏng lẻo.

Answer 5

là gì rõ ràng và không quá dấu hiệu rõ ràng của phần mềm yếu ước tính có thể được phát hiện mà không nhiều kiến ​​thức chi tiết về nhiệm vụ tại tay?

Ước tính được đưa ra mà không có nhiều kiến ​​thức chi tiết về nhiệm vụ trong tầm nhìn nói chung là không tốt.

Có lẽ cách tiếp cận chung mà bạn có thể thực hiện là kiểm tra các mục trong yêu cầu tương ứng với các mục trong ước tính. Nếu bạn muốn kiểm tra nhanh các kích thước tương đối, nếu có một ước tính 100 từ được đưa ra cho một bản tóm tắt từ 100.000 thì nó không có cơ hội đúng.

Ngoài ra (như những người khác đã nói) kiểm tra xem phân tích, mã hóa, gỡ lỗi, thử nghiệm, tích hợp, dự phòng, v.v ... được đề cập. Nó cho thấy một số suy nghĩ đã đi vào nó.

Đạt được thành công và đăng xuất tiêu chí ở các giai đoạn khác nhau là một dấu hiệu tuyệt vời. Nếu họ có một điểm xác định được thực hiện 10% ít nhất là nếu ước tính sai lầm bạn biết sớm và có cơ hội thích nghi. Nếu không có trạm kiểm soát cho đến khi "kết thúc", bạn có thể không biết rằng bạn đang ở phía sau cho đến ngày đó là hit.

Answer 6

• là trình biên dịch dự toán sẵn và sẵn sàng thảo luận với dự án thành viên cao cấp khác? Nếu không, đó thường là một mối quan tâm .

• Là dự toán gửi đến khách hàng trước kinh nghiệm và kỹ năng của đội ngũ nhân viên phát triển là biết. Ước tính hai điểm có thể giúp nhưng chỉ ở một mức độ nào đó.

• Trước khi có cơ hội để xem ước tính, bạn được thông báo rằng bạn cam kết cung cấp tất cả các chức năng được mô tả bởi một ngày cụ thể.

(Cám ơn đáp lại câu hỏi của tôi, bằng cách này.)

Answer 7

Một cách hữu ích khác để đánh giá dự toán là so sánh nó với các nỗ lực thực tế đã được chi cho các dự án trước của loại hình tương tự. Dữ liệu tốt nhất để so sánh sẽ là dữ liệu nỗ lực của các dự án trước đây mà tổ chức đã thực hiện. Nếu không có dữ liệu lịch sử của tổ chức, bạn có thể thử điểm chuẩn ước tính dựa trên điểm chuẩn toàn ngành.

Tôi cũng sẽ nói nếu ước tính được trình bày dưới dạng số tuyệt đối duy nhất (giả sử 180 ngày) thì đó không phải là dấu hiệu tốt. Một số tuyệt đối duy nhất sẽ chỉ ra rằng ước tính là nhiệm vụ sẽ được hoàn thành với xác suất 100% trên dữ liệu đã cho. Các ước tính được trình bày trong một phạm vi (nói 130 đến 180 ngày) sẽ chỉ ra rằng phạm vi mà nhiệm vụ có thể được hoàn thành.

Phần lớn những gì tôi đã viết ở trên tôi ghi bản quyền của cuốn sách:

Phần mềm Dự toán: Làm rõ Black Art bởi Steve McConnell

Answer 8

tôi kiểm tra dự toán so với đồng nhân quyền lực. Mặc dù không phải là phương pháp phỏng đoán rất chính xác, nhưng rõ ràng nếu một số công việc lớn chỉ có một hoặc hai nhà phát triển được gán cho nó, nhiệm vụ đó không được ước tính chính xác

Answer 9

Ước tính tốt sẽ có sự cố tốt, liên quan đến tất cả các giai đoạn của dự án.

Nó gần như chắc chắn sẽ không kết thúc vào một ngày thuận tiện cho doanh nghiệp.

Nó sẽ bao gồm các rủi ro của các loại khác nhau.

Nó sẽ được trình bày theo khoảng tin cậy, hoặc là ngầm định (10-12 tháng) hoặc bằng cách sử dụng đơn vị lớn (khoảng bốn phần tư).

Nó sẽ được thực hiện bởi ai đó có trách nhiệm thực hiện dự án, tốt nhất là nhiều hơn một người như vậy.

Nếu có sự chậm trễ khi bắt đầu, sẽ có sự chậm trễ ở cuối (được biểu thị từ 10-12 tháng kể từ khi bắt đầu hoặc khoảng 1Q2010 nếu chúng tôi bắt đầu ngay bây giờ, không phải vào tháng 1 năm 2010 khi dự án chưa bắt đầu).

Giả định và phụ thuộc sẽ được liệt kê rõ ràng và nổi bật.

Chỉnh sửa: Một phần của điều này phụ thuộc vào giai đoạn của dự án. Một ước tính sớm nhưng chính xác là một dấu hiệu cảnh báo, đặc biệt nếu không có khoảng tin cậy được gán. Reeks của một ước tính Procrustean.

Ngoài ra, hãy xem các phương pháp phát triển khác. Một dự án có thời gian có thể có lịch trình cứng nhắc và tùy ý, nhưng bộ tính năng sẽ linh hoạt.

Answer 10

Không ai nói điều đó, vì vậy tôi sẽ làm như vậy. Câu trả lời rõ ràng là nếu bạn có ước lượng lịch trình phần mềm thì đó là một dấu hiệu chắc chắn về các con số không thực tế. Có, có rất nhiều phương pháp để ước tính phần mềm nhưng không có phương pháp nào chính xác trong bất kỳ cách nào, hình dạng hoặc hình thức nào. Điều thường xảy ra là thời hạn được đặt. Nếu nhiệm vụ vượt quá ước tính thì thời gian thêm sẽ được dùng để làm cho kết quả tốt hơn. Nếu nhiệm vụ không được ước tính thì có điều gì đó được hy sinh để đáp ứng việc giao hàng (như thử nghiệm và các tính năng).

Tôi biết câu trả lời này không phải là những gì mọi người muốn tin, nhưng việc ước tính luôn luôn là một phỏng đoán. Thường xuyên hơn không, nhà phát triển thậm chí không thể dự đoán số tiền họ sẽ đạt được vào cuối ngày. Bạn đang mong đợi họ đoán những điều tháng/năm xuống con đường về một cái gì đó mà họ thậm chí không chắc chắn những gì đang thực sự tham gia được nêu ra.

Câu trả lời thực tế duy nhất cho câu hỏi của bạn không dễ đưa ra kết quả không thực tế sẽ sử dụng bảng tính dựa trên lịch sử trước đó tại công ty bạn. Thật không may, điều đó sẽ không tính đến các nhiệm vụ mà người ước tính đã bỏ qua. Ít nhất điều này có thể cung cấp số lượng ballpark.

Trừ khi bạn phát triển hệ thống tắt chính xác của cùng một hệ thống chính xác lặp đi lặp lại, thì bất kỳ ai nghĩ rằng họ đã tìm ra điều này là tự lừa dối bản thân. Có quá nhiều biến liên quan.

Answer 11

• Ước tính số quản lý muốn được thông báo?
• Liệu ước tính có phù hợp với ngày giao hàng được lên kế hoạch cho lần phát hành tiếp theo không?
• Phần thưởng quản lý những người cung cấp tin tốt hơn sau đó mọi người có tin xấu không?
• Ước tính số được chuẩn bị trước khi biết ai sẽ làm việc với dự án?
• Đã làm ai đó muốn bit đó thực hiện chức năng chuẩn bị ước tính ?
• Có lịch sử của phần mềm bị trễ không?
• Có bình thường đối với nhà phát triển được di chuyển sang các nhiệm vụ khác dù là một dự án?
• Có một số hoặc tất cả các nhà phát triển đã từ bỏ trên nhận xét về ước tính xấu là lãng phí thời gian?

Tính số câu hỏi mà bạn nhận được “có” hoặc “có thể” câu trả lời. ...

Nếu bạn nhận được hầu hết là “không” câu trả lời cho các câu hỏi trên, sau đó nó có thể là giá trị xem xét dự toán chi tiết để xem liệu nó có bao gồm các tác vụ mà những người khác được liệt kê trong chuỗi này hay không.

Answer 12

Nếu bạn thấy một hoặc nhiều trong số này, bạn có thể có một ước tính xấu:

• ước lượng điểm đơn: một ước tính nên được kết hợp với một phạm vi ngày càng tốt hoặc một giá trị niềm tin
• Thiếu granularity của nhiệm vụ: một nhóm nhiệm vụ lớn thường chỉ ra rằng chức năng không được hiểu rõ (đặc biệt là một vấn đề do các vấn đề được hiểu kém thường không được ước tính)
• Không có biểu hiện giả định và/hoặc rủi ro
• Không đầy đủ mọi nỗ lực được xếp hạng cho các mục bị bỏ qua hoặc đánh giá thấp (ví dụ: xây dựng tập lệnh, tài liệu, triển khai, v.v.)

Tôi đồng ý với sateesh, tôi thực sự thích Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen của Steve McConnell. Ông có một số danh sách kiểm tra hữu ích khi xem xét và/hoặc chuẩn bị các ước tính.

Answer 13

Bất kỳ những điều sau đây:

• Đây là một dự án lớn và không có một chiến lược cấp cao ngắn mô tả
• Không có một tầm nhìn rõ ràng, ngắn gọn và súc tích về những gì muốn trở thành đạt được với dự án
• Dự án không có cấu trúc xung quanh giá trị kinh doanh đang được phân phối dần dần
• Nhóm đang cố đưa ra các ước tính "chính xác" cho một dự án lớn, đi vào (hoặc đã được thực hiện với) một giai đoạn phân tích dài? (thay đổi sẽ đến, và thường sẽ ảnh hưởng đến các ước tính đó theo cách không thể định lượng dễ dàng mà không cần nỗ lực nhiều hơn)
• Ước tính "chi tiết" cho toàn bộ dự án (liên quan đến trước)
• Có aren ' t ước tính chi tiết cho giai đoạn đầu tiên, hoặc có cái gì đó sai trong những người.

Answer 14

Wow ... Tôi thực sự thích câu trả lời của bộ công cụ.

Và tôi đồng ý rằng bất kỳ ước tính nào đều thiếu sót, bởi vì nó giả định rằng trình ước lượng có nhiều cách để biết cách giải quyết vấn đề hơn bất kỳ bộ ước lượng nào thực sự thực hiện khi dự án được ước tính. Tuy nhiên, tôi nghĩ bạn vẫn cần ít nhất ước tính kích thước của ngọn núi trước khi bạn bắt đầu. Một số người nghĩ rằng liệu nó có giá trị cố gắng để làm điều đó nên đi trước bất kỳ nỗ lực nào và đó chính là bản chất của ước tính.

tôi đã đưa ra một vài chỉ số nhiều hơn một ước tính nguy hiểm:

• Không tham chiếu chéo - Nếu ước tính không thể được xác nhận ít nhất hai cách khác nhau, nó có thể sẽ là không đáng tin cậy . Ví dụ, các ước tính cuối cùng tôi đã thực hiện tôi đã có thể phá vỡ công việc thành các khối nhỏ tính năng, và xem xét bao lâu nó được đưa đội của chúng tôi để làm các tính năng tương tự như phạm vi. Sau đó, tôi đã có thể xem xét tổng của các chi phí này và xem phạm vi lớn như thế nào so với các dự án khác mà tôi đã làm việc. Đó là hai cách để xác nhận.
• Nền của trình ước tính - nếu đây là ước tính phần mềm được thực hiện bởi một anh chàng phần cứng không bao giờ viết mã - rất sợ. Tinh vi hơn - nền tảng của người ước tính càng gần với miền công nghệ và vấn đề của dự án thì càng tốt.
• Chi tiết - như đã nói một vài cách khác nhau trong một vài bài đăng khác nhau - tôi muốn xem chi tiết cho cả hai tính năng riêng lẻ cũng như các tác vụ cần thiết để hoàn thành từng tính năng. Hầu hết các ước tính tôi thấy không hiển thị chi tiết trong bản trình bày chính thức, nhưng nếu bạn hỏi người đã thực hiện ước tính, họ sẽ có một tệp ở đâu đó. Hy vọng rằng nó không phải là mặt sau của một khăn ăn giấy màu với bia và nước sốt cà chua. :)
• Giả định được ghi nhận - bất kỳ công cụ ước tính nào cũng sẽ phải đưa ra một số giả định về nhiệm vụ. Những tài liệu này phải được ghi lại ở đâu đó, tốt hơn trong các thủ tục giấy tờ chính thức. Tôi luôn có chút lo lắng khi tôi thấy một đề xuất ngắn với nhiều giả định không được ghi nhận. Hoặc là họ đã suy nghĩ và không thông báo cho khách hàng, hoặc họ không nghĩ đến. Tôi không thực sự chắc chắn cái nào tệ hơn. Nó đi mà không nói rằng các giả định cũng nên được hợp lý.
• Vòng đời cân bằng - Tuy nhiên, nhiệm vụ được chia nhỏ, tỷ lệ thiết kế, mã và thử nghiệm là gì? Làm thế nào về tài liệu, tích hợp với các hệ thống bên ngoài và hỗ trợ phát hành sau? Làm thế nào về những điều thêm mà rất quan trọng (quản trị hệ thống, CM rất kinh nghiệm, nỗ lực quản lý)?
• Slack - Tôi chắc rằng các daemon doanh nghiệp rẻ tiền sẽ đến và đuổi tôi đi, nhưng lịch biểu và chi phí sẽ có một số chậm chạp. Nếu ước tính có vẻ đầy tham vọng và gây áp lực cho một con mắt có kinh nghiệm, nó có thể là quá thấp. Ước tính gần như không bao giờ quá cao.

Answer 15

Làm cách nào để người đó ước tính với những người thực hiện công việc?

Tôi thường thấy ước tính nơi có một người chung làm công việc, mặc dù nhóm được tạo thành từ các cá nhân có nguồn gốc rất khác nhau. Nhiều khả năng các nhiệm vụ và đặc sản không xếp hàng một cách hoàn hảo và bạn có một lập trình viên C++ serverside, người cuối cùng cũng làm gui hoặc cơ sở dữ liệu của bạn ... Đôi khi người quản lý của nhóm không thực sự đánh giá cao điểm mạnh của thành viên nhóm, nếu anh ta được yêu cầu tự mình đưa ra ước tính bởi vì nhóm của anh ấy bận rộn với dự án trước, bạn sẽ thấy rằng công việc được đề cập thực sự chỉ phù hợp với một phần của nhóm (không có động lực, thiếu kỹ năng, v.v.)

Answer 16

Tôi hoàn toàn đồng ý với Dunk, dấu hiệu đầu tiên của ước tính xấu chỉ là sự hiện diện của lịch biểu trả trước chi tiết lớn. Ước tính chính xác, ước tính, nếu không chúng tôi sẽ gọi cho chúng là chính xác hiển thị. Vì vậy, họ không bao giờ nên được sử dụng một mình trong việc quản lý một dự án.

Điểm quan trọng nhất để xem xét không phải là chính xác dự toán nhưng quán. Nếu một bên thứ ba đang thực hiện ước tính cho bạn, sau đó yêu cầu xem lịch sử thành công hay thất bại của họ, hãy nói chuyện với khách hàng trước đây của họ và xác định độ tin cậy của họ.

Tất cả những gì được nói, từ quan điểm Agile, một số cách chúng tôi cố gắng đạt được các ước tính nhất quán hơn trong một dự án là;

• Sử dụng tiêu chuẩn định kích thước tương đối (S, M, L, XL) thay vì dựa trên thời gian (ngày lý tưởng).
• tập trung vào độ phức tạp không phải thời gian
• Luôn luôn sử dụng nhóm ước tính không đơn người ước tính
• Thu thập ước tính thường xuyên trong suốt dự án, thường vào lúc bắt đầu của mỗi nước rút
• phản hồi sử dụng từ chạy nước rút trước khi xác định câu chuyện phức tạp
• theo dõi tốc độ để mang lại ý nghĩa cho các kích thước tương đối
• thường xuyên và đầu hồi tưởng câu chuyện để kiểm tra/hiểu bất kỳ trận đòn

Nếu bạn đang đối phó với các công ty sử dụng các phương pháp ước tính này, thì rất có thể bạn sẽ nhận được kết quả phù hợp và do đó tốt hơn.

Answer 17

"Bốn đến sáu tuần", khi không đi kèm với một sự cố vào nhiệm vụ ngắn ...