Scrum или Аgile. Подход к небольшим проектам

Подход к внедрению 1С — какую методологию предпочесть?

Как внедряют проекты в ФТО

Крупные проекты в ФТО обычно внедряются с помощью классической «водопадной» методологии:

  • Первым этапом проекта является «Анализ и дизайн». В ходе этого этапа проводится интервью с бизнес-экспертами, подрядчик готовит документ «Дизайн решения», и согласует его с клиентом. В результате этого мы получаем точно определенный функциональный объем проекта, а также:
  1. Детальный план работ вплоть до запуска в промышленную эксплуатацию
  2. Точные сроки
  3. Точный бюджет.

Далее, друг за другом, идут этапы:

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

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

Минусы классического подхода

  • Непопадание в ожидания. В классическом проекте от согласования дизайна на систему до первой демонстрации ее (т.н. интеграционного тестирования с заказчиком) проходит до 6 месяцев, а до запуска системы в эксплуатацию – до 9 месяцев, а в крупных проектах и больше. Часть ожиданий клиента относительно системы, которая была недостаточно точно отрефлексирована в дизайне, оказывается не выполненной, и это становится известно только через месяцы работы.
  • Компания не стоит на месте. За время разработки и подготовки к запуску (условно, 9 месяцев) бизнес-процессы в компании меняются, и запускаемая система уже отстает от жизни. Стоимость внесения изменений по ходу проекта высока.
  • Существенная часть бюджета тратится на малополезную работу. Этап «Анализ и дизайн» проекта (проведение интервью, написание и согласование дизайн решения) занимает 20-30% бюджета проекта. В нашей практике крайне редки случаи, когда после запуска проекта полученный дизайн решения реально используется.
  • Работа на корзину. На этапе дизайна бизнес-эксперты могут придумывать процессы или функциональность, которые не будут использоваться в реальной жизни. Все согласованные пожелания разрабатываются полностью, а после запуска существенная часть функционала переделывается, или выкидывается и разрабатывается с нуля.
  • Запланированный CAPEX тратится целиком. Невозможно в произвольный момент остановить проект и пользоваться тем функционалом, что уже готов: клиент получает результаты только после запуска.

Альтернативный подход

Альтернатива – методология agile, или гибкий подход.

Ключевые отличия подхода:

  1. Разработка ведется итеративно. Каждая итерация приводит к созданию и запуску нового блока функциональности.
  2. Планирование работы команды ведется не сразу на весь проект, а на следующую итерацию.
  3. Существенно уменьшен объем создаваемой документации.
  4. Больше коммуникации между командой клиента и подрядчика

Подробнее об этой методологии.

1. Итеративная разработка

Окончание каждой итерации – демонстрация промежуточных результатов клиенту и (чаще всего) запуск новой функциональности в эксплуатацию. Такой подход позволяет:

  • Получать быструю обратную связь от бизнес-экспертов и конечных пользователей по новой функциональности и корректировать планы по созданию системы.
  • Система всегда в состоянии «готова». В любой момент времени можно остановить разработку (и соответственно выделение бюджета) и пользоваться тем продуктом, который уже разработан.
  • Изменение требований – это хорошо, это естественная ситуация, а не отклонение от нормы (как в «водопадной» модели). Бизнес не стоит на месте.

2. Планирование по итерациям

Общий план проекта – не расписан детально, а представляет из себя roadmap по ключевым функциям. Детальное планирование ведется только на ближайшую итерацию.

За счет этого:

  • Разрабатывается только то, что необходимо: низкоприоритетные задачи не будут разрабатываться до высокоприоритетных (а может и никогда).
  • Сокращается избыточная работа на планирование руководителя проекта как со стороны клиента, так и подрядчика
  • Уменьшается ставка в проекте: подрядчик не должен закладывать в ставку риски недооценки проекта, возникновения форс-мажорных ситуаций и т.п. На примере ФТО ставка по agile модели меньше ставки в fix-price проектах на 40%.

3. Меньше документации

В ходе проекта не создается полный дизайн решения на всю систему, этапа «Анализ и дизайн не существует. Документация на создаваемую функциональность в рамках ближайшей итерации создается в упрощенном
виде.

В результате этого:

  • Уменьшаются непроизводительные затраты труда. За счет того, что документация создается непосредственно перед или во время разработки (когда часть системы уже работает), повышается ее точность и качество.
  • Сокращается бюджет проекта, за счет отказа от этапа дизайна, снижается количество документации.

4. Больше коммуникации

  • Команда подрядчика общается с командой заказчика не только на интервью и приемке системы, а на регулярной основе (ежедневно/еженедельно).
  • «Владелец продукта» со стороны клиента вовлекается в проект с той же частотой: он всегда понимает, что нужно делать в каком порядке, и транслирует это команде.
  • Личное общение в команде лучше, чем согласование ТЗ.
  • Все это дает возможность глубже погружаться в бизнес клиента и более оперативно реагировать на изменения.

5. От чего придется отказаться?

Важно! В agile проекте не может быть фиксированного бюджета или фиксированного срока.

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

Agile проект: функциональный объем не определен точно – функции разрабатываемого решения добавляются, уточняются и удаляются в любой момент по ходу проекта. Без детального ТЗ нельзя оценить точно трудозатраты.

Фиксируется один из параметров:

  • Определяется приблизительно функциональный объем, по его достижению («система всех устраивает») проект прекращается. Стоимость и сроки – переменная величина.
  • Фиксируется бюджет и/или срок. Проект завершается по достижению заданных параметров в том функционале, что
    удалось реализовать за заданный бюджет.

Когда нельзя применять Agile?

  • Внедряемая система заменяет старую. Поскольку новая система создается и внедряется поэтапно, нормальная работа бизнеса нарушается: старая система уже не работает, новая еще не работает.
  • Большая команда (более 5 бизнес-экспертов). С ростом команды простая коммуникация (без детальных описаний процессов и согласований на всех уровнях) крайне затрудняется.
  • Нет «владельца продукта» со стороны заказчика (или его невозможно выделить). Без человека, который точно понимает, что конкретно надо реализовать в системе в первую очередь, невозможна тактика частой
    поставки продукта.
  • Нет доверия к подрядчику. В agile проекте невозможно точно оценить и зафиксировать бюджет. Работа по принципу Time&Material (оплата по фактически потраченному времени) в условиях недоверия некомфортна клиентам.

При этих вводных «водопадная» модель работает лучше.

Когда можно применять Agile?

  1. Создается новая система. До начала проекта функциональность отсутствовала, поэтому возможно запускать новую систему поэтапно: персонал и руководство клиента приветствуют более быстрое получение результатов.
  2. Разумный размер команды клиента. В небольших командах возможны ежедневные/еженедельные планерки, на которых согласуется содержание и функциональность, создаваемая на очередном этапе работы, а специалистам
    подрядчика напрямую уточнять у бизнес-экспертов детали реализации. Это позволяет сократить сроки за счет отказа от подробного описания.
  3. Есть доверие к подрядчику. Работа по T&M в таких условиях возможна и экономит бюджет.
  4. Особенно Agile полезен в том случае, если к началу проекта ожидания от системы у клиента не до конца ясны – например, автоматизируются бизнес-процессы, которых еще нет в реальной жизни компании. В этом случае работа постепенными приближениями еще сильнее спасает от работы на корзину, что обязательно случается в классических проектах: бизнес-экспертам, как и всем людям, сложнее придумать правильный процесс, чем рассказать тот процесс, что уже есть.

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