Наверх ▲

Масштабирование Agile и Lean разработки в рамках программы

Александр Якима Александр Якима Консультант по Lean и Agile методологиям, в настоящее время работает с командами в Индии и США, а также в Украине и России.

(Демонстрация слайда).

Александр Якима: Вопрос в том, можем ли мы достичь такой же эффективности, когда речь идет, например, о 100 – 150 человек, которые работают на единую цель. Но одна цель означает: либо все работают над одним продуктом, либо, например, работают над несколькими продуктами, как-то связанными между собой. Если мы не говорим о какой-то одной цели (а каждая "командочка" занята своим маленьким "мирком"), то проблемs масштабирования нет. Это предыдущая задача внедрения "Agile" в одной команде. Опять же проблема, которую мы решаем – это "Agile" в программе, работающей на одну цель.

(Демонстрация слайда).

О чем мы поговорим сегодня:

  • Командные практики, которые переносятся с масштаба одной командочки на масштаб всей программы.
  • Распределенность. В том числе поговорим немножко об аутсорсинге и "Product Ownership", который обычно является ключевой проблемой.
  • "Lean"-требования. Увидим, что общего и разного между "Agile" и "Kanban".
  • Подходы к масштабированию: какие проблемы возникают, как я их решаю.

Обо всем этом мы будем говорить в контексте "Lean"-мышления.

(Демонстрация слайда).

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

Здесь важно учитывать несколько основных тем темы "Lean". Первое – это работа с очередями. В "Lean" мы пытаемся держать очереди как можно более короткими. Это понятно, почему.

Кстати, о каких очередях идет речь. Первая уже видна – это очередь требования. Пример очереди требования – это "back-log". Почему важно держать "back-log" коротким.

(Демонстрация слайда).

Если я здесь, где-то в "голове" очереди (третий, четвертый) – я могу приблизительно прогнозировать, что меня обслужат сейчас за четыре-пять минут (плюс-минус). Если я здесь 35-й, то говорить об этом более-менее точно не могу – слишком большая вариабельность. Поэтому мы держим "back-log" короткими. За счет чего мы это делаем. За счет чего можно держать "back-log" коротким. За счет короткого релиза. Короткий "back-log" "мапится" на короткий "time-frame".

02:55

(Демонстрация слайда).

Вторая тема, важная – мы стараемся все пакеты (пакет – это задача) держать небольшими по размеру. Большие пакеты непропорционально замедляют работу над проектами.

(Демонстрация слайда).

Третья тема "Lean" крайне важна – распределение обязанностей, делегирование обязанностей на самый низкий уровень. Таким образом, мы делаем всю программу достаточно самоорганизованной. При этом нет проблемы с принятием решения. Для принятия каждого решения не нужен большой "луп" аж наверх. Все очень просто.

(Демонстрация слайда).

Наконец, еще одна, предпоследняя тема "Lean" – максимально уменьшаем количество задач, которые уже открыты, но не завершены. Все это работает хорошо только в одном случае – если у нас команда (программа, в данном случае) постоянно совершенствуется, ищет варианты совершенствования себя, находит новые и новые "затыки" в системе. Эта логика постоянного поиска "затыков" и их устранения в "Lean" называется "кайдзен мышлением". Маленькие "шажки", при которых мы оптимизируем всю систему.

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

(Демонстрация слайда).

Итак, первая практика – парадигма "Define Build Test ". Это означает, что в рамках гибкой разработки мы пытаемся каждую задачу пропустить через короткий повторяемый цикл, который несет ценность на выходе из этого цикла. Шаги цикла очень простые – определить, что мы делаем (это делает "Product Owner"), построить (это делают разработчики) и верифицировать (это делают тестировщики), Этот цикл прокручивается несколько раз по ходу спринта.

(Демонстрация слайда).

Вот так это приблизительно работает. Пользовательская история входит в рамки итерации. Несколько DBT-циклов. На выходе – готовый результат. На каждом срезе здесь функциональность, которую можно "пощупать". Здесь – точно также. Теперь вся программа, по сути, строится из этих маленьких DBT-командочек. Мы часто будем использовать термин "DBT-команда" и "Agile"-команда" практически как синонимы, но подчеркивая, что в каждой команде выполняются три функции – определения, построения и тестирования.

05:51

