Làm thế nào để ảnh hưởng đến các ưu tiên của lỗi đối với các nhà phát triển và xử lý chúng cho phù hợp?

Chúng tôi có một quá trình lỗi hiện đang được làm việc.

Chúng tôi có 3 cấp độ lỗi:

Lỗi P1: Lỗi ngăn người dùng làm việc. Họ phải được giải quyết tại chỗ.
Lỗi P2: Lỗi đang tác động nhưng người dùng có thể làm việc
Lỗi P3: Lỗi không ảnh hưởng và nơi người dùng có thể làm việc.

P1 là bắt buộc và phải được xử lý tại chỗ. Nhưng đối với P2 và P3, chúng tôi đánh giá theo từng trường hợp.

Với 3 cấp độ mà chúng tôi có, nhóm có xu hướng làm việc với những phát triển mới cấp bách hơn mà khách hàng yêu cầu, thay vì giao dịch với P2 và P3, điều này gần như không khẩn cấp.

Các câu hỏi như sau:

Tôi có nên thêm một mức độ ưu tiên khác, như có P4 không?

Tôi cũng nên chỉ định cho họ các mục tiêu để xử lý các vé không khẩn cấp như trong tuần này, khi không chỉ định một nhiệm vụ mã hóa, bạn nên xử lý ít nhất 1 P2?

Hiện tại, chúng tôi không có mục tiêu như tôi nêu ở trên nhưng mối quan tâm của tôi là việc cung cấp cho họ những mục tiêu như vậy có thể là tàn bạo. Điều chắc chắn là tôi cần nói chuyện với họ về các mục tiêu, nhóm muốn tham gia thảo luận đặc biệt là khi chúng tôi đang thiết lập mục tiêu.

Cập nhật:

Tôi đã đề xuất câu hỏi này trong điều khoản tương tự. Tuy nhiên nó không giống nhau chút nào.

Câu hỏi của tôi là làm thế nào để mọi người đối phó với các lỗi, mà không áp đặt một chương trình nghị sự nghiêm ngặt và chưa được giải quyết. Vì vậy, không, câu hỏi ngụ ý không giúp tôi. Tuy nhiên, cảm ơn bạn.

agile debugging issue-tracking

— Andy K
nguồn

Bản sao có thể có của Làm thế nào tôi có thể thuyết phục ban quản lý xử lý nợ kỹ thuật?

— gnat

thông thường mức độ ưu tiên không hữu ích bằng thứ tự ưu tiên ... "bug X" quan trọng hơn "bug Y". nếu cuối cùng bạn thêm p4, bạn sẽ muốn p5 và p3,5

— sudo rm -rf slash

Nếu bạn có quá nhiều lỗi P1 đến nỗi tất cả các nhà phát triển của bạn luôn bận rộn sửa chúng thay vì làm việc trên P2 / P3, thì bạn đã làm điều gì đó rất sai. Đừng thêm bất kỳ tính năng nào trong một thời gian. Tập trung vào việc đi sâu và khắc phục các sự cố kiến trúc (hoặc nhân sự) gần như chắc chắn gây ra nhiều lỗi này. Ví dụ: nếu bạn đang mã hóa bằng C ++, hãy đảm bảo rằng bạn đang sử dụng RAII ở mọi nơi bạn có thể, vì vậy bạn đừng quên thủ công .release().

— Vụ kiện của Quỹ Monica

Mục tiêu của bạn là gì? Bạn có muốn các nhà phát triển làm việc nhiều hơn với các sửa lỗi và ít hơn về các tính năng mới không? Vui lòng chỉnh sửa câu hỏi của bạn để làm rõ. Ngoài ra, hãy mô tả cách các nhà phát triển hiện đang nhận hoặc đảm nhận công việc? Điều gì được sử dụng để quyết định những gì được làm việc trên?

— sleske

tính năng, lỗi, thay đổi bất cứ điều gì bạn gọi nó, phần mềm không làm những gì nó cần. Sự khác biệt duy nhất giữa một lỗi và một tính năng là ai trả tiền cho nó.

— mattnz

Câu trả lời:

