Agile трайб




Проекты в сфере data science и разработка соответствующих продуктов командой data scientists требуют использования эффективных методик. Одной из таких методик является эджайл (agile).

Содержание страницы

Для чего применяется методология Agile?
  • Ускорение вывода продукта на рынок. Если вы хотите что-то сделать быстрее, нужно делать это в соответствии с Agile. Очень простой пример. Есть две компании, у них примерно одинаковый бизнес. Одна пишет ТЗ, затем проектирует систему и рисует дизайн — это водопадная модель, на разработку которой может уйти несколько месяцев. Во второй компании, работающей по Agile, к этому времени может быть уже запущен сайт, выпущено ПО, она начнет зарабатывать деньги и захватывать рынок, что самое главное.
  • Управление изменениями в приоритетах. Это, пожалуй, весьма болезненная проблема практически для всех компаний. Если вы делаете проект, который длится хотя бы несколько месяцев, то у вас обязательно поменяются требования. Конечно, если это не софт, например, для спутника или марсохода. Хотя даже спутникам и марсоходам обычно заливают свежую версию софта, когда они прилетают в точку назначения. Если говорить про коммерческую разработку, то проблема в том, что программисты, аналитики и дизайнеры, никогда не знают, что нужно не только заказчику, который им платит, но и пользователям. Обычно все подходят к вопросу так: пока пользователь не попробует функционал сайта или приложения, вы не знаете, нужен он или нет.
  • Улучшение взаимодействия между IT и бизнесом. Это головная боль, особенно для крупных компаний, ведь у бизнеса периодически меняются требования, каждый говорит на своем языке. В результате стороны друг друга не понимают.

Ответом на все эти вызовы явился Манифест гибкой разработки ПО.

Манифест гибкой разработки

Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

  • Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается — рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры — JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
  • Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
  • Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время — материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
  • Готовность к изменениям во взвешивании со следованием первоначальному плану.

В Agile есть план, оценки и прогнозы. Но если у вас есть какой-то первоначальный план для годового проекта, а вы через три месяца уже предоставили какую-то версию продукта, пользователи его пощупали, вы сняли метрики, посмотрели, что и как они используют, узнали что-то новое, то после этого первоначальный план можно почти полностью поменять.

12 принципов Agile

Ценности влекут за собой 12 принципов Agile :

  1. Наивысшая ценность — это удовлетворение потребностей заказчика благодаря регулярной и максимально ранней поставке ценного для него ПО. Если заказчик хочет получить от нас большого слона, но мы можем дать ему часть этого слона не через год, а через три месяца, потом еще через три месяца еще одну часть, а затее ежемесячно выдавать кусочки, то чем чаще мы это будем делать и чем раньше, тем лучше.
  2. Мы всегда готовы изменять требования, даже на поздних стадиях проекта, если узнаем что-то новое. Таким образом, мы создаем бизнесу или внешнему заказчику конкурентное преимущество. Допустим, работают две компании: одна написала ТЗ и за год сделала продукт, а мы сделали концепцию продукта (неважно, в каком виде) и постепенно его выкатываем и раскатываем. Тогда наш продукт будет больше соответствовать требованиям заказчиков, пользователей и рынка в целом.
  3. При использовании Agile работающий продукт выпускают максимально часто. В манифесте прописаны сроки — от пары недель до пары месяцев. На самом деле это неделя/месяц, если вы используете Scrum. В России чаще всего каждые две недели выпускается что-то новое. А если делают какой-то веб-проект, то обычно используют одну из вариаций Kanban, значит, релизы можно делать каждый день.
  4. Бизнес обязательно должен работать вместе с программистами, помогать им понять специфику данного рынка. Если вы работаете в банке, то вам требуется понимание принципа работы банка в целом и очень подробные сведения о той сфере, за которую вы отвечаете. Наиболее частой проблемой является недоступность бизнеса — когда разработчик не может получить у сотрудника нужную информацию. При использовании Agile важно избегать возникновения подобных ситуаций.
  5. Команда — один из краеугольных камней Agile. Наилучших результатов достигает команда замотивированных профессионалов. Есть гениальное замечание о том, что эффективность Scrum зависит от руководителя. В Agile руководитель прежде всего должен создавать условия для команды и обеспечивать всестороннюю поддержку, проводить коучинг, следить за атмосферой в коллективе.
  6. Есть много исследований, которые показывают, что лучшее общение — лицом к лицу. Причем желательно, чтобы было какое-то средство визуализации, на котором можно писать: лист бумаги, доска со стикерами и т.д. Самый простой и эффективный способ узнать требования клиента, заказчика или пользователя — поговорить с ними.
  7. Работающий продукт. Степень готовности проекта должна измеряться не словами, не тем, что ТЗ уже написано и 50% макетов нарисовано, а количеством функционала, выпущенного в production.
  8. В Agile важен ритм, постоянные улучшения. Бизнес и программисты всегда должны иметь возможность делать процесс устойчивым, постоянно его улучшать.
  9. Про этот пункт менеджеры обычно не любят говорить разработчикам, но Agile вообще не будет работать, если вы написали быдло-код. У вас должна быть хорошая гибкая архитектура, в которую можно добавлять разные элементы и при необходимости легко их изменять. И если команда не будет уделять максимум внимания техническому качеству (писать хороший код, использовать инженерные практики, автоматизировать процессы), то никакого Agile у вас не будет.
  10. Простота. Она проявляется в технической составляющей, в дизайне. Это один из принципов экстремального программирования. Простота очень важна также с точки зрения выпуска продукта: когда вы хотите «нарезать» того «слона», лучше начать с простой части.
  11. Менеджер (руководитель, Scrum-коуч, Agile-коуч) в команде меняет свою роль: он не столько занимается организацией процесса, сколько учит команду, поэтому команда должна быть самоорганизованной. Есть специальные стратегии, как из группы людей сделать самоорганизованную команду.
  12. Команда должна постоянно анализировать свою работу, процессы: что получилось, как они этого добились, и постоянно улучшать организацию работ.

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

Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов.

