Giữ nhanh nhẹn với chính sách không có lỗi / lỗi

Trong dự án của chúng tôi, chúng tôi làm việc theo phương pháp zero-bug (aka zero-defect). Ý tưởng cơ bản là các lỗi luôn được ưu tiên cao hơn các tính năng. Nếu bạn đang làm việc với một câu chuyện và nó có một lỗi thì nó phải được giải quyết để câu chuyện được chấp nhận. Nếu một lỗi được tìm thấy trong giai đoạn nước rút cho một câu chuyện cũ hơn, chúng ta cần đặt nó tiếp theo trong hồ sơ tồn đọng của chúng tôi và giải quyết nó - ưu tiên hàng đầu.

Lý do tôi nói giải quyết là không phải lúc nào chúng tôi cũng sửa lỗi. Đôi khi chúng tôi chỉ tuyên bố rằng "sẽ không sửa chữa" vì nó không quan trọng. Tất cả trong tất cả nghe có vẻ tuyệt vời. Chúng tôi đang vận chuyển các sản phẩm chất lượng cao và không mang "bướu" dưới dạng tồn đọng lỗi lớn.

Nhưng tôi không chắc cách tiếp cận này là chính xác. Tôi có xu hướng đồng ý rằng chúng ta luôn cần sửa các lỗi nghiêm trọng càng sớm càng tốt và chúng ta cần loại bỏ các lỗi không thú vị. Nhưng những gì về lỗi quan trọng nhưng không quan trọng bằng các tính năng mới? Tôi có xu hướng nghĩ rằng họ nên được nộp trong hồ sơ tồn đọng với một ưu tiên phù hợp.

Tôi sẽ đưa ra một ví dụ để nó rõ ràng hơn - trong dự án của tôi, chúng tôi làm việc với một giao diện người dùng được viết bằng flex. Chúng tôi có một màn hình hướng dẫn mở ở cùng kích thước cho mọi độ phân giải màn hình. Hóa ra khi chúng ta mở rộng cửa sổ trình hướng dẫn, một trong các trang trông không được tốt (có một thanh cuộn dọc không biến mất mặc dù trình hướng dẫn hiện có thể hiển thị mọi thứ và không yêu cầu thanh cuộn). Tôi nghĩ rằng lỗi này là xấu xí. Tôi chắc chắn rằng nó PHẢI được sửa chữa. Nhưng chúng tôi đang có một lịch trình chặt chẽ và chúng tôi có rất nhiều tính năng mà chúng tôi sợ sẽ không cắt giảm và đưa vào phát hành. Tôi cảm thấy rằng chúng ta có thể sống với lỗi như vậy. Nó không cần phải sửa nhưng ở mức độ ưu tiên thấp hơn các tính năng khác (vì vậy, trong trường hợp chúng tôi không thể hoàn thành nó, ít nhất chúng tôi đã không bỏ qua các tính năng quan trọng hơn). Nhưng,

Tôi rất thích nghe ý kiến ​​về cách quản lý các lỗi mà tôi không muốn đánh dấu là "sẽ không sửa" nhưng cũng không quan trọng nhất.

Sửa lỗi trước khi viết mã mới thực sự là một trong mười hai điểm của bài kiểm tra Joel . Joel cũng giải thích lý do tại sao điều này là phải có:

Nói chung, bạn càng chờ đợi lâu trước khi sửa lỗi, thì càng tốn kém (về thời gian và tiền bạc).

Bạn có một sự lựa chọn:

• Hoặc bạn thực hiện một tính năng được yêu cầu cao và trì hoãn sửa lỗi, điều này chắc chắn sẽ làm tăng chi phí sửa chữa nó,

• Hoặc bạn sửa lỗi ngay bây giờ, cho rằng khách hàng sẽ thất vọng vì bạn quá chậm trong việc cung cấp tính năng họ cần rất nhiều.

Nếu lỗi không quan trọng lắm, trong khi tính năng là, quản lý sẽ có xu hướng yêu cầu thực hiện tính năng này trước, sau đó sửa lỗi. Kinh doanh khôn ngoan, đây là một lựa chọn hoàn toàn hợp lệ, theo như quản lý hiểu rõ hậu quả, nghĩa là sẽ khó khắc phục lỗi muộn hơn bây giờ.

Bám sát "không có tính năng mới cho đến khi tất cả các lỗi được sửa" có thể không phải là lựa chọn kinh doanh tốt nhất. Bạn đã đề cập đến những hạn chế của nó, vì vậy không cần phải giải thích nó.

Điều này đang được nói, nguy cơ để cho các tính năng rất quan trọng được thực hiện trước khi sửa các lỗi nhỏ có rủi ro: đặt giới hạn ở đâu? Là một tính năng được yêu cầu bởi 1 000 khách hàng quan trọng hơn một lỗi mà 100 khách hàng gặp phải? Làm thế nào để đánh giá liệu một tính năng nhất định có nên được thực hiện trước khi sửa một lỗi nhất định không?

