Tại sao lịch trình phần mềm rất khó xác định?

Dường như, theo kinh nghiệm của tôi, việc các kỹ sư của chúng tôi ước tính chính xác và xác định các nhiệm vụ cần hoàn thành giống như nhổ răng. Thay vì chỉ đưa ra ước tính swag trong 2-3 tuần hoặc 3-6 tháng ... cách đơn giản nhất để xác định lịch trình phần mềm để chúng không quá khó để định nghĩa? Chẳng hạn, khách hàng A muốn có một tính năng trước ngày 02/01/2011. Làm thế nào để bạn sắp xếp thời gian để thực hiện tính năng này khi biết rằng có thể cần phải sửa các lỗi khác trên đường đi và chiếm thêm thời gian kỹ thuật?

Nếu bạn đang tạo ra một dự án gần giống với các dự án khác mà bạn đã thực hiện, sử dụng các công cụ quen thuộc và một nhóm quen thuộc, và bạn được cung cấp các yêu cầu bằng văn bản, chắc chắn, thì có thể ước tính tốt.

Đây là những điều kiện mà các họa sĩ, thợ lắp đặt thảm, người làm vườn, v.v., thường xuyên gặp phải. Nhưng nó không phù hợp với nhiều dự án phần mềm (hoặc hầu hết).

Chúng tôi thường được yêu cầu ước tính các dự án sử dụng các công cụ, công nghệ mới, nơi các yêu cầu đang thay đổi, v.v. Đây là phép ngoại suy thành ẩn số hơn là nội suy qua các kinh nghiệm trong quá khứ của chúng tôi. Vì vậy, việc ước tính sẽ khó khăn hơn.

Theo kinh nghiệm cá nhân của tôi, nó hoàn toàn trái ngược với những gì Pemdas đã nói : với thực tế, tôi chỉ hiểu rằng hoàn toàn không thể ước tính được một nhiệm vụ sẽ cần bao nhiêu thời gian. Khi bắt đầu sự nghiệp phát triển phần mềm, tôi thường đưa ra các ước tính như "45 ngày", "năm tuần", v.v., sau đó đã rất cố gắng để hoàn thành kịp thời gian. Vài năm sau, tôi bắt đầu đưa ra các ước tính ít chính xác hơn như "khoảng một tháng", "năm đến bảy tuần", v.v. Thật ra, tôi cố gắng không đưa ra bất kỳ ước tính nào, hoặc yêu cầu khách hàng đưa ra ước tính của riêng mình hoặc thời hạn hoặc tôi đưa ra một ước tính càng thô càng tốt.

Tại sao nó rất khó để có một ước tính? Bởi vì gần như không thể biết toàn bộ mã nguồn sẽ được viết như thế nào trước khi thực sự viết nó và bởi vì công việc của bạn phụ thuộc vào những điều ngẫu nhiên khi những người khác làm việc, động lực của bạn, v.v ... Dưới đây là danh sách chi tiết hơn về các lý do có thể:

1. Không dễ để biết chính xác những gì được yêu cầu để làm một sản phẩm, và đặc biệt là làm thế nào để làm điều đó . Rất thường xuyên, tôi bắt đầu một số phần của một ứng dụng, hơn là sau nhiều ngày làm việc, tôi hiểu rằng cách tiếp cận đầu tiên của tôi là sai, và có một cách tốt hơn và thông minh hơn để làm mọi việc.

2. Một số vấn đề có thể phát sinh . Ví dụ: nếu, để bắt đầu công việc của bạn, bạn phải cài đặt trên máy của mình một máy chủ SQL ưa thích và cài đặt không thành công và hỗ trợ không tồn tại, bạn có thể mất hàng tuần để giải quyết vấn đề này.

3. Yêu cầu thường không đủ rõ ràng , nhưng sau khi đọc chúng lúc đầu, bạn nghĩ rằng chúng là như vậy. Đôi khi bạn có thể hiểu rằng nghĩa 'A' và sau khi bắt đầu thực hiện chúng, bạn sẽ nhận thấy rằng chúng có thể có nghĩa là 'B'.

