Как часто Вам докучал Заказчик со своими новыми и новыми требованиями?

Теперь все изменится вместе со Scrum. Scrum — это адаптивная методология избавления от излишних придирок Заказчика.

Допустим, Вы составили ТЗ (техническое задание), подписали его, сделали все как там написано, НО Заказчику НЕ НРАВИТСЯ, хоть сделанное и соответствует всем его требованиям. И что же теперь делать? Заказчик будет мириться с тем, что уже есть, или?..

Не рискуйте переплачивать за переделку заказа без гарантии на то, что Вас все будет устраивать после переделки!

• Если Ваш Заказ для Вас является принципиально важным (кнопка такая-то на таком-то расстоянии, картинка так-то и т.д.).
• Разработчик по-своему трактует описанные в ТЗ требования и отказывается вносить изменения в проект на этом основании.
• Если запустить проект нужно уже сейчас, а дополнительные функции разрабатывать по ходу — когда проект начнет отбивать начальные инвестиции.
• Если доводить проект до конца в том виде, как описано в ТЗ — нет смысла.

Scrum — значит тратить по-минимуму, но в то же время гибко. Т.е. фиксированного бюджета нет, существует экспертная оценка, в которой, как правило, заложены риски и учтена скорость работы (по опыту предыдущих проектов). Договорные отношения в данном случае оформляются как договор на разработку проекта с поэтапной разбивкой + дополнительные соглашения на возникающие по ходу развития проекта хотелки Заказчика.

Итак,

• Работа по этапам и приоритетам. Разработка будет производится по четко спланированным Вами приоритетам. Вы сможете дорабатывать Ваши идеи в процессе разработки. Т.е. сделали Вам выпуклую кнопку, но Вам не понравилось как это смотрится. Тогда Вы заменяете ее на квадратную, переплачивая только за одну эту кнопку, а не за все кнопки на Сайте.
• Полный контроль над ситуацией в виде ежедневного отчета. Что было сделано за вчера, какие планы на сегодня, какие есть проблемы.
• Частые демонстрации проекта. По окончанию спринта, Заказчик сможет просмотреть работающую тестовую версию проекта с приростом функций, наиболее важных для бизнеса Заказчика. Функции можно будет проверить. Предложения на последующие этапы работ высказать. После демонстрации происходит ретроспектива — анализ хода прошедшего этапа работы с целью улучшения процессов разработки с последующим переходом к следующему этапу работ.

• Вместо ТЗ — Backlog. Backlog — документ, содержащий список всех требований к проекту, причем пункты списка упорядочены по степени важности. По ходу проекта список и приоритеты могут изменяться, в зависимости от потребностей Заказчика, новых идей или изменяющихся условий.

Важно! Заказчик проекта может вносить любые изменения прямо по ходу проекта (но не в текущий этап разработки).

• Спринт — этап разработки. Вся разработка проекта идет короткими этапами (спринтами). Функции, которые нужно реализовать на каждом спринте — зафиксированы (их нельзя менять по ходу спринта). Они разбиты на задачи, а задачи имеют оценки и приоритеты. Продолжительность спринта фиксирована.

Важно! Заказчик не может менять функции, которые нужно реализовать на спринте, по ходу спринта.

• Результатом работы каждого спринта является полностью оттестированный проект, в котором реализованы все функции предыдущих спринтов + прирост функциональности из текущего спринта, что позволяет осуществить запуск проекта на самых ранних стадиях, реализовав только самый необходимый минимум функционала, и затем, параллельно с работой сайта проводить разработку следующих по важности частей проекта.