Bạn làm gì khi có yêu cầu vào phút cuối để loại trừ một tính năng khỏi bản phát hành?

Có một tính năng đã vượt qua thử nghiệm chấp nhận, cả nội bộ và khách hàng. Đây là một tính năng làm việc đầy đủ. Tuy nhiên, hiện đã có yêu cầu loại trừ tính năng này khỏi bản phát hành sắp tới. Theo khách hàng, tính năng này nên được gỡ bỏ vì người dùng chưa được đào tạo về cách sử dụng nó.

Quá trình hành động tốt nhất để xử lý tình huống này là gì? Chúng ta có nên thiết kế phần mềm để dự đoán rằng một tính năng có thể được loại trừ vào phút cuối bằng cách sử dụng cài đặt cấu hình không? Có giải pháp phụ thuộc vào ngữ cảnh nào có thể đúng hơn trong một số tình huống so với các giải pháp khác không?

1. Xóa tài liệu cho tính năng;
2. Vô hiệu hóa giao diện cho tính năng (ẩn các mục menu hoặc xóa tùy chọn khỏi lệnh console).

Mọi thứ khác đều quá nguy hiểm.

Chủ lao động trước của tôi bán một số phần mềm kích hoạt các tính năng khác nhau dựa trên giấy phép cụ thể có liên quan. Vì vậy, khả năng bật / tắt các tính năng trong thời gian chạy là một tính năng được thiết kế. Nói chung, mọi người gọi đây là "phát triển theo hướng tính năng" ( bài viết trên wikipedia , cuốn sách hay về chủ đề này ). Nó đòi hỏi rất nhiều thử nghiệm để tìm ra các lỗi có thể gây ra bằng cách bật và tắt các tính năng. Vì hầu hết mọi người trong văn phòng đều tạo khóa cấp phép cho tất cả các tính năng, nên các khả năng tính năng hạn chế có xu hướng được sử dụng kém (và trong nhiều lần, không được kiểm tra cho đến khi khách hàng gọi đến bàn trợ giúp).

Đối với "sửa" vào phút cuối của bạn thì giải pháp nhanh nhất sẽ là ẩn các lệnh menu / phím nóng / nút bật tính năng này. Điều này sẽ giới thiệu các lỗi khác . Hãy thẳng thắn với khách hàng và quản lý dự án của bạn.

Tôi sẽ không bao giờ viết mã sao cho các tính năng có thể bật hoặc tắt - trừ khi yêu cầu đó được đưa ra phía trước.

Xóa hoặc vô hiệu hóa một tính năng là một thay đổi đối với thông số kỹ thuật và giống như bất kỳ thay đổi thông số kỹ thuật nào khác, cần có thời gian để thực hiện và xác minh. Bạn cần hỏi tại sao tính năng này sẽ bị loại trừ - nó vẫn còn quá lỗi để phát hành? Có phải khách hàng không muốn tính năng đó không? Có một số lý do kinh doanh để trì hoãn các tính năng?

Đặc biệt trong trường hợp tính năng được cho là "quá lỗi" được phát hành, bạn cần cảnh giác liệu tính năng đó có phải là "lỗi" hay không, liệu nó có thực sự là bản phát hành chưa sẵn sàng để phát hành hay không tính năng cụ thể đó chỉ là vấn đề mà các vấn đề xuất hiện nhiều nhất - trong trường hợp đó, vô hiệu hóa tính năng đó sẽ không giúp bạn nhiều ...

Chúng tôi trả lời các yêu cầu vào phút cuối bằng cách thảo luận về sự thay đổi quan trọng đối với khách hàng. Thực hiện các thay đổi lớn ngay trước khi triển khai làm mất hiệu lực toàn bộ giai đoạn thử nghiệm và chấp nhận, vì vậy chúng tôi sẽ chuyển yêu cầu thay đổi sang bản phát hành sau hoặc chuyển ngày ra mắt để có thể kiểm tra chính xác thay đổi vào phút cuối (khách hàng thường chọn chuyển thay đổi sang bản phát hành tiếp theo khi họ biết rằng giải pháp thay thế là chuyển ngày ra mắt :-))

Chức năng tùy chọn là tốt nhất (imho) bật / tắt thông qua cấu hình. Giống như bạn đề cập đến điều này phải được thiết kế từ đầu.

Tôi đã phải làm điều này trong quá khứ, đôi khi với các tính năng đã đưa nó vào sản xuất và hóa ra là một thảm họa. Tôi đã làm tất cả những điều sau đây.

1) Thay đổi cấu hình để tắt tính năng. Hoạt động ở nơi có thể định cấu hình 2) Tắt / xóa tất cả các thực thể UI kích hoạt tính năng này. 3) Vô hiệu hóa mã trong tính năng để nó không làm gì (nhưng dường như hoạt động) Phải làm điều này khi chúng tôi không có quyền truy cập vào mã vỏ gui.

Về việc bạn nên thiết kế khả năng bật hay tắt tính năng, tôi sẽ nhìn vào bức tranh lớn hơn và xem cách bạn thêm các tính năng hiện tại. Đây không phải là một bước tiến lớn để biến các tính năng thành các mô-đun bị phát hiện động nhất. Tôi thích mô-đun, vì vậy tôi có xu hướng đi theo cách này.

Đôi khi bạn có thể làm cho một tính năng không thể truy cập như một cách giải quyết ngắn hạn, dễ dàng hơn mà thực sự loại bỏ nó. Kiểm tra xem có thể chấp nhận được các tạo tác có thể nhìn thấy hay không (ví dụ: các nút và tùy chọn menu có thể nhìn thấy nhưng bị vô hiệu hóa).

