Про Agile и его практики на просторах интернета написано огромное количество информации. Разные люди трактуют и применяют Agile по-разному, на то оно и гибкое явление. Для многих идея Agile превратилась в некий ритуал над проектами, где зачитывают манифест, делятся на команды по 3-9 человек, клеят карточки на доске, ведут бэклог, каждый день рассказывают историю о том, что делали вчера... Но качественных проектов от этого не становится больше. Ведь все это бесполезно, если у команды нет понимания сути и желания использовать Agile-подходы в работе.
Кратко об Agile
Agile — гибкий подход к управлению проектом, ориентированный на создание максимальной ценности для потребителя, как можно быстрее и чаще. Agile — свод принципов и ценностей, которые отвечают на вопрос: «Как быть?» или «Как поступать?» в той или иной ситуации. Принципы и идеи собраны в Agile-манифесте.
Прежде чем браться за практику, необходимо чтобы все члены команды, начиная с руководителя, принимали Agile и были готовы следовать его принципам. В противном случае инициатива будет бесполезной.
Для реализации ценностей и принципов Agile существует множество практик, каждая из которых адресована для решения конкретной проблемы, возникающей в процессе реализации проекта. К таким практикам относится, например, ретроспектива, покер-планирования, спринты, митинги, демо, WIP (ограничение задач в работе), критерий готовности (DoD), диаграмма сгорания задач и множество других.
Определенный набор практик называют фреймворками или основами, в рамках которых используются различные процессы и методы. К таковым относятся, например, Экстремальное программирование (XP), Scrum, Kanban.
В XP (экстремальном программировании) используются практики, которые помогают сводить к минимуму затраты на разработку, максимально точно прогнозировать результат, быстро реагировать на изменения требований клиентов, общаться и обучаться разработчикам без отрыва от производства.
Среди них:
- парное программирование (один разработчик кодирует, а другой следом проверяет, через какое-то время они меняются местами. Так увеличивается качество кода и ускоряется обмен знаниями),
- тестирование до разработки (сначала пишется тест, покрывающий желаемое изменение, затем код),
- смена позиций (участники все время перемещаются на новые участки работы, чтобы избежать изоляции знаний и добиваться, таким образом, обмена идеями между разработчиками для всех частей программного продукта),
- непрерывная интеграция написанного кода (код выпускается каждые несколько часов или, как минимум, один раз в день)
- игра в планирование: быстро формируется план работы и постоянно меняется по мере того, как условия задачи становятся всё более чёткими.
- частые релизы, итерации идут от 1 дня до 3 недель.
- непрерывная обратная связь с заказчиком и прочее.
Если XP используется только при разработке программного обеспечения, то Kanban и Scrum, в силу своей адаптивности, могут быть применены в разных сферах деятельности.
Идея Kanban заключается в том, чтобы в любой момент времени можно было запустить в работу нужные задачи или элементы в производство и максимально быстро их выполнить.
Это достигается путем визуализации всего бизнес-процесса, благодаря которому мгновенно обнаруживаются застои на каком-либо этапе производства и устраняются. Kanban может быть применен в разных сферах, от IT-проектов до производства в сфере промышленности. Подробнее о Kanban мы писали здесь.
Из всех фреймворков Agile больше всего нашей команде подошел Scrum, поэтому расскажем о нем подробнее.
Scrum более директивный подход к управлению проектами и включает в себя больше практик, чем Kanban, но также не навязывает четкие алгоритмы, а предлагает только базовые правила.
Scrum чрезвычайно обманчив: он прост для понимания, но требует колоссальных усилий при внедрении. В нашем случае внедрение Scrum заняло около 6 месяцев, и только относительно недавно он начал приносить ожидаемый результат.
Нередко среди команд распространен так называемый ScrumBut, когда принципы Scrum не используются в полной мере.
Его типичные примеры:
- Мы работаем по Scrum, но не можем выпускать готовый продукт так часто, так что наши спринты длятся 2 месяца
- У нас Scrum, но мы не устраиваем ежедневные митинги, потому что и так сидим все в одном офисе и общаемся.
- Мы не проводим ретроспективы, так как все проблемы, которые у нас были, устранены.
Это неверная позиция, с нашей точки зрения. Использование всех базовых процессов, методов Scrum необходимо. Их нужно прощупать со всех сторон на практике, поиграться с ними и только потом решить, подходят они вам или нет, что использовать, а что модифицировать.
Так, например, у нас было с ежедневными митингами: их мы исключили на начальном этапе работы по Scrum. Аргументация была простой: все рядом, а коллективная полемика ни к чему, так как лучше не отвлекать людей своими проблемами, а руководитель может с каждым индивидуально и оперативно разрешить любой возникший вопрос или проблему. Но, как показала дальнейшая практика, ежедневные митинги по 15-20 минут чрезвычайно важны. Но об этом далее.
Каким проектам подходит Scrum
Изначально Scrum зародился и применялся только в IT-сфере, но сегодня его практики можно встретить во многих проектах, где присутствует высокая степень неопределенности, где идеальный план сталкивается с реальностью и рассыпается в прах, где часто меняются приоритеты и возникают непредсказуемые сложности.
Scrum сегодня используют в маркетинговых, образовательных проектах, в рекрутинге, медиа, юристы и бухгалтеры, при ремонте квартир и даже в госструктурах.
К примеру, когда ремонт квартиры идет не строго по дизайн-проекту или вовсе кардинально меняется из-за отсутствия возможности сломать стену, Scrum вполне может подойти.
А для изготовления мебели строго по образцу — нет. Только если в процессе не возникают непредсказуемые сложности: от задержки и поставки не того материала до потери схемы заказа.
Есть мнение, что Scrum больше подходит для долгих, непрерывно развивающихся проектов. Также считается, что он особенно эффективен на начальных стадиях, когда нет четкого понимания, что делать в первую очередь и как именно. А по мере развития проекта могут использоваться лишь отдельные практики — Agile это допускает и предполагает.
Что убивает пользу от Scrum на корню
1. Прежде всего — это всевозможные виды потерь времени. В Scrum не должно быть ни одного движения впустую. К этому относится, например, многозадачность, неясность задач, отсутствие фокуса.
По поводу многозадачности и переключения между проектами американский ученый Джеральд Вайнберг привел следующие результаты исследований:
2. Люди с иным мышлением
К таким относятся, например, люди-звезды, эгоисты, всезнайки, стремящиеся показать только собственный результат, а не общий. Педантам, любящим порядок и стабильность, людям, сосредоточенным на процессе, а не результате, несамостоятельным исполнителям, не способным выдавать идеи, авторитарному руководителю, единолично принимающему все решения, тоже не место в Scrum-команде.
Scrum учит командной ответственности. Каждый член на равных со всеми добровольно отвечает за продукт.
3. Отсутствие согласованности действий и прозрачности работ
Бывает, что исполнитель занимается не тем, что запланировано было командой. Скажем, завтра релиз, а Пете ударила в голову новая идея и вместо того, чтобы допилить фичи из спринта, весь день занимался задачей, которая не войдет в него. В результате Петя подводит всю команду и релиз откладывается как минимум на 1 день. А если обратиться к таблице, представленной выше, то Петя из-за смены фокуса потерял гораздо больше времени, не говоря уже о сорванных сроках и психоэмоциональном состоянии остальных членов команды.
Мы сформулировали далеко не весь список причин провального применения Scrum, но выделили, на наш взгляд, наиболее важные.
Условия для создания Scrum
Для работы по Scrum необходим гармоничный баланс между процессом и результатом. Это достигается за счёт того, что проектом одновременно управляют Scrum-мастер и Владелец продукта.
Именно наличие двух руководителей помогает качественно работать как над развитием продукта, так и прогрессом команды. В совсем небольших командах эти две роли может играть один и тот же человек.
Владелец продукта (Product owner или Менеджер продукта) представляет интересы целевой аудитории. Он, как никто, знает потребности клиента, ваших пользователей, целевой аудитории. Именно составляет список пользовательских историй и определяет приоритеты.
Владелец продукта является ключевой ролью и принимает ответственные решения, поэтому он должен обладать высоким уровнем компетентности и ответственности.
Scrum-мастер координирует работу команды, следит за соблюдением принципов Scrum, контролирует ход проекта, помогает преодолевать трудности и заторы в работе, организует митинги, следит за сроками. Очень важным для Scrum-мастера является способность поддерживать положительную атмосферу в команде. Это своеобразный «Цербер», неукоснительно несущий вахту у врат царства Scrum, который с криком «Ты не пройдешь!» ограждает команду от всего несущественного.
Команда состоит из 3-9 человек, которые за счет взаимодействия и синергии обеспечивают наличие всех необходимых знаний и компетенций для обеспечения поставки продукта (услуги).
Примечание команды Flowlu:
В случае совмещения ролей важно понимать, что самое важное — это найти баланс. Роли Владельца продукта и Scrum-мастера подразумевают неизбежный конфликт интересов. Чрезвычайно сложно балансировать между желанием раздуть бэклог текущего спринта для увеличения ценности поставки и соблюдением принципов Scrum. Изменения в текущий спринт нужно вносить только при критической необходимости. К примеру, в функционале обнаружилась ошибка, которая делает его часть полностью неработоспособным, или ценность поставки будет нулевая без выполнения той или иной задачи. Если у одного человека не получается достичь такого баланса, то полезным будет делегировать роль Scrum-мастера одному из членов команды или не задействованному в проекте лицу. Это субъективное мнение, основанное лишь на личном опыте.
Инструменты для реализации Scrum-практик — подручные средства или специальное ПО.
Если у вас небольшой, простой проект, то это могут быть ватман, стикеры, карандаш, ручка, доска, стена. Для реализации сложных проектов без специальной программы не обойтись.
На начальном этапе внедрения Scrum мы использовали многофункциональную JIRA, обеспечивающую 100% покрытие потребностей в инструментарии. Но система оказалась чрезвычайно сложной в настройке и освоении. Поэтому решили, что пусть лучше ей пользуются eBay и Cisco, и за пару недель запилили свое приложение Agile проекты для Flowlu. Сейчас используем именно его и параллельно расширяем возможности, ориентируясь на собственные потребности и запросы наших любимых пользователей.
Практики Scrum, позволяющие достигать скоростных улучшений при ограниченности ресурсов
Работа по Scrum позволяет нам каждые 4 недели поставлять новый функционал и оперативно устранять недостатки продукта, внося корректировки в дальнейшие планы развития.
Бэклог
Примечание команды Flowlu:
Бэклог (Backlog Product) — приоритезированный список пользовательских историй.
Пользовательские истории (User Stories) — пожелания пользователей к продукту в виде сценариев использования. Формулируются обычно в виде: «Что, кому нужно и для чего». Скажем: «Мне, как бухгалтеру строительной организации нужна сводная таблица плановых затрат и поступлений, чтобы отслеживать кассовые разрывы». Именно такая формулировка пользовательской истории помогает точнее понимать и реализовывать потребности.
Эпики (Epics) или категории — это пользовательские истории, которые не могут быть выполнены за одну итерацию и содержат декомпозированный набор задач (или тех же историй). Эпик может быть закрыт в течение нескольких итераций разработки, после того, как все истории по нему будут реализованы, а новые перестанут поступать.
По каждой пользовательской истории должна быть резолюция Владельца продукта. К примеру: «Сделать» или «Не будет сделано», если она потеряла актуальность или противоречит направлению развития. На основании резолюции принимается решение о включении той или иной истории в поставку. Важно регулярно проводить ревью бэклога, где каждая история еще раз переоценивается и подтверждается ее приоритет. По нашему опыту, значимость пользовательских историй может разительно меняться от спринта к спринту.
Спринт
Примечание команды Flowlu:
Спринты — это итерации, жестко фиксированные по времени, которые начинаются с этапа планирования и заканчиваются демонстрацией продукта и ретроспективой.
Владелец продукта включает в спринт наиболее ценные на данный момент истории, задачи, зафиксированные ошибки.
При работе над спринтом последовательность задач лучше не изменять, так как они уже расставлены с учетом приоритета и блокировок (когда одну из задач невозможно выполнить, пока не выполнена другая).
Сроки спринта
Продолжительность спринта в Scrum обычно составляет 2-4 недели, что зависит от типа продукта и возможностей команды. Например, для разработки софта, скорее всего, подойдет 4-недельный спринт, а для медиа-проектов — недельный.
Со временем наиболее удобный временной отрезок для спринта определяется опытным путем. Благодаря строгой фиксации сроков, команда привыкает работать в одном темпе, что положительно сказывается на результате.
Оценка спринта
Один из важнейших этапов всей итерации. Именно во время оценки, команда вникает в суть и оценивает каждую задачу.
Существует множество способов, позволяющих эффективно оценивать объем работ в Scrum. Мы, например, используем покер планирование.
Эта техника позволяет объективно оценить каждую задачу в спринте, так как исключает эффект привязки при ее проведении. Каждый член команды, независимо от других, молча оценивает задачу и выкладывает карту с оценкой рубашкой вверх. При совпадении или небольшом расхождении оценок достигается консенсус и принимается итоговая оценка. Такой процесс повторяется для каждой задачи. В случае радикальной разницы в оценках задачи проводится коллективный разбор каждой крайней оценки (самой максимальной и самой минимальной).
В чем оценивать истории? Это решает каждый самостоятельно. Можно в днях, часах, абстрактных баллах — «попугаях» или стори поинтах. При использовании абстрактных величин, важно конвертировать одну единицу в нечто измеряемое во времени.
Примечание команды Flowlu: в нашей работе мы используем стори поинты, где 1 стори поинт = 4 часам работы.
Очень помогает при оценке сравнение текущей задачи с подобными, которые уже были реализованы, либо с теми, которые уже оценены. Если задача не поддается измеримой оценке, то она должна быть декомпозирована на простые действия, понятные всем участникам команды и ее владельцу. Реализация каждой задачи в спринте у нас не превышает 2 рабочих дней.
Регулярное проведение оценки с каждым разом повышает точность. А в процессе легко вычисляется «вес спринта» или производительность команды за итерацию.
Визуализация работы
Для визуализации процесса выполнения задач по спринту используется доска, разделенная на конкретные этапы работ (например, «Сделать», «В процессе», «Сделано», «Принято»). С помощью ее мгновенно выясняется, что уже выполнено, а к чему еще не приступили.
Благодаря тому, что известна сумма закрытых задач и тех, что еще предстоит сделать, Scrum-мастер на диаграмме сгорания задач легко контролирует скорость работы команды в рамках спринта, вовремя замечает отставание от графика и предпринимает меры.
Допустим, вам предстоит сложный спринт в 40 story points, сроком на 20 рабочих дней. Прямая линия (линия идеального сгорания) на диаграмме покажет, сколько story points в идеале должно сгорать каждый день. Линия фактического остатка будет отображать, сколько story points осталось закрыть на текущий день. Если линия фактического значения выше эталона — команда отстает, ниже — опережает план.
В случае серьезного отставания спринт должен быть оптимизирован, задачи декомпозированы, а наименее важные — исключены из спринта. Важно, чтобы они были включены в следующую итерацию и полностью реализованы. Если задача не может быть выполнена частично, она полностью исключается и заменяется на другую.
Совещания
Ежедневные 15-минутные стендапы полезны в любой команде, даже если все участники сидят в одном кабинете и общаются между собой в течение дня.
По началу такие 15-минутки кажутся бредом, но проведя несколько совещаний, каждый начинает понимать, как вся команда достигает цели, какие сложности возникают и как они будут решены.
На ежедневном стендапе каждый участник команды стоя рассказывает о достигнутых результатах за прошлый день, обещает, что будет достигнуто сегодня и делится проблемами, из-за которых ему не удается добиться результата. По окончании совещания каждый член команды осведомлен, кто и чем будет заниматься сегодня, и как разрешить возникшие трудности. Если в рамках совещания какой-либо вопрос не разрешен, то он решается в рабочем порядке при участии руководителя, чтобы не отнимать у всей команды время.
Такая схема переговоров помогает держать тонус в коллективе: каждый участник стремится каждый день достигать какого-то результата, в противном случае ему нечего будет рассказать на очередном стендапе. Стендапы также помогают вовремя выявить риски, угрожающие успешному завершению спринта и нивелировать их.
Демо и ретроспектива
Каждый спринт заканчивается двухэтапным обзором. I этап — это демонстрация выполненного функционала для всей команды, а II этап — ретроспектива. Оба проводятся в последний день спринта.
Основная цель проведения ретроспективы — повысить качество следующей итерации. На ретроспективе с командой обсуждаются 2 основных вопроса: «Что было сделано хорошо?» и «Что можно сделать лучше в следующей итерации?».
Продолжительность ретроспективы может зависеть от объема спринта. Для 1-недельного спринта совещание идет примерно 45 минут, для 2-недельного — 1,5 часа и т.д. Но в основном продолжительность зависит от сложностей, которые возникли в процессе спринта, чтобы в следующем их исключить.
Подробнее об ретроспективе мы писали здесь.
Заключение
Scrum — один из тех подходов к управлению проектом, который может быть понят только на деле. Каждый член команды должен разделять и принимать принципы работы.
Главное в Scrum — поддерживать драйв и положительный настрой в команде, и, ни в коем случае, не нарушать сроки поставки.