Nói chung, bạn có hai trục cho lỗi: trọng lực và tần số.

Vì vậy, rõ ràng một cái gì đó nghiêm trọng và thường xuyên là ưu tiên cao nhất. Tuy nhiên, điều gì đó nghiêm trọng nhưng hiếm khi xảy ra nên được cân nhắc gần giống như điều gì đó không nghiêm trọng nhưng lại xảy ra thường xuyên. Vì vậy, giả sử bạn đánh giá trọng lực từ 1 đến 3 và tần số từ 1 đến 3, các loại lỗi bạn có thể nên sửa là những lỗi vượt qua đường chéo được xác định bởi trọng lực 1, tần số 3 và trọng lực 3, tần số 1.

Lỗi chặn hoặc lỗi có thể tạo ra thiệt hại tiềm tàng cho thông tin khách hàng sẽ luôn là trọng lực 3. Tương tự, lỗi với trọng lực 1 sẽ không được người dùng chú ý hoặc có mức độ ưu tiên thấp. Nếu bạn không chắc chắn ở đây, 2 có lẽ là một số an toàn để gán.

Một lỗi mà người dùng nhìn thấy mỗi lần chương trình được khởi chạy sẽ có tần số là 3. Một lỗi với tần số 1 sẽ là một điều hiếm khi xảy ra nếu có. Một lần nữa, nếu bạn không chắc chắn, 2 có lẽ là một số an toàn để gán.

Chủ yếu là chủ quan về những gì cấu thành một lỗi với trọng lực 3 hoặc một lỗi với tần số 3, nhưng sử dụng ý thức chung của bạn. Một lỗi với trọng lực 1, tần số 2 có lẽ là nhãn sai chính tả. Một lỗi với trọng lực 2, tần số 1, có thể là xử lý lỗi thích hợp khi kết nối cơ sở dữ liệu bị hỏng.

Một lần nữa, đây chỉ là một ý tưởng sơ bộ, nhưng ý tưởng là nhấn mạnh vào những gì nên là trọng tâm để sửa lỗi là một loại xử lý. Rõ ràng không thể loại bỏ tất cả các lỗi, chặn hoặc bằng cách khác, mặc dù ít nhất với phương pháp này, bạn có thể nói rằng các lỗi không quá bức xúc hoặc quá thường xuyên. Nếu bạn chỉ sửa các lỗi đang chặn lỗi, thì các lỗi tần số cao sẽ bị bỏ qua và người dùng sẽ nhận thấy rằng bạn đã không sửa các lỗi này.

Ngoài ra, để thuận tiện, bạn có thể thấy bạn thích cung cấp các chữ cái cho trọng lực hoặc tần số, vì vậy bạn có thể nói rằng một lỗi là lỗi B3, và rõ ràng cả trọng lực và tần số.

Chúc may mắn!

— Neil
nguồn

Trong thực tế, chỉ có một số liệu cho các lỗi - ROI - chi phí sửa chữa là bao nhiêu so với số tiền mà công ty mất vì không sửa nó. So sánh điều đó với các tính năng. Tất nhiên, cách bạn tính toán số liệu đó liên quan đến trọng lực, tần suất, v.v.

— corsiKa

@corsiKa, có ROI là một số liệu tổng hợp: "lợi nhuận" và "đầu tư". Và đối với các lỗi, sự trở lại có thể được mô hình hóa dưới dạng tổng hợp của "trọng lực" và "tần số".

— Paul Draper

@corsiKa, kiểu phân tích ích kỷ máu lạnh đó về các quyết định chất lượng thực sự vô cùng vô trách nhiệm. Đó là logic tương tự dẫn đến các công ty dược phẩm lách luật kiểm tra hiệu quả nếu họ có thể "thoát khỏi nó", hoặc giữ thuốc có lợi nhuận trên thị trường bất chấp mức độ nghiêm trọng và tần suất của tác dụng phụ. Đó là sự vô trách nhiệm tương tự dẫn đến các botnet lớn bao gồm các bộ định tuyến tiêu dùng không an toàn và các thiết bị "thông minh", bởi vì nhà sản xuất không thể thấy bất kỳ giá trị đồng đô la nào trong bảo mật tốt. Trọng lực và tần số là số liệu tốt hơn NHIỀU so với "tác động cuối cùng".

