Làm thế nào để giải thích rằng thật khó để ước tính thời gian cần thiết cho một dự án phần mềm lớn hơn?

Tôi là một nhà phát triển cơ sở và tôi thấy thật khó để ước tính cần bao nhiêu thời gian để hoàn thành một dự án phần mềm lớn hơn. Tôi biết cách cấu trúc kiến ​​trúc nói chung, nhưng thật khó để tôi biết những chi tiết nào tôi phải làm và những vấn đề tôi phải giải quyết. Vì vậy, thật khó để ước tính sẽ mất bao nhiêu thời gian để hoàn thành một dự án lớn hơn, bởi vì tôi không biết tôi cần giải quyết vấn đề gì và mất bao lâu để giải quyết chúng.

Làm thế nào để tôi giải thích điều này cho một người không phải là nhà phát triển phần mềm ?

Bạn có thể yêu cầu anh ấy / cô ấy ước tính sẽ mất bao lâu để cô ấy truy cập vào một địa điểm xa xôi ở một góc không có người ở trên thế giới. Một ví dụ cực đoan, chúng ta hãy chọn một số đỉnh ít được biết đến hơn ở dãy Hy Mã Lạp Sơn, nơi rất ít (nếu có) mọi người đã từng leo lên. Cô ấy sẽ cần rất nhiều sự chuẩn bị cộng với thực hành trước khi bắt đầu cuộc hành trình, cộng với một loạt giấy phép, mỗi thứ có thể trì hoãn chuyến đi trong nhiều tháng đến nhiều năm ... và một đội hỗ trợ tốt ... sau đó một lần lên đồi dốc, cô ấy sẽ cần chờ đợi và cầu nguyện cho thời tiết tốt để bắt đầu leo ​​lên đỉnh ... vv. Hầu hết những điều này rất khó để không thể ước tính, ngay cả với kinh nghiệm trước đó.

Và vấn đề là: mỗi dự án phần mềm giống như leo lên một ngọn núi mới, nơi chưa có ai trước đây, vì vậy không ai có kinh nghiệm trực tiếp trước đó. Các nhà phát triển dày dạn kinh nghiệm có thể đã thu thập kinh nghiệm về các dự án tương tự ít nhiều , nhưng sẽ luôn có những yếu tố mới và bất ngờ - nếu không, nếu một dự án phần mềm giống hệt như một dự án trước đó, sẽ hoàn toàn không có lý do gì để thực hiện .

Bạn đã giải thích điều đó với người đó chưa? Bạn là kỹ sư phần mềm chuyên nghiệp, vì vậy người mà bạn đang xây dựng phần mềm nên xem xét kiến ​​thức và phản hồi của bạn khi nói đến việc thiết kế và triển khai hệ thống phần mềm.

Các Cone của sự không chắc chắn có lẽ là một điểm tốt bắt đầu. Các dự án phần mềm rất khó ước tính cho đến khi biết thêm chi tiết, điều này sẽ xảy ra sau đó trong dự án. Ngoài ra, thay đổi yêu cầu cũng sẽ thay đổi ước tính. Ước tính ban đầu của bạn khi bắt đầu một dự án sẽ có một lượng lớn biến động.

Bạn có thể quan tâm đến các kỹ thuật ước tính khác, quá. Bạn đã đề cập rằng bạn chỉ là một nhà phát triển cơ sở. Nói chung, các nhà phát triển có kinh nghiệm hơn có khả năng ước tính tốt hơn vì họ đã thấy nhiều vấn đề hơn, giải quyết chúng và (hy vọng) theo dõi ước tính so với thời gian thực tế. Bạn có thể tận dụng điều này bằng cách sử dụng các kỹ thuật ước tính như băng rộng băng rộng hoặc lập kế hoạch chơi bài .

Là một nhà phát triển cơ sở, bắt đầu theo dõi ước tính và thời gian thực tế ngay bây giờ. Bạn có thể thích đọc về Quy trình phần mềm cá nhân được phát triển tại Viện Kỹ thuật phần mềm. Các cuốn sách cốt lõi của PSP là Kỷ luật về Kỹ thuật phần mềm , PSP: Quá trình tự cải thiện cho các Kỹ sư phần mềm và Giới thiệu về Quy trình phần mềm cá nhân . Tôi tin rằng Giới thiệu về Quy trình phần mềm cá nhân sẽ bao gồm các chủ đề mà bạn sẽ thấy hữu ích nhất. Tôi nghĩ rằng nó thường quá mức cần thiết cho hầu hết các nhà phát triển, nhưng nó có một số ý tưởng hay và thực tiễn tốt có thể được rút ra và sử dụng để cải thiện năng suất cá nhân và trau dồi các kỹ năng khác nhau (bao gồm cả ước tính) mà bạn sẽ tiếp tục sử dụng trong sự nghiệp của mình.

Nếu bạn sẽ làm nhiều công việc ước tính hơn, tôi rất muốn giới thiệu hai cuốn sách của Steve McConnell: Dự toán phần mềm: Làm sáng tỏ nghệ thuật đen (tập trung vào ước tính như một nghệ thuật và khoa học) và Phát triển nhanh: Lập kế hoạch phần mềm hoang dã (phần mềm chung quy trình kỹ thuật và chủ đề quản lý dự án).

Tham khảo tài liệu. Có một đống lớn các tài liệu phức tạp và thường mâu thuẫn, như đã được chứng minh bằng thực tiễn (thí nghiệm), không hoạt động như mong đợi. Ít nhất các học giả bị ảnh hưởng bởi một đống sách.

