Ước tính thời gian cho công việc

Question

Chúng tôi vừa mới bắt đầu làm việc tại công ty của tôi. Chúng tôi đang dành một chút thời gian ước tính nỗ lực bằng cách sử dụng kế hoạch poker và sau đó khi các nhiệm vụ chi tiết được làm việc ra một ước tính thời gian được đưa vào mỗi nhiệm vụ.

Vấn đề chúng tôi có là ước tính thời gian liên tục sai (thường là trên ước tính). Mặc dù tất cả chúng ta đều có thể đồng ý về một nỗ lực, khiến một nhóm đồng ý về thời gian cho một nhiệm vụ khó khăn hơn nhiều - những gì phải mất 1 người một giờ có thể mất một người khác 3 giờ. Chúng tôi sẽ đi đâu đó ở giữa.

Ai nên đến với ước tính thời gian cho một công việc và khi nào điều này xảy ra?

Đây có phải là điều chúng tôi cần thực hành nhiều hơn hoặc chúng tôi đang làm sai?

Answer 1

Những người thực sự thực hiện công việc ước tính chi phí liên quan. Nếu bạn đang sử dụng thời gian thô làm chỉ số để ước tính, thì các phương pháp Agile cau mày trên đó. Nhóm của bạn nên sử dụng khái niệm trừu tượng để ước tính chi phí, chẳng hạn như 'điểm'. Bạn có thể bắt đầu với đường cơ sở thô 1 giờ mỗi điểm với tối thiểu 1 điểm. Sau đó, các nhà phát triển có thể đưa ra ước tính thô về việc phải mất bao lâu. Tát chúng hoặc bất cứ ai khác trên cổ tay nếu họ nói chuyện trong giờ hoặc trong bất kỳ đơn vị thời gian khác.

Vấn đề là khi phát triển di chuyển dọc theo nhiều lần chạy nước rút, người quản lý dự án có thể điều chỉnh ước tính thời gian 'điểm' của nhóm để phù hợp với thực tế - Điều này thậm chí có thể được thực hiện cho từng nhà phát triển riêng lẻ. Những người tham gia sẽ trở nên tốt hơn và tốt hơn khi ước tính khi tiến độ dự án. Vì vậy, vì Sprints là một quá trình lặp lại, ước tính thời gian được cải thiện với nhiều lần lặp lại hơn.

Điều này đặt ra một câu hỏi khác: Tại sao bạn lo lắng về thời gian? Thời gian cơ bản là chi phí trong mô hình Thác. Trong Agile, mục tiêu là phát triển phần mềm thành VALUE không phải chi phí. Các điểm lý do được sử dụng là nó là một cơ sở trừu tượng so sánh rằng chủ doanh nghiệp, người quản lý dự án và người sáng tạo (nhà phát triển) đều có thể xem bằng ánh sáng trừu tượng. Các chủ doanh nghiệp có thể xem xét các điểm có sẵn trong một lần chạy nước rút đã cho - và biết các điểm có sẵn - họ có thể chọn chức năng quan trọng nhất. Nó luôn luôn là một chút của một quyết định khó khăn, nhưng một lần nữa, mục tiêu là để phát triển hướng tới giá trị và đi từ thời gian boxing hoặc tính năng nhồi.

Answer 2

"Ai nên đến với ước tính thời gian cho một công việc và khi nào điều này xảy ra?" Phụ thuộc vào cách bạn điều hành nhóm của mình. Bạn có để cho các thành viên trong nhóm thực sự tự quản lý, do đó, nhiệm vụ được giao khi một người lấy nó trong khi chạy nước rút? Bạn có thể phải tiếp tục sử dụng thời gian để hoàn thành dựa trên khả năng của một nhà phát triển trung bình trong nhóm. Bạn có một trưởng nhóm chỉ định nhiệm vụ cho mọi người khi chúng được tạo ra trong cuộc họp Lập kế hoạch Sprint không? Hãy để người được chỉ định ước tính thời gian để hoàn thành nhiệm vụ.

Tôi đồng ý xóa thời gian khỏi ước tính nỗ lực hơi khó hiểu. Câu hỏi lớn đặt ra là: bạn đang đánh giá quá cao thời gian nhiệm vụ là gì? Đội có ngồi khoảng 4-5 ngày sau khi chạy nước rút không có gì để làm không? Nếu vậy, hãy chuyển đến Chủ sở hữu sản phẩm và cho cô ấy biết nhóm muốn thêm một hoặc hai mục nhỏ vào Sprint. Bạn thường không thêm công cụ vào chạy nước rút liên tục, nhưng Scrum là một khuôn khổ để quản lý công việc, và miễn là nhóm ký tắt việc thêm các mục mới, không cần phải để Scrum làm việc cho nhóm của bạn ... .không ép buộc nhóm của bạn làm việc cho Scrum.

Ngoài ra, các câu hỏi của bạn dường như chỉ ra rằng nhóm của bạn có vận tốc lớn hơn so với những gì đang được lên kế hoạch. Nếu chạy nước rút trong 2 tuần của bạn (10 ngày làm việc) có vận tốc là 10, nhưng nhóm của bạn sẽ hoàn thành mọi thứ trước ngày thứ 7, hãy tăng điểm câu chuyện của bạn trên lần chạy nước rút tiếp theo tới 11 hoặc 12.