4. Khách hàng thích thay đổi chính xác yêu cầu của họ khi bạn vừa hoàn thành phần có liên quan và họ thực sự không hiểu tại sao bạn yêu cầu thêm hai tuần và 2000 đô la để thực hiện một thay đổi nhỏ , vì họ không thấy rằng thay đổi nhỏ này yêu cầu thay đổi những thứ khác, đòi hỏi phải thay đổi những người khác, vv

5. Bạn không thể ước tính động lực của bạn . Có những ngày bạn có thể làm việc hàng giờ và thành công tốt đẹp. Có những tuần, sau khi viết mười dòng mã, bạn chuyển sang Lập trình viên StackExchange và dành hàng giờ để đọc câu trả lời.

6. Mọi thứ trở nên thực sự tồi tệ khi ước tính của bạn phụ thuộc vào người khác . Ví dụ, trong một dự án 2 tháng, tôi đã phải chờ một nhà thiết kế thực hiện công việc của mình để hoàn thành công việc của riêng tôi. Nhà thiết kế này đã mất 3 tháng trước khi đưa ra một mẩu tin không thể sử dụng được. Tất nhiên dự án đã muộn.

7. Ước tính của bạn cũng phụ thuộc vào khách hàng của bạn . Tôi đã có những khách hàng dành hàng tuần trước khi trả lời thư của họ. Nó thực sự có thể ảnh hưởng đến lịch trình của bạn khi bạn phải chờ câu trả lời của họ (ví dụ nếu bạn yêu cầu họ đưa ra yêu cầu chính xác).

Bạn có thể làm gì?

1. Đưa ra một lịch trình lớn hơn . Nếu bạn nghĩ rằng bạn có thể thực hiện công việc trong hai tuần, hãy nói rằng bạn sẽ giao nó trong một tháng.

2. Hãy rõ ràng . Nếu bạn dựa vào một nhà thiết kế, một nhà phát triển khác, v.v., hãy nói điều đó. Thay vì nói "Tôi sẽ giao sản phẩm trong ba tháng", hãy nói "Tôi sẽ giao sản phẩm trong hai tháng sau khi nhà thiết kế sẽ đưa cho tôi các tệp PSD."

3. Giải thích rằng nếu các yêu cầu thay đổi mỗi ngày, dự án sẽ khó được giao kịp thời.

4. Cắt lát lịch trình của bạn . Cung cấp các bộ phận của một dự án lớn đúng thời gian dễ dàng hơn.

5. Không bao giờ đưa ra ước tính khi bạn sử dụng một sản phẩm mà bạn không biết rõ hoặc đặc biệt là khi bạn sẽ làm việc với mã nguồn của người khác: bạn không bao giờ có thể dự đoán được mã nguồn có thể tệ đến mức nào và bạn sẽ dành bao nhiêu thời gian hiểu và sao chép nó vào WTF hàng ngày.

Một câu hỏi rất giống là "Sẽ mất bao lâu để giải câu đố ô chữ này?"

Bạn không thể trả lời rằng cho đến khi bạn đã xem nó để thấy vô số điều như:

• Có phải trong một ngôn ngữ quen thuộc? (Tiếng Tây Ban Nha so với tiếng Anh so với tiếng Trung Quốc)
• Đây có phải là một trong những loại chúng tôi đã giải quyết trước đây? (Một trong một loạt chạy trong một tạp chí, ví dụ)
• Có bất kỳ khách hàng tiềm năng nào yêu cầu kiến ​​thức bổ sung trước khi chúng ta có thể hiểu nó không?
• Có nơi nào trong câu đố mà theo hiểu biết của bạn, sẽ cần thêm công việc không?

