Nhà phát triển có nên chấp nhận ước tính khối lượng công việc được thực hiện bởi macro Excel không?

12

Trong một dự án mới, một người bạn đã phải viết các bài kiểm tra trong đó thời gian cần thiết để viết chúng được tính bằng một macro Excel được viết bởi người quản lý không phải là nhà phát triển của anh ta.

Trong trường hợp như vậy, một nhà phát triển có nên chấp nhận trách nhiệm viết và chạy thử nghiệm trong thời gian tính toán không? Là kết quả của các bài kiểm tra đáng tin cậy?

Để biết thông tin, bạn tôi đã từ chối chịu trách nhiệm về các ước tính mà anh ta đã không thực hiện, yêu cầu thành công để thực hiện dự án khác và đã được thay thế bởi một anh chàng ngoài trường thiếu kinh nghiệm.

project-management productivity testing

— Nelstaar
nguồn

7

"Chấp nhận" một "ước tính" nghĩa là gì? Nếu bạn ước tính sẽ mất 30 ngày để làm điều gì đó, điều gì xảy ra nếu tôi "chấp nhận" nó? Tôi quan tâm bạn ước tính mất bao lâu để tôi làm một việc gì đó? Bạn có thể ước tính tôi sẽ làm điều đó trong một phút cho tất cả những gì tôi quan tâm, bạn sẽ sai chứ không phải tôi.

— David Schwartz

2

@David Chấp nhận một ước tính thường đề cập đến việc xem xét các ước tính và đảm bảo sự đồng thuận. Ví dụ: nếu một công cụ ước tính tham số được sử dụng, việc các kỹ sư dự án xem xét dữ liệu đó để đảm bảo tính nhất quán, có thể sử dụng phương pháp thứ hai như Wideband Delphi.

— Thomas Owens

12

Âm thanh giống như một cái gì đó nên được gửi đến Scott Adams cho một phim hoạt hình Dilbert.

— MetalMikester

1

Miễn là có một đánh giá. Tôi ví dụ cụ thể này không có.

— Nelstaar

5

Hãy nhớ rằng: một ước tính, một cam kết, một mục tiêu và một kế hoạch để đạt được một mục tiêu là bốn điều khác nhau. Hãy chắc chắn rằng mọi người đều hiểu rõ những thứ đó là gì và đầu ra của bốn thứ đó là gì.

— nlawalker

14

Nó phụ thuộc vào mức độ nhạy cảm của họ đối với nhà phát triển và họ dựa trên dữ liệu / logic nào. (chúng có thể dựa trên dữ liệu thống kê được thu thập trong nhiều năm về thời gian cần thiết - bởi chính nhà phát triển này và / hoặc bởi những người khác - để giải quyết các nhiệm vụ tương tự trong quá khứ ... hoặc họ có thể hoàn toàn dựa vào người quản lý của mình - đúng hoặc không đúng - giả định.)

Tốt nhất, anh ta nên thảo luận với người quản lý của mình rằng người ta không thể mong đợi một cách hợp lý để cam kết và chịu trách nhiệm về một nhiệm vụ do người khác ước tính.

Rõ ràng việc từ chối cam kết với các ước tính thực sự có thể dẫn đến sự thay thế kịp thời của anh ấy, vì vậy tốt hơn là nên có một cách tiếp cận nhẹ nhàng hơn và tránh đối đầu trực tiếp nếu có thể.

— Péter Török
nguồn

7

Có lẽ macro đang hoạt động trên một số loại dữ liệu đầu vào, nó không chỉ là một trình tạo số ngẫu nhiên? Vì vậy, để trả lời câu hỏi của bạn, chúng tôi cần biết dữ liệu đầu vào là gì và macro làm gì. Không có điều này bất kỳ câu trả lời là khá vô nghĩa.

Hoặc, câu hỏi của bạn có thực sự về việc chấp nhận các ước tính được tạo ra bởi người quản lý thiếu kinh nghiệm liên quan không? Trong trường hợp này, câu trả lời là không, bạn (hoặc bạn của bạn) nên đưa ra ước tính của riêng họ và gửi chúng cho người quản lý. Nếu 2 hình không khớp nhau thì chúng cần phối hợp với nhau để tìm ra cách tốt nhất về phía trước - có thể đồng ý viết ít bài kiểm tra hơn hoặc có thể mất nhiều thời gian hơn để viết tất cả.

