Agile: секреты эффективных команд

agile_ustwo
Полтора года назад я переехала из Москвы в Лондон и начала работать в студии ustwo. Я — программист, последние несколько лет пишу приложения для iOS. Ещё на собеседованиях было понятно, что ustwo — это особенное место: расслабленная атмосфера, домашне-хипстерский дизайн офиса, умнейшие люди. И наш процесс разработки продукта — тоже особенный.

Клиенты приходят в студию не только для того, чтобы мы помогли им создать новый продукт, но и чтобы научиться работать, как мы. И мы стараемся сделать так, чтобы после завершения сотрудничества компания-клиент продолжала использовать наши методы. Они основаны на Agile, но многое мы поменяли под себя или придумали сами. До Лондона я пять лет работала программистом в разных компаниях в Москве, и везде был самый обычный waterfall — начальство и аналитики придумывают задачи, дизайнеры делаю дизайн, разработчики пишут код, тестировщики тестируют. Так что в первые недели работы в ustwo меня ждало много сюрпризов.

Люди

Мы называем себя fampany, от слов family и company. Студия была основана двумя лучшими друзьями (отсюда и название, us two), дружба — это основа нашей философии. Как в студии в целом, так и на отдельных проектах. Поэтому в команде, работающей над проектом, нет иерархии и все равны. У нас нет разделения на junior и senior, нет менеджеров. Ответственность за проект лежит на всей команде целиком. Основа этого подхода в том, что мы все — взрослые люди, профессионалы в своих областях, и мы заинтересованы в создании качественного продукта. Мы доверяем друг другу. Не надо никому говорить «сделай это», потому что все и так всё сделают. Это настолько просто, что непонятно, как может быть иначе. Именно поэтому заключительный этап наших собеседований направлен на то, чтобы отсеять людей, которые не готовы работать в самоуправлямой команде.

Обычно команда на проекте состоит из разработчиков, UX и UI дизайнеров, тестировщиков и коуча. Коуч (или, как мы его называем, Team Coach) — это человек, который помогает команде наладить рабочий процесс и следит, чтобы все её члены были довольны происходящим. Он выполняет роль Scrum Master и командного психолога.

Один из самых важных принципов — все члены команды имеют возможность участвовать во всех этапах проекта, от идеи до реализации. Не бывает такого, что дизайнер приходит к программисту и говорит «смотри, я сделал новый экран, теперь ты его должен разработать». К тому моменту, когда дизайн поступает в разработку, его уже много раз видели и обсуждали все члены команды. Потому что чем больше умных людей думают над задачей, тем больше идей они могут сгенерировать, тем лучше продумают проблему, тем лучше придумают решение, тем раньше увидят возможные проблемы реализации.

Чтобы все эти люди могли решать задачи, им нужно отдыхать. Поэтому у нас очень строгая позиция по поводу сверхурочной работы. Мы не засиживаемся в офисе до вечера и не работаем по выходным. Какая бы ни была срочная проблема, всегда будет следующий рабочий день, чтобы с ней разобраться. Я по себе отлично знаю разницу между человеком, который работает с утра и до ночи и человеком, который много отдыхает, выбрасывая все рабочие мысли из головы. Я была обоими этими людьми, и первый из них явно менее эффективен. Он вечно устаёт и у него нет возможности посмотреть на свою работу свежим взглядом.

Методология

Обычно мы работаем по Scrum, точнее, по нашей собственной методологии, которая на нём основана. Спринты (этапы работы) по две недели, в начале — планирование, в конце — демонстрация результатов и ретроспектива (там обсуждают, как прошёл спринт, что было хорошо, а что нужно менять). Я сначала относилась к этому процессу скептически, но потом очень его полюбила.

Во-первых, список задач на спринт всегда фиксированный, и экстренное добавление новых случается только в случае реальных форс-мажоров. За полтора года работы я могу вспомнить только один такой случай. Люди учатся относиться к проблемам спокойнее: даже если задача срочная, ничего страшного не случится, если она будет сделана не прямо сейчас, а через две недели. Во-вторых, больше нет понятия дедлайна. Что несколько парадоксально, учитывая, что теоретически дедлайн есть каждые две недели. Но он очень условный (как, прямо скажем, и все остальные дедлайны). Если задачу не удалось сделать в срок, то нужно просто обсудить имеющиеся проблемы на ретроспективе и работать дальше. При этом я не могу вспомнить, был ли у нас когда-либо спринт, который не удалось выполнить целиком. Обычно мы закладываем чуть больше времени, чем нужно. Я стараюсь закончить все задачи за сутки до конца спринта, чтобы было время на рефакторинг кода и дополнительное тестирование.