Nếu không có các quy tắc nghiêm ngặt và nếu quản lý không hiểu rõ quá trình phát triển, bạn có thể thấy bản thân mình trong một vài năm tồn đọng đầy lỗi được coi là không đủ quan trọng để được sửa chữa trước một tính năng ưa thích khác.

Bên cạnh việc đi sâu vào các chi tiết cấp thấp cụ thể về tình huống của bạn, tốt hơn bạn nên đảm bảo rằng bạn đã có những thứ cơ bản, cơ bản ngay.

Về vấn đề này, tôi tin rằng điều rất quan trọng là chỉ ra rằng chính sách mà bạn đề cập, "lỗi luôn được ưu tiên cao hơn các tính năng", đặc biệt là từ này luôn đi lệch khỏi ít nhất hai trong bốn nguyên tắc được nêu trong Tuyên ngôn của Agile :

Các cá nhân và tương tác qua các quy trình và công cụ

Đáp ứng để thay đổi theo kế hoạch

Tôi không nhấn mạnh rằng bạn nên thay đổi chính sách, bởi vì tôi tin chắc rằng một người nên nhanh nhẹn về việc áp dụng các nguyên tắc nhanh nhẹn.

Nhưng ít nhất bạn nên nhận thức được khi bạn đi chệch hướng và hiểu liệu sự sai lệch có hợp lý hay không . Nói một cách đơn giản, tốt hơn là bạn chắc chắn rằng những gì bạn gọi là "nhanh nhẹn", không thực sự chuyển thành giả mạo vô nghĩa, vì vậy được bao quát một cách hùng hồn trong Tuyên ngôn Agile Half-Arsed :

Các cá nhân và tương tác qua các quy trình và công cụ
và chúng tôi có các quy trình và công cụ bắt buộc để kiểm soát cách các cá nhân đó (chúng tôi thích thuật ngữ 'tài nguyên') tương tác

Phần mềm làm việc trên tài liệu toàn diện
miễn là phần mềm đó được ghi lại toàn diện

Tất nhiên, sự hợp tác của khách hàng đối với việc đàm phán hợp đồng
trong phạm vi các hợp đồng nghiêm ngặt và chịu sự kiểm soát thay đổi nghiêm ngặt

Đáp ứng thay đổi theo kế hoạch
được cung cấp một kế hoạch chi tiết được đưa ra để đáp ứng với thay đổi và được thực hiện chính xác

Vì lợi ích của sự khó hiểu, không chỉ các nguyên tắc linh hoạt mà chính sách không có lỗi dường như đi chệch hướng.

Trong các dự án không nhanh nhẹn mà tôi tham gia, thường được coi là ... không khôn ngoan khi dành thời gian cho các lập trình viên để sửa các lỗi không đủ quan trọng để biện minh cho việc trì hoãn phát hành các tính năng ưu tiên cao.

Do đó, quản lý thường dành (có thể chính xác hơn để nói đã đầu tư ) một số nỗ lực để quyết định những lỗi nào có thể chờ đợi để phát hành tiếp theo.

• ^{Bạn có tình cờ làm việc trên phần mềm quan trọng nhiệm vụ? Tôi yêu cầu bởi vì trong trường hợp này, chính sách lỗi không có ý nghĩa khá tốt và đáng để thỏa hiệp các nguyên tắc nhanh nhẹn / không nhanh nhẹn / bất cứ nguyên tắc nào. Mặc dù tôi có thời gian khó khăn để cố gắng tưởng tượng quá trình nhanh nhẹn trong trường hợp này.}

Bạn biết đấy, trừ khi bạn làm việc trên phần mềm quan trọng, tôi sẽ khuyên bạn nên đánh giá kỹ hơn các kỹ năng và khả năng tư duy của quản lý.

Ý tôi là, từ những gì bạn mô tả, có vẻ như chúng chỉ đơn giản là không có khả năng để ưu tiên đúng các lỗi và tính năng. Nếu đây là trường hợp, nếu họ không thể xử lý một nhiệm vụ tương đối thường xuyên như vậy, thì họ không có khả năng gì khác? Cung cấp mức lương cạnh tranh? cơ hội phát triển nghề nghiệp? điều kiện làm việc?

Như bạn đã chỉ ra một cách chính xác, chính sách không có lỗi có nguy cơ các vấn đề không quan trọng bị bỏ qua hoặc bị đẩy xuống dưới tấm thảm, bởi vì bây giờ không phải là thời điểm tốt nhất để giải quyết chúng.

Những gì bạn có thể làm là, khi một vấn đề mới được báo cáo, đưa ra quyết định ba chiều:

1. Đây là một lỗi chính hãng và cần được sửa càng sớm càng tốt: đặt lên trên phần tồn đọng
2. Đây là một lỗi chính hãng, nhưng không quan trọng đối với chức năng của ứng dụng: biến nó thành một câu chuyện thông thường và để chủ sở hữu sản phẩm ưu tiên nó.
3. Đó không phải là một lỗi, hoặc đó là một bản sao hoặc nó không đáng để nỗ lực giải quyết: từ chối với lý do thích hợp.

