Các kích thước Story Point cho các tác vụ lặp đi lặp lại có thay đổi sau khi bạn tự động hóa tác vụ không?

Đây là tình huống Scrum:

1. Một tác vụ nhất định (thực hiện bảng dữ liệu dân cư phía sau) là một câu chuyện thường xuyên
2. Các bảng thường có chức năng tương tự nhưng tùy chỉnh
3. Mỗi bảng mất khoảng một tuần để thực hiện (8 điểm câu chuyện)
4. Cuối cùng, nhóm đầu tư 4 tuần để tạo ra một thành phần có thể tái sử dụng
5. Bây giờ tạo một bảng mới là gần như ngay lập tức

Câu hỏi của tôi: Có phải một câu chuyện bảng mới vẫn là số 8 vì đầu ra / độ phức tạp không thay đổi? Hoặc là 1 vì nỗ lực là tối thiểu?

Nghiên cứu của tôi: Khi tôi tham gia khóa đào tạo scrum với Jeff Sutherland, tôi đã rời đi với sự hiểu biết rằng câu chuyện vẫn là số 8 vì điểm câu chuyện đo lường đầu ra. Thủ tướng vẫn nhận được các bảng tương tự, chúng chỉ được phân phối nhanh hơn 5x. Đó là một cải tiến vận tốc chính hãng (làm cùng một công việc nhưng nhanh hơn)

Nhưng tôi muốn xác minh rằng sự hiểu biết của tôi là đúng. Có ai giúp đỡ không? Chúng tôi đang tìm kiếm định nghĩa scrum chính thức, btw. Tôi đã nghiên cứu trang web của scrum inc và trải qua "Nghệ thuật thực hiện hai lần công việc trong một nửa thời gian" và không thể tìm thấy tài liệu rằng sự hiểu biết của tôi là đúng hay sai.

Cảm ơn bạn!

Cập nhật Tôi đã thực sự tìm kiếm các liên kết đến tài liệu của các cơ quan chính thức scrum. Tôi nghĩ rằng câu hỏi này hiện đang gây hiểu lầm bởi vì rất nhiều câu trả lời dưới đây chỉ là ý kiến ​​của mọi người.

CẬP NHẬT 1/22: TRẢ LỜI INC

"Nó vẫn giữ nguyên để đại diện cho phân phối giá trị bằng nhau. Vận tốc của nhóm là thước đo chính. Cải thiện quy trình của bạn sẽ dẫn đến Vận tốc tăng: https://www.scruminc.com/velocity/ " --- Phản hồi của Scrum Inc. thông qua Twitter

TRẢ LỜI CỦA TÔI TRẢ LỜI:

Tiến sĩ Jeff Sutherland, người tạo ra Scrum trả lời câu hỏi này trực tiếp trong Hội thảo về Điểm so với Giờ của ông trên slide 6

Điểm là gì? Điểm là thước đo của đội OUTPUT. Tương quan với nhưng không nhất thiết giống như nỗ lực.

JJ Sutherland, Giám đốc điều hành của Scrum Inc. trả lời trực tiếp hơn nữa trong bài học của mình về Bắt đúng vận tốc

Chỉ vì nhóm đã trở nên tốt hơn trong việc thực hiện bất kỳ câu chuyện cụ thể nào, giá trị điểm bạn nên giữ nguyên.

CÂU TRẢ LỜI CỦA TÔI:

Nguồn bổ sung. Vì câu hỏi này còn gây tranh cãi, đây là nghiên cứu trả lời một số mối quan tâm lên tiếng trong các câu trả lời khác:

Đúng. Mục tiêu của Scrum là tăng vận tốc

Nguồn 1

Mặc dù vận tốc có xu hướng dao động theo thời gian, nhưng theo quy luật, nó sẽ có xu hướng tăng lên khoảng 10% mỗi Sprint. - JJ Sutherland

Nguồn 2

