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

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

Если вы просто «программируете для развлечения», тогда хорошо, у вас все получается. Я не думаю, что писать спецификации - это весело.

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

Это все о «Самостоятельном управлении проектами» ... даже для развлечения.

Я сочувствую вам ... Раньше у меня было много репозиториев, которые, как правило, застревали на уровне 200 или около того.

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

Я научился писать свои собственные спецификации для личного использования

to

1. Дайте мне сосредоточиться, чтобы выполнить свою работу, а не уходить в полосу особого крипа.
2. Напомни мне, над чем я работаю
3. Чтобы иметь отличные идеи до того, как я начну писать код
4. Держите вещи веселее в течение более длительного времени

Для меня жизненно важно написание собственных спецификаций!

Вы бы не начали бизнес без плана, не так ли?

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

BIG EDIT: стремление к личной эффективности и завершению проектов. Я прочитал «Как все делается» ... Несмотря на всю хипповскую чушь о «психике» и различных уровнях разума (которые, я уверен, не основаны ни на какой науке), советы очень хорошие.

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

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

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

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

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

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

Это всего лишь мой личный опыт, и я считаю, что вам стоит попробовать. Надеюсь, вам это тоже пригодится.

Я смог выполнить несколько хобби-проектов и закончить некоторые из них. Я пытаюсь закончить их все, но некоторые просто не могу собрать.

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

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

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

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

Иногда лучший способ сделать это - просто сделать это.

Зе Франк объясняет это намного лучше меня: http://www.zefrank.com/theshow/archives/2006/07/071106.html (ссылка на видео с руганью)

РЕДАКТИРОВАТЬ: просто добавить. Если вы обнаружите, что хотите оставить незавершенный проект ради новой грандиозной идеи ... сделайте это! Не оглядывайся!

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

Причина, по которой вы начали, была из-за страсти. Это очень важно. Не стоит заставлять себя «выкладываться» в свободное время. Вы истощите свою страсть, которая является вашим самым важным ресурсом.

Я обычно пишу первый набор спецификаций, когда начинаю.

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

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

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

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

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

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

Единственное лучшее, что я когда-либо находил, чтобы помочь приблизиться к завершению, - это то, что кто-то другой работает над проектом вместе с вами. Найдите друга (или двух), который интересуется одним и тем же, и разработайте / закодируйте его вместе с ними. У вас есть не только кто-то, от кого можно оттолкнуть идеи, но и кто-то, кто вас мотивирует, не говоря уже о том, что прогресс в два раза быстрее, так что вы, надеюсь, закончите, прежде чем сдадитесь :)

Конечно, для этого требуется контроль версий, но вы уже использовали это в своих проектах, верно? :)

Вы хотите закончить их?

Я считаю разумным никогда не заканчивать хобби-проект. Вы можете просто продолжать работать над этим, пока живете. Aciddose годами работал над своим виртуальным инструментом xhip, упорно не доходя до 1.0, заставляя инструмент исправлять программы людей от одного выпуска к другому, ничего не стоящего. Тем не менее, он и пользователи его софтсинта, похоже, отлично проводят время.

Может быть, если вы просто будете стремиться к «освобождению», а не «закончить», вы будете более удовлетворены. Бета-версии позволяют продолжать мечтать.

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

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

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

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

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

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

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

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

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

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

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

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

Краткий ответ: разработка спецификаций для хобби-проекта не является ни необходимой, ни достаточной для гарантии завершения.

Что, как говорится...

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

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

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

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

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

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

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

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

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

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

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

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

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

—Джон Галл

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

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

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

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

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

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

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

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

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

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

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

• Найдите способы мотивировать себя "скучными" частями. Технические характеристики, возможно, если это поможет вам сосредоточиться. Но найдите то, что работает для вас, будь то тиканье заданий, награждение себя печеньем или мечты о славе и богатстве.

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

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

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

Мне подходит статья Джоэла о составлении расписаний на основе фактов. Хотя я реализовал это иначе.

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

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

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

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