Liệu một ước tính thời gian bằng một lời hứa trong Scrum?

Nếu một ước tính không phải là một lời hứa thì với tư cách là chủ sở hữu sản phẩm, làm thế nào tôi có thể giao các dự án của mình mà không biết sẽ mất bao lâu?

Một nhóm Scrum có hoạt động hiệu quả hơn nếu chúng ta coi ước tính thời gian là một lời hứa?

Bao nhiêu nghiên cứu (chuẩn bị, nỗ lực để hiểu vấn đề) trong một câu chuyện là đủ để đưa ra ước tính đúng?

Điều gì về các sự cố kỹ thuật không mong muốn (các vấn đề thực sự có thể làm xáo trộn các ước tính ban đầu của bạn) xuất hiện sau khi bạn ước tính công việc của mình?

Ước tính không hứa hẹn khắc trên đá. Họ là những người đoán tốt nhất mà nhóm có thể thực hiện về nỗ lực cần thiết để hoàn thành nhiệm vụ / câu chuyện.

Trả lời câu hỏi của bạn "với tư cách là chủ sở hữu sản phẩm, làm cách nào tôi có thể phân phối các dự án của mình mà không có thời gian tham khảo?", Câu trả lời là bạn có thể và nên có thời gian làm tài liệu tham khảo (tức là bạn sẽ phát hành vào một ngày nhất định). Những gì bạn không có là phạm vi chính xác sẽ có trong giao hàng.

Lưu ý rằng những gì tôi nói là đúng với từng phương pháp bạn sử dụng để thúc đẩy sự phát triển của bạn. Sự khác biệt giữa Scrum và các phương pháp khác (như Waterfall), là trong Scrum, thực tế này được thừa nhận và được tính đến. Những gì bạn sẽ làm, với tư cách là một PO, là ưu tiên phạm vi của bạn và đảm bảo rằng nhóm, tại bất kỳ thời điểm nào là:

1. Làm việc trên tính năng quan trọng nhất (đọc: có giá trị) chưa được gửi (nhiệm vụ, yêu cầu, câu chuyện của người dùng)
2. Đã hoàn thành thành công mọi tính năng quan trọng hơn tính năng mà chúng hiện đang làm việc (điều này đề cập đến Định nghĩa Hoàn thành : Mọi câu chuyện hoàn thành đều được kiểm tra, chấp nhận, không có lỗi và hoàn thành tính năng).

Có được điều đó, giờ đây bạn có thể giao hàng hoặc giao hàng, trong lúc thả mũ, biết rằng tại bất kỳ thời điểm nào , bản dựng mới nhất là sản phẩm tốt nhất có thể được vận chuyển. Điều này có nghĩa là vào ngày cam kết phát hành ban đầu của bạn, bạn sẽ cung cấp sản phẩm tốt nhất có thể.

Tất nhiên, điều này không hứa hẹn rằng nó sẽ bao gồm mọi câu chuyện bạn yêu cầu của nhóm phát triển, nhưng bạn biết rằng những câu chuyện chưa hoàn thành còn lại tất nhiên là những câu chuyện ít quan trọng nhất, có thể dễ dàng được gửi vào một ngày sau đó.

Ngoài ra, các ước tính được thực hiện bởi nhóm sẽ ngày càng tốt hơn, cho phép bạn có một ý tưởng vững chắc sớm về phạm vi sẽ ở cuối bản phát hành. Bạn sẽ có thể giao một sản phẩm rắn tốt đúng thời gian, với một vài tính năng ít quan trọng hơn một vài tuần sau đó (tất nhiên bạn sẽ có thể ước tính khi nào sẽ có).

Đối với số lượng nghiên cứu cần thiết - có luật về lợi nhuận giảm dần khi chơi ở đây. Nếu bạn phá vỡ câu chuyện của mình đủ nhỏ, thì một nghiên cứu nhỏ sẽ cung cấp cho bạn một ước tính đủ gần. Nếu bạn hiểu sai, bạn sẽ sửa đổi trong lần chạy nước rút tiếp theo và các ước tính sẽ tốt hơn. Trong 3-4 lần chạy nước rút, trung bình, bạn nên có một ý tưởng tốt về thời hạn có thể được phân phối theo thời hạn (hoặc sẽ mất bao lâu để hoàn thành phạm vi).

Khi bạn ước tính điểm câu chuyện trong Scrum, bạn nên biết đủ để có thể thực sự bắt đầu viết tính năng này. Ước tính không được dự kiến ​​là hoàn toàn chính xác, toàn bộ quan điểm của các phương pháp phát triển Agile là họ nhận ra rằng bạn không thể dự đoán chính xác thời gian phát triển sẽ mất bao lâu.

