Эволюция Скрама в «Моём Круге»

До Скрама команда довольно успешно работала по более-менее традиционному подходу: — менеджер формирует задачи на ближайший релиз, — во время совещаний эти задачи распределяются. — В течение рабочей итерации каждый разработчик пишет отчёт о проделанной работе и после релиза на очередном собрании все узнают о вкладе каждого в развитие проекта. Этот подход работает достаточно хорошо, поскольку команда пока еще небольшая — 3 разработчика и менеджер.
Постепенно команда увеличивается. Появляются дополнительные разработчики, аналитик, верстальщики, тестировщики. С ростом команды появляются трудности. Труднее всего менеджеру — задачи растут как на дрожжах. Новые фичи, старые баги, редизайн, переезд базы данных, согласование текстов, рассылка… На совещаниях мы уже не успеваем ни оценить проделанную работу, ни зачитать отчёты разработчиков, ни прослушать информацию от аналитика. Встречи начинают занимать всё больше времени. Разработчики всё чаще ошибаются в прогнозируемых сроках выполнения работы. В отчётах постоянно возникает «делал делал, но не успел сделать фичу А». Для того, чтобы добраться до истины приходится писать более детальные отчёты, которые в конечном итоге к сожалению никому не нужны. Общение внутри команды перестаёт быть простым, а в результате любая совместная работа становится менее эффективной.
Сначала мы пробовали работать , поделившись на команды по профессиональной наклонности. Мы поделились на Бэкэндеров и Фронтэндеров. Почти сразу мы ощутили преимущества такого подхода: Бэкэндеры и фронтэндеры могут делать задачи относительно независимо. К примеру, пока бэкэндеры пишут классы работы с базой данных и бизнес-логику, фронтэндеры рисуют и верстают интерфейс пользователя. Планирование упрощается — бэкэндеры рассматривают только свои задачи, а фронтэндеры только свои. Раздельное планирование экономит время, кроме того временные издержки сокращаются за счёт того, что разработчики занимаются задачами именно в той области, в которой они являются экспертами. Тем не менее недостатки тоже не заставили долго ждать: Проблемы с коммуникацией этот подход никак не решил, более того, он воздвиг новые барьеры — фронтендер и бэкэндер, занимающиеся одной фичей, вынуждены отдельно от своих команд синхронизировать свои действия. Процесс становится менее гибким — в случае каких-то изменений в разрабатываемой функциональности, особенно если эти изменения вносит одна из сторон (эти безумные фронтэндеры опять переделали всю форму, откуда им знать, что мы никак не можем сохранить данные, полученные от такой формы, расскажу им об этом на следующей встрече). Следствием этих двух недостатков становится уход от ответственности: (я свою часть работы сделал, а то что они там не сделали меня не волнует, я в этом всё равно не разбираюсь) Очевидно, что такой тип разделения был не самым удачным и мы продолжили поиски другого пути
Нам трудно смириться с меньшей эффективностью работы команды, поэтому в поисках решения мы обратили внимание на Скрам и пригласили Асхата Уразбаева помочь нам в миграции нашего процесса. Чем нас подкупил Скрам: Наш процесс оказался в чём-то похож на Скрам — короткие итерации, планирование, подобие демонстрации, потому переход на Скрам казался делом несложным Скрам обещал решить наши проблемы: трудности коммуникации внутри команды, пониженную эффективность работы и увеличивающуюся бюрократию Говорят, что Скрам хорошо масштабируется — вдруг мы снова начнём расти? К тому же Скрам очень демократичный и интересный подход. Можно даже сказать «модный» =)
Что же делать, если вас укусил Скрам-мастер? ежедневные скрам-митинги около дашборда Недельная итерация — спринт, раз в неделю демонстрация, ретроспектива и планирование.
От идеи разделения команды мы не отказались и поделились на независимые подкоманды, в каждой из которых были как фронтэндеры, так и бэкэндеры. Кроме независимости такая модель даёт дополнительные преимущества — увеличенная эффективность (две небольшие команды делают две крупные фичи быстрее, чем одна большая) — и дополнительная гибкость (внутри небольшой команды всегда проще договориться и согласовать изменения, возникшие в ходе разработки, а кроме того, одна из команд всегда может перестать делать фичи и начать исправлять баги) Тем не менее и эта модель не лишена недостатков. Основным из них так и остаётся сложность межкомандного общения: часто одна из команд не знает, что делает другая и с ходом времени это «незнание» накапливается.. А это приводит к второй проблеме, которая нам особенно не нравится — «наследственность». То есть ситуация, когда одна из мини-команд «традиционно» занималась, к примеру новым разделом «Компании» на «Моём Круге», а вторая команда и знать не знает как устроен этот раздел. В случае каких-то задержек, болезней и отпусков проблема становится особенно острой. Вывод: эта модель разделения нам подходит, но использовать ее нужно с осторожностью — если есть возможность работать всем вместе, то лучше так и поступать, оставив разделение на независимые подкоманды для «особых случаев»…
Дашборд или дашборда для нашей команды оказалась наверное самым важным изобретением, решившим многие проблемы, существовавшие до внедрения Скрама. Это способ общения разработчиков, наглядный инструмент синхронизации усилий и контроля хода спринта. В первые же недели мы привязались к дашборде, сделанной из вспененной потолочной плитки так, что потом никогда бы не поверили, что нам придется от нее отказаться. Первой же проблемой оказался переезд. В новом офисе нам не нужна была кустарная потолочная плитка — одна из стен в нашей комнате целиком «пробковая». Но уже через пару недель мы заметили, что «переносом сделанных тасков» на дашборде люди стали заниматься на скрам-митингах или вообще стали забывать это делать. Оказалось, что в новом помещении просто неудобно расположены столы и нет возможности легко подойти и посмотреть на дашборду. Кроме того, слишком мало места для того, чтобы собираться всей командой на скрам. Отсюда совет всем внедряющим — убедитесь, что доступ к дашборде максимально лёгок для всех членов команды — это гораздо важнее, чем кажется на первый взгляд. Вторая проблема с дашбордой существовала давно, просто мы старательно ее обходили: наши тестеры располагаются в питерском офисе Яндекса и не могут полноценно участвовать в скраме и видеть нашу дашборду. Мы подключали их с помощью видеосвязи, но это не помогает — даже если все члены команды обладают удобным доступом к дашборде, а один — не обладает никаким, то работа становится гораздо менее эффективной. В нашем случае тестеры с запозданием узнавали о выполненных тасках и не имели возможности своевременно протестировать и сообщить об их готовности к релизу. Нашим решением стало использование Jir -ы, а если быть точнее, то модуля GreenHopper , который представляет собой свою, виртуальную дашборду, с дрэг-энд-дропом и аджаксом. Скорость и удобство работы с джирой заметно меньше, чем с бумажными карточками, висящими на соседней стене, но зато этот доступ имеют все члены команды, что гораздо важнее. Само собой, джира дает дополнительные преимущества — хранит таски, ссумирует за нас человеко-часы, отслеживает историю релизов и многое другое. Тем не менее мы иногда ностальгируем по бумажной дашборде из потолочной плитки… =)
Планирование, наверное, является самой сложной частью процесса в Скраме. Но при грамотном проведении его сложность компенсируется лёгкостью всей следующей итерации. Тем не менее, чтобы упростить планирование и избавиться от ошибок (а ошибки планирования всегда всплывают в процессе и порой стоят очень дорого), мы использовали разные практики: Прежде всего это плэнниг покер. Покер позволяет довольно точно оценивать задачи — каждый участник планирования выставляет свою оценку некоторой задаче, а финальная оценка появляется на карточке только после того, как мнения всех игроков совпадут. У покера тем не менее есть недостатки — с ним планирование немного затягивается. С одной стороны — это расплата за более высокую точность оценки, но нередко бывает так, что на очевидную оценку типа «да поправить эту форму это дело 30 минут» приходится тратить 5 минут, потому что кто-то выкидывает «вопрос» или «1 час» со словами «ну я эту форму в глаза не видел, так что не знаю как оценить». Наше решение — мы постепенно отказались от покера, хотя он хорошо работает. Но если у нас возникают разногласия в оценке, то мы идём по проверенному пути. Вторая практика, вернее подход — использование в оценке «идеальных часов». Не вдаваясь в подробности хочу сказать, что основной засадой в оценке идеальными часами является подход типа «ну мы то знаем, что это идеальные часы, поэтому больше 1 часа ставить будет слишком много». Обычно один из разработчиков или менеджеров может давить на команду, рассчитывая снизить время на задачу до «разумного». Это разрушает саму концепцию идеальных часов и часто ведет к перепланированию. Нередко планирование слишком сильно затягивается, тем не менее очень важно довести его до конца. По началу оно может отнимать так много времени, что на него может уйти 4 или даже 6 часов, что просто невыносимо. Однако постепенно, с опытом, команда начинает проводить планирование всё быстрее, не теряя при этом точности и не пропуская важные задачи. Лично мы пришли ко времени порядка 2 часов на недельную итерацию. А если бы использовали бумажную дашборду, то возможно управлялись бы еще быстрее. Когда я рассказывал про неудачную попытку разделить нашу команду на бэкэндеров и фронтэндеров, я упомянул, что кое-какой полезный опыт из этого эксперимента мы вынесли. Мы поняли, что процесс разработки у верстальщиков отличается от всех остальных разработчиков — им приходится выполнять очень много мелких задач, а еще эти задачи нередко появляются прямо во время спринта (что всеми другими разработчиками обычно воспринимается без особого энтузиазма). Поэтому мы отделяем все мелкие интерфейсные задачи не связанные с бэкэндом, такие как вёрстка, косметический редизайн, тексты на сайте, и т.п. Их группировкой и планированием занимаются только фронтэндеры. И наоборот — в планировании глубокобэкэндных задач они не участвуют. Это не только ускоряет весь процесс в целом, но вдобавок избавляет от лишнего утомления команду. Поскольку кроме команды решения о новой функциональности часто принимают отдельные важные люди, то разумным решением было добавление еженедельной встречи с экспертами до или сразу после планирования. Переносить эту встречу на другой день весьма неудобно — нередко фичи начинают разрабатываться, а потом не проходят согласование с маркетингом или кардинально меняются после встречи с другими экспертами.
Демонстрация — это еще одна очень важная часть Скрама. Хорошая демонстрация экономит очень много времени, потому что позволяет большому количеству людей увидеть и обсудить новые изменения в проекте, собрать очень важный ранний фидбэк и оценить прогресс взглядом со стороны. Мы используем традиционную модель — каждый разработчик подключается к проектору или плазме и демонстрирует свои достижения. Зрители комментируют и собирают фидбэк. Первой важной деталью демонстрации являются зрители. Если по каким-то причинам на вашу дему не успевают дизайнер, продакт оунер и еще пара человек, то нужно ее перенести. Потому что почти никакого смысла в демонстрации «самим себе» нет. Лучше всего, если дему увидят люди, которые раньше ее не видели. Чтобы еще больше расширить круг посетителей демонстрации можно использовать видеоконференцию или хотя бы конференц-кол. Дайте возможность всем участвовать в обсуждении. Как уже упоминалось, необходимо собирать любой возможный фидбэк от участников демонстрации. Например, зрители могут сразу обратить внимание на недочёты дизайна, кривую вёрстку или откровенные баги. Всю информацию может фиксировать один человек, но мы используем средства коллаборативного редактирования, это экономит время. Еще хочу упомянуть о том, что даже очень хорошо организованная демонстрация нередко плавно перетекает в планирование, когда кто-нибудь из участников начинает обсуждать подробности реализации той или иной фичи. Скрам-мастер должен аккуратно пресекать любые обсуждения такого рода.
Ретроспектива — это положительная обратная связь в скраме — способ найти и исправить проблемы, а также увеличить эффективность процесса. Тем не менее с ретро у нашей команды сразу не заладилось. Так или иначе, но вспоминаем о ретроспективе мы только в том случае, если несколько спринтов подряд всё идёт не так как хотелось бы. Основной причиной такого отношения нашей команды к ретро по всей видимости является невысокая исполняемость решений, вынесенных в ходе ретроспективы. Теперь, если мы проводим ретро, то стараемся искать исключительно простые решения возникших проблем. Если такие решения не находятся, то вся ретроспектива — пустая трата времени. Решения вида «проводить скрам каждый день» у нас не работают. А вот решения «проводить скрам каждый день не позже чем через час после полдника» работают =) Решения нужно фиксировать на карточках в виде заданий на следующую итерацию, либо каким-то другим привычным способом. Результаты следования принятым решениям нужно обязательно обсуждать на демонстрации либо на следующей ретроспективе, иначе никто не вспомнит про них и это еще раз незаметно снизит ценность ретроспективы. В целом, мне самому очень интересен положительный опыт использования ретро в других командах.
Какой же стала модель взаимодействия команды с внешним миром после внедрения Скрама? Прежде всего, де факто, в команде нет менеджера проекта. И если честно, то после того, как менеджер исчез, ничего особенно не изменилось. Процесс уже настолько привычен, что с уверенностью можно сказать, что сейчас в команде разработки нет ни одного человека без которого бы процесс остановился. Тем не менее у нас есть менеджер продукта или продакт-оунер, который отвечает за общее направление развития, а также несколько экспертов: менеджеры по маркетингу, менеджеры портала, редакторы. Как я уже говорил — со всеми этими людьми нужно советоваться и очень важно делать это как можно раньше — лучше всего сразу после планирования либо даже до планирования. Еще одной важной деталью является выбор экспертов: дело в том что если обращаться за помощью и советом ко всем возможным советчикам, то продукт никогда не достигнет релиза… Поскольку команда разработки МК относительно самостоятельная, то взаимодействие с другими командами происходит не так и часто. И это один из наших недостатков. Сотрудничество команд, использующих Скрам, происходит очень естественно: чтобы обсудить и поставить задачу для другой команды нужно просто заглянуть к ним на планирование, чтобы следить за прогрессом — нужно смотреть на их дашборду, а чтобы оценить результат — нужно посетить демонстрацию. Взаимодействие абсолютно независимых скрам-команд настолько простое и элегантное, что после такого опыта бывает непросто вернуться к реалиям «написать письмо менеджеру проекта А и теребить его каждый день, пока они не сделают то что нужно». Я уже упоминал, что тестеры в нашей команде работают над проектом из питерского офиса. Практика показала — скрам можно адаптировать к самым разным условиям и удалённые сотрудники тоже могут жить «по скраму». Что для этого нужно? Обеспечить их максимально прозрачное участие в скрам-митингах, демонстрации и планированию. И конечно максимально удобный доступ к дашборду и бэклогу.
Еще несколько слов об инструментах, которые мы используем. Для визуализации дашборды мы используем Jira с модулем Greenhopper . Это полноценная доска, в которой можно смотреть на карточки, перетаскивать их, создавать новые и удалять старые. Мы используем сразу несколько «досок» для того, чтобы отслеживать задачи на текущий спринт, сделанные в прошлых спринтах задачи, которые еще не ушли в релиз, а также задачи, которые еще не были запланированы, но несомненно интересны. Для общения с тестировщиками и другими удалёнными сотрудниками мы используем офисную конференц-связь. С тем же успехом можно использовать skype . Для подключения удалённых зрителей к демонстрации мы используем оборудование для расшаривания экрана в переговорке. Кроме того можно использовать удалённый рабочий стол или удалённого помощника. А еще новые бета версии скайпа тоже позволяют расшаривать экран. Для сбора фидбэка во время демонстрации мы используем коллаборативный редактор. С его помощью каждый участник демонстрации может дополнять единый документ с выводами и результатами демы, который используется потом на планировании. Самое простое и популярное решение в вебе сейчас — это Etherpad. Я очень рад, что его всё таки не закрыли. Для ведения бэклога мы используем внутреннюю вики. Мы сразу пишем все планируемые задачи в прошедшем времени, чтобы потом оставалось только перенести их в «сделанное», без изменения формулировки =)
Фидбэк чрезвычайно важен для нашего проекта, поэтому его своевременное поступление и обработка являются существенной частью нашего процесса. Наверное самым ранним источником фидбэка является отчёт с демонстрации. Это наш дополнительный артефакт, на создание которого нас толкнули проблемы с памятью — многие замечания, сказанные на демонстрации, забывались во время планирования и поэтому никогда не доходили до разработки. Чтобы этот отчёт не давил тяжким грузом бюрократии на наш гибкий процесс, время жизни его ограничено сутками, то есть он выполняет роль буфера обмена. Саппорт Яндекса является еще одним источником фидбэка, но уже не раннего, а самого что ни на есть позднего. Поэтому периодически мы собираем все замечания от пользователей, поступивших через официальные каналы саппорта. Некоторые из них идут напрямую на планирование. Родные и близкие всегда готовы прийти на помощь. Самый лучший способ увидеть все проблемы с формой регистрации — попросить зарегистрироваться маму любимого менеджера. Едиснтвенная проблема в этом решении — через некоторое время нужно искать новую «маму». С помощью поиска по блогам можно найти массу всего полезного. В том числе и отзывы пользователей о нашем проекте. Если вы сейчас придумываете название своему проекту, то задумайтесь, а как вы потом будете искать его упоминания в блогах =) Поиск в социальных сетях в общем то также доступен через сервис blogi.yandex.ru , но у нас есть еще один маленький инструмент сбора фидбэка — наш дизайнер, Алишер Якупов, завёл за правило расставлять хэштег #mkbug в комментариях к любым найденным упоминаниям о багах на «Моём Круге». По этому хэштегу мы легко и просто «достаём» все текущие упоминания о багах прямо во время планирования. Более того, со временем некоторые люди стали сами расставлять этот хэштэг, за что им отдельная благодарность =)
Прошло почти полтора года после внедрения Скрама в «Моём Круге». Можно подводить какие-то итоги. Чем мы особенно довольны: Все члены команды участвуют в создании продукта на всех стадиях. Это дает очень приятное ощущение причастности. Проблемы с коммуникацией в команде теперь нас не одолевают так сильно, как раньше. Мы приспосабливаемся к изменениям. Внешние воздействия, приводящие к изменениям и пересмотру планов, теперь переживаются гораздо легче. Мы чувствуем себя одной дружной командой, даже не смотря на удалённых сотрудников . В случае каких-то проблем или сложностей мы находим способ справиться с ними с минимальными потерями Мы постоянно развиваемся, потому что в условиях скрама гораздо проще делиться опытом Кроме того, как нам кажется, пути назад уже нет, нам нужен путь вперёд =)

Эволюция Скрама в «Моём Круге»

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (8)

Similar to Эволюция Скрама в «Моём Круге»

Similar to Эволюция Скрама в «Моём Круге» (20)

Recently uploaded

Recently uploaded (9)

Эволюция Скрама в «Моём Круге»

Editor's Notes