Таким образом, можно использовать такой принцип и методологию agile в data science командах и проектах.

Sbergile в формате постоянных перемен

Кирилл Мартыненко, директор по процессам ИБ Сбербанка, эксперт BISA

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

Agile как стиль управления

Буквально год назад многие специалисты начали активно использовать понятия Scrum и Agile. Что же под ними подразумевается, и как это можно использовать?

Agile представляет собой гибкую методологию, а точнее – концептуальный подход к разработке программного обеспечения. Понятие Agile закрепилось в современном формате в феврале 2001 г., когда был принят так называемый Agile Manifesto, который и является основополагающим документом для Agile. Со времени создания «манифеста» в философию Agile было включено множество методологий и концепций – это и Scrum, и экстремальное программирование, и часть Lean-технологий.

В свою очередь, понятие Scrum появилось примерно 20 лет назад, когда Кен Швабер и Джефф Сазерленд решили создать собственную методологию разработки программного обеспечения для технологических отраслей. Название данной методологии, которое переводится как «схватка», авторы позаимствовали из американского футбола. Сделано это было после краха других методов управления, применявшихся в то время.

Достаточно долго Agile и Scrum не обсуждались в широких кругах, хотя эти подходы использовались, например, Федеральным бюро расследований США, компаниями Google и Facebook. А рассуждения о гибкости относились, в первую очередь, к ИТ-подразделениям, в частности к тем, которые занимаются разработками. Считанные единицы специалистов ИБ-отделов видели в своей работе что-либо иное, кроме трекеров задач подразделений и проведения сессий вопросов/ответов с сотрудниками, поскольку безопасность всегда считалась достаточно закрытой сферой. Кроме этого у в отечественной сфере ИБ еще и отчетливо ощущается влияние профильных ведомств, с которыми подразделениям информационной безопасности приходится плотно взаимодействовать: «Какая гибкость? Какая свобода действий? О чем вы! Главное – четкий приказ, желательно письменный, и его беспрекословное выполнение».

Так почему же все-таки возник серьезный интерес к Agile и почему именно сейчас? Все очень просто: мир меняется, ландшафт угроз тоже, появляются новые технологии и новые потребности бизнеса. Если продолжать использовать классические методы управления, то уже к тому моменту, когда ИБ-подразделение согласует и представит какой-либо новый продукт, он окажется неактуальным и отстающим от требований бизнеса на несколько месяцев, а то и лет. Сейчас необходимость трансформировать продукт возникает еще до того момента, когда он попадает на первичное тестирование, и специалисты по ИБ должны всегда отвечать «конечно, без проблем, давайте поменяем концепцию», а не упрямо твердить «нет, это запрещено требованиями безопасности».

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

Путь преодоления

С чем же пришлось столкнуться на практике команде кибербезопасности Сбербанка уже сейчас, в то время, когда основные проекты в рамках Agile (или Sbergile, как его называют в Сбербанке) еще не очень сильно затрагивают ИБ-службу? В первую очередь, это были страх и непонимание.

Ранним майским утром в одном из кабинетов службы кибербезопасности Сбербанка внезапно появилась деревянная доска, разделенная цветным скотчем на полоски, на которой висели несколько бумажек. Увидев ее, все сотрудники Управления стандартов и процессов информационной безопасности, вовлеченного в эксперимент, улыбались, но на всякий случай обходили эту доску подальше.

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

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

В течение недели сотрудники с опаской посматривали на бумажки, на которых они сами (это является крайне важным психологическим фактором) написали собственные фамилии как «имена исполнителей», а в пятницу собрались на первый SCRUM Управления. Эта встреча позволила решить очень многие психологические проблемы – люди начали общаться друг с другом, обсуждать «чужие» задачи, узнавать об имеющихся проблемах. Уже в ближайший понедельник несколько задач, которые оставались в замороженном состоянии долгие месяцы, были решены. Как? Кто-то из сотрудников выяснил «на стороне», кому можно позвонить, чтобы попросить помощи, кто-то услышал полезный совет от коллег, а кто-то просто понял, что нет ничего страшного в том, что ты чего-то не знаешь или не умеешь.

Каждая следующая неделя лишь усиливала позитивный эффект работы в функциональных командах. А эффект создания продукта каждую неделю, пусть и не в итоговом варианте, значительно сократил время согласования результатов работы с конечными заказчиками, для которых, в первую очередь, эта работа и выполнялась. Сотрудники Управления, которые раньше даже не имели представления о том, что происходит в соседнем кабинете, вдруг начали помогать друг другу решать теперь уже общие задачи. Причем это происходило без наличия письменного официального поручения.

Так Agile поселился в Управлении стандартов и процессов информационной безопасности службы кибербезопасности Сбербанка и стал нормой поведения для каждого из сотрудников.