Giai đoạn mà bạn cam kết cung cấp là khi bạn chấp nhận các câu chuyện từ sản phẩm tồn đọng thành Sprint. Bạn đang hứa sẽ cung cấp những câu chuyện trong nước rút.

Nếu bạn thực hiện cam kết này, điều này có nghĩa là bạn sẵn sàng thực hiện thêm một số giờ nếu có vẻ như bạn sẽ không đáp ứng lời hứa của mình. Trong thực tế, một số câu chuyện sẽ mất nhiều thời gian hơn bạn nghĩ và những câu chuyện khác sẽ mất ít thời gian hơn bạn nghĩ.

Khi nhóm đã thực hiện đủ ước tính, họ sẽ làm tốt hơn.

Bạn cũng có thể muốn nhìn vào ...

The Clean Coder (Sách) - có một chương trong cuốn sách này có tựa đề "Ngôn ngữ cam kết" và cũng là một chương về ước tính, thực sự rất bắt mắt.

Kanban - Kanban mang phong cách phát triển chạy hơn - cũng có sự kết hợp giữa Scrum và Kanban được gọi là "Scrumban", lấy từ cả hai ý tưởng.

Không.

Tổng của tất cả các ước tính trên mỗi nhiệm vụ hoàn thành trong một lần chạy nước rút được gọi là vận tốc . Vận tốc được định nghĩa là "số điểm hoàn thành trên mỗi lần chạy nước rút" trong đó "điểm" là đơn vị mà nhóm của bạn ước tính.

Vì vậy, vận tốc cho bạn biết nhóm của bạn có thể tạo ra bao nhiêu trong lần chạy nước rút tiếp theo, giả sử họ sử dụng cùng một phương pháp để ước tính và nhóm ổn định, v.v.

Và đó là cách bạn có thể khá chắc chắn những gì nhóm có thể cung cấp mà không phải thực hiện bất kỳ lời hứa ngẫu nhiên nào.

Ước tính nỗ lực là một công cụ để dự báo. Một dự báo không phải là một cam kết hoặc đảm bảo. Dự báo được đánh giá lại liên tục để tính đến kiến ​​thức mới và nên bao gồm các lựa chọn thay thế có thể như các biến thể lạc quan và bi quan.

Chúng tôi đang hướng về phía trước trong Agile. Các cam kết không thêm giá trị cho kế hoạch tổ chức hơn dự báo.

Rất khuyến khích Dự toán và Lập kế hoạch nhanh nhẹn của Mike Cohn

Nếu một ước tính không phải là một lời hứa thì với tư cách là chủ sở hữu sản phẩm, làm thế nào tôi có thể giao các dự án của mình mà không biết sẽ mất bao lâu?

Bạn không làm việc với một ước tính lớn, nhưng với rất nhiều ước tính nhỏ ở cấp độ câu chuyện. Rất nhiều lỗi ước tính ở cấp độ câu chuyện trung bình ra. Bạn không thể hứa cả nội dung và ngày. Tuy nhiên, bạn có thể khá tự tin rằng phần trên của phần tồn đọng sẽ có trong một bản phát hành (thay vào đó, có một ngày khá chính xác - nhưng không cố định - tại thời điểm mà toàn bộ phần tồn đọng có thể được gửi).

Một nhóm Scrum có hoạt động hiệu quả hơn nếu chúng ta coi ước tính thời gian là một lời hứa?

Không. Điều đó dẫn đến ước tính bao cát và biến biểu đồ vận tốc / phát triển thành dữ liệu vô dụng - điều này ngăn cản nhóm cải thiện.

Bao nhiêu nghiên cứu (chuẩn bị, nỗ lực để hiểu vấn đề) trong một câu chuyện là đủ để đưa ra ước tính đúng?

Phụ thuộc vào mức độ bạn quan tâm về độ chính xác. Bạn có thể dành hàng tuần để chuẩn bị mọi ước tính một cách cẩn thận, hoặc đưa ra ước tính thiện chí nhanh chóng và hy vọng sai sót trung bình. Cách đầu tiên là thiết lập cho sự thất bại, bởi vì ước tính điều gì đó bạn chưa từng làm trước đây thực sự khó khăn và công nghệ phần mềm là tất cả những thứ bạn chưa từng làm trước đây.