Второе – освоение короткой итерации. Мы знаем, что это делается (и, в принципе, неплохо) на уровне одной команды. На уровне всей программы это важно. Важно, чтобы вся программа научилась синхронно начинать и заканчивать итерацию. Под конец каждой итерации вся программа может выдать "на гора" готовые, ощутимые результаты из "software", которые работают.

(Демонстрация слайда).

Вид итерации очень простой. Опять же, начало, конец, демо – здесь готовый результат, инкремент. Каждая история, которая входит, прокручивается в нескольких DBT-циклах.

(Демонстрация слайда).

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

(Демонстрация слайда).

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

(Демонстрация слайда).

Вот как выглядит релиз. Это обычно некоторая совокупность спринтов. У него тоже есть планирование, демо. Но на входе здесь у нас уже "feature" или эпосы. На уровне спринтов на каждую команду они попадают в виде пользовательских историй. Есть тоже свой "выхлоп", который мы демонстрируем точно так же, как в каждом спринте. Все, в принципе, достаточно просто.

07:58

(Демонстрация слайда).

Следующая практика. Частые релизы, можно сказать, даже более того: очень важно, чтобы они были регулярными (например, каждый квартал). Почему это важно. Потому что команды тогда привыкают. Вся программа привыкает к тому, что даты крайне важны. Нельзя их переносить, "слыпать". Мы всегда доставляем точно по датам. Стейкхолдеры при этом приучаются к одной простой вещи. Мы же понимаем, что даже самая лучшая программа никогда не может доставлять 100% "Scope", на который "комитятся" впритык. Это реальность. Поэтому, как понимают стейкхолдеры, важна правильная приоритезация. Эти два конца сходятся, и получается успех с точки зрения бизнеса.

(Демонстрация слайда).

Следующая практика – конкурентное тестирование, или, как мы ее еще называем, параллельное тестирование. Это означает, тестирование идет параллельно разработке. Не откладывая тестирование ни в какие-то последующие спринты (хоть это иногда и принято). Есть такое понятие, как "закалочные спринты" ("hardening sprints"). Некий спринт, где-то к концу релиза, в котором якобы наверстывается качество, в котором никакой новой функциональности уже не создается. Это достаточно типичный антипатор.

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

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

(Демонстрация слайда).

Но, опять же, выделенная команда тестировщиков. Это практически никогда не работает. Основная причина, почему это не работает, диктуется как раз принципами "Lean". Первая тема "Lean", о которой мы говорили – это большие очереди. Между разработкой и тестированием возникает большая очередь задач. Опять же, большая непредсказуемость. Вместо этого тестировщики живут, действуют постоянно, 100% времени, в "scrum"-командах, тех DBT-командах.

10:42

(Демонстрация слайда).

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

(Демонстрация слайда).

Что это означает. Непрерывная интеграция, несмотря на то, что она связана очень четко с целым набором "tools" и паттернов, как она делается – это, в первую очередь, культура.

Культура программы, во-первых, культура одной "scrum"-команды. Синхронизировать то, что сделал я, с остальными членами команды. Это делается желательно на уровне просто одного эпизода кодирования, много раз в день. Хотя бы раз в день в хороших, нормальных командах. Дальше DBT-команда с остальными командами в рамках программы. Хотя бы несколько раз в спринт, если не каждый день.

Культура синхронизации кода важнее даже "tools", которые используются для нее. Важная практика. Но часто этого сложно добиться. Когда мы внедряем в "scrum" (в частности, в распределенный), когда у вас 15 – 20 "scrum"-команд. Часто проблема интеграции настолько сложна, что люди приходят к решению: давайте создадим интеграционную команду, которая будет за всеми "подчищать" проблемы, связанные с интеграцией.

(Демонстрация слайда).

Это максимум может жить один-два релиза. Если вы создаете интеграционную команду либо наследуете от предыдущего процесса – у вас уже должен быть план, как от нее избавиться. Но избавиться в хорошем смысле. Эти люди должны войти в другие "scrum"-команды. Самая важная вещь в распределенном "scrum"– это ответственность за интеграцию лежит на всех "scrum"-командах, а не на какой-то отдельной ортогональной команде к этой всей программе.

12:41

(Демонстрация слайда).

Наконец, самое главное, что отличает "scrum" в принципе (в том числе, распределенный), широкомасштабную разработку от просто инкрементальной итерационной разработки. Это постоянное совершенствование. Помним, кстати, тему из "Lean", о которой мы только что говорили. Постоянное совершенствование, "кайдзен мышление".

