Tỷ lệ lỗi chấp nhận được khi ước tính thời gian dự án là gì?

Công ty nơi tôi làm việc đang hướng tới mục tiêu có tỷ lệ lỗi tối đa 10%. Họ hy vọng các nhà phân tích sẽ không bỏ lỡ ước tính nhiều hơn hoặc ít hơn 10%.

Tôi không biết phải nghĩ gì về nó, vì tôi không có gì để so sánh với nó.

Điều gì có thể là một đường cơ sở tốt để đo lường nếu chúng ta ước tính quá sai, cho nhiều hay ít? Bao nhiêu (tính theo%) bạn có nghĩ là ổn để để bỏ lỡ?

Trừ khi bạn đang ước tính một cái gì đó rất giống với những gì bạn và đồng nghiệp đã làm trước đây, +/- 10% là lạc quan một cách lố bịch. Quản lý của bạn không có nhiều kinh nghiệm với phần mềm hoặc họ không biết về Giới hạn lớn đối với Ước tính Phần mềm . Bài báo đó có một số tài liệu hỗ trợ đi kèm , và rất nhiều punditry có thể được tìm thấy.

Hãy xem xét một hệ thống đơn giản hơn nhiều so với một dự án phần mềm thông thường: Rubik's Cube. Bạn có thể giải quyết bất kỳ vị trí nào trong 20 lần di chuyển , tối đa. Nhưng vì bạn đang ước tính, bạn chỉ có thể nhìn vào một khối lập phương trong vài phút trước khi đưa ra giải pháp. Bạn có thể đưa ra một ước tính tốt? Không, đôi khi việc ước tính một quy trình mất nhiều thời gian hơn so với thực hiện quy trình.

Một hệ thống đơn giản khác: Pinocchio. Một chiếc máy tự động bằng gỗ, mảnh mũi của anh ta phát triển khi anh ta nói dối. Điều gì xảy ra khi Pinocchio nghỉ ngơi và sau đó nói "Mũi của tôi đang phát triển"? Một số hệ thống không thể dự đoán được, chúng không thể giải quyết được.

Hai vấn đề này được tích hợp sẵn cho hầu hết các hệ thống phần mềm. Do đó, bạn sẽ không bao giờ có được ước tính gần +/- 10%.

Lời khuyên của tôi là đưa ra một ước tính được đệm rất nhiều, làm việc như một nô lệ để hoàn thành dự án nhanh nhất có thể, và sau đó trông bận rộn cho đến khi bạn ở dưới 10% hoặc hơn. Tại thời điểm đó, công bố một thành công ngoạn mục.

Tôi sẽ rất do dự về bất kỳ loại "lề lỗi mục tiêu" nào vì nó thực sự phụ thuộc vào dự án. Nếu bạn đang cố gắng ước tính sẽ mất bao lâu để cài đặt, định cấu hình và tùy chỉnh hệ thống CRM mới trong đó không ai chắc chắn loại tùy chỉnh nào sẽ cần thiết và loại thay đổi quy trình kinh doanh nào sẽ cần và công ty không có lịch sử của các dự án lớn tương tự, biên độ lỗi của bạn phải khá lớn (tức là bạn có thể đoán rằng sẽ mất 18 tháng +/- 50% và báo giá 9-27 tháng). Khi dự án tiến triển, các thông số kỹ thuật trở nên rõ ràng hơn, các quyết định được đưa ra về quy trình kinh doanh, các nhà phát triển của bạn sẽ thoải mái hơn, v.v. những lề lỗi đó sẽ trở nên chặt chẽ hơn. Nếu bạn đang cố gắng ước tính sẽ mất bao lâu để xây dựng trang web thương mại điện tử cơ bản thứ 101 khi bạn ' đã có một lịch sử tốt từ 100 người đầu tiên, bạn sẽ có thể đưa ra một ước tính chính xác hơn nhiều. Hầu hết các dự án, mặc dù, sẽ rơi ở đâu đó ở giữa.

Bây giờ, nếu bạn đang trích dẫn một số thay vì một phạm vi, câu trả lời có lẽ là bắt đầu trích dẫn phạm vi để người thực hiện ước tính có thể chỉ định mức độ chính xác mà họ mong đợi ước tính của họ.

Một đường cơ sở tốt sẽ là một dựa trên dữ liệu thực mà bạn đã thu thập.