Vì thường có một vài điều mới trong một dự án (nếu không đó không phải là một dự án), bạn không thể biết họ sẽ mất bao lâu để giải quyết cho đến khi bạn có một cái nhìn rất cẩn thận về chúng. Có lẽ thậm chí giải quyết ít nhiều hoặc họ, và sau đó bạn vẫn không chắc chắn rằng không có bất ngờ hay hai nơi mà bạn không nghĩ về họ.

Ngoài ra, có một áp lực mạnh mẽ để làm điều đó với giá rẻ nhất có thể, do đó càng nhanh càng tốt và đổ lỗi cho một ước tính quá thấp không gây áp lực cho người quản lý dự án mà là nhà phát triển đưa ra ước tính. Nhà phát triển không mất nhiều lần lặp lại để nắm bắt điều này và học cách RẤT mệt mỏi khi đưa ra bất kỳ con số tuyệt đối nào.

Lý do rõ ràng nhất khiến các kỹ sư của bạn không thể đưa ra ước tính chính xác là không thể .

Tất nhiên bạn có thể ước tính mất bao nhiêu thời gian + -2 phút từ nhà bạn để làm việc. Bạn biết cách lái xe, bạn có thể đánh giá giao thông và một số yếu tố bên ngoài khác.

Hãy cho tôi biết bạn sẽ mất bao nhiêu thời gian để lái xe từ London đến Barcelona. Tất nhiên không có công cụ lập kế hoạch GPS tiên tiến. Sử dụng phương pháp cũ tốt như chúng ta vẫn làm trong ước tính phần mềm. Dự đoán và dự đoán theo kinh nghiệm .

Trong phần mềm, nó tệ hơn:

1. Ước tính thường trở thành một cam kết , vì vậy đánh giá của chúng tôi được sửa đổi.
2. Có thể có sự khác biệt rất lớn giữa ước tính của Bob và Karl cho cùng một nhiệm vụ.
3. Sự không chắc chắn là rất phổ biến, có bao nhiêu người trong chúng ta bị mắc kẹt trong một lỗi ngu ngốc hoặc sự cố ổ cứng phá hủy mọi ước tính tốt rõ ràng.
4. Chúng ta thường quên đi tất cả các nhiệm vụ khác ngoài lập trình, bao gồm các cuộc họp, các cuộc gọi điện thoại, giúp đỡ đồng nghiệp, v.v.
5. Bộ não con người bị hạn chế . Nó đã không được thiết kế để ước tính các nhiệm vụ chạy dài.

Đó là lý do tại sao không thể nói với khách hàng của bạn những gì bạn sẽ có thể giao hàng cho ngày 02/01/2011 với độ chính xác tốt và quên ngày 03/01/2011.

Để giải quyết tất cả những vấn đề đó, tôi khuyên bạn nên sử dụng các kỹ thuật ước tính nâng cao như Planning Poker (từ chối trách nhiệm: đây là một trong những trang web của tôi) và Phát triển lặp với tính toán Vận tốc .

• Hai vấn đề đầu tiên được giải quyết bằng Planning Poker. Ước tính là tập thể và nhóm sở hữu chúng chứ không phải cá nhân.
• Các vấn đề thứ ba cuối cùng được giải quyết bằng cách sử dụng Vận tốc và Phát triển lặp. Bằng cách biết vận tốc của bạn (yếu tố để áp dụng cho các ước tính của bạn dựa trên lịch sử), bạn có thể lập kế hoạch phát hành với độ tin cậy cao hơn. Phát triển lặp lại, khi được thực hiện tốt, đưa các tính năng quan trọng nhất lên hàng đầu và giúp bạn sớm cung cấp giá trị cho người dùng của mình.

Phát triển phần mềm là - theo định nghĩa - một hành động khám phá và phát minh. Nó phải luôn luôn liên quan đến một cái gì đó chưa biết.

Lần duy nhất mọi thứ liên quan đến phát triển phần mềm được biết đến là khi phần mềm hoàn tất.

