Agile *

Всем доброе утро!
Сегодня мы поднимем такую интересную тему, как DevOps Governance в Enterprise.

В современных реалиях не так просто прийти к бизнесу и сказать: "Давайте всё автоматизируем, и всё будет хорошо!" Нет, это так не работает, особенно в крупных компаниях. А если у Вас ещё и нет единого процесса внесения изменений, то каждый будет кто в лес по грибы, кто домой за скатертью-самобранкой приходить и навязывать свои идеи.

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

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

Гибкие методологии давно заняли свое место в разработке программного обеспечения. Но эйфория свободы и самоорганизации постепенно рассеялась. Выступили подводные камни и неудобные пружины Scrum. Подтвердилось, что Kanban годится только для японского сборочного конвейера. А в манифесте Agile все читали только половину (ту, что слева). Концептуальные противоречия с заказчиком не исчезли. Очевидно, нужна новая методология.

В настоящее время в интернете много эфирного времени посвящено обсуждению различных достоинств масштабирования Agile и ведущих подходов в этой области: Scaled Agile Framework (SAFe http://www.scaledagileframework.com) и Large Scale Scrum (LeSS http://www.craiglarman.com/Large-Scale_Scrum ).

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

На бумаге …

SAFe основан на работе Дина Леффингвелла (Dean Leffingwell), и был формализован в виде фреймворка в 2011 году. Я работал с Дином в 2008 во время руководства командой консультантов в одной крупной многонациональной компании мобильной связи, помогая им определить и внедрить ранний подход к планированию Agile Release Train (ART)  –  то, что теперь эволюционировало в SAFe.

Меня зовут Тимур Исхаков, я технический директор в Ak Bars Digital. Мы отвечаем за развитие ИТ Ак Барс Банка. 

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

С 2018 года мы стали работать по SAFe: стримы, каналы, бизнес-юниты — вот это вот всё. И как результат — в 2021 году Ак Барс Банк занял 4 место в рейтинге самых инновационных банков России, а мобильное приложение Ак Барс Онлайн 3 года подряд входит в ТОП-3 лучших мобильных банков по версии Markswebb. 

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

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

Я назвал этот формат командной ретроспективы - восхождение на гору Фореверест. Задача, которую я ставил перед собой при разработке данного формата - вовлечь всех участников команды в сам процесс ретроспективы, узнать именно их мнение и услышать именно их идеи. Не знаю, как вы, а я сталкивался с тем, что традиционные форматы ретро не позволяют раскрыть потенциал каждого - то времени не хватает, то сам формат помогает молчунам оставаться в тени. Я пробовал разные форматы, но всегда приходил к выводу, что они устраивают меня не в полной мере. А что команды? Команды тоже были не против попробовать что-нибудь новое. Итак, требования к новой форме проведения ретроспективы, помимо вовлеченности, стали: понятность правил, легкость развертывания, хорошее соотношение затраченного времени на полученный результат, скорость обработки полученной информации. Составив список требований, я принялся визуализировать концепт.

Начнем с образа. Обычно это таблица в разных вариациях столбов и колонок. Я решил использовать объединяющую фигуру - круг. Из образа круга сам собой появился образ горы - просто наложил несколько окружностей друг на друга. Образ горы, как понятная и яркая цель. Окружности стали шагами - что-то типа «пять почему», бросил веревки для наших альпинистов - линии движения участников. У каждого свой маршрут, ребята будут подступаться к горе с разных сторон, но цель у них будет общая - добраться до вершины и встретиться там. И когда вы всё это расскажете команде, которая первый раз в жизни видит такой формат, дайте им минутку собраться с мыслями, силами, возможно задать вопросы и получить на них ответы, и только потом начинайте восхождение.

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

Добрый день! Меня зовут Денис Окулов, заместитель руководителя направления по функциональной экспертизе PROF-IT GROUP. С 2008 года я специализируюсь на внедрении и развитии решений на базе SAP и 1С, и за это время я реализовал свыше 20+ проектов для ведущих промышленных предприятий в России и СНГ.

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

Сегодня «модным» запросом рынка становится технология «переезда» с SAP (и аналогичных западных решений) на 1С ERP в кратчайшие сроки, и речь идет о считанных месяцах (месяца 3-4). Более того, у некоторых заказчиков есть желание провести все еще быстрее. Но логика обстоятельств не позволяет играть со сроками, так или иначе, и заставляет считаться с объективными трудностями этого процесса.

Даже при выборе крайне оптимизированной по временному критерию технологии есть минимальные сроки, «сжать» которые становится предельно дорого. Другими словами, каждый дополнительный день экономии по времени потребует вложений ресурсов с растущим в прогрессии коэффициентом. Например, 1-й дополнительный день экономии срока («сжатия графика») потребует + 200 человеко-часов, 2-й день —+500 человеко-часов, 3-й, соответственно, + 900 и т. д. и т. п.

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

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

С каждым днем всё больше российских компаний открывают для себя пользу масштабируемых Agile‑практик. Причем это уже не просто локальный Scrum в отдельных командах, а переход на более высокий уровень взаимодействия команд и продуктов.

Меня зовут Антон Чижов и я руковожу Центром практик Agile в МТС. В этой статье я расскажу о том, что такое продуктовая трансформация и как мы ее проводили в МТС. А в конце статьи вас ждет анонс моего выступления на конференции True Tech Day, которая пройдёт 31 марта 2023 года.

Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи  «Почему оценка задач сломала Agile».

У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то  в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum.

При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений».

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

Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?

В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.

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

Привет! Меня зовут Евгения Воропаева. Я занимаюсь тестированием в PIMS-команде СберМаркета, мы разрабатываем внутреннюю систему для отдела контента и производства. Проект существует уже 2,5 года и за это время PIMS рос и развивался, приходили и уходили люди, менялись подходы к работе, внедрялись новые практики. Методом проб и ошибок мы выстроили процессы в команде тестирования, которые считаем оптимальными. Хочу поделиться результатом, к которому мы пришли и надеюсь, наш опыт будет вам полезен.

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

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

Сразу будем делать? Или сначала проверим, а кто‑то вообще его купит?

Я уверен, что у статей‑списков есть огромный потенциал для проверки гипотез о спросе.

Привет всем, кто интересуется Канбан‑методом, и кто хочет познакомиться поближе с одним из его инструментов — S.T.A.T.I.K.

Задумка этой статьи появилась тогда, когда в очередной раз ко мне кто‑то подошел с вопросом: «Мы собираемся делать СТАТИК, где про это можно почитать?»

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

Привет, Хабр! На этапе выбора темы статьи было много идей: написать про DevOps или про платформы, а может про продуктовые команды или про практики SRE? Но пришли к выводу, что нет ничего интереснее, чем реальная увлекательная история трансформации. Мы, команды платформы разработки MOEX и экосистемы Финуслуги.ру, в лице Карапета Манасяна, Александра Барыкова, Антона Квашёнкина и Юлии Лутковской, расскажем практически про весь путь изменений и про их подводные камни. Важно отметить, что в статье затрагивается довольно много тем, местами даже будут блоки со скриптами ?. Поехалиии!

Каждому проектному менеджеру – от junior до senior, известен скоуп методологий управления проектами. Но многие работодатели не понимают, кто такой менеджер проектов, чем он должен заниматься и какие методологии работают для конкретных задач. Как не выбрать то – не знаю что и не попасть туда – не знаю куда? Давайте разбираться вместе.
Меня зовут Лана Демченко, я администратор проектов направления медицинских ИТ-продуктов в компании «БАРС Груп». Также имею опыт работы в продажах и в административном управлении.

Хочу поделиться своим опытом в том, как я бесплатно получил сертифицированное обучение по основам проектного менеджмента от Google на Coursera. Описываемые действия, в моем конкретном случае, помогли мне сэкономить около €300 на всех частях этого курса. Для меня - это ощутимые деньги и я рад, что вообще есть подобная возможность.

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

Эмпирические выводов по прошествии 5 месяцев профильной работы менеджером проектов в разработке веб-приложений.

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

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