Я провожу много времени, работая над проектами, в которых я являюсь единственным разработчиком, менеджером проектов, дизайнером, специалистом по QT (да, я знаю ... плохо!), А иногда я даже клиент.
Я перепробовал практически все для планирования проектов и управления собой, от просто сидения и работы вольным стилем до завершения проекта, сколько бы времени это ни заняло, до одиночной версии схватки, в которой я провел совещание с прогрессом над собой на протяжении одного -человек сгорает график каждое утро (не шучу).
Для тех из вас, кто проводит много времени в одиночестве, как лучше организовать себя, управлять крупными (для одного человека) проектами и поддерживать производительность на максимально высоком уровне?
Ответы:
Хранение четкого списка ваших целей жизненно важно. Для ползучего объекта легко взять на себя управляемый проект. Подход TDD «все готово, когда работает» также полезен. Это мешает вам стать перфекционистом.
Одна вещь, которая действительно помогает мне, - это представить, что другой инженер или менеджер проекта скажет в той или иной ситуации. Часто я могу «стыдить себя» из-за плохого кода или вернуться на правильный путь, если график смещается.
источник
Вот, пожалуйста ... http://xp.c2.com/ExtremeProgrammingForOne.html
ХР хорошо масштабируется, поскольку она оптимальна для небольших целевых команд.
Единственное, что вы не могли сделать в одной команде - это PairProgramming.
источник
Если вы работаете в одиночку. Вот советы:
источник
Кодовые обзоры.
Они особенно полезны, поскольку вы будете объяснять код тому, кто не работал над тем же проектом, чтобы у него не было ваших предположений о том, как он должен работать.
Они также получат дополнительное преимущество от обмена знаниями в компании, поэтому, когда кому-то еще придется работать над проектом (из-за того, что люди заняты в другом месте, заболели, уволились или были уволены), им не придется начинать с нуля. ,
источник
Я выпустил свою собственную версию Agile, основанную на историях, интенсивном взаимодействии с клиентами, частых выпусках и разработке на основе тестов. Я использую вики, чтобы отслеживать истории, как можно больше вовлекать клиентов в их написание, и заставляю клиента работать со мной, чтобы расставить приоритеты и организовать релизы. Я использую TDD для разработки и реализации. Я настроил QA-сервер, на котором клиент может опробовать частые выпуски (иногда ежедневно по мере разработки новых функций), чтобы быстро получать обратную связь. Я редко прохожу больше 3 итераций без релиза в QA. Заказчик принимает решение, когда версия QA имеет достаточно функций, чтобы начать работу, и если больше нет функций из списка, необходимо разработать.
источник
В моей компании наша группа работает над одним и тем же проектом, но на относительно независимых срезах. Одна вещь, которую мы часто здесь делаем, это когда что-то, что вы делаете, кажется немного сложным, или вы находитесь на распутье в пути с более чем одним способом реализации чего-либо, вы берете кого-то еще и обсуждаете за и против, прежде чем Вы продолжаете. Если вы подождете, пока ваш код будет завершен, чтобы выполнить проверку, вы, как правило, уже потратили слишком много времени, чтобы подумать о серьезных архитектурных изменениях, хотя, безусловно, многие недостатки обнаруживаются в обзорах кода.
Кроме того, я понимаю, что в последнее время разработка, управляемая тестами, стала немного модным словом, но она может быть очень полезна для индивидуальных разработчиков, поскольку она обеспечивает проверку качества на ходу, а когда возникают трудности с написанием тестов, вы знаете, что вам, вероятно, потребуется реструктуризация код. Это также помогает более поздним сопровождающим не случайно взломать код трудными для обнаружения способами.
источник
Я предлагаю вам следующее:
источник
Я хотел бы сказать, что смог практиковать то, что проповедую 100% времени, но BDD, похоже, является хорошим подходом для вашей ситуации:
Вот ссылка с дополнительной информацией: http://en.wikipedia.org/wiki/Behavior_driven_development
источник
Я в очень похожей лодке. Я стараюсь максимально следовать гибким принципам (а также понимаю их). Я, вероятно, не делаю вещи "правильно", но я добился большого успеха в своих проектах, пытаясь следовать гибким принципам. Это требует огромного количества дисциплины, так как нет команды, чтобы удостовериться, что вы не просто начинаете принимать ярлыки.
источник
Я считаю, что использование инструментов форматирования кода, таких как ReSharper, гарантирует, что, по крайней мере визуально, код будет легко подобрать для других разработчиков.
С точки зрения реальных методологий, одному разработчику трудно придерживаться какой-то конкретной. Я консультант, который обычно работает в одиночку, и мне и клиенту проще всего использовать гибкий процесс. Обычно я стараюсь, чтобы мои клиенты напрямую вводили свои требования в такой инструмент, как Trac (или я буду от их имени). Это не только помогает другим разработчикам определить цель кода, но и вам самим за 3 месяца!
источник
Философия: XP / TDD + GTD
общий план:
источник
Любая подходящая методология поможет - независимо от количества людей в проекте. Так что выбирайте по одному за раз и посмотрите, как вы можете подать заявку и сопоставить со своим доменом, и оценить их успехи.
Возможно, интереснее спросить, какие методологии не выбрасывать, потому что над проектом работает всего 1 человек.
И ключевой из них, который выделяется для меня, - «Контроль исходного кода» (да, это инструмент, но он является частью вашего рабочего процесса, а также процесса). У людей может возникнуть искушение дать этот пропуск, поскольку им «не нужно поддерживать одновременное редактирование кода несколькими людьми».
По иронии судьбы я нахожу, что решение для управления версиями, например GIT, лучше для человека, чем что-то вроде SVN.
источник
Если он выбрасывает код, он может быть немного слабоватым с методологиями, но что-то важное, и я бы сказал, что ваш способ воспринимать его как командный проект с одним человеком очень приятный и дисциплинированный.
Напишите свой код для следующего парня, который будет читать, а не вы ... будьте добры к нему / ней. Даже «выкинутый» код остается навсегда.
источник
проворный
функции, истории и контрольные примеры гораздо более поучительны, чем более формальная документация, и набор рабочих тестов лучше демонстрирует, как использовать что-то или как что-то работает, чем любое количество мертвых деревьев
Также легче выполнять работу между итерациями.
источник
Как консультант, я бы посоветовал вам найти способ, чтобы на любом задании всегда было как минимум два разработчика.
Я согласен с тем, чтобы быть гибким и оставлять гибкий след историй и тестов, которым могут следовать другие, но я не верю, что этот или какой-либо другой процесс или методология будут придерживаться, пока люди работают в одиночку.
источник
Я думаю, что обзоры кода - хорошее начало, но мне нравится, когда они сделаны неформальными и увлекательными, например, проверка парного кода или парное программирование для решения определенной проблемы / проблемы или некоторого улучшения (например, изменение устаревшего кода в соответствии с новыми стандартами кодирования). ). Иногда два взгляда лучше, чем один, и это тоже весело, я чувствую, что обмен мнениями и обсуждение кажутся более открытыми. Вы также можете провести формальный / неформальный обед и обсудить сессию, чтобы поговорить о том, что вы делали по отдельности или в группе, например, упомянуть новый шаблон, который вы использовали, или новые технологии, как была решена проблема?
источник