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

    Введение


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

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

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

    Н.Н.У


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

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

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

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

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

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

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


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

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

    Мотивация


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

    Плюсы


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


    Минусы


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


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

    Заключение


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

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

    Н.Н.У — Нулевые Начальные Условия.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 6

      0
      >>В большинстве компаний не найти человека с должностью «build-master»
      Обычно эту роль выполняет пара скриптов.
        +3
        Начинал карьеру как раз таки в роли «build-master».
        Сборка проекта под win(клиент, сервер), mac(клиент, сервер), linux(сервер), solaris(сервер), web клиент на java, под палм.
        + под 3 языка.

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

        Когда уходил, 3 часа занимал полный билд, и час моего времени.

        Не всегда всё может сделать скрипт)
          0
          Согласен с Вами полностью. Скрипту будет «влом» сбегать на кухню и сказать Васе что он чего-то не до залил и он будет ждать когда Вася на кухне поговорит с коллегами за новый iPhone или еще чего-нить. А у человека понимающего что через час выдача билда даже мысли о «влом» не возникнет.
            +5
            Излагайте мысли четче, а то полный бред получается, если прочитать «чего-то», влом", «поговорить за iPhone ».
        +3
        Увидев «Постулат 1», ожидал увидеть еще постулатов.
          +1
          Да, хотел добавить еще несколько, но все они свелись к одному, а номер не убрал, чтобы можно было сформулировать постулаты 2, 3, 4..., подходящие именно в вашем случае.

        Only users with full accounts can post comments. Log in, please.