Термины и определения
Качество продукта - степень его соответствия техническому заданию. В идеальном мире сайт должен полностью соответствовать техническому заданию и не иметь критических дефектов.
Критический дефект - ошибка, блокирующая выполнение базового функционала сайта. Например, невозможность авторизоваться на сайте, имеющим личный кабинет.
Итерационная модель разработки
Данная модель подходит для больших проектов (выше 100 человеко часов в месяц). Суть метода - объединение заявок по сайту в группы (называемые итерациями) и реализация всей группы задач за короткий цикл (как правило, 3-5 недели) с последующим полным тестированием всего продукта. Данный метод подходит для больших проектов, тк подразумевает полномасштабное тестирование всего функционала сайта. Полное тестирование, как правило, занимает фиксированное количество времени (20-30 часов), поэтому его применение не целесообразно для небольших итераций.
Каждая итерация состоит из шести основных этапов:
- Составление и утверждение списка изменений, которые необходимо реализовать в рамках итерации.
- Написание Технических заданий на наиболее крупные изменения.
- Оценка времени необходимого на реализацию итерации и утверждение даты старта начала и окончания работ.
- Полное тестирование сайта клиента и всех изменений внесенных в процессе итерации на тестовом сервере разработчиков. Доведение итерации до стабильного состояния, за счет исправления критических дефектов.
- Интеграция изменений на сайт клиента.
- Повторное тестирование сайта клиента для подтверждения качества продукта.
В целом среднее время необходимое на завершение итерации - 4 недели плюс составление и утверждение Технических заданий.
Плюсы:
- Стабильное качество продукта от итерации к итерации. Достигается за счет полного тестирования перед каждой выкладкой итерации на сайт клиента.
Минусы:
- Изменения на сайте появляются не сразу, а только после окончания итерации (как правило, в течение 4-5 недель).
- Затраты на тестирование всегда имеют фиксированную стоимость, не зависящую от количества изменений произведенных за время итерации.
Динамическая модель разработки
Вы не найдете такого метода в современной литературе по программированию. Это наша внутренняя методика быстрой разработки небольших проектов. В основе ее лежит предположение, что сайт клиента имеет малую степень связности компонентов (изменения в одной части сайта практически не затрагивает функционал других частей системы). Следовательно, можно править обособленную часть сайта и тестировать только ее.
За каждой частью сайта или за сайтом в целом закрепляется ответственный разработчик или группа разработчиков (в зависимости от масштаба проекта), которые понимает всю внутреннюю взаимосвязь компонентов сайта и могут грамотно исправить или доработать нужный функционал системы. Разработка в большинстве случаев ведется непосредственно на сайте клиента, либо на его локальной копии в случае “масштабных” изменений.
Методика предполагает отсутствие итераций и финального тестирования всего продукта. В процессе разработки разработчики сами тестируют тот модуль или ту часть кода, которую они правили. Изменения сразу же интегрируются на сайт клиента.
Данный способ позволяет сократить бюджеты на разработку в разы и увеличить скорость внедрения нового функционала, практически без потери качества продукта. Но нужно понимать, что качество продукта при таком методе разработки будет ниже, чем в предыдущей модели разработки. Есть небольшая вероятность возникновения критических дефектов, которые не заметили разработчики. В случае нахождения таких дефектов клиентом, необходимо срочно создать заявку на менеджера проекта. Дефект будет исправлен на общих условиях выполнения работ над заявками.
Работа над заявками, как правило, проходит в несколько этапов, каждый из которых состоит из двух этапов: внедрение и тестирование. Тестирование проводится либо менеджером клиента, либо специально обученным тестером и никогда разработчиком. Такое независимое тестирование позволяет находить большее число ошибок и недоработок, по сравнению с тестирование разработчиком, что напрямую влияет на качество выполненных работ. Время необходимое для тестирования и доработку включается во время выполнения задачи.
Плюсы:
- Низкая стоимость за счет исключения полного тестирования.
- Высокая скорость внедрения изменений на сайт за счет отсутствия итераций.
Риски:
- Нестабильное качество продукта. Могут появляться критические дефекты, за счет не учтенных взаимосвязей между компонентами. Это случается редко, но все же случается. Такие ошибки исправляются на общих условиях работы над заявками.