Lần duy nhất không có công nghệ hoặc tính năng kinh doanh không xác định là khi đó là một giải pháp đóng gói hoàn chỉnh, sẵn sàng để tải xuống.

Lý do chúng tôi viết phần mềm mới là vì chúng tôi có một tính năng mới hoặc công nghệ mới hoặc cả hai. Mới có nghĩa là mới - chưa biết - không thể đoán trước.

Bởi vì phát triển phần mềm phải liên quan đến tính mới, nên nỗ lực phát triển không thể dự đoán được.

Thành thật mà nói, tôi nghĩ rằng nó chỉ cần thực hành. Nếu bạn viết đủ mã cuối cùng, bạn sẽ "khá" chính xác. Sếp đầu tiên của tôi tin rằng kỹ năng này đủ quan trọng để anh ta yêu cầu tôi thực hành điều này một cách không chính thức trên mọi tính năng / dự án mà tôi thực hiện. Sau mỗi dự án, chúng tôi đã xem xét các ước tính và cố gắng tìm ra nơi tôi đã sai. Cuối cùng, bạn có được hang của nó.

Nó không bao giờ dễ dàng. Bạn chỉ cần cố gắng để có được tốt hơn về nó.

Một lợi thế của việc chia mã có thể phân phối của bạn thành các phần nhỏ hơn, là để khách hàng hiểu được những gì mong đợi và khi nào cần nó. Bây giờ bạn có một số loại đường cơ sở để họ sử dụng làm tài liệu tham khảo.

Nếu họ có định nghĩa chặt chẽ về một tính năng mà họ cần tại một thời điểm xác định, họ cần biết rằng các tài nguyên bổ sung phải được phân bổ cho yêu cầu này. Họ đang mạo hiểm về mức độ nghiêm trọng của các lỗi xảy ra và thời gian chúng có thể đi mà không cần sửa chúng. Khi một cái gì đó quan trọng xuất hiện, bạn quay trở lại khách hàng và buộc họ đưa ra quyết định. Tôi có sửa lỗi hoặc đưa ra thời hạn cho tính năng mới không? Cung cấp cho họ đủ thông tin để đưa ra quyết định sáng suốt.

Hy vọng rằng bạn có đủ lịch sử làm việc cùng nhau và đã thiết lập bản thân đủ để được tin tưởng. Bạn không thể mong đợi họ hiểu đầy đủ về quá trình phát triển, nhưng bạn có thể khiến họ cảm thấy bạn đang nỗ lực trung thực và không tận dụng sự thiếu hiểu biết của họ.

Bởi vì chúng tôi làm lịch trình quá sớm. Xem bài viết của Construx về làm sơ bộ sơ bộ, sau đó tốt hơn sau. Ngoài ra nếu bạn không theo dõi cách bạn đã làm theo ước tính trước đó, thật khó để cải thiện. FogBugz thực hiện điều đó [một khách hàng của họ miễn phí, không có xung đột lợi ích nào khác].

Tôi đã học được rất nhiều từ cuốn sách này:

Dự toán phần mềm: Làm sáng tỏ nghệ thuật đen

Trong ngắn hạn để có được kết quả ước tính tốt hơn, chúng tôi làm điều này:

1. tất cả trừ những nhiệm vụ tầm thường được ước tính bởi hơn một người (hai trong trường hợp của chúng tôi)
2. chúng tôi chia nhiệm vụ thành nhiệm vụ nhỏ hơn. Càng có nhiều nhiệm vụ, khả năng ước tính của bạn sẽ càng tốt - luật số lượng lớn nếu tôi nhớ chính xác từ boo
3. chúng tôi ước tính kịch bản tồi tệ nhất, tốt nhất và có khả năng nhất. Đôi khi mỗi chúng ta ước tính những kịch bản cây hoàn toàn khác nhau. Điều đó có nghĩa là chúng ta phải nói chuyện và thường thì hóa ra là một trong số chúng ta không hiểu nhiệm vụ. Nếu một người ước tính nhiệm vụ một mình nó sẽ được ước tính sai.
4. chúng ta đặt 3 số từ điểm trên vào phương trình và nhận ước lượng (excell) k