Từ chối điểm trắng sẽ không giúp được ai, và làm việc theo thời gian mà bạn không thể gặp cũng không có gì thú vị, giải pháp nằm ở cách tiếp cận chuyên nghiệp và đi đến thỏa hiệp cho phép tiến hành công việc.

— Steve
nguồn

Các thử nghiệm được cắt thành các phần phụ (gần như nguyên tử) và người ta ước tính nhỏ.

— Nelstaar

Tôi nghĩ rằng bằng cách sử dụng phương pháp này, người thử nghiệm cuối cùng không nhìn thấy / kiểm tra bức tranh lớn.

— Nelstaar

1

"Có lẽ macro đang hoạt động trên một số loại dữ liệu đầu vào, nó không chỉ là một trình tạo số ngẫu nhiên" Nó cũng có thể là ngẫu nhiên bởi vì chúng không có cách nào để nắm bắt MỌI biến làm cho thuật toán chính xác như vậy.

— maple_shaft

1

@maple_shaft: Đó là lý do tại sao họ gọi đó là ước tính - điều đó không (hoặc không nên) được cho là chính xác. Cho dù bạn ước tính bằng cách sử dụng một số tính toán trong Excel, hoặc bằng bút chì và giấy, sẽ không tạo ra bất kỳ sự khác biệt nào. Sử dụng Excel để ước tính có ý nghĩa hơn nhiều so với một số 'kỹ thuật' khác mà tôi đã thấy khi sử dụng ...

— Treb

@Treb Ước tính phải chính xác như dữ liệu được cung cấp và trạng thái dự án hiện tại cho phép, được đưa ra Hình nón không chắc chắn.

— Thomas Owens

5

Chắc chắn nhất là KHÔNG.

Một chương trình nhỏ, thậm chí là một chương trình lớn, phức tạp, không thể ước tính được bất kỳ công việc lập trình nào sẽ mất bao lâu. Xem giới hạn toán học để ước tính phần mềm để biết lý do tại sao. Một bài báo dài hơn, được đánh giá ngang hàng, Giới hạn lớn cho Dự toán phần mềm cũng có sẵn.

Tôi cũng sẽ xem xét lại ý kiến của tôi về người quản lý trong câu hỏi: tại sao anh ta hoặc cô ta tin rằng macro bảng tính chưa từng được thử trong quá khứ, cho rằng mọi thứ khác đã được cố gắng để ước tính thời gian tác vụ phần mềm trong quá khứ.

— Bruce Ediger
nguồn

1

Tôi chưa đọc các giấy tờ đầy đủ (nhưng), nhưng các phương pháp tham số đã được sử dụng rộng rãi để ước tính các dự án phần mềm trong vòng 15% trong hơn 20 năm, giả sử rằng dữ liệu đầu vào là hợp lệ. Ngoài ra, các phương pháp hợp tác như Wideband Delphi có thể (và đã được sử dụng) để xác nhận tính chính xác của các mô hình tham số. Xem Kinh tế Kỹ thuật phần mềm (Boehm) để thảo luận về các phương pháp tham số và áp dụng Wideband Delphi cho các dự án phần mềm (cả có và không có mô hình đo lường).

— Thomas Owens

Tôi đồng ý với Thomas. Mặc dù bạn không thể dự đoán chính xác từng nhiệm vụ cho toàn bộ dự án, trong suốt quá trình của dự án và sử dụng dữ liệu lịch sử cho một tổ chức cụ thể bạn có thể nhận được trong sân bóng. Một số nhiệm vụ sẽ mất nhiều thời gian hơn và một số nhiệm vụ ngắn hơn nhưng cuối cùng chúng trung bình. Đặc biệt nếu dự án tương tự như dự án đã được thực hiện bởi tổ chức. Như đã nói, ước tính không thể giải thích cho những điều bất ngờ thực sự tồi tệ, như phần cứng / phần mềm không hoạt động như quảng cáo, công nghệ mới khó hơn nhiều so với dự đoán, thiếu nhà phát triển, lãnh đạo và quản lý kém.

