Совместная работа над одной историей в распределенной команде – Swarming Across Distance
| June 15, 2012 | Posted by admin under Практики, Статьи |
“Swarming” (swarm – роиться, копошиться) – это методика, когда многие члены команды работают вместе, в одно и то же время, над реализацией одной пользовательской истории и могут использовать для этого все множество своих навыков. Это признано мощным подходом для быстрой поставки высококачественных историй. Джоанна Ротман рассматривает, как достичь тех же результатов, когда ваша команда распределена географически.
Мы знаем, как использовать swarming, когда все члены команды расположены в одном месте. Но что делать, если вы – часть географически распределенной agile команды? Решение зависит от того, как вы распределены, и сколько часовых поясов между вами.
Как вы распределены?
Слишком много географически распределенных команд разделены по функциям. Так, разработчики, или некоторые из разработчиков, находятся в одних местах, а тестировщики, или некоторые из тестировщиков, – в других. Product owner/заказчик – еще в одном месте, и если есть бизнес аналитики, то часто они находятся где-то еще.
Проще всего проиллюстрировать это историей. Я встретила менеджера программ, Стефана, на одном из моих семинаров. Он работал в Германии. Стефан был обеспокоен одним из проектов в своей программе. В проекте было два разработчика в Великобритании, один разработчик во Франции, два – в Германии, и два тестировщика в Бангалоре. Product owner был в Германии, и, кроме того, product owner пытался управлять баклогом для двух других команд.
В этой картине много неправильного. Но однако же эта история – типичный случай того, что я слышу время от времени от географически распределенных команд. Поскольку команды не используют swarming, product owner считает, что у него есть время для одновременного выполнения задач для нескольких команд.
Фокус на усилия
Первое предложение, которое сделал Стефан, – разработчики должны уменьшить свой показатель WIP (прим. перев. – см. Work in Progress ), они должны фокусироваться на одной истории в один момент времени. До этого каждый из них занимался своими собственными историями. Теперь все они обсуждали вопрос “Как нам начать работу по одной истории вместе?”
Начать работу вдвоем
Они не начали все вместе. Сначала двое разработчиков в Великобритании начали работу над историей. Такое решение было связано с тем, что они находились в одном часовом поясе. Имело смысл начать с наименьшей разницы в часовых поясах.
Эти двое разработчиков физически находились в разных местах, поэтому перед ними возникли те же вопросы, что и у географически распределенной команды. Они использовали Google docs, разделение экранов (screen sharing), парное программирование, и работу посредством архитектуры. Они практиковались на нескольких историях. Оказалось, что их истории слишком большие. Когда они сделали их меньше, одновременная работа стала легче.
Добавление еще одного разработчика
После того, как разработчики из Великобритании попрактиковались на одной истории, появилась готовность добавить еще одного разработчика. Для следующей истории имело смысл добавить одного из немецких разработчиков. Им надо было решить проблему с разницей часовых поясов в один час, а также с разным временем начала и окончания рабочего дня и перерыва на обед.
Они сработались и смогли поставить историю, после чего они решили, что готовы ввести тестировщика. Но они были озабочены разницей часовых поясов.
Добавление тестировщика
Имея Манчестер и Лондон в Великобритании, Мюнхен в Германии и Бангалор в Индии, у проектной команды появилась значительная разница часовых поясов. В течение рабочего дня у них было максимум пять часов для совместной работы, предполагая что тестировщики останутся подольше, а разработчики отложат обед. Можно работать так время от времени, но не постоянно.
Поэтому, вместо того, чтобы работать вместе все пять часов, команда решила разбить свое время на определенные временные интервалы (timebox-ы).
Работа во временных интервалах
Мы уже знаем цену работы во временных интервалах – это во многом присуще agile. Но нам не обязательно работать в одно- или двухнедельных временных интервалах. Мы можем работать и в меньших интервалах.
Команда решила использовать мощь временных интервалов , чтобы направить усилия во время совместной работы над одной фичей , и сделать максимум работая вместе.
Первые 90 минут они работали вместе (swarming). Разработчики и тестировщики разделяли экраны , занимались парным программированием, и т.д., все что можно вообразить для команды, размещенной в одном месте.
За рамками этого выделенного интервала все зависело от того, что происходило у конкретного человека.
Могут ли люди синхронизировать свои обеды? Или они теряют остаток дня на обед? Команда должна была решить это. Эта команда попробовала несколько подходов, в зависимости от того, что еще происходило.
Ручное тестирование замедляет команду
Когда они начали заниматься swarming-ом, тестировщик мог тестировать только вручную. А значит, команда получала технический долг в каждой итерации, и тестировщик никогда не осознавал до конца, что происходит. Когда он работал с разработчиками, то понимал , что делает фича, но все же он не мог разработать автоматизированные тесты.
Благодаря swarming-у, разработчики смогли встроить «зацепки» в код, чтобы тестировщик смог автоматизировать некоторые тесты. Это не было совершенным решением, но ничто не совершенно.
С помощью коучинга, тестировщик стал меньше бояться автоматизации, и начал действовать более продуктивно.
Добавляем Канбан для визуализации прогресса
Поскольку у команды Стефана были члены во многих часовых поясах, и такое небольшое перекрытие по времени, члены команды использовали канбан доску, чтобы отслеживать прогресс историй. Таким образом каждый мог решить, нужно ли ему прийти пораньше или остаться попозже на следующий день.
В географически распределенных командах временные сдвиги – обычная практика. Не нужно делать такие сдвиги каждый день, но если вы видите, что можете помочь команде, если сделаете сдвиг на час или два на день или два, вы возможно пойдете на это. Канбан может помочь команде увидеть, стоит ли это того.
Вскоре команда Стефана поняла, что когда они начали делать swarming чаще, им понадобились временные сдвиги. Они были слишком далеко друг от друга, чтобы swarming проходил легко, если нужно интегрироваться с тестировщиками.
“Нам нужно больше историй!”
Один из эффектов swarming-а заключался в том, что команда заканчивала свою работу быстрее. У них был меньший WIP, и они завершали истории быстрее. Теперь они стали требовать от product owner-а меньших и хорошо написанных историй, которые они могут разработать совместно. Product owner был удивлен и не был готов, что команда начнет требовать работу у него.
Сначала product owner пытался управлять потребностью в историях самостоятельно. Затем он понял, что одновременно делает задачи для всех проектов. Он попросил помощи и передал работы с двумя другими командами еще одному product owner-у, и сконцентрировался на этой команде.
У вас есть другие альтернативы
Есть и другие альтернативы для swarming-а. Если вы решили экспериментировать, вы можете выбрать другой путь. Команда Стефана выбрала:
- Начать с тем, кто ближе.
- Добавить следующего.
- Временные интервалы, чтобы справиться с проблемой разных часовых поясов.
Другая альтернатива:
- Начать с кем-то на каждом архитектурном уровне, плюс тестировщик.
- Временные интервалы, чтобы справиться с проблемой разных часовых поясов.
Еще одна альтернатива:
- Использовать канбан доску для визуализации работы.
- Не пытаться делать swarming в реальном времени, но вместо этого быть доступным, если у кого-то есть вопросы.
Третья альтернатива мне не нравится, т.к. она влечет одновременную работу над несколькими задачами.
Когда вы слишком распределены, чтобы заниматься swarming-ом
Иногда вы слишком распределены, чтобы заниматься swarming-ом как кросс-функциональная команда. Я часто видела ситуацию подобную той, что в проекте у моего коллеги Тима. У него есть разработчики в нескольких местах в США: Кембридж (Массачусетс), Денвер и Сан Хосе. Все тестировщики – в Пуне. Из-за разницы часовых поясов, у них нет подходящего времени для переговоров, что делает невозможной их совместную работу в течение длительного периода.
В проекте Тима разработчики занимаются swarmimg-ом в течение своего дня. После того, как они отработали вместе, закончили свои unit и интеграционные тесты, они передают код тестировщикам в Пуне.
Это не идеально. Однако, они используют канбан доску, чтобы отслеживать прогресс истории и проблемы вокруг нее. Когда у тестировщиков в Пуне есть проблемы, они создают карточки на канбан доске, которые могут увидеть разработчики и отреагировать на них.
Визуализация помогает
Swarming во времени и пространстве – это не просто. Если вы используете инструменты, которые позволяют вам увидеть рабочее пространство друг друга, это может помочь. Но что действительно помогает, так это возможность видеть прогресс работ.
Swarming помогает уменьшить командный WIP, помогает команде закончить свою работу быстрее и лучше, помогает увидеть, куда вы движетесь, и построить отношения между членами команды.
Иногда, вы не можете сделать так, чтобы это работало. Значит, это не нужно. Но если есть такая возможность, попробуйте и посмотрите, что произойдет. Дайте мне знать о результатах ваших экспериментов, хорошо?
-
Dmitry Pavlov
-
Tanya Aleksandrova
-