Причем очень важно отметить, что постоянное совершенствование процесса – это не то же, что ретроспективы. Это не тождественное понятие, хотя часто одно с другим путается. Постоянное совершенствование. Потому так и называется, что оно происходит на каждом этапе разработки, в каждом эпизоде. Ретроспективы – это только некие "check point". Эта практика должна работать и на уровне всей программы.

(Демонстрация слайда).

Перешли к распределенной разработке. Здесь работает очень простой принцип. Чем больше расстояние, тем большего размера пакеты гоняются между двумя точками. Расстояние – понятие совершенно относительное. Что такое расстояние. Это может быть географическое расстояние между, например…

Представьте себе "Product Owner" в США, и где-то в Боснии команда разработчиков его. Но опять же он не может с ними "face to face" общаться каждый день. Не может пойти посмотреть что-то и сказать: "Нет, это неправильно. Давайте так". У них значительно меньше "Check Point", и они значительно менее эффективны. Что это значит. Это значит, что они будут сообщаться, например, один-два раза в неделю. При этом он отошлет пачку требований, они что-то "на гора" выдадут. Вот так, большими пачками, при которых еще и потери будут высоки по дороге. Это важно.

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

14:55

(Демонстрация слайда).

Хуже всего работает программа, у которой географический разрыв происходит на уровне одной DBT-команды, "scrum"-команд. Почему. Потому что мы строим программу таким образом, что у нас DBT-команда – это некий "кирпичик" масштабирования. В рамках этого одного "кирпичика" все взаимодействия как раз наиболее интенсивны. Их развивать очень плохо. Поэтому желательно "Product Owner", разработчика и тестировщика держать в одной "куче".

(Демонстрация слайда).

Значительно лучше выглядит вариант, когда у нас распределенность в программе, но ни одна из DBT-команд не разорвана. Это работает всегда значительно лучше. Но даже в таких случаях, если мы можем как-то сделать так, чтобы разработчики и тестировщики в "scrum"-командах жили вместе, то "Product Owner"– это часто проблема, особенно в заказной разработке. "Product Owner" – где-то всегда там, а все остальные аллоцированы.

(Демонстрация слайда).

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

Доверия нет. Конечно, если люди не работают лицом к лицу – откуда оно появится. "Автоматом" никогда не появятся. Тем более если это заказная разработка, и, кроме отношений "Product Owner" – команда", вступают в силу еще и отношения "заказчик – контрактер". Доверия априори нет. Тем более, команда не наращивает какую-то экспертизу. Это тоже очень серьезный нюанс.

16:55

(Демонстрация слайда).

Есть ряд решений, одно из них неплохое. Это введение "Proxy Product Owner". По сути, воспитание человека в рамках вашей команды, который будет жить с этой командой, по крайней мере, процентов восемьдесят времени. Возможно, курсировать куда-то в гости к "Product Owner" и наоборот. Но проводить время с командой. Он как раз решает, служит таким "фасилитатором" с точки зрения как раз правильного коммуницирования требований.

Зачем он нужен. Представьте себе. Прошел один DBT-цикл. Вот пример локального решения. Команда приходит к "Product Owner" и говорит (это совершенно нормальная ситуация): "А правильно ли мы движемся, туда ли мы идем?". Вот уже "screen" есть, пару кнопочек, что-то нажимать можно. А нет "Product Owner", некому сказать.

(Демонстрация слайда).

Это тип, пример как раз локальных решений, для которых совершенно достаточно "Proxy Product Owner". Он говорит: "Да, ребята. Все нормально. Только здесь вот немножко не так". Они работают сразу дальше.

Тем не менее, "Proxy Product Owner" не заменяет "Product Owner". Это первый момент. Общение с "Product Owner" не совершается теперь через него как через посредника. Это тоже очень существенно. Общение "Product Owner" и команды должно обязательно все-таки продолжаться.

Более того. Ситуация становится нездоровой в случае, если "Product Owner" не работает с командой хотя бы на этапе планирования и демо. Иногда еще на уровне PBR ("Product", "Backlog" и "Refinement").

18:36

(Демонстрация слайда).

Кроме этого, очень полезно все-таки обмениваться визитами. Никогда бы не подумал. Пока не поедешь куда-то (например, в Индию – Бангалор или Мумбаи), не увидишь трафика этого, условий, в которых они работают (кто-то живет30 километровот города, и в команде таких 80%, потому что жилье слишком дорогое), то не можешь понять, почему они никогда не могут на работу прийти раньше, чем 9.30 АМ (местного индийского времени) и не могут уйти позже 6 PM.

