Аджайл, скрам и другие: что получает ИТ-бизнес

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

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

С таким тезисом совершенно согласен Сергей Стрелков, руководитель направления собственных разработок компании КРОК: повальное использование гибких методик началось даже не в текущем году, а несколько раньше, считает он.

«Однако в 2016 г. об этом стали говорить чаще, активнее и вплоть до первых лиц отдельных компаний, — отмечает он. — Тем временем в области разработки программного обеспечения методология аджайл уже давно и плотно вошла в практику, в этом направлении совершенно точно нет отставаний от запада. Исключением являются лишь госконтракты. Например, в Великобритании от разработчиков, которые участвуют в гостендерах, почти наверняка будут ожидать применения Agile или Scrum, у нас, к сожалению, пока к этому не пришли».

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

Agile стало таким же размытым понятием как Big Data, уверен Михаил Иванов, директор центра банковских технологий компании «Техносерв», так как т.к. Agile — это некие описанные идеи и принципы, которые могут соблюдаться полностью, а могут частично. Поэтому для сервисов, ориентированных на рынок, есть понимание, считает он, что нужно стремиться в сторону Agile. Но в будущем Agile не займет полностью всю разработку. Например, разработку/доработку систем отчетности по требованиям ЦБ проще, дешевле и качественнее сделать стандартным поэтапным водопадом, подчеркивает Иванов.

Иван Голенев, генеральный директор компании Univef, тоже отмечает, что допустимость Agile-методов во многом зависит от типа заказчика: «Например, госструктуры законодательно вынуждены формулировать свои требования в рамках классической методологии через составление технического задания и разработку стандартной проектной документации, и там гибкие методы вряд ли будут популярны в массовом порядке».

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

Скорей всего, применимость методологии зависит не только от формы собственности и вида бизнеса клиента. «Эффект бывает двоякий, — говорит Евгений Колесников, руководитель направления „Большие данные и машинное обучение“, компания „Инфосистемы Джет“. — Если заказчик активно участвует в гибком процессе, он получает возможность эффективно влиять на то, каким получается его продукт, и это отлично. Если же команда будет работать по Agile, а заказчик — нет, то обе стороны ждет разочарование. Клиент начнет подозревать, что процесс никогда не сойдется, а команда разработки — что заказчик сам не знает, что хочет получить».

Интерес к Agile действительно вырос, считает Алексей Лапшин, генеральный директор компании «АйТи. Бизнес-решения» (ГК АйТи), но «говорить, что именно большинство ИТ-компаний научилось работать по этой методологии, нельзя. Просто есть на рынке компании, которые изначально работали с Agile и у них, как правило, с этим все прекрасно, а есть те, кто только учиться и начинают это делать. Клиенты методологией Agile также интересуются, но часто им не хватает понимания, что именно дает эта методология и как ее правильно применять».

Алексей Ионов, профессиональный и Agile-коуч, EPAM, видит ситуацию шире: «Многие компании запустили у себя (в том числе с нашей помощью) одну или несколько Agile-команд и разобрались в большей или меньшей степени, как эти подходы работают или могут работать на уровне команды. Но сейчас в полный рост встает задача масштабирования этих подходов как минимум на уровень портфеля проектов, а как максимум — на уровень всего бизнеса, и тут достаточно много вызовов, с которыми приходится считаться. На таком уровне уже недостаточно знать Agile-манифест или Scrum-гайд, нужно нечто большее, некоторое инновационное видение, новые принципы существования организации». Это путь, который еще предстоит пройти большинству компаний, полагает Ионов, но альтернатива в виде потери рынка еще менее привлекательна, чем сложности, которые нужно преодолеть.

Давно ли это было?

Путь, который российские ИТ-компании уже прошли по дороге аджайл, довольно длинный и непростой.

Евгений Колесников: «Элементы того, что позже стало называться Extreme Programming, а еще позже — Agile, мы применяли в своих проектах еще в конце 90-х годов».

В EPAM гибкие технологии разработки применяются с момента их появления во второй половине 90-х, вспоминает Алексей Ионов.

Сергей Стрелков: «Само направление разработки ПО развивается в компании около 20 лет, мы начинали с методологии Microsoft solutions framework, а со временем добавили туда также элементы Rational unified Process и Agile. Последнее произошло около 10 лет назад».

«В „ЛАНИТ-ТЕРКОМ“ гибкие методики разработки ПО мы применяем около восьми лет, — говорит Татьяна Елисеева, директор департамента промышленных систем „ЛАНИТ-ТЕРКОМ“ (группа компаний ЛАНИТ). В основном это, конечно, реализация процессов на базе Scrum. Также есть некоторый опыт применения Kanban».

Иван Голенев: «Первоначально мы применяли классический подход к разработке ПО, поскольку большую часть времени занимались заказной разработкой под требования конкретного клиента и опирались на так называемые лучшие практики и каскадную модель разработки программного обеспечения. Вместе с тем около трех лет назад мы стали замечать, что все больше заказчиков хотят как можно быстрее начать получать отдачу от проекта создания автоматизированной информационной системы. И тогда Univef начала использовать комбинированный подход, при котором традиционные методы разработки программных продуктов сочетаются с итерационными».

Более двух лет работают по аджайл в «Техносерв», три с половиной года — в компании «АйТи».

«В нашей компании сфера разработки появилась относительно недавно, однако, несмотря на это, мы являемся исполнителями по ряду крупных проектов, в том числе Lattelecom, — отмечает Александр Мютель, директор департамента программных решений «Сервионики» (ГК «Ай-Теко»).

Организация работы

