Сергей Господчиков

Stachka.Agile

Section Curator: Sergey Gospodchikov

The world is accelerating. The environment is getting more complicated and is changing faster and faster. Users are becoming more demanding.

Waterfall development model has got outdated? Will Agile save us? What is Agile? What is Scrum? What is LeSS? What is Kanban? What to choose? What does it mean to be flexible? What practices we are to apply in the development to give the user more value earlier than others? How to scale the development with the growth of the product?


We will try to answer these and other questions. Our section is a meeting place with experts and common specialists. Here you can get some advice and new ideas. Look into the future. It will not be boring!

About the Curator:

45 years old. Ulyanovsk. Scrum master at MTS Cashbox (Litebox). Master of Business Administration (MBA), Professional Scrum Master (PSM I, PSM II), Professional Product Owner (PSPO I), Certified LeSS Practitioner (CLP).


Contacts:

Facebook: https://www.facebook.com/profile.php?id=1000060877...

Telegram: https://t.me/gospodchikovs


Метод Kanban в России постепенно набирает популярность.Но то, как его запускать всё еще остаётся секретом. Есть ли какой-то способ, как запустить Kanban-систему и не попасть впросак? Да, это метод STATIK (System Thinking Approach to Introduce Kanban) - это простой воркшоп из 8 шагов, результатом которого будет понятная и работающая система. Я расскажу из каких шагов он состоит, почему там нет ничего лишнего, как его можно проводить, чего от него ожидать и чему я научился за несколько десятков проведенных воркшопов!


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


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

Может лучше просто будем код писать?

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

Нет, это не серебряная пуля, просто математика работает всегда. Приходите на доклад – расскажу ;)


Есть ли жизнь без проджект-менеджеров, тимлидов и жесткого давления? Конечно! Один из принципов agile-манифеста гласит: "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им". Я расскажу как мы используем ценности и принципы agile-манифеста. Я расскажу про наш процесс onboarding и как это помогает строить фича-команды для масштабируемого скрама. Я расскажу как мы используем практики экстремального программирования. Я расскажу, как ценности компании находят свое отражение в нашей работе и помогают создавать продукт в плоских автономных командах.

Разберёмся в том, какие hard and soft skills нужны скрам-мастеру, чтобы построить крутой процесс Скрама, создать классную скрам-команду и добиться повышения эффективности команды в частности и бизнеса в целом. И главное, посмотрим, как должен уметь думать Скрам-мастер, чтобы уметь это делать.

История про успешную SAFe трансформацию в важнейшем бизнес юните и запуск первого Agile Release Train (ART). Как выстраивать потоки ценности, вовлекая в процесс сотни сотрудников? Как с помощью SAFe сблизить "бизнес" и "разработку", синхронизировать работу над десятком информационных систем и снизить Сycle Time? Почему в основе всего должны быть опытные кросс-функциональные фиче команды, работающие по Scrum? Как SAFe помогает распространять Agile и Lean принципы в промышленных масштабах? О чем важно помнить, если вы действительно хотите трансформировать систему? На эти вопросы я отвечу в своем докладе и расскажу, как SAFe помог нам сделать еще один шаг на пути к организационной гибкости.

В своем докладе я подробно расскажу о:

  • Что такое продукт - то что имеет ценность / выполняет полезную кому-то функцию. Продукт не значит что-то что имеет коммерческую ценность
  • Что такое команда - люди, продукт (цель), ценности. Примеры команд (на протяжении полутора лет в Леруа работал в 5 разных командах, создавал 3 команды)
  • Работа с командой - это с одной стороны работа с потребностями конкретных людей, их личных целей; с другой стороны - работа на объединение этих людей, их целей в общем направлении (разработке продукта), на основе общих ценностей. Примеры такой работы в разных условиях - когда идёт трансформация в компании, и когда понятные и чёткие цели
  • Аджайл и гибкая разработка в условиях множества команд и продуктов. Разные методологии, но общая философия - "нам не шашечки, нам ехать"

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


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

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


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