Cá nhân, tôi không nghĩ rằng có nhiều lợi ích khi cố gắng để có được ước tính rất chính xác. Những gì tôi cố gắng làm là đảm bảo các ước tính đủ chính xác - tức là tôi đã bỏ lỡ điều gì đó có thể khiến câu chuyện đi lệch khỏi ước tính của nó theo một độ lớn. (Xem điểm tiếp theo).

Điều gì về các sự cố kỹ thuật không mong muốn (các vấn đề thực sự có thể làm xáo trộn các ước tính ban đầu của bạn) xuất hiện sau khi bạn ước tính công việc của mình?

Lặp lại nhỏ. Đặt hàng tồn đọng. Chuyện nhỏ. Những thứ nguy hiểm là những gì bạn không biết bạn không biết. Thiếu chuyên môn về một vấn đề sẽ dẫn đến các ước tính kém, nhưng bạn có thể điều chỉnh bằng cách có được kiến ​​thức chuyên môn (chi tiết hơn) hoặc đi với các ước tính 'đủ tốt' - tất cả là về quản lý rủi ro.

Nếu một ước tính không phải là một lời hứa thì với tư cách là chủ sở hữu sản phẩm, làm thế nào tôi có thể giao các dự án của mình mà không biết sẽ mất bao lâu?

Đây là một trong những hiểu lầm lớn nhất về Scrum. Câu hỏi "Dự án của tôi sẽ mất bao lâu?" giả định rằng bạn có thể xác định, tại một số thời điểm, chính xác những gì dự án sẽ đòi hỏi để hoàn thành. Nhưng toàn bộ ý tưởng về Scrum là nó thừa nhận rằng những điều bạn học về một dự án, khi bạn làm việc trong dự án, sẽ thay đổi định nghĩa của dự án.

Cách phổ biến nhất để xác định một dự án là liệt kê các tính năng mà nó sẽ có. Thông thường, một dự án được hoàn thành khi tất cả các tính năng đã được thực hiện. Nhưng điều gì sẽ xảy ra nếu, khi bạn làm việc trong một dự án, bạn nhận ra rằng 5 trong số các tính năng được xác định khi bắt đầu sẽ không cần thiết, nhưng có 7 tính năng mà mọi người nghĩ đến trong 6 tháng đầu thực sự nên được đưa vào? Điều đó làm gì với câu hỏi sẽ mất bao lâu?

Một yếu tố khác là những điều bạn học sẽ thay đổi sự hiểu biết của bạn về cách triển khai các tính năng nhất định và khi bạn tiến gần hơn đến việc thực hiện từng tính năng mà ước tính của bạn sẽ thay đổi. Cá nhân, tôi chống lại việc đưa các ước tính số vào bất cứ điều gì không tiến gần đến chân trời đang được thực hiện - có thể sử dụng các ước tính mô tả như "nhỏ", "nhỏ", "trung bình", "lớn" và "khổng lồ" hoặc "sử thi". Sau đó, bạn không ngụ ý độ chính xác cao hơn khả năng ước tính của bạn.

Thật ra, "Sẽ mất bao lâu?", Không thể trả lời được nhiều hơn, "Sẽ thế nào khi nó hoàn thành?". Kế toán và doanh nhân truyền thống ghét điều này, đó là lý do tại sao rất khó để di chuyển khỏi Thác nước trong một số tổ chức.

Đó cũng là lý do tại sao bạn cần phải nói nhiều về vận tốc và số liệu với một hạt muối. Các dự án phần mềm có một loại Nguyên tắc không chắc chắn của Heisenberg được tích hợp trong đó và nếu bạn dành quá nhiều thời gian để tinh chỉnh các phép đo, bạn sẽ kết thúc với những điều vô cùng chính xác.

Vì vậy, không, một ước tính không phải là một lời hứa. Đó là một ước tính. "Lời hứa" là cam kết mà Nhóm thực hiện để hoàn thành một số tính năng hoặc câu chuyện nhất định trong một Sprint cụ thể.

Các ước tính cần phải đủ chính xác để cho phép Nhóm xác định có bao nhiêu tính năng (hoặc câu chuyện) mà họ có thể phù hợp với một Sprint một cách khít khao. Thậm chí quan trọng hơn độ chính xác trong các ước tính là tính nhất quán, bởi vì Nhóm sẽ tìm hiểu mức độ ước tính giá trị công việc mà họ có thể phù hợp với Sprint, ngay cả khi công việc thực tế thường gấp đôi so với ước tính. Miễn là nó liên tục tắt, họ sẽ có thể lập kế hoạch.