Làm thế nào để báo cáo lỗi yếu tố trong một chạy nước rút?

Tôi đã đọc Scrum gần đây. Theo hiểu biết của tôi, một cuộc họp được tổ chức trước khi nước rút bắt đầu, để quyết định những gì được chuyển từ tồn đọng sản phẩm sang tồn đọng nước rút sắp tới. Khi một tính năng được hoàn thành trong lần chạy nước rút hiện tại, nó sẽ đi vào nhóm "Sẵn sàng để QA" và tại thời điểm này tôi đang bị lẫn lộn. Các báo cáo lỗi có quay trở lại tồn đọng sản phẩm? Tôi cho rằng họ không thể quay lại tồn đọng nước rút vì chúng tôi đã quyết định công việc nào sẽ được thực hiện cho chu trình này? Điều gì xảy ra khi QA tìm thấy một lỗi? Nó đi đâu?

Theo cách tôi thấy, có hai giải pháp chính cho vấn đề này:

1. Đừng phân bổ 100% thời gian của bạn cho lần chạy nước rút hiện tại. Cho phép 10-15% thời gian của bạn để sửa lỗi và các hoạt động hỗ trợ khác sẽ xuất hiện trong giai đoạn nước rút. Sau đó, nếu một lỗi chặn xuất hiện, bạn có thời gian để sửa nó trong lần chạy nước rút hiện tại.

   Nếu một lỗi không chặn xuất hiện, bạn có thể sửa nó ở cuối giai đoạn nước rút hiện tại nếu bạn còn thời gian hoặc nó đi vào "nồi" cho lần chạy nước rút tiếp theo.

2. Thường xuyên có một "sửa lỗi" chạy nước rút. Có lẽ ngay trước khi phát hành chính tiếp theo. Bạn có thể sử dụng điều này để "dọn dẹp" càng nhiều lỗi càng tốt / muốn sửa cho lần phát hành tiếp theo.

Cả hai giải pháp này có lẽ đều đúng với Scrum "thuần túy", nhưng chúng hoạt động trong thế giới thực.

Trong giai đoạn nước rút "thông thường", bạn vẫn có thể bao gồm các tác vụ để sửa các lỗi cụ thể, xử lý chúng như bạn sẽ làm một phần của chức năng mới.

Trong một thế giới scrum lý tưởng, không có nhóm "Sẵn sàng cho QA" (ít nhất là không thể nhìn thấy bên ngoài nhóm), vì một tính năng không được hoàn thành cho đến khi các hoạt động QA kết thúc và các lỗi đã được sửa. Điều này có nghĩa là cần có những người trong nhóm có thể tham gia các hoạt động QA.

Trong thế giới thực, bạn có thể có một nhóm QA / thử nghiệm riêng biệt hoạt động song song với nhóm scrum (phát triển). Trong trường hợp đó, cách tiếp cận sau có thể hoạt động tốt:

1. Ngay trước khi một tính năng được đưa vào nhóm "Sẵn sàng cho QA", nhà phát triển (chính) của tính năng đó và đại diện QA, người sẽ (có thể) sẽ ngồi lại cùng nhau và xem qua tính năng này. Mọi vấn đề được tìm thấy tại thời điểm đó đều được giải quyết trước khi tính năng được đưa vào nhóm "Sẵn sàng cho QA". Lưu ý rằng đây không phải là một phần đầu của bản chạy nước rút. Nó có nghĩa là để có được trái cây treo thấp trong các vấn đề giải quyết càng sớm càng tốt.

2. Bất kỳ vấn đề nào được tìm thấy sau khi bàn giao cho QA nên được đặt trong hồ sơ tồn đọng của sản phẩm dưới dạng câu chuyện, sẽ được tính đến trong cuộc họp lập kế hoạch tiếp theo.

3. Đối với các lỗi show-stopper, hãy dành một lượng thời gian cố định cho mỗi lần chạy nước rút. Nếu, gần cuối nước rút, có thời gian còn lại trong bộ đệm này, nó có thể chứa đầy các vấn đề ưu tiên thấp hơn.