— Dunk

1

Bạn cần đọc và hiểu bài. Một macro bảng tính đơn giản không có cơ hội ước tính chính xác. Phần mềm là toán học, và các hệ thống toán học đôi khi gặp phải một vấn đề nhỏ được gọi là không hoàn chỉnh. Tôi đảm bảo với bạn rằng người quản lý được đề cập đang đánh lừa chính mình và kết quả của vĩ mô không tương quan với thực tế.

— Bruce Ediger

1

@Bruce: Đã sử dụng công thức (bao gồm bảng tính Excel) để ước tính dự án thành công, tôi chắc chắn có thể khẳng định rằng cả Thomas, Người quản lý hoặc bản thân tôi đều không nhất thiết phải tự lừa mình. Như tôi đã nói, mỗi nhiệm vụ riêng lẻ sẽ khác nhau, nhưng trong suốt quá trình của một dự án, họ có xu hướng thậm chí ra ngoài. Tôi đã thấy rằng việc sử dụng công thức (được phát triển và sửa đổi theo thời gian) đã chính xác hơn nhiều so với ước tính của nhà phát triển cá nhân. Nói chung, các nhà phát triển quá lạc quan hoặc quá bi quan. Tất nhiên, các công thức chỉ hoạt động khi được cung cấp dữ liệu hợp lý, kỹ năng chắc chắn là một yếu tố.

— Dunk

Tôi đọc những giấy tờ tối qua. Họ đi ngược lại hơn 40 năm bằng chứng trong quản lý dự án và hơn 30 năm bằng chứng trong quản lý dự án phần mềm. Xem iiasa.ac.at/Admin/PUB/Document/RM-75-071.pdf và Sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Ừ!

Đây là một "mùi công việc" khổng lồ. Đó là quản lý vi mô đáng kinh ngạc.

Nếu họ không thể tin tưởng nhân viên của mình để đưa ra ước tính, họ không tin tưởng bạn điều gì nữa?

— ozz
nguồn

1

99% các nhà phát triển thậm chí không thể đưa ra các ước tính xấu dựa trên bất kỳ mục tiêu nào chứ đừng nói đến ước tính chính xác. Vì vậy, tôi thấy không có gì chỉ ra "mùi công việc" bởi vì một người khác đã đưa ra một ước tính. Đặc biệt nếu họ sử dụng dữ liệu thực tế để biện minh cho số lượng của họ. Nếu mọi người phải chịu trách nhiệm đáp ứng ước tính mọi nhiệm vụ thì đó là vấn đề mùi công việc. Tuy nhiên, nếu công cụ đánh giá thấp tất cả các nhiệm vụ thì tất cả các nhà phát triển sẽ thiếu các ước tính. OTOH, nếu mọi người khác dường như đáp ứng hầu hết tất cả các ước tính và một nhà phát triển khác không bao giờ thực hiện thì đó là vấn đề về mùi của nhà phát triển.

— Dunk

@Dunk - Quan điểm của tôi, quản lý vi mô ở mức độ này trong việc phát triển phần mềm là một "mùi công việc" và tôi sẽ không muốn làm việc ở đó.

— ozz

1

những gì bạn gọi là quản lý vi mô là cách duy nhất để kinh doanh trong nhiều ngành công nghiệp. Nếu bạn không thể đưa ra ước tính chi phí hợp lý và tiến độ cho các dự án lớn thì công ty của bạn sẽ có một công việc rất khó khăn để có được hợp đồng. Trái với lý tưởng nhanh nhẹn, khách hàng trong nhiều ngành sẽ không cam kết với hàng chục triệu hợp đồng đô la nếu họ không biết cuối cùng họ sẽ nhận được gì. Họ sẽ không hài lòng với ý tưởng rằng tiền của họ đã biến mất, họ có một sản phẩm hoạt động, nhưng nó chỉ làm được 50% những gì họ cần hoặc muốn.

