Практическая конференция Agile,DevOps,ITSM 2018

«Туннели» под Ла-Маншем: как избежать проблемы нестыковок проектов цифровой трансформации

В 1994 году был открыт «Евротуннель» протяженностью более 50 км, состоящий из двух железнодорожных и одного служебного пути. Одной из основных проблем при строительстве была точность стыковки британской и французской бригад, погрешность которой по вертикали и по горизонтали не должна была превышать 2,5 метра, в противном случае пришлось бы соединять два рукава при помощи зигзагообразной связки, что привело бы к удорожанию проекта и резкому снижению скорости поездов на искривленном участке. Как известно, в результате строительства погрешность составила 35,8 сантиметров по горизонтали и 5,8 сантиметров по вертикали. Подобное происходит сейчас в большинстве организаций, вставших на путь цифровой трансформации – точность «стыковки» проектного офиса, бизнес-аналитиков и разработчиков решений ключевым образом влияет на будущие результаты и стоимость решения. «Зигзагообразной связкой» при этом является терминология, используемая в BABoK, PMBoK, Agile@Scale и ITSM когда разными словами обозначают идентичные понятия, правда, в отличии от строительства туннелей, этот зигзаг можно выправить. Доклад посвящен обсуждению проблем нестыковок в проектах цифровой трансформации, разбору возникающих трудностей и путей их преодоления.

DevOps и Agile: вместе или врозь?

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

Как побороть страхи Agile-трансформации?

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

Портал госуслуг: госпроект с яркой историей и свежим вектором развития

Портал государственных услуг Российской Федерации – самый посещаемый сегодня государственный ресурс в Рунете и вполне естественно, что к надежности инфраструктуры его поддержки и системе сопровождения предъявляются особые требования. Доклад посвящен обсуждению вопросов построения процессов разработки, способных обеспечить требуемую нагрузку на Портал и особенностей применения гибких методологий в условиях государственной системы контрактов. Разбираются пять обязательных правил, без которых невозможно создание и сопровождение Agile-систем в государственных организациях, а также дается описание направлений дальнейшего расширения присутствия государства в пространстве Сети.

Формирование DevOps-команд: этапы, проблемы, производительность

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

Без права на ошибку

Библиотеке ITIL уже несколько десятилетий, процедуры и процессы ITSM открыты, отлично прописаны, проработаны давно стали классикой сервис-менеджмента, однако путь от теории к практике не выстлан розами и реализовать потенциал известных методологий удается далеко не каждой организации. В задачу ITSM-управления ГБУ «Инфогород» входит обеспечение ДИТ Москвы инструментами организации эксплуатации и поддержки сотен информационных систем, обеспечивающих управление и жизнедеятельность мегаполиса. Специфика работы управления связана с непрерывным развитием и модернизацией ITSM- ядра – информационной системы, реализующей процессы поддержки и эксплуатации и работающей в режиме 24х7. Еще совсем недавно в очереди на модернизацию ITSM-ядра стояло более 150 запросов от десятков структурных подразделений ДИТ Москвы, что, при существовавшей ранее скорости обработки в 5-6 запросов в месяц, означало три года работы, при условии, что за это время новых запросов поступать не будет (в реальной ситуации приходит 5-10 запросов еженедельно). Оперативное выполнение в непрерывном режиме большого количества запросов на модификации без нарушения работоспособности смежных подразделений ДИТ Москвы не оставляет ITSM-управлению право на ошибку. Доклад посвящен изложению опыта построения инфраструктуры непрерывной разработки, модификации и запуска в промышленную эксплуатацию процессов организации создания и тестирования информационных систем, позволившей на порядок увеличить скорость выполнения запросов (до 8-10 в неделю), сократив при этом жизненный цикл релиза с двух- трех месяцев до полутора-двух недель. Особое внимание уделено обсуждению секретов синтеза уже известных методологий ITSM и других подходов к управлению (Lean-management и др.) для получения действительно гибкого ITSM-ядра, позволившего команде ГБУ «Инфогород» организовать практически параллельное тестирование, линейно увеличивая темпы разработки и внедрения в зависимости от числа разработчиков.