Когда спрашиваешь ИТ-руководителей, реализован ли у них ITIL, они обычно отвечают: «Да, конечно, только мы его локализовали для себя». Степень и вид такой «локализации» может быть самым причудливым, требования практики всегда перебивают предписания теории. Похоже, так же точно дело обстоит и с гибкими методологиями.

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

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

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

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

Татьяна Елисеева отмечает, что практически во всех проектах «ЛАНИТ-ТЕРКОМ» применяются основные принципы работы по аджайл. В основном это Scrum и его вариации. При этом есть небольшие проекты как по размеру команд, так и по длительности, а есть многолетние проекты, в которых одновременно работает 4-5 и более скрам-команд, есть удаленные команды на стороне заказчика.

Что делается «гибким способом»?

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

Гибкие технологии управления проектами применяются в ИТ для решения, в первую очередь, инновационных задач, подчеркивает Елена Литвинова: «Это такие задачи, в которых мы не знаем точно, что именно хочет получить заказчик или как этого добиться. Особенность работы здесь такова, что „идеальный продукт“ не нужен. Нужно как можно быстрее показать „условно готовый“ продукт заказчику, чтобы получить его реакцию, оценить удобство использования и продолжить доработку в нужном направлении».

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

Методологии разработки сами по себе фактически не зависят от сферы их применения, отмечает Александр Мютель: «Если говорить об области применения самой разработки ПО, то сюда входят и решения по разработке различного системного ПО, и разработка пользовательских приложений, веб-сайтов различного масштаба».

В «Техносерв» по гибкой методологии ведется ряд «пилотов и разработок для заказчиков из банковской сферы, телекома и ритейла. Основная сфера применения гибких методологий разработки ПО, считает Михаил Иванов, это создание клиентоориентированного ПО, являющегося фронтом взаимодействия компании и ее клиентов (физические или юридические лица). Сфера применения — там, где необходимо минимальное время вывода на рынок».

Этот же параметр — время вывода — как критичный фактор выбора методологии называет и Алексей Ионов, приводя примеры: дистанционное обслуживание клиентов и развитие цифровых каналов продаж. «Это относительно новое направление, что позволяет ему быстро развиваться, не затрагивая „исторический“ слой существующих систем», — отмечает он.

«АйТи» ведет в аджайл в основном заказную разработку или доработку и внедрение коробочных решений.

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

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

Организационные изменения

Насколько быстро можно научиться работать в аджайл? Насколько это сложно, каких потребует изменений?

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

Примерно так же было и в «ЛАНИТ-ТЕРКОМ». «Серьезных организационных изменений не происходило, но у нас, например, никогда и не было излишних уровней иерархии в компании — отмечает Татьяна Елисеева. — Скорее идет процесс пересмотра ролей различных специалистов и некоторое перераспределение зон ответственности и обязанностей».

В других компаниях этот пересмотр был весьма существенным.

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

Организационные изменения касаются уровня команд: их члены перестают делиться на постановщиков и исполнителей требований, появляется больше сотрудничества, поясняет Алексей Ионов, и замечает: «Это не так просто для тех, кто много лет работал по „классике“, когда постановка задач существовала отдельно, генерируя требования на сотни страниц еще до того, как разработка пробовала реализовать хоть одно из них в точном соответствии с документацией. Но в первую очередь я отмечу необходимость изменения образа мышления: на смену „начальник-исполнитель“ приходит совместная работа ради достижения цели».

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

Эту технологическую сторону дела особо отмечает и Сергей Стрелков: «Кроме регулярного обучения, которое мы проводим, также очень важны элементы процесса разработки, связанные с автоматизацией конвейера доставки ПО — от размещения исходного кода в системе контроля версий до установки в продуктивной среде. Важным здесь является использование принципов continuos integration/delivery/deployment и test driven development, а также автоматизация регрессионного и нагрузочного тестирования». Только применение подобных практик позволяет регулярно, эффективно и в короткие сроки поставлять заказчику значимую для него функциональность с высоким уровнем качества«.

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

«Мы активно привлекаем специалистов из показавших себя команд для передачи коллегам опыта в области управления разработкой и поддержкой уже выпущенного продукта, — говорит он. — Речь идет не только об Agile, но и о бережливой разработке (DevOps), непрерывной интеграции (Continuous Integration). На стыке динамичности разработки в стартапах и отлаженных процессов Enterprise-разработки мы выстраиваем свои практики». Так что технологическая часть разработки критически важна для применения гибких методик. Но этого явно мало.

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

Экономический эффект

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

Татьяна Елисеева: «Нельзя сказать: „Работаешь по аджайл, значит гарантированно сдаешь проекты в срок“. Это не совсем так. Agile — это набор принципов, которые помогают выстраивать эффективный процесс работы как внутри команды разработки, так и в общении с заказчиком и понимании его потребностей. Итогом данной работы должна быть и является удовлетворенность заказчика результатом и успешно завершенный проект».

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

При этом аджайл подразумевает открытость процесса разработки, что требует существенной зрелости самого клиента, подчеркивает Колесников. «Если он готов работать гибко в обратной связи с нами, это, безусловно, пойдет на пользу финальному результату. Что касается наших собственных продуктов, то применение аджайл дало существенное ускорение в удовлетворении требований существующих заказчиков. Немаловажным фактором является необходимость быть „в тренде“ и оперативно реагировать на новые возможности в продуктах конкурентов».

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

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

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

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

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

Хочется надеяться, что ИТ-компании при всем этом выиграют больше всех. Ведь это они первые придумали такой подход к делу, не правда ли?