Следование Agile-методологиям стало эдакой частью джентельменского набора любой IT компании. Большинство команд работают на основе одного из фреймворков этой методологии, чаще всего по Scrum’у. И это уже общепринятая практика. Проблема в том, что в большинстве случаев применение Scrum’а — внешняя атрибутика и не более.
Давайте разбираться.
Как чаще всего выглядит скраминг?
Каждый день проводим стендапы, в начале спринта делаем планинг и эстимируем задачи, в конце — ретроспектива. Вот только для чего нужны ежедневные стендапы никто не понимает, трудоёмкость скоупа задач на спринт в несколько раз превышает доступное время у команды. А все action item’ы с ректроспектив плавно перетекают из одного спринта в другой, как, впрочем, и задачи.
В итоге, вроде бы, всё делаем правильно, но разработку это никак не ускоряет и не облегчает. Почему так происходит?
Как правило, Scrum внедряют без понимания принципов его работы. В какой-то книге или докладе говорилось, что это очень круто и must have у всех современных компаний. Значит, надо срочно начинать скрамить! В результате, все атрибуты присутствуют, но ничего не меняется. Или меняется, но в худшую сторону.
Что же тогда делать?
Обращаемся к первому принципу Agile: «Люди и взаимодействие важнее процессов и инструментов.» Данная методология в первую очередь про людей и про коммуникации между ними. И начинать тоже надо с них.
Необходимо объяснить, для чего это нужно и какие преимущества даёт. Что стендапы — это не собраться и 15 минут убить впустую. Каждый член команды будет понимать, чем заняты его коллеги и какие у них проблемы. Работа становится более прозрачной. Это позволяет раньше выявлять проблемные моменты и решать их за счёт помощи участников команды друг другу.
Спринты должны стать итерацией сроком от 1 до 4 недель. Причём для этой итерации заранее нужно составить список задач для выполнения, который после начала спринта уже не будет меняться. И объём работ по этим задачам не должен превышать возможности команды. Иначе задачи начнут растягиваться на несколько спринтов и планирование и формирование скоупа потеряет всякий смысл.
По результатам спринта подводим итоги. Что удалось сделать? Что не получилось? Что в следующем спринте можно улучшить? Для каждого пункта улучшений назначить ответственное лицо и сроки выполнения. Но опять же, на это нужно заложить время, чтобы у человека была возможность выполнить назначенный на него action item.
Далее начинается следующая итерация, для которой также делается оценка задач и планируется объём работ. Есть разные подходы к оценкам: часы, story-points и т.д. Для начала вполне можно обойтись оценкой в часах. Кстати, многие компании допускают ошибку, когда отдельно не прописывают в задаче время на разработку и время на тестирование. Ведь задача может занять один час у разработчика и 8 часов у тестера. Если всё это слепить в одно значение, будет трудно спланировать загруженность команды.
И таким образом необходимо повторять одну итерацию за другой, с каждым разом докручивая этот механизм на основе обратной связи от команды и результатов спринта. Через некоторое время получится выстроить хорошо отлаженные процессы, которые будут ОБЛЕГЧАТЬ разработку, а не создавать набор никому непонятных ритуалов.
Но, разумеется, никаких улучшений не произойдёт, если:
- Каждый член команды не будет понимать, какая у него роль на проекте и в чём суть всех Scrum-активностей.
- Не будет уделяться достаточно внимания адекватной и реальной оценке трудоёмкости задач.
- Участники команды не будут брать на себя ответственность за выполнение своих задач и достижение целей спринта.
Очевидно, что большая часть описанных выше рекомендаций очень просто звучит в теории и оказывается совсем непростой, когда их внедряют на практике. Отчасти это происходит, потому что многие внедряют Scrum насильно, не объяснив, для чего это делается. Но даже в случае, когда команде всё объяснили и обо всём договорились, можно столкнуться с сопротивлением. По началу даже производительность может снизиться. Однако через несколько спринтов все участники такого эксперимента поймут, сколько же плюсов несёт в себе новый подход.
Менеджерам станет понятно, чем в конкретный момент времени занята команда разработки. Если происходят какие-либо простои, то из-за чего это случается и какие вероятные пути решения. Разработчикам 100% понравится, что у них есть заранее определённый план работ, который не изменяется на протяжении спринта. Им больше не могут докидывать супер срочные задачи, ради которых нужно всё бросить и переключиться на них. А в тот момент, когда люди увидят, что их предложения с ретроспектив реально внедряются и процессы меняются с учётом интересов команды, последние сомнения должны отпасть.
Как показывает практика, большинство компаний очень неохотно переходит, например, с работы по водопадной методологии на гибкую. Однако сотрудники тех компаний, где был успешно внедрён Agile, уже ни в какую не соглашаются возвращаться к старым подходам.
Несомненно, применение Scrum’а может быть не самой лёгкой задачей, однако все усилия обязательно окупятся в будущем.
Автор статьи — Артемий Баумгартен, Full Stack разработчик. Артём занимается разработкой приложений для бизнеса при помощи Ruby On Rails и React/Vue. Главная цель в работе — сделать продукт, который будет эфективно решать необходимые бизнес-задачи.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