Усложняем и совершенствуем

Наверняка многие из вас скажут: ну хорошо, появились доска и еженедельные встречи, но использование таких подходов – лишь часть Agile. А где же все остальное?

Именно об этом подумали и в службе кибербезопасности Сбербанка, поэтому сейчас она стремится к трансформации в полноценный трайб со своими кластерами и функциональными командами (скводами и чаптерами). Делается это, опять-таки, не потому, что появилось какое-то распоряжение руководства, а потому, что данные методики действительно продемонстрировали свою эффективность.

В качестве инструмента автоматизации деятельности трайба было выбрано давно зарекомендовавшее себя на рынке решение Atlassian JIRA, и уже сейчас в системе имеется более 100 активных задач. В ближайшие несколько месяцев их количество вырастет в разы: пока инструмент действует только в пределах одного Управления, но уже очень скоро решение будет масштабироваться в расчете на всю службу кибербезопасности.

Следующими шагами «эволюции» станут работа в спринтах и расчет задач по story point’ам. Они будут учитываться, в том числе, в системе мотивации персонала по итогам квартальной и годовой оценок.

Итоговыми целями являются обеспечение в службе кибербезопасности полноценного управления Change с использованием Agile-практик, а также решение оперативных задач (Dev Ops) Security Operations Centre и подразделения, занимающегося предотвращением случаев мошенничества. Цели – достаточно амбициозные, но нет сомнений в том, что уже в текущем календарном году удастся достигнуть положительных результатов в данных направлениях.

Скептики, возможно, сочтут такие методы неподходящими для России, но у подхода Agile нет географических рамок, и он не привязан к менталитету какого-либо народа. Кроме того, кое-кто неизбежно заявит, что для реализации Agile, как любого другого проекта, нужны деньги. Ответить на это заявление можно конкретными цифрами: в службе кибербезопасности Сбербанка первый бюджет «Agile как проекта» составил ровно 5 тыс. руб., потраченных в магазине на канцелярские принадлежности и цветной скотч.

Итак, в первую очередь, важно желание что-то сделать либо изменить, а методы реализации и средства на это всегда найдутся. Скоро использование Agile станет такой же нормой, как установленный на каждом устройстве антивирус или изменяющиеся раз в несколько десятков дней пароли – в этом нет никаких сомнений. А вот где (в авангарде или в арьергарде) окажетесь вы в тот момент, когда Agile станет мэйнстримом, – решать только вам.

McKinsey: Как банк ING встал на Agile-рельсы

McKinsey: Как банк ING встал на Agile-рельсы

Летом 2015 года нидерландская банковская группа ING начала программу преобразований, чтобы перейти от традиционной организационной модели к адаптивной (Agile) схеме работы, построенной по примеру таких компаний, как Google, Netflix и Spotify. Благодаря новой структуре и модели работы банковской группе удалось ускорить вывод новых продуктов на рынок, повысить уровень вовлеченности персонала и увеличить производительность труда.

Кейс Agile-трансформации ING является знаковым не только для финансовой отрасли Нидерландов или Европы. ING первым из крупных традиционных корпораций отважился не просто на локальные эксперименты с новыми подходами в области управления, а на комплексную Agile-трансформацию, которая охватывает все направления бизнеса и тысячи сотрудников.

Еще более важно, что вся организация откликнулась на изменения, показав именно те результаты, ради которых затевалась вся трансформация: повысилась удовлетворённость клиентов, сократились издержки. ING впервые стал работодателем #1 в Нидерландах, опередив не только другие финансовые институты, но и Google, традиционно занимающий первые строчки в предпочтениях соискателей.

Зачем банку новый подход к работе

Когда в июне 2015 года ING начал внедрять модель Agile, у банка не было особого финансового стимула для трансформации — компания показывала хорошие результаты. Но поведение и ожидания клиентов уже менялись: на них влияли новые цифровые сервисы и лидеры цифровых технологий из других отраслей.

Руководители ING решили разобраться, как взаимодействовать с клиентом в новых условиях многоканальной работы, а не просто продвигать продукты. Приоритет банка — качественно обслуживать клиентов по всем направлениям: чтобы клиенты могли обратиться через один канал, а потом продолжить взаимодействие через другой — например, зайти в отделение за кредитной консультацией, а потом оформить кредит по телефону или через сайт.

Чтобы реализовать эту стратегию, ING требовалось организовать работу по принципам Agile, свести к минимуму бюрократию и дать сотрудникам необходимые полномочия. Менеджмент хотел сделать компанию гибкой, чтобы она быстро адаптировалась к изменениям и самостоятельно ориентировалась в новых реалиях. Цель — помочь сотрудникам стать более разносторонними и квалифицированными профессионалами.

Внедрение Agile не ограничивается изменениями только в ИТ-отделе или другом подразделении. Главное — придерживаться принципа «сквозного процесса» и создавать междисциплинарные команды, которые работают над удовлетворением потребностей клиента и объединены общим пониманием успеха. В такие команды входят маркетологи, специалисты по продуктам, коммерческие специалисты, UX-дизайнеры, специалисты по ИТ и анализу данных.

Как стать лучшими в своем деле

