Как мы работаем
Если кратко, то основные два подхода к созданию ПО можно описать так:
- Последовательная разработка (Waterfall). Такой подход применяется в случае, когда заказчик точно и в деталях знает, что он хочет получить от продукта, что, на самом деле, встречается не часто. В этом случае перед началом разработки составляется четкое техническое задание. Разработка идет в рамках этого задания.
- Итеративная разработка. Такой подход применяется в случае часто меняющихся или не до конца проработанных требований. Мы в кратчайшие сроки разрабатываем первую работоспособную версию с самым важным функционалом и отдаем заказчику. Как правило, получив готовый продукт, в процессе эксплуатации пользователь понимает, что он еще хочет получить от системы, а что хочет изменить. Следующая версия выходит также через короткий срок и учитывает новые пожелания заказчика. Таким образом, процесс идет до той поры, до которой желает заказчик.
При последовательной разработке, практикуемым большинством IT-компаний, заказчик видит только окончательную версию продукта. При этом есть большой риск того, что полученный продукт не оправдывает ожидания клиента, хотя может и соответствовать формальным начальным требованиям. При итеративной разработке, благодаря постоянной обратной связи с заказчиком и частым выпускам версий с учетом пожеланий клиента, такой риск впустую потратить деньги сводится к нулю.
В своей работе мы предпочитаем использовать гибкие методологии, такие как XP. Гибкие методологии предполагают, прежде всего, итеративную разработку.
Также мы используем автоматизированное тестирование. С точки зрения заказчика это в первую очередь означает следующее:
- Продукт изначально содержит намного меньше ошибок, то есть заказчик получит более надежную систему.
- При необходимости доработки функциональности выход новых версий происходит существенно быстрее и вероятность, что старая функциональность пострадает, сводится к минимуму.
- Если функциональные тесты разрабатываются совместно с заказчиком и в первую очередь, еще до построения системы, то они могут являться еще и приемочными тестами, исключающими возможность неправильной трактовки требований заказчика.