Bước đầu tiên để làm điều này là ghi lại tất cả các ước tính . Bước thứ hai là ghi lại kết quả thực tế . Hãy trung thực, đừng bị 'tự điều chỉnh' thực tế. Thu thập đủ thông tin này và bạn có một số dữ liệu cho cơ sở thống kê mức độ ước tính của bạn tốt như thế nào. Lưu ý, điều này có thể / sẽ thay đổi mạnh mẽ dựa trên ai đã ước tính và ai là người làm việc. Chỉ bằng cách làm điều này, bạn mới có thể mong đợi một cách hợp lý để đưa ra một 'lề lỗi', đó là bất cứ thứ gì khác.

Nó cũng không dừng lại ở đó; phân tích nguyên nhân khiến ước tính bị tắt có thể giúp cải thiện tính chính xác của ước tính trong tương lai của bạn. Lưu ý: Chúng vẫn là ước tính , và như vậy, chỉ là ước tính .

Dự toán cũng không kết thúc sau ước tính đầu tiên; đây là điều có thể được điều chỉnh khi dự án tiến triển khi có thêm kiến ​​thức, điều này giúp giảm tỷ lệ lỗi có thể xảy ra khi bạn thực hiện. Bạn càng cởi mở hơn với giao tiếp, những bất ngờ trước đó sẽ được thảo luận - dẫn đến mọi người ít ngạc nhiên hơn và cho phép có nhiều thời gian hơn để điều chỉnh dự án hoặc mong đợi của khách hàng.

Thứ hai, có lẽ cách xử lý lề lỗi tốt hơn là ' độ tin cậy bên trong ' thay vì chỉ là% lề lỗi. Bạn dựa trên bạn ước tính ngày giao hàng trên một khoảng tin cậy, chứ không phải là một ngày duy nhất.

PERT là một ví dụ về khung để xử lý ước tính dựa trên lý luận thống kê. Ví dụ:

"Dựa trên những gì tôi biết bây giờ, chúng tôi có mức độ tin cậy 90%, chúng tôi có thể cung cấp trong 8 tháng. Độ tin cậy 95% trong 10 tháng, độ tin cậy 99% trong 2 năm, v.v."

Lưu ý ở đây: Họ càng tin tưởng bạn, ước tính sẽ càng lớn. Tùy thuộc vào mức độ phức tạp (hay còn gọi là mức độ chính xác của bạn), nó có thể là một sự khác biệt nhỏ giữa 80% và 90%, hoặc nó có thể rất lớn!

Cuối cùng - Chúc may mắn;) Nếu bạn từng giải quyết 'tỷ lệ lỗi tối đa' trong ước tính phần mềm, theo đó bạn có thể chỉ định một cái gì đó như 'tất cả các ước tính của chúng tôi sẽ là +/- 10%', hãy chắc chắn ủy thác một bộ phim phòng vé cho phần còn lại của chúng tôi trong ngành công nghiệp phần mềm. Tôi đang suy nghĩ điều gì đó giống như sự giao thoa giữa Office Space và Ma trận: D

Nó thực sự phụ thuộc rất nhiều vào quy mô và độ phức tạp của dự án.

Nếu ước tính dự án của bạn là 1 tuần - 10% là hợp lý. Nó có nghĩa là +/- 1/2 ngày.
Nếu đó là 1 tháng thì 10% là không ổn định - theo kinh nghiệm của tôi, không thể dự đoán những gì bạn sẽ khám phá trong 1 tháng.

Hơn một tháng - tất cả các cược đã tắt :).

Đây là cho mỗi nhà phát triển - vì vậy, đối với nhóm 4 nhà phát triển 1week == 1 tháng.

Đối với nhóm 4 nhà phát triển, chủ yếu là đưa ra danh sách các tính năng có thể được thực hiện trong 1 tháng và trong vòng 10% cho các tính năng đó. Sau đó, ước tính lại cho tháng tiếp theo.

Tôi đã đưa ra một số giả định ngây thơ ở đây

1. Tất cả các nhà phát triển có thể làm việc song song.
2. Không được xem xét thử nghiệm - họ nên có thời gian để kiểm tra
3. Tất cả các nhà phát triển đều bình đẳng - Frontend, Backend, Designers, v.v ...

Bạn phải tính đến những người trong .. nhưng đây là ý tưởng chung.

Có rất nhiều biến:

1. Dự án kéo dài bao lâu?

2. Dự án sẽ được quản lý như thế nào? Thác nước? Nhanh nhẹn? Bánh quy?

