Điểm câu chuyện cho các nhiệm vụ sửa lỗi: Nó có phù hợp với Scrum không?

Tôi chỉ tự hỏi liệu chúng ta có nên gán điểm câu chuyện cho các nhiệm vụ sửa lỗi hay không. JIRA, phần mềm các vấn đề theo dõi của chúng tôi, không có lĩnh vực điểm trong câu chuyện cho Bug vấn đề kiểu (nó chỉ cho Câu chuyện s và Epic s).

Chúng ta có nên thêm loại sự cố Lỗi vào các loại sự cố có thể áp dụng của trường Story Points không? Những ưu và khuyết điểm là gì? Nó sẽ phù hợp với Scrum?

Lý tưởng nhất là phần mềm của bạn không có lỗi sau mỗi lần lặp và sửa lỗi phải là một phần của mỗi lần chạy nước rút, vì vậy công việc cần sửa lỗi nên được xem xét khi gán điểm câu chuyện (nghĩa là một nhiệm vụ có nhiều khả năng tạo ra lỗi có nhiều điểm câu chuyện được gán cho nó).

Tuy nhiên, trong thực tế, lỗi bề mặt sau triển khai mọi lúc, cho dù thử nghiệm của bạn có cứng nhắc đến đâu; Khi điều đó xảy ra, loại bỏ lỗi chỉ là một thay đổi khác, một tính năng nếu bạn muốn. Không có sự khác biệt cơ bản giữa báo cáo lỗi và yêu cầu tính năng trong ngữ cảnh này: trong cả hai trường hợp, ứng dụng cho thấy một hành vi nhất định và người dùng (hoặc một số bên liên quan khác) muốn thấy nó thay đổi.

Từ góc độ kinh doanh, các lỗi và tính năng cũng giống nhau, thực sự: hoặc bạn làm điều đó (kịch bản B) hoặc bạn không (kịch bản A); cả hai kịch bản đều có chi phí và lợi ích kèm theo, và một người kinh doanh đàng hoàng sẽ chỉ cân nhắc và đi với bất cứ điều gì mang lại cho họ nhiều lợi nhuận hơn (dài hạn hoặc ngắn hạn tùy thuộc vào chiến lược kinh doanh).

Vì vậy, có, bằng mọi cách, gán điểm câu chuyện cho lỗi. Làm thế nào khác bạn sẽ ưu tiên lỗi so với các tính năng và lỗi chống lại lỗi? Bạn cần một số biện pháp nỗ lực phát triển cho cả hai, và tốt hơn là nên so sánh.

Vấn đề lớn nhất với điều này là các lỗi thường khó ước tính hơn: 90% hoặc nhiều hơn nỗ lực thực tế nằm trong việc tìm ra nguyên nhân; một khi bạn đã tìm thấy nó, bạn có thể đưa ra một ước tính chính xác, nhưng gần như không thể đánh giá được việc tìm kiếm sẽ mất bao lâu. Tôi thậm chí đã nhìn thấy một phần lớn các lỗi trong đó phần lớn thời gian được dành để cố gắng tái tạo lỗi. Mặt khác, tùy thuộc vào bản chất của lỗi, thường có thể thu hẹp tìm kiếm với một số nghiên cứu tối thiểu trước khi đưa ra ước tính.

Ước tính các lỗi có điểm vốn đã khó khăn như đã chỉ ra trong các câu trả lời khác và đúng, giải pháp lý tưởng là các lỗi được tìm thấy trong một tính năng SAU việc chạy nước rút đã được chấp nhận nên được coi là các tính năng mới .

Tuy nhiên, khó khăn này trong việc ước tính điểm cho các lỗi là một trong nhiều lý do khiến các gói phần mềm Agile PM cho phép các tác vụ và lỗi được ước tính theo giờ, bởi vì cần có kỹ năng và kinh nghiệm để trở thành kỹ năng ước tính điểm. Nhiều dự án gặp vấn đề nghiêm trọng với việc xác định vận tốc chính xác, vì vậy nhiều dự án Agile sử dụng các điểm để xác định câu chuyện nào đưa nó vào giai đoạn nước rút, tuy nhiên họ sử dụng hàng giờ khi tính toán biểu đồ phát sinh .

Có vẻ như trực quan nhưng có thể quản lý được miễn là ước tính giờ không được sử dụng như một yếu tố để xác định cam kết nước rút. Quá mức sẽ tự nhiên dẫn đến các tính năng bị mất hoặc không đầy đủ hoặc quá giờ, do đó, theo thời gian, tất cả những người liên quan buộc phải cải thiện việc ước tính điểm, tại đó việc ước tính số giờ cho các nhiệm vụ và lỗi dần trở thành một số liệu vô nghĩa.