Возможен ли DevOps в корпоративной среде?

Многие корпорации приступили к DevOps-трансформации своих ИТ-департаментов, надеясь сделать из них свой аналог Google, однако на этом пути их подстерегает множество препятствий. Какие ошибки совершают компании на пути трансформации? Что такое культура DevOps и зачем она нужна? Доклад посвящен ответам на эти и другие вопросы, неизбежно возникающих у корпораций, вставших на путь DevOps-трансформации.

Эффективность разработки без магии и ГМО

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

Веб-ориентированный подход для ДИТ

При разработке масштабных информационных систем часто возникает ситуация, когда решение бизнес-задач упирается в невозможность вовремя реализовать нужный функционал и вместо результата от сотрудников департаментов информационных технологий (ДИТ) бизнес слышит отговорки типа: «система еще не готова к перезапуску», «сотрудники ИТ распланированы на ближайшие два года, приходите в конце пятилетки» и пр. Доклад посвящен анализу проблем, стоящих сегодня перед ДИТ, особенностям построения корпоративной инфраструктуры, тонкостям развития и эксплуатации крупных веб-проектов. Особое внимание в докладе уделено изложению опыта взаимодействия с крупнейшими заказчиками из ретейла или финтеха, а также сравнению традиционного подхода к разработке и веб-ориентированного («web-driven») подхода.

Особенности цифровой трансформации банков

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

Дюжина разгневанных заказчиков: как расставить приоритеты?
ИТ – это очень ценный, дорогой и дефицитный ресурс, из-за которого между бизнес- подразделениями зачастую разворачиваются ожесточенные войны. В ход пускаются такие аргументы как важность для бизнеса конкретной доработки, актуальность определенной модернизации и пр. доводы в пользу ускорения выпуска соответствующих релизов приложений или развертывания аппаратной инфраструктуры. Как правильно, понятно и прозрачно для всех расставить приоритеты выполнения работ, основываясь на их ценности для компании в целом? Пройдя через множество споров и войн, мы выработали свой подход, успешно применяемый и по сей день. Доклад посвящен изложению опыта приоритизации решения задач ретейлера на основе принципа вычисляемых значений работ Weighted Shortest Job First (WSJF).

Как достичь высот ITSM?
Большинство предприятий начинают приступать к развертыванию процессов ITSM с операционных процессов и по мере повышения уровня зрелости переходят к реализации жизненного цикла сервисов, что часто чревато потерей множества возможностей для инноваций. Например реализация операционных аспектов ITSM приведет к стабилизации сервисов, но пока вся организация не будет охвачена целостной системой поддержки жизненного цикла сервисов, эффект окажется достаточно скромным. Как показывает опыт, подобных нюансов в ИТ сервис-менеджменте не мало – доклад посвящен изложению ретроспективного опыта развертывания процессов ITSM как со стороны бизнеса, так и функциональных подразделений в компаниях различной отраслевой принадлежности и форм собственности. Особое внимание уделено разбору преимуществ и проблем, возникающих при развертывании процессов ITSM в компаниях, находящихся на разных уровнях зрелости.

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

Новая операционная модель цифровой организации
Цифровая трансформация диктует организациям необходимость развития новых компетенций, причем в самом широком смысле понимания англоязычного термина «capabilities»: современная цифровая архитектура, таланты, культура, прорывная бизнес-модель и, конечно, новая операционная модель. Чтобы не повторить судьбы многих крупных компаний – бывших лидеров, не сумевших пережить предыдущие промышленные революции, надо изучить их опыт, особое внимание уделив важности трансформации процессов и операционной модели. В докладе анализируются существующие эффективные операционные модели, сочетающие в себя лучшие подходы, в том числе, Agile, DevOps и ITSM, а также разбирается имеющийся практический опыт в области цифровой трансформации.