Придешь, поработаешь, увидишь людей. Возникает сразу какое-то доверие, сразу все решается. Начинает возникать некое понимание.

(Демонстрация слайда).

Кроме этого, нет более эффективного метода общения, чем лицом к лицу, кроме одного: лицом к лицу напротив "White Board". Это и надо пытаться производить, особенно в распределенном случае. Причем здесь есть много совершенно разных подходов. Некоторые сейчас используют.

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

(Демонстрация слайда).

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

20:29

(Демонстрация слайда).

"Lean"-требования. Очень удобная метафора для того, чтобы понять, как мы смотрим на требования с точки зрения "Lean" – это "контейнер". Мы смотрим на требования как на некоторый "контейнер", который наполняется как раз "Just in Time", то есть точно вовремя, тогда, когда надо, а не все с начала.

(Демонстрация слайда).

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

Но не все, на самом деле. Всегда остается какой-то элемент. Если мы делаем это определение "up front" (то есть с самого начала), у нас есть риск, что эта штука будет значительно больше из-за того, что мы наполняем вот этот контейнер совершенно ложной информацией.

(Демонстрация слайда).

Что использовать в качестве контейнера очень просто. Принято использовать эпосы, "feature", истории. Почему. Потому что, на самом деле, они не являются требованием. Аналогию можно привести из программирования. Ссылка на объект: сама объектом не является, но на него указывает.

Пример – эпос. "Community"-функции работы с документами. Что-то общее, размытое. Понятно, о чем это – но непонятно, что. Четких рамок не видно.

"Feature", одновременный доступ к документам – уже более четко, понятнее, что. Но все равно достаточно "размыто".

Пользовательская история. Сейчас будет один продукт, и более четко. Как пользователь я могу редактировать строку (неразборчиво, 22:41), если ее не редактирует другой пользователь, даже если он открыл тот же документ. Все достаточно четко уже. Следующий уровень четкости на уровне эпизода – это уже некий критерий приемки, некий конкретный сценарий и так далее.

(Демонстрация слайда).

Очень важный "skill" также для программы – это умение делить "контейнеры" на "контейнеры". Здесь мы очень четко подразумеваем, что "контейнер" несет бизнес-ценность. Поэтому, если мы говорим, что делим пользовательские истории в рамках программы – мы делим их опять же на пользовательские истории, которые несут ценность.

23:17

(Демонстрация слайда).

Итак. "Agile", "Kanban". Я так предусматриваю, что большинство все-таки слышало вкратце, что такое одно и другое. Между этими двумя методологиями есть много схожего. Например. Мы все знаем, что такое "Kanban". Это, грубо говоря, система с минимальным числом аксиом. Ограничиваем количество работы в прогрессе, используем "Pool"-систему, систему "вытяжки": берем задачу, только когда освободился ресурс на входе. По сути, все. Остальное – это просто визуализация "Workflow" и общая известная, понятная всем система внесения совершенствования в процесс. Политика изменения процесса. Все очень просто.

А что между ними общего. Если посмотрим аккуратно, то ограничения на работу в прогрессе есть и там, и там. В "Agile" оно такое же (в "Scrum", например). Мы берем на двухнедельную итерацию только то, что можем в рамках этой итерации доставить. Вот вам другая формулировка ограничения на работу в прогрессе. Система "Pool" работает тоже, просто она работает двухнедельными "чанками". Мы берем следующую работу только когда начинается итерация. Мы не берем больше, чем вмещается в следующий спринт.

(Демонстрация слайда).

Когда "Kanban" точно показан для команды. Я не хочу спорить, что лучше. Но когда "scrum" может вообще пролажать, а "Kanban" хорошо подойдет. Поддержка (неразборчиво, 24:43) какие-то выскакивают, с полной неожиданностью. "Product Owner" просто не может собраться с мыслями и как-то зафиксировать на две недели "Scope" спринта. Несмотря на то, что внешние условия это могут позволять, и так далее.

24:59

(Демонстрация слайда).

Искусственно сложный процесс и, самое главное, разрыв DBT-команды. Если разработчики где-то, скажем, в Питере, а в Бангалоре все тестировщики, то вам "scrum" не удастся построить, скорее всего. Наверное, тогда "Kanban" стоит использовать.

