что такое аджайл и скрам
Scrum и Agile для чайников
Комментарий Котиков
Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.
На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.
Эджайл и скрам помогают организовать процесс работы в команде так, чтобы выпускать интересный пользователю продукт регулярно и часто.
В некоторых банках путь идеи к пользователям благодаря эджайлу сократили с двух лет до шести месяцев — в других компаниях шесть месяцев цикла разработки сжались в три. В наше суматошное время это истинное конкурентное преимущество, особенно для малых игроков.
Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?
Кое-что из эджайла и скрама можно взять даже в индивидуальную работу. Обеспечить регулярную публикацию постов, отмерять нагрузку на исполнителя, оценивать будущие задачи по времени и не забывать анализировать качество проделанной работы — смотрите, за нас уже всё придумали. Осталось внедрить.
Эджайл
(англ.agile —«проворный, шустрый, сообразительный»)
Концепция гибкости:
Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.
«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?
Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете
Скрам
(англ. scrum — толкотня в борьбе за мячик в регби)
Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.
Жесткость скрама заключается в структуре. Есть некий набор подходов, работающих вместе лучше, чем по отдельности. Вытащить что-нибудь и заиспользовать вам, я надеюсь, никто не запретит.
Обычно скрам происходит там, где есть некий продукт, имеющий ценность для пользователей и заказчиков, и нужно как можно быстрее на пути к цели понимать, в том ли направлении мы сейчас бежим — или надо корректировать курс. Формат скрама позволяет выпускать очередную версию чаще, регулярно получать обратную связь и быстро дорабатывать продукт, а также — улучшать процесс работы.
Если вы работаете в команде, скрам предписывает всем участникам процесса стремиться к взаимозаменяемости, к способности «подхватить» провисающую задачу, если сосед заболел, к обмену навыками и коллективной ответственности за продукт. Индивидуализма в скраме мало. Решения принимаются коллективно (по строгим принципам), никто не может надавить и заставить выбрать другое решение, если команда уверена, что остановилась на верном.
Поэтому даже если мы все уверенно побежали в неправильном направлении, у нас будет в конце спринта возможность его скорректировать и починить то, что нас направляет не туда. Команда в скраме самоорганизующаяся и самонастраивающаяся.
Команда в скраме
Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.
В каждой команде есть:
Устройство спринт
Работа в скраме состоит из спринтов. Все спринты устроены одинаково. Предполагается, что с каждым следующим спринтом команда становится всё сыграннее и эффективнее. В скраме учишься на своих ошибках, но быстро — каждый спринт анализируешь, что именно натворил и как хочешь это исправить.
У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.
В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.
Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.
В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.
Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.
В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.
Результатом спринта всегда является что-то, что можно показать. Показывает работу команда на демо в конце спринта.
На мой взгляд, скрам-процесс похож на работу над коллективным блогом. Такой процесс помог бы соблюсти регулярность, свести воедино экспертизу авторов и не набирать столько, что не успеешь сделать.
Структура спринта
Спринт начинается с планирования: команда садится и обсуждает: вот эту идею берем, вон ту не берем. В IT этот процесс может затягиваться на пару часов, потому что обсуждение идет вплоть до деталей. В случае работы с блогом это может превратиться в обсуждение тем и плана статей, которые потом останется сесть и написать — понимая, что пишем, когда и зачем.
Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.
Каждый участник стендапа по очереди отвечает на три вопроса:
Все завязывающиеся в процессе детальные разговоры уходят за пределы стендапа. Стендап — это точка, в которой можно поймать проблемы или узнать, что мы с коллегой почему-то делаем одно и то же одновременно, а значит — кто-то из нас может заняться чем-то другим.
Вообще поддержанием всех вот этих четких правил поведения должен заниматься скрам-мастер. Это обычно идеологи технологии, верящие в нее и готовые выстраивать процесс для максимальной эффективности проведенного вместе времени. Без скрам-мастера процессы выродятся в минимально возможные, потому что человек ленив и экономичен.
В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.
«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)
Что такое Agile, как работает Scrum и почему от KPI пора отказываться?
«Гибкие методологии управления», Aglie – последние несколько лет эти термины не просто на слуху, они в абсолютном тренде. Даже мы, команда Kickidler используем методологию Agile в своей работе. Сегодня разберёмся в том, почему давно проверенные KPI уступают место новым подходам, а также поговорим о том, как контролировать сотрудников в Agile.
Что такое Agile?
Прежде всего, Agile – это не «ещё один метод управления компанией» и не какая-то конкретная практика. Agile представляет собой полноценную методологию: комплексное собрание инструментов, подходов и принципов, которые необходимы и достаточно для выстраивания любого бизнес-процесса в организации.
Главная идея Agile: контроль с сохранением максимальной гибкости в планировании и реализации проектов. Эта мысль появилась в Кремниевой Долине, где новые тренды возникали, развивались и гибли в течение считанных недель. Счёт шёл на часы: та мысль, которая ещё вчера могла родить нового титана рынка, сегодня уже никому не была интересна. Традиционный метод прямого управления, которого придерживались консерваторы, в таких условиях просто не работал – и так появился Agile.
В чём разница между Agile и Scrum?
Agile – это, собственно, методология, основные принципы которой вы найдёте чуть ниже. Можно назвать Agile фундаментальным базисом для выстраивания компании нового поколения. Scrum же – это «структурный подход»: один из инструментов Agile, который используется чаще всего.
Суть Scrum в создании универсальных проектных команд, внутри которых уже есть все необходимые специалисты: дизайнеры, разработчики, маркетологи. Исчезает сам формат сотрудничества между отделами: все, кто нужен, уже состоят в команде. Кроме того, к ней обязательно присоединяются «владелец продукта» (куратор проекта) и scrum-мастер, организатор работы.
Рабочий процесс в Scrum выстраивается спринтами – это периоды продолжительностью 7-30 дней, в зависимости от команды и проекта. На каждый спринт формируются свои задачи, по которым в конце подводятся результаты. А дальше следует новый спринт.
Манифест Agile и основные принципы
Всё строится на следующих ключевых правилах:
Это очень простые тезисы, но часть из них полностью противоречит привычным для консервативного бизнеса стратегиям прямого контроля и управления. Отсутствие бюрократии, самоорганизация внутри команд – новые нормы современного мира, что приводит нас к очевидному вопросу:
KPI устарели?
Система KPI хороша всем, кроме одного: чем дальше в 21-й век, тем хуже она работает. Чтобы понять, почему так происходит, нужно обратиться к истокам и посмотреть на 1954-й год. Именно тогда Питер Друкер, один из самых выдающихся теоретиков менеджмента в истории, представил свою концепцию «ключевых показателей эффективности».
Мысль была проста и элегантна: «Работодатель хочет, чтобы сотрудник выполнял определённый объём работ. Нужно определить для каждого работника – а в более широком понимании для каждого проекта или подразделения – некие ключевые показатели, которые позволят понять, справляется человек или нет».
KPI чаще всего очевидны: для маркетинга это количество лидов, для отдела продаж – собственно продажи. Для производства – объём выпускаемой продукции и процент брака. Для офиса – время, проведённое сотрудником за компьютером, в рабочем приложении. И так далее.
Однако у KPI есть ключевой недостаток: неповоротливость. Питер Друкер разрабатывал эту концепцию для рынка пятидесятых, стабильного и предсказуемого. Планирование на месяцы и годы вперёд было нормальным явлением, поэтому компания могла себе позволить вложиться в определение KPI, донесение их до сотрудников и контроль над соблюдением этих показателей.
Сегодня мы живём в совершенно другом мире: рынок меняется ежемесячно, ежедневно, а иногда и ежечасно. KPI устаревают раньше, чем вы их окончательно принимаете, становятся непоказательными. И здесь на сцену выходят новые методы организации работы.
Чего хочет современный работодатель?
Пользуясь KPI, мы устанавливаем жёсткие рамки конкретных показателей и загоняем в них сотрудника. Например, если для маркетолога ключевой параметр – количество лидов или заявок, он будет его повышать в ущерб их рентабельности в средне/долгосрочной перспективе. Работники на производстве могут увеличивать выработку, игнорируя рост расходов на обслуживание оборудования и замену инструментов. И так далее.
Современная практика показывает: KPI – это лишь промежуточный этап, который косвенно относится к настоящим требованиям работодателя. На самом же деле бизнес всегда стремится к выполнению вполне конкретных целей: росту выручки. Снижению расходов. Повышению конверсии рекламы. И так далее.
Методология Agile построена как раз на понимании этого принципа в сочетании с высокой динамикой рынка. Если упрощать, работает простое правило: ставите цель на короткий период – получаете результат – ставите новую цель. На первый план выходит не достижение каких-то абстрактных, численных показателей, а удовлетворённость конечного пользователя результатом вашей работы: клиента, руководителя, себя самого и т. д.
Как контролировать сотрудников без KPI?
Agile предполагает работу в проектных группах с контролем над достижением ценности. Вся деятельность ведётся короткими итерациями: 2-3 недели на выполнение одной цели – например, это может быть «снизить дебиторскую задолженность клиентов перед компанией на 40% и более». Команда работает, еженедельно проводятся общие совещания-планёрки с обсуждением результатов, по истечении срока подводятся итоги.
Такой подход работает, но при этом важно понимать: переход от привычных KPI к Agile-методологии, которая предполагает высокую вовлечённость сотрудника в процессы и определённую степень личной ответственности, не всегда проходит гладко. Более того, даже в процессе работы в agile-модели сотрудники могут время от времени пытаться снизить личный вклад в проект, «выехав на плечах других». Мир не стал идеальным, поэтому даже если ваша команда использует принципы agile, контроль за ней все равно нужен.
И здесь на помощь приходят методы непрямого контроля. Вам нужен способ проверять «уровень старательности» сотрудника, не привлекая его внимания – так вы не подорвёте доверие к принципам agile, но сможете держать руку на пульсе.
Мониторинг с помощью системы учета рабочего времени Kickidler даёт всю необходимую информацию: вы видите, сколько времени сотрудник проводит в рабочих приложениях, насколько он активен, какие ведёт переписки, чем вообще занимается на протяжении дня. При этом сам специалист даже не подозревает о вашем внимании.
Другой метод – дать сотрудникам возможность самим контролировать собственную продуктивность, без участия или с минимальным участием руководства. Для этой задачи идеально подходит новый инструмент программы Kickidler Автокик.
Автокик – это автоматические уведомления о нежелательных событиях и интерфейс самоконтроля сотрудника. Первая функция позволяет показывать сотруднику автоматическое уведопление, например, если он бездействовал в течение получаса, посещал непродуктивный для работы сайт или запускал нежелательную программу, например, игру. Интерфейс самоконтроля позволит сотруднику видеть собственную продуктивность за день, учитывая продуктивную, непродуктивную деятельность. Бездействие и общее количество отработанных часов. Специально для удаленных команд мы разработали возможность сотруднику самостоятельно включать и отключать граббер-агент программы, чтобы никто не имел доступ к компьютеру сотрудника в нерабочие часы.
В результате KPI как таковых нет, но вы сохраняете контроль над ситуацией. А в будущем можно использовать тот же Kickidler как платформу для самомодерирования отношения внутри команды – например, организовать открытый доступ к отчётам по активности работающей по проектам группы. «Все видят всех», полная прозрачность: такой подход увеличивает ответственность сотрудников и снижает вовлечённость руководителя, обеспечивая одновременный рост результатов.
Жёсткий прямой контроль уходит в прошлое. Сейчас наступило время гибких методологий и непрямого управления: попробуйте выстраивать работу по-новому, а наши инструменты вам в этом помогут.
Система учета рабочего времени
Agile, scrum, kanban: в чем разница и для чего использовать?
Главный редактор RB.RU
Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?
Специально для тех, кто запутался в терминах, мы кратко разобрали эти понятия и спросили экспертов, зачем компании переходить на новую систему.
Определение
Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.
Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.
Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».
Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.
К отдельным agile-подходам относятся scrum и kanban.
Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.
Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.
Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.
Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.
Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.
Для визуализации agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.
Примеры употребления
Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.
Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.
(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)
Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.
(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)
Слово экспертам
В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.
Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.
Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.
Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.
Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей. Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.
Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.
Что почитать по теме?
Поиск инвестора онлайн стал намного проще. Узнай как
Текст: Александр Петров.
Видео по теме: