Как вы знаете, когда прекратить добавлять функции?

Некоторое время назад я написал очень маленький скрипт на python, который периодически проверял xml-фид на наличие новых записей и предупреждал пользователя о новых записях, когда они присутствуют. Я написал это для себя, так что, по сути, это была консольная программа, которую мог использовать любой, кто знаком с интерфейсом консоли.

Через некоторое время я решил, что это может быть более полезным для других людей, и начал приводить его в порядок, очищать входные данные, удалять ошибки. Мне пришло в голову, что, поскольку я написал сценарий, я знал, как использовать его эффективно, аккуратно и т. Д. Другие не могли, поэтому я начал добавлять графический интерфейс. Это началось с простого меню, а затем расширилось до более полного графического интерфейса с интерфейсом и меню опций. Затем я добавил сохраненные пользовательские настройки, а также хранилище для ранее найденных XML-каналов, чтобы ускорить повторный поиск.

Я добавил протоколирование, чтобы помочь отладить приложение на случай, если что-то пойдет не так, довел приложение до последней доступной стабильной базы кода Python для выбранной платформы и улучшил функции диалога.

Я исправил ошибку и прокомментировал свой код, и все же у меня все еще есть вещи, которые, я думаю, можно сделать, чтобы улучшить приложение, прежде чем я сделаю его доступным для альфа-тестеров. Это очень далеко от моего оригинального сценария из 20-30 строк. То, что я ожидал, заняло бы у меня всего час или два, чтобы перейти от проверки концепции к программе приемлемого использования, что заняло в 10-20 раз больше. (Я все еще новичок, и вещи занимают у меня много времени, но все же ....)

Как вы знаете, когда прекратить добавлять / настраивать / исправлять вещи и позволить вашему ребенку выползать на открытом воздухе?

Когда вы попали в срок.

Если у вас нет срока, это ваша проблема ...

Вот как я работаю:

1. Я добавляю новые функции / ошибки в мой журнал.
2. Я расставляю приоритеты всего портфеля продуктов по стоимости бизнеса и оценкам (последнее не обязательно в случае личного проекта).
3. Я выделяю рабочее время для себя. Дата выпуска - конец того времени.
4. Я начинаю с самого первого в списке. Я работаю над функцией время. Чтобы завершить, функция должна быть действительно полной, включая документацию (в конце функции я могу отправить продукт).
5. Я беру следующий, пока мое выделенное время не будет использовано.
6. Если время, затрачиваемое на создание объекта, расходуется, я временно его отбрасываю.
7. Когда выделенное время израсходовано, я беру последнюю сборку и делаю с ней релиз.
8. Я повторяю процесс из пункта 1.

Сделайте SRS, а затем код в соответствии с требованиями. Когда вы достигли всех целей, упомянутых в SRS, пришло время остановиться и протестировать ваш продукт.

В краткосрочной перспективе, когда у вас есть что-то, что работает надежно и не выходит из строя. Даже если он не делает все, что мог , если бы вы работали над ним бесконечно. Доставка, как говорится, это особенность . Надежность и ограниченный набор функций дают вам возможность протестировать основную функциональность на реальных людях в реальном мире, которые найдут вещи, о которых вы никогда не думали, которые нарушают ваш код таким образом, что вам никогда не придет в голову. На данный момент, чем меньше у вас возможностей, тем легче будет устранить эти ранние проблемы. Поскольку базовая функциональность работает более надежно, вы можете приступить к реализации других полезных вещей, зная, что ваш самый важный и центральный код все еще работает хорошо.

В долгосрочной перспективе: После того, как вы завершили и задокументировали систему плагинов, которая позволит вашим пользователям (и, конечно, вам) быстро и легко внедрять новые функции, если они вам нужны. Это должна быть последняя функция, которую нужно добавить - после этого все плагины.

Если вы уверены в стабильности своего программного обеспечения, перейдите к выпуску, хотя возможны ожидающие функции. Стабильность важнее, чем функции. Получите обратную связь, подключитесь к существующим функциям и решите, что будет дальше и когда!

Вы всегда можете продвигать проект навсегда.

Очень хорошее правило заключается в том, что вы никогда не должны добавлять вещи, которые не соответствуют утвержденному варианту использования. Это гарантирует, что у вас не будет много вещей, которые было бы неплохо иметь, но которые никто не использует. Утверждение гарантирует, что другие, чем вы, согласны с тем, что это необходимо в вашем проекте.

Это зависит от того, почему вы добавляете функции. Владельцы проекта просят об этом? пользователей? QA? Программисты?

• Добавьте функции, которые вы должны.
• Просеять через функции, которые важны.
• Игнорируйте особенности, которые приятно иметь.

Сосредоточьтесь на цели программы и сделайте ее целенаправленной. Запросы на функции, которые расширяют его назначение, должны быть тщательно опрошены, прежде чем он станет швейцарским армейским ножом.

Я не прекращаю добавлять функции больше. Я просто пытаюсь получить приложение как можно скорее и писать текстовые файлы, если мне нужно. Тогда я могу решить, когда остановиться и когда работать над чем-то другим

Также помогает то, что мне нравится делать минимум возможного, чтобы что-то сделать (не прибегая к взлому).

Я бы предложил вам это. Дайте себе сказать неделю. Создайте список работ, которые нужно выполнить в течение этой недели, и убедитесь, что если у вас есть функция, которую вы не можете выполнить, вы можете отменить ее.

В конце недели отпустите его. Выпуск рано, выпуск часто.

Когда у вас есть что-то надежное и полезное, отпустите. Вам не нужно прекращать добавлять функции, но если кто-то использует то, что у вас есть, вы получите гораздо лучшее представление о том, какие функции нужны. В настоящее время вы угадываете.