Техническое задание или гибкие методологии разработки?

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

Совсем недавно мы перешли на гибкие методологии в разработке проектов для наших клиентов и хотим рассказать о нашем опыте в сравнении с классическим подходом в разработке проектов по техническому заданию.

Техническое задание (ТЗ)

В классической методике разработки сайтов используется, как правило, техническое задание, в которое включено:

- Характеристики и требования предъявляемые к разрабатываемому Продукту

- Схемы, планы и условия разрабатываемого продукта

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

Гибкие методологии разработки (Agile methodology)

Манифест:

- Люди и взаимодействия важнее, чем процессы и инструменты

- Работающий код важнее совершенной документации

- Сотрудничество с заказчиком важнее контактных обязательств

- Реакция на изменения важнее следования плану

Agile - методологии пришли к нам с Запада и постоянно набирают большую известность и популярность в России.

Сравнение работы по ТЗ и по Agile

1. Составление технических требований

При работе по ТЗ: в результате можно получить соответствующий (или формально соответствующий) ТЗ Сайт, при этом не выполняющий поставленные задачи. Обязательное следование ТЗ может вылиться в желание "ни в коем случае" не перевыполнить план.

Решение в Agile: Клиент и Исполнитель совместно пишут сценарии пользователей (пример: Как администратор сайта я могу добавлять/удалять/редактировать страницы сайта, добавлять на них текст и фотографии), а техническая реализация остается на Исполнителе.

2. Практически не возможно описать все в точности, что должно быть на сайте и как оно должно работать

При работе по ТЗ: расхождение во взглядах то, что одна сторона подразумевает как само собой разумеющееся - для другой стороны таковым не является (все люди разные и их представления тоже).

Что мы поняли: когда клиент думает о том как должна обрабатываться форма, проходить процесс регистрации итп - это то, что усложняет и замедляет процесс разработки продукта и как правило не ведет к лучшим результатам.

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

3. Клиенту точно не известно, что именно ему нужно с точки зрения технической реализации

При работе по ТЗ: если нет детального описания - может быть создано что угодно.

Решение в Agile: Когда есть задача, выраженная в сценарии, написание которых является простым описанием действий - Исполнитель находит лучший способ решения (в соответствии с опытом и личными наработками), клиенту не приходится ломать голову - как же это лучше сделать.

4. В процессе разработки стало ясно, что необходимо другое

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

При работе по ТЗ: Внесена предоплата, большая часть работы сделана и исполнителю не выгодно переделывать....

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

5. Проектная документация

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

Решение в Agile: Основной метрикой agile методов является рабочий продукт. Отдавая предпочтение непосредственному общению - agile методики значительно уменьшают объем письменной документации по сравнению с другими методами.

Вывод

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

Если вы выбрали будущего партнера по разработке сайта (внимательно посмотрев портфолио, отзывы и может быть даже позвонив клиентам) - поставьте им цели и доверьте процесс технической реализации!