Всем привет! Сегодня я хочу рассказать историю о своем увлекательном путешествии на «антиконференцию» AgileCamp 2015.
До участия в этом мероприятии у меня не было опыта применения Scrum и Kanban, поэтому было очень интересно опробовать гибкие методологии на практике. Заранее прошу прощения, если где-то напутал с терминологией или переиначил смысл услышанного – прежде всего мне хотелось поделиться своими впечатлениями. Буду рад любым вашим комментариям, в том числе с замечаниями и дополнениями.
Место встречи изменить нельзя
Проделав долгий путь: на самолете, аэроэкспрессе, метро и трансферном автобусе, я оказался в подмосковном пансионате Яхонты, на берегу очень живописного озера.
Красивая природа, чистый и свежий воздух, прохладная погода – можно сказать, что атмосфера на AgileCamp 2015 была особенной во всех смыслах.
Первый день «антиконференции» по традиции начался с регистрации и, конечно же, горячего кофе, который расходился так быстро, что его не успевали подливать в бойлеры. Медленно, но верно, все гости AgileCamp собрались в местном конференц-зале на приветственную линейку.
После небольшого вступительного слова от организаторов, «вожатые» AgileCamp презентовали свои «пионерские отряды»:
- Продуктовый – про боль пользователей, исследование рынка и работу с аудиторией.
- Инженерный – про максимально быструю и качественную разработку, с помощью рефакторинга, TDD, BDD и DevOps.
- Процессный – про проектный менеджмент всей цепочки создания продукта.
Самыми интересными мне показались темы Процессного отряда, поэтому я пошел в отряд к вот такой звездной бригаде вожатых, уже знакомых мне по их выступлениям, статьям и книгам:
Старт!
После вводной презентации все отряды разошлись по своим конференц-залам. К этому времени вожатые уже приготовили первое задание: каждый из нас получил по игральной карте, с которой должен был отправиться на поиски сильнейшей покерной комбинации. Мне достался туз пик, сильная карта, которая не всем подошла. Пришлось обойти весь зал, прежде чем я нашел ребят, которым не хватало именно такой карты для Флеша. После этого мы объединились с соседней пятеркой, сели за один стол, и так появилась наша боевая команда («Черный экран», привет!).
Следующее задание было не менее интересным: нам необходимо было придумать несколько новых продуктов и описать их вот в таком формате Geoffrey Moore:
Идей было много, но когда обсуждение было еще в самом разгаре, поступило новое задание: отправиться в «поля», к коллегам за обратной связью по придуманным нами сервисам. Переоценить пользу таких, даже самых простых опросов сложно — благодаря вопросам и уточнениям других участников, мы вернулись за стол с куда более проработанными идеями. Но, в живых должен был остаться только один продукт. Мы еще немного поспорили и в итоге выбрали идею одного сервиса. После этого настало время двигаться дальше.
Игра-симуляция по написанию ТЗ
Перед тем, как приступать к разработке требований для нашего сервиса, вожатые предложили сыграть нам в игру по подготовке ТЗ, в которой было немало «прозрений» и «узнаваний».
Правила очень простые: сначала участники делятся на команды по 5 человек. В каждой команде распределяются следующие роли: 2 разработчика, 2 аналитика и 1 почтальон. Аналитики уходят в другой конец зала, где получают картинку с разноцветными геометрическими фигурами и задание «написать ТЗ на эту картинку, используя исключительно текст». Разработчики, в свою очередь, по готовому ТЗ должны нарисовать картинку, «идентичную натуральной». Общение осуществляется исключительно в письменном виде через почтальона. Добавьте сюда еще ограничение времени, и вы получите очень увлекательную игру.
Я не буду раскрывать секретов нашей команды, чтобы вам интереснее было сыграть самим, скажу только, что эта игра позволяет наглядно убедиться в важности коммуникаций. А так же покажет все преимущества итеративных процессов и прототипирования. Попробуйте сами, «прозрений» и «узнаваний» и правда будет очень много.
Lean Startup Canvas
Следующим нашим заданием стало описание бизнес модели нашего сервиса с помощью Lean Startup Canvas:
На первый взгляд, кажется, что если у вас есть гениальная продуманная идея, то нет задания проще. Однако (да-да), выполнение этого задания заняло у нашей команды очень много времени. Пока мы просто обсуждали наш продукт за столом, он выглядел простым и понятным, но стоило начать формализацию, как появилось множество вопросов. Мы спорили, какие проблемы мы на самом деле решаем, что мы предлагаем и на что тратим свои средства. В итоге мы кое-как заполнили все поля этой таблицы и расслабились.
Но в этот момент к нам подошел один из вожатых и рассказал, что блоки этой чудо-таблицы можно (и нужно) использовать для самопроверки. Например, фичи должны решать проблемы, метрики должны отображать параметры решения, каналы продаж должны соответствовать аудитории, а уникальные преимущества должны быть недоступны конкурентам. Оказалось, что наш первый вариант Lean Canvas просто кишел противоречиями.
Вооружившись новыми знаниями, мы еще раз прошлись по табличке, и в финальной версии получили более или менее стройную концепцию продукта. В общем, самопроверки лишними точно не бывают.
Карты пользовательских историй
Итак, мы получили формализованное представление о нашем продукте. Далее нам необходимо было выполнить декомпозицию работ по разработке нашего продукта. Мы обсудили разные варианты разбиения: по архитектурным компонентам, экранным формам и пользовательским историям.
Следующее задание заключалось в том, чтобы создать вот такую Story Map для минимального жизнеспособного продукта (MVP):
Мы с большим энтузиазмом приступили к работе и очень быстро забыли про выбранную гипотезу жизнеспособности, с жаром обсуждая реализацию отдельных Task-ов. Наша карта сильно раздулась и обросла разными фичами. В какой-то момент мы вспомнили про нашу гипотезу, записали ее на листочек, который наклеили на самое видное место. После этого мы основательно проредили карту – для проверки гипотезы достаточно было самого минимума функций.
Следующим шагом стала оценка задач. Одна половина команды исследовала Planning poker, другая — Bucket estimation.
Как проводить оценку первым и вторым способом подробно описано во множестве разных книг, поэтому поделюсь только приобретенным при выполнении задания опытом. Planning poker хорошо нивелирует влияние личностей (вы, наверное, замечали, что порой люди высказывают свои оценки под влиянием своих авторитетных коллег). Но итеративные таинства с картами – процесс весьма не быстрый. Bucket estimation в этом плане проще, поэтому он хорошо подходит для уже сработавшихся команд, которым необходимо быстро выполнять оценку.
После того, как оценки были сделаны, мы были готовы начать планировать первую рабочую итерацию и закидывать задачи ребятам из Инженерного отряда. Но на этой позитивной ноте тренинг по этой части закончился, и нам пришлось расстаться с нашим продуктом. Меньше чем за один день мы превратили идею создания продукта в конкретные задачи с оценками трудозатрат. Я на личном опыте убедился в том, какую пользу приносят обратная связь, итеративность, формализация и верификация своих идей.
World Cafe
В завершении дня мы испробовали этот интересный способ обсуждения проблем.
Сначала методом голосования мы выбрали 10 тем для обсуждения. Каждая из тем была закреплена за определенным столом. Участники приходили за стол с интересующей их темой и выбирали модератора. Далее все 20 минут обсуждали проблему, а модератор направлял дискуссию и фиксировал ее результаты. Как только выходило время, участники переходили за другие столы, а модератор оставался, чтобы передать накопленный опыт новой команде.
Через несколько таких раундов модераторы озвучили результаты обсуждений.
За нашим столом, где я был модератором темы, обсуждали «Большой Legacy проект и Agile в нем». Тема оказалась очень актуальной для большой доли аудитории: коллеги из самых разных компаний делились не только своей болью и страхами, но и успешными историями.
Если резюмировать три раунда обсуждений, получится следующее: Agile может помочь решить такую проблему Большого Legacy, как долгий процесс внесения изменений при невысоком качестве. Но, во-первых, для внедрения Agile в любом проекте требуется искреннее желание самой команды. Во-вторых, без подготовительного этапа внедрить Agile в огромный монолитный проект с соответствующей организационной структурой не получится. Необходимо делить проект на небольшие функциональные части, и формировать небольшие команды под каждую из них. В-третьих, это невероятно сложно и совсем не быстро, поэтому для таких изменений необходим спонсор. У одних коллег таким спонсором становились владельцы продукта, у других – внешние заказчики. Дальнейшее решение сводится к возврату огромного технического долга: кто-то практикует выделенные команды, кто-то использует технический налог. Очень полезными в таком процессе оказываются практики «агрессивного» автотестирования, правило бойскаута и Code Review.
Виски пати
В завершение дня организаторы устроили виски «Сибирская Корона» пати, где у костра до глубокой ночи участники обсуждали самые разнообразные темы: от перспектив применения Agile в своих проектах, до детских опытов с ассемблером, а так же обменивались байками про сибирские морозы, медведей, уральские леса и тайны сталинского метро.
Второй день начался с бодрящей зарядки на свежем воздухе, участники «Сибирская корона» пати неспешно собирались в холле конференц-зала, кофе расходился с удвоенной скоростью. Многие решили не ждать обеда, чтобы выписаться из номеров, и приходили с рюкзаками и сумками.
На столах нас уже ждала увлекательная и познавательная игра getKanban.
Игра-симуляция getKanban
На AgileCamp мне, наконец, удалось поиграть в эту чудесную игру-симулятор. Мне она представлялась неким развлечением, а по факту оказалась ничуть не проще реального рабочего процесса :) На одно только изучение правил и первую итерацию у нас ушло часа 2, но зато потом все пошло как по маслу.
Переоценить пользу от этой игры сложно. Я думаю, в нее имеет смысл играть и незнакомым людям, и работающим командам, потому что она позволяет «на спичках» прочувствовать подводные камни Kanban-процесса и увидеть сильные и слабые стороны своей команды.
По традиции не буду раскрывать секретов, но намекну, что вы не просто так заполняете кучу бумажек и диаграмм на каждом шаге игры, возможно, они окажутся весьма полезными ;).
Что стало для меня некоторой неожиданностью, так это возможность качественно прогнозировать время выполнения разных типов задач и сходимость процесса по базовым метрикам проекта.
Ball Point Game
Скажу честно, эта игра стала самым веселым и позитивным испытанием за эти два дня.
Правила игры просты: на команду из 10 человек выдается 15 шариков для пинг-понга. 1 бал = 1 шарик, которого коснулся каждый член команды. Шарики можно перекидывать или катать, но есть ограничение – его нельзя передавать соседу слева или справа. Игра состоит из 5 итераций: 2 минуты обсуждения и 2 минуты работы.
Я снова не буду раскрывать секретов нашей стратегии, но скажу, что благодаря активному участию каждого члена команды, и улучшению процесса после каждой итерации, мы прошли, путь от простой схемы с 35 баллами до отлаженного конвейера с 156 баллами за 2 минуты.
Запомнились и понравились также итоговые выводы из всего этого процесса: если решения будете придумывать не вы сами, а вам их просто будет выдавать менеджер – вряд ли вы будете так увлеченно и самозабвенно передавать шарики от пинг-понга.
И вряд ли вы получите хоть сколько-нибудь близкий результат, если откажетесь от итераций и будете сначала 10 минут думать, а потом 10 – работать.
Попробуйте сами, чтобы в этом убедиться ;)
Ретроспектива, которая работает
А завершились два дня Agile в отдельно взятом пансионате рассказом о ретроспективе и цикле непрерывных улучшений.
Мы обсудили структуру ретроспективы и активности на каждом из этапов. Подробную презентацию на эту тему можно посмотреть здесь.
А для закрепления полученных знаний, мы провели ретроспективу по утренней игре getKanban с помощью такой вот необычной колоды карт, Пасьянса ретроспективы:
Было не так-то просто удержаться от поиска виноватых, но коллективный разум победил эти порывы, и мы на позитивной волне обсудили наши недоработки, наметили несколько улучшений и поблагодарили друг друга за хорошую работу.
Заключение
В этой статье я описал самые запомнившиеся мне моменты AgileCamp. Конечно, на «антиконференции» обсуждали много других интересных: тем от диаграммы сгорания спринта до особенностей отечественного менеджмента.
Главный вывод, который я сделал для себя: гибкие методологии — это мощный инструмент организации процесса разработки ПО:
- Ограничение Work in Progress, будь то лимит задач в Kanban или бэклог спринта в Scrum, убирает вредные переключения между задачами.
- Коллективная ответственность способствует самоорганизации и командной работе.
- Самоорганизация позволяет получить совершенно другой уровень ответственности, вовлеченности и мотивации.
- Итерации позволяют быстро реагировать на изменения требований, делать выводы и улучшать процессы.
- Непрерывное улучшение процессов позволяет добиваться значительных результатов, за счет улучшений на каждой итерации.
Однако пользоваться этим инструментом не так просто, как мне казалось после прочтения нескольких книжек. Agile-процесс задает высокую планку для уровня самоорганизации команды, вовлеченности, ответственности и осознанности каждого сотрудника. Поэтому недостаточно просто формально выполнять правила той или иной методологии, необходимо эти правила принять и работать в духе гибких методологий.
Самое главное, что это возможно и это работает! «Антиконференция» AgileCamp наглядно показала, что при желании, даже совершенно незнакомые люди активно включаются в командный процесс и добиваются все вместе хороших результатов.
Удачи вам на ниве Agile, а ребятам из ScrumTrek новых увлекательных AgileCamp’ов (и да, «Черный экран», привет!).
Автор: Kluge