Slide 5 của Bài học về Vận tốc của Scrum Inc hiển thị biểu đồ vận tốc với sự cải thiện 12 lần theo thời gian VÀ đặt tiêu đề cho biểu đồ "Cải thiện đầu ra" với "Điểm" là trục y:

Nguồn 3

Truy cập ScrumLab.scruminc.com và xem các hội thảo trên web về Metrics. Nó cho thấy cách chúng tôi đo lường hiệu suất của công ty bằng cách cải thiện vận tốc, chỉ số hạnh phúc và doanh thu trên mỗi điểm. Tôi nghe thấy rất nhiều đội chậm phàn nàn rằng đi nhanh hơn sẽ tạo ra nhiều chuyện tào lao hơn. Điều này là do Chủ sở hữu sản phẩm không chịu trách nhiệm cho việc nhân đôi doanh thu trên mỗi điểm. Nếu bạn tăng gấp đôi vận tốc và doanh thu gấp đôi trên mỗi điểm, công ty sẽ tạo ra số tiền gấp bốn lần. Điều này sẽ làm cho tất cả mọi người hạnh phúc. Đó là lý do tại sao bạn cần ba số liệu. - Jeff Sutherland

Đúng. Story Points Đo sản lượng / sản xuất

Nguồn 1

Số liệu quản lý để phân phối dự án cần phải là một đơn vị sản xuất Jeff Sutherland trong bài viết dứt khoát của mình Tại sao Điểm câu chuyện tốt hơn giờ

Nguồn 2

Nếu Nhóm bắt đầu ước tính các câu chuyện ở các giá trị thấp hơn vì chúng đã phát sinh nhiều kinh nghiệm hơn và các câu chuyện có vẻ dễ dàng hơn, Velocity dường như sẽ không bao giờ được cải thiện. Đây là một lý do lớn tại sao ước tính trong giờ không hoạt động. - Giám đốc điều hành Scrum Inc, JJ Sutherland

KHÔNG. Tăng vận tốc không làm hỏng khả năng dự đoán

Trước hết, là một PO hoặc dự đoán điều hành là rất quan trọng, nhưng năng suất thậm chí còn quan trọng hơn. Hầu hết các PO nếu được lựa chọn giữa việc duy trì mức sản xuất hoặc cải thiện đáng kể năng suất với chi phí của một số dự đoán nhỏ sẽ chọn năng suất tăng. Điều đó đang được nói, sự đánh đổi là một lựa chọn sai lầm nếu một nhóm sử dụng mô hình scrum Thời tiết hôm qua được đề xuất cho kế hoạch chạy nước rút.

Sử dụng thông thường ... nếu một nhóm sản xuất 10 vật dụng mỗi tuần, sau đó tìm cách sản xuất 40 vật dụng mỗi tuần; vận tốc của họ đã được cải thiện gấp 4 lần. PO đang nhận được gấp 4 lần số vật dụng trong cùng một khoảng thời gian. Gọi rằng vận tốc phẳng là trái với định nghĩa của từ.

ĐÚNG. Chơi game hệ thống là có thể nếu cả đội gian lận

Cuối cùng - có thể chơi trò chơi hệ thống, nhưng có thể chơi bất kỳ hệ thống nào. Scrum giảm thiểu các câu chuyện chọn anh đào của từng nhà phát triển bằng cách lấy từ một hồ sơ tồn đọng theo thứ tự và bằng cách đo vận tốc trên cơ sở nhóm, chứ không phải trên cơ sở nhà phát triển cá nhân. Nếu bạn đo dev bằng dev vận tốc thì bạn không làm scrum. Và nó giảm thiểu chơi game hệ thống thông qua các ước tính bằng cách chải chuốt các câu chuyện như một nhóm. Để bao cát ước tính của bạn, bạn phải làm điều đó trước nhóm và nhóm phải thông đồng với bạn. Nhưng nếu bạn muốn chơi trò chơi hệ thống thì thực sự không quan trọng bạn sử dụng quy trình nào. Scrum không phụ thuộc vào một nhóm gồm 4 - 6 nhân viên có năng lực, có năng lực, quan tâm đến việc hoàn thành các mục tiêu cùng nhau; Nhưng nếu bạn có nhân viên gian lận trong công việc để chơi game hệ thống thì quy trình của bạn không phải là vấn đề.