— Dunk

@dunk - Nếu bạn hài lòng với việc quản lý tạo ra các ước tính cho bạn, hãy tiếp tục. Tôi muốn có đội ngũ phát triển sản xuất ước tính. Các ước tính quản lý khổng lồ (cùng với các yêu cầu thay đổi liên tục, một cuộc thảo luận khác) là lý do tại sao nhiều dự án phần mềm không cung cấp đúng thời hạn và trong ngân sách theo lịch trình. Tôi muốn tin tưởng những người làm công việc này.

— ozz

Vấn đề không phải là quản lý làm dự toán hay người làm công việc sắp tới dự toán. Đó là một câu hỏi về việc kéo các ước tính ra khỏi mông của bạn hoặc cố gắng dựa trên các dữ liệu khách quan của bạn. Theo kinh nghiệm của tôi, khi so sánh các ước tính quản lý với các ước tính của nhà phát triển, bạn sẽ thấy rằng các ước tính quản lý có xu hướng dẫn đến thời gian dài hơn để hoàn thành. Các nhà phát triển có xu hướng lạc quan .....

— Dunk

3

Hoàn toàn KHÔNG.

Tôi hứa với bạn rằng người quản lý không quá ảo tưởng khi nghĩ rằng macro Excel của anh ta có thể dự đoán chính xác các ước tính. Tôi thậm chí không tranh luận điều gì nên là một thực tế nổi tiếng rằng có quá nhiều biến liên quan để dự đoán chính xác một cái gì đó như thế này trong một thuật toán. Nếu anh ta phát minh ra một thuật toán như vậy, anh ta nên cấp bằng sáng chế cho nó và kiếm được hàng triệu đô la theo ý kiến của tôi.

Điều thực sự xảy ra ở đây là người quản lý đang sử dụng macro Excel được cho là này như một sự ngụy trang mỏng manh để che giấu sự thật rằng anh ta đang ép buộc những kỳ vọng không thực tế và áp lực không đáng có đối với các nhà phát triển của mình.

Anh ta biết đó là BS và không quan tâm, đó là một cái cớ để đặt quá nhiều tài nguyên và cố gắng hoàn thành công việc nhanh hơn bằng cách làm cho tất cả các nhà phát triển "vô giá trị" của anh ta mãi mãi "LATE".

Người quản lý này nghe giống như một kẻ ngốc bóc lột.

— phong_shaft
nguồn

1

Ơ, chỉ vì người quản lý đang tạo ước tính cho các nhà phát triển không có nghĩa là họ không chính xác và chúng tôi thực sự không thể đưa ra kết luận đó mà không có thêm thông tin. Nếu người quản lý có năng lực, họ nên nhận ra thực tế so với phi thực tế khá dễ dàng điều chỉnh mọi thứ cho phù hợp.

— rjzii

1

@Rob, Bạn đang quên điểm mấu chốt mà OP đưa ra, rằng chúng đang được giữ theo các ước tính này (giả sử nghiêm ngặt vì nhà phát triển trước đó trong nhóm đã đề cập "không muốn giữ các ước tính" và được chỉ định lại). Không có gì sai với các mô hình ước tính nhưng chúng phải là một hướng dẫn sơ bộ và không có gì để "giữ các nhà phát triển", điều mà tôi không may đã thấy quản lý làm với rất nhiều người.

— maple_shaft

2

Vấn đề ở đây là những ước tính này đã được chuyển trực tiếp vào hóa đơn của khách hàng. Tại sao một số nhà quản lý tiếp tục gọi nó là ước tính?

— Nelstaar

@maple_shaft - Không biết ước tính là gì, thật khó để nói nếu chúng không hợp lý và do đó sự phản đối để được giữ cho chúng là hợp lệ. Nếu họ là những ước tính công bằng (tức là "Tám giờ để viết Hello World") thì không có vấn đề gì với việc họ bị giữ ngoài triết lý.

— rjzii

3

Trong một dự án mới, một người bạn đã phải viết các bài kiểm tra trong đó thời gian cần thiết để viết chúng được tính bằng một macro Excel được viết bởi người quản lý không phải là nhà phát triển của anh ta.

