Nhóm phát triển của tôi chỉ tăng 100% (từ 1 nhà phát triển lên 2). Đoàn hệ mới của tôi muốn đầu tư vào phần mềm theo dõi lỗi. Có lợi ích cho phần mềm như vậy cho một nhóm nhỏ như vậy?

Tôi nghĩ rằng tất cả các câu trả lời "có" đi một chặng đường dài để chứng thực ý tưởng. Nhưng tôi sẽ đưa ra ý tưởng rằng quyết định dựa trên một vài câu hỏi:

• Làm thế nào để bạn muốn giao tiếp như là một nhóm? Với 2 nhà phát triển, bạn hiện là một nhóm. Bạn muốn giao tiếp như thế nào? Rất nhiều đội ngũ nhanh nhẹn sống với những cá nhân và bản phác thảo bảng trắng. Nhưng họ cũng có thể đi xa hơn để viết ra mọi thứ, đặc biệt nếu đó là một lỗi không được xếp hạng cao trong danh sách ưu tiên trong một thời gian.
• Bạn muốn giao tiếp với khách hàng như thế nào? Tôi không biết câu trả lời cho vấn đề này, nhưng nếu bạn có bất kỳ lý do nào để xuất bản các lỗi (hoặc các lỗi cố định trong tài liệu phát hành phiên bản), thì cuối cùng bạn sẽ viết chúng xuống. Cũng có thể chọn một hệ thống quản lý lỗi ứng suất thấp và được thực hiện với nó.
• Có giá trị để bảo tồn lịch sử? Câu trả lời có thể là "không phải ngay bây giờ" nhưng nếu bạn nghĩ rằng trong tương lai, bạn muốn thấy xu hướng lỗi để bạn có thể thấy những nơi mà người dùng đang gặp nhiều vấn đề nhất hoặc những nơi bạn có thể dành thời gian kiểm tra và xem xét trước khi phát hành chính - sau đó nhận hệ thống theo dõi lỗi. Điều về lịch sử là ngày bạn muốn ghi lại không phải là ngày bạn nên bắt đầu lưu giữ hồ sơ.

IMO, câu trả lời cho những câu hỏi này là về nơi bạn thấy sản phẩm sẽ đi và cách bạn muốn phát triển nhóm của mình và ít hơn về việc liệu "2 người = lý do cho hệ thống theo dõi lỗi". Câu hỏi lớn hơn có lẽ là "một hệ thống theo dõi lỗi có đáng để dành thời gian cấu hình & quản lý và chi phí mua hàng không?"

1, nhưng chỉ khi nó không đau. Ví dụ, GitHub có trình theo dõi vấn đề rất đơn giản và có thể sử dụng với hơn đủ các tính năng cho một nhóm nhỏ. Bugzilla, Trac hoặc các loại khác đều tốt, nhưng tất cả đều yêu cầu phần cứng, cài đặt và cấu hình trước khi sử dụng và bảo trì chắc chắn là một chi phí khác không.

Chúng tôi đã có một nhóm rất nhỏ ngay lần đầu tiên tôi sử dụng phần mềm theo dõi lỗi và tôi đã rất ngạc nhiên về số lượng công cụ chúng tôi đã nghĩ rằng chúng tôi cần sửa chữa bằng cách nào đó không bao giờ được sửa chữa. Nó hoàn toàn xứng đáng cho dù đội của bạn có lớn đến đâu.

Đúng. Một ngàn lần có.

Thậm chí đừng nghĩ về vấn đề theo dõi lỗi mà là theo dõi vé.

Có thể thấy tất cả các nhiệm vụ của bạn trong vé có một lợi thế rất lớn. Bạn có thể giữ một lịch sử của một nhiệm vụ ở một nơi. Bạn biết ai đã làm việc trên nó và khi nào. Bạn có thể chi tiết như nói những gì đã hoàn thành vào ngày nào cho một nhiệm vụ.

Để theo dõi lỗi, bạn có thể đặt tất cả các lỗi của mình ở một nơi và theo dõi những gì đã được hoàn thành và những gì vẫn đang được tiến hành.

Nó chỉ giúp bạn quản lý mọi thứ tốt hơn nhiều.

Đó là giá trị nó với một nhóm của một hoặc nhiều.

Đối mặt với nó, cho dù bạn mua một giải pháp phần mềm chính thức hay không, bạn sẽ có một hệ thống theo dõi lỗi / tính năng. Nó có thể là trong notepad, nó có thể là ghi chú dán, nó có thể nằm trong một khối các bình luận ở đầu mã của bạn. Tuy nhiên, trừ khi bạn chỉ đang phát triển ngẫu nhiên, bạn sẽ ghi lại danh sách việc cần làm của mình ở đâu đó. Tại sao không sử dụng một hệ thống có tổ chức hơn có thể phát triển cùng với nhóm của bạn?

Cũng đáng xem xét: Nhiều trình theo dõi lỗi được các nhóm rất nhỏ (1-2) sử dụng miễn phí, do đó, không giống như bạn đang phải chịu bất kỳ chi phí lớn nào cho lợi ích.

Bạn không cần bất kỳ phần mềm theo dõi lỗi nào miễn là mọi thành viên trong nhóm

• Có một bộ nhớ ảnh hoàn hảo, và
• Có thể đồng bộ hóa suy nghĩ của họ với mọi thành viên khác trong nhóm.

Câu trả lời ngắn gọn là có.

Một số lý do tại sao:

1. Khả năng đăng nhập các lỗi đã được tìm thấy đối với các phiên bản cụ thể.
2. Khả năng biết lỗi nào (đã biết) chưa được sửa.
3. Theo dõi ai đã sửa một lỗi đã được tìm thấy lại.
4. Doanh thu của nhà phát triển - cho phép chuyển giao kiến ​​thức ngay cả khi bạn bị tấn công là xe buýt hoạt ngôn.

Bạn có thể sẽ muốn xem xét một cái gì đó sẽ không mất nhiều thời gian để bạn thiết lập / quản lý. Tôi cũng sẽ đề nghị tìm kiếm thứ gì đó bao gồm khả năng tích hợp nó với kiểm soát nguồn của bạn.

Câu trả lời này là để thêm trọng số cho phía CÓ của đối số.

Tôi chủ yếu là một nhóm của một. Tôi sử dụng rộng rãi theo dõi vấn đề (redmine) cùng với tích hợp SVN.

Nó thực sự tuyệt vời và tôi sẽ phát điên nếu không có nó; chất lượng của tôi sẽ giảm vì tôi quên mọi thứ và tôi không biết mình phải làm gì.

Công cụ năng suất:

• IDE Decent
• Theo dõi vấn đề
• Kiểm soát nguồn

Theo dõi vấn đề; đừng rời khỏi nhà mà không có nó

Nếu bạn có ít hơn 3 thì có lẽ bạn có thể nhận được bằng bảng tính tài liệu google, có lẽ, tôi đoán vậy. Nhưng thực sự chi phí cài đặt bugzilla hoặc tương tự ở đâu đó rất tầm thường bên cạnh chi phí của một lập trình viên mà bạn nên làm điều đó tốt hơn. (Cộng với khi bạn tăng lên 7 thì nó sẽ ở đó)

Ngay cả một nhóm gồm một người có thể được hưởng lợi từ một số loại theo dõi lỗi, có thể là một tệp văn bản ghi chú hoặc một số phần mềm đầy đủ. Đối với 2 nhà phát triển, tôi chỉ khuyên bạn nên đầu tư thời gian để thiết lập một số hệ thống theo dõi lỗi chứ không phải tiền. Tùy thuộc vào dự án, bạn có thể nhận được bằng cách viết ra các lỗi trên giấy, duy trì danh sách thông qua một tài liệu trực tuyến được chia sẻ hoặc sử dụng phần mềm theo dõi lỗi miễn phí như Trac hoặc Bugzilla. Fogormsz cũng có sẵn dưới dạng dùng thử miễn phí trong 45 ngày.

Đúng.

Bạn cần theo dõi họ một số cách!

Vấn đề là bạn có bao nhiêu lỗi thay vì có bao nhiêu nhà phát triển. Bạn có thể quản lý với một bảng excel khi xử lý một vài lỗi, nhưng ngay cả khi đó nó không phải là tốt nhất.

