какие проблемы может решать хороший scrum мастер
Какие проблемы может решать хороший scrum мастер
Описать Скрам Мастера как коуча можно с трех разных сторон:
Скрам-мастеру важно понимать, что не все участники команды находятся на одном уровне, зачастую нужно применять индивидуальный подход и работать с каждым членом команды индивидуально.
Чем отличается коуч от ментора?
Понятия «коучинг» и «менторство» используются как синонимы. Безусловно, между ними много общего, но есть одно ключевое различие: чтобы провести коуч сессию, не обязательно быть экспертом в той или иной области, но если вы хотите чему-то научить, то экспертные знания просто необходимы. Лисса Адкинс в своей книге «Коучинг agile-команд» писала о том, что, если соединить коучинг и менторство в своей практике, то можно достичь гораздо большего в работе со своей командой.
Задачи:
С понятием препятствия разобрались, вот несколько примеров возможных препятствий:
Устранение препятствий очень важная тема, так как препятствия есть всегда, а вот как их разрешать не всегда понятно. Ниже вы найдете несколько техник, которыми мы пользуемся на ежедневной основе:
Кто эти люди? Зачем я им нужна? и другие проблемы скрам-мастера
Что чувствует скрам-мастер, который знает о скраме только из гайда? Как он пытается помочь команде не развалить и улучшить существующие процессы? Статья о трудностях, с которыми я столкнулась в начале своего пути самурая.
Команда, в которую я пришла как QA-инженер, была уже сформирована: стандартные процессы построены, атмосфера в коллективе — дружелюбная и спокойная. Через год моей работы встал вопрос о том, кто заменит скрам-мастера, который перешел в другую команду. Мне захотелось попробовать. Опыта в управлении и построении процессов не было, но почва для старта доброжелательная. Почему бы и нет?
Сложности
Через неделю эйфории (еее, новая ачивка!) на голову свалилась тысяча и одна проблема (мама, помоги!). Большая часть из них — личные, банальные или решаются прохождением пары тренингов. Я хочу поделиться четырьмя основными сложностями, с которыми может столкнуться начинающий скрам-мастер.
Отсутствие авторитета
Несмотря на то, что я работала в команде год, роль скрам-мастера была для меня новой. Для построения новых процессов авторитет — одна из важных составляющих. Когда пытаешься изменить привычные практики, основываясь только на теоретических знаниях, скептического отношения со стороны команды избежать сложно. Даже введение одной из самых распространенных практик — скрам-покера — было для меня проблематичным.
Тень бывшего мастера
От сравнений никуда не деться. Если до моего появления что-то работало плохо, и после моего прихода ничего не изменилось, возникали запросы: «У нас слишком сложный планнинг, давай сделаем уже что-нибудь с ним!». В случае, когда что-то было удобно для команды, например, физическая доска на дейли, а после появилась я и сказала: «Мне неудобно, давайте менять!», команда не понимала, зачем это необходимо.
Другая сложность связана с коммуникацией. Предыдущий скрам-мастер довольно остро воспринимал отзывы о своей работе, а мне было важно получать обратную связь. В итоге, первый полезный фидбек удалось собрать только через пару месяцев — помогли упорство и разговоры с глазу на глаз. На личных встречах некоторые ребята рассказали, что им было некомфортно критиковать мою работу: предыдущий опыт говорил о том, что задеть чувства скрам-мастера легко, и фидбек воспринимается как оскорбление.
Коммуникация с командой
Идеальный скрам-мастер наблюдает за настроением в команде, анализирует, как работают процессы, понимает, как команда реагирует на изменения. Как не перепутать безразличие к процессу со стороны команды с тем, что уже хорошо работает? Как собрать адекватный фидбек? Здесь мне явно не хватало практики. Особенно сильно эти вопросы беспокоили на ретроспективе, когда на общей встрече на обсуждение выносились незначительные проблемы или не выносились вовсе. Такое происходит, если команда хорошо провела спринт или если проблемы умалчиваются.
Синдром волонтера
В начале пути хочется выложиться на максимум, чтобы команда сразу осознала, какая я крутая и как много могу. Почему я должна делать меньше, если могу делать больше?
Способы решения
Универсального решения для всех трудностей быть не может. Ниже перечислю шаблоны поведения, которые мне когда-то помогли привыкнуть к новой роли.
Решать проблемы поэтапно
Роль скрам-мастера я совмещала с должностью QA-инженера и физически не могла позволить себе заниматься только улучшением процессов в команде. Я пыталась найти баланс и, как следствие, избежала серьезных проблем от изменения всего и вся в команде. Поэтапное решение помогало не только не закопаться в изменениях ради изменений, но и отслеживать, как какое-то конкретное нововведение повлияло на проблему, которая решалась изначально.
Я хотела изменить несколько вещей в работе команды. Одной из них была физическая доска для дейли. Мне было лень заниматься её оформлением из спринта в спринт. Ситуация усложнялась тем, что эта проблема не затрагивала всю команду. Другая проблема с доской — это реактивное обновление статусов задач. Так как команда находилась в одном кабинете, узнать прогресс по задаче было достаточно легко — спросить коллегу или посмотреть на доску. Трудности в тот момент это не вызывало, но могло поломать процессы в случае продолжительной удаленной работы кого-нибудь из коллег или появления удаленного сотрудника.
Решением первой проблемы было делегирование оформления доски или переход на какой-нибудь электронный инструмент. Второй — развитие культуры поддержания порядка. Кстати, аргумент «когда-нибудь нам это, может быть, поможет» недостаточно мотивирует команду на изменения.
Аргументировать любое изменение
Не нужно бросаться с места в карьер с криком: «Сейчас всё будет!». В самом начале пути скрам-мастерства есть вероятность наворотить процессы ради процессов, это может ухудшить карму. Сначала стоит понять, зачем, а потом транслировать идею команде.
В ситуации с отказом от физической доски, я проговорила команде, что мне сложно заниматься оформлением, а если альтернативного варианта для доски не найдется, то я попрошу команду разделить со мной обязанности по разрезанию и развешиванию стикеров.
Изучить поведение авторитета
Видите, что кто-то в команде удачно рассказывает о своих идеях? К мнению лидера прислушиваются? Можно понаблюдать за тем, как этот человек доносит информацию, скорее всего, он с командой на одной волне. Важно так же настроиться на эту волну.
Душой нашей команды был менеджер продукта. Важность и необходимость фичей, над которыми он предлагал работать, команда разделяла. И дело не только в том, что это были очевидно необходимые и важные изменения. Менеджер аргументировал предложение, освещал плюсы, вносил ясность — это помогало осознать и принять новую задачу.
Найти единомышленников
Одна голова хорошо, а имей сто друзей. Коллективный разум — это прекрасно, но не все вопросы можно выносить на командное обсуждение. Можете найти одного/двух неравнодушных коллег и советоваться с ними. Но разные члены команды обладают навыками в разных аспектах работы, поэтому лучше не держать фокус на паре советников. Расширяйте круг общения.
За новыми идеями по части процессов я обращалась к менеджеру продукта. Острые углы и проблемы мне помог найти инженер по тестированию. На выходе получалось приятное и провалидированное решение.
Необходимый для скрам-мастера опыт помогут получить книги, тренинги и практика. Но количество советов зашкаливает, и трудности вызывает даже приоритезация советов в порядке необходимости. Осознание сложностей — шаг в правильном направлении к поддержанию и построению процессов.
А что дальше?
Теперь, когда хаос упорядочен, можно подумать о работе над конкретными навыками и задачами.
Разбор полётов. Уроки и выводы начинающего Scrum-мастера
Источник фото
Уже третий год я внедряю ценности и принципы Agile в жизни команд разработчиков. За плечами – работа Scrum-мастером в двух крупных компаниях, опыт удаленного внедрения гибких методологий в совершенно разных отраслях, бесчисленное количество прочитанных книг и посещенных митапов.
Но начиналось всё с малого, и за это время я набила не одну шишку. А со временем стала замечать, что шишки эти были довольно типовыми, и коллеги-новички сталкиваются с ними на регулярной основе. Не желая оставаться в стороне, и дабы предостеречь коллег от возможных неудач, решила поделиться своим опытом в этой статье.
Итак, какие уроки я извлекла и выводы сделала в первый год работы в роли Scrum-мастера (о которых кратко пунктами изложила в самом конце):
Розовые очки
После двухдневного тренинга по Scrum я была готова сворачивать горы, изменять мир на пути компании к лучшему. Ничто так не вдохновляет, как грамотный коуч и команда единомышленников! Но стоит только начать, как вдруг ты остаёшься один на один со своим фреймворком Scrum. Есть ребята, загруженные собственными задачами, есть привычки и ценности, которые уже сложились в работе команды, есть менеджмент, который по-своему видит процессы, и это не всегда идёт параллельно с ценностями и представлениями Agile. В общем, добро пожаловать в реальный мир.
А потому еще в начале предстоит заслужить доверие и открытость команды. Важно опираться на свой предыдущий опыт и здравый смысл. Поймите, в чём действительно сейчас нуждается ваша команда, какие проблемы и недосказанности существуют и как вы можете им помочь, чтобы закрыть хотя бы часть возникающих вопросов.
Сопротивление
Безусловно, нововведениям и очевидным грядущим изменениям не очень обрадовались. В моем случае скорее это было смирение с тем, что пришёл ещё кто-то, чтобы управлять и учить: «ну ведь и так всё хорошо». Делать нечего – пришлось доказывать, что я пришла помогать, и на практике это демонстрировать.
Важный момент: если в самом начале вы не найдёте в команде разработчиков сторонников, рискуете быть отвергнутыми.
Первое, с чем сталкивается новоиспечённый Scrum-мастер при попытке изменения, – это сопротивление. Процесс, конечно, естественный, но не безболезненный. Люди готовы меняться только тогда, когда видят в этом ценность для себя. Поэтому самый выигрышный вариант – дать возможность команде самой прийти к мысли, что Scrum улучшит и их процессы, и жизнь.
Задайте себе вопрос: «какова цель моего присутствия в этой роли и как я могу помочь своей команде улучшить существующие процессы работы?». Если ответ нашёлся – отлично, вперёд к изменениям! Если нет, то стоит понаблюдать ещё.
Говоря об улучшении – можно провести серию встреч, направленных на выявление болей команды и формирование открытости, к примеру. Но об этом я хочу поговорить в следующих статьях.
Спешка – худший помощник
Спешка и желание показать себя с первых дней работы – наверное, самая большая ошибка начинающего Scrum-мастера. Жизненно важно знать, что резкие изменения без понимания, зачем это нужно и как повлияет на сложившийся уклад жизни команды, может вызвать ещё большее сопротивление и недоверие. Бывали случаи, когда Scrum-мастер вредил командам именно вследствие непродуманных и непроработанных изменений.
Готовность к изменениям наступает у команды постепенно. Понаблюдайте за командой в течение 1-2 недель, не вмешиваясь в «естественный» ход вещей. На первых этапах необходимо понять для себя логическую цепочку процессов и сложившихся ценностей, увидеть уязвимые места в работе и, собственно, предложить решение. Шаг за шагом пытайтесь внедрять события и ценности методологии в сознание и жизнедеятельность своей команды.
В этом вам поможет фасилитация встреч, частое взаимодействие с командой, как личное, так и в формате событий, коучинг. И, конечно, доверие и открытость к диалогу.
Понимание среды
Когда я лишь начинала работу с командой, допустила большую оплошность, которая поначалу не бросалась в глаза и казалась пустяком. А именно – упускала из виду множество тематических чатов разработчиков, которые раскрывали их с другой стороны. Дистанцировалась от руководства и пропускала важную информацию, которую можно было бы, в свою очередь, донести до команды.
Не повторяйте мою ошибку: не важно, маленькая у вас компания или большая, но понимать коммуникацию между отделами и знать лично пару ключевых коллег нужно. Говорят, что Scrum-мастер должен устранять препятствия, отвлекающие команду от создания ИТ-продукта. Но как это сделать, если вы не будете знать, к кому обратиться?
Итак, в самом начале особенно важно:
Присутствие стратегии
И вот мы поговорили с командой и руководством, задали интересующие вопросы, получили на них ответы, зашли во все чаты и получили приглашения на все мероприятия. Мы видим проблему, знаем цели менеджмента – но с чего начать, чтобы её решить, пока не понятно. Что делать дальше?
Для того, чтобы прийти к решению, важно сформулировать чёткие цели того, что именно и почему мы хотим изменить. А после – составить план работ, отвечающий на вопрос, «как мы это будем делать?».
Чаще всего, приходя в команду, я видела, как ребята проводят ежедневные совещания по 1,5-2 часа, на которых пытаются проработать все вопросы. А это, между прочим, – колоссальное количество времени, которое вычитается из рабочих часов и снижает эффективность работ команд. Да и Scrum Guide предполагает на это событие только 15 минут и ни минутой больше.
Как быть: самым правильным подходом, на мой взгляд, является разделение таких активностей и фокусировка на поставленных задачах в рамках целей Sprint.
Отталкиваясь от болей и наиболее частых вопросов, помимо основных событий Scrum (планирование, daily, demo, retro) может формироваться, например, еженедельная исследовательская встреча, обсуждение бэклога идей или же мозговые штурмы для обсуждения углубленных вопросов, как происходит сегодня у нас в ICL Services. Мы видим боль, знаем, как исправить ситуацию и что нужно сделать – остаётся лишь обсудить изменение формата работ с менеджментом и командой для достижения наилучшего эффекта.
План тоже должен быть гибким и изменяться в зависимости от условий и особенностей членов команды. Немаловажно обсудить намеченный путь с руководством, ведь не всегда всё предложенное вами будет немедленно внедрено в работу. А что-то и вовсе может видоизмениться в зависимости от целеполагания и запросов самого руководства.
Нехватка технических знаний
Технического образования у меня нет, а потому досконально разобраться в обширной терминологии команды разработчиков для меня было (и местами остаётся) довольно сложной задачей, учитывая, что технологии не стоят на месте.
Но и здесь есть довольно простые лайфхаки:
Agile и Scrum на практике: вопросы скрам-мастеру
К чему готовиться, когда приходишь в команду, где применяют Agile. Кому нужен Scrum, в чем его сила и когда он мешает.
Слова Agile и Scrum прочно вошли в жизнь разработчиков за рубежом и в России. Мнения о гибких правилах разработки в профессиональном сообществе расходятся. Сегодня мы обсудим эту тему с человеком, который работает по принципам Agile уже более 10 лет и успел получить опыт проведения скрамов в российской и международной компаниях. Мой собеседник — Владимир Морозов — преподаватель факультета Android-разработки в GU, он нам расскажет про функции Scrum мастера и какую роль он играет в команде.
— Владимир, какие курсы вы сейчас ведете в GeekUniversity и GeekBrains?
— Веду курс командной разработки Android-приложения и учебный блок, посвященный подготовке к интервью. Иногда еще читаю лекции для project-менеджеров.
— В каких компаниях и командах вы занимались разработкой и практиковали Agile и Scrum?
— Я не любитель часто менять работу: в 2007 году пришел в компанию, которая разрабатывала ПО для ритейловых сетей. В этой компании мало кто знал про Agile, и когда команда столкнулась с проблемами, мы стали анализировать ситуацию и искать решение. В итоге пришли к необходимости использовать Scrum. Сейчас работаю в DXC Technology — тоже по скраму.
Уточню, что Scrum — это не методология и не технология, а фреймворк, как утверждают авторы скрам-гайда Ken Schwaber и Jeff Sutherland. На русский язык тяжело перевести, что такое фреймворк, поэтому говорят «методология». На самом деле это контейнер с правилами, который каждая компания и команда заполняет своими процессами. Я бы сказал, что скрам — это набор правил и рекомендаций.
Если мы рассматриваем скрам как контейнер, у разных команд он будет выглядеть по-разному. Когда команда работает по скраму, она постоянно ищет и пробует новые решения, обновляет процессы, отбрасывает ненужное, развивается.
Разработка программного обеспечения — штука сложная: тяжело прогнозировать сроки выполнения задач, синхронизировать задачи между разработчиками, расставлять приоритеты. Скрам помогает решать эти проблемы и организовывать работу так, чтобы ваша команда развивалась непрерывно.
— В чем ключевые особенности взаимодействия в командах, применяющих Agile?
— Появляется чувство локтя, повышается ответственность у участников команды, возникает самомотивация, когда разработчик заинтересован завершить задачу. Наверное, это.
Конечно, если в команде появляется токсичный человек, это проблема, которую надо решать. Если человек понимает, почему мы работаем именно так, надо попытаться заразить его скрамом. Если же он продолжает гнуть свою линию, его стоит исключить из команды. Это одна из функций scrum-мастера. К любому человеку нужен индивидуальный подход, и рецептов тут быть не может.
— Чем еще занимается скрам-мастер?
— Устраняет препятствия, мешающие нормальной работе команды. Сюда входит отслеживание процессов по скраму, обучение сотрудников этому фреймворку, обнаружение проблем и отправка их руководству, если их не решить своими силами.
— Чем на практике отличается применение методологии Agile в разных компаниях (российских и зарубежных) и командах? Какие факторы влияют на эти различия?
— Главное отличие в том, что владелец продукта — тот, кто ставит задачи — в российских компаниях находится рядом, а в зарубежных, как правило, в другой стране — ближе к клиентам, с которыми плотно работает. Это накладывает отпечаток на общение. Во-первых, надо знать иностранный язык хотя бы в бизнес-рамках. Во-вторых, вы общаетесь не вживую, а по Skype и другим подобным каналам.
— По вашему опыту, когда Scrum работает лучше всего и какие у него противопоказания?
— Скрам отлично работает, когда сотрудники самомотивированы, ответственны. А еще, когда не до конца понятно, что делать, и вы постоянно ищете, как улучшить процессы разработки ПО.
Если же все предельно ясно и есть четкое ТЗ, да если это еще и госзаказ, скрам не подходит. В разношерстной команде, где каждый — специалист в своей области, скрам мастер тоже не очень актуален, хотя его функции можно использовать.
— Когда в феврале этого года в блоге вышла небольшая статья про Agile, у одного читателя возник вопрос: есть ли в Scrum место «причесыванию кода» — рефакторингу и «выпиливанию костылей»? Или в погоне за новыми запросами пользователя трудно найти на это время?
— Интересно, что в твиттере недавно появилось на эту тему сообщение от автора принципов SOLID, Роберта Мартина, или Дядюшки Боба, как зовут его в сообществе. Он посоветовал при оценке задачи закладывать в нее рефакторинг и написание тестов. Считаю этот совет очень разумным и полезным.
Еще желательно придерживаться правила бойскаутов: код после вас должен стать лучше, чем был. Зашли в метод, внесли новшество, заметили какую-то проблему — устранили. Если код не вычищать, со временем он превратится в такое спагетти, что добавление функциональности будет занимать слишком много времени.
— У себя в профиле вы указали, что в программировании, помимо прочего, вам важна тестируемость кода. Что вы под этим подразумеваете?
— К сожалению, начинающие разработчики, да и не только они, часто пренебрегают написанием автотестов. Как проверить код? Только тестированием. Это можно сделать вручную либо написать автотест — кусок кода для проверки другого кода.
Да, на этапе разработки мы потратим время, но зато исключим человеческий фактор в будущем, ведь автотест не уйдет на больничный или в отпуск, не уволится. Мы освободим сотрудников от рутинной работы по ручному тестированию. Сейчас в мире тенденция: меньше ручного тестирования — больше автотестов.
— И еще один вопрос от читателей: «Agile — это модно, молодежно, но можно пример успешного Agile-проекта в топовых компаниях? Скорее всего, даже если вы найдете ссылку, это будет классический подход с элементами Agile. В отличие от чистого аджайла, там будет документация и заранее заданная архитектура». От себя добавлю: разве наличие документации и заданной архитектуры нарушает принципы Agile?
— Работаю по Scrum в компании DXC Technology. Почитайте, чем она занимается. Не уверен, что это компания топовая, но международная — точно.
Как связана архитектура с Agile? Я не понимаю. Это как сравнивать зеленое с круглым.
Если в ранних версиях руководства по скраму говорилось, что работающий код лучше документации, это не значит, что документация не нужна. В последней редакции гайда таких фраз уже нет. Разработка документации ведется в рамках отдельных задач и/или Definition of done, то есть определения законченности задачи.
— Есть ли в Agile механизм защиты продукта от перегрузки лишними функциями из-из «хотелок» пользователей? Или это за рамками подхода?
— За рамками. За этим следит владелец продукта: он ведет backlog (список задач) и расставляет приоритеты. Любая «хотелка» должна быть проанализирована.
— В каких ситуациях уместно так называемое экстремальное программирование (XP)? Был ли у вас такой опыт?
— Мы работаем по этим методикам. Фактически Scrum — часть экстремального программирования. Добавим сюда парное программирование, непрерывную интеграцию и разработку через тестирование — получим XP.
Если заказчик недоступен, в скраме его замещает владелец продукта. Мне кажется, чем больше элементов экстремального программирования вы применяете, тем качественнее продукт. XP — это работа без стрессов, а не наоборот. 🙂
К примеру, подход test-first означает, что сначала мы пишем тест, он падает, затем пишем код под этот тест, и тест в результате «зеленый», то есть показывает, что код написан верно. Теперь мы точно знаем, что тест работает с новым кодом, сам код не содержит дефектов — следовательно, нет багов у пользователя и он не треплет нам нервы.
Парное программирование улучшает качество кода и способствует повышению профессионализма команды. Код автоматически получает ревью, а разработчики делятся друг с другом знаниями. Качественный код — значит, меньше багов и проще добавлять новую функциональность в будущем.
Еще один принцип XP — частые итерации и общение с клиентами. Это нам дает скрам. У нас нет строгой точки релиза, когда перед поставкой продукта все разработчики трудятся в мыле днем и ночью. Поставка может быть итогом каждого спринта. А непрерывная интеграция обеспечивает работоспособность проекта постоянно.
— Как выглядит спринт в команде Android-разработчиков? Что чаще всего идет не так и что при этом может сделать мастер?
— В данном случае не важно, идет ли речь об Android- или веб-разработке, о десктопных приложениях или сервисах. Проблемы бывают общими или командными. Общие проблемы — это неправильное прогнозирование задач (времени их выполнения), неверная расстановка приоритетов, отсутствие или неясность цели на спринт.
В каждой команде — свои проблемы. Это может быть внутренняя коммуникация, назойливое руководство или еще что-то. С подобными препятствиями помогает бороться скрам-мастер. К слову, сейчас наша команда работает на Java, C#, Golang, Python и Angular (TypeScript).
— Читала, что в веб-разработке в распределенных командах американцы чаще берут на себя фронтенд, а россияне сосредотачиваются на бэкенде. В Android-разработке подобного не прослеживается?
— Что касается веба, — да. Фронтенд — часть, которую видит пользователь, а значит, американский разработчик лучше напишет и оформит текст для американской аудитории, поскольку и языком владеет на уровне носителя, и клиента знает.
У меня не настолько большой опыт работы с зарубежными Android-разработчиками, чтобы говорить о подобных нюансах. Но сейчас наша команда пишет микросервисы на C# — это тоже можно считать бэкендом 🙂
— Насколько понимаю, Аgile ориентирован на опытных специалистов, которые умеют брать на себя ответственность. Когда в команду приходит Junior, которого предстоит многому научить, он еще не полностью вовлечен в проект. Что, кроме собственного желания сотрудника, влияет на скорость вовлечения? Как этому способствует скрам?
— Обучать таких людей — одна из обязанностей scrum-мастера. Чтобы скорее вовлечься, нужно просто начать работать в команде.
— Насколько обременительно быть скрам-мастером: какую часть рабочего времени приходится выделять на организационные моменты? Насколько это сочетается с другими задачами ведущего разработчика?
— Наверное, у всех по-разному. Мне вообще нравится помогать людям, а работа скрам-мастера в этом и заключается. Что-то кому-то объяснить, с кем-то поработать в паре, подсказать. Конечно, ведущий разработчик, или сеньор, как правило, занят написанием каких-то базовых вещей, основ архитектуры, а мидлы и юниоры уже навешивают на эту архитектуру рюшечки. Когда джуниорам что-то непонятно, они иногда отвлекают от работы.
Наша команда создана недавно, и в ней уже подобрались сеньоры, но все равно разработчики и автотестеровщики из других команд приходят за советом, а иногда даже просят посмотреть code review. Однако эта работа никак не связана с задачами скрам-мастера.
Если у вас одна команда, обязанности и функции скрам-мастера не слишком обременительны, но если вы выступаете в этой роли в нескольких командах, то ни на что другое времени не останется.
— Спасибо за ответы! Интересно было узнать мнение человека, который не первый год в теме Agile и знает изнутри, как работает Scrum.
К чему готовиться, когда приходишь в команду, где применяют Agile. Кому нужен Scrum, в чем его сила и когда он мешает.
Слова Agile и Scrum прочно вошли в жизнь разработчиков за рубежом и в России. Мнения о гибких правилах разработки в профессиональном сообществе расходятся. Сегодня мы обсудим эту тему с человеком, который работает по принципам Agile уже более 10 лет и успел получить опыт проведения скрамов в российской и международной компаниях. Мой собеседник — Владимир Морозов — преподаватель факультета Android-разработки в GU, он нам расскажет про функции Scrum мастера и какую роль он играет в команде.
— Владимир, какие курсы вы сейчас ведете в GeekUniversity и GeekBrains?
— Веду курс командной разработки Android-приложения и учебный блок, посвященный подготовке к интервью. Иногда еще читаю лекции для project-менеджеров.
— В каких компаниях и командах вы занимались разработкой и практиковали Agile и Scrum?
— Я не любитель часто менять работу: в 2007 году пришел в компанию, которая разрабатывала ПО для ритейловых сетей. В этой компании мало кто знал про Agile, и когда команда столкнулась с проблемами, мы стали анализировать ситуацию и искать решение. В итоге пришли к необходимости использовать Scrum. Сейчас работаю в DXC Technology — тоже по скраму.
Уточню, что Scrum — это не методология и не технология, а фреймворк, как утверждают авторы скрам-гайда Ken Schwaber и Jeff Sutherland. На русский язык тяжело перевести, что такое фреймворк, поэтому говорят «методология». На самом деле это контейнер с правилами, который каждая компания и команда заполняет своими процессами. Я бы сказал, что скрам — это набор правил и рекомендаций.
Если мы рассматриваем скрам как контейнер, у разных команд он будет выглядеть по-разному. Когда команда работает по скраму, она постоянно ищет и пробует новые решения, обновляет процессы, отбрасывает ненужное, развивается.
Разработка программного обеспечения — штука сложная: тяжело прогнозировать сроки выполнения задач, синхронизировать задачи между разработчиками, расставлять приоритеты. Скрам помогает решать эти проблемы и организовывать работу так, чтобы ваша команда развивалась непрерывно.
— В чем ключевые особенности взаимодействия в командах, применяющих Agile?
— Появляется чувство локтя, повышается ответственность у участников команды, возникает самомотивация, когда разработчик заинтересован завершить задачу. Наверное, это.
Конечно, если в команде появляется токсичный человек, это проблема, которую надо решать. Если человек понимает, почему мы работаем именно так, надо попытаться заразить его скрамом. Если же он продолжает гнуть свою линию, его стоит исключить из команды. Это одна из функций scrum-мастера. К любому человеку нужен индивидуальный подход, и рецептов тут быть не может.
— Чем еще занимается скрам-мастер?
— Устраняет препятствия, мешающие нормальной работе команды. Сюда входит отслеживание процессов по скраму, обучение сотрудников этому фреймворку, обнаружение проблем и отправка их руководству, если их не решить своими силами.
— Чем на практике отличается применение методологии Agile в разных компаниях (российских и зарубежных) и командах? Какие факторы влияют на эти различия?
— Главное отличие в том, что владелец продукта — тот, кто ставит задачи — в российских компаниях находится рядом, а в зарубежных, как правило, в другой стране — ближе к клиентам, с которыми плотно работает. Это накладывает отпечаток на общение. Во-первых, надо знать иностранный язык хотя бы в бизнес-рамках. Во-вторых, вы общаетесь не вживую, а по Skype и другим подобным каналам.
— По вашему опыту, когда Scrum работает лучше всего и какие у него противопоказания?
— Скрам отлично работает, когда сотрудники самомотивированы, ответственны. А еще, когда не до конца понятно, что делать, и вы постоянно ищете, как улучшить процессы разработки ПО.
Если же все предельно ясно и есть четкое ТЗ, да если это еще и госзаказ, скрам не подходит. В разношерстной команде, где каждый — специалист в своей области, скрам мастер тоже не очень актуален, хотя его функции можно использовать.
— Когда в феврале этого года в блоге вышла небольшая статья про Agile, у одного читателя возник вопрос: есть ли в Scrum место «причесыванию кода» — рефакторингу и «выпиливанию костылей»? Или в погоне за новыми запросами пользователя трудно найти на это время?
— Интересно, что в твиттере недавно появилось на эту тему сообщение от автора принципов SOLID, Роберта Мартина, или Дядюшки Боба, как зовут его в сообществе. Он посоветовал при оценке задачи закладывать в нее рефакторинг и написание тестов. Считаю этот совет очень разумным и полезным.
Еще желательно придерживаться правила бойскаутов: код после вас должен стать лучше, чем был. Зашли в метод, внесли новшество, заметили какую-то проблему — устранили. Если код не вычищать, со временем он превратится в такое спагетти, что добавление функциональности будет занимать слишком много времени.
— У себя в профиле вы указали, что в программировании, помимо прочего, вам важна тестируемость кода. Что вы под этим подразумеваете?
— К сожалению, начинающие разработчики, да и не только они, часто пренебрегают написанием автотестов. Как проверить код? Только тестированием. Это можно сделать вручную либо написать автотест — кусок кода для проверки другого кода.
Да, на этапе разработки мы потратим время, но зато исключим человеческий фактор в будущем, ведь автотест не уйдет на больничный или в отпуск, не уволится. Мы освободим сотрудников от рутинной работы по ручному тестированию. Сейчас в мире тенденция: меньше ручного тестирования — больше автотестов.
— И еще один вопрос от читателей: «Agile — это модно, молодежно, но можно пример успешного Agile-проекта в топовых компаниях? Скорее всего, даже если вы найдете ссылку, это будет классический подход с элементами Agile. В отличие от чистого аджайла, там будет документация и заранее заданная архитектура». От себя добавлю: разве наличие документации и заданной архитектуры нарушает принципы Agile?
— Работаю по Scrum в компании DXC Technology. Почитайте, чем она занимается. Не уверен, что это компания топовая, но международная — точно.
Как связана архитектура с Agile? Я не понимаю. Это как сравнивать зеленое с круглым.
Если в ранних версиях руководства по скраму говорилось, что работающий код лучше документации, это не значит, что документация не нужна. В последней редакции гайда таких фраз уже нет. Разработка документации ведется в рамках отдельных задач и/или Definition of done, то есть определения законченности задачи.
— Есть ли в Agile механизм защиты продукта от перегрузки лишними функциями из-из «хотелок» пользователей? Или это за рамками подхода?
— За рамками. За этим следит владелец продукта: он ведет backlog (список задач) и расставляет приоритеты. Любая «хотелка» должна быть проанализирована.
— В каких ситуациях уместно так называемое экстремальное программирование (XP)? Был ли у вас такой опыт?
— Мы работаем по этим методикам. Фактически Scrum — часть экстремального программирования. Добавим сюда парное программирование, непрерывную интеграцию и разработку через тестирование — получим XP.
Если заказчик недоступен, в скраме его замещает владелец продукта. Мне кажется, чем больше элементов экстремального программирования вы применяете, тем качественнее продукт. XP — это работа без стрессов, а не наоборот. 🙂
К примеру, подход test-first означает, что сначала мы пишем тест, он падает, затем пишем код под этот тест, и тест в результате «зеленый», то есть показывает, что код написан верно. Теперь мы точно знаем, что тест работает с новым кодом, сам код не содержит дефектов — следовательно, нет багов у пользователя и он не треплет нам нервы.
Парное программирование улучшает качество кода и способствует повышению профессионализма команды. Код автоматически получает ревью, а разработчики делятся друг с другом знаниями. Качественный код — значит, меньше багов и проще добавлять новую функциональность в будущем.
Еще один принцип XP — частые итерации и общение с клиентами. Это нам дает скрам. У нас нет строгой точки релиза, когда перед поставкой продукта все разработчики трудятся в мыле днем и ночью. Поставка может быть итогом каждого спринта. А непрерывная интеграция обеспечивает работоспособность проекта постоянно.
— Как выглядит спринт в команде Android-разработчиков? Что чаще всего идет не так и что при этом может сделать мастер?
— В данном случае не важно, идет ли речь об Android- или веб-разработке, о десктопных приложениях или сервисах. Проблемы бывают общими или командными. Общие проблемы — это неправильное прогнозирование задач (времени их выполнения), неверная расстановка приоритетов, отсутствие или неясность цели на спринт.
В каждой команде — свои проблемы. Это может быть внутренняя коммуникация, назойливое руководство или еще что-то. С подобными препятствиями помогает бороться скрам-мастер. К слову, сейчас наша команда работает на Java, C#, Golang, Python и Angular (TypeScript).
— Читала, что в веб-разработке в распределенных командах американцы чаще берут на себя фронтенд, а россияне сосредотачиваются на бэкенде. В Android-разработке подобного не прослеживается?
— Что касается веба, — да. Фронтенд — часть, которую видит пользователь, а значит, американский разработчик лучше напишет и оформит текст для американской аудитории, поскольку и языком владеет на уровне носителя, и клиента знает.
У меня не настолько большой опыт работы с зарубежными Android-разработчиками, чтобы говорить о подобных нюансах. Но сейчас наша команда пишет микросервисы на C# — это тоже можно считать бэкендом 🙂
— Насколько понимаю, Аgile ориентирован на опытных специалистов, которые умеют брать на себя ответственность. Когда в команду приходит Junior, которого предстоит многому научить, он еще не полностью вовлечен в проект. Что, кроме собственного желания сотрудника, влияет на скорость вовлечения? Как этому способствует скрам?
— Обучать таких людей — одна из обязанностей scrum-мастера. Чтобы скорее вовлечься, нужно просто начать работать в команде.
— Насколько обременительно быть скрам-мастером: какую часть рабочего времени приходится выделять на организационные моменты? Насколько это сочетается с другими задачами ведущего разработчика?
— Наверное, у всех по-разному. Мне вообще нравится помогать людям, а работа скрам-мастера в этом и заключается. Что-то кому-то объяснить, с кем-то поработать в паре, подсказать. Конечно, ведущий разработчик, или сеньор, как правило, занят написанием каких-то базовых вещей, основ архитектуры, а мидлы и юниоры уже навешивают на эту архитектуру рюшечки. Когда джуниорам что-то непонятно, они иногда отвлекают от работы.
Наша команда создана недавно, и в ней уже подобрались сеньоры, но все равно разработчики и автотестеровщики из других команд приходят за советом, а иногда даже просят посмотреть code review. Однако эта работа никак не связана с задачами скрам-мастера.
Если у вас одна команда, обязанности и функции скрам-мастера не слишком обременительны, но если вы выступаете в этой роли в нескольких командах, то ни на что другое времени не останется.
— Спасибо за ответы! Интересно было узнать мнение человека, который не первый год в теме Agile и знает изнутри, как работает Scrum.