Процесс

Работа над задачей начинается с общего совещания, где обсуждается, зачем она нужна, какие требования к ней существуют и какие сложности могут возникнуть в процессе дизайна или разработки. После этого мы проводим sketching sessions, где на бумаге пытаемся в общих чертах набросать новый экран или фичу. В этом тоже участвует вся команда. Рисуем, обсуждаем, снова рисуем. Постепенно становится понятно, в каком направлении двигаться. UX дизайнер начинает работу над прототипом (или несколькими прототипами). Если у него возникают технические вопросы («а возможно ли это сделать и сколько это займёт времени»), он общается с разработчиками.

Проводится user testing, то есть тестирование прототипа на потенциальных пользователях. В зависимости от задачи и проекта этот этап можно пропустить. Например, я сейчас работаю на проекте, связанном с медициной, и там ни одна фича, ни одна строка текста не может быть передана в разработку без предварительного тестирования с врачами. На менее серьёзных проектах user testing можно делать реже, чтобы просто время от времени проверять правильность наших догадок. Проводит тестирование UX дизайнер, но важно, чтобы у всех членов команды была возможность на нём иногда присутствовать. Видеть живых людей, которые пробуют использовать твой продукт — бесценно.

После того, как прототип протестировали на пользователях или на команде, UI дизайнер начинает работу над финальным дизайном. Он тоже время от времени советуется с разработчиками, чтобы его решения не оказались для них сюрпризом. Перед тем, как приступить к разработке, вся команда снова собирается вместе. Смотрят финальный дизайн и обсуждают список требований (который обязательно должен быть у каждой задачи).

На некоторых проектах после этого проводится совещание, которое мы называем BDD (behavior-driven development) session. На нём пишутся сценарии для всех требований. Например, если требование — «показать список книг», то сценарий — «пользователь переходит в раздел книг и видит там список книг». Расписав все сценарии, мы ещё раз проверяем, правильно ли мы понимаем задачу, все ли случаи учтены и для всего ли у нас есть дизайн.

После этого программисты могут приступать к разработке. Во время работы над интерфейсами они периодически совещаются с дизайнерами, если у них возникают какие-нибудь вопросы или сомнения. Никогда не поздно сказать «слушай, кажется, мы вот тут кое-что не учли». Когда работа программиста закончена, команда должна её проверить. Разработчики проверяют код; тестировщики проводят ручное тестирование и пишут часть тестов (unit тесты обычно пишет автор задачи); дизайнеры проверяют, что приложение выглядит и ведёт себя так, как было задумано. Это моё любимое ноу-хау, мы называем этот процесс PPP, что расшифровывается как Pixel Perfect Precision. Изначально мы придумали этот термин для описания нашего подхода к дизайну продуктов и даже написали об этом небольшую книжку.

Когда все участники процесса счастливы и довольны результатом, работа над задачей завершается.

С 2013 по 2015 годы Google проводил исследования, пытаясь выяснить секрет успеха эффективных команд. Оказалось, что результаты команды мало зависят от суммарного опыта её членов. На самом деле в основе всего лежит психологическая безопасность (psychological safety). Это означает, что всем членам команды должно быть комфортно друг с другом. Они не боятся рисковать и быть уязвимыми. Нестандартная идея, странная шутка, «я не знаю, как это делать, ты не мог бы мне помочь» — в хорошей команде все эти вещи воспринимаются с пониманием и поддержкой. И, как показывает наш опыт, именно такие команды создают лучшие продукты.

Другие статьи автора: Аля Позднякова

Эффективность 101: дзен и планирование

Я привыкла всё делать логично и эффективно. Работать, тренироваться, покупать еду, ходить...
Подробнее

Не пропустите свежие статьи о e-commerce

Подпишитесь на рассылку и получайте подборку свежих статей раз в неделю. Без рекламы и спама.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *