Làm thế nào để bạn biết khi nào ngừng thêm tính năng?

Cách đây một thời gian, tôi đã viết một tập lệnh python rất nhỏ, định kỳ kiểm tra nguồn cấp dữ liệu xml cho các mục mới và cảnh báo người dùng về các mục mới khi có mặt. Tôi đã viết cái này cho chính mình, vì vậy nó thực chất là một chương trình dựa trên giao diện điều khiển mà bất kỳ ai thoải mái với giao diện điều khiển đều có thể sử dụng.

Sau một thời gian, tôi quyết định nó có thể được sử dụng nhiều hơn cho người khác và bắt đầu dọn dẹp nó, vệ sinh đầu vào, loại bỏ lỗi. Tôi nhận ra rằng vì tôi đã viết kịch bản nên tôi biết cách sử dụng nó một cách hiệu quả, chính xác, v.v. Những người khác có thể không, vì vậy tôi bắt đầu thêm GUI. Điều này bắt đầu như một menu đơn giản, và sau đó mở rộng sang GUI đầy đủ hơn với cả giao diện và menu tùy chọn. Sau đó tôi đã thêm tùy chọn người dùng được lưu trữ và cũng lưu trữ cho các nguồn cấp dữ liệu xml được tìm kiếm trước đó để tăng tốc độ tìm kiếm lặp lại.

Tôi đã thêm ghi nhật ký để giúp gỡ lỗi ứng dụng trong trường hợp xảy ra sự cố, đưa ứng dụng lên cơ sở mã trăn ổn định mới nhất có sẵn cho nền tảng đã chọn của tôi và các tính năng hộp thoại được cải thiện.

Tôi đã sửa lỗi và nhận xét mã của mình một cách rõ ràng, nhưng tôi vẫn có những điều tôi nghĩ có thể được thực hiện để cải thiện ứng dụng trước khi tôi cung cấp nó cho những người thử nghiệm alpha. Nó khác xa so với kịch bản dòng 20-30 ban đầu của tôi. Những gì tôi dự đoán sẽ khiến tôi mất chỉ một hoặc hai giờ để đi từ bằng chứng về khái niệm sang một chương trình sử dụng chấp nhận được đã mất 10-20 lần. (Tôi vẫn là một người mới và công cụ này khiến tôi mất nhiều thời gian, nhưng vẫn ....)

Làm thế nào để bạn biết khi nào nên dừng thêm / điều chỉnh / sửa chữa các công cụ và để em bé của bạn bò ra ngoài trời?

Khi bạn đạt đến thời hạn.

Nếu bạn không có thời hạn, đây là vấn đề của bạn ...

Đây là cách tôi làm việc:

1. Tôi thêm các tính năng / lỗi mới trong sản phẩm tồn đọng của tôi.
2. Tôi ưu tiên toàn bộ sản phẩm tồn đọng trên giá trị doanh nghiệp và ước tính (cuối cùng là tùy chọn trong trường hợp dự án personnal).
3. Tôi phân bổ thời gian làm việc cho bản thân mình. Ngày phát hành là kết thúc thời gian đó.
4. Tôi bắt đầu với đầu tiên trong danh sách. Tôi làm việc trên một tính năng một thời gian. Để được hoàn thành, một tính năng phải thực sự hoàn chỉnh bao gồm cả tài liệu (ở cuối tính năng, tôi có khả năng có thể giao sản phẩm).
5. Tôi lấy cái tiếp theo cho đến khi hết thời gian được phân bổ.
6. Nếu thời gian được sử dụng khi tôi xây dựng một tính năng, tôi sẽ loại bỏ tính năng này theo thời gian.
7. Khi thời gian được phân bổ được sử dụng, tôi lấy bản dựng mới nhất và phát hành cùng với nó.
8. Tôi lặp lại quá trình từ điểm 1.

Tạo một SRS sau đó mã theo các yêu cầu. Khi bạn đã đạt được tất cả các mục tiêu được đề cập trong SRS, đã đến lúc dừng lại và kiểm tra sản phẩm của bạn.