Опять же, масштабируемые практики есть и в случае "Kanban". Часто они пересекаются, возможно, не по форме, но по смыслу с "Agile"-практиками. Частые релизы и там, и там, два уровня планирования. Но здесь нет DBT-цикла. Это иногда может быть весьма опасным.

(Демонстрация слайда).

Вообще, использование "Kanban" может быть совершенно опасным без некоторых вещей. Без гибких практик, таких как непрерывная интеграция, особенно в масштабе программы. Если мы не интегрируем код часто, можем стоять на границе очень серьезной проблемы. "Product Ownership". Если нет кого-то, кто приоритезирует, проблем не избежать точно. Фасилитация процесса. Можно не называть этого человека "Scrum" или "Kanban"-мастер. Но кто-то должен "оунить" процесс. И так далее.

(Демонстрация слайда).

Наконец, последняя часть нашей беседы – подходы к масштабированию. Что означает "Agile" вообще для программы, если мы применяем "Agile" в масштабах программы. Это, во-первых, переход от таких "силосных ям" (вот разработчики, вот тестировщики), отделов больших, на DBT-команды, где есть и те, и другие.

Эти командочки создаются надолго. Это опять же переход от динамической локации и ресурсов на проекты на работу долго (на месяцы, годы, возможно) для того, чтобы команды могли сработаться и как-то "импрувать" свою скорость разработки, экспертизу. Они работают только с одним "back-log" каждая. Поэтому мультизадачности по проектам тоже нет. Вот он, переход важный.

27:06

(Демонстрация слайда).

Теперь вопрос в том, как. Вот сформировали мы DBT-команду. Что она делать будет? Один из вариантов – это компонентная команда. Команда, которая держит "Own Ship" над одной компонентной системой. Часто так легко организовать команду.

(Демонстрация слайда).

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

Лучший вариант – это "feature"-команды или команды вокруг "feature". Но она создается не под "feature". Помним же, что DBT-команда создается надолго. Она создается вокруг некой области требований.

(Демонстрация слайда).

Вот, например, "user"-менеджмент, который включает много в себя разного. Все "feature", которые будут попадать в эту область, будут идти этой команде. Немножко сложнее построить, потому что люди должны уметь полностью "feature" "and to and" по всей системе сделать. Но зато надежность такой программы значительно выше. "Back-log" их звучат на бизнес-языке, кстати. Это тоже очень важный момент.

(Демонстрация слайда).

Простое правило. Всегда, когда можно, создаем "feature"-команды. Где нельзя – компонентные. Иногда по объективным причинам нельзя. Например, если есть какая-то компонентная в нашей системе, которая будет, мы знаем, использоваться еще с какой-то третьей стороной, то что тогда. Наверное, в этой компонентной есть своя какая-то автономная жизнь, и нужна какая-то команда, которая будет "оунить" этот компонент.

(Демонстрация слайда).

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

Представим себе это как один логический день, для простоты. Представим себе также, что это все коллоцировано (просто не хочу ударяться в подробности). Что происходит, если это, например, три "location". Первая часть с утра – стейкхолдеры программы представляют видение на релиз в программе.

Но важно здесь учесть, что планируют в "Agile" все. Если мы говорим, что это планирование релиза, все разработчики, тестировщики – каждый, кто создает пользовательскую ценность, будет там. Он будет планировать. Команды планируют. Разбиваются на команды, работают, например, в течение 3 – 3,5 часов совместно.

Получается, например, если мы считаем, что у нас в релизе четыре спринта, они должны закончить с планом каждого спринта поверхностным. Планы потом могут "решафлиться". Нам нужно получить вообще "scope" релиза, общий комитмент на релиз. Представляют планы группе и стейкхолдерам. Все понимают, какие есть зависимости. Потом стейкхолдеры "эпрувают" эти планы, смотрят на риски, управляют рисками, классифицируя их (например, на "Mitigated", "Accepted", с которыми ничего нельзя сделать, "Owned", если кто-то может ими заняться). Все команды, вся программа "комитятся". Голосуют, насколько уверенно они себя чувствуют на предмет доставки этого релиза.

30:22

(Демонстрация слайда).