Có benifet rõ ràng - Tôi sử dụng phần mềm theo dõi lỗi ngay cả trên các dự án cá nhân. Nó không chỉ hữu ích để theo dõi lỗi mà còn theo dõi các yêu cầu tính năng và tính năng của TODO.

Tôi đã sử dụng lỗi ở mọi nơi khi làm việc một mình. Nó hoạt động với DVCS của bạn bằng cách giữ thông tin lỗi cùng với nguồn của bạn. Chi phí rất thấp vì nó không yêu cầu máy chủ trung tâm. Nhược điểm là bạn phải cẩn thận những nhánh nào bạn nhập vào các lỗi mới để đảm bảo chúng lan truyền kịp thời, mặc dù điều đó có thể không quan trọng nếu bạn chủ yếu muốn theo dõi lỗi của mình và những gì đã được sửa trong lần kéo gần nhất của bạn, thay vào đó hơn là theo dõi toàn bộ tình trạng của một nhóm.

Chỉ cần bắt đầu sử dụng một

Nếu bạn chỉ bắt đầu sử dụng một cái, bạn sẽ bắt đầu nhận ra sự tiện lợi của chúng trên thực tế, giống như phần mềm kiểm soát phiên bản, hoặc cho vấn đề đó, kiểm soát phiên bản phân tán.

Trưởng thành phát triển

Không có vấn đề gì nếu bạn có một nhóm 100 hoặc 1, tôi bắt đầu sử dụng theo dõi lỗi và kiểm soát phiên bản phân tán (rất có ý nghĩa vì các cam kết cục bộ) chỉ cho bản thân tôi và tôi và tôi đã cảm thấy ở một cấp độ khác, nhưng không chỉ có điều, tôi có thể quản lý công việc của mình ở một cấp độ khác ... đến một mức độ mà nó có thể mở rộng mà không cần tôi đầu tư nhiều nỗ lực hơn.

Bằng cách sử dụng trình theo dõi, bạn có thể lường trước các vấn đề và ưu tiên công việc, trình theo dõi lỗi / vấn đề không chỉ dành cho các lỗi / vấn đề, chúng còn nhiều hơn cho quản trị dự án và mỗi dự án nên có điều đó .

Đối với tôi nó không chỉ là về phần mềm, mà là quá trình diễn ra xung quanh nó. Trong công việc hàng ngày của tôi với tư cách là Quản lý kiểm tra, về cơ bản tôi sống trong một và nó cung cấp các lợi ích sau:

Tôi thấy điều này hoạt động thực sự tốt với 2+ người thử nghiệm và 3+ nhà phát triển.

Quản lý các nỗ lực sửa lỗi nhà phát triển

Chúng tôi chủ động quản lý "hàng đợi lỗi" của nhà phát triển để kiểm soát số lượng công việc họ đã giao cho họ và đảm bảo rằng chúng tôi có phân bổ cấp độ cho công việc sửa lỗi trong toàn nhóm.

Quyết định những gì không và không được sửa chữa

Xử lý các lỗi mới trong quy trình hàng ngày là một cách tuyệt vời để giúp tập trung vào những gì bạn làm và không sửa chữa, cũng như khi bạn sửa nó. Đầu vào một dự án, bạn muốn sửa chữa mọi thứ. Cuối cùng, bạn chỉ muốn sửa các nút chặn hiển thị và công cụ theo dõi lỗi rất tốt cho việc đó

Khi bạn cần số liệu

Vấn đề lớn đối với tôi là Metrics, tức là khi bạn muốn có thể xem các xu hướng tìm lỗi và sửa lỗi, trong đó các khu vực lỗi của mã, hoặc người kiểm tra đang tìm và kiểm tra lại lỗi nhanh như thế nào. Đã đến lúc cho một hệ thống theo dõi lỗi.

Tôi đồng ý với ý kiến ​​chung rằng một thành viên trong nhóm là đủ để bắt đầu cần một trình theo dõi lỗi. Tôi mô tả nó là bắt buộc sau khi bạn có một hoặc hai người dùng thực sự, nhưng rất quan trọng trước khi phát hành lần đầu tiên.

