К чему готовиться, когда приходишь в команду, где применяют 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.