Trong ngắn hạn, khi bạn có một cái gì đó hoạt động đáng tin cậy và không bị hỏng. Ngay cả khi nó không làm mọi thứ nó có thể làm nếu bạn làm việc đó vô thời hạn. Vận chuyển như đã nói là một tính năng . Độ tin cậy và bộ tính năng bị hạn chế cung cấp cho bạn cơ hội để chức năng cốt lõi được kiểm tra bởi những người thực trong thế giới thực, những người sẽ tìm thấy những thứ mà bạn không bao giờ nghĩ rằng sẽ phá vỡ mã của bạn theo những cách không bao giờ vượt qua tâm trí bạn. Tại thời điểm này, bạn càng có ít tính năng, bạn càng dễ dàng khắc phục những sự cố ban đầu đó. Vì chức năng cốt lõi hoạt động đáng tin cậy hơn, bạn có thể bắt đầu triển khai các công cụ "tốt đẹp khác" với kiến ​​thức rằng mã trung tâm và quan trọng nhất của bạn vẫn hoạt động tốt.

Về lâu dài: Khi bạn đã hoàn thành và ghi lại hệ thống trình cắm sẽ cho phép người dùng của bạn (và tất nhiên là bạn) triển khai các tính năng mới một cách nhanh chóng và dễ dàng nếu bạn cần chúng. Đó phải là tính năng cuối cùng bạn cần thêm - sau đó là tất cả các plugin.

Khi bạn chắc chắn về tính ổn định của phần mềm, hãy phát hành mặc dù có thể có các tính năng đang chờ xử lý. Sự ổn định quan trọng hơn các tính năng. Nhận phản hồi, kết hợp với các tính năng hiện có và quyết định những gì sẽ được cung cấp tiếp theo và khi nào!

Bạn luôn có thể chăm sóc một dự án mãi mãi.

Một quy tắc rất tốt là bạn không bao giờ nên thêm những thứ không có trong trường hợp sử dụng được phê duyệt. Điều này đảm bảo rằng bạn sẽ không có nhiều thứ tốt đẹp để có, nhưng không ai sử dụng. Phê duyệt đảm bảo rằng những người khác hơn bạn đồng ý rằng điều này là cần thiết trong dự án của bạn.

Nó phụ thuộc vào lý do tại sao bạn thêm các tính năng. Là chủ dự án yêu cầu nó? người dùng? QA? Lập trình viên?

• Thêm các tính năng bạn có.
• Chọn lọc thông qua các tính năng quan trọng.
• Bỏ qua các tính năng là tốt đẹp để có.

Tập trung vào mục đích của chương trình và làm cho mục đích của nó tập trung. Các yêu cầu tính năng mở rộng mục đích của nó nên được đặt câu hỏi kỹ lưỡng trước khi nó trở thành một con dao quân đội Thụy Sĩ.

Tôi không ngừng thêm các tính năng nữa. Tôi chỉ cố gắng đưa ứng dụng ra khỏi đó càng sớm càng tốt và viết các tệp txt nếu tôi cần. Sau đó tôi có thể quyết định khi nào nên dừng lại và khi nào nên làm việc gì đó khác đi

Nó cũng giúp tôi thích làm việc tối thiểu có thể để hoàn thành công việc (mà không cần dùng đến hack).

Tôi muốn đề nghị bạn timebox nó. Cho mình một tuần nói. Tạo một danh sách công việc cần hoàn thành trong tuần đó và đảm bảo nếu bạn có một tính năng bạn không thể hoàn thành, bạn có thể sao lưu nó.

Vào cuối tuần phát hành nó. Phát hành sớm, thường xuyên phát hành.

Khi bạn đã có một cái gì đó đáng tin cậy và hữu ích, phát hành. Bạn không cần phải ngừng thêm tính năng, nhưng nếu có ai sử dụng những gì bạn đã nhận được ở đó, bạn sẽ hiểu rõ hơn về những tính năng nào muốn có. Hiện tại, bạn đang đoán.