Bạn không nên cho điểm để giải quyết lỗi. Hãy xem xét thực tế rằng lỗi xuất phát từ một câu chuyện trong đó các nhà phát triển đã kiếm được điểm khi hoàn thành câu chuyện. Nó không nên nhận lại điểm khi thực sự không nên kiếm điểm để bắt đầu.

Sửa lỗi nên có ảnh hưởng tiêu cực đến vận tốc. Nếu không, chất lượng giảm cuối cùng sẽ được thưởng với một vận tốc không bị ảnh hưởng hoặc thậm chí tăng lên!

Có lẽ một liên kết hữu ích:

http://www.infoq.com/news/2011/01/story-point-to-bugs

Tôi sẽ khuyên bạn nên xử lý lỗi như một câu chuyện của người dùng và gán cho nó một số điểm. Tôi không nhất thiết phải viết nó theo định dạng "Là một X, tôi muốn Y sao cho Z" như thường thấy với các câu chuyện của người dùng - Tôi sẽ viết nó nhiều hơn là "Là một X, khi IY, Z xảy ra, nhưng Z 'là hành vi dự kiến ​​".

Ưu điểm của việc này là cho phép bạn ưu tiên sửa lỗi ngay bên cạnh các yêu cầu tính năng mới. Sự thật là đôi khi, một tính năng mới quan trọng hơn việc sửa lỗi. Tuy nhiên, nó cũng cho phép bạn định cỡ đúng công việc cần thiết, cho phép bạn điều chỉnh nó phù hợp với nước rút khi bạn có khả năng thực hiện.

Một điều cần lưu ý rằng có thể khó ước tính nỗ lực cần thiết để sửa lỗi. Nó có thể liên quan đến nhiều thành phần tương tác với nhau, đòi hỏi ai đó phải làm quen với các tương tác của các phần lớn của hệ thống hoặc nhiều người để khắc phục.

Ước tính các câu chuyện dựa trên khái niệm rằng, theo thời gian, một nhóm kiếm được kinh nghiệm trong việc giải quyết chúng. Với nó, độ chính xác được cải thiện và vận tốc có thể được thiết lập để đo tốc độ của các đội. Một phương pháp hoàn hảo để thiết lập các tiên lượng đáng tin cậy cho các lần chạy nước rút trong tương lai.

Lỗi là một thực tế của cuộc sống cho một công ty phát triển phần mềm. Mặc dù tôi đồng ý rằng tất cả các lỗi nên được phát hiện trong quá trình phát triển câu chuyện, chấp nhận rằng điều này không thể đạt được mọi lúc, nên là điều mà mọi đội nên lên kế hoạch. Thay vì ngoan cố nghĩ rằng quy trình nên thống trị đội, nó nên theo cách khác.

Tất nhiên, lỗi hoặc câu chuyện, từ phía doanh nghiệp không quan trọng việc nhóm đang xử lý vấn đề gì. Cả hai có thể tạo ra một lượng giá trị bằng nhau cho chủ sở hữu sản phẩm.

Trong nhóm của chúng tôi, chúng tôi đã thử nghiệm một số kỹ thuật để ước tính lỗi:

1. Ước tính lỗi hoàn toàn không biết
2. Chỉ ước tính các lỗi đã được phân tích
3. Phân bổ thời gian để sửa lỗi và không ước tính lỗi, nhưng xếp hạng chúng thay vì chỉ dựa trên giá trị doanh nghiệp

Với 1. chúng tôi đã thất bại thảm hại. Đối với hầu hết các lỗi, chúng tôi đã tìm thấy 90% thời gian dành cho phân tích lỗi. Sau đó, sửa lỗi có thể được ước tính theo cùng một câu chuyện. Bằng cách lập kế hoạch cho các lỗi vào một lần chạy nước rút, chúng tôi đã phạm sai lầm rằng phạm vi không xác định đã ảnh hưởng đến việc giải quyết câu chuyện cho đến khi gần như mọi lần chạy nước rút chúng tôi làm theo cách này đều thất bại.

Dựa trên tỷ lệ 90/10 (phân tích để sửa lỗi) tùy chọn kỹ thuật ước tính 2. có nghĩa là chúng tôi phải lập kế hoạch phân tích không phải là thứ được bao phủ cho kế hoạch chạy nước rút (chúng tôi đã học được từ phương án 1, nhưng không có giải pháp thực sự làm thế nào để tiếp tục với các lỗi được phân tích). Kết quả là phân tích lỗi đã không được thực hiện do chạy nước rút tập trung vào các mục được lên kế hoạch thay thế. Nhóm không có thời gian để tập trung vào các lỗi từ tồn đọng. Vì vậy, cuối cùng họ cũng không được thực hiện.

