Методологии жизненного цикла программного обеспечения для команд One Man [закрыт]

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

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

Вот несколько вещей, которые я считаю важными:

• Как говорит Денис, контроль версий жизненно важен, но SVN - не единственный вариант. Я в основном использую Perforce, а git - хорошая альтернатива. Мне нравится модель развития "mainline"; это позволяет мне проводить эксперименты в ветвях кода, объединять их с основной строкой, когда они работают, и мусор, если они этого не делают.
• Я использую блокнот для заметок и программу для отслеживания задач. В настоящее время я использую Redmine для последнего; до этого я использовал Fogbugz. Мне также нравится Redmine, потому что у него действительно хорошая встроенная вики, которую я могу использовать для постоянных заметок и ссылок на важные сайты.
• Также очень важно отслеживать то, что я делаю, и устанавливать себе какие-то разумные ограничения, чтобы я мог сделать достаточно, не сгорая - см. Ниже.

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

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

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

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

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

Используйте SVN выше, версия все. Для отслеживания ноутбук подойдет для более простых проектов, при необходимости у вас есть много бесплатных приложений для отслеживания задач / ошибок (Redmine - это круто). Agile / XP / Непрерывная интеграция / другие были бы немного излишними, по моему мнению.

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

Я думаю, что наилучшим способом действий было бы просто следовать некоторым соответствующим образом выбранным (исходя из ваших потребностей и проекта) широко распространенным передовым методам из ряда моделей процессов. Ознакомьтесь с методами отслеживания проделанной работы / оставшейся работы, управления требованиями, контроля версий, тестирования (особенно модульного и приемочного тестирования), непрерывной интеграции, стандартов кодирования, «Вам это не нужно» и так далее. Если у вас нет, я предлагаю прочитать Code Complete и The Pragmatic Programmer и практиковать их советы.

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

Парень спрашивает о конкретных методологиях, а люди отвечают «используйте программное обеспечение X / Y». Это НЕ вопрос инструментов, на самом деле существует много методологий, и кажется, что для них еще нет отчета о проверке: Agile, Iterative, Spiral, Waterfall, XP, V-Model, TDD.