Cách quản lý tồn đọng của trình theo dõi sự cố


10

Chúng tôi đã sử dụng Trac một cách cẩn thận trong vài năm nay và danh sách "vé hoạt động" của chúng tôi đã tăng lên gần 200 mặt hàng. Chúng bao gồm các lỗi có mức độ ưu tiên quá thấp và quá phức tạp để khắc phục, các yêu cầu tính năng đã bị trì hoãn, các vấn đề chưa bao giờ thực sự tạo ra khiếu nại nhưng mọi người đều đồng ý phải sửa một ngày nào đó, tái cấu trúc mã theo kế hoạch và các lỗi không thiết kế khác mà chúng tôi không ' t muốn mất dấu, v.v.

Kết quả là, với gần 200 vấn đề này, danh sách này gần như áp đảo; nó không còn hữu ích như một nguồn của những gì cần phải làm ngay bây giờ.

Cách tốt nhất để theo dõi các vấn đề của loại này là gì?

Một phần của vấn đề là một số trong những vấn đề này có mức độ ưu tiên thấp đến mức chúng có thể không bao giờ được thực hiện. Tôi ghét mất dấu những món đồ này (tương tự như không muốn ném thứ gì đó ra khỏi nhà trong trường hợp tôi có thể cần nó vào một ngày nào đó); Tôi có cần phải vứt chúng đi bất kể (bằng cách đánh dấu chúng là wontfix) và cho rằng tôi có thể tìm thấy chúng trong tương lai nếu tôi cần chúng không?


200 cho cả một đội làm tôi cười. :-) Một mình tôi có 120 vấn đề mở, hầu hết trong số đó tôi sẽ không bao giờ tìm cách khắc phục! - Vì vậy, để tóm tắt: câu hỏi tuyệt vời! Tôi chỉ định hỏi như vậy.
Martin Ba

Câu trả lời:


6

Đầu tiên, yêu cầu mỗi nhà phát triển xem xét từng mục và xem xét / kiểm tra từng mục để xem liệu đó có còn là vấn đề không (có thể hoạt động tốt nhất để phân chia chúng cho mọi người). Sau đó, đóng bất kỳ vấn đề nào không còn là vấn đề hoặc đã được quan tâm với các nỗ lực phát triển khác.

Bây giờ hãy chắc chắn rằng mỗi cái được đánh dấu là một nỗ lực phát triển lớn, vừa hoặc nhỏ. Đây là một ước tính rất sơ bộ chỉ được sử dụng để dễ dàng phân loại các dự án hơn và để giúp kéo mọi thứ lại với nhau. Nếu mọi thứ đã được ước tính thì nó sẽ có ích, nhưng đừng gác máy vào giờ. Chỉ cần đi với một kiểm tra ruột nhanh chóng. Nó thường hoạt động để đưa các nhà phát triển vào một căn phòng và chỉ cần đi qua từng mục và sử dụng nỗ lực mà phần lớn mọi người cảm thấy là phù hợp.

Xem xét từng nhóm trong ba nhóm nỗ lực và đánh dấu từng mục trong nhóm với mức độ ưu tiên là Quan trọng, Giá trị doanh nghiệp cao, Giá trị kỹ thuật cao, Giá trị trung bình, Giá trị thấp và Sẽ không bao giờ sửa chữa.

Đến thời điểm này, bạn thực sự biết danh sách từ trong ra ngoài và thực sự hiểu công việc liên quan đến tồn đọng của bạn và bạn có thể bắt đầu thực sự đưa ra quyết định nên làm gì với các mục. Lấy tất cả các mục được đánh dấu là sẽ không bao giờ sửa chữa và lưu trữ chúng ra khỏi hồ sơ tồn đọng của bạn.

Bây giờ khi bạn lên lịch các mục để đi vào bản phát hành tiếp theo của mình, bạn có thể sử dụng các mục quan trọng và có tầm quan trọng cao làm cốt lõi cho bản phát hành của mình. Xem lại danh sách các mục ưu tiên trung bình và thấp và thêm vào bất kỳ mục nào có thể được xử lý cùng lúc với các mục khác trong danh sách của bạn vì các nhà phát triển sẽ làm việc trong phần đó của hệ thống.

Danh sách các mục được đánh dấu với mức độ ưu tiên trung bình hoặc thấp có thể được sử dụng làm danh sách những thứ để mọi người làm việc khi họ có một chút thời gian rảnh rỗi hoặc đào tạo cho nhân viên mới. Tôi luôn thấy rằng thật tuyệt khi có một người trong nhóm trong mỗi lần lặp lại làm việc với những vật phẩm này và giúp đỡ những người còn lại trong nhóm khi cần thiết. Bằng cách này, bạn vẫn đang hoàn thành công việc trên vòng lặp hiện tại nhưng có ai đó linh hoạt và có thể giúp dập tắt đám cháy khi cần nhưng đang xử lý các vấn đề thường không được chú ý.

Một điều mà chúng tôi thấy rất hay là, giữa mỗi lần lặp, chúng tôi có một khoảng thời gian 2 tuần ngắn trong đó toàn bộ nhóm sẽ chỉ làm việc trên các mục được đánh dấu bằng một nỗ lực phát triển nhỏ. Chúng tôi sẽ tập trung đóng một số lượng lớn vé trong một thời gian ngắn.


3

Trac có cài đặt ưu tiên không? Một cái gì đó giống như 1 cho các điểm dừng chương trình lớn và 5 hoặc hơn cho những điều tốt đẹp sẽ được thực hiện đôi khi?

