Các cách tốt nhất để đưa việc sửa lỗi vào quy trình Scrum? [đóng cửa]

Tôi đã nghiên cứu và đọc về Scrum trong vài ngày gần đây và đọc về Lập kế hoạch Sprint và các nhiệm vụ. Một vấn đề nảy ra trong đầu tôi là làm thế nào để đối phó với các lỗi trong Scrum. Henrik Kniberg liệt kê một số cách giải quyết vấn đề này trong cuốn sách rất hay của anh ấy là Scrum and XP from the Trenches :

1. Chủ sở hữu sản phẩm in ra các mục Jira có mức độ ưu tiên cao nhất, mang chúng đến cuộc họp lập kế hoạch chạy nước rút, và dán chúng lên tường cùng với các câu chuyện khác (do đó ngầm chỉ rõ mức độ ưu tiên của các mục này so với các câu chuyện khác).
2. Chủ sở hữu sản phẩm tạo các câu chuyện đề cập đến các mặt hàng Jira. Ví dụ: “Sửa các lỗi báo cáo quan trọng nhất của back office, Jira-124, Jira- 126 và Jira-180”.
3. Sửa lỗi được coi là nằm ngoài giai đoạn nước rút, tức là nhóm giữ hệ số tập trung đủ thấp (ví dụ 50%) để đảm bảo rằng họ có thời gian để sửa lỗi. Sau đó, đơn giản giả định rằng nhóm sẽ dành một khoảng thời gian nhất định cho mỗi sprint để sửa các lỗi Jira đã báo cáo
4. Đặt sản phẩm tồn đọng trong Jira (tức là bỏ qua Excel). Xử lý lỗi giống như bất kỳ câu chuyện nào khác.

Đây có thực sự là điều cần được quyết định trên cơ sở từng dự án hay có những giải pháp tốt hơn? Tôi có thể nghĩ ra các vấn đề với mỗi cách tiếp cận đó. Có sự kết hợp nào từ những cách tiếp cận đó hoạt động tốt nhất không? Làm thế nào để bạn xử lý điều này trong các dự án của bạn?

Đây là một câu hỏi rất hay và tôi có một số nhận xét khi nói đến các cách tiếp cận khác nhau đối với vấn đề này.

1. Xử lý bình đẳng tất cả các lỗi với các hạng mục tồn đọng nghe có vẻ là một ý tưởng hay trên lý thuyết (công việc được theo dõi ở một nơi duy nhất) nhưng lại không hoạt động tốt trong thực tế. Các lỗi thường ở cấp độ thấp và nhiều hơn, vì vậy nếu bạn tạo một câu chuyện người dùng riêng lẻ cho từng lỗi thì các câu chuyện "thực" sẽ sớm bị che khuất.
2. Thời gian rõ ràng trong mỗi sprint dành riêng cho các bản sửa lỗi sẽ tốt nếu được thực hiện theo cách mà chủ sở hữu sản phẩm có thể nhìn thấy được. Các lỗi nên được đề cập trong cuộc thảo luận hàng ngày và thảo luận về các lỗi đã sửa nên diễn ra trong quá trình đánh giá sprint. Nếu không, chủ sở hữu sản phẩm sẽ không nhận thức được những gì đang diễn ra trong dự án.
3. Đưa toàn bộ công việc tồn đọng vào công cụ theo dõi lỗi dẫn đến cùng một tập hợp các vấn đề như trong 1. Hơn nữa, hầu hết các trình theo dõi lỗi không được thiết kế với Scrum và việc sử dụng chúng cho mục đích này có thể gây khó khăn.

Giải pháp mà chúng tôi thấy hài lòng nhất là đưa một câu chuyện người dùng duy nhất có tên "Vé" hoặc "Lỗi" vào mỗi sprint. Sau đó, một câu chuyện như vậy có thể được chia thành các nhiệm vụ cấp thấp mô tả một lỗi cụ thể (nếu được biết trong quá trình lập kế hoạch) hoặc các nhiệm vụ meta dành một số giờ nhất định để sửa lỗi nói chung. Bằng cách này, chủ sở hữu sản phẩm có khả năng hiển thị quy trình và biểu đồ kết thúc phản ánh tiến trình.

