Какой процесс разработки программного обеспечения одинокий разработчик должен иметь? [закрытый]

1. Используйте Source Control для ВСЕГО
2. Разработайте спецификации и получите одобрение перед запуском - сопротивление будет, но объясните это для их же блага.
3. Модульные тесты! Это больно, потому что вы просто хотите сделать это, но это спасет вас в долгосрочной перспективе.
4. Используйте отслеживание ошибок - Bugzilla или FogBugz, если можете себе это позволить.

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

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

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

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

edit

И, как сказал lod3n, контроль версий, но вы уже используете это правильно ???! !?!

Был там, сделал это.

Книга Планирование экстремального программирования очень помогла. Я использовал карты 3х5, наклеенные на стену. Это держало моего босса в курсе моих успехов, помогало с оценками и планированием и держало меня в курсе. Игра в планирование дает хорошие боеприпасы, если ожидания вашего босса нереалистичны.

Модульное тестирование, как утверждали другие, помогает, даже если вы единственный разработчик. Я считаю, что стиль TDD ценен.

lod3n абсолютно прав в отношении управления версиями.

Я уже использовал итерации в стиле XP; вы также можете создать список незавершенных предметов (даже что-то простое, например, электронную таблицу или карты 3x5).

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

Иметь систему отслеживания ошибок, как для дефекты и новые функции. Не полагайтесь на свою память.

Непрерывная интеграция и автоматическая сборка могут помочь даже одному разработчику.

Трудно выделить рекомендацию по контролю версий.

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

Как бы безумно это ни звучало, я использую scrum только потому, что мне нравятся концепции спринтов и задержек. Это упрощает постановку реалистичных целей. Конечно, идея мастера схватки и команды - это все, что вам нужно, но если вы работаете над внешними проектами, где возможно, что вы можете подобрать дополнительного члена команды с вашими невыполненными заданиями, будет легко распределить работу. Может, мне просто нравятся отставания. С помощью Scrum вам нужно будет попросить кого-нибудь стать менеджером по продукту, чтобы он рассказал об особенностях продукта. Контроль версий является обязательным и, вероятно, должен быть реализован b4, даже беспокоясь о процессе разработки программного обеспечения. Я работал в компании, которая начиналась с 2 разработчиков и перешла к 12 за год. Мы начали без контроля версий и с низкими стандартами кодирования. Изменения, которые вам нужно будет внести, будут постепенными, поэтому не беспокойтесь о том, чтобы торопиться делать 180.

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

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

Затем есть собственно процессы разработки. Я всегда рекомендовал бы иметь процесс, независимо от того, мала ли команда или большая. Хитрость в том, чтобы найти правильный процесс. Теперь у вас есть процесс - это просто случайный процесс, который, похоже, не работает для вас слишком хорошо. Редко можно взять процесс разработки учебника и применить его непосредственно. Что вам нужно сделать, так это адаптировать процесс к потребностям и культуре вашей компании. Посмотрите на как можно больше парадигм разработки и попытайтесь найти что-то, что подходит, и они начнут формировать это в соответствии с вашими потребностями. Возможно, вам придется попробовать и потерпеть неудачу с рядом различных процессов. Возможно, процесс персонального программного обеспечения станет хорошим стартовым процессом, а может быть, гибким процессом, вариантом RUP? У вас есть много вариантов, начните их пробовать.

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

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

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

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

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

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