Начинается новый проект, и все в восторге. Команда разработчиков так заинтересована в том, чтобы сразу приступить к кодированию. Но подождите, есть несколько вещей, которые нужно сделать в самом начале, чтобы потом вы не ломали голову над проектом.
Вот некоторые из тех, с которыми я столкнулся. Люблю слышать ваши предложения.
- Серверы и машины разработчика
а) Установите шаблоны для своих серверов. Вы должны быть в состоянии создать сервер с соответствующей конфигурацией программного/аппаратного обеспечения за считанные минуты в течение всего срока службы вашего проекта.
б) Убедитесь, что у ваших машин разработчиков достаточно огневой мощи. Это может быть идеальное время, чтобы получить финансирование для тех обновлений, которые разработчики никогда не получали.
c) Сервер разработки. В некоторых случаях команды решают использовать общий сервер разработки в качестве области интеграционного тестирования. Они могут даже работать с общей базой данных на начальных этапах проекта. Хотя поначалу это может показаться продуктивным, чем раньше вы откажетесь от этого подхода, тем лучше. Эта настройка задерживает действия автоматизации, дает ложное ощущение скорости и может легко привести к искусственным задержкам в таких областях, как миграция.
2. Окружающая среда
а) Типичный проект может иметь отдельные среды для разработки/тестирования и производства. Каждая среда может состоять из комбинации приложений, конфигураций, баз данных и т. д.
б) Команде необходимо решить, сколько сред разработки и тестирования. Также, как они хотят управлять различиями между ними. Ввод в эксплуатацию новой среды снова займет всего несколько минут.
c) Еще одна проблема заключается в том, как вы подключаете свои вышестоящие и нижестоящие приложения к каждой из этих сред. В большинстве корпоративных проектов потоки данных должны устанавливаться как вверх, так и вниз по течению от внешних систем в среду разработки/тестирования.
3. Контроль версий
а) Распределенный или центральный. Распределенный контроль версий теперь более распространен, и у вас есть отличные и разнообразные возможности. Вы даже можете полагаться на сторонних поставщиков, таких как github, вместо того, чтобы создавать свои собственные. Или, может быть, вы хотите использовать такой инструмент, как TFS, в свете его общей поддержки жизненного цикла приложения.
б) Установите рабочий процесс управления версиями
- Вы выбираете именованные ветки или отдельные репозитории?
- Разрешен ли ребазинг?
в) Маркировка
г) Регистрация коммитов
д) Это не просто код. Контроль версий не должен ограничиваться вашим кодом. Любой артефакт, который делает ваш проект таким, какой он есть, должен контролироваться версиями. Ваши конфигурации, база данных, документы и т. д. Я обнаружил, что некоторые разработчики корпоративных баз данных не очень рады использованию программного обеспечения для контроля версий. Как команда, вы должны убедиться, что это не так, и что база данных и конфигурация рассматриваются как первоклассные граждане в мире контроля версий.
4. Управление знаниями
а) Команда должна выбрать механизм обмена и накопления знаний о продукте/проекте.
б) Предпочтительным методом является создание вики проекта. Вы можете начать сбрасывать свои первоначальные мысли, а затем легко обновлять их.
в) Если в проекте задействовано много документов, можно также рассмотреть систему управления документами.
г) Вики можно использовать для обеспечения согласованности в команде, будь то стандартизация терминологии или стандартизация технических объектов.
- Общие специфические для проекта термины, сокращения и их значения
- Технические стандарты и сведения о соответствии (типы данных, стандарты именования)
- Эталонные реализации и примеры кода
- Он также может содержать информацию об управлении проектом, такую как контактные данные, пути эскалации связи, планы отпусков и планы проекта высокого уровня, а также информацию о расписании.
e) Методология управления проектами и ожидаемые результаты
- Команда должна решить, какова их модель доставки. Например, будут ли это двухнедельные итерации или непрерывное развертывание функций в области интеграции по мере того, как что-то выйдет из рук разработчика.
f) Какой инструмент или метод можно использовать для отслеживания прогресса команды.
g) Такие, казалось бы, простые вещи, как консенсус относительно того, когда задача будет отмечена как 100 %, могут иметь большое значение для понимания статуса проекта в любой данный момент.
Я думаю, вы понимаете, что ничто из вышеперечисленного не должно мешать вам на самом деле добиться цели с самого начала. Не обязательно, чтобы у вас было все это, прежде чем вы откроете свою IDE. Однако, по моему опыту, команда должна поставить перед собой задачу избавиться от большинства этих проблем в течение первых нескольких итераций.