Sau khi nhiệm vụ công việc kết thúc và ước tính của chúng tôi bị sai, chúng tôi cố gắng tìm lý do tại sao. Và chúng tôi kết hợp kiến ​​thức này vào quá trình ước tính tiếp theo. Cho đến nay đây là quá trình tốt nhất tôi đã sử dụng để ước tính các nhiệm vụ lớn hơn. Khi tôi nói nhiệm vụ tôi có nghĩa là các công việc mất từ ​​khoảng 50-500 giờ.

Lưu ý: Điều này thực sự chỉ áp dụng cho các dự án mà bạn lập hóa đơn theo giờ so với tỷ lệ cố định / căn hộ.

Tôi thường cố gắng lên kế hoạch cho lịch trình của mình để nó chủ yếu bao gồm một loạt các SCRUM Sprints (cho dù có sử dụng SCRUM hay không). Trước khi lập lịch trình, tôi xác định độ dài mỗi lần chạy nước rút và các tính năng sẽ dành cho dự án. Thông thường, có một số tính năng phải được thực hiện trước tiên vì vậy tôi cố gắng đưa ra ước tính tốt nhất (không bị nhầm lẫn với sự lạc quan) cho những tính năng đó và bất kỳ tính năng nào sẽ đến cuối dự án sẽ có ước tính tổng quát. Sau khi ánh xạ các tính năng thành chạy nước rút, tôi cố gắng thêm 1 đến 2 lần chạy nước rút ở phần đuôi của dự án để tính đến các tính năng trượt sang phải và cho các tính năng bị bỏ qua trong tập hợp yêu cầu ban đầu.

Chìa khóa cho vấn đề này là tôi làm cho tất cả những điều này minh bạch cho khách hàng trả trước để họ hiểu tại sao hai lần chạy nước rút cuối cùng lại trống rỗng hoặc dân cư thưa thớt. Ít nhất là đến thời điểm này, khách hàng mà tôi đã làm việc đã thích điều này vì họ biết rằng có một số đệm trong lịch trình / tài chính vì hầu hết họ đều biết rằng ước tính SW có xu hướng ít hơn cụ thể. Họ cũng nhận thức được rằng nếu chúng ta không cần nước rút cuối cùng thì đó là những giờ chúng ta không lập hóa đơn. Với tính minh bạch trong cách xây dựng lịch trình và phản hồi thường xuyên về tiến trình đang diễn ra trong quá trình thực hiện dự án, mọi khách hàng mà tôi đã thực hiện điều này đã vô cùng hài lòng.

Ngoài tất cả những điều được đặt tên, tôi thấy hai điều này là một số vấn đề lớn nhất. Trước tiên, bạn ước tính ngày cuối cùng dựa trên mỗi devloper có sẵn trong 8 giờ một ngày 5 ngày một tuần. Điều này là không chính xác và hầu như sẽ đảm bảo 100% rằng ngày kết thúc bị bỏ lỡ trên bất kỳ dự án nào không tầm thường. Mọi người dành thời gian nghỉ ngơi, tham dự các cuộc họp của công ty (hoặc không dựa trên dự án), đấu tranh với nhân sự về yêu cầu bảo hiểm y tế, nghỉ giải lao, v.v. Không bao giờ giả sử có sẵn hơn 6 giờ mỗi nhà phát triển mỗi ngày.

Các nhà phát triển tiếp theo nổi tiếng quên ước tính tất cả các nhiệm vụ không phát triển như các cuộc họp và email liên quan đến dự án, triển khai, hỗ trợ QA, hỗ trợ UAT, viết bài kiểm tra đơn vị, nghiên cứu, tài liệu, v.v. ước tính có cách tốt hơn.

