Có nghiên cứu về những bất lợi của việc sử dụng các hệ thống theo dõi vấn đề? [đóng cửa]

Tôi không thích các hệ thống theo dõi vấn đề vì:

• Phải mất quá nhiều thời gian để mô tả các vấn đề trong đó. Điều này không khuyến khích việc sử dụng nó.
• Bạn tạo một nơi để giữ lỗi của bạn. Và nếu có một nơi dành cho họ, mọi người thường không quan tâm quá nhiều đến việc sửa lỗi vì họ có thể đặt nó ở đó để một ngày nào đó ai đó có thể sửa nó (hoặc không).
• Với thời gian, danh sách lỗi trở nên dài đến mức không ai có thể đối phó với nó nữa, chiếm rất nhiều thời gian của chúng tôi.

Tôi thích xử lý các vấn đề bằng cách sử dụng post-it trên bảng trắng, đối thoại trực tiếp và tiêu diệt các lỗi quan trọng ngay khi chúng xuất hiện. Tôi không quan tâm quá nhiều để theo dõi lịch sử lỗi vì tôi không nghĩ rằng nó đáng giá quá cao.

Tôi ở đây một mình à? Có nghiên cứu (sách / bài viết / bất cứ điều gì) về những nhược điểm (hoặc lợi thế lớn) của việc sử dụng các hệ thống theo dõi vấn đề?

Phải mất quá nhiều thời gian để mô tả các vấn đề trong đó. Điều này không khuyến khích việc sử dụng nó.

Nếu bạn thậm chí không thể mô tả một lỗi, làm thế nào bạn có thể bắt đầu sửa nó?

Bạn tạo một nơi để giữ lỗi của bạn. Và nếu có một nơi dành cho họ, mọi người thường không quan tâm quá nhiều đến việc sửa lỗi vì họ có thể đặt nó ở đó để một ngày nào đó ai đó có thể sửa nó (hoặc không).

Đó là một vấn đề với nhóm của bạn không phải với phần mềm.

Với thời gian, danh sách lỗi trở nên dài đến mức không ai có thể đối phó với nó nữa, mất rất nhiều thời gian của chúng tôi.

Một lần nữa bạn mô tả một vấn đề với nhóm của bạn.

Điểm quan trọng của phần mềm theo dõi lỗi là không giúp bạn thúc đẩy nhóm của mình sửa lỗi, đó là lưu giữ hồ sơ để bạn có thể theo dõi nguyên nhân gây ra lỗi và ngăn chặn chúng xảy ra lần nữa. Không có phần mềm nào sẽ là sự thay thế cho việc quản lý tốt.

IMO điểm bắt đầu của bạn là thiên vị. Nếu các nhà phát triển không sửa được các lỗi, dự án sẽ thất bại, cho dù họ theo dõi lỗi bằng cách sử dụng một công cụ theo dõi lỗi thích hợp, sau đó, chạm khắc đá hay không. Đó không phải là lỗi của công cụ nếu nó không được sử dụng hoặc sử dụng sai. (Điều đó nói rằng, tất nhiên có những trình theo dõi lỗi / vấn đề xấu ngoài kia ... Tôi đã làm việc trong một dự án sử dụng một công cụ hoàn toàn không phù hợp cho công việc này, vì vậy tôi nghĩ tôi biết nó có thể tệ đến mức nào. Nhưng cũng có những cái tốt, trong đó yêu cầu buổi lễ và chi phí tối thiểu, cho phép bạn tập trung vào các thông tin liên quan.)

Tuy nhiên, nếu các nhà phát triển quan tâm và dự án lớn hơn kích thước tầm thường và có nhiều hơn một nhà phát triển trên đó, và có một số loại quản lý liên quan (tất cả đều khá phổ biến trong các dự án trong thế giới thực ), sẽ sớm xuất hiện các câu hỏi như:

1. Những lỗi mở nào cần được sửa trước? (lưu ý: trong một dự án lành mạnh, điều này phải được quyết định bởi chủ sở hữu sản phẩm và / hoặc quản lý, KHÔNG phải bởi nhà phát triển - trước hết họ phải biết về tất cả các lỗi mở!)
2. Chúng ta có bao nhiêu lỗi mở và mức độ nghiêm trọng?
3. Cái nào trong số này phải được sửa trước khi chúng tôi sẵn sàng phát hành?
4. Mất bao nhiêu thời gian để lập kế hoạch cho các bản sửa lỗi này - thường dẫn đến: trung bình mất bao nhiêu thời gian để sửa một lỗi?
5. Có bao nhiêu lỗi đã được báo cáo bởi khách hàng trong phiên bản trước?
6. ai đã sửa lỗi này và lỗi này, khi nào và những thay đổi (mã / cấu hình / dữ liệu) nào đã khắc phục?
7. Những sửa lỗi nào được bao gồm trong bản phát hành mà chúng tôi sắp phát hành?
8. ...

Bạn có thể trả lời các câu hỏi [cập nhật] lặp đi lặp lại, đáng tin cậy và hiệu quả [/ update] dựa trên ghi chú sau của bạn không?

Có, nhập dữ liệu lỗi vào trình theo dõi vấn đề đòi hỏi một số chi phí. Tuy nhiên, nó được bù đắp nhiều hơn bởi thời gian và công sức tiết kiệm được khi tra cứu và tạo các báo cáo như trên, từ dữ liệu lỗi được lưu trữ.

Phương pháp của bạn có thể làm việc cho các dự án rất nhỏ với số lượng lập trình viên hạn chế. Khi một dự án trở nên lớn hơn, việc có một hệ thống theo dõi vấn đề trở nên quan trọng hơn nhiều cho sự phối hợp giữa các nhóm khác nhau, đặc biệt là nếu các bản sửa lỗi sẽ được đưa ra trong các bản phát hành mã khác nhau. Các dự án phức tạp sẽ có nhiều bộ phận / bộ phận chuyển động và đảm bảo rằng các sự cố được lên lịch và khắc phục là một phần quan trọng trong việc thực hiện theo dõi vấn đề tốt

Một số bài báo / nghiên cứu có thể khiến bạn quan tâm bao gồm bài viết này thảo luận về việc sử dụng Jira của Zend và nghiên cứu này của Pháp thảo luận về việc sử dụng các hệ thống theo dõi lỗi.

Có thể có những nghiên cứu, nhưng thậm chí tốt hơn là những kinh nghiệm khó kiếm được của những người trong lĩnh vực này. Hầu hết các hệ thống theo dõi vấn đề phải chịu các quá trình thúc đẩy thiết kế của họ. Trình theo dõi vấn đề thường cần hỗ trợ 2 lớp người dùng riêng biệt:

1. Nhóm phát triển
2. Người dùng hệ thống

Cal Henderson (trước đây của Flickr) có một bài viết tuyệt vời về thiết kế của nhiều trình theo dõi vấn đề và lý do tại sao anh ấy thích trình theo dõi vấn đề GitHub (như tôi). Ngoài ra, Garrett Dimon đã trình bày thiết kế của Sifter và minh họa một cách đơn giản hóa quy trình để theo dõi vấn đề hiệu quả hơn . Tôi đã áp dụng một số ý tưởng từ cả hai bài đăng này để giúp đơn giản hóa quy trình theo dõi vấn đề của nhóm tôi.

Tất cả những gì đã nói, nó vẫn đến với mọi người qua quá trình và công cụ. Suy nghĩ chung của tôi là các trình theo dõi vấn đề có xu hướng tạo ra hồ sơ tồn đọng này mà bạn phải quản lý. Trong quá trình xử lý, mọi người có nhiều khả năng hợp lý hóa những gì là hoặc không phải là một lỗi. Trong quá trình của chúng tôi, chúng tôi đưa ra quyết định gần như ngay khi lỗi được đệ trình về việc đó có phải là vấn đề hay không. Khi quyết định đó được đưa ra, lỗi sẽ đi vào Pivotal Tracker. Sự khác biệt ở đây là chúng tôi sử dụng Trình theo dõi để ưu tiên , không phải là bút giữ cho những việc chúng tôi không muốn làm. Trong thực tế khi Icebox bắt đầu trở nên quá lớn, tôi chủ động xóa các mục, bao gồm cả các lỗi. Nếu một vấn đề đủ lớn để xử lý, nó sẽ xuất hiện trở lại.

Chúng tôi hiếm khi cần lịch sử lỗi. Đôi khi, ai đó có thể đề cập đến một triệu chứng của lỗi và chúng tôi có thể thực hiện tìm kiếm để xem liệu nó có liên quan đến một số vấn đề chúng tôi đã xử lý hay không. Nhưng, đó là hiếm.

TL; DR Tập trung vào quy trình của bạn, chọn các công cụ đơn giản và giải quyết các vấn đề khi chúng xuất hiện.

giết những con bọ quan trọng ngay khi chúng xuất hiện

Có vẻ như bạn đang đột nhập vào cánh cửa mở ở đây. Các lỗi quan trọng bị "giết" càng sớm càng tốt, bất kể bạn có sử dụng trình theo dõi vấn đề hay không.

• Oh và một phần "khi chúng xuất hiện" là BTW khá trơn. Trong một dự án, chúng tôi đã có một lỗi quan trọng đe dọa sẽ ném toàn bộ sản phẩm ra khỏi doanh nghiệp (điều gì có thể quan trọng hơn?). Nó rất phức tạp (lỗi kiến ​​trúc) và chúng tôi biết sẽ mất nhiều thời gian để sửa nó. Khách hàng vui lòng đồng ý cho chúng tôi một năm để sửa chữa (trước khi bỏ sản phẩm của chúng tôi) và chúng tôi đã làm điều đó trong khoảng một năm.

Đối với các trình theo dõi vấn đề, tôi đã sử dụng chúng trong gần mười năm và theo quy định, tất cả các lập trình viên xung quanh tôi đã dành khá ít thời gian với trình theo dõi (lưu ý tôi đang nói về lập trình viên; các nhà quản lý là câu chuyện khác nhau). Tôi đã thấy các trường hợp (hiếm khi) khi nó không như vậy - trong tất cả các trường hợp này, một cái gì đó đã bị phá vỡ nghiêm trọng.

Về các nghiên cứu về các cuộc đối thoại trực tiếp và theo dõi vấn đề, một lần nữa cảm giác như bạn đang bước vào cánh cửa mở ở đây. Theo dõi vấn đề là một giao tiếp bằng văn bản điển hình ; Có rất nhiều nghiên cứu cho thấy rằng để thảo luận về mọi thứ, giao tiếp face2face hiệu quả hơn nhiều so với điện thoại , điều này hiệu quả hơn nhiều so với văn bản .

• Thực tế khi bạn hỏi về f2f, cảm giác như bạn (mis) sử dụng trình theo dõi để thảo luận về mọi thứ - đây không phải là mục đích của nó. Để tìm ra mục đích sử dụng của nó, chỉ cần đánh vần tên của nó từ từ và rõ ràng: hệ thống theo dõi vấn đề .

danh sách lỗi quá dài

Theo kinh nghiệm của tôi, ở trên là một lợi thế không phải là một vấn đề.

Với danh sách lỗi dài, các nhà phát triển có thể thiết lập một hàng đợi và lên kế hoạch sửa chữa phía trước. Điều này là hiệu quả như nó được; với tôi đây cơ bản là một niết bàn khi tôi có một hàng đợi như vậy để làm việc. Đầu tiên lỗi - sửa chữa - hoàn thành, thứ hai lỗi - sửa chữa - thực hiện, lỗi tiếp theo - sửa chữa - làm vv vv Không gián đoạn ngu ngốc, không có phiền nhiễu đau đớn với cuộc trò chuyện f2f oh-so-hiệu quả, dòng chảy tinh khiết .

• Tôi chỉ nhớ lại một trường hợp khi danh sách lỗi dài là một vấn đề. Nó đã xảy ra khi một số kẻ ngốc ở cấp quản lý cao hơn quyết định một chính sách buộc các nhà phát triển phải chọn lỗi tiếp theo từ một đống 50-100 gần như hàng ngày. Thật là một sự lãng phí. Chúng tôi mất vài tháng đau đớn cho đến khi chúng tôi tìm ra cách leo lên cái này trên đầu và sửa nó.
  Một thời gian sau khi chúng tôi quản lý để thiết lập luồng công việc thuận tiện, chúng tôi phát hiện ra rằng "tồn đọng vô tận" của chúng tôi đã trống rỗng.