Пресс-Релизы
Техническое задание или гибкие методологии разработки?
Какой подход наиболее эффективен в разработке сайтов? В этой статье нет никакой теории, только непосредственный опыт, который может быть полезен для тех, кто впервые думает о разработке веб-проекта, и для тех, кто уже работал по данному направлению.
Совсем недавно мы перешли на гибкие методологии в разработке проектов для наших клиентов и хотим рассказать о нашем опыте в сравнении с классическим подходом в разработке проектов по техническому заданию.
Техническое задание (ТЗ)
В классической методике разработки сайтов используется, как правило, техническое задание, в которое включено:
- Характеристики и требования предъявляемые к разрабатываемому Продукту
- Схемы, планы и условия разрабатываемого продукта
Требования - это хорошо, однако, как показывает практика, требования к программному обеспечению бывают очень изменчивы в процессе его создания, да и отобразить все требования порой бывает сложно. Поэтому в процессе совершенствования подхода в разработке сайтов - стали появляться более гибкие подходы.
Гибкие методологии разработки (Agile methodology)
Манифест:
- Люди и взаимодействия важнее, чем процессы и инструменты
- Работающий код важнее совершенной документации
- Сотрудничество с заказчиком важнее контактных обязательств
- Реакция на изменения важнее следования плану
Agile - методологии пришли к нам с Запада и постоянно набирают большую известность и популярность в России.
Сравнение работы по ТЗ и по Agile
1. Составление технических требований
При работе по ТЗ: в результате можно получить соответствующий (или формально соответствующий) ТЗ Сайт, при этом не выполняющий поставленные задачи. Обязательное следование ТЗ может вылиться в желание "ни в коем случае" не перевыполнить план.
Решение в Agile: Клиент и Исполнитель совместно пишут сценарии пользователей (пример: Как администратор сайта я могу добавлять/удалять/редактировать страницы сайта, добавлять на них текст и фотографии), а техническая реализация остается на Исполнителе.
2. Практически не возможно описать все в точности, что должно быть на сайте и как оно должно работать
При работе по ТЗ: расхождение во взглядах то, что одна сторона подразумевает как само собой разумеющееся - для другой стороны таковым не является (все люди разные и их представления тоже).
Что мы поняли: когда клиент думает о том как должна обрабатываться форма, проходить процесс регистрации итп - это то, что усложняет и замедляет процесс разработки продукта и как правило не ведет к лучшим результатам.
Решение в Agile: Важно не техническое описание, а отвечающая поставленным сценариям разработка (пример: Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы).
3. Клиенту точно не известно, что именно ему нужно с точки зрения технической реализации
При работе по ТЗ: если нет детального описания - может быть создано что угодно.
Решение в Agile: Когда есть задача, выраженная в сценарии, написание которых является простым описанием действий - Исполнитель находит лучший способ решения (в соответствии с опытом и личными наработками), клиенту не приходится ломать голову - как же это лучше сделать.
4. В процессе разработки стало ясно, что необходимо другое
Это часто встречается в процессе разработки больших проектов, когда разработка может происходить в течение нескольких месяцев и за это время у клиента изменяются бизнес-цели. Для многих компаний - реакция на изменения очень важна
При работе по ТЗ: Внесена предоплата, большая часть работы сделана и исполнителю не выгодно переделывать....
Решение в Agile: итерационный процесс (когда выполнение работ идет небольшими этапами 1-2 недели, результаты которых согласуются обеими сторонами. В первую очередь создается самое важное для бизнес-целей).
5. Проектная документация
При работе по ТЗ: Огромное количество документации в которой разобраться порой невозможно, да и менеджер со стороны клиента не всегда человек с техническим образованием.
Решение в Agile: Основной метрикой agile методов является рабочий продукт. Отдавая предпочтение непосредственному общению - agile методики значительно уменьшают объем письменной документации по сравнению с другими методами
Вывод
Конечно гибкие методологии не панацея и важно то, как будут выстраиваться отношения клиент-исполнитель, и принципы гибких методологий помогают выстроить процесс разработки сайта более взаимовыгодно.
Если вы выбрали будущего партнера по разработке сайта (внимательно посмотрев портфолио, отзывы и может быть даже позвонив клиентам) - поставьте им цели и доверьте процесс технической реализации!
Желаем успешных проектов!
Хотите разместить свой пресс-релиз на этом сайте? Узнать детали