Có các mô hình ước lượng tham số để ước tính thời gian hoàn thành các dự án, bao gồm các dự án phần mềm. Thông thường, ước tính là cho mã sản xuất, nhưng tôi không hiểu tại sao nó không thể được ngoại suy để ước tính sẽ mất bao lâu để viết mã kiểm tra. Những ước tính này chỉ tốt như dữ liệu được đưa vào chúng, mặc dù.

Giả sử rằng phương pháp được sử dụng là mô hình ước tính hợp lệ và dữ liệu là chính xác và hợp lệ, không có lý do gì một ước tính tốt không thể đến từ macro Excel được viết bởi người quản lý không phải là nhà phát triển.

Trong trường hợp như vậy, một nhà phát triển có nên chấp nhận trách nhiệm viết và chạy thử nghiệm trong thời gian tính toán không?

Không có ước tính bao giờ nên được chấp nhận một cách mù quáng, trong mọi trường hợp. Không có ước tính nào là hoàn hảo, bất kể nó được tạo ra như thế nào. Kỹ sư phải xem xét mọi ước tính, xác định các vấn đề tiềm ẩn, đánh giá tác động của chúng và thảo luận và tinh chỉnh dự toán khi cần thiết.

Là kết quả của các bài kiểm tra đáng tin cậy?

Các thử nghiệm chỉ tốt như những nỗ lực dành cho việc thiết kế và thực hiện chúng. Nếu một người thử nghiệm tạo ra các thử nghiệm chất lượng thấp, các lỗi sẽ chuyển qua thử nghiệm và đưa nó đến giai đoạn sau của dự án. Lý do là áp lực lịch biểu sẽ dẫn đến các thử nghiệm chất lượng thấp, vì vậy nếu thời gian không đủ để thiết kế các trường hợp thử nghiệm phù hợp và sau đó thực hiện các trường hợp đó, thì các thử nghiệm sẽ không hữu ích.

— Thomas Owens
nguồn

3

Âm thanh như bạn đang hỏi hai câu hỏi khác nhau:

Là kết quả của các bài kiểm tra đáng tin cậy?

Excel là một công cụ giống như bất kỳ công cụ nào khác mà chúng tôi làm việc và những tính toán được viết trong đó không thực sự có ảnh hưởng đến kết quả của thuật toán. Thực tế là việc ước tính đến từ một macro Excel không liên quan đến việc kết quả tính toán hay không (nghĩa là tính hợp lệ của ước tính) có hợp lệ hay không. Nếu bạn có các giả định xấu trong mô hình cơ bản thì việc bạn sử dụng để tính toán là không quan trọng vì các giả định cơ bản là không chính xác.

Trong trường hợp như vậy, một nhà phát triển có nên chấp nhận trách nhiệm viết và chạy thử nghiệm trong thời gian tính toán không?

Nếu yêu cầu mà nhà phát triển thực hiện công việc trong thời gian được chỉ định là trong liên hệ của họ thì họ không thể làm gì nhiều để tranh luận với điều đó miễn là các ước tính là hợp lý. Điều này dẫn đến điểm tiếp theo: nếu các tính toán đưa ra một khoảng thời gian hợp lý và chúng tương tự như ước tính mà nhà phát triển sẽ tự đưa ra thì không có lý do gì để không phản đối các mốc thời gian đưa ra. Trên thực tế, nó có thể có lợi cho các nhà phát triển vì họ có thể ảnh hưởng đến các giả định được sử dụng trong mô-đun trái ngược với nếu chúng được đưa ra một dòng thời gian tùy ý.

Nếu các mốc thời gian dường như không khả thi đối với số lượng công việc cần thiết thì rõ ràng họ nên nêu ra mối quan tâm này và cố gắng và làm việc với người quản lý để có được các mốc thời gian thực tế hơn, nhưng nếu dòng thời gian là khả thi thì họ sẽ gặp khó khăn khi phản đối chúng.