Cá nhân, tôi thích hóa thạch cho cả kiểm soát nguồn và theo dõi lỗi. Đây là một SCM phân phối thấp hoàn toàn được tích hợp tốt cho trình theo dõi lỗi và wiki. Và nó là một bản cài đặt có thể thực thi được, di động rộng rãi và sử dụng một ứng dụng web nội bộ làm GUI của nó. Trang chủ của nó thực sự được phục vụ gần như hoàn toàn bởi một bản sao hóa thạch.

Với trình theo dõi được tích hợp chặt chẽ với kiểm soát sửa đổi, bạn có thể dễ dàng liên kết các thay đổi với vé và xem cập nhật vé trong cùng chế độ xem dòng thời gian dưới dạng sửa đổi (và chỉnh sửa trang wiki).

Có có có có! Có thể theo dõi, ưu tiên và quản lý các vấn đề của bạn là chìa khóa để phát triển phần mềm thành công. Với một người, bạn có thể (gần như) thoát khỏi một bảng tính và nén các cây nguồn cũ. Việc thêm một nhà phát triển vào dự án sẽ thay đổi đáng kể - đột nhiên, theo dõi vấn đề và kiểm soát mã nguồn là cần thiết hoặc bạn sẽ bỏ qua các vấn đề, chức năng ghi đè và nói chung là có thời gian khốn khổ của nó.

Tôi ngạc nhiên khi chưa có ai nhắc đến công ty mẹ của StackExchange, FogCalet, - phần mềm FogBugz của họ là ứng dụng theo dõi vấn đề tốt nhất mà tôi từng sử dụng. Tốc độ cao, lực cản thấp và giá cả phải chăng, đặc biệt nếu bạn sử dụng giải pháp lưu trữ của họ. Họ từng có một bản dùng thử được lưu trữ miễn phí, tôi tin rằng, hai giấy phép người dùng miễn phí - đó có thể không còn là vấn đề nữa, nhưng tôi khuyên bạn nên kiểm tra nó.

đây là 2 xu của tôi

để theo dõi lỗi tôi chỉ cần sử dụng bảng tính google-doc, tôi có thể mời bất kỳ ai tôi muốn chỉnh sửa hoặc xem nó. nó miễn phí vì vậy không có nhiều đầu tư. tôi theo dõi tất cả các nhiệm vụ trên đó để chỉ lỗi.

tôi cũng chạy SVN trên máy chủ web của mình mà không phải trả thêm bất kỳ chi phí nào cho việc lưu trữ web.

một số khách hàng đã yêu cầu sử dụng unuddle hoặc phần mềm quản lý dự án / theo dõi lỗi như vậy nhưng tôi thích các giải pháp miễn phí mà tôi đề cập ở trên.

Nếu bạn có một trình theo dõi lỗi tối giản, tôi muốn nói rằng nó hữu ích ngay cả đối với một nhóm. Tại một trong những trang web dự án của bạn tôi QuokForge , về cơ bản họ cung cấp một ví dụ Red Mine cho mỗi dự án. Red Mine, theo tôi có một trình theo dõi lỗi tốt (ngay cả khi đôi khi hơi lạ). Cụ thể là vì bạn có thể báo lỗi bằng cách chỉ nhập văn bản vào trường MỘT. Tôi cũng đã sử dụng FogBugz trước đây. Nó miễn phí cho 2 người hoặc ít hơn. Và nó cho phép sự đơn giản tương tự, nộp một lỗi bằng cách chỉ điền vào một trường văn bản. (Nó cũng cung cấp biểu đồ và những thứ khác cực kỳ hữu ích)

Về cơ bản, đừng biến lỗi thành một quy trình nghiêm ngặt và chính thức yêu cầu bạn dành ra 30 phút để điền vào báo cáo lỗi (BugZilla, tôi đang nhìn bạn). Điều này chỉ có nghĩa là mọi người sẽ không sử dụng nó.

