В этой статье речь пойдет о гибкой методологии разработки применительно к системам дистанционного банковского обслуживания и их преимуществе перед традиционными подходами.
Зачем меняться?
В первую очередь хотел бы отметить, что, разумеется, нет смысла менять то, что хорошо работает и не вызывает нареканий у бизнес-заказчиков и конечных пользователей. Это относится к любому продукту или услуге.
К сожалению, такое случается не часто, и адаптивные изменения становятся не самоцелью, а жизненной необходимостью.
В чем же основные проблемы традиционных подходов к управлению проектами? Несомненно, они обладают некоторыми преимуществами и прекрасно работают в определенных случаях. Выбор оптимального подхода для разработки зависит в первую очередь от того, насколько хорошо определен конечный результат и насколько изучена предметная область, в которой идет разработка.
Для простых задач нет ничего более эффективного, чем waterfall. Процесс описан, разложен по полочкам, оптимально настроен. Использовать что-то другое для достижения цели – трата времени. Хотите сделать стул – пользуйтесь лучшими практиками, не нужно изобретать велосипед.
В более сложных случаях помогает проектное управление (PMI, Prince2 и им подобные). Хотите построить мост – спросите инженеров как, воспользуйтесь многолетними наработками и сделайте как надо.
Но существующие методологии плохо приспособлены к программной разработке сложных продуктов. В традиционных подходах есть необходимость продумать все максимально подробно в начале, они плохо реагируют на необходимость изменений. Все требования бизнес-заказчика являются некой абстракцией, которые все представляют по-разному. В итоге после тщательного и долгого планирования, разработки и тестирования выясняется, что заказчик хотел не совсем то, что получилось, какие-то требования вообще изменились за прошедшее время (принят новый закон, например), или необходимость в каком-то функционале исчезла, так как в мире появилась какая-то новая технология.
Нивелировать подобные риски призваны гибкие методологи разработки (Agile).
Что такое Agile и Scrum в частности
Тема эта весьма обширна и заслуживает не одной статьи, при желании в Интернете можно найти много материалов. Вкратце же agile-методологии – это нынешний мировой тренд в разработке программного обеспечения, с успехом применяющийся мировыми лидерами (Google, Microsoft и т.д.). Команды разработки фокусируются на business value, быстро и последовательно стараются предоставлять работающие части проекта заказчику. При этом фокус идет на людей и их взаимодействие, на работающий продукт, сотрудничество и быструю реакцию на изменения. Про контракты, процессы, инструменты, документацию, конечно, тоже не забывают, но все это отодвигается на второй план.
По статистике Standish Group, Agile-проекты в 3 раза более успешны (42% против 14%), чем проекты, ведущиеся по традиционным методологиям.
Следует упомянуть, что Standish Group использует классическое определение успешности проекта – on Time, Scope, Budget (треугольник менеджера).
Agile-фреймворки предлагают эмпирический подход. Что это значит? Не пытаться учитывать бесконечное множество переменных, как это предлагает делать PMBOK, создавая огромное количество практик и процессов с входами и выходами. Эмпирический подход не полагается на предсказания, а лишь на прогнозы, которые основаны уже на имеющихся фактических данных.
Пример предсказания: «Мы знаем, что команда не успевает, но к 27 мая мы “должны” реализовать вот “этот” функционал». В предсказании всегда есть попытка выдать желаемое за действительное, фантазию за реальность, вымысел за правду. Команда физически не готова работать с той скоростью, которой от нее ждут, и реальность притягивают за уши к желаемому.
Пример прогноза: «Команда работала на протяжении последних 2 месяцев со средней скоростью 20 абстрактных единиц в итерацию, поэтому мы прогнозируем, что к 27 мая может быть доставлено 100 единиц функционала».
Прогноз опирается на данные, полученные опытным путем в конкретных условиях и с конкретными людьми. Прогноз будущего строится лишь на таком основании. Прогноз не может быть плохим или хорошим, как и сама итерация. Это просто реальность.
Scrum – самый популярный на данный момент гибкий фреймворк, реализующий принципы эмпиризма. Суть его заключается в том, что продукт разрабатывается короткими итерациями, они называются спринтами (в нашем случае это 4 недели) с фокусом на получение полноценного инкремента продукта в конце каждой итерации. Присутствует жесткое ограничение по времени, постоянная продолжительность спринта привносит ритм в разработку. Новая функциональность проектируется, разрабатывается, тестируется на протяжении одного спринта. В его конце она полностью готова к выходу в релиз.
Scrum состоит из некоторого набора ролей, митингов и артефактов.
Команда разработки (Dev team) обычно состоит из 4–9 человек (программисты, аналитики, тестировщики, дизайнеры). Они ответственны за конечный результат разработки. В нашем случае это две команды от вендора Банк Софт Системс, решение которого используется у нас и в Интернете, и в мобильном банкинге.
Product owner (PO) – это человек, определяющий и приоритезирующий требования, исходя из их рыночной ценности. Он решает, что будет сделано в следующей итерации, несет ответственность за успешность и доходность продукта, руководит командой и принимает работу.
Scrum Master (SM) ответственен за внедрение практик, эффективность работы команды, защищает команду от внешних воздействий, учит остальную компанию (банк) взаимодействовать с командой, обеспечивает видимость и прозрачность всех процессов.
Каждый спринт начинается с планирования, на котором команда разработки и Product owner определяют, что и как будет сделано в следующей итерации. Ставится цель спринта – в чем будет заключаться конечное value для клиента. При этом скорость работы команды определяет объем работ. Попытки взять в спринт больше работы, чем может сделать команда, неизбежно будет вести к падению качества. Как бы этого ни хотелось, но невозможно заставить людей работать больше, чем они могут.
В конце итерации проводится обзор спринта, обычно в формате демонстрации, на который приглашаются все заинтересованные лица (в идеале – конечные пользователи тоже), собирается обратная связь. Частый сбор обратной связи и оперативное реагирование на нее является ключевым преимуществом гибкой методологии разработки – это позволяет скорректировать понимание бизнес-требований до того, как на движение в неправильном направлении было потрачено много времени, а также лучше управлять приоритетами на основе информации, полученной от заинтересованных лиц.
Конечно, это не полное описание фреймворка, существует много подводных камней, но для общего понимания этого будет достаточно.
Так в чем же преимущество?
Внедрение Скрама в нашем банке еще полностью не завершено, но определенно есть осязаемые, а не теоритические улучшения.
В PMBOK, например, качество является одной из переменных и может быть снижено, что на практике и происходит, когда в погоне за сроками на команду разработки оказывается давление. В Скраме же качество – это константа, она не снижается от спринта к спринту. Эмпирически оценивая скорость работы команд, мы определили тот максимальный объем работ, который возможно брать в спринт без угрозы потери качества.
С помощью Скрама мы стали максимально минимизировать риски. Каждый спринт – это отдельный проект (фиксированное время, стоимость и плавающий scope), на выходе которого имеем готовую новую функциональность. Мы больше не рискуем бюджетами больших проектов.
Задачи оценивают те, кто будет их выполнять. 60-летний опыт разработки программного обеспечения показывает, что подход, когда у исполнителей должен быть архитектор и менеджер, которые разбивают задачу на подзадачи, описывают элементы системы, устанавливают требования к ним, определяют порядок разработки и распределяют разработчиков, – не работает. Ни архитектор, ни менеджер не могут сказать, кто и за сколько сможет сделать ту или иную задачу. Переход к прогнозированию времени выполнения задач их исполнителями позволяет нам не тратить кучу времени на все равно несбыточные оценки.
Весь процесс разработки стал гораздо более прозрачным для бизнеса, мы можем быстро вносить изменения, проблемы быстро идентифицируются, есть возможность проверять результаты и реагировать на изменения.
Эмпирический процесс, который используется в фреймворке, позволяет минимизировать риск того, что мы сделаем абсолютно ненужный пользователям функционал, потратив на это много времени и ресурсов.
Согласно отчету той же Standish Group, 45% реализованных требований в ИТ-проектах никогда не используются. Приоритезация требований позволяет бороться с рисками, мы фокусируемся на самом важном для клиента в данный момент функционале, можем реализовать минимальную ценную часть продукта (MVP) для проверки реакции пользователей, не тратя много ресурсов. Согласно правилу Парето, 80% ценности продукта содержится в 20% требований. Если мы реализуем 20%, то повышается вероятность доставить что-то ценное, при этом не увеличивая бюджет. Регулярная переоценка позволяет в каждой итерации корректировать направление развития продукта.
Команда разработки присутствует на обзорах спринта, это способствует вовлечению в процесс, «боли» клиентов становятся более понятными разработчикам, они перестают существовать в вакууме, их отношение к продукту меняется. Команда становится заинтересованной в успешности продукта. К сожалению, при работе с вендорами часто приходится сталкиваться с обратным.
Зачастую все заинтересованы в успешных проектах, а не продуктах. Но конечным пользователям абсолютно безразлично, был ли проект успешен или нет, уложился ли он в заявленные сроки или стоимость. Все, что интересует любого из нас, когда он пользуется чем-либо, – это продукт. Если он успешный, то люди им пользуются и покупают, если же нет – уходят и находят более качественный и/или удобный аналог.
Фокус Скрама направлен на разработку высококлассных качественных продуктов, которые должны радовать конечных пользователей (нас с вами) и приносить удовлетворительный ROI их создателям.