— tự đại diện

@Wildcard Tôi thực sự là một người cộng sản, vì vậy tôi đồng ý 100% với bạn rằng những điều đó tốt hơn. Điều đó không thay đổi thực tế rằng đây là cách các công ty phần mềm hoạt động và đi ngược lại làn sóng đó, trừ khi bạn điều hành công ty, sẽ nhấn chìm bạn. Mặc dù đáng chú ý, nhưng nó không ích kỷ. Đó là phục vụ đơn lẻ, nhưng đó không phải là bản thân, đó là công ty. Chỉ cần ném mà ra khỏi đó.

— corsiKa

@Wildcard và corsiKa công ty không phải là một công ty lớn và chúng tôi không thể đủ khả năng để nói "oh chúng tôi sẽ mất tiền, sau đó chúng ta hãy làm gì đó nếu không hãy giữ nó". Tuy nhiên, trong sơ đồ lớn của mọi thứ, tôi không tin rằng cách tiếp cận mà bạn đề cập là bền vững trong thời gian dài. Con người - Khách hàng là xa ngu ngốc. Các công ty đã rao giảng loại phúc âm đó, Sun, để đặt tên cho một người không còn ở đây nữa. Tôi đã làm việc trong quản lý tài khoản đủ lâu để tiền không phải là như vậy. Đối với bất cứ ai, nếu bạn tình cờ làm việc cho công ty đó, nơi công ty thiếu lòng trung thành 1 / n

— Andy K

Điều này thực sự sôi sục với những gì bạn coi là quan trọng hơn. Lỗi P2 hay tính năng mới?

Thông thường một hệ thống quản lý dự án nhanh sẽ bao gồm một số loại cuộc họp ưu tiên trong đó các nhiệm vụ được sắp xếp theo mức độ ưu tiên và được thực hiện theo thứ tự đó.

Các nhà phát triển không được phép chọn các nhiệm vụ mà họ làm việc. Đó là công việc của người quản lý dự án. Ai phải đảm bảo rằng dự án có số lượng lớn nhất các tính năng quan trọng được bao gồm trước khi hết ngân sách.

Đó thực sự là điều quan trọng nhất. Các quy tắc đơn giản như "sửa ít nhất 1 P2 mỗi tuần" không thực sự giúp ích cho mục tiêu này.

— Ewan
nguồn

Rắc rối với việc gán mức độ ưu tiên là bất kỳ mức độ chi tiết nào của nhóm bạn chọn, bạn luôn luôn có nhiều hơn một thùng. Bạn cần sắp xếp mọi thứ theo thứ tự, không chỉ nói "tất cả những điều này là ƯU TIÊN HÀNG ĐẦU!"

— Ewan

@Ewan Ngoài ra còn có khả năng lạm phát ưu tiên trong đó nhóm cao nhất của bạn có nhiều vấn đề hơn bạn có thể hy vọng giải quyết và các mức độ ưu tiên mới được phát minh ra bên ngoài hệ thống theo dõi lỗi. Tôi đã nghe người ta nói về P trừ 2 vấn đề.

— kasperd

Nói rằng các nhà phát triển không được phép chọn các nhiệm vụ họ làm việc sẽ gây hại cho năng suất của bạn. Nếu một nhà phát triển bị chặn trong vấn đề ưu tiên cao nhất mà họ đang làm việc, thì tốt hơn là họ có thể làm việc với một vấn đề khác trong khi đó họ không làm gì trong khi vấn đề đầu tiên của họ bị chặn trên một cái gì đó. Hơn nữa, các vấn đề không gây hại cho người dùng nhưng gây hại cho năng suất của nhà phát triển thường không được ưu tiên cao như họ nên làm. Cuối cùng, nói với các nhà phát triển rằng họ không được phép đưa ra quyết định của riêng họ là một cách chắc chắn để phá hủy động lực.

— kasperd

