Mất bao lâu để ước tính các nhiệm vụ lập trình?

9

Ví dụ: nếu tôi chia một dự án thành n sản phẩm công việc riêng biệt (giả sử các lớp hoặc hàm hoặc thành phần) thì có phải là thời gian phù hợp để n * t là một khoảng thời gian phù hợp để ước tính không?

estimation

— Michael Behan
nguồn

9

Dễ thôi. Chỉ cần lập kế hoạch một chút thời gian để xem xét khối lượng công việc của bạn và ước tính khoảng thời gian ước tính sẽ mất và ... oh, chờ đợi.

— joshin4colours

Vì tất cả các ước tính của bạn sẽ luôn luôn sai, lợi tức đầu tư bằng không = thời gian không chi tiêu. Oh ngoại trừ ông chủ sẽ buộc bạn tạo ước tính không có thật. Agile ước tính nơi bạn chọn một số số ngẫu nhiên của Wikipedia trong một số đơn vị đo lường đơn vị ngẫu nhiên được gọi là BogoEstimons, hoặc một cái gì đó, có vẻ tốt hơn so với ước tính trong các đơn vị làm việc theo giờ thực của con người.

— Warren P

Ước tính thời gian để ước tính nhiệm vụ. Hãy để Công cụ Ước tính bắt đầu

— người dùng

13

Nếu bạn có đủ thông tin để chia nhỏ nó xuống mức đó, bạn không nên dành nhiều hơn một phút cho mỗi cái. Dù sao thì bạn cũng sẽ không đúng, nhưng bạn sẽ đúng sau một phút như sau một giờ.

Mặt khác, nếu bạn đang nói về những câu chuyện của người dùng , tôi sẽ đề nghị đưa các bên liên quan vào một phòng và dành năm phút để đặt câu hỏi trước khi ước tính.

Bất kể, đừng lãng phí nhiều thời gian để ước tính. Chúng không hữu ích hoặc đủ chính xác để xứng đáng với nỗ lực.

— pdr
nguồn

3

+1. nhưng tôi không đồng ý rằng ước tính không hữu ích lắm. Họ giúp lập kế hoạch tốt hơn, và có năng suất cao hơn.

— superM

4

@superM: Tôi không nói rằng chúng không hữu ích chút nào. Họ chắc chắn là có. Tôi đã nói rằng họ không có giá trị nhiều thời gian sử dụng. Phần mềm làm việc hữu ích hơn nhiều, vì vậy hãy dành phần lớn thời gian của bạn cho việc đó.

— pdr

@superM: Bạn đã bao giờ làm một so sánh giữa các ước tính của bạn và các giá trị thực? Điều này sẽ cho một bài học tuyệt vời về giá trị thực của phỏng đoán (mà theo ước tính là theo định nghĩa). Ước tính là một điều Pareto cổ điển: Bạn có được ước tính khá tốt trong 20% thời gian. Lãng phí thêm thời gian sẽ làm cho nó chỉ tốt hơn 5%.

— JensG

Đối với tôi, tôi làm việc trong một dự án càng lâu, tôi càng ước tính tốt hơn. Có quá nhiều yếu tố và một số yếu tố tôi không thể kiểm soát và biết những yếu tố [đặc thù của dự án] đi kèm với kinh nghiệm. Đôi khi bạn không thể thoát khỏi việc ước tính và đôi khi bạn nằm trong số những người phải chịu đựng những ước tính không chính xác của bạn.

— superM

2

Theo kinh nghiệm của tôi, một trong những điều cốt lõi 'vâng, thực sự hiệu quả' của cách tiếp cận nhanh là phương pháp 'Nhiệm vụ nên mất ít hơn một ngày'. Nếu bạn ước tính những thứ mất nhiều thời gian hơn một ngày, bạn sẽ trở nên khá xa.

Khi bạn đã chia nhỏ chúng để bạn có thể làm điều đó, bạn đã làm đủ; bất kể những gì thực sự là những gì.

— Telastyn
nguồn

2

Trong phương pháp nhanh nhẹn, Planning Poker được xem là một cách hiệu quả để sử dụng toàn bộ nhóm để nhanh chóng ước tính nỗ lực cần thiết cho các câu chuyện của người dùng trong một lần chạy nước rút (giả sử đây là điều bạn đang nói đến). Mặt khác, tôi sẽ không dành quá vài phút để ước tính một tác vụ duy nhất là một phần của câu chuyện người dùng.

Tôi đặc biệt khuyên bạn nên sử dụng kỹ thuật dựa trên sự đồng thuận này nếu bạn đang cố gắng ước tính cho một nhóm các nhà phát triển.

Lập kế hoạch chơi bài có nghĩa là bạn có thể nhận được một số ước tính khá tốt cho mỗi câu chuyện của người dùng trong một phiên duy nhất (không quá 1-2 giờ).

Làm một số đọc về điều này và thử nó!

Ngoài ra, theo nguyên tắc chung, không có tác vụ nào trong câu chuyện của người dùng vượt quá 7,5 giờ (một ngày làm việc). Nếu có, bạn cần chia nhiệm vụ thành các nhiệm vụ nhỏ hơn.

— Gallagher
nguồn

1

Lập kế hoạch ước tính poker Điểm, không có đơn vị thực tế nào. Loại nào làm cho chúng tương tự như cách ước tính thực sự là; Ass Ass hoang dã.

— Warren P

1