Câu chuyện bàn cuối của bạn không còn đòi hỏi tám điểm nỗ lực.

Câu chuyện về câu chuyện là một đơn vị đo lường tương đối, được quyết định và sử dụng bởi các nhóm Scrum riêng lẻ, để cung cấp các ước tính tương đối về nỗ lực hoàn thành các yêu cầu

scrum.org

Nếu bạn tiếp tục ước tính các câu chuyện ở mặt sau ở tám điểm thì bạn sẽ hiểu sai vận tốc của mình như một phép đo nỗ lực trên mỗi lần chạy nước rút.

Nó cũng sẽ là không lịch sự khi tiếp tục chỉ định tám điểm để làm việc mà bạn biết chỉ cần một điểm nỗ lực.

Tăng vận tốc không phải là một mục tiêu. Mục tiêu là lập kế hoạch đáng tin cậy.

Điểm câu chuyện là một công cụ trong một vòng phản hồi sẽ cho bạn biết, theo thời gian, vận tốc điển hình của bạn là gì. Điều này sau đó sẽ cho bạn biết bạn thực sự có thể áp dụng bao nhiêu điểm trong một lần chạy nước rút. Vận tốc có thể trôi đi một chút theo thời gian nhưng nếu nó thay đổi quá nhanh thì vô dụng. Vận tốc tăng đột ngột sẽ chỉ cho bạn biết rằng bạn vẫn không biết mình đang làm gì. Vì vậy, bạn muốn giữ cho vận tốc của mình không đổi, điều đó cho bạn biết ước tính của bạn đã tốt và có khả năng sẽ tốt cho lần chạy nước rút tiếp theo.

Bạn biết đầu ra của bạn không phải là hằng số, bạn nhận thức được thực tế là bây giờ bạn có thể tạo các bảng nhanh hơn nhiều. Vì vậy, nó sẽ hoàn toàn đánh bại mục đích của chu trình lập kế hoạch của bạn nếu bạn khăng khăng liên kết các điểm câu chuyện với các sản phẩm.

Một lần nữa, vận tốc không liên quan đến năng suất và vận tốc tăng không phải là lý do để ăn mừng. Một điểm câu chuyện cuối cùng là một đoạn nước rút của bạn. Để làm cho nó thực hơn, một số nhóm xác định một nhiệm vụ nổi tiếng mà mọi người đều hiểu và gọi đó là nhiệm vụ điểm câu chuyện tiêu chuẩn để bất kỳ phần công việc nào cũng có thể liên quan đến nhiệm vụ tiêu chuẩn về độ phức tạp và thời gian tiêu thụ. Không cần phải nói nếu nhiệm vụ tiêu chuẩn trở nên dễ dàng hơn, mọi thứ sẽ thay đổi và mọi người sẽ phải thích nghi với ý nghĩa mới của một điểm câu chuyện, thật tệ. Cách đúng đắn và thuận tiện để đi là xác định một nhiệm vụ tiêu chuẩn mới cũng không kém phần thách thức đối với nhóm.

Điểm câu chuyện phản ánh bao nhiêu nỗ lực để thực hiện câu chuyện. Họ là một dự đoán của nỗ lực. Nếu số lượng nỗ lực đi xuống, số điểm cũng vậy.

Hãy nhớ rằng, các điểm là một công cụ để giúp bạn ước tính. Không hơn không kém. Họ không phải là phần thưởng hay số liệu đo lường đầu ra. Chúng chỉ đơn giản là một cách để ước tính có bao nhiêu công việc sẽ tham gia để hoàn thành mục tiêu của câu chuyện.