Как проходит:

  • Совместная работа начинается со знакомства участников друг с другом. Далее объявляется тема
  • Создание свободной атмосферы творчества
  • Работа самоорганизовавшихся групп; участники самостоятельно распределяют время, выделяют этапы работы. Участники групп могут работать по пять человек, по парам, другие могут состоять из десяти и более человек. Часть участников, как правило, переходят из одной группы в другую
  • Каждая группа сама подводит итоги, дает рекомендации по решению задачи и презентует их для всех остальных на «доске новостей»
  • Планирование и целеполагание
  • Завершение, обмен опытом и впечатлениями

Участники открытого пространства:

  • спикеры секции Agile
  • участники конференции

Голосование


Если вы ответственный тимлид или ведущий разработчик в компании у которой много направлений разработки, то скорее всего вы постоянно сталкиваетесь с тем, что на вас валится куча задач и проблем от команды разработки. А так, как вы "ответственный", то вам приходится с этим потоком задач что-то делать. Однако времени на всё не хватает. Из за этого приходится работать по выходным , что выполнить все обязательства или признаваться в том что "хотел но не смог". В докладе будут рассмотрены способы и методы организации своего времени и стратегия реагирования за большой входящий поток задач.

Почему многие компании, заявляющие, что они работают по Scrum, на самом деле понимают под Scrum что-то другое? Как мы умудряемся создавать работающий продукт без аналитиков, PM-ов и тимлидов?

Универсальный солдат: какие скиллы требуются разработчику для эффективной работы в скрам-команде? Дейли, ретро, обзор, PBR: а когда собственно код писать? Какие подводные камни подстерегают разработчика, работающего в скрам-команде и как их избежать?


- Мы — команда Трекера, которая сама использует свой сервис. Задачи по разработке Трекера ведутся в нём самом, поэтому мы имеем возможность улучшать инструмент и этим улучшать собственные процессы. - Проблема с “ненастоящим” скрамом: спринты есть, а скрама нет У нас, как и у многих других, были спринты и встречи, похожие на описанные в Scrum Guide. Но скрам не работал. Расскажу, как мы его настроили. - Проблема с потерей задач в процессе выполнения Зачастую наши задачи повисали в промежуточных состояниях, например, в тестировании или "готовности к релизу", но не доезжали до продакшена. - Организация скрам-команд: как ужиться фронтенду и бекенду? Как разрабатывать и тестировать фичу, затрагивающую несколько компонентов? Специалисты разных типов должны работать вместе, чтобы выполнить задачу. Кроме того, при разработке могут понадобиться изменения в компонентах с разным релизным циклом: фронтенд, бекенд, библиотеки и т.д. Мы нашли удобное решение этих вопросов. - Жизнь задачи: Как попасть в продакшен и не заблудиться? Проблема с "зависшими" задачами и со сложным жизненным циклом решается удобным набором статусов задачи и переходов между ними. Расскажу про наш вариант. - Организация ревью кода: как распределить задачи по ревьюверам? Что сделать, чтобы ревью заканчивалось в разумное время? Организация ревью кода это не просто: сроки затягиваются, а разработчики в разной степени склонны проводить ревью. Мы пробовали разные варианты решения и автоматизировали их через Трекер, это помогло решить большую часть проблем. - Git flow и его настройка под процесс, управление составом релизов, хотфиксы и откаты релизов. Это может показаться банальным, но git flow действительно работает и приносит пользу. Однако, есть несколько близких вариантов его организации, и какой удобнее использовать — зависит от процессов в команде. - Поддержка тестирования: Teamcity, docker и тестовые стенды Teamcity настраивается гибко, а docker удобнее deb-пакетов. Расскажем, как это можно применить для поддержки тестирования. - Проблемы со сложными релизами в нескольких окружениях, zero downtime релизы. Каждый релиз каждого компонента должен деплоиться в несколько окружений. Мы научились избегать конфликта версий и не забывать об отдельных частях. И обновляться без перерыва в обслуживании при этом. - Сервис для релизов и автоматизация Любую рутину можно автоматизировать. Вот мы и сделали маленький инструмент для поддержки релизного цикла, а интеграция с Трекером позволила встроить его в процесс.