Термины и определения

Качество продукта - степень его соответствия техническому заданию. В идеальном мире сайт должен полностью соответствовать техническому заданию и не иметь критических дефектов.

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

Итерационная модель разработки

Данная модель подходит для больших проектов (выше 100 человеко часов в месяц). Суть метода - объединение заявок по сайту в группы (называемые итерациями) и реализация всей группы задач за короткий цикл (как правило, 3-5 недели) с последующим полным тестированием всего продукта. Данный метод подходит для больших проектов, тк подразумевает полномасштабное тестирование всего функционала сайта. Полное тестирование, как правило, занимает фиксированное количество времени (20-30 часов), поэтому его применение не целесообразно для небольших итераций.

Каждая итерация состоит из шести основных этапов:

  1. Составление и утверждение списка изменений, которые необходимо реализовать в рамках итерации.
  2. Написание Технических заданий на наиболее крупные изменения.
  3. Оценка времени необходимого на реализацию итерации и утверждение даты старта начала и окончания работ.
  4. Полное тестирование сайта клиента и всех изменений внесенных в процессе итерации на тестовом сервере разработчиков. Доведение итерации до стабильного состояния, за счет исправления критических дефектов.
  5. Интеграция изменений на сайт клиента.
  6. Повторное тестирование сайта клиента для подтверждения качества продукта.

В целом среднее время необходимое на завершение итерации - 4 недели плюс составление и утверждение Технических заданий.

Плюсы:

  • Стабильное качество продукта от итерации к итерации. Достигается за счет полного тестирования перед каждой выкладкой итерации на сайт клиента.

Минусы:

  • Изменения на сайте появляются не сразу, а только после окончания итерации (как правило, в течение 4-5 недель).
  • Затраты на тестирование всегда имеют фиксированную стоимость, не зависящую от количества изменений произведенных за время итерации.

Динамическая модель разработки

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

За каждой частью сайта или за сайтом в целом закрепляется ответственный разработчик или группа разработчиков (в зависимости от масштаба проекта), которые понимает всю внутреннюю взаимосвязь компонентов сайта и могут грамотно исправить или доработать нужный функционал системы. Разработка в большинстве случаев ведется непосредственно на сайте клиента, либо на его локальной копии в случае “масштабных” изменений.

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

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

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

Плюсы:

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

Риски:

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