Phải đọc: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Tháng huyền thoại: Các tiểu luận về Kỹ thuật phần mềm là một cuốn sách về công nghệ phần mềm và quản lý dự án của Fred Brooks, với chủ đề chính là "thêm nhân lực cho một dự án phần mềm muộn sẽ làm cho nó muộn hơn". Ý tưởng này được gọi là luật của Brooks, và được trình bày cùng với hiệu ứng hệ thống thứ hai và sự ủng hộ của nguyên mẫu.

Những quan sát của Brooks dựa trên kinh nghiệm của ông tại IBM trong khi quản lý sự phát triển của OS / 360. Anh ta đã thêm nhiều lập trình viên vào một dự án nằm ngoài tiến độ, một quyết định mà sau đó anh ta sẽ kết luận một cách trực giác để trì hoãn dự án hơn nữa. Ông cũng đã phạm sai lầm khi khẳng định rằng một dự án - viết trình biên dịch ALGOL - sẽ cần sáu tháng, bất kể số lượng công nhân tham gia (yêu cầu lâu hơn). Xu hướng các nhà quản lý lặp lại những lỗi như vậy trong phát triển dự án đã khiến Brooks châm biếm rằng cuốn sách của ông có tên là "Kinh thánh về Kỹ thuật phần mềm", bởi vì "mọi người đều trích dẫn nó, một số người đọc nó và một vài người đọc nó." Cuốn sách được coi là một tác phẩm kinh điển về các yếu tố con người của công nghệ phần mềm ...

Tìm hiểu những gì họ có kế hoạch làm với ước tính này. Trong tâm trí của họ, họ muốn biết liệu sẽ mất nhiều tháng hay nhiều năm và bạn đang cố gắng để có được số giờ chính xác (Kỹ sư điển hình).

Xem nếu bạn có thể làm việc trên một phần của dự án và sau đó đưa ra một ước tính tốt hơn nếu cần thiết.

Nếu họ tiếp tục đẩy, bạn sẽ bị buộc phải chia thành nhiều nhiệm vụ như bạn có thể áp dụng khung thời gian. Nói với họ bạn sẽ cho họ biết ngay khi bạn thấy bất cứ điều gì có thể ảnh hưởng đến ước tính và điều chỉnh. Mọi người thường cố gắng tránh những điều bất ngờ.

Tôi đã gặp những người tuyên bố họ có thể ước tính phần mềm, nhưng tôi không biết họ làm thế nào. Không ai trong số họ có thể giải thích cách họ làm điều đó.

Là một nhà tư vấn, khách hàng của tôi thường yêu cầu tôi làm việc trên cơ sở giá thầu cố định. Vì vậy, tôi cần phải ước tính để tôi có thể chuẩn bị một giá thầu thực tế. Tôi chưa bao giờ một lần thành công ở đây. Người ta sẽ nghĩ rằng tôi sẽ trả giá cao hơn thường xuyên khi tôi trả giá, nhưng đó không bao giờ là trường hợp. Kết quả là tôi thường mất rất nhiều tiền trong các hợp đồng của mình và cuối cùng kiếm được ít hơn rất nhiều nếu tôi làm việc cho một công ty như một nhân viên bình thường.

Tôi đã tìm kiếm nhiều năm cho một cuốn sách dạy tôi cách ước tính phần mềm, nhưng tôi vẫn chưa tìm thấy.

Đối với việc giải thích điều này cho một người không phải là lập trình viên. Bạn có thể chỉ ra rằng không ai trong ngành luôn có thể đáp ứng ước tính của họ. Nó xảy ra tất cả thời gian mà các sản phẩm phần mềm mới được phát hành trước, chỉ xuất xưởng hàng tháng hoặc hàng năm sau ngày được công bố ban đầu.

Nếu một công ty lớn như Microsoft không thể tìm ra cách ước tính thời gian sản xuất các sản phẩm của riêng mình, tôi phải làm thế nào?

Cho dù tôi được trả theo giờ hay theo công việc, khách hàng của tôi luôn mong tôi cung cấp các ước tính này. Tôi không biết làm thế nào họ mong đợi tôi tạo ra chúng khi ước tính đó không được dạy ở bất cứ đâu và tôi không có cơ sở hợp lý cho các ước tính của mình.

Ước tính toàn bộ thời gian của dự án thường được thực hiện bởi người quản lý dự án chứ không phải người lập trình.

Bạn có thể xây dựng một đối số dựa trên thực tế là người quản lý dự án có danh sách đầy đủ các nhiệm vụ cần thiết. Nếu không có danh sách này, mọi ước tính sẽ là một dự đoán 'xấu'.

Ngoài ra, thời gian phụ thuộc vào nhiều yếu tố như số lượng người có sẵn và phạm vi yêu cầu mà bạn không nói là mình có. Kiến trúc thôi là chưa đủ.

Một điểm khác bạn có thể làm là công nghệ phần mềm vẫn còn ở giai đoạn sơ khai so với các lĩnh vực kỹ thuật khác và chưa đủ trưởng thành để các kỹ thuật phát triển có thể ước tính xuất hiện.

Kỹ thuật phần mềm cũng trong tình trạng liên tục. Vào thời điểm một công nghệ đã đủ để được coi là trưởng thành, nó thường bị bỏ rơi để ủng hộ một số công nghệ mới. Điều đó ngăn cản bất cứ ai có đủ kinh nghiệm với bất kỳ một công nghệ nào để có thể đưa ra các ước tính đáng tin cậy.

Tương phản điều này với dự toán xây dựng. Đó là một vấn đề rất dễ hiểu, không chỉ vì các hợp đồng được trao dựa trên hồ sơ dự thầu, mà bởi vì nhân loại đã xây dựng mọi thứ kể từ buổi bình minh của nền văn minh.