Làm thế nào để tính toán một lỗi sửa lỗi?

Chúng tôi đã triển khai Scrum khá thành công trong 5 tháng qua. Mặc dù vậy, chúng tôi cách 3 tuần so với SẢN PHẨM mà không bao giờ thực hiện bất kỳ thử nghiệm tích hợp đầu cuối nào. NGOÀI RA! Tôi cần giúp đỡ. Không giải quyết được nguyên nhân của việc này (tại thời điểm NÀY), chúng ta cần lập kế hoạch lặp lại hiện tại, bao gồm các cải tiến nhỏ và NHIỀU vẫn chưa biết sửa lỗi. Làm thế nào để bạn tính đến kịch bản này? Làm thế nào để bạn lập kế hoạch lặp đi lặp lại của bạn để sửa lỗi chưa được tìm thấy?

Scrum hay không, bugfixing về cơ bản là không thể dự đoán. Điều tốt nhất tôi tin bạn có thể làm là:

• Bắt đầu thử nghiệm ngay lập tức, không có ước tính ban đầu khi nào nó sẽ được thực hiện.
• Khi bạn phát hiện ra từng lỗi, hãy phân tích ban đầu đến điểm bạn có thể ước tính.
• Ước tính lỗi và quyết định xem nó có phải được sửa hay không và có phải sửa nó cho các thánh tích ban đầu hay không.
• Nếu nó phải được sửa, thêm nó vào vòng lặp.
• Vẽ biểu đồ ghi đĩa. Tại một số điểm, nó sẽ bắt đầu giảm, có nghĩa là bạn không còn tìm thấy lỗi nhanh hơn bạn quản lý để sửa chúng. Tại thời điểm đó, bạn sẽ có thể đưa ra ước tính sơ bộ (và dần dần chính xác hơn) khi phát hành có thể được thực hiện.

Hơn bạn nên đảm bảo lần sau bạn bắt đầu kiểm tra sớm và sửa lỗi khi bạn đi. Tất cả các phương pháp hợp lý, nhanh nhẹn hay không, kêu gọi sửa các lỗi đã biết trước khi tiến hành với các tính năng mới. Ngoài ra, bạn nên tính toán bao nhiêu thời gian đã dành cho việc sửa lỗi từng tính năng, để bạn có thể cải thiện ước tính của mình để triển khai tính năng sang trạng thái gỡ lỗi trong tương lai.

Việc lập dự toán và bugfixing đang độc đáo được bao phủ bởi Joel Spolsky trong Bằng chứng Dựa Scheduling và Hard-assed Bug Fixin' . Nó không liên quan đến Scrum, nhưng tôi nghĩ nó đủ chung để áp dụng nó.

Làm thế nào để tính toán một lỗi sửa lỗi? Làm thế nào để bạn lập kế hoạch lặp đi lặp lại của bạn để sửa lỗi chưa được tìm thấy?

Về một "lặp sửa lỗi". Lỗi tìm thấy nên được đối xử không khác với câu chuyện. Làm việc với nhóm để ước tính nỗ lực (điểm câu chuyện) để sửa từng lỗi và làm việc với chủ sở hữu sản phẩm / khách hàng để quyết định xem lỗi có nên đi vào lần lặp tiếp theo hay không.

Về "lỗi chưa được tìm thấy". Tốt hơn là, nhóm đang tìm và sửa các vấn đề mỗi lần lặp. Nếu bạn không, sau đó thảo luận về điều này trong hồi cứu tiếp theo của bạn. Nếu chất lượng sản phẩm thấp đến mức không thể phát hành, thì ngay lập tức hãy chuyển "công cụ tìm lỗi " tốt nhất của bạn sang tìm lỗi (không sửa). Nếu chất lượng đủ cao để cung cấp bản phát hành beta cho người dùng chọn - hãy thực hiện. Nếu bạn không thể, thì tối thiểu sẽ cung cấp các bản trình diễn người dùng trực tiếp thảo luận về các khu vực yếu mà bạn đề xuất cần cải thiện.

Chúng tôi không lập kế hoạch 'lặp lại sửa lỗi', nhưng chúng tôi lên kế hoạch lặp lại kiểm tra hệ thống trước mỗi lần phát hành. Kiểm tra hệ thống là tích hợp, hồi quy và kiểm tra thực tế trên tất cả các bộ phận của sản phẩm. Người kiểm tra kiểm tra sản phẩm (một hệ thống di sản khá lớn) và các nhà phát triển sửa bất kỳ lỗi nào được tìm thấy. Nếu không tìm thấy lỗi, chúng tôi sẽ bắt đầu điều tra lịch trình tính năng cho dự án tiếp theo hoặc làm việc với các cải tiến nội bộ.

Hiện tại, chúng tôi lên kế hoạch cho sáu tuần kiểm tra hệ thống sau khi đóng băng mã (đối với dự án năm tháng, bao gồm kiểm tra hệ thống), để đảm bảo mọi thứ đều hoạt động. Đây là trên tất cả các thử nghiệm được thực hiện trong các lần lặp thực hiện.

Bạn cần xác định một bộ tiêu chí "phát hành". Chúng có thể bao gồm:

• Thời gian trung bình giữa thất bại
• Số lượng lỗi được tìm thấy mỗi ngày
• Mức độ nghiêm trọng của khuyết tật được tìm thấy mỗi ngày
• Số lượng khuyết điểm nổi bật

Vân vân.

Sau đó, vào cuối mỗi lần lặp mà bạn có một số người kiểm tra (bằng tay hoặc bằng cách viết kiểm tra tự động) và những người khác sửa lỗi để xem bạn đã đáp ứng tiêu chí của mình chưa. Nếu bạn đã phát hành, nếu không thì hãy đi lặp lại.

Cần có khả năng ghi đè lên điều này cũng như thường các số liệu thô không đưa ra một bức tranh thực tế về ứng dụng. Bạn có thể có một vài khiếm khuyết thực sự nghiêm trọng, nhưng chúng chỉ biểu hiện trong những điều kiện hiếm hoi mà bạn có thể sống trong thời gian ngắn.

Một cách để làm điều đó là viết các câu chuyện cho thử nghiệm tích hợp của bạn, trong đó bạn viết các câu chuyện mới cho bất kỳ lỗi nào bạn tìm thấy, sau đó sửa các câu chuyện lỗi trong lần lặp tiếp theo.

Một cách khác để làm điều đó là chỉ tạo một câu chuyện có nội dung "Sửa lỗi tìm thấy trong kiểm tra tích hợp". Từ các bản phát hành trước, bạn sẽ có ý tưởng về việc có bao nhiêu vấn đề thường được tìm thấy và mức độ khó khắc phục của chúng, vì vậy bạn có thể chỉ định điểm câu chuyện dựa trên kiến ​​thức đó. Bạn có thể chia nó thành các thành phần nếu điều đó làm cho nó dễ quản lý hơn. Luôn luôn không thể tránh khỏi sự không chắc chắn trong việc này. Thêm một số điểm câu chuyện thêm vào tài khoản cho nó.

Có lẽ bạn đã nhận ra muộn màng rằng cách tốt nhất là kết hợp một thử nghiệm tích hợp nhỏ vào mỗi lần lặp nếu có thể. Chúc mừng bạn đã nhận ra điều đó và cải thiện quy trình của bạn chỉ một chút cho bản phát hành tiếp theo của bạn.