Chỉ cần nhớ đóng không thương tiếc tất cả các "lỗi" thực sự là các tính năng mới và tạo các mục tồn đọng mới cho chúng. Ngoài ra, hãy nhớ sửa tất cả các lỗi được báo cáo so với sprint hiện tại trước khi sprint kết thúc để coi sprint là đã xong.

Trên thực tế, tôi nghĩ rằng tốt nhất là câu trả lời của jpeacock từ câu hỏi này Bạn có tính số giờ dành cho việc sửa lỗi đối với scrum không?

Hãy để tôi trích dẫn nó:

• Nếu lỗi dễ sửa / nhanh chóng (một lớp lót, v.v.), thì chỉ cần sửa nó.
• Nếu lỗi không phải là nhỏ và không phải là một trình chặn, thì hãy thêm nó vào công việc tồn đọng.
• Nếu lỗi là một trình chặn thì hãy thêm một nhiệm vụ (cho sprint hiện tại) để nắm bắt công việc cần thiết để sửa nó và bắt đầu làm việc với nó. Điều này yêu cầu phải chuyển thứ gì đó khác (từ sprint hiện tại) sang backlog để tính cho số giờ mới vì tổng số giờ có sẵn của bạn không thay đổi.

Bước đầu tiên là xác định lỗi là gì. Tôi dạy rằng lỗi chỉ là lỗi nếu đó là chức năng không hoạt động trong quá trình sản xuất như dự kiến ​​/ thiết kế. Chúng trở thành các PBI loại lỗi được ưu tiên chống lại sự phát triển mới. Thiếu chức năng trong sản xuất là một Tính năng và trở thành một mặt hàng tồn đọng của sản phẩm bình thường. Bất kỳ mã lỗi nào được tìm thấy trong một sprint được coi là công việc chưa hoàn thành và vì bạn không chuyển sang câu chuyện tiếp theo cho đến khi câu chuyện hiện tại được hoàn thành; không cần thiết phải theo dõi những khiếm khuyết này trong sprint vì nhóm luôn làm việc với mã vi phạm. Post-it có thể rất tiện dụng ở đây để nhắc nhở nhanh giữa các đồng đội. Việc sửa mã bị hỏng luôn được ưu tiên hơn việc viết mã mới.

Hàng tồn kho là lãng phí. Theo dõi lỗi là hàng tồn kho. Theo dõi lỗi là lãng phí.

Xử lý bình đẳng tất cả các lỗi với các hạng mục tồn đọng nghe có vẻ là một ý tưởng hay trên lý thuyết (công việc được theo dõi ở một nơi duy nhất) nhưng lại không hoạt động tốt trong thực tế. Các lỗi thường ở cấp độ thấp và nhiều hơn, vì vậy nếu bạn tạo một câu chuyện người dùng riêng lẻ cho từng lỗi thì các câu chuyện "thực" sẽ sớm bị che khuất.

Nếu bạn có nhiều lỗi hơn các tính năng thì bạn cần phải làm việc với các phương pháp kỹ thuật của mình. Đây là mùi cho thấy có gì đó khác không ổn và việc theo dõi không phải là câu trả lời. Đào sâu hơn. Thực ra bọ luôn có mùi. Chúng không hay ho và nếu bạn có nhiều trong số chúng, bạn cần tìm (các) nguyên nhân gốc rễ, loại bỏ chúng và ngừng tập trung vào việc theo dõi lỗi.

Đừng theo dõi các khuyết điểm trên danh sách, hãy tìm chúng và sửa chúng - Mary Poppendieck

Thật vậy, nếu hàng tồn kho là lãng phí, thì hàng tồn kho có khuyết tật thì sao ...

Đó là lý do tại sao tôi luôn cố gắng thực hiện tâm lý Stop-the-Line với phát triển dựa trên thử nghiệm và tích hợp liên tục, để chúng tôi tìm ra và sửa chữa hầu hết các khiếm khuyết thay vì đưa chúng vào danh sách làm lại.

Và khi các lỗi đi qua, chúng tôi sẽ sửa chúng trước khi viết mã mới (dù sao thì những câu chuyện có lỗi cũng không được thực hiện). Sau đó, chúng tôi cố gắng sửa chữa quy trình của mình để làm cho nó dễ mắc lỗi hơn và phát hiện ra các khiếm khuyết ngay khi chúng xảy ra.

