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

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

Для тех из вас, кто проводит много времени в одиночестве, как лучше организовать себя, управлять крупными (для одного человека) проектами и поддерживать производительность на максимально высоком уровне?

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

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

Вот, пожалуйста ... http://xp.c2.com/ExtremeProgrammingForOne.html

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

• Вы можете создать таблицу запросов функций, расставить приоритеты и выбрать самый верхний.
• определить критерии приемлемости (как выглядит) и закодировать его в исполняемый тест
• Далее определите инженерные задачи, которые нужно выполнить
• Пишите модульные тесты, делайте самое простое (YAGNI) и все время выполняйте рефакторинг. Цель состоит в том, чтобы сделать прохождение внешнего приемочного испытания
• Timebox каждой сессии. Для эффективного управления временем вы также можете взглянуть на технику Pomodoro .
• Используйте контроль версий и настройку CI-сервера / командного файла, чтобы создать инсталляцию или zip-файл вашего программного обеспечения.
• Демо часто. Направьте обратную связь в исходную таблицу и переориентируйте

Единственное, что вы не могли сделать в одной команде - это PairProgramming.

Если вы работаете в одиночку. Вот советы:

1. Делайте как можно меньше работы на низком уровне. Используйте как можно больше библиотек и инструментов, включая вещи, которые, по вашему мнению, можно легко закодировать (не делайте этого, просто используйте библиотеку).
2. Возьмите подход сверху вниз. Только кодируйте то, что вам действительно нужно.
3. Когда вы видите проблему в абстрактном выражении, ищите в Google и используйте научные статьи академического сообщества, что уже доказано. Вам нужно всего лишь кодировать их алгоритм.
4. Разработайте свою систему так, чтобы вы могли как можно больше свободно менять вещи. (включая копирование и вставку некоторого кода отсюда туда). Цель состоит в том, чтобы сэкономить ваше время, когда вы поймете, что совершили ошибку. Постарайтесь свести к минимуму объем работы, которую вы должны отбросить, если допустите ошибку. Кусок кода, который нужно выбросить (вместо копирования-вставки здесь и там) - это эквивалент времени, потерянного при написании этого кода.
5. Имейте много автоматических тестов, чтобы вы могли регулярно делать регрессионные тесты каждый раз, когда вы вносите изменения
6. Разделите обязанности вашего дизайна (т.е. уменьшите сцепление). Сделайте вещи максимально модульными
7. Используйте отладчик для отладки и используйте бинарный поиск, чтобы найти дефект.
8. Постоянно рефакторинг вашего кода для уменьшения (явной) связи и открытых методов (неявная связь).
9. Не важно. Это здесь на всякий случай, я могу придумать что-то новое: P

Кодовые обзоры.

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

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

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

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

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

Я предлагаю вам следующее:

1. Тест-управляемая разработка
2. Используйте в коде «TODO: обратите внимание», когда вы видите что-то, что вы не можете сделать немедленно, и возвращайтесь к ним, когда у вас есть время, чтобы остаться на Facebook и ждать, пока ваш клиент перезвонит
3. Напишите свой код, поскольку ваш клиент будет покупать его, глядя на код, а не только на результат, представьте, что ваш клиент будет председателем для проверки кода.
4. Заполните свой код подтверждения

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

Вот ссылка с дополнительной информацией: http://en.wikipedia.org/wiki/Behavior_driven_development

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

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

С точки зрения реальных методологий, одному разработчику трудно придерживаться какой-то конкретной. Я консультант, который обычно работает в одиночку, и мне и клиенту проще всего использовать гибкий процесс. Обычно я стараюсь, чтобы мои клиенты напрямую вводили свои требования в такой инструмент, как Trac (или я буду от их имени). Это не только помогает другим разработчикам определить цель кода, но и вам самим за 3 месяца!

Философия: XP / TDD + GTD

общий план:

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

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

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

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

По иронии судьбы я нахожу, что решение для управления версиями, например GIT, лучше для человека, чем что-то вроде SVN.

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

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

проворный

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

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

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

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

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