Если у талантливых молодых людей спросить, где они мечтали бы работать, почти всегда они назовут Facebook, Google, Netflix, Spotify и Uber. Интересно, что все эти фирмы работают в разных отраслях и ориентированы на разные цели — медиабизнес, поиск в интернете, организация перевозок. Их общая черта — особый подход к работе и яркая корпоративная культура. Они работают в небольших группах, которые объединены общей целью, следуют Agile-манифесту, тесно взаимодействуют с клиентами и всегда готовы вносить изменения в то, над чем работают.

Руководители ING осознали, что работают в технологической компании — только в сфере финансовых услуг, и начали искать ответ на вопрос, как стать лучшими в своем классе. Поскольку у других банков не было такого опыта, они наблюдали за подходами технологических компаний, чтобы адаптировать их к особенностям банковского бизнеса.

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

Ключевые элементы преобразований ING

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

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

Цель ING — выпускать новые релизы программ намного чаще: каждые две недели вместо пяти-шести крупных обновлений в год. Интеграция процессов разработки продуктов и эксплуатации ИТ-систем помогает им создавать продукты с инновационными характеристиками.

Новая модель управления персоналом.

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

Банковская группа добилась результатов в каждом из этих аспектов. Они выпускают релизы каждые две-три недели, а не пять-шесть раз в год. Чистый коэффициент лояльности (NPS) и показатели вовлеченности сотрудников тоже заметно возросли.

Начало преобразований головного офиса

От разработки стратегии и видения до внедрения новой организационной модели работы в масштабе всего головного офиса прошло около девяти месяцев:

  1. Сначала компания проработала видение и изучила опыт ведущих технологических компаний.
  2. Затем определила целевую организационную модель с новой «нервной системой»: для этого потребовалось два месяца и пять выездных совещаний совета директоров.
  3. Параллельно банк создал шесть пилотных команд: на основе этого опыта они корректировали организационные решения, условия работы и общую структуру.
  4. После этого они сосредоточились на практической реализации: подборе сотрудников, подключению их к работе и реорганизации офисов.

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

Банк оставил в стороне отдел кадров, финансовую службу, отдел управления рисками, а также отделения, колл-центры, операционный блок и ИТ-инфраструктуру. Это не значит, что эти подразделения не перешли на модель Agile: просто в них адаптивность проявляется иначе.

Например, в операционном блоке и колл-центрах компания создала самоуправляемые команды, как в Zappos. Их ответственность возросла, а контроль со стороны руководства стал менее пристальным, чем раньше. Параллельно ING внедрил ежедневные стендапы и другие гибкие приемы работы для сотрудников службы продаж и сети отделений: так руководители подталкивали их двигаться в сторону Agile.

Функциональные подразделения — юридическая служба, финансовая служба и отдел управления операционными рисками — остались независимыми и не задействованы в Agile-командах напрямую. Но команды обращаются к ним за помощью и объективными советами.

Конечно, можно начать с ИТ-отдела и постепенно двигаться в сторону бизнеса: ИТ-специалисты проверят и доработают концепцию, прежде чем она будет внедряться более широко. Однако в ING уверены, что внедрение можно начать с любого направления и потом расширять его в сторону бизнеса и ИТ. Любая из этих моделей работоспособна.

Что действительно невозможно по мнению топ-менеджеров банка — выборочно внедрять разные элементы Agile-подхода: это бессмысленно и только усложняет работу. Например, иногда формально принимается адаптивный подход, но при этом сохраняется существующая оргструктура и система управления.

Новая организационная модель

Новая модель работы ING начинается со сквода. Каждый сквод должен:

  1. Письменно сформулировать цель, для достижения которой он работает.
  2. Определиться со способом измерения эффекта для клиентов.
  3. Решить, как управлять повседневной работой.

Скводы входят в трайбы, в которых используются дополнительные инструменты: скрам, канбан-доски для планирования и ежедневные стендапы. С помощью этих механизмов работа согласовывается с владельцами продуктов и даёт ощущение причастности. Вся организация была разделена примерно из 350 скводов по девять человек, сгруппированных в 13 трайбов.

Для синхронизации на уровне трайбов банк проводит квартальный обзор бизнес-результатов ( Quarterly Business Review — QBR ), как в Google и Netflix. Каждый трайб описывает, чего достиг за прошедший квартал и какие основные выводы сделал, отмечая не только достижения, но и неудачи. Во время такого обзора команды формулируют цель на следующий квартал и указывают, с какими трайбами или скводами будут сотрудничать для ее достижения. Все трайбы имеют свободный доступ к документам QBR. В компании поощряют комментарии и обратную связь — эта информация также свободно распространяется во всем банке. В ING прошли уже более десятка QBR, но руководство уверено: несмотря на улучшения, еще есть над чем работать.

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

Например, разработка мобильных приложений банка — отдельный трайб со своим руководителем и Agile-коучем. В трайб входят три сквода: по одному на каждую популярную мобильную платформу — iOS, Android и Windows Phone. Каждый сквод объединяет разработчиков, маркетологов, дизайнеров, продуктовиков и других специалистов: всего девять человек. Специалисты одного направления из разных скводов составляют чаптер: например, дизайнеры приложений для iOS, Android и Windows Phone — это чаптер дизайна мобильных приложений.

Тысячи программистов Сбербанка переехали в новый офис Agile Home. ФОТО

Содержание

Тысячи программистов Сбербанка переехали в новый офис Agile Home