Tôi sẽ giả sử từ câu hỏi Thác nước. Nếu đó là trường hợp bạn dự kiến ​​sẽ thất bại bởi một số phần trăm đưa ra yêu cầu ký quỹ.

Nếu câu trả lời là một số phương pháp Agile, đặc biệt là một cái gì đó như SCRUM. Nó không thực sự quan trọng phần trăm ký quỹ là gì. Tỷ lệ lỗi 50% trên Sprint 2 tuần là 1 tuần, trên Sprint 1 tuần là 2,5 ngày, cả hai trường hợp cực kỳ tồi tệ nhất. Điều này là do ngày giao hàng được ước tính lại mỗi Sprint và nó sẽ ngày càng chính xác hơn theo thời gian, thay vì ngày càng ít hơn.

Với thác 50% lỗi không phải là không nghe thấy, nhưng trong một dự án 12 tháng là 6 tháng và nó không thực sự bị phát hiện / thừa nhận, điều đó thật tệ cho đến 10 tháng sau 12 tháng.

Quay trở lại khi tôi từng dẫn dắt các nhóm phần mềm, đại khái là xung quanh ranh giới Creta / Đệ tam, chúng tôi thực sự đã tiến gần tới việc đạt được +/- 10% về ước tính. Đó là khoảng +/- 15% nếu bộ nhớ rất tinh ranh của tôi phục vụ. Nhưng điều này là do chúng tôi đã ước tính cho những điều chúng tôi đã thực hiện : phần mềm giao tiếp thời gian thực tương đối đơn giản, lấy byte từ A và chuyển chúng sang B bằng ngôn ngữ mà chúng tôi quen thuộc, trong môi trường thời gian thực do chúng tôi thiết kế , nói chuyện với phần cứng được thiết kế trong nhà bởi một vài văn phòng. Rất nhiều biến thể nhỏ về chủ đề trên, trong nhiều năm theo nghĩa đen .

Mong đợi để đạt được loại tỷ lệ lỗi này trong ước tính dự án phần mềm thông thường là, thẳng thắn, lố bịch . Khi bạn thấy nó đạt được rõ ràng, đó là do mọi người ước tính quá mức và độn (làm thêm các dự án và vật nuôi để sử dụng ngân sách), hoặc ước tính thấp và làm việc như những con chó vào buổi tối và cuối tuần để bù giờ.

Có lẽ bạn đã nghe điều 300% phải không?

Tôi thực sự sử dụng nó. Hoàn toàn dựa trên những gì tôi đã thấy trong nhiều năm. Khi tôi nghe một hoặc hai ngày, đó là một tuần hoặc hơn để thực sự được thực hiện . Và đã thử nghiệm. Trong mọi môi trường. Tài liệu cập nhật. Kiểm tra khả năng sử dụng. Hiệu suất được thử nghiệm. Tải thử nghiệm. Một vài giờ thực sự giống như một ngày.

Tôi nghĩ rằng chúng tôi thực sự xấu khi ước tính vì:

• Giúp đỡ người khác
• Bị gián đoạn
• Đào tạo người mới
• Những thứ khác sắp tới
• Bị ốm hoặc không khỏe
• Bao gồm những người rời đi
• Cần nghỉ hoặc thời gian nghỉ
• Bị người khác làm xao lãng
• Được tổ chức bởi các nhóm khác
• Lạc quan quá mức so với thực tế
• Không phân bổ thời gian để làm việc trên các thử nghiệm không liên tục
• Dễ dàng loại trừ thời gian để thử nghiệm, đặc biệt là viết thử nghiệm tự động

Vì vậy, ở cấp độ cao nhất, với những người kinh doanh cần ước tính tốt hơn 300%, những gì chúng ta sẽ làm là nhắm đến những ước tính hợp lý tốt nhưng với mức giá cao hơn và chung chung hơn. "Chúng tôi sẽ có chức năng chỉnh sửa người dùng" ngay cả khi phiên bản 1 chỉ dành cho 1 nhóm người dùng để thay đổi 1 trường.

Khi nói đến "tỷ lệ lỗi chấp nhận được khi ước tính thời gian dự án là gì?" Tôi thấy rằng cách tiếp cận này, được sử dụng trong nhiều môi trường Agile giúp thay đổi câu hỏi thành chức năng tối thiểu để có phiên bản alpha hoặc beta trực tiếp và sau đó lặp lại trên đó.