@kasperd Tôi nghĩ rằng hầu hết các nhà phát triển chấp nhận rằng họ là nhân viên cũng như siêu thiên tài kỹ thuật và chấp nhận rằng chủ nhân của họ phải quyết định những nhiệm vụ nào nên được thực hiện trước. Rõ ràng nếu một trong số đó bị chặn, bạn sẽ chuyển sang phần quan trọng nhất tiếp theo, nhưng bạn không bỏ qua 10 nhiệm vụ quan trọng để thực hiện công việc tuyệt vời này.

— Ewan

Tôi đã thấy rằng nếu công việc được hoàn thành hoặc bị chặn, thay vì kéo một nhiệm vụ phát triển khác vào giai đoạn nước rút (làm scrum) thì một lỗi nên được ưu tiên. MS nổi tiếng đã ưu tiên tất cả các lỗi trong mọi nhiệm vụ phát triển khi làm việc trên Windows 2000 - họ thấy rằng đó là cách tốt nhất để sản xuất phần mềm không có lỗi (một trong những lý do mà 2000 thực sự thích) như thể họ không làm , lỗi sẽ có xu hướng bị bỏ lại vì thường có một số phát triển mới để làm việc thay thế.

— Baldrickk

Đây là một chu kỳ khá phổ biến đối với một phần mềm để chồng các lỗi không nghiêm trọng cho đến khi một cái gì đó đưa ra, sau đó một sự kiện lớn xảy ra và nhiều trong số chúng được sửa chữa cùng một lúc; có thể bằng cách dành một hoặc hai lần chạy nước rút cho các lỗi trước khi phát hành một bản phát hành mới, hoặc bởi phần mềm là EOL và đã sống sót sau các lỗi heap-o-bug.

Vì vậy, bạn đang ở trong một công ty tốt nếu các nhà phát triển của bạn chỉ để họ trượt. Tất nhiên, bạn có thể tung hứng với "quy tắc" như bạn đã đề cập ("nếu bạn không làm việc trên một tính năng mới, bạn phải làm việc trên ít nhất một P2 mỗi tuần"), nhưng điều đó có thể sẽ khiến bạn không được ưa chuộng.

Câu hỏi của tôi là làm thế nào để mọi người đối phó với các lỗi, mà không áp đặt một chương trình nghị sự nghiêm ngặt và chưa được giải quyết.

Thay vào đó, tôi sẽ đề nghị thay đổi suy nghĩ tổng thể một chút và làm cho các lỗi giống như các tính năng hơn theo nghĩa chúng là công dân hạng nhất trong hồ sơ tồn đọng của bạn. Vâng, các tính năng mới là tuyệt vời; có, quản lý và bán hàng rất khó khăn về các tính năng mới. Nhưng có một ứng dụng ổn định, hoạt động tốt thay vì một đống lỗi khổng lồ cũng rất quan trọng.

Đừng nói với các nhà phát triển của bạn rằng họ phải làm công việc họ không thích; nhưng cố gắng thay đổi không khí để họ thích làm việc với bọ. Cố gắng thấm nhuần niềm tự hào về một ứng dụng không có lỗi. Làm cho nó trở nên thú vị hơn (sic) để khắc phục lỗi bằng cách đặc biệt cho phép chúng thực sự khắc phục lý do cơ bản khiến biểu hiện lỗi đó (nghĩa là không chỉ là cách khắc phục / hack nhanh), nếu có. Trích xuất một số cấu trúc lớp bị hỏng và thay thế nó bằng một cái gì đó phù hợp hơn có thể rất thú vị cho các nhà phát triển. Nếu bạn có một số mảnh trung tâm bị hỏng thường xuyên làm cho các lỗi xuất hiện ở nơi khác, hãy sửa chữa mảnh trung tâm.

Cách bạn đạt được mục tiêu của mình phụ thuộc rất nhiều vào tính cách của chính bạn và của các nhóm của bạn - đừng cố lừa họ vào những gì bạn muốn đạt được, nhưng hãy thảo luận cởi mở, cố gắng để có được hiệu ứng ngang hàng, hãy để họ đưa ra một quá trình làm việc bản thân, và như vậy.

— AnoE
nguồn