Dựa trên cách bạn mô tả quy trình công việc của bạn từ một câu chuyện, với một sản phẩm tồn đọng, tồn đọng nước rút và các nhóm khác (Tôi cho rằng chúng trông giống như "đang tiến hành / đang phát triển", "sẵn sàng cho QA", "đã hoàn thành "), có vẻ như bạn đang thêm một số yếu tố của Kanban vào Scrum - một sự kết hợp không phổ biến đôi khi được gọi là Scrumban . Khái niệm Kanban bổ sung các giới hạn về kích thước của mỗi nhóm để ngăn các nhà phát triển của bạn có quá nhiều câu chuyện đang diễn ra hoặc những người thử nghiệm của bạn không kiểm tra quá nhiều. Nó tương tự như vận tốc để di chuyển các mặt hàng từ sản phẩm của bạn tồn đọng vào tồn đọng nước rút của bạn, nhưng trong một lần chạy nước rút.

Tôi sẽ tiếp cận vấn đề bằng cách để các tác vụ của bạn là các câu chuyện của người dùng, với các câu chuyện người dùng của bạn chuyển từ tồn đọng sản phẩm sang tồn đọng chạy nước rút sang nhóm tiến trình để sẵn sàng cho thùng QA đến thùng hoàn thành. Sau khi nhà phát triển hoàn thành câu chuyện (dựa trên định nghĩa của bạn về kết thúc), anh ta sẽ chuyển nó vào thùng "sẵn sàng cho QA" nơi người tiếp theo sẽ kéo nó ra và làm việc với nó. Nếu có bất kỳ vấn đề nào với nó, một lỗi sẽ được đưa vào hệ thống theo dõi của bạn và câu chuyện người dùng sẽ được chuyển vào thùng hoàn thành kể từ khi nó được triển khai và thử nghiệm. Nếu không có vấn đề gì với nó, nó sẽ di chuyển ngay vào thùng đã hoàn thành.

Khi lỗi xuất phát từ trong lần chạy nước rút của bạn, không có vấn đề gì với việc đưa nó trở lại vào hồ sơ tồn đọng nước rút (hoặc có lẽ là một loại xô "đang tiến hành"). Một câu chuyện với những khiếm khuyết đã biết thường được coi là chưa hoàn thành. Nếu nó xác định rằng không có đủ thời gian để kết thúc câu chuyện hoặc các khiếm khuyết được quy cho là không hiểu câu chuyện, thì một lựa chọn có thể là bỏ qua nó hoàn toàn cho đến khi bạn có thể hiểu rõ hơn về nhu cầu - trong trường hợp này, tôi khuyên bạn không nên bao gồm cả việc thực hiện bị lỗi trong sản phẩm phát hành của bạn.

Nếu, do khiếm khuyết của bạn, câu chuyện không kết thúc trong lần chạy nước rút của bạn, điều này sẽ xuất hiện trong các tính toán vận tốc của bạn cho những lần chạy nước rút trong tương lai. Những câu chuyện chưa hoàn thành (những câu chuyện khiếm khuyết) không giúp bạn có được bất kỳ điểm câu chuyện nào, vì vậy bạn sẽ lên kế hoạch cho những lần chạy nước rút nhỏ hơn. Càng ít câu chuyện phức tạp sẽ dẫn đến nhiều thời gian hơn trong thử nghiệm và sẽ khuyến khích bạn dành nhiều nỗ lực hơn để sớm tìm ra khuyết điểm - ngăn ngừa lỗi không chỉ rẻ hơn mà còn mất ít thời gian hơn tổng thời gian để xác định rằng có vấn đề tồn tại, tìm ra vấn đề trong thiết kế hoặc thực hiện, khắc phục sự cố và kiểm tra lại để đảm bảo sự cố đã được giải quyết mà không có bất kỳ tác động tiêu cực nào khác đến hệ thống. Vì bảng thời gian là chìa khóa, khả năng ngăn ngừa lỗi dẫn đến việc chạy nước rút hiệu quả hơn trong tương lai.

