Является ли написание спецификаций для хобби-проектов единственным способом их завершения?

Question

Вот что мне интересно. Каждую ночь, когда наш 3-месячный ребенок дает нам спать, я прыгаю к компьютеру и начинаю кодировать свои хобби-проекты. У меня есть около 20 различных проектов, над которыми я работаю: различные типы проектов, от игр на C ++ до веб-приложений, а также некоторый вклад в проекты с открытым исходным кодом. Это действительно страсть, и это было в течение многих лет.

Тем не менее, когда я оглядываюсь назад, я вижу, что не смог полностью завершить один из моих хобби-проектов. Я всегда делал прототипы и настраивал самые важные функции, но со временем, вместо того, чтобы закончить свой проект, я в конечном итоге переключаюсь на другой проект, который на данный момент кажется «намного круче». Поэтому я обычно получаю глючные и неполные игры, в которых нет ни конца, ни истории, 3D-движков, которые имеют самую быструю процедуру PolygonDraw из всех когда-либо существовавших, но при этом им не хватает реализации чего-либо еще и т. Д. Список длинный. Я думаю, что я, должно быть, написал незаконченный Понг более чем в сто раз!

Мне сказали, что для этого нужно написать спецификации для моих хобби-проектов.

С одной стороны, я пишу много спецификаций на работе. Я знаю, насколько они важны для определения дорожной карты продукта и соблюдения графика. С другой стороны, спецификации и хобби-проект, похоже, совсем не согласны! Мне кажется, что кривая обучения созданию игры - это то, что делает ее интересной; не сама игра. Отсюда удовольствие от потери времени на реструктуризацию всего движка, удовольствие от создания самых бесполезных функций и так далее ...

Итак, возникает вопрос: вы когда-нибудь писали спецификации для своих хобби-проектов? Чем они отличаются от работы? Как вам удается завершить свои хобби проекты?

Я был бы рад узнать, работая над моим новым проектом: генератором сонаты для фортепиано:)

Answer 1

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

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

Если на самом деле у вас нет пользователей, тогда не расстраивайтесь из-за отказа от проекта - если никто не заинтересован, его, вероятно, не стоит преследовать.

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

Answer 2

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

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

Безболезненные функциональные характеристики

К сожалению, у меня не хватило смелости попытаться сделать мои спецификации более интересными для чтения на работе.

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

Answer 3

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

Я заканчиваю примерно половину того, что начинаю.

Answer 4

Статья Джоэла о доказательном планировании работает для меня. Хотя я реализовал это по-другому.

Идея состоит в том, чтобы разбить проект на небольшие задачи и дать сметы, а затем сделать прогноз, когда ваш проект будет завершен, исходя из времени, которое потребовалось завершенным задачам для их завершения.

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

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

Плюс: создайте то, что вы будете использовать позже. Использование вещей дает вам стимул улучшить его позже.

Answer 5

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

Это трудно работа . Может показаться, что ваша программа выполнена на 90%. Но выполнение этих последних 10% (устранение всех ошибок, обеспечение качества приложения, написание документации и т. Д.) Требует столько же работы, сколько и первые 90%. И если вы хотите серьезно относиться к маркетингу своей программы, отвечать на письма поддержки, исправлять ошибки других людей, это еще большая работа. И, возможно, не тот вид работы, который вас больше всего интересует.

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

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

Несколько советов:

• Убедитесь, что вы действительно хотите завершить проект. То есть, награды стоят всей тяжелой работы. (Если нет, то примите этот факт и оставайтесь счастливым мастером.)

• Найдите способы мотивировать себя через «скучные» части. Спецификации, может быть, если это поможет вам сосредоточиться. Но найдите то, что работает для вас, будь то тикирование предметов, награждение себя печеньем или мечта о славе и богатстве.

• Выпуск рано, выпуск часто. Чем больше вы сэкономите для «большого релиза», тем больше вероятность того, что этот релиз никогда не случится.

• Первый выпуск, затем переписать. Когда вы почувствуете желание сделать основную переписку, сначала выполните выпуск, а затем переписать (если вы все еще готовы к этому). Программное обеспечение никогда не бывает идеальным. Если вы стремитесь к совершенству без какого-либо давления, чтобы выпустить свой недоделанный (но уже существующий) код, то у вас ничего не получится.

Answer 6

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

Answer 7

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

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

Answer 8

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

В данный момент я работаю над улучшением своих навыков SQL, и я трачу много свободного времени между написанием запросов и записью своего опыта. После нескольких настроек у меня был приличный документ с описанием того, что нужно было сделать.

Answer 9

У меня такая же проблема. Одна вещь, которую я заметил, что помог, хотя, понижает мои амбиции. как WAY WAY low. Написание спецификации - это один из способов реализовать амбиции, если у вас есть какое-то ограничивающее правило для спецификации, например «Спецификация может быть только одной страницей», или «спецификация может быть длиной не более 300 слов», или «Spec только то, что я могу сделать за один день кодирования». Правильный баланс может потребовать некоторой практики. Если вы идете с последним лимитом, вы можете наложить правило ОБЯЗАТЕЛЬНОГО увольнения проекта, если вы не можете закончить его за один день.

Самое приятное в этом то, что он ограничивает вас достижимыми целями. Поначалу это может звучать глупо или неправильно. Или, может быть, это звучит разумно, но вы просто не можете с этим поделать, вы хотите делать удивительные вещи, а не обычные вещи! Не мелочи, которые можно сделать за несколько часов!

но имейте это в виду:

«Сложная система, которая работает неизменно установлено, что эволюционировал из простая система, которая работала. обратное утверждение также представляется правда: сложная система, разработанная из царапина никогда не работает и не может быть сделана работать. Вы должны начать все сначала, начиная с простой работы система.»

—Джон Галл

Гораздо проще сделать этот амбициозный проект, если у вас уже есть ЗАВЕРШЕННЫЙ и РАБОЧИЙ проект, на котором он может быть основан. Тогда «более сложная вещь» МОЖЕТ быть проектом, который подходит в течение дня. Это идеал и философия, над которой я работаю, потому что я думаю, что у нее больше шансов на успех. Глядя на прошлые успешные проекты, подавляющее большинство из них развивались именно таким образом, независимо от того, было ли это намеренным или нет.

Answer 10

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

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

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

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

Я не особенно опытен, все еще учусь, но именно так я продолжаю заниматься своими делами (иногда, если не сталкиваюсь с общей причиной блока из-за неопытности) и как я в прошлом подходил ко многим мультимедийным и веб-проектам на основе хобби года. Хотя парень, который сказал «с открытым исходным кодом», когда вам скучно, и пусть кто-то другой подхватит его, была бы хорошей идеей, если вы хотите, чтобы ваш код использовался, но достигли ваших личных целей.