По состоянию на середину мая 2017 года в новый офис Сбербанка в Москве, который обустраивается под работу команд в Agile-формате, переехали более 4 тыс. человек. Переезд продолжается. Об этом рассказала TAdviser Agile-коуч Сбербанка Наталья Поляченко.

Новый офис Сбербанка под названием Agile Home полностью займет здание бизнес-центра по адресу Кутузовский проспект, д.32/1. В нем насчитывается 16 этажей. В перспективе здесь смогут работать порядка 9-10 тыс. сотрудников Сбербанка, говорит Поляченко. По состоянию на май введены в строй 1-й, 3-6 и 12-15 этажи здания.

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

Каждый «трайб» состоит из 15 команд, включающих примерно по 10 человек. Они работают над задачами спринтами со сроком в две недели каждый, рассказала Поляченко.

При этом ранее бизнес и ИТ-сотрудники существовали по-отдельности, а теперь обе этих стороны представлены в одной и той же команде и вместе работают над продуктами. Наталья Поляченко рассказала TAdviser, что по состоянию на май примерно 25% сотрудников в новом офисе — представители бизнеса, а 75% — представители ИТ.

Инфраструктура нового офиса выстроена и вокруг «трайбов», и отдельно — вокруг команд. Пространство офиса организовано так, что команды, с одной стороны, являются достаточно изолированными друг от друга, а с другой — находятся близко друг к другу.

На 15 этаже Agile Home, где побывал TAdviser, по состоянию на май размещены два «трайба» — цифровых продуктов и массовой персонализации. Помимо рабочих мест для сотрудников здесь есть конференц-зона, переговорные комнаты, будки для телефонных переговоров или разговоров тет-а-тет и др.

Основная цель Agile-трансформации — ускорить вывод новых продуктов на рынок. Руководитель блока «Розничный бизнес» Сбербанка Александр Торбахов отметил в разговоре с TAdviser, что при работе по старой модели от появления идеи до выхода продукта на рынок может проходить до 2 лет. По модели Agile Сбербанк планирует укладываться в несколько месяцев.

Agile-трансформацию Сбербанк начал с розничного бизнеса. Александр Торбахов заявил TAdviser, что по состоянию на май на разработку по методологии Agile переведены уже практически все розничные продукты.

По состоянию на май 2017 года сформирован один трайб и по корпоративным продуктам — для среднего и малого бизнеса, рассказала Наталья Поляченко TAdviser.

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

Перевести разработку на Agile в полном объеме по розничному бизнесу планируется до конца 2017 года, рассказал Торбахов TAdviser.

Источник фото в этом материале — TAdviser.

Три офиса в Agile-формате

Сбербанк приспособил свой новый офис в доме 32 на Кутузовском проспекте под работу в методологии Agile. Такая модель подразумевает создание внутри офиса кросс-функциональных команд для более быстрого и эффективного выполнения задач.

Как рассказала в интервью TAdviser генеральный директор компании «Сбербанк-Технологии» Алиса Мельникова, первая волна Agile-трансформации была проведена с розничным блоком банка и охватила более 1100 сотрудников СберТеха. До конца 2017 года, по её словам, планируется вовлечь в Agile и другие блоки.

Результатом уже проделанной работы стал рост скорости и качества взаимодействия бизнес-подразделения розницы и разработчиков, говорила Мельникова.

Для создания нового офисного пространства Сбербанк пригласил три российских архитектурных бюро, которые независимо друг от друга реализовывали свои решения на трех этажах нового московского офиса.

Проект IND Architects

На 15 этаже проект выполняла команда IND Architects [1] , которая в 2013 году уже реализовала офис под Agile для «Альфа-Банка» — «Альфа Лаборатория». Офис разделен на шесть частей, связанных «кольцевой дорогой», которая позволяет лучше ориентироваться в пространстве и быстрее добраться до нужного пункта.

Площадь этажа составляет 7 тыс. кв. м. Каждая из шести частей офиса полностью автономна и создана по единой схеме: здесь есть open-space по фронту остекления, в ядре — переговорные разных типов, лаундж, кофе-поинт и санузлы. Расчет сделан на то, чтобы тратить минимальное количество времени на перемещения по офису и не отвлекаться от сосредоточенной работы. Все функциональные пространства, которые потребуются командам, есть под рукой в шаговой доступности.

Каждая из шести зон разбита на блоки. В одной зоне может работать примерно десять команд.

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

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

Проект Aurora

В представлении архитектурного бюро Aurora офисное пространство нового типа подразумевает предельную гибкость: удобство в формировании команд, возможность самоорганизации и постоянное двухуровневое взаимодействие. [2]

Первый уровень – так называемые скводы (англ. squad) – это самоорганизующиеся рабочие группы, состоящие из 10-15 специалистов разного профиля, своего рода маленькие стартапы. Второй уровень – трайбы (англ. tribe), в которые объединяются скводы. Для четырех трайбов на этаже выделены зоны совместной работы, каждая из которых вмещает порядка 200 человек.

Изначально здание было спроектировано под апартаменты, поэтому этаж был разделен на противопожарные отсеки, которые не предполагали свободное перемещение по нему людских потоков. С помощью инженерных и технических решений удалось выдержать все пожарные нормы и требования и учесть нужды типового трайба: для его успешного функционирования нужны порядка восьми переговорных, один coffe point и два вендинговых автомата.

