Là nhà phát triển chính, tôi thường nhận được thông số kỹ thuật cho một dự án mới và được hỏi phải mất bao lâu để hoàn thành phần lập trình của công việc liên quan.Tính toán thời gian lập kế hoạch dự án
Tôi chỉ tự hỏi các nhà phát triển khác tính toán những lần này một cách chính xác như thế nào?
Cảm ơn!
Oh và tôi hy vọng điều này không được coi là một câu hỏi tranh luận, tôi chỉ quan tâm đến việc tìm kiếm kỹ thuật tốt nhất!
Ước tính thường được coi là nghệ thuật đen, nhưng nó thực sự dễ quản lý hơn mọi người nghĩ.
Tại Inntec, chúng tôi phát triển phần mềm hợp đồng, hầu hết nếu có liên quan đến việc làm việc với chi phí cố định. Nếu ước tính của chúng tôi liên tục tắt, chúng tôi sẽ không hoạt động trong thời gian ngắn.
Nhưng chúng tôi đã kinh doanh được 15 năm và chúng tôi có lãi, vì vậy rõ ràng toàn bộ điều ước tính này là khả năng giải quyết được.
Bắt đầu
Hầu hết những người nhấn mạnh ước lượng đó là không thể được làm đoán hoang dã. Điều đó có thể làm việc không thường xuyên cho các dự án nhỏ nhất, nhưng nó chắc chắn không quy mô. Để có được độ chính xác nhất quán, bạn cần một cách tiếp cận có hệ thống.
Năm trước, người cố vấn của tôi đã cho tôi biết điều gì đã hiệu quả với anh ấy. Nó giống như phương pháp ước tính cũ của Joel Spolsky, mà bạn có thể đọc ở đây: Joel on Estimation. Đây là một cách tiếp cận đơn giản, công nghệ thấp và nó hoạt động tốt cho các nhóm nhỏ. Nó có thể bị hỏng hoặc yêu cầu sửa đổi cho các nhóm lớn hơn, nơi mà chi phí giao tiếp và quá trình bắt đầu chiếm một phần đáng kể thời gian của mỗi nhà phát triển.
Tóm lại, tôi sử dụng bảng tính để chia nhỏ dự án thành các phần nhỏ (dưới 8 giờ), có tính đến mọi thứ từ thử nghiệm đến giao tiếp tới tài liệu. Cuối cùng, tôi thêm vào một hệ số 20% cho các mục và lỗi không mong muốn (chúng tôi phải sửa chữa miễn phí trong 30 ngày).
Rất khó để giữ ai đó ước tính rằng họ không có ý định tạo ra. Một số người muốn có toàn bộ nhóm ước tính mỗi mục và đi với số cao nhất. Tôi sẽ nói rằng ít nhất, bạn nên thực hiện ước tính bi quan và cho nhóm của bạn một cơ hội để nói lên nếu họ nghĩ rằng bạn đang đi.
Học tập và Nâng cao
Bạn cần thông tin phản hồi để cải thiện. Điều đó có nghĩa là theo dõi số giờ thực tế bạn chi tiêu để bạn có thể so sánh và điều chỉnh ý nghĩa ước tính của mình.
Ngay bây giờ tại Inntec, trước khi chúng tôi bắt đầu làm việc trên một dự án lớn, các mục hàng bảng tính trở thành ghi chú dán trên bảng kanban của chúng tôi và người quản lý dự án theo dõi tiến trình trên chúng mỗi ngày. Bất cứ khi nào chúng tôi đi qua hoặc có một món đồ mà chúng tôi không cân nhắc, nó sẽ trở thành một miếng nhỏ màu đỏ, và nó cũng đi vào báo cáo ghi chép của chúng tôi. Hai công cụ này cùng nhau cung cấp phản hồi vô giá cho toàn đội.
Đây là ảnh của một bảng kanban điển hình, khoảng nửa chừng qua một dự án nhỏ.
Bạn có thể không có khả năng đọc các tiêu đề cột, nhưng họ nói Backlog, Brian, Keith, và chọn Xong. Backlog được chia nhỏ theo nhóm (khu vực quản trị, vv) và các nhà phát triển có một cột hiển thị (các) mục họ đang làm việc.
Nếu bạn có thể nhìn kỹ, tất cả các ghi chú đó đều có số giờ ước tính trên chúng và cột ghi chú trong cột của tôi, nếu bạn thêm chúng, nên bằng khoảng 8, vì đó là bao nhiêu giờ ngày làm việc. Thật bất thường khi có bốn người trong một ngày. Cột của Keith trống rỗng, vì vậy có lẽ anh ta đã ra ngoài vào ngày này.
Nếu bạn không biết tôi đang nói về những gì: các cuộc họp đứng, scrum, báo cáo ghi xuống, vv, hãy xem scrum methodology. Chúng tôi không tuân theo nó, nhưng nó có một số ý tưởng tuyệt vời không chỉ để ước tính, mà còn để học cách dự đoán khi nào dự án của bạn sẽ xuất xưởng khi công việc mới được thêm vào và ước tính bị bỏ qua hoặc gặp hoặc vượt quá (điều đó xảy ra). Bạn có thể xem công cụ tuyệt vời này được gọi là báo cáo ghi xuống và nói: chúng tôi thực sự có thể giao hàng trong một tháng và hãy xem báo cáo ghi xuống để quyết định những tính năng chúng tôi đang cắt.
FogBugz có một thứ gọi là Lập biểu dựa trên bằng chứng có thể là cách dễ dàng hơn, tự động hơn để nhận các lợi ích mà tôi đã mô tả ở trên. Ngay bây giờ tôi đang thử nó trên một dự án nhỏ bắt đầu trong một vài tuần. Nó có một báo cáo ghi sẵn được tích hợp sẵn và nó thích hợp với việc lập kế hoạch không chính xác của bạn, do đó có thể khá mạnh mẽ.
Cập nhật: Chỉ cần lưu ý nhanh. Một vài năm đã trôi qua, nhưng cho đến nay tôi nghĩ rằng mọi thứ trong bài đăng này vẫn giữ được ngày hôm nay. Tôi cập nhật nó để sử dụng từ kanban, vì hình ảnh trên thực sự là một bảng kanban.
Tôi biết điều này là 3 tuổi, nhưng bạn có thể đăng lại hình ảnh của bảng dự án mà bạn đã đăng khoảng hai phần ba xuống bài đăng của bạn không? –
+1 để cung cấp cho chúng tôi một tham chiếu tốt như 'Joel on Estimation' – kta
@WilliamGrand Tôi không thể tìm thấy hình ảnh đó, nhưng tôi đã cắm vào một hình ảnh tương tự và chỉnh sửa xung quanh nó. –
Ước tính tốt đi kèm với trải nghiệm hoặc đôi khi không hoàn toàn.
Tại công việc hiện tại của tôi, 2 đồng nghiệp của tôi (dường như có nhiều kinh nghiệm hơn tôi) thường bị đánh giá thấp gấp 8 lần (có, EIGHT) lần. Tôi, OTOH, chỉ có một lần trong 18 tháng qua đã vượt qua ước tính ban đầu.
Tại sao điều đó xảy ra? Không ai trong số họ, dường như không thực sự biết những gì họ đang làm, codewise, vì vậy họ có nghĩa là ngón tay cái mút.
Bottom line:
Không bao giờ đánh giá thấp, nó là an toàn hơn nhiều để đánh giá quá cao. Cho sau này bạn luôn có thể 'tăng tốc' phát triển, nếu cần thiết. Nếu bạn đã ở trên một dòng thời gian chặt chẽ, không có nhiều bạn có thể làm.
Đây có lẽ là một trong những misteries lớn trong lĩnh vực CNTT. Vô số dự án phần mềm thất bại đã chỉ ra rằng chưa có giải pháp hoàn hảo cho điều này, nhưng điều gần nhất để giải quyết điều này tôi đã tìm thấy cho đến nay là sử dụng cơ chế ước lượng thích ứng được xây dựng trong FogBugz.
Về cơ bản, bạn đang phá vỡ các mốc quan trọng của mình thành các tác vụ nhỏ và dự đoán sẽ mất bao lâu để hoàn thành chúng. Không có tác vụ nào dài hơn 8 giờ. Sau đó, bạn nhập tất cả các nhiệm vụ này như các tính năng được lên kế hoạch vào Fogbugz. Khi hoàn thành nhiệm vụ, bạn theo dõi thời gian của mình với FogBugz. Sau đó, Fogbugz sẽ đánh giá các ước tính trong quá khứ và thời gian thực tế của bạn và sử dụng thông tin đó để dự đoán một cửa sổ (với xác suất) mà bạn sẽ hoàn thành một vài mốc quan trọng tiếp theo của mình.
Ah muốn chúng tôi vẫn có FogBugz! Chúng tôi từng sử dụng điều này, nhưng nhóm nghiên cứu đã không thích ứng với nó tốt nên tài khoản đã bị hủy bỏ: ( – Curt
Nếu bạn đang sử dụng FogBugz, thì Evidence Based Scheduling ước tính ngày hoàn thành rất dễ dàng.
Bạn có thể không, nhưng có lẽ bạn có thể áp dụng các nguyên tắc của EBS để đưa ra ước tính.
Đánh giá quá cao hơn là đánh giá thấp. Đó là bởi vì chúng tôi không biết thông số kỹ thuật "không xác định" và (trong hầu hết các trường hợp) thay đổi trong suốt vòng đời phát triển phần mềm.
Theo kinh nghiệm của mình, chúng tôi sử dụng các bước lặp lại (giống như trong Phương pháp Agile) để xác định dòng thời gian của chúng tôi. Chúng tôi chia nhỏ các dự án thành các thành phần và đánh giá quá cao các thành phần đó. Tổng các ước tính này được sử dụng và tăng thêm thời gian để thử nghiệm và triển khai hồi quy, và tất cả công việc tốt ....
Tôi nghĩ rằng bạn phải quay trở lại từ các dự án trước đây và học từ những sai lầm đó bạn có thể ước tính một cách khôn ngoan.
Không có kỹ thuật chung. Bạn sẽ phải dựa vào trải nghiệm của bạn (và nhà phát triển của bạn). Bạn sẽ phải tính đến tất cả các biến môi trường và quá trình phát triển. Và ngay cả khi đối phó với điều này, có một cơ hội lớn bạn sẽ bỏ lỡ một cái gì đó.
Tôi không thấy bất kỳ điểm nào trong việc ước tính thời gian lập trình. Quá trình phát triển được kết nối với nhau, việc ước tính một bên của nó sẽ không tạo ra bất kỳ kết quả có giá trị nào. Toàn bộ điều cần được ước tính, bao gồm lập trình, thử nghiệm, triển khai, phát triển kiến trúc, viết tài liệu (tài liệu công nghệ và hướng dẫn sử dụng), tạo và quản lý vé trong bộ theo dõi vấn đề, cuộc họp, kỳ nghỉ, lá bị bệnh (đôi khi nó phải đợi anh chàng, sau đó giao nhiệm vụ cho người khác), các phiên kế hoạch, nghỉ giải lao.
Dưới đây là một ví dụ: chỉ mất 3 phút để trứng được rang khi bạn thả nó lên cây chiên. Nhưng nếu bạn nói rằng phải mất 3 phút để làm một quả trứng chiên, bạn là sai. Bạn bỏ lỡ:
Dưới đây là một cuốn sách khởi đầu tốt về lập dự toán dự án:?
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
Nó có một mô tả tốt về một số kỹ thuật ước tính. Nó giúp bạn có được trong vài giờ đọc.
Chỉ nghĩ rằng tôi sẽ nói rằng tôi có cuốn sách này, và vì mục đích của tôi, nó không thực tế lắm. có thể một số người khác có một số giá trị của nó. –
Yêu cầu ước tính trường hợp xấu nhất và nhân với 5. – Oded
@Oded: Theo kinh nghiệm của tôi, 8 là số an toàn hơn :) – leppie
@leppie - Tôi là người lạc quan ở trung tâm ... – Oded