Bằng cách này, các vấn đề ít quan trọng hơn sẽ không bị lãng quên hoàn toàn, nhưng chúng cũng không buộc tất cả các tính năng sáng bóng mới ra khỏi nước rút tiếp theo. 'Biến nó thành một câu chuyện' chỉ để ban quản lý có thể tiếp tục khẳng định bạn đang tuân theo chính sách không có lỗi và chủ sở hữu sản phẩm có thể cân bằng tầm quan trọng của vấn đề với tầm quan trọng của các tính năng trong hồ sơ tồn đọng.

Lưu ý rằng, với quy trình này, các vấn đề như thanh cuộn mà bạn đề cập có thể vẫn chưa được giải quyết vào cuối dự án, nhưng sau đó là vì không ai nghĩ rằng nó đủ quan trọng (kể cả khách hàng), không phải vì không có thời gian khi vấn đề được tìm thấy.

Tôi thích sơ đồ của bạn, tuy nhiên, như bạn đã xác định, nó chỉ cần một tinh chỉnh nhỏ để làm cho nó hoạt động - Như bạn đã thấy, thực tế thường là một tính năng mới hơn một sửa lỗi .....

Đề nghị của tôi là buộc ưu tiên lỗi tăng mỗi lần chạy nước rút. Hãy nói rằng bạn có một lỗi ở cấp độ 5 (thang điểm 1 cao, 5 = thấp). Nó bắt đầu là 5, 4 lần chạy nước rút sau, lỗi cấp 1 của nó. Tuy nhiên, tâm trí cần thiết cho tính toán ưu tiên là "Mức độ ưu tiên hiện tại - Số lượng Sprint", thay vì "Tăng mức độ ưu tiên của các lỗi còn tồn tại ở cuối mỗi lần chạy nước rút" - điều này ngăn mức độ ưu tiên được "đặt lại" xuống mức thấp hơn để trì hoãn hơn nữa.

Lỗi cấp 1 phải được giải quyết trong lần chạy nước rút tiếp theo ......

Rất đơn giản để giải thích, dễ thực hiện ....

Bây giờ, mức độ mà tính năng yêu cầu, có thể một tỷ lệ khác. Sau một thời gian, yêu cầu phải được xử lý - được thực hiện hoặc loại bỏ, ngăn chặn tồn đọng các tính năng không có giá trị ......

Bạn gặp rắc rối khi bạn cố gắng quá hiểu biết hoặc cố chấp về bất cứ điều gì trong phát triển phần mềm cũng như tất cả chúng ta thực sự muốn mọi thứ bị cắt và khô. Lỗi nên được sửa trước khi các tính năng mới được thêm vào, nhưng tôi vẫn sẽ xem xét tầm quan trọng của từng lỗi khi đưa ra quyết định này cùng với phạm vi của vấn đề. Có ngoại lệ cho tất cả mọi thứ.

Một số ứng dụng quá lớn, chúng có các phần hoàn toàn không liên quan. Tôi không thấy lý do tại sao mọi tính năng mới của mô-đun tài khoản phải trả phải được giữ lại, bởi vì có một vài lỗi khó chịu trong GUI lợi ích của nhân viên. Nếu một số phiền toái về bước GUI được đặt trong phần mua hàng của trang web công ty, hãy sửa nó, nhưng nhiều lỗi có thể không được sửa nếu tính năng được thêm vào là kết quả của bảo mật bổ sung, nhu cầu kinh doanh và đặc biệt là thay đổi quy định.

Khác với sự khác biệt lớn về thời gian và tài nguyên để hoàn thành một trong hai, tốt nhất là lấy một số đầu vào của người dùng / khách hàng. Nếu họ có thể sống với lỗi nếu điều đó có nghĩa là có được tính năng mới, hãy thêm tính năng này. Mục tiêu nên là để tránh lỗi chồng chất, vì vậy có một khoảng cách dừng. Tại một số điểm, nhiều vấn đề nhỏ trở thành một vấn đề lớn.

Viết bài kiểm tra để hiển thị lỗi khi chạy kiểm tra là một khởi đầu tốt để sửa lỗi. Nhưng khi cố gắng sửa các lỗi có mức độ ưu tiên ít nhất thì chúng ta nên suy nghĩ kỹ trước khi tiến hành. Tôi không có ý bỏ qua việc sửa nó. Nhưng chúng ta có thể sử dụng các tài nguyên không quan trọng để sửa các lỗi đó. Giả sử, trong nhóm của tôi, chúng tôi đào tạo các tài nguyên mới với các lỗi được ưu tiên ít nhất trong danh sách lỗi. Bằng cách này, chúng tôi có cơ hội đào tạo tài nguyên mới cũng như truyền niềm tin vào họ rằng họ đã sửa lỗi trong mục nhập vào ứng dụng. Điều này chắc chắn sẽ khiến họ tình nguyện cho nhiệm vụ ưu tiên tiếp theo.

Hi vọng điêu nay co ich :)