Bằng cách chấp nhận sự không chắc chắn, giờ đây chúng tôi đã giải quyết tùy chọn 3. Chúng tôi đã chia phần tồn đọng của sản phẩm thành một phần câu chuyện / nhiệm vụ thông thường mà nhóm có thể ước tính bằng cách sử dụng điểm câu chuyện và tồn đọng lỗi. Trong lỗi tồn đọng, chủ sở hữu sản phẩm xếp các lỗi dựa trên giá trị doanh nghiệp và phán đoán nhóm rất thô bạo. Nhóm nghiên cứu cho phép phân bổ một khối thời gian trong giai đoạn nước rút mà họ có thể dành để tập trung vào các lỗi. Chủ sở hữu sản phẩm không biết kết quả chính xác vì trước đây không thể lập kế hoạch đó. Tỷ lệ tồn đọng lỗi so với tồn đọng thông thường có thể được điều chỉnh cho mỗi lần chạy nước rút tùy thuộc vào trạng thái hiện tại của từng tồn đọng và tầm quan trọng và giá trị kinh doanh của nội dung.

Bằng cách loại bỏ sự không chắc chắn, nó đã giải phóng đội một lần nữa. Nước rút không bị xâm phạm bởi các lỗi không xác định. Bằng cách tách các lỗi thành một tồn đọng khác nhau, cả hai đều tập trung chạy nước rút thường xuyên của nhóm và khiến chúng tôi hoàn thành các lỗi có chứa giá trị kinh doanh quan trọng.

Vì vậy, nó phụ thuộc vào việc điểm câu chuyện có phù hợp với bạn hay không. Tôi sẽ cố gắng ước tính lỗi bằng cách sử dụng điểm câu chuyện trước. Nếu thất bại, hãy thử tùy chọn của tôi 3. Nó đã khiến nhóm (hơn 30 nước rút cũ) của chúng tôi tập trung vào các lỗi cũ một lần nữa chứa giá trị kinh doanh lớn. Nó cũng đã giải phóng chúng tôi khỏi việc cố gắng cung cấp một cái gì đó mà nhóm đơn giản là không thể ước tính. Nó đang nắm lấy những điều chưa biết đã đưa chúng ta đến gần hơn với thực tế và cũng khiến cho những lần chạy nước rút của chúng ta thành công trở lại trong khi mang lại một khối lớn (dựa trên tỷ lệ lỗi trong câu chuyện) của giá trị doanh nghiệp thông qua sửa lỗi. Tỷ lệ chúng tôi sử dụng gần đây là 50/50.

Tôi phải không đồng ý với câu trả lời hàng đầu về việc gán điểm câu chuyện cho các lỗi. Điểm câu chuyện nên được cho giá trị mới được cung cấp. Nếu bạn định gán điểm cho giá trị sản phẩm và các mặt hàng không có giá trị, bạn cũng có thể chỉ ước tính và theo dõi giờ.

Lỗi là chi phí chung của những gì bạn đã làm ngày hôm qua và không phải là dấu hiệu cho thấy tốc độ hoàn thành sản phẩm và chúng cũng không tạo ra bất kỳ giá trị sản phẩm mới nào (hãy nghĩ về nó). Lỗi là loại giống như gián đoạn và tất cả các bánh bò khác mà bạn cần phải xử lý hàng tuần. Toàn bộ ý tưởng của các điểm câu chuyện là nó theo dõi / ước tính khi chúng tôi sẽ phân phối sản phẩm (hoặc bộ tính năng). Điểm câu chuyện là tùy ý và đó là cách nó loại bỏ tất cả chi phí phi giá trị khỏi ước tính. Nói chung, công việc không có giá trị là không đổi theo tuần, do đó, nó được tích hợp vào vận tốc nhóm. Nhóm sẽ tăng tốc khi họ loại bỏ hoặc giảm công việc không có giá trị này.

Đặt một cách khác, tại sao thậm chí theo dõi điểm đến lỗi? Vì vậy, vào cuối ngày, bạn biết mỗi thành viên đã làm bao nhiêu "công việc"? Dừng lại! Người quản lý tồi! :) Đo lường đội, không phải người chơi. Khuyến khích nhóm tự quản lý nếu một người không giảm cân. Hiệu quả hơn nhiều. Làm các mục điểm câu chuyện không nên làm cho một cá nhân cảm thấy tốt hơn, nhưng toàn bộ nhóm sẽ cảm thấy tốt hơn khi họ thực hiện cam kết vào cuối nước rút. Trong thể thao, mục tiêu tốt cho đội bóng hay cá nhân? Nếu cá nhân chơi cho chính mình, đội sẽ thua trong thời gian dài.

Bạn biết đấy, cuối cùng bạn muốn không sử dụng điểm nào cả. Ước tính là thời gian lấy đi từ công việc thực tế. Khi một đội đạt tối đa chi, họ hoàn toàn không sử dụng điểm mà biết chính xác có bao nhiêu vật phẩm họ có thể kéo vào nước rút. Họ đã thành thạo nghệ thuật phá vỡ các đơn vị công việc mà ước tính là lãng phí quá trình.

