2008-12-15 23 views
7

Vào những thời điểm khác nhau trong sự nghiệp, tôi đã khuyến khích nhân viên tôi làm việc và/hoặc quản lý để theo dõi các khiếm khuyết trong các tạo phẩm của quá trình phát triển ngoài mã nguồn (tức là yêu cầu, kiểm tra, thiết kế). Mỗi khi yêu cầu đã được đáp ứng với sự kinh ngạc, lẫn lộn và kháng cự. Nó có vẻ rất rõ ràng với tôi rằng tôi luôn luôn bị sốc khi mọi người chống lại ý tưởng.Chúng ta có nên theo dõi các khuyết tật trong những thứ khác ngoài mã không?

Những gì chúng tôi nhận được từ bài tập này là hình ảnh về nơi các lỗi được tạo và nơi chúng được tìm thấy (trong phần nào của quá trình). Nếu chúng ta đang xây dựng các yêu cầu xấu thì chúng ta sẽ biết nó và có thể làm việc để cải thiện chúng.

Có ai khác đang thu thập thông tin về các lỗi không có trong mã nguồn không?

+0

Để làm rõ: Bạn có theo dõi lỗi trong những thứ khác ngoài mã nguồn không? –

+0

bạn có thể theo dõi lỗi trong đồng nghiệp của bạn, nhưng họ có thể không thích nó! –

+0

như đường phố trên tường? – annakata

Trả lời

10

Có, theo dõi tất cả.

Tài liệu, tài liệu thiết kế, yêu cầu, v.v.

Tôi cũng ngạc nhiên khi bạn nghe "đối số" chống lại nó.
Ít nhất hệ thống theo dõi sẽ có thể xác định được nơi phát hiện lỗi và phần nào của quá trình được tiêm.

1

Vâng, chắc chắn. Các tạo tác xung quanh mã của bạn - các mô hình, thông số kỹ thuật, tài liệu, thông tin yêu cầu, các trường hợp sử dụng, v.v. - tất cả đều có thể chứa các lỗi ảnh hưởng đến chính mã đó.

0

Thông thường, hệ thống theo dõi lỗi có giả thiết rằng chúng là danh sách những thứ cần sửa hoặc triển khai. Theo dõi lỗi trong các yêu cầu hoặc tài liệu khác (ví dụ: danh sách công việc) dường như không giống nhau. Nó là một vấn đề của việc giữ hồ sơ để bạn có thể xu hướng các vấn đề và đánh giá nếu bạn đang làm cho ít hơn của họ.

Tôi đang theo dõi chúng, nhưng bên ngoài hệ thống theo dõi lỗi của chúng tôi.

+0

để bạn ủng hộ hai hoặc nhiều hệ thống theo dõi? Điều đó có vẻ phản trực giác và lãng phí thời gian và tài nguyên. – Tim

+0

Bạn vẫn cần sửa lỗi, ngay cả khi đó là lỗi trong tài liệu. –

+0

một đối số cho trình theo dõi nguồn mở. chỉ tìm kiếm và thay thế "lỗi" với "tình huống thú vị" ... – DarenW

0

Vâng duh ... bất cứ điều gì bạn có thể cải thiện, làm những gì có thể cải thiện!

Điều trị tất cả là theo dõi lỗi có ý nghĩa - ý kiến ​​sẽ khác nhau, nhưng bạn sử dụng một hệ thống theo dõi sẽ đưa ra một bức tranh lớn nhất cho tất cả, cho phép phân công nhiệm vụ, v.v. hoặc một cái gì đó nhằm mục đích sử dụng các hệ thống này theo cách vượt ra ngoài việc theo dõi mã nguồn ban đầu - hình ảnh thuyết phục nhiều hơn từ.

0

Tôi thường theo dõi nguồn gốc của tất cả các lỗi. Chúng có thể được sửa trong mã, nhưng chúng không nhất thiết phải gây ra bởi điều đó.

Yêu cầu sai, yêu cầu diễn giải sai, thiết kế tồi, lỗi phát triển, tài liệu xấu, kiểm tra sai, thiếu kiểm tra, kiểm tra lỗi thời, mã không làm những gì nhà phát triển làm, lỗi công cụ/trình biên dịch (rất hiếm, theo quan điểm của tôi), hãy xây dựng sự cố hệ thống ....

Với tôi, tất cả đều "hệ thống không làm những gì khách hàng muốn", và tất cả chỉ ra điều gì đó phải được thay đổi để thực hiện nó làm những gì khách hàng muốn nó làm. Tranh luận xem đó là lỗi hoặc tính năng, hoặc một lỗi mã nguồn hoặc một số vấn đề khác làm sao để giải quyết các vấn đề với tôi.

3

Tuyệt đối. Chỉ cần nhìn vào Ubuntu Bug #1.

+0

Đó là ... một 404. Bạn đang cố gắng mỉa mai? –

0

Một vấn đề lớn mà không ai có vẻ đã đề cập là bắt đầu một cơ sở dữ liệu về mùi hôi và bẫy để sử dụng khi thực hiện đánh giá ngang hàng.

Đây là tài nguyên vô giá cho các đồng nghiệp thực sự thực hiện đánh giá.

Nó chắc chắn sẽ trả hết trong dài hạn. Đây cũng sẽ là một tài liệu sống, cơ sở dữ liệu, vv mà được thêm vào như:

  • lỗi được cố định
  • như các đồng nghiệp thực hiện đánh giá, và
  • như máu mới đến gia nhập đội (s) mang đến cho họ những kiến ​​thức và kinh nghiệm mới.

HTH.

cổ vũ,

Rob

0

aboslutely. nếu quá trình của bạn đủ tốt để theo dõi ngược nguồn gốc của lỗi đến orgin tuyệt vời. nó giúp khách hàng và nhà thiết kế hội đủ điều kiện các ràng buộc mà họ hoạt động.

khách hàng: phát triển robot để cắt cỏ nơi mà tất cả lá cỏ sẽ được cắt theo chiều dài thống nhất chính xác

nhà thiết kế: chúng tôi sẽ sử dụng kéo mẫu giáo thuận tay trái gắn vuông góc với mặt đất đảm bảo sắc nét/cắt chính xác

QA: cắt chính xác.

khách hàng: tại sao robot mất 6 ngày để cắt cỏ. chúng ta cần trong 30 phút hoặc ít hơn!

theo dõi rõ ràng nguồn gốc của lỗi hiệu suất có thể giúp trong các cuộc trò chuyện đúc và cải thiện quy trình tiếp theo.

0

Chúng tôi theo dõi lỗi trong phần mềm, lỗi trong tài liệu, lỗi trong bản vẽ và yêu cầu các tính năng mới đều sử dụng cùng một công cụ theo dõi.

Các vấn đề liên quan