Вот что является самым главным, разменной монетой при этом планировании. Вот это листок целей. Обычно это флипчарт-лист. Кстати, планирование релиза, но очень визуально. Там нет никаких "tools", по крайней мере, на этом этапе. Все делается на листах, с карточками. Вот пример. Это цели одной "scrum"-команды в рамках программы на один релиз. Цели, а тут их "Business Value". Вот художество. Видно, что я там понарисовывал?

(Демонстрация слайда).

Это пример. "Room" большой. Здесь столы команды. Здесь за каждым сидит "scrum"-командочка. Вот презентационная "area". Здесь в самом начале стейкхолдеры вещают часик, два, полтора, что они ожидают от команды в результате релиза. Вся программа должна сказать, а что же их этого мы реально сделаем, доставим. У каждого стола, у каждой команды где-то на стенках своя "area". Обычно шесть больших листов с карточками. Четыре, например, спринтовых листа с карточками. Один – с целями, и один – с рисками. Все очень просто.

Команды услышали видение, начали планировать. Это, например, три часа планирования в автономном режиме. Тут они работали друг с другом, ловят стейкхолдеров, общаются очень эффективно. Потом каждый, например, час или 45 минут собираются здесь в режиме "scrum of scrums". Здесь чек-лист по планированию, где мы находимся сейчас.

После окончания этого всего действа каждая команда представляет видение всей программе и стейкхолдерам. Получает (неразборчиво, 32:10) или нет на доработку. Потом берут все листы с целями и рисками только, вывешивают все на одну стенку (в данном случае окно нарисовал, не знаю, видно ли). Все. Снимают риски, классифицируют, например, на "Mitigated", "Accepted", "Owned" кем-то, и голосуют, как они себя чувствуют по поводу этого.

(Демонстрация слайда).

Вот пример. Это "scrum"-мастер одной из команд. Вот их план. Пытаются что-то представить группе. А вот стейкхолдеры уже к чему-то "приколупались" здесь – спрашивают о чем-то.

32:43

Здесь возникает куча вопросов: "Ой, а у нас же там зависимость", и так далее. Очень важный процесс. Вот эта "area", где "scrum of scrums" происходит. "Velocity instability" – есть ли скорость команды, все ли истории "проистимированы" и так далее.

(Демонстрация слайда).

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

×          "я займусь этим риском",

×          "это мы "митигируем" потому, что…",

×          "вот это мы принимаем, еще не можем сделать, и потом голосуем",

×          "да, все, все, мы это доставим".

Это некий неявный договор между стейкхолдерами и командами.

(Демонстрация слайда).

Теперь очень быстро – как это все "трэкать". "Scrum of Scrums" работает еще: вот начался первый день релиза – и поехали. Это напоминает "daily scrum meeting", только проводится, например, несколько раз за спринт. Собираются "scrum"-мастера со всех команд (или еще некоторые люди) и обмениваются статусом.

(Демонстрация слайда).

Иногда можно использовать связи между командами совершенно неформального характера. Попробовали "синтегриться" – сразу возникли вопросы, кто-то из девелоперов поговорил с девелоперами из другой команды. Это тоже очень эффективно работает.

(Демонстрация слайда).

Работает хорошо с "Community of Practice" (сообществами по практикам), которые мы, к сожалению, не совсем успеем сегодня обсудить.

(Демонстрация слайда).

Как еще "трекать" статус. Помним, что у нас основной протокол общения между стейкхолдерами и программой – это вот эти листы с целями. Мы смотрим, сколько из "Business Value" мы доставили, по мнению стейкхолдеров.

(Демонстрация слайда).

"Burndown Chart" всей этой программы, всего релиза. Работает, кстати, значительно лучше и точнее, чем "Burndown Chart" одной DBT-команды на уровне спринта. Можно легко обосновать, почему.

(Демонстрация слайда).

"Burndown Chart" может не сказать, что именно отстает. Тогда статус на уровне "feature"-релиза очень и очень полезен.

34:43

(Демонстрация слайда).

Итак. Что делать, какие первые шаги для того, чтобы как-то начать процесс перехода на "Agile" в рамках программы. Первое – отконфигурировать программу. Создать эти действительно полноценные "agile"-командочки, из которых она будет состоять. Потом – обучить команды. Не "scrum"-мастеров, которые потом донесут совершенно корявый "message" своим командам, а именно тех, кто будет создавать ценность девелоперов и тестировщиков.