Эргономичное планировочное решение позволило сделать офис просторным и обеспечить комфортные условия для работы: удобные рабочие места по фронту остекления, зоны отдыха и неформального общения, зоны коворкинга и кофе-поинты, библиотеки и блоки с переговорным с маркерными досками на стенах и встроенными системами хранения – все в ядре офиса. На 14-ом этаже размещено наибольшее количество рабочих мест — около 750, что отвечало требованию технического задания.

Проект «Адетэйл»

Еще один этаж был доверен архитектурному бюро «Адетэйл» [3] .

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

Сама структура офиса подчиняется общей формации рабочих групп – так называемых сквотов. Один сквот состоит из 8-10 человек, которые работают над конкретной задачей. Глобальные вопросы требуют объединения сквотов вместе и формируют новую единицу – трайб. Таким образом, фиксированных рабочих мест в офисе нет, а есть много зон для работы сквотов и возможность объединить их в трайбы.

Для удобства масштабирования пространства архитекторы прибегли к использованию раздвижных перегородок, которые делят как открытые пространства, так и переговорные комнаты (которых в офисе насчитывается 37) на несколько зон либо объединяют их в единое помещение.

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

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

В офисе есть 4 кухни и 11 кофепоинтов, где сотрудники могут перекусить и отдохнуть. Большое количество неформальных зон для работы, как, например, диваны-купе, пуфы и пр., создают ощущение «типичного» офисного пространства.

Герман Греф: Agile – это самая радикальная трансформация за всю историю Сбербанка

В сентябре 2016 года на сайте Сбербанка был размещен видеоролик, в котором президент банка Герман Греф рассказывает о преимуществах и задачах предстоящей Agile-трансформации.

Если раньше Agile был способом написания программного кода, то сегодня – это способ существования всех организаций, отметил он.

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

Греф считает предстоящую трансформацию колоссальной, самой радикальной за всю историю банка.

Завершая выступление, Герман Греф признался, что с каждым днем «у нас все больше уверенности в том, что мы будем успешны». На этой фразе позади президента Сбербанка один из участников мероприятия зевнул.

Пилотные проекты Agile-трансформации

В июне 2016 года Сбербанк решил нанять компанию-консультанта для подготовки детальной программы трансформации структуры и модели управления на основании целевой модели Agile-организации.

Соответствующий запрос предложений [4] был объявлен 24 июня, а выбор победителя состоялся 8 июля.

Начальная цена контракта составляла 345 млн руб. На тендер поступило три предложения. Самое дорогое — за 345 млн рублей — от компании McKinsey, победителя предыдущего тендера Сбербанка на обучение топ-менеджеров основам Agile (см подробнее ниже). С заявкой на сумму 340 млн рублей на запрос предложений откликнулась компания Bain & Company, а за 99,999 млн рублей готовность оказать услуги Сбербанку изъявила Boston Consulting Group (BCG).

Сбербанк выбрал победителем McKinsey. Boston Consulting Group набрал наименьшее количество баллов несмотря на минимальную цену заявки.

По итогам выполнения работ, которые запланированы до 31 января 2017 года, McKinsey получит 120,7 млн рублей. Еще 224 млн рублей Сбербанк выплатит в случае выполнения ключевых показателей эффективности (их суть в ТЗ Сбербанк не раскрыл).

McKinsey должен будет подготовить предложения по изменению структуры, функций и управляющих процессов Сбербанка с целью перехода к целевой модели Agile-организации. Требуется также детально описать инструменты Agile-организации для внедрения в первой волне (на основе утвержденной целевой модели и подходов к трансформации) и описать организационный периметр первой волны.

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

По ожиданиям Сбербанка, новая структура и модель управления банком должны обеспечивать радикальное сокращение продолжительности создания новых продуктов (time to market). Управленческие решения должны разрабатываться и приниматься с высокой скоростью, система управления банком должна стать дешевле, а инновационная деятельность — интенсивнее.

Обучение топ-менеджеров основам Agile

В течение апреля 2016 года McKinsey учила топ-менеджеров Сбербанка принципам бимодальной и Agile-организации. Компания одержала победу на оказание таких услуг в соответствующем конкурсе с заявкой на сумму 53,9 млн рублей [4] . Начальная цена составляла 55 млн рублей. Конкурентами McKinsey на конкурсе были Deloitte, Accenture и EMC.

Наряду с обучением в рамках контракта McKinsey определяла целевую модель Agile-организации для Сбербанка. Это необходимо для того, чтобы в дальнейшем разработать программу трансформации структуры и модели управления на основе принципов бимодальной и Agile-организации в банке.

От McKinsey требовалось описание возможных организационных моделей, подходов к трансформации модели управления и структуры банка на основе принципов Agile и бимодальной организации и проведение диагностики банка с точки зрения готовности к трансформации и выбору наилучшего подхода (в т.ч. с точки зрения HR-готовности, ИТ-готовности, зрелости основных процессов управления, реалистичности изменений в корпоративной культуре — на основе ранее проведенной диагностики корпоративной культуры), подготовлены рекомендации по выбору подхода, разработан план трансформации.

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

Греф — главный двигатель Agile-подхода

О планах трансформации Сбербанка в январе 2016 года говорил президент банка Герман Греф.

Использование Agile-подхода в практике бизнеса

Использование Agile-подхода в практике бизнеса