Bạn nói nhiệm vụ này ban đầu mất 8 điểm, tương đương khoảng một tuần. Bây giờ, hãy nói rằng nước rút của bạn kéo dài một tuần, vì vậy trong kế hoạch bạn sẽ kéo xuống 8 câu chuyện đáng giá. Nếu bạn giữ câu chuyện này ở mức 8 điểm thì bạn chỉ có thể lên kế hoạch hoàn thành câu chuyện này trong giai đoạn nước rút. Nếu thời gian thực tế chỉ là một giờ chứ không phải 40 giờ, bạn sẽ làm gì với 39 giờ còn lại? Bạn vừa tạo một kế hoạch rất kém cho lần chạy nước rút của mình vì những điểm câu chuyện không chính xác.

nếu câu chuyện được thể hiện chính xác hơn như một điểm, điều đó có nghĩa là bạn vẫn có thể kéo thêm 7 điểm nữa trong giai đoạn nước rút một tuần hiện tại. Điều đó dường như phản ánh chặt chẽ hơn thực tế của bạn, vì vậy thay đổi kích thước của câu chuyện có ý nghĩa bởi vì nó giúp bạn lập kế hoạch.

Bạn đề cập trong câu hỏi của bạn một mong muốn cải thiện vận tốc, nhưng đó không thực sự là những gì bạn nên làm. Ít nhất, không phải theo nghĩa đen. Năng suất của bạn sẽ tự nhiên tăng lên, nhưng vì mục đích lập kế hoạch giá trị vận tốc của bạn nên duy trì khá ổn định.

Hãy nghĩ về các hiệu ứng. Giả sử bạn có một nhóm năm người, vận tốc 100 điểm trong một lần chạy nước rút và bạn mong muốn mọi người xử lý 20 điểm một cách hợp lý. Bây giờ bạn có nhiệm vụ này đã trở nên tầm thường, nhưng vẫn được tám điểm. Một thành viên trong nhóm nắm được năm trong số các nhiệm vụ này, thực hiện chúng trong hai ngày, đặt chân lên bàn trong tám ngày còn lại, đánh bại mọi người bằng cách xử lý các nhiệm vụ trị giá 40 điểm và nhận tiền thưởng. Mọi người khác bị ông chủ nhai.

Nếu bạn hài lòng với điều đó, thì đừng thay đổi điểm cho nhiệm vụ này. Tôi sẽ không thích tình huống đó.

Mỗi tác vụ có cùng số điểm sẽ được yêu cầu để có một nhà phát triển có cùng thời gian.

Và tôi hoàn toàn không đồng ý với câu trả lời của Nathaniel ở đây. Giữ các điểm sẽ làm cho vận tốc hoàn toàn không thể đoán trước được, bởi vì một số nhiệm vụ sẽ được thực hiện nhanh hơn, nhưng các nhiệm vụ khác thì không, do đó, việc chạy nước rút với các nhiệm vụ được tăng tốc sẽ cho bạn một vận tốc rất lớn, và lần tiếp theo chúng ta lại chạy xuống.

Đó cũng không phải là cách bạn ước tính. Nếu tôi biết rằng tôi có mười nhiệm vụ khá giống nhau, tôi sẽ không cho họ những điểm giống nhau ngay từ đầu. Tôi đưa ra rất nhiều điểm cho điểm đầu tiên, có nghĩa là "thực hiện các nhiệm vụ và xây dựng các công cụ để thực hiện các nhiệm vụ tương tự rất nhanh", sau đó ít điểm hơn cho các nhiệm vụ lặp đi lặp lại.

Đó là một tình huống khác khi một nhà phát triển cơ sở bắt đầu hoặc một nhà phát triển tham gia từ một nhóm khác và tăng vận tốc của họ vào lúc khác vì họ học (cách thực hiện công việc của họ ngay từ đầu hoặc tất cả các bit họ cần biết về cụ thể dự án).