Создать сообщество по практикам. В первую очередь, "scrum"-мастера, "Product Owner". Если распределена, то "Proxy Product Owner". Основная практика – освоение итерации, непрерывной интеграции. Это две ключевых основных. Теперь пару итераций так проработать, удостовериться, что мы можем что-то доставлять под конец каждого спринта и потом попробовать совместное полноценное планирование релиза.

(Демонстрация слайда).

Есть много книг по этому поводу. Я только остановлюсь на двух, которые, по моему субъективному мнению, наиболее ценны по масштабированию. Название это немножко обманчиво. На самом деле, это как раз есть книга о масштабировании гибкой разработки. Все. Вопросы.

35:55

Вопросы и ответы

Реплика из зала: Не рассматривалось ли тестирование как издержка? Ведь она, по сути, ценности отдельной для заказчика не приносит.

Александр Якима: Да. Напрямую – нет. Но ее отсутствие приводит к очень серьезному "waste", регрессии. Она "ударяет по голове сковородкой", когда не ожидаешь. А тогда уже нарастили столько кода, что потери – в много раз больше. Здесь хитрый подход надо.

Реплика из зала: Ваш опыт интересен. Такой кейс расскажу. Например, заказчик переходит на "Agile" – там такой "move", условно говоря, человек 80, а то и 100 одна команда. Команда никогда не была "feature"-ориентирована. Не было таких "feature"-ориентированных команд. Там были релизы по полгода, и все как всегда, как обычно. Решили переходит на "Agile".

Тут появляются классные "Agile"-консультанты и говорят: "Ребята, нужно, чтобы "feature"-команды были". – "Какие "feature"-команды? У нас тут два человека в Ижевске, три – в Саратове, пять – в Киеве. А еще у нас в Сингапуре есть. Мы все – одна команда. Какая там "feature"-команда". А мы приходим и говорим: "Так, ребята, смотрите. Вы должны сидеть в одном городе, желательно в одной комнате, собираться и все такое".

Мне интересен опыт. Когда у нас есть какая-то исторически сложившаяся структура, жестоко распределенная и, более того, очень-очень большая (человек сто). Нам эту всю структуру нужно "мувнить" на "Agile".

Александр Якима: Опять же. Нельзя "мувнуть" на "Agile"… Нельзя "мувнуться" в счастье без боли. Это означает, что часто (это из реального опыта) начинают интегрировать "agile"-команды. Я не говорю "feature"-команды, а "agile"-команды, которые могут (опять же, то, что мы говорили) определять, разрабатывать, тестировать. Они могут быть компонентными. Но первая, самая важная – тестировщики (желательно еще "Product Owner" и разработчики) живут вот так, в локации, "неразорванно". Если они "разорваны", то нельзя построить "Agile". По крайней мере, это будет большой мукой.

Тут не бывает таких вариантов, что все классно. Другое дело, что есть мы это принимаем как данность (знаем, что не будем тех людей увольнять, а тех набирать, оставляем так, как есть) – тогда мы исходим из того, что это уже первая неэффективность, встроенная в систему, когда "Agile" не рекомендуется применять. Я говорил о том, что разрыв DBT-команды – лучше пробовать "Kanban", видеть, что тогда при этой неэффективности все же можно "заимпрувать", и как-то вот так разумно двигаться.

Реплика из зала: Так заказчик сходил, послушал классных консультантов.

Александр Якима: Я понял.

Реплика из зала: Они ему сказали: «400 плюс проценты».

Александр Якима: Понятно. Но идеальных ответов нет.

Реплика из зала: Мне интересен просто опыт. Эти все рассуждения о том, что это есть хорошо, это есть плохо… Я сам читаю примерно 20 тренингов по "Scrum" и "Agile" в крупнейшей в Европе корпорации. Мне интересен опыт. Как "мувнуть", кто "мувал". Покажите мне человека, который "мувал", чтобы я ему задал вопросы.

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

 

 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Александр Кудымов

Александр Кудымов

Проектировщик интерфейсов, канбан-мастер.

Евгений Кобзев и Александр Кудымов (СКБ "Контур") объясняют, почему им стал тесен скрам и на какие грабли не стоит наступать.

Михаил Радченко

Михаил Радченко

Директор компании "SoftPatent".

Михаил Радченко дает обзор своей практики патентования интернет-разработок.

Роберт Трит (Robert Treat)

Роберт Трит (Robert Treat)

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

Роберт Трит (OMNTI) рассказывает о проблеме "раздувания" данных в Postgres.