Последнее время у всех на слуху Agile-подход к проектной деятельности в организации. Со стороны упрощенное содержание данной методологии легко понять, но несмотря на это ключевой преградой на пути внедрения Agile в практику бизнеса является непонимание того каким образом его можно встроить в текущие бизнес-процессы, как будет организована деятельность работников в новых, гибких условиях. В статье рассмотрено содержание agile-подхода, конкретизированы роли участников agile, приведена характеристика ключевых процедур, которые используются в данном подходе, проанализирован опыт Сбербанка в этой области, так как данная организация одна из первых в отечественной практике масштабно внедрила agile методологию в своей деятельности, смогла по-новому организовать работу сотрудников Розничного и ИТ-блоков.

Автор

Руслан Алексеевич Долженко, д.э.н.

Ключевые слова:

Инновации, управление проектами, agile, гибкая методология разработки, банковские продукты.

Конкуренция как ключевой двигатель рыночной экономики не статична, она также развивается, проявляет себя в разных аспектах, заставляя бизнес постоянно пересматривать акценты в своих целях. Увеличение прибыли как ключевая детерминанта остается неизменной, но средства ее достижения постоянно меняются: максимизация производственных мощностей, налаживание отношений с клиентами, социальная ориентация бизнеса, успешный бренд и другие. В современных условиях, когда любая идея может быть скопирована, любой ресурс найден на рынке, успешными могут быть только такие организации в основе которых лежит уникальная управленческая концепция. Как отметил в одном из своих выступлений Г. Греф, руководитель крупнейшего банка РФ: «Нет никакой конкуренции товаров, продуктов или услуг. Есть конкуренция моделей управления и она развивается совершенно колоссальными темпами».

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

Одним из таких подходов к максимально быстрой, гибкой разработки продуктов и осуществления услуг является agile-методология, которую еще называют гибкая методология разработки. Несмотря на ее преимущества в виде скорости и гибкости, данный подход является крайне формализованным, в нем качественно отработаны все элементы, все процедуры, четко прописаны все роли, которые могут осуществлять участники. И если изначально данный подход появился в области разработки программного обеспечения, то сейчас его рассматривают как особый подход к реализации проектной деятельности в организации. В какой-то мере, можно говорить об agile-империализме, связанном с продвижением agile-методологии сначала в смежные, связанные с ИТ, затем в более отдаленные области. За счет своих преимуществ ее пробуют использовать в области бизнеса, в проектной деятельности, в образовании, в государственном управлении. Одним из первых в отечественной бизнес-практике масштабно, применительно к отличной от ИТ сфере деятельности, agile-методологию начал использовать Сбербанк России. Анализируя опыт данной компании можно понять в чем заключаются преимущества данного подхода, какие процедуры он предусматривает, с какими трудностями может столкнуться практика на пути внедрения agile. Именно этому и будет посвящена данная работа.

Цель статьи – рассмотреть особенности agile-методологии, описать возможности ее использования в банковской отрасли, конкретизировать содержание процедур, ролей, артефактов, предусмотренных в данном подходе. Данное направление крайне актуально для отечественного бизнеса, который понимает, что производство и реализация продуктов, осуществление услуг без опоры на ИТ имеет крайне мало перспектив, и значит нужно осваивать новые подходы к организации своей деятельности.

Понятие и сущность agile методологии

Что такое Agile? В переводе с английского это слово означает «шустрый, проворный, быстрый». Так называется семейство методологий создания продуктов, базирующихся на четырех ценностях, известных как Agile Manifesto, опубликованных в августе 2001 году. Вот эти ценности:

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

Помимо этих 4 ценностей в манифесте выделяются 12 правил Agile:

  1. Наивысший приоритет — удовлетворение потребностей заказчика;
  2. Изменение требований приветствуется;
  3. Продукт следует выпускать как можно чаще;
  4. Ежедневно работать вместе;
  5. Мотивированные профессионалы;
  6. Непосредственное общение;
  7. Работающий продукт;
  8. Поддерживать постоянный ритм;
  9. Постоянное внимание к техническому совершенству;
  10. Простота — искусство минимизации лишней работы;
  11. Самоорганизующиеся команды;
  12. Поиски улучшения эффективности.

И, наконец, можно выделить три базовых принципа гибкой разработки:

  1. Прозрачность. Процесс должен одинаково пониматься всеми его участниками. Все участники процесса должны пользоваться общей терминологией. Те, кто выполняет работу, и принимает итоговый результат, должны иметь общее представление о критериях готовности продукта.
  2. Инспекция. Участники процесса должны часто инспектировать ключевые моменты работы, отслеживать прогресс достижения цели проекта для своевременного выявления нежелательных отклонений. Однако, инспектирование не должно быть настолько частым, чтобы мешать работе и должно проводиться квалифицированными специалистами в области гибкой разработки.
  3. Адаптация. Если в ходе инспекции было сделано заключение, что один или более аспектов процесса отклонились от допустимых норм, а производимый продукт может стать неприемлем, то необходимо внести изменения либо в процесс, либо в рабочие материалы. Изменения должны вноситься как можно раньше для уменьшения риска последующего отклонения от нормы.

На ценностях и принципах Agile основана деятельность таких лидеров как Google, Microsoft, Amazon. Некоторые отечественные компании, в первую очередь IT, все более активно используют данную методологию. Но лишь одна крупная компания решила внедрить agile‑методологию в свою практику, речь идет о Сбербанке, организации, которая создала собственный Agile-фреймворк в блоке «Технологии» совместно с Розничным блоком и начала использовать гибкие подходы в своей деятельности. По сути, пока еще частично, но Сбербанк можно обозначить как agile-организацию.