Ý tưởng là nếu chúng ta biết rằng một nhiệm vụ 1 điểm sẽ mất 7,5 giờ, chẳng hạn, chúng ta có thể nói rằng câu chuyện người dùng 5 điểm sẽ mất 30 giờ và câu chuyện người dùng 10 điểm sẽ mất 60 giờ. Ví dụ: chúng tôi có thể chọn một trong những nhiệm vụ nhỏ nhất và thời gian ước tính có thể được chỉ định là giá trị của một điểm câu chuyện người dùng. Sau đó, chúng ta có thể sử dụng câu chuyện người dùng này làm cơ sở để ước tính các tác vụ lớn hơn. Nếu chúng tôi nghĩ rằng một nhiệm vụ khác sẽ mất gấp đôi thời gian, chúng tôi sẽ chỉ định 2 điểm câu chuyện của người dùng (15 giờ), v.v.

— Ciaran Gallagher

1

Tôi nghĩ rằng nó phụ thuộc vào những gì bạn cần. Nếu, ví dụ, việc phân bổ tài nguyên cho dự án của bạn phụ thuộc vào nó (như trường hợp ở đây đôi khi), tốt hơn là thực hiện cẩn thận. Nói cách khác, nếu bạn đang làm một dự án không có loại cần thiết này, bạn có thể không đi sâu vào chi tiết. Dành quá nhiều thời gian cho nó không phải là một ý tưởng tốt để làm một ước tính chính xác là rất khó.

Có một khái niệm nổi tiếng được gọi là Hình nón không chắc chắn và Hình nón không chắc chắn tại Wikipedia cho biết mức độ chính xác của một ước tính thường có thể là bao nhiêu. Nó đáng để đọc về.

— Joqus
nguồn

1

Bạn nhận được gì từ ước tính của bạn?

Tùy thuộc vào những gì bạn làm việc, các ước tính cá nhân chính xác có thể có liên quan (khách hàng trả tiền cho bạn vào cuối tuần hoặc nhiệm vụ / câu chuyện đang chặn người khác và yêu cầu ETA chính xác) hoặc không (bạn có 200 câu chuyện trong hồ sơ tồn đọng, không ai sẽ chết nếu một câu chuyện thay đổi trong một tuần và bạn đang tính vào các lỗi ước tính để trung bình vượt qua một số lượng lớn trong số đó).

Chỉ cần dành thời gian tối thiểu để có được ước tính đủ tốt cho nhu cầu của bạn. Không có công thức.

Cá nhân, tôi xem xét hơn một hoặc hai phút có nghĩa là bạn có thể ước tính sai (chia nhỏ hoặc lên kế hoạch khám phá).

— ptyx
nguồn

0

Trên thực tế, bạn cần ước tính để giúp các bên liên quan khác gán mức độ ưu tiên tương đối - vì vậy các ước tính dựa trên phạm vi rộng mà ít nhất nói task1 là nỗ lực gấp 3 lần so với task2, (ngay cả khi về mặt giờ nó không chính xác lắm) rất hữu ích. Dành nhiều thời gian là cần thiết để hiểu những nhiệm vụ đó là gì (để đạt được các mục tiêu nhất định) và sau đó có ước tính sơ bộ cho chúng.

Khi bạn có mức độ ưu tiên tương đối, chỉ cần tập trung vào việc thực hiện và điều chỉnh ước tính trên đường đi. Nói cách khác, dành ít thời gian cho các ước tính trước, nhưng hãy tinh chỉnh các ước tính của bạn khi thời gian trôi qua để kế hoạch dự án đưa ra một ý tưởng tốt khi những gì sẽ được thực hiện.

— Roopesh Shenoy
nguồn

0

Ước tính tốt là một lần dựa trên thực tế không phải là giả định.

Do đó, nếu bạn đã có (các) dự án tương tự và nắm bắt thời gian ước tính trước đó của bạn, thì đó có thể là máy chủ như một cơ sở ước tính tốt để bắt đầu . Tuy nhiên, tùy thuộc vào phạm vi dự án của bạn, có thể có các tạo phẩm không xác định , tốt hơn là làm rõ với BA hoặc chủ sở hữu sản phẩm càng sớm càng tốt.

Cũng đúng khi nói rằng: Ước tính dự án phần mềm là không chính xác . Tuy nhiên, có một số thực tiễn ước tính thực tế có thể giúp:

Những người làm công việc, nên tham gia dự toán
Mang theo các chuyên gia: Đánh giá của chuyên gia là rất quan trọng để thành công dự án
Ước tính các phần lớn như một phạm vi
Sử dụng Kỹ thuật Delphi: Đây là phương pháp giúp hội tụ ý kiến của nhóm nếu có xung đột trong ước tính dự án phần mềm.
Hãy ghi nhớ chi phí
Hãy ghi nhớ các tài nguyên được phân bổ có sẵn để thực hiện công việc

— Yusubov
nguồn

Tôi chưa bao giờ quan sát một nhóm hoặc cá nhân đã ước tính thường xuyên (hơn 50% thời gian) hóa ra là chính xác trong vòng 10% thời gian thực tế sử dụng. Những người khác ở những nơi khác khẳng định những thành công mà tôi khó có thể tưởng tượng được xảy ra ở bất cứ nơi nào tôi từng làm việc.

— Warren P

"Chính xác trong vòng 10% thời gian thực tế sử dụng" - thực sự là kết quả rất kém. Cũng tính đến biên độ lỗi, tăng theo độ phức tạp và phụ thuộc bên ngoài của dự án.

— Yusubov

Đó là những gì tôi đang nói. Ước tính hút.

— Warren P

yeap, đó thực sự là một cú đánh lớn để có "chính xác trong vòng 10% thời gian thực sự bỏ ra" ...

— Yusubov