Khi ước tính thời gian cho các nhiệm vụ có thể mất nhiều thời gian hơn một vài giờ, tôi cố gắng hết sức để sử dụng quy tắc này:

1. Đừng bao giờ cố gắng dự đoán khi nào người khác sẽ hoàn thành công việc của họ nếu bạn tình cờ phụ thuộc vào nó. Chỉ nói cho chính mình.
2. Đầu tiên phân tích nhiệm vụ, sau đó ước tính. Bằng cách phân tích, tôi có nghĩa là ít nhất là viết ra (và không cố giữ mọi thứ trong đầu bạn!) Một danh sách các nhiệm vụ với ước tính cho từng người trong số họ.
3. Nếu một nhiệm vụ đủ phức tạp, hãy ước tính thời gian cho chính phân tích đó. Hãy để ước tính là một quá trình riêng biệt. Bạn cũng có thể chắc chắn rằng ông chủ của bạn biết về điều đó.
4. Đừng ước tính dưới áp lực. Hãy nói rõ rằng cần có thời gian để đưa ra ước tính hợp lý và chỉ cần nói với họ điều gì đó như "Tôi sẽ đặt tên cho một ngày mai vào lúc 11:00 khi tôi hoàn thành phân tích nhiệm vụ". Tôi biết một số khách hàng / người quản lý có thể nhấn mạnh, nhưng họ sẽ không vượt qua. Đặt khuôn mặt bận rộn của bạn và yêu cầu thời gian của bạn!
5. Hỏi thêm một chút thời gian so với bạn nghĩ bạn sẽ cần bởi vì có lẽ bạn đã quên thêm thời gian giải lao cà phê (và giả sử sự sai lệch) trong ước tính của bạn.
6. Đối với các nhiệm vụ lớn, hãy hỏi nhiều hơn - có thể sẽ có nhiều hơn một lần uống cà phê.
7. Nếu bạn thực sự không thể ước tính (nhiệm vụ quá khó / không quen thuộc) hoặc thực sự không chắc chắn - hãy hỏi ai đó có khả năng giúp đỡ với phân tích của bạn.

Có thể có nhiều quy tắc hơn thế, nhưng tôi thực sự không có một poster với quy tắc này trên tường của tôi. Tôi chỉ xây dựng chúng bây giờ, nhưng chúng đến từ kinh nghiệm của tôi (vì vậy nó có thể không phù hợp với bạn).

Cách đáng tin cậy duy nhất để lên lịch phát triển phần mềm mà tôi có thể nghĩ ra (nhưng tôi chưa thực sự thử nó) là Lập kế hoạch dựa trên bằng chứng , về cơ bản là phương pháp Monte Carlo được sử dụng để tính xác suất ngày tàu dựa trên hồ sơ lịch sử về các nhiệm vụ mà bạn ' đã hoàn thành trước đây. Cảm giác thật tuyệt vì không thử sử dụng bất kỳ số liệu nào ngoài thời gian ước tính và thời gian thực tế. Tuy nhiên, nó đòi hỏi nhiều kinh nghiệm để phân chia các nhiệm vụ lớn thành các nhiệm vụ nhỏ hơn trước đó và bạn phải có một bộ dữ liệu lịch sử lớn để làm cho nó hoạt động đủ chính xác.

Có "ẩn số đã biết" và "ẩn số chưa biết". :-)

1. Ước tính thường trở thành thời hạn.

   • Không ai muốn bỏ lỡ một thời hạn và trở thành tiêu đề!

2. Yêu cầu thay đổi (thường là hợp lý) và lập trình viên không thể phủ quyết nó.

3. Lập trình viên làm / có thể không kiểm soát các yếu tố như

   • Có sẵn mã cô ấy phụ thuộc vào
   • Chất lượng mã cô ấy phụ thuộc vào
   • Kiến trúc và thiết kế tổng thể của hệ thống
   • API để truy cập các phần khác của hệ thống