Agile организация – это объединение максимально самодостаточных самоорганизующихся кроссфункциональных команд, которые обладают всеми инструментами, навыками и полномочиями для удовлетворения определенной потребности клиента и используют гибкие методы разработки продукта (Scrum, Kanban, Design Thinking, Lean Startup и др.) при максимальной автоматизации внедрения (с помощью таких инструментов как DevOps, Continuous Delivery и др.) и максимальной гибкости поддерживающих процессов (HR, закупки, финансирование и др.).

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

Часто, когда говорят об agile-методологии, упоминают такое понятие как Scrum. Scrum – набор базовых элементов и правил, предназначенный для продуктивного и творческого создания продуктов с максимально возможной ценностью и для решения нетривиальных задач.

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

Рисунок 1. Сравнение эффективности Agile-команд и команд, работающих по всем другим методам разработки ПО

Таким образом, если судить о количественных показателях эффективности использования agile по совокупности ИТ-предприятий, то налицо явное повышение результативности команд. Как обстоят дела с качественными результатами, насколько люди, задействованные в agile-проектах, испытывают удовлетворенность от того, что им приходится работать в новых условиях? Результаты исследований показывают, что участники подобных проектов отмечают значительные улучшения от внедрения Agile (рисунок 2).

Рисунок 2. Улучшения, которые обеспечивает использование agile в бизнесе

Источник: 10-й отчет о состоянии адаптивных методик разработки (State of Agile Report), подготовленный в 2016 г. компанией VersionOne; 1 321 проектов отраслевой базе данных Numetrics о программном обеспечении; примеры клиентов

Отметим, что в данном исследовании речь идет о результатах использования гибких, адаптивных методик разработки программного продукта. В нашем случае мы будем рассматривать возможности не просто использования agile в процессе разработки, но перестройки принципиальных подходов к организации деятельности работников, подразделений, функциональных блоков банка (а в потенциале и всей деятельности финансовой организации).

Agile-проекты не всегда оказываются успешными. Как показывает практика, некоторые подобны проекты не принесли должного эффекта. Основные причины неудачной реализации проектов agile приведены на рисунке 3.

Рисунок 3. Top-5 основных причины неудачной реализации проектов Agile (в %)

Как видно из рисунка 3 тот факт, что руководству удалось реализовать начинания по внедрению agile еще не говорит, что эта деятельность приведет к успеху в проектах. Если культура компании противоречит ключевым принципам agile, о которых было сказано ранее, если у работников нет опыта в применении данных методов, а руководство не поддерживает начинание, то можно с определенной уверенностью спрогнозировать, что внедрение agile в итоге окажется неудачным.

Каковы барьеры на пути внедрения методологии agile в практику бизнеса? Согласно 10-й отчета о состоянии адаптивных методик разработки, который был подготовлен в 2016 г. компанией VersionOne, ключевыми барьерами являются (Рисунок 4):

Рисунок 4. Top-5 барьеров для широкого внедрения Agile (в %)

Источник: 10-й отчет о состоянии адаптивных методик разработки (State of Agile Report), подготовленный в 2016 г. компанией VersionOne; интервью в ING

Как видно из рисунка, ключевым барьером на пути внедрения Agile является инертная, консервативная культура организации, отсутствие возможности ее изменить. Общее для людей сопротивление переменам также не способствует эффективному использованию agile-методологии. На третьем месте жесткая модель работы, не позволяющая гибко реагировать на потребность в изменении деятельности и продукта.

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

  • вовлечение бизнес-заказчика – возможность выделения на стороне бизнес-подразделения сотрудника, который будет отвечать за продукт, выступать в роли его владельца, т.е. принимать итоговый результат;
  • команда и её окружение – возможность создания кросс-функциональных (включающих все необходимые компетенции (аналитики, дизайнеры, архитектор автоматизированной системы, разработчики, тестировщики, администратор тестового стенда, администратор автоматизированной системы)) команд размером 5-9 человек и вовлечения всех участников процесса от производства до сопровождения;
  • система и её окружение – архитектура системы должна обеспечивать возможность работы с атомарными задачами, гибкое управление требованиями и безопасные частые внедрения.

С учетом обозначенных моментов можно сделать вывод, что несмотря на кажущуюся эффективность, интерес бизнеса к agile, который во многом перегрет вниманием массовой общности практиков, внедрение данной методологии должно быть крайне продуманным, учитывающим все системные последствия коренного изменения подходов к организации деятельности проектных команд. Несмотря на обозначенные сложности в отечественной практике есть пример внедрения agile в крупнейшей финансовой организации, речь идет о Сбербанке. Рассмотрим, что подвигло данную компанию на такое масштабное изменение, которое затронуло розничный и ИТ блок.

Текущие масштабы использования Agile-методологии в Сбербанке, промежуточные итоги по ряду территориальных банков

Во-первых, можно выделить следующие вызовы, которые обусловили необходимость внедрения Agile в Сбербанке:

  1. Низкая скорость внедрения изменений, например, данные о Time-to-market (время от начального замысла нового продукта до его внедрения на рынок) по некоторым продуктам представлены в таблице 1.

Таблица 1 — Время от начального замысла до внедрения на рынок по некоторым продуктам Сбербанка