Процесс разработки программного обеспечения для небольших команд

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

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

Ответ 1

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

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

Вещи, которые я никогда не сдаду даже для меня:

контроль исходной версии
подпорки
TODO
модульное тестирование /TDD
документация кода
рефакторинг/обзоры кода

Ответ 2

Пусть могучий SecretGeeek научит вас как быть автономным программист. Наслаждайтесь:)

   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success >>>> profit ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste

Ответ 3

Разработка с поддержкой TODO

Серьезное предложение от SecretGeek.

Настройте среду разработки или редактор, чтобы автоматически перечислить все строки с тегами TODO. Visual Studio делает это по умолчанию.

Шаг 1

Запись классов или методов (т.е. "Открытый класс..." или "Открытый суб..." без кода внутри.)
Включить грубую логику
Добавить псевдо-код с надписью "TODO:"
Только напишите очень тривиальный код - все остальное просто добавьте TODO

Шаг 2

Повторите шаг 1 до тех пор, пока все приложение не будет исправлено.
Теперь у вас есть большой список задач "TODO".
Проверить полноту (широту)
Посмотрите, что можно удалить.
Посмотрите, что можно упростить (например, два похожих комментария todo: могут ли они быть идентичными?

Шаг 3

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

Шаг 4

Исправить ошибку компиляции за раз:
- запись оболочек классов, методов и т.д.
- Добавление TODO: псевдокод к каждому из них, когда вы идете.
- (Также добавьте комментарии и объяснения "HACK:", если это необходимо, если нажать для времени)
- При необходимости замените TODO на требуемый тривиальный код

Шаг 5

Повторите шаг 4, пока не осталось ошибок компиляции.
Если есть TODO влево, затем вернитесь к шагу 3.

(Там также много предварительного планирования, прототипирование бумаги, встречи с клиентами, обсуждение, промедление, дизайн базы данных, кофе-пить, генерация кода для sprocs и crud-sproc-звонков, импорт повторно используемых DAL, использование блоков PAG, идти PAG!, назад-вперед-дебаты до подписания документа, споров, поздних ночей, разочарования, общения с друзьями, просеивания по электронной почте, царапин в visio, печати вещей и оставления их в куче, scrounging for скрепки, ловли автобусов, занимались спинкой и шеей и т.д., но все это было исключено для простоты...)

(MarkJ снова) Немного похоже на процесс программирования псевдокода из Code Complete. И мы все согласны, каждый должен читать Code Complete, правильно?

Ответ 4

Я бы рекомендовал метод Crystal Clear

Семь свойств

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

Ответ 5

Большинство гибких методологий соответствуют вашему профилю.

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

Я рекомендую Headfirst Software Development, если вы хотите начать с некоторого чтения

Ответ 6

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

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

Ответ 7

Не прямой ответ на ваш вопрос, но у Стив Макконнелл есть статья под названием Less is More, написанная более десятилетия назад о том, почему команды более продуктивны.

Ответ 8

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

Подробнее об этом читайте здесь: http://martinfowler.com/articles/continuousIntegration.html