Về mặt quản lý dự án và ước tính thời gian, vâng, nó có thể được thực hiện nhưng nó phụ thuộc nhiều vào tính chất công việc đang được thực hiện. Bạn có thể sẽ thấy các ước tính chính xác hơn được đưa ra cho thời gian cần thiết để viết mã thử nghiệm đơn vị (giả sử nhà phát triển hiểu khung và đã viết chúng trước đó) so với việc bạn viết mã mới đối với các trường hợp sử dụng, mã thử nghiệm được viết cho

— rjzii
nguồn

Tôi đồng ý phương pháp này có thể / có thể được sử dụng miễn là có một hộp thoại giữa các tác nhân của dự án.

— Nelstaar

1

@Nelstaar - Khá nhiều thứ tôi từng đọc về quản lý và ước tính dự án liên quan đến một hộp thoại đang chạy và điều chỉnh mọi thứ khi thời gian trôi qua. Thông thường hầu hết các ước tính đáng tin cậy đều có xác suất liên quan đến chúng liên quan đến tỷ lệ trúng mục tiêu được chỉ định (nghĩa là 90% cơ hội thực hiện nhiệm vụ mất 8 giờ).

— rjzii

2

Tôi không muốn chơi thử các bài kiểm tra viết, nhưng dự án có thể đã có một vài nhà phát triển viết chúng trước đây. Nếu ước tính dựa trên những dữ liệu này, chúng có thể chính xác hơn so với bạn của bạn đã giả định. Vì bạn của bạn đã rời khỏi dự án, không cố gắng tạo ra các ước tính đối nghịch hoặc xem liệu chúng có thể được hoàn thành như dự đoán hay không, chúng tôi sẽ không bao giờ biết.

Tất cả những gì anh phải làm là hoàn thành một hoặc hai bài kiểm tra để xem mức độ chính xác của ước tính và trả lại cho người quản lý bằng một lập luận hợp pháp. Có thể có các thành viên khác trong nhóm có thể đã cung cấp phản hồi về độ tin cậy của các ước tính hoặc hậu quả của việc tụt lại phía sau. Đôi khi một người quản lý phải đưa 'cái gì đó' cho sếp của mình để giữ cho mọi người vui vẻ. Các nhà phát triển xem đây là một cảm giác sai lầm về bảo mật. Có lẽ nếu có một phong trào cho các nhà phát triển để cung cấp các ước tính và cho thấy sự sẵn sàng để hoàn thành công việc, ban quản lý có thể phát triển niềm tin hơn.

Điều tôi đoán là, nếu anh ta có thể hoàn thành các bài kiểm tra trong thời gian ngắn hơn, anh ta sẽ không nói gì về nó. Sau đó, một lần nữa, xin lỗi chính mình từ một thực tế mà anh ta không tin, có thể cho thấy mức độ toàn vẹn cao.

— Jeff
nguồn

+1 để đưa ra phản hồi trong khi thực hiện các nhiệm vụ liên quan đến các ước tính.

— rjzii

1

Câu trả lời dễ và ngắn:

Bạn không quan tâm việc ước tính đến từ đâu.

Những gì bạn thực sự quan tâm là ước tính chính nó. Đồng ý với nó hoặc không đồng ý và giải thích lý do và mức độ bạn sẽ ước tính. Đó là điều quan trọng nhất.

— Clement Herreman
nguồn

1

Bạn nên quan tâm nơi ước tính đến từ đâu. Một mô hình tham số với đầu vào hợp lệ và hợp lý, trình tạo số ngẫu nhiên, sinh viên khoa học máy tính năm đầu tiên, kỹ sư phần mềm với 5 năm kinh nghiệm với ít hơn 6 tháng trong lĩnh vực và kỹ sư phần mềm đã trở thành người quản lý dự án với 25 năm kinh nghiệm trong miền tất cả đều có khả năng khác nhau để tạo ra một ước tính hiệu quả. Điều này cũng quay trở lại với một nhận xét tôi đã đưa ra về một câu trả lời trước đây về trách nhiệm đạo đức / nghề nghiệp của một kỹ sư phần mềm để đại diện, bảo vệ và thách thức các ước tính một cách thích hợp.