Bạn nên thực hiện một tính năng dễ dàng có thể chuyển chỉ nếu đó là một yêu cầu mà người dùng / quản trị viên có thể chuyển đổi các tính năng on / off.

Nếu nó đủ dễ để bạn không phải làm điều đó trong dự đoán, thì có lẽ cũng dễ làm như vậy khi bạn biết nó cần thiết, và hơi dễ dàng hơn để loại bỏ nó ra.

Nếu bạn không thể tắt tính năng này mà không có rủi ro đáng kể khi giới thiệu các lỗi mới, hãy nói với mọi người điều đó. Mặt khác, về cơ bản, bạn đang tình nguyện trở thành vật tế thần khi các vấn đề không thể tránh khỏi xảy ra, mặc dù vấn đề thực sự là bất cứ điều gì dẫn đến yêu cầu vào phút cuối này thay đổi.

Dựa trên các chỉnh sửa của bạn, tôi sẽ đoán đây là một tính năng không thể thiếu. Loại bỏ nó có thể có tác động đến các bộ phận khác của hệ thống. Thực sự, khách hàng không nên mong đợi có thể yêu cầu thay đổi cơ bản cho hệ thống mà không phải chịu bất kỳ chi phí nào. Các chi phí trong trường hợp này là để bạn bằng cách nào đó vô hiệu hóa điều này (có thể chỉ bằng cách nhận xét các dòng mã lớn) và sau đó kiểm tra lại để đảm bảo rằng mọi thứ đã bị hỏng.

Cách đơn giản nhất để "vô hiệu hóa" một tính năng như thế này sẽ là xóa / nhận xét các điểm nhập cảnh ở mức cao nhất. Ví dụ: nếu điểm vào duy nhất cho tính năng là một nút trên Giao diện người dùng, chỉ cần nhận xét dòng tạo nút. Nếu có nhiều điểm vào, bạn có thể phải đào sâu hơn để vô hiệu hóa nó.

Phụ thuộc rất nhiều vào nếu nó là lỗi nguy hiểm / hỏng / không mong muốn

Nếu nó không thể làm bất cứ điều gì không an toàn và họ chỉ loại trừ nó vì lý do dễ sử dụng, thiếu tài liệu đào tạo hoặc vì nó bị hỏng, chúng tôi thường chỉ xóa điểm vào tính năng đó khỏi UI và để mọi thứ khác vào vị trí.

Nếu nó là lỗi nguy hiểm, chúng tôi làm điều đó và thêm các ngoại lệ rõ ràng trong logic kinh doanh cốt lõi để nó không thể được thực thi.

Điều tồi tệ nhất là nơi tính năng không mong muốn (ví dụ thay đổi quy định làm cho khái niệm bất hợp pháp) và tất cả các tham chiếu đến tính năng phải được xóa hoàn toàn.

Khi bạn di chuyển xuống danh sách, khả năng xảy ra lỗi sẽ tăng lên. tùy thuộc vào tình huống của bạn, hai lựa chọn đầu tiên hoặc đầu tiên có thể là thứ gì đó có thể được cung cấp nhanh chóng, thứ ba gần như không bao giờ.

Đối với việc thiết kế các tính năng chuyển đổi, trừ khi khách hàng muốn rằng tôi thường không đi theo hướng đó cho đến khi khách hàng đã chứng minh lịch sử đưa ra lựa chọn quá muộn đó.

Giả định của tôi là ban quản lý đã bán tính năng này dưới dạng tiện ích trả phí và vào phút cuối, khách hàng nói rằng họ không muốn trả tiền cho tiện ích bổ sung (có thể nhận ra rằng nó không đáng tiền).

Theo quan điểm đó, quản lý sai lầm.

Tôi đã làm việc với một số hệ thống trong đó quyền truy cập tính năng được điều khiển bởi cài đặt bảo mật. Điều này làm cho loại tính năng này vô hiệu hóa tương đối tầm thường. Chỉ không kích hoạt tính năng cho bất kỳ nhóm bảo mật nào. Trừ khi tính năng được kích hoạt cho tất cả, việc kiểm tra với nó bị vô hiệu hóa sẽ được thực hiện.

Các tính năng khác có thể bị vô hiệu hóa dễ dàng được gắn với các giá trị mã. Chúng thường xử lý một trường hợp cụ thể của một cái gì đó như sản phẩm, khách hàng hoặc bất cứ thứ gì. Vô hiệu hóa các tính năng này có thể được thực hiện bằng cách không kích hoạt (các) giá trị mã liên quan.

Như những người khác đã lưu ý, một số tính năng có các điểm nhập UI cụ thể có thể bị xóa. (Các trường hợp trên có thể là trường hợp đặc biệt của điều này.). Xóa (các) điểm vào sẽ cho phép bạn gửi tính năng mà không cho phép truy cập. Đây thường là cách ít rủi ro nhất để xử lý trường hợp này.

Nếu các tính năng được phát triển trên các nhánh tính năng, bạn sẽ có thể xóa bỏ hợp nhất nhánh tính năng và kiểm tra lại. Điều này nên đơn giản hơn các phương pháp vô hiệu hóa mã khác. Tạo một bản vá loại bỏ tính năng sẽ đơn giản hóa việc kích hoạt lại tính năng này sau. Điều này cung cấp cho bạn một tương đương thô của một nhánh tính năng.