Пару месяцев назад я была на тренинге по Scrum. Делясь опытом с соучениками, упомянула, что у меня сейчас команда из десяти человек в восьми офисах. Мне не то чтобы не совсем не поверили, но к разговорам, что у нас нормальный процесс, отнеслись с, вероятно, оправданным скептицизмом.
Однако же, мы успешно делаем проекты командами, разделенными на 2-4 офиса, всего же у нас на данный момент десять офисов разработки, и, когда мы ищем человека в команду, обращаем внимание в первую очередь на его способности и человеческие качества, а уже во вторую — на место жительства. К тому же у нас в компании люди иногда кочуют между офисами, потому что так веселее. В общем-то, когда мы начали работу над нашим текущим проектом, у нас было всего четыре локации.
В DataArt я работаю уже шесть лет, и у меня немалый опыт организации людей, находящихся в сотнях километрах друг от друга. Подозреваю, что члены фриланс-команд читают меня со снисходительной усмешкой, но, думаю, найдутся люди, которым мой опыт покажется небесполезным.
Итак, я хочу поделиться наблюдениями, приемами и принципами организации распределенной команды. В проектах мы обычно практикуем Scrum, за исключением случаев, когда это не получается ввиду неготовности заказчика. Но и в этом случае мы должны быть единой командой, синхронизировать знания, статус и все такое прочее.
Итак, в чем проблема распределенной команды? Коммуникации. Затруднены коммуникации на всех уровнях, что порождает веер проблем. Та самая «транспортировка», которая упомянута как один из компонентов waste (потери) в концепции Lean Software Development.
Я для себя выделила три составляющие проблемы коммуникаций:
- Техническая: если человека рядом нет, к нему нельзя просто взять и подойти, чтобы обсудить какие-то текущие проблемы.
- Мотивационная: если у команды нет своей комнаты, где перед глазами есть доска со стикерами, списком проблем и остальной полезный контекст, фокус и приоритеты начинают «плыть».
- Психологическая: люди, которые не сидят рядом и не видятся каждое утро, обсуждая за кофе последние новости или успехи детей в школе, менее склонны прощать ошибки коллегам, особенно если про коллегу они знают только логин в системе контроля версий и e-mail. Может возникать концепция «мы и они» по отношению к коллегам из другого офиса и прочие неприятные штуки
- Отдельным пунктом стоит адаптация Scrum-активностей под распределенную команду.
Техническая составляющая
Решается современными технологиями вообще на раз-два. Мессенджеры, голосовая связь, screensharing и даже камера в телефоне — все нам в помощь.
Мы уже давно традиционно используем старый добрый Skype, но с ним в последнее время начались проблемы, а у продукта появилось много достойных конкурентов. Мне известно, что как минимум одна команда у нас использует Hangouts. Так что я бы предложила на Skype не зацикливаться.
Все члены команды есть в скайпе, есть общекомандный чат. Люди иногда создают подчатики на несколько человек — обсудить свою проблемку. Есть уговор, что, когда человек за компьютером, он читает, что пришло в скайпе.
Когда не хватает текста и голоса, можно шарить экран. Skype премиум это позволяет даже в конференциях, раньше я еще использовала join.me (наверное, если напрягусь, вспомню еще с десяток подобных продуктов).
Как-то мы обсуждали архитектуру, и я рисовала по ходу в блокноте, потом фотографировала на телефон и посылала коллеге, коллега его дорисовывал в paint и рассылал обратно.
В общем, слава современным технологиям, были бы мысли и идеи, которыми стоит поделиться, а способ сделать это быстро и эффективно найдется.
Мотивационная составляющая
Вот тут уже сложнее. Конечно, у каждого проекта есть вики, Confluence или сайт на корпоративном Sharepoint. Но, положа руку на сердце, кто туда заглядывает, кроме как за ссылками на энваронменты и паролями от тестовых аккаунтов? Правильный ответ: новички проекта в поисках высокоуровневого описания архитектуры.
Но, если людям не напоминать про цели, статус спринта и всяческие простые правила, команда расслабляется. Для успешного процесса нужны информационные радиаторы.
Есть два варианта, я использую оба попеременно или сразу: общее обсуждения того, что мы видим на виртуальном dashboard во время stand-up, и рассылка емкого короткого статус-письма, по факту — тот же самый радиатор.
Например, начиная со второй половины итерации, QA каждое утро рассылают их видение происходящего. Список юзер-стори, статус каждой, кто отвечает за продвижение ее дальше.
Цветовое кодирование статуса — наше know-how (сейчас подумалось, не запатентовать ли). Оранжевый — кодирование в процессе, девелоперы уверены, что успеют; желтый — передано в тестирование; салатовый — тестеры приняли и историю можно показывать; зеленый — принял PO. Красный — высокий риск не успеть, т. ч. не тратим усилия, пока не закроем остальные. Еще был оговорен черный — для исключенных из итерации. Если тестеры не приняли функционал, он отскакивает на оранжевый или красный уровень.
В том же письме напоминается список рисков, блокеров и всего того, о чем стоит помнить прямо сейчас. Такое письмо рассылается раз в день после stand-up, оно должно быть максимально коротким и включать в себя только самое важное. Вполне себе выполняет основные функции тех самых красивых и не очень диаграмм, развешанных по стенам комнаты для stand-up. Главное, чтобы оно и правда было коротким, и самое важное должно быть сверху: ни один девелопер не будет прокручивать донизу десять экранов «какого-то менеджерского бреда»
Психологические аспекты
Я не дипломированный психолог, однако мне очевидно, что, если участники проекта ощущают себя одной командой, особой группой, они будут друг друга поддерживать, прощать, не желать подвести команду, и великодушно предлагать помощь забуксовавшему коллеге.
Самое больше препятствие для этого — чисто деловые отношения, когда члены команды воспринимают друг друга не как живых людей, а как непонятную картинку с аватара, где какой-то чувак в мотоциклетном шлеме позирует на фоне развалившегося пионерлагеря, и все это в размере 70х70 пикселей и снято 10 лет назад.
Чтобы логины в логе коммитов и ники в скайпе воспринимались как живые люди, я всегда прошу людей при разговорах использовать камеры, чтобы мы видели живого человека, мимику, невербальную информацию; в общем чате и даже на stand-ups приветствуется small talk, обсуждение каких-то новостей, проблем, ссылки на цитаты с баша. В аккуратных дозах это не мешает работе, но зато создает понимание и ощущение того, с кем ты работаешь.
Вначале проекта мы, конечно же, стараемся все собраться и побухать познакомиться поближе, устроить тимбилдинг. Если все удалось, на несколько месяцев запала хватает, а, чтобы продолжалось подольше, нужно прилагать некие усилия по поддержанию человеческих отношений.
Не все люди видят в этом всем смысл. У нас команде есть человек, про которого я даже не знаю, как он выглядит, потому что он принципиально не использует камеру (видела одну старую фотку). В другом проекте кое-кому мешал проектный чат. В скайпе есть опция: сделать так, чтобы нотификации о новых сообщениях чата появлялись только в том случае, если там есть ключевые слова. У нас было специальное заклинание для вызова QA-лида.
Парадокс в том, что подобные «чудачества» играют положительную роль и способствуют появлению внутрикомандных мемов, понятных только участникам проекта. А общие шутки сближают, как ничто другое.
Вообще, внутренние шутки и традиции проектных команд, наверное, должны быть предметом изучения социологов. Когда что-то новое возникает и живет длительное время в наших проектах, я всегда радуюсь, потому что чем больше общего контекста, тем меньше разделения на «они» и «мы», тем сплоченнее команда.
Здесь же, наверное, стоит упомянуть практику face-to-face (one-to-one), которая тоже прекрасно срабатывает по скайпу, но она хороша и не для распределенных команд, тут особой специфики нет.
Адаптация Scrum-активностей
Agile ввел понятие команды и командной ответственности как противовес отдельным инженерам, каждый из которых делал какой-то свой кусок работы, понятия не имея, на каком этаже сидит тот, кто делает соседний.
В конце 90-х, когда эти идеи зародились и оформились, еще не было так развито видеообщение. Мощности рабочих станций могли себе позволить только электронную почту и ICQ (Jabber, IRC, etc.) и единственным разумным выходом и правда было сажать всех вместе. Сейчас уже технологии позволяют адаптировать Scrum под использование видеоконференций не вырождая при этом идею в кошмарные карго-культы.
Daily Scrum
Самое простое. Все наливают кофе, садятся за компьютер, надевают наушники и начинается Skype-конференция. Stand up как stand up.
Обычно лидер проекта шарит свой экран, на котором развернут наш скрам-тул. Обновляем статус, потраченное время, что там еще.
Договариваемся о митингах, обсуждаем проблемы. Единственное различие — люди прихлебывают свой утренний кофе не стоя.
У нас есть правило, что сначала высказываются все коротко, если кому есть что обсудить, остается в конференции, кому не надо, могут отключаться и идти работать. Я обычно по итогам митинга рассылаю минутки, и все замечательно.
Sprint Planning Meeting
Вот это самое сложное. Мы опять собираемся в конференцию, PO шарит экран со скетчами и описанием истории, команда смотрит, обсуждает, голосует…
По классике, он может длиться до 4-х часов.
Нереально. По опыту, если человек сидит в наушниках больше 30 минут, ему просто необходимо расслабить внимание и перевести взгляд, он внезапно оказывается читающим почту или ленту фейсбука, и вы его теряете. Если человеку интересна тема беседы, он может продержаться 45-60 минут, но это уже край, потом надо размять ноги, шею, выпить воды…
Если разойтись «на 10 минут», это затягивается, потому что кто-то пошел налить кофе и застрял спорить о достоинствах последнего фреймворка. Пока его все ждали, программисты уже ушли в код, а тестер запустил пачку автотестов и сейчас как раз льет тестовые данные в базу через VPN, поэтому у него все булькает и изображение замирает.
Поэтому спринт мы планируем сильно заранее кусками по 30-35 минут в день. Иногда два куска — утром и вечером.
Planning pocker тоже происходит по скайпу. Если у всех членов команды есть колода, люди просто выбирают карту и показывают рубашкой к камере со словами «готов». Если нет карт, то цифра набирается в чат, человек говорит «готов». По команде люди переворачивают карты или нажимают «enter».
Были у нас промежуточные варианты вроде рисования цифры в блокноте маркером, или приложения для Andriod, которое рисовало карту на экране.
Sprint Review и Sprint Retrospective
Разнесены по времени и тоже проходят как видеоконференции. Зачастую стейкхолдеры-заказчики имеют какую-нибудь комнату, оборудованную камерами, экранами и прочим иногда даже работающим оборудованием, т. ч. для них делается презентация, ведется лог вопросов замечаний, рассылаются итоги…
Ретроспектива обычно бывает уже на следующий день, список тем и голосование по ним идет через проектный чат.
Последняя сессия планирования, знаменующая начало итерации бывает уже после ретроспективы, чтобы, если необходимо, сместить акценты итерации и что-то добавить-убрать.
Вот, собственно, и все.
Ничего особо премудрого, но работает.
И мы действительно делаем проекты распределенными командами.
Всем хорошего дня!
Автор: eshalapanova