Không có một kích thước phù hợp với tất cả các giải pháp và mỗi dự án là khác nhau. Các lỗi cũng có thể được phân loại từ nhiệm vụ quan trọng đến khó sửa chữa.

Trừ khi quan trọng đối với việc vận hành hệ thống, tôi thích lỗi trở thành thẻ câu chuyện. Điều đó khiến ưu tiên phát triển tính năng so với sửa lỗi thực sự rõ ràng. Trong một tình huống mà các bản sửa lỗi được coi là "nằm ngoài nước rút", việc sửa lỗi có thể chuyển sang sửa các lỗi thực sự nhỏ trong khi các tính năng kinh doanh thực sự quan trọng không được phát triển.

Chúng tôi đã vượt qua một số hoán vị trước khi đặt lỗi như một cách tiếp cận câu chuyện. Hãy thử một số điều khác nhau và phát lại chúng tại các cuộc họp cổ điển của nhóm.

Trong trường hợp của chúng tôi (phát triển greenfield, 2-3 nhà phát triển) các lỗi được tìm thấy được viết ra, đánh dấu rõ ràng là lỗi và dựa trên mức độ nghiêm trọng của chúng, chúng được chỉ định cho lần lặp tiếp theo hoặc để lại trong công việc tồn đọng. Trong trường hợp có lỗi nghiêm trọng và khẩn cấp, chúng sẽ được thêm vào quá trình lặp lại đang diễn ra.

Tôi không biết tại sao những thứ đơn giản như sửa lỗi lại phức tạp với các quy tắc .. Scrum có rất ít quy tắc, nhớ không? Mọi tính năng, Hỗ trợ, Đề xuất hay Khuyết điểm đều là vấn đề tồn đọng trong Scrum, không có sự khác biệt. Vì vậy, như hướng dẫn Scrum đã nói: các nhiệm vụ trong Sprint không bao giờ bị giới hạn bởi những gì bạn quyết định trong cuộc họp lập kế hoạch, Scrum Hằng ngày giúp mọi người thảo luận về những "trở ngại" trên đường đi của họ.

Tại sao?

Vì vậy, bạn thảo luận và suy nghĩ hợp lý với tư cách là một nhóm nếu bạn muốn khiếm khuyết, tức là vấn đề tồn đọng đi vào PBI hoặc vẫn ở trong Sprint này và cung cấp ...

Câu hỏi tốt hơn là làm cách nào để ngừng tạo lỗi trong giai đoạn phát triển? xem -> http://bit.ly/UoTa4n

Nếu bạn đang xác định và ghi lại các lỗi, bạn sẽ phải cắt bỏ và sửa chữa sau đó vào một thời điểm nào đó trong tương lai. Điều này dẫn đến "nước rút ổn định" tức là một lần chạy nước rút toàn bộ chỉ để sửa lỗi. Hoặc bạn có thể thêm chúng trở lại vào công việc tồn đọng và ưu tiên chúng như một phần của một số sprint trong tương lai. Điều đó cũng có nghĩa là bạn sẽ cung cấp và mong đợi được đăng ký và phát hành phần mềm với các lỗi đã biết trong đó (P3 & P4 hay còn gọi là mỹ phẩm và trẻ nhỏ).

Điều này không thực sự nhanh nhẹn?

Tôi đã lập bảng ý tưởng trong dự án của chúng tôi để giới thiệu một sprint sửa lỗi ngắn sau mỗi sprint thứ ba. Nước rút hiện tại của chúng tôi là ba tuần.

Ý tưởng là nó sẽ cho phép tất cả các nhà phát triển tập trung vào việc sửa lỗi cùng nhau, cho phép chỉ tập trung vào những câu chuyện mới trong các cuộc chạy nước rút thường xuyên và giữ sự tập trung thường xuyên vào việc giảm nợ công nghệ.

Các bản sửa lỗi sẽ được nhóm thành các câu chuyện có liên quan và được ưu tiên. Không nhấn mạnh vào việc định kích thước trước khi chạy nước rút vì các nhà phát triển đấu tranh để xác định kích thước các bản sửa lỗi mà không gặp khó khăn để hiểu bản chất của lỗi.

Có ai đã thử điều này hoặc có bất kỳ phản hồi nào về cách họ nghĩ rằng điều này có thể hoạt động?

Chúc mừng, Kevin.