— Thomas Owens

Chính xác: quan trọng nhất là thảo luận về dự toán. Tôi sẵn sàng chấp thuận sử dụng macro Excel nếu các ước tính mà nó đưa ra thường đúng hơn so với kỹ sư 25 năm kinh nghiệm. Điều quan trọng là ước tính và giải thích dẫn đến nó (khối lượng công việc, tài nguyên sẵn có, khó khăn), không phải bởi ai hoặc những gì nó đã được công bố.

— Clement Herreman

Bạn đồng ý với tôi nói rằng câu trả lời của bạn là sai? Đưa ra cùng một đầu vào (chẳng hạn như khối lượng công việc, tài nguyên, độ khó, v.v.), ai cũng quan trọng như cái gì và tại sao. Nó đi xuống một yếu tố tin tưởng. Tôi tin tưởng COCOMO (được tạo ra và duy trì bởi một số bộ óc hàng đầu trong ước tính chi phí phần mềm) hơn một macro Excel (được tạo bởi một người có kinh nghiệm và kiến thức hạn chế trong ước tính chi phí, ít hơn nhiều so với miền ứng dụng). Đó là tất cả về bức tranh lớn để thiết lập mức độ đáng tin cậy của ước tính này.

— Thomas Owens

Không, tôi đoán tôi không đủ rõ ràng. Nó thực sự không quan trọng ai đã làm dự toán. Điều quan trọng là tính chính xác của ước tính. Bất cứ khi nào tôi có được một ước tính, tôi so sánh nó với những gì tôi ước tính, sau đó thảo luận với người quản lý dự án của tôi nếu tôi đồng ý hay không. Nếu lập luận của họ đủ tốt, thì tôi đồng ý với họ, và chấp nhận ước tính. Xem? Tôi chưa bao giờ nói chuyện cũng không nghĩ về người ước tính.

— Clement Herreman

Làm thế nào để bạn xác định độ chính xác nếu bạn không biết ai ước tính và họ đã sử dụng phương pháp nào? Tôi có thể cung cấp cùng một dữ liệu cho hai người - một người là sinh viên kỹ thuật phần mềm năm thứ nhất hiện đang tham gia khóa học khoa học máy tính đầu tiên và người kia là kỹ sư phần mềm cao cấp với 15 năm kinh nghiệm và 5 người trong miền. Cả hai đều sử dụng các phương pháp ước tính giống nhau (đừng quên - thông thường, đầu vào cũng là ước tính). Học sinh có thể nói sẽ mất 6 tháng với độ tin cậy 95%. Kỹ sư cao cấp có thể nói sẽ mất 15 tháng với độ tin cậy 80%. Tôi tin tưởng các kỹ sư cao cấp hơn.

— Thomas Owens

1

Về lý thuyết, một nhà phát triển không bao giờ nên chấp nhận một ước tính được thực hiện bởi bất kỳ người nào khác, bất kể nó được đưa ra như thế nào. Một lý do là việc đưa ra một ước tính dài hơn so với người quản lý của bạn cảm thấy thoải mái với việc ngay lập tức phơi bày một vấn đề lịch trình tiềm năng hoặc có thể là sự hiểu lầm về phạm vi công việc sẽ được thực hiện.

Mọi người thường thấy việc ước tính thời gian lập trình thậm chí còn khó hơn so với việc lập trình, vì vậy nếu người quản lý của bạn có thể viết một macro Excel có thể giải quyết vấn đề đó , anh ta có thể có thể xây dựng một macro để viết mã (không chắc).

Bây giờ, trong thực tế , nếu bạn hiểu công việc và các ước tính có vẻ hợp lý, thì thật đơn giản để bày tỏ một số mối quan tâm về phương pháp trong việc thông qua nhưng sau đó đồng ý tạm thời để xem liệu bạn có thể gặp họ không. Sau này, nếu công việc khiến bạn mất nhiều thời gian hơn dự toán, bạn nên đưa điều này đến sự chú ý của người quản lý của bạn vào thời điểm sớm nhất có thể. Hãy chuẩn bị để thảo luận về lý do chính xác dựa trên kinh nghiệm thực hiện thực tế của bạn. Hy vọng rằng tại thời điểm đó, người quản lý của bạn sẽ không vô lý và tiếp tục khẳng định rằng bạn làm việc với các ước tính được tạo ra một cách máy móc.