Một số nhiệm vụ có thể ước tính, một số thì không. Đối với những thứ không thể ước tính, hãy sử dụng ngân sách.

Sửa một lỗi không phải là một nhiệm vụ dễ ước tính bởi vì nó có một số thành phần chưa biết đối với nó. Điều gì gây ra khuyết tật? Một khi nguyên nhân được hiểu, làm thế nào nó có thể được sửa chữa? Sự thay đổi này có tác động gì đến phần còn lại của hệ thống? Có bao nhiêu khuyết điểm mới mà bạn đã sửa chữa khiếm khuyết này?

Hãy nhớ rằng nguyên nhân của lỗi có thể đến từ bất kỳ điểm nào trong vòng đời phần mềm - yêu cầu hiểu sai hoặc truyền thông sai, thiết kế kém hoặc giả định sai, mã hóa kém, kiểm tra kém, kiến ​​thức mới về vấn đề dựa trên thông tin học được từ bản phát hành hiện tại ...

Tạo ngân sách có thể được thực hiện theo một vài cách khác nhau cho các tác vụ sửa lỗi. Đây là một số ý tưởng tôi đã sử dụng hiệu quả:

• Sử dụng dữ liệu lịch sử (nói từ lần lặp trước) để giúp bạn hiểu được bao nhiêu thời gian để dành cho việc sửa lỗi.
• Đặt "khối" sửa lỗi (giả sử 5 điểm hoặc 20 giờ) trong hồ sơ tồn đọng của bạn và để khách hàng chọn điều này thay cho câu chuyện.
• Yêu cầu mỗi thành viên trong nhóm của bạn dành một lượng thời gian nhất định cho mỗi lần lặp sửa lỗi.

Mục tiêu của bạn là sửa chữa càng nhiều lỗi càng tốt trong ngân sách được phân bổ. Thảo luận với các chiến lược khách hàng của bạn để ưu tiên các khiếm khuyết được báo cáo. Ví dụ, bạn sắp xếp các khiếm khuyết theo mức độ quan trọng sau đó ưu tiên? Ưu tiên nghiêm ngặt? Bạn có nên tấn công "trái cây treo thấp" trước không? Lỗi UI trước?

Ngoài ra, sửa lỗi không kiếm được giá trị. Sửa lỗi là một dạng lãng phí. Bạn đã kiếm được giá trị trên tính năng này vì vậy bạn không nên nhận "điểm thưởng" để sửa lỗi.

Có ngân sách giúp lập kế hoạch và vẫn cung cấp cho bạn một bức tranh chính xác về Vận tốc. Ngân sách một số điểm cụ thể để sửa lỗi, cung cấp cho ngân sách một lượng thời gian xấp xỉ dựa trên dữ liệu lịch sử của bạn và sau đó xóa hết số lỗi có thể trong thời gian được ngân sách!

Thay vì tập trung vào các câu chuyện và lỗi và công việc và mỗi điểm có, tôi thấy tốt hơn là tập trung vào việc cung cấp các tính năng cho khách hàng.

Khách hàng mong đợi phần mềm hoạt động và chỉ mang lại giá trị thực sự cho sự phát triển, cải tiến và các tính năng mới khi những điều này thúc đẩy doanh nghiệp tiến lên.

Sửa lỗi, quan trọng như có thể, không thúc đẩy doanh nghiệp tiến tới các lĩnh vực mới và khách hàng mới (tiếp tuyến và cuối cùng có lẽ có nhưng không phải ngay lập tức đó là những gì quản lý đang đo lường).

Vì vậy, các điểm được xem tốt nhất từ ​​quan điểm cao hơn về vận tốc và có bao nhiêu điểm mỗi tuần đã được thực hiện trong lịch sử cho các câu chuyện được ghi tương tự.

Điều này có thể dẫn đến việc quản lý bằng cách theo dõi lịch sử hồ sơ thay vì thúc đẩy nhu cầu cấp thiết cho những câu chuyện trong tuần này được hoàn thành và thường xuyên thấy rằng chúng không phải. Tuy nhiên, việc mất kiểm soát từ phía trước và tăng sự tin tưởng rằng điều này đòi hỏi sẽ có một số nhà quản lý chạy đến cánh cửa kinh hoàng.

Tôi sử dụng Trình theo dõi Pivotal (Tôi chỉ là JIRA, Trak, Trello và những người khác nữa) và Trình theo dõi Pivotal cũng không thực hiện các điểm cho các công việc hoặc lỗi. Điều đó được thực hiện vì những lý do tốt tương tự ở trên khiến điều đó cũng đúng trong JIRA như bạn đang nhìn thấy chính mình.