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

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

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

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

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

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

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

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

 Манифест:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

 Желаем успешных проектов!