— Peter ALLenWebb
nguồn

-1

Một trong những phương pháp phát triển phần mềm mới nhất là nhanh nhẹn và một trong những khung nhanh nhẹn nổi tiếng là scrum . Nhưng trong phương pháp này, các nhà phát triển (nhóm scrum) chịu trách nhiệm tính toán thời gian cần thiết để thực hiện một tác vụ hoặc thực hiện một câu chuyện người dùng.

Tôi chắc chắn nói KHÔNG . Bởi vì:

Người quản lý không phải là nhà phát triển không thể ước tính thời gian cần thiết để thực hiện công việc
Ước tính thời gian cần thiết để thực hiện bất kỳ công việc nào cần một số trí thông minh của con người, mà Excel không có
Bằng cách chấp nhận thực hành làm việc như vậy, người quản lý dần dần quen với việc thay thế các nhà phát triển trong việc ước tính thời gian. Điều này có thể dẫn đến thảm họa. Hãy xem xét kịch bản này trong đó người quản lý của bạn nói:

Tôi muốn bắt đầu một dự án mới để bán xe đạp trực tuyến và tôi biết rằng phải mất 3 tuần để bạn và John hoàn thành nó.

— Saeed Neamati
nguồn

5

OP không đề cập đến nhóm của bạn mình bằng các phương pháp nhanh. Tôi không nghĩ các quy tắc nhanh có bất kỳ sự liên quan nào cho các đội sử dụng các phương pháp khác (hoặc không có phương pháp nào cả). Mặc dù vậy, thông thường nên :-) Hơn nữa, rõ ràng không phải Excel đã quyết định về các ước tính, nó chỉ thực hiện một số tính toán dựa trên một số giả định và dữ liệu (mỗi cái có thể đúng hoặc không chính xác) . Nếu tôi nhập ước tính cho một nhiệm vụ nhất định của từng thành viên trong nhóm của chúng tôi, sau đó đặt Excel để tính trung bình của các nhiệm vụ này, liệu Excel có thực hiện ước tính không?

— Péter Török

3

1 và 2 là ngang nhiên sai. Các mô hình ước lượng tham số được chấp nhận rộng rãi trong quản lý dự án phần mềm và đã hơn 20 năm và bất kỳ ai có đào tạo quản lý dự án (kỹ sư phần mềm hoặc không) đều có thể được đào tạo để sử dụng các công cụ này, giả sử rằng họ (hoặc, tốt nhất là các kỹ sư dự án ) có thể cung cấp các ước tính chính xác của các đầu vào.

— Thomas Owens

3

-1 - Điều này không trả lời câu hỏi, có lỗi rõ ràng ("... phương pháp phát triển phần mềm mới nhất là nhanh nhẹn") và dường như không thêm bất cứ điều gì liên quan. Tôi không chắc chắn những gì upvote hoặc câu trả lời được chấp nhận là cho.

— Morgan Herlocker

1

chúng tôi chắc chắn không biết từ câu hỏi nếu ước tính tham số là tiêu chuẩn tại công ty này và / hoặc nếu nó dựa trên lịch sử tốt cho doanh nghiệp của họ; nếu đó là trường hợp nhiều như tôi ghét nói, thì từ chối làm công việc của một người theo quy trình hoạt động được chấp nhận của tổ chức (không tuân theo một cách đặt câu hỏi hợp lý) là không đúng.

— StevenV

2

@Thomas Tôi đồng ý, tôi chỉ nghĩ rằng có quá nhiều điều chúng ta không biết về tình huống để trả lời một cách cụ thể Có hoặc không. Trong mọi trường hợp, từ chối thẳng thừng mà không có một cuộc thảo luận tốt để đảm bảo rằng tình huống và lý luận được hiểu là hiếm khi di chuyển nghề nghiệp tốt.

— StevenV