Если вам потребовалось создать собственный онлайн-магазин, интернет-сервис либо B2B-портал, надо выбрать разработчика, который выполнит ваш заказ. Представьте, что у вас две информационных компании с примерно одинаковым уровнем опыта. У каждой есть свои преимущества, свои технологии и специалисты… Однако при этом одна из двух фирм объявляет в качестве плюса следующее: «Мы трудимся по Agile!»
Для начала: что Agile даёт заказчику — повышенную прибыль или больше хлопот, чем обычно?
Agile — это более гибкая методика, которой пользуются разработчики. Весь процесс делится на множество небольших этапов, которые называются спринты. Обычно спринт продолжается от недели до месяца. Результат спринта — это всегда что-то, с чем заказчик уже в состоянии работать, так называемый инкремент продукта (product increment). Благодаря этому клиенту проще следить за разработкой на всём её протяжении. К тому же легче по ходу вносить корректировки, исходя из пожеланий заказчика и из внешних факторов, например меняющихся трендов.
Далее — плюсы, которые даёт применение Agile.
1. Нет постоянной волокиты
Применяя подход Agile, можно избавиться от технического задания (ТЗ) как неотъемлемого и обязательного элемента разработки. Казалось бы, как такое возможно? Ведь именно ТЗ обычно содержит объяснения по поводу того, зачем нужен тот или иной компонент, а также описание общей концепции.
Если клиент с самого начала желает действовать по ТЗ, это объяснимо. Но обычно чем дальше, тем больше становятся видны минусы. Ведь никуда не деться, например, от исправлений по ходу реализации. Например, дойдя до этапа подписания договора с системой, где требуется интеграция, команда сталкивается с тем, что ситуация изменилась: договор подписали не с той системой, с которой планировали, а с другой, и условия интеграции другие. Или просто поменялась ситуация на рынке либо в самой фирме заказчика — приходится учитывать и это.
Чтобы следовать строгому ТЗ, надо преодолеть несколько препятствий:
- ТЗ придётся продумать до мелочей. А учесть всё — попросту невозможно. Заказчик может с самого начала сохранять уверенность, что подробно описал все требования — но уже в ходе второй демонстрации он придумает что-то новое. И чтобы внести в ТЗ корректировки, надо изначально учесть их возможность. А также, само собой, заложить затраты времени с учётом впечатляющего резерва просто «на всякий случай».
- Надо заранее настроиться на то, что уйма времени и денег уйдёт впустую. Ведь они будут с самого начала потрачены на следование логике ТЗ, которое с наибольшей вероятностью будет переписано и перестроено.
- Внося корректировки, надо будет следить не только за самим ТЗ, но и за множеством дополнительных документов, корректируя по мере надобности и их. Иначе наступит ответственный момент внутреннего аудита и может возникнуть ситуация, когда заказчик объявит, что результат не соответствует ТЗ, а разработчик не получит оплату.
- Отдельная сложность — сделать так, чтобы составление подробного ТЗ не занимало несколько месяцев. Если проект крупный, то заказчику часто требуется согласовывать разработку с разными отделами и ответственными лицами. А они, в свою очередь, вносят свои замечания и предложения, причём экономить время в процессе — это не их забота, ведь у каждого из них есть свои дела. Как итог, можно столкнуться с тем, что ТЗ начнёт устаревать ещё до того, как удастся его утвердить, не говоря уж о начале реализации.
- Даже тем, кто не использует систему Agile, приходится проводить регулярные демонстрации. Ведь, чтобы протестировать все функции, нужно много времени. А время — всегда в дефиците.
- Что бы ни утверждали сторонники стандартного проектного подхода, чёткое следование ТЗ не помогает обнаружить проблемы с качеством. А вот гибкий подход подразумевает, что каждый спринт содержит инкремент ценности. И если со временем сценариев становится меньше или спринт становится финансово затратнее, то это и есть один из поводов задуматься о качестве: чем оно хуже, тем больше ресурсов уходит на корректировку.
Чем прост договор по Agile? Например, в договоре указано, что работа должна приниматься ежемесячно в рамках указанной детализации. Как итог, согласовывать и подписывать документ проще. Причём и клиент, и разработчик по-прежнему защищены от произвола.
Сам процесс получается прозрачным. Клиент в состоянии контролировать разработку на любом этапе. Только решения без волокиты принимать намного проще.
2. Двигаться «небольшими шагами» — дешевле и эффективнее
Когда на рынке появляется минимально жизнеспособный продукт (MVP), его проще адаптировать под нужды потребителей.
Прибыль всегда остаётся в фокусе. Используя MVP, можно сразу получить прибыль, а потом увеличивать её, с большей лёгкостью удовлетворяя запросы потребителей.
Отличительные черты Agile в веб-разработке
Применительно к данной сфере подход даёт следующие плюсы.
1. По продукту
Без Agile
Надо строго следовать плану, который включает:
- начальную проектную дату;
- конечную проектную дату;
- проектный бюджет.
Сначала необходимо предположить, каким должен быть идеальный проект (онлайн-магазин, приложение, портал и так далее), потом надо составить ТЗ для разработчика. И уже потом, когда ТЗ будет реализовано, можно принимать продукт в работу.
Собирать на демонстрации представителей всех отделов компании — это не избавление от проблем. Реальные потребности отразят только конечные пользователи. Однако для разработчика на первое место выйдет только следование ТЗ, ведь ему будет важнее будет соблюсти сроки и уложиться в бюджет.
На практике ТЗ почти всегда не учитывает какие-то важные детали. И пока разработчик трудится, на рынке уже появляется конкурентный продукт, более подходящий; условия рынка меняются, и задание устаревает.
С Agile
Фактически каждый спринт — это уже отдельный мини-проект. Его итог — лишь часть задуманных функций, но ими уже можно пользоваться. Конечно, сами по себе программисты от этого не начнут работать быстрее, зато они гораздо быстрее будут выдавать готовые к использованию MVP. Сделав за один-два месяца минимальную версию, можно сразу начинать её корректировать, учитывая произошедшие на рынке изменения. Готовый продукт гораздо проще будет сделать таким, чтобы он отвечал запросам потребителей.
Как только пользователи протестируют возможности MVP, от них поступит обратная связь. Если у продукта обнаружатся существенные недостатки, можно будет сразу это учесть и внести изменения — или, если надо, заменить продукт на новый. И это относится к каждой новой версии.
Система Agile недаром получила своё название (по-английски — подвижный, проворный). Ведь сама суть подхода — это и есть предельная гибкость, способность меняться и перестраиваться. Вносить изменения — дешевле и проще. Корректировка — обычное дело, а не что-то ужасное и вызывающее у всех дрожь. Продукт получается максимально отвечающим запросам пользователей. Отслеживать это помогает обратная связь, начиная от простых оценок и отзывов, заканчивая веб-анализом и изучением юзабилити проекта.
2. По процессу
Без Agile
Сделать разработку прозрачной и добиться адаптивности — изначально сложно. Ведь клиент не видит, что получается у подрядчика на всём протяжении его труда. Может быть, столь долгожданный продукт на деле станет сплошным разочарованием. Но и прерывать дело на середине нельзя — иначе окажется, что время и деньги были потрачены впустую.
Корректировать ТЗ — затратно и тяжело. Для этого надо согласовать объёмный документ со всеми инстанциями — это волокита. Зачастую даже составление начального ТЗ оказывается настолько трудоёмким, что заказчик уже и сам не захочет корректировать документ.
Для разработчика главным приоритетом становится стремление закончить в срок. Сложно ли будет вносить изменения потом, для него уже неважно. Это и есть один из главных минусов классического проектного подхода.
С Agile
Здесь конечный срок перестаёт быть определяющей категорией. В приоритете — продукт, который улучшают пошагово, по мере надобности. Сам процесс намного проще корректировать. Его можно даже остановить, если понадобится — тогда в качестве результата останется инкремент, то есть MVP, уже способный выполнять начальные задачи.
Разработчики подходят к делу ответственнее. Для них нет стремления просто успеть в срок. Если что-то будет сделано плохо, то справляться с этим придётся самим разработчикам — очевидно, что они заинтересованы с самого начала стремиться всё сделать хорошо. Ведь подрядчик будет получать оплату до тех пор, пока ему удаётся подтверждать: да, продукт всё ещё можно сделать лучше.
Применяя подход Agile, заказчик и разработчик взаимодействуют в рамках совещаний каждый день. Обратная связь быстрая, реакция на замечания — тоже. Даже если у клиента нет времени на обсуждение, он получает от разработчика отчёт по работе за день и может изучить данные, как только появится время.
3. По прибыли
Убыточный проект — это самый серьёзный провал. А чтобы этого не допустить, нужно сделать так, чтобы продукт соответствовал запросам потребителей.
Без Agile
Высокий риск неизбежен. Заказчик несколько месяцев или даже лет подряд тратит ресурсы, разрабатывая продукт, который может в итоге не окупиться. А узнать это можно только по окончании.
С Agile
Команда сразу сфокусирована на главных целях. Если свежие версии выходят регулярно, то также регулярно приходит и обратная связь. Опираясь на неё, проще корректировать продукт и повышать окупаемость.
Рентабельность — главный показатель успеха. Именно Agile позволяет окупить финансовые и временные инвестиции с наибольшей вероятностью.