Выпускайте первую версию!

в 4:33, , рубрики: gtd, версионирование, итерация, ПО, разработка, релиз, стабильность, управление проектами, метки: , , , , ,

Введение

Грамотно налаженные и состоявшиеся процессы — не для нас! Это ведь скучно, когда все уже настроено и работает как часы, но к этому надо стремиться. А уж после порадоваться проделанной работе и очередной раз проверить, как же все хорошо работает…

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

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

Н.Н.У

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

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

Постулат 1: Код в основной ветке разработки нестабилен

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

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

Во множестве проектов нет отдела контроля качества и тестирования, часто нет никаких тестов. Вся разработка ведется в основной ветке. Вот для таких проектов и озвучен постулат 1.

Выпустите версию

Ваш код еле компилируется, имеется множество ошибок, фатальных и не очень, заказчик начинает седеть от вида и поведения системы? Выпускайте версию!

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

Мотивация

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

Плюсы

Из положительных моментов выпуска версии можно выделить:

  • Создание «точки отсчета» продукта;
  • Регламентированное попадание нового функционала к заказчику;
  • Повышение стабильности и качества продукта;
  • Нормальный ритм работы команды;
  • Широкие возможности планирования развития продукта;
  • «Контролируемость» разработки;
  • Простое исправление ошибок без внесения большего количества новых.

Минусы

Есть и недостатки выпуска первой версии на ранних этапах работы над проектом:

  • «Стрельба трассирующими» по заказчику. Не каждый к этому готов;
  • Новые трудозатраты для выпуска версии;
  • Замедление поставки нового функционала заказчику на итерацию.

Не исключаю, что каждый читатель сможет привести еще по паре плюсов и минусов выпуска первой сырой версии.

Заключение

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

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

Н.Н.У — Нулевые Начальные Условия.

Автор: VaiMR

Поделиться

* - обязательные к заполнению поля