Nếu bạn có thể sắp xếp theo mức độ ưu tiên, bạn có thể bỏ qua các công cụ ưu tiên thấp hơn bây giờ.


1
Bất cứ điều gì ở mức độ "tốt đẹp để làm đôi khi" sẽ không bao giờ được thực hiện. Yank nó ra.
Aaron McIver

1
@Aaron: Tôi muốn giữ nó xung quanh trong trường hợp chúng tôi muốn tăng mức độ ưu tiên đôi khi. Rõ ràng, nó sẽ không bao giờ được thực hiện ở mức ưu tiên đó, trừ khi các nhà phát triển có quá nhiều thời gian trong tay (và đã tạo một ứng dụng khách gopher cho phần mềm và làm cho nó tuân thủ haiku).
David Thornley

Trac có một cài đặt ưu tiên, mặc dù chúng tôi đã tích lũy đủ số lượng tồn đọng mà tôi vừa quyết định, chúng tôi vẫn cần một cách tiếp cận "kéo dài ra".
Josh Kelley

3

đọc: http://en.wikipedia.org/wiki/5S_%28methodology%29

Đặt chúng trên gác mái, đợi một năm, sau đó chuyển nhà. Đó là những gì tôi làm.

Nghiêm túc nếu bạn không sửa nó thì hãy quên nó đi. Xem lập trình cực đoan.

Nhưng đối với các mặt hàng về mã. Bạn có thể đặt chúng trong một hệ thống đánh giá mã, như những quan sát nhỏ. Hệ thống này có thể được thiết lập để gắn cờ các vấn đề khi phần đó của hệ thống được chỉnh sửa. Tôi thấy điều này không hoạt động như đồng nghiệp, nghĩ rằng đây là những gì được mong đợi và không giải quyết các quan sát đánh giá.

Cách duy nhất để làm điều đó là ưu tiên tàn nhẫn. Làm ngay bây giờ hoặc không làm phiền.


bạn có thể giải thích về cách 5s liên quan đến theo dõi lỗi sw không, bài viết trên wikipedia dường như tập trung vào sản xuất
jk.

@jk mọi thứ đều được kết nối. Chúng ta có thể học hỏi từ mọi thứ. Sản xuất tinh gọn và phát triển phần mềm Agile gần như giống nhau. Với một ngoại lệ chính. Trong sản xuất không thể lặp lại là một khiếm khuyết, trong thiết kế lặp lại là một khiếm khuyết (ngừng viết cùng một mã nhiều lần). Mặc dù có những phần của quy trình nên được lặp lại (quy trình).
ctrl-alt-delor

2

Đây thực sự không phải là một câu hỏi kiểm soát phiên bản nhiều như một câu hỏi về quy trình làm việc và ưu tiên kinh doanh. Theo dõi những điều được biết là sai là một ý tưởng tốt ngay cả khi chúng không có khả năng "từng" được sửa chữa có một vài lợi ích. Đối với một điều, nó có nghĩa là QA (nếu bạn có một nhóm QA riêng) biết không đăng nhập một lỗi mới cho nó. Một lợi ích khác là nếu một vấn đề mới xuất hiện, nhưng nguyên nhân cốt lõi của nó là do một trong những vấn đề "chúng tôi biết về vấn đề này nhưng đó là mức độ ưu tiên thấp", bất kỳ phân tích nào về bản sửa lỗi đều được theo dõi - có thể làm cho bản mới hơn, cao hơn- phiên bản ưu tiên của lỗi dễ dàng hơn nhiều để sửa chữa.

Một khía cạnh khác của điều này là có thể có một số thời gian để giải quyết một số công việc này, ngay bây giờ hoặc trong tương lai. Có thể một ngày nào đó bạn sẽ nhận được một thực tập sinh, và có thể chỉ định một vài trong số những người đơn giản hơn cho họ như một lời giới thiệu để có được bàn chân ướt trong codebase.

Nếu các nhà phát triển cảm thấy rằng những vấn đề này sẽ tốt để khắc phục - ví dụ: nếu họ đại diện cho nợ kỹ thuật và nó sẽ làm cho cơ sở mã hóa dễ dàng hơn để xử lý chúng, nhưng chúng không có giá trị kinh doanh - có thể đáng để thảo luận rằng với các bên liên quan kinh doanh và xem liệu có thể đạt được thỏa thuận khi các mặt hàng tồn đọng đó thỉnh thoảng được nhận hay không. Tôi đã thấy các nhóm scrum làm những việc như chặn 3-5 điểm vận tốc trên mỗi lần chạy nước rút cho các mục "tồn đọng kỹ thuật" - điều này có thể đòi hỏi một số yếu tố chính trị tùy thuộc vào mối quan hệ của nhóm phát triển với các bên liên quan kinh doanh, nhưng tôi đã thấy nó hoạt động rất tốt


1

Điều này thực sự phụ thuộc vào một vài điều.

  1. Nhóm lớn bao nhiêu: Nếu nhóm đủ lớn, bạn có thể chỉ định vé theo cách cho phép các mục ưu tiên thấp hơn được hoàn thành.
  2. Tần suất bạn thực hiện phát hành: Nếu chu kỳ phát hành đủ dài, bạn có thể thoát khỏi việc thêm nhiều thứ hoặc giữ lại bản phát hành cho đến khi bạn giải quyết được tất cả các vé.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.