Bất kể bạn làm gì, bạn nên liên quan đến Chủ sở hữu sản phẩm (người hy vọng là đại diện khách hàng / người dùng) khi quyết định cách ưu tiên các khiếm khuyết. Một số khiếm khuyết có thể được chấp nhận để đưa vào một bản phát hành nếu có cách giải quyết hoặc chúng hiếm gặp, có nghĩa là khiếm khuyết sẽ hiển thị như một câu chuyện trong một lần chạy nước rút trong tương lai. Các khiếm khuyết khác có thể là khẩn cấp và "trình chiếu" - chúng phải được xử lý ngay lập tức và không thể sử dụng sản phẩm nếu chúng tồn tại.

Nếu thời gian dành cho khuyết tật khá nhất quán từ mùa xuân này sang mùa xuân khác, thì bạn không thực sự cần phải quản lý nó - vận tốc nhóm của bạn sẽ phản ánh điều đó.

Mặt khác, nếu sửa lỗi có thể được lên kế hoạch (tức là bạn có thể hoãn sửa lỗi trong thời gian chạy nước rút), thì hãy làm như vậy.

Mặt khác, Scrum không có câu trả lời hay - lỗi sẽ là thay đổi nội dung chạy nước rút không có kế hoạch ở giữa nước rút, điều đó có nghĩa là bạn sẽ cần phải đàm phán lại các cam kết của mình.

Một chạy nước rút nên được khép kín. Điều đó có nghĩa là tất cả các hoạt động, bao gồm QA, sửa lỗi và tài liệu, phải được hoàn thành trước khi kết thúc cuộc chạy nước rút. Các hoạt động tiền triển khai cũng nên diễn ra trước khi nước rút kết thúc.

Vấn đề với việc không hoàn thành là bạn bị phân tâm trong lần chạy nước rút tiếp theo.

Nếu, trong lần chạy nước rút B, bạn phải chuyển sự chú ý của mình trở lại mã từ lần chạy nước rút A để bạn có thể sửa lỗi, thì khả năng bạn tập trung vào các nhiệm vụ trong lần chạy nước rút B sẽ xuất hiện ngoài cửa sổ. Vận tốc về phía trước của bạn cũng vậy.

Ở công việc cuối cùng của tôi, chạy nước rút đã được lên lịch dựa trên khái niệm "giờ lý tưởng"; của một nhà phát triển 8 giờ, 5 giờ là các tính năng mới của TDDing chưa từng tồn tại trước đây. Ba người kia đang làm mọi thứ khác; e-mail, cuộc họp, biên dịch / cam kết / cập nhật mã, tái cấu trúc công việc và vâng, sửa lỗi.

Chúng tôi đã xem xét một công việc đã được thực hiện nhưng có lỗi vẫn được tính vào vận tốc của đội; tuy nhiên, lỗi là nợ kỹ thuật phải trả khi nó tích lũy, và do đó rõ ràng là phải tránh. Chúng tôi không bao giờ có một vấn đề thực sự với những người làm công việc cẩu thả; không ai muốn phải quay lại.

Thỉnh thoảng, chúng tôi cũng có những lần chạy nước rút sửa lỗi. Chúng tôi đã may mắn có được một khách hàng không thể đưa ra các yêu cầu với tốc độ mà chúng tôi có thể tiêu thụ chúng, vì vậy để tồn đọng một chút, chúng tôi thường lên kế hoạch hai tuần để đối tượng "giết nhiều khuyết điểm và trả hết nợ kỹ thuật hết mức có thể ". Về mặt kỹ thuật, vận tốc cho một lần chạy nước rút như vậy bằng không, nhưng đây là công việc cần phải được thực hiện và làm cho khách hàng hài lòng, vì vậy nó đáng giá.