Опубликовано

Процесс сборки билдов и релиза

Процесс сборки билдов и релиза

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

В один момент времени может быть до 2х веток кода:

  • Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
  • Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).
  • 0й – разработка
  • 1й – тестирование, fix, разработка, сдача этапа (деливери)
  • 2й – тестирование, fix, разработка, сдача этапа (деливери)
  • 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

  • 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
  • 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
  • 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
  • 4. PM планирует объем функционала {Ф} для следующего деливери.
  • 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
  • ! У дефектов приоритет всегда выше, чем у нового функционала!
  • 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
  • 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
  • ! Деливери собирается и отправляется только после одобрения QA!
    • Деливери отправляется заказчику вместе с сопроводительной документацией.
  • 8. PM инициирует слияние двух веток.
  • 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
  • 10. Процесс повторяется до выпуска финальной версии.
Опубликовано

Как проверить сайт.

Как проверить сайт

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

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

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

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

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

Как проверить, что сайт соответствует именно вашим требованиям, изложенным в техническом задании? Обратиться к специалисту по контролю качества QA. Скорее всего, это будет именно тот аналитик, что помогал составлять техническое задание. Хотя в идеале это должны быть совсем разные люди. Будьте уверены, Ваш сайт еще на протяжении минимум двух недель будет дорабатывать компания с раздутым именем.

Как известно, скупой платит дважды, в редких случаях трижды. Заложив в бюджет создания сайта работу по описанию требований и их тестированию от 20% до 30% стоимости всей разработки, позволит Вам избежать многих подводных камней на пути к успеху.