Практики гибкого управления при работе с государственными заказчиками
Развертывание и эксплуатация информационных систем в государственном секторе существенно отличается от аналогичных проектов в коммерческих предприятиях: основания для работ по автоматизации, варианты финансирования, изменение рамок проекта и его бюджета, формирование команды проекта, наличие «пожизненной» отчетности по проекту, «сезонность» при работе с госсектором и др. Все это накладывает свои ограничения на применение Agile и Scrum в государственных структурах, вплоть до того, что некоторые организации и органы государственной власти, отдавая уважение эффективности применения гибких методик, ошибочно уверены в их неприменимости для государственного сектора. Однако, использовать гибкие техники в госсекторе можно, но с учетом ряда нюансов: не следовать одной универсальной методике, учитывать особенности зон ответственности государственного чиновника за последствия запуска информационной системы, применять понятный для чиновников язык представления архитектуры и пр. Доклад посвящен изложению тонкостей выполнения Agile-проектов на государственных предприятиях. Особое внимание уделено разбору конкретного опыта выполнения проекта в принадлежащем федеральной корпорации по развитию малого и среднего предпринимательства банке содействия малому бизнесу и предпринимательству («МСП Банке»), в наблюдательный совет которого входят руководители Министерства экономического развития РФ.

Современная разработка ПО. Взгляд из мира ITSM
Раньше считалось, что бизнесу нужны ИТ-системы для улучшения работы бизнес-процессов, потом оказалось, что бизнесу нужны ИТ-услуги, чтобы скрыть сложность ИТ, а теперь выяснилось, что бизнесу нужны цифровые продукты, которые помогут его клиентам решать свои задачи через цифровую трансформацию, пользовательский опыт, омниканальность, большие данные, машинное обучение (вычеркнуть лишнее, добавить недостающее). Как бы то ни было, все сводится программному обеспечению, а где ПО – там и разработка. Однако людям из мира ITSM некоторые вещи, понятия и правила, принятые в разработке ПО, кажутся странными и забавными. О них и идет речь в докладе. Особое внимание уделено организационным мерам устранения каждой такой странности.

Ретейлер цифровой экономики: управление разработкой
Ни для кого не секрет, что большой проект электронной коммерции – это не в последнюю очередь, ИТ-проект. Перешагнув порог в 100 тыс заказов в сутки компания Wildberries столкнулась с ситуацией, когда законы организации и функционирования классического монолитного ИТ-отдела уже не отвечают ожиданиям бизнеса. Кроме страданий разработчиков и головной боли бизнес-заказчиков масла в огонь подливало отсутствие на рынке достаточного количества квалифицированных ИТ-специалистов. Так начался путь компании в мир, как уже позже стало понятно, Agile, а позже мы назовем свой подход к разработке "естественным Agile". Проект оказался настолько увлекательным, что вышел за рамки ИТ – идеями Agile проникся бизнес и сегодня в каждом департаменте компании имеется свой ИТ-отдел с прямым подчинением бизнес-департаменту. Доклад посвящен опыту компании Wildberries по созданию среды гибкой разработки. Особое внимание уделено анализу конкретного опыта – плюсами и минусами Agile-подхода, а также особенностями его применения в ретейле.

Возможен ли Agile без технического совершенства?
Многие компании сталкиваются с тем, что любые изменения в процессах разработки рано или поздно перестают приносить плоды – это может произойти хотя бы по причине дальнейшей невозможности и\или дороговизны модернизации программного кода, когда выпуск каждого релиза означает экзекуцию и драму. В докладе на конкретных примерах объясняется, почему так происходит и почему «внедрение Agile процесса» не помогает, а только усугубляет ситуацию. Любое изменение процессов, продуктов, состава и конфигурации команд результата не дает, потому что такие изменения лишь одна часть формулы успеха. Особое внимание в докладе уделено другой части – инженерным подходам.

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

За чей счет DevOps-банкет?
Кто и зачем заказывает DevOps-проекты? Как сократить Time-to-market, издержки и повысить качество ИТ-решений? В докладе ответы на эти и другие вопросы. Особое внимание уделено разбору реальных кейсов и анализу деталей выполнения проектов DevOps.