Когда миф сталкивается с мифом,
столкновение бывает весьма реальное
О Scrum и проблемах его имплементации сейчас говорит едва ли не каждый, у кого есть представление об управлении проектами.
Обилие достоверных (и не очень) источников информации в сети позволяет любому новичку уже через час качественного серфинга в интернете вести лекции по основам Scrum и, с видом бывалого скрам мастера, рассказывать о проектах, где данный фреймворк не работает ни в каком виде.
Команда IAMPM проанализировала сложившуюся ситуацию и пришла к выводу, что нередко знания о Scrum в головах тех, кто не читал Scrum Guide, основываются на сплетнях и мифах (а мифы, как известно — это устаревшие сплетни).
Сказать по правде, даже читавшие гайд не всегда интерпретируют его правильно. Чтобы качественно расхлебать эту кашу нужен целый курс. Даже серии статей будет мало, чтобы расставить все точки над «Ё». Поэтому, давайте развеем хотя бы самые распространенные заблуждения и почистим пространство вокруг себя.
Миф №1: Волшебная самоорганизующаяся команда и менеджер, который должен уйти
Junior Scrum-послушники в коридорах своего Agile храма шепчутся о том, что самоорганизующаяся команда, которую никто никогда не видел, сойдет с небес на землю, и тогда менеджер, опекающий команду на протяжении всей жизни, уйдет.
А если серьезно, многие говорят, что создать самостоятельную команду с взаимозаменяемыми участниками — задача непосильная. На самом деле, проблема в самой трактовке понятия «самоорганизация».
В оригинальном значении, отсутствие жесткого менеджмента — это свобода выбора для команды по вопросам: «что делать», «когда делать», «как делать», дающая прирост продуктивности и развивающая чувство ответственности в каждом участнике. Менеджер, или в нашем случае Scrum Master, всегда будет рядом с командой, мягко наставляя и взращивая своих товарищей.
Миф №2: Scrum команда — это вся команда проекта, которую потенциально можно поделить на подкоманды
Scrum Guide четко дает понять, что Scrum команда не может состоять из подкоманд, и вся команда должна быть сфокусирована на одном виде деятельности. Что имеется в виду?
Классическая Scrum команда не должна состоять из дизайнеров, frontend и backend-разработчиков, тестировщиков, маркетологов и других специалистов, но могут быть отдельные команды frontend, backend, QC, design и так далее, сфокусированные в рамках спринта на конкретных целях.
Миф №3: Участник Scrum команды — и жнец, и чтец, и на дуде игрец
Ноги у данного мифа растут из предыдущего пункта. Часто начинающие адепты самого популярного фреймворка считают, что каждый член команды должен быть одинаково талантлив во всем: разработчики должны рисовать крутые макеты, дизайнеры — шикарно верстать, тестировщики — кодить и самостоятельно фиксить баги и т. д.
Как вы уже поняли, речь идет о термине «взаимозаменяемость», и он совершенно не об этом.
В рамках методологии Scrum команда должна состоять из специалистов одинакового стека, сфокусированных на одной общей цели. Задачи между разработчиками должны распределяться таким образом, чтобы все члены команды знали как архитектурно устроен проект (компонент) и понимали, чем занимаются товарищи по команде, чтобы в непредвиденной ситуации помочь своему коллеге, или даже закончить задачу вместо него.
Миф №4: Scrum — оправдание для тех, кто не умеет писать документацию
Тут тоже мимо. Как правило, проекты, процесс реализации которых проходит в рамках Scrum, хорошо документированы, оценены, и распланированы практически по дням. При этом, могут быть и такие ситуации, когда scrum применяют в R&D, тогда конечный результат проекта описан весьма примерно, а цель спринта сформулирована как «провести эксперимент и описать, что получилось».
Такой подход позволяет совершить все возможные ошибки в начале проекта и, в результате полученного опыта, выпустить качественный и востребованный продукт.
О применении Scrum в подобных проектах менеджеры рассказывают более охотно, на почве чего и рождается неправильное представление о документировании проекта в рамках фреймворка.
Миф №5: Митингу — время, работе — час
Обидное суждение о том, что в рамках Scrum (да и Agile, в принципе) у разработчиков не остается времени на работу из-за постоянных митингов появилось… Да бог знает, кто сказал об этом первым! Главное, что возник такой миф из-за тотально неправильной организации времени, выделенного на митинги!
Проблемы, о которых часто говорят:
- Дейли митинг может затянуться до получаса.
- На Scrum митинге разбираются вопросы каждого индивидуально, а в это время остальная команда скучает.
- Встреч слишком много и они проводятся часто.
- Иногда на встречу не приходят ключевые фигуры.
- Львиную долю времени может занимать «треп не по теме».
- Встреча заканчивается без достижения соглашений.
- Во время митинга не у всех есть возможность встретиться.
Решать такие проблемы несложно, достаточно лишь установить правила проведения встреч и следовать им. Вот несколько простых советов.
- Предупреждайте свою команду о проведении встречи заранее. Если встреча ежедневная — добавьте повторяющееся событие в календарь.
- Определите временные рамки встречи и не выходите за них.
- За несколько часов до встречи скиньте всем участником адженду митинга и дайте возможность сформулировать вопросы. Постарайтесь собрать все вопросы и комментарии по поводу цели собрания до начала митинга, чтобы примерно продумать структуру беседы.
- Выберите фасилитатора митинга или возьмите эту ответственность на себя. Фасилитатор встречи следит за временем, не дает участникам отходить от темы, направляет беседу в русло, нужное для достижения соглашения, не дает обстановке накаляться.
- Если у кого-то из вашей команды есть объемный вопрос, который он хотел бы с вами обсудить, но это не касается темы встречи или не несет пользы для остальной команды, пригласите сотрудника на кофе после митинга и обсудите все один на один.
Эти и другие правила проведения встреч значительно упростят вам жизнь и позволят сократить время, затрачиваемое на постоянные коммуникации.
Миф №6: Стартовавший спринт — неприкосновенный Грааль, в который нельзя ничего наливать
Можно же! Главное — не смешивать! Каждый спринт, который вы спланировали и начали, должен иметь цель. Если появились маленькие (и не очень) задачи, которые необходимо выполнить, смело добавляйте их в спринт. Но не перестарайтесь, добавленные задачи не должны отвлекать от главной цели. Отвлекают? Уберите их обратно.
Откуда мы знаем? Так говорит Scrum Guide!
P.S. Есть еще одна микро-сплетня, о которой мы просто не в силах промолчать. Многие думают, что по окончанию спринта получение новой работоспособной версии совершенно необязательно и можно две-три недели заниматься исключительно инфраструктурными задачами.
Не-а. Так не работает.
По окончанию спринта заказчик должен получить работоспособную версию, которую уже можно дать пощупать бета-тестировщикам, а то и зарелизить! Таким образом мы реализуем принцип постоянной доступности продукта: захотел показать пользователям — показал, не захотел — не показал.
Миф №7: Заказчику полработы не показывают
Выглядеть вполне самодостаточной командой и не получать никаких занудных и неудобных правок от заказчика во время итерации — мечта всех разработчиков. Стремление к исполнению данной мечты ведет к тому, что после кровью и потом подготовленного демо, команда переделывает все заново.
Почему так происходит? Команда неверно переняла видение заказчика и имплементировала его по-своему, соответственно результат не совпал с ожиданиями, заложенными в проект.
Как этого избежать? Показывать заказчику прототип инкремента и сверять понимание конечного результата командой и клиентом.
Миф №8: Зачем нам ретроспектива? У нас и так все классно
Часто, понятие ретроспективы связывают с решением проблем и настройкой неработающих процессов. Это не так. Ретроспектива или «взгляд назад» нужна для того, чтобы проанализировать все то, что произошло за время проведения итерации — две-три недели.
Даже если супер-scrum-команда покрыла все отобранные для разработки задачи, сделала все дополнительные срочные хотелки, выпустила bug-free инкремент и даже не вспотела — встретиться все равно нужно. Как минимум, чтобы понять, как это удалось и как потом повторить этот фокус.
Что идеальная команда может делать на ретро:
- Хвалить друг-друга. Публично воздавать должное товарищам — отличный шаг к укреплению командного духа.
- Обсуждать нерешенные вопросы с прошлой ретроспективы.
- Отказываться от нерабочих процессов и продумывать новые.
- Обсуждать новые технологии, которые хотелось бы внедрить в проект.
- Знакомиться с новыми практиками координации работ в проекте.
- Рассказывать друг другу о собственных инициативах, направленных на улучшение командной работы.
Ретро — легальный способ высказать все, что на душе, и не быть побитым за это. Шутка.
Мифы не сочиняют о банальных вещах
Эти и другие мифы о популярном фреймворке часто заставляют тех, кто еще не окунулся в мир гибких методологий, бояться имплементации Scrum у себя в команде, отказываться искать идеальную конфигурацию, сдаваться на волю обстоятельств, сказав: «Мы пробовали, это не работает».
Самые лучшие источники знаний о Scrum — это Scrum Guide, ваш собственный опыт, книги евангелистов фреймворка и знания тех, кто внедрял его не один раз. Поэтому не спешите сходить с дистанции: читайте, спрашивайте, проходите курсы и, самое главное, пробуйте!
P.S. А какие мифы о Scrum знаете вы? Пишите свои комментарии в нашем тематическом посте на facebook. Самые лучшие комментарии мы наградим бонусами и полезным контентом.