Cuối cùng, có một danh sách lỗi (ngay cả khi tất cả mỗi lỗi chứa khoảng 50 ký tự văn bản) là vô cùng quý giá. "Hmm, cơn sốt để phát hành 1.0. Tôi nghĩ rằng tôi đã sửa lỗi cuối cùng." Và thật tuyệt vời cho các nhà quản lý khi thấy bạn thực sự đang làm gì đó :). Trong một nhóm, điều đó có giá trị hơn vì cả hai bạn đều không cố gắng giữ một bộ danh sách việc cần làm tinh thần khác trong đầu. Và nó sửa lỗi "Bạn đã sửa lỗi [lỗi bảo mật thực sự xấu] chưa? Ừm, tôi nghĩ là vậy. Ok, hãy phát hành 1.0 đi."

Tôi cũng thích theo dõi các tính năng là tốt. Đây là một chút tùy chọn hơn nhưng tôi vẫn tìm thấy lợi ích từ việc có thể giảm tải nhiệm vụ tinh thần là giữ một danh sách việc cần làm trong đầu.

Ngoài ra, hãy xem Joel đã nói gì về nó

Bạn vừa đạt đến con số đó ... 2 ! Mặc dù tôi có thể thấy những lợi ích của việc sử dụng phần mềm theo dõi lỗi ngay cả khi bạn là nhà phát triển duy nhất ... bạn chỉ có thể nhận được mà không cần đến nó khi tổng số nhà phát triển là 1.

Tuy nhiên, ngay khi bạn có hai hoặc nhiều nhà phát triển, không có một lý do duy nhất nào để không có phần mềm theo dõi lỗi, không phải một.

Đúng. Và một đề xuất là bitbucket http://www.bitbucket.org Họ cung cấp theo dõi lỗi miễn phí cũng như các kho riêng tư miễn phí trong đồng bóng.

Một. Trong trường hợp đó, nó giống như một danh sách việc cần làm hơn.

Tôi giả sử bằng cách đầu tư thời gian của bạn. Có rất nhiều hệ thống theo dõi lỗi miễn phí ngoài kia, điều đó sẽ tốt cho một nhóm hai người. Tôi sẽ không nhìn vào các dịch vụ thương mại cho đến khi tôi có một đội ngũ lớn hơn.

Tôi nghĩ rằng câu hỏi của bạn đã làm nổi bật quan niệm sai lầm của bạn. Đối với nó không phải là nhóm cần theo dõi lỗi, đó là (các) sản phẩm.

Vì vậy, theo dõi lỗi cần phải được thực hiện trong phần mềm? Vâng, điều đó sẽ giúp ích, bạn không nghĩ sao?

Nó có thể không có giá trị nếu có hai điều kiện sau đây:

1. Các vấn đề có tuổi thọ ngắn. Trong trường hợp này có thể là đủ với một bảng tác vụ đơn giản (vì thật thông minh để hình dung quy trình làm việc vì nhiều lý do khác). Tuy nhiên, nếu bạn không thể giải quyết vấn đề nhanh chóng, f.ex. sửa lỗi nhanh chóng, bạn sẽ thấy hữu ích để theo dõi vấn đề.
2. Thay đổi mã được ghi lại với các bài kiểm tra tự động như tài liệu sống. Tức là, lỗi và sửa lỗi được ghi lại với các thử nghiệm thất bại khi chúng xuất hiện, với việc vượt qua các thử nghiệm trở thành thử nghiệm hồi quy sau khi sửa chữa. - Và các thay đổi chức năng được ghi lại bằng các thử nghiệm chấp nhận tự động (ví dụ: sử dụng một số công cụ BDD như FitNesse hoặc Cucumber). Tài liệu như vậy nên dễ dàng có sẵn từ một máy chủ CI như Jenkins.

Nếu 1 hoặc 2 không có mặt, bạn sẽ được hưởng lợi từ việc theo dõi vấn đề.

Không

Đừng theo dõi lỗi, sửa chúng .

Đó không phải là quy mô của nhóm quan trọng, đó là thời gian bạn sẵn sàng xem xét các lỗi trong danh sách trước khi sửa chúng.

Nếu bạn đang sử dụng Agile / TDD, danh sách lỗi của bạn sẽ ngắn và các lỗi sẽ không tồn tại lâu trong danh sách. Bất kỳ hệ thống theo dõi sẽ đủ trong trường hợp đó.