Что такое agile scrum
Что такое Agile и подойдет ли он вашей компании
Что такое Agile
Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.
Термин Agile употребляют в двух основных значениях:
Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.
Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.
«Манифест Agile» и основные принципы
Agile-манифест базируется на четырех главных ценностях:
1. Люди и их взаимодействие важнее процессов и инструментов.
Нужно создать такие условия, чтобы инструменты и процессы не ограничивали команду, а позволяли ей работать как можно эффективнее. Каждый может сам решать, какие инструменты и процессы ему подходят.
В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.
2. Работающий продукт важнее документации и отчетности.
Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации. Поэтому в рамках Agile фокусируются на том, чтобы продукт как можно быстрее был готов к использованию, пренебрегая технической документацией и отчетностью.
3. Сотрудничество с заказчиком важнее соблюдения формальных условий.
Даже если перед проектом подписан договор с жесткими условиями и характеристиками, в процессе работы они могут меняться. Например, если некоторые детали окажутся не такими значимыми, и задачу можно решить гораздо проще и эффективнее. Это делается в интересах клиента, которому важен рабочий продукт, а не формальные требования. При этом важно постоянно быть на связи и обсуждать каждое изменение, принимая решение совместно.
4. Готовность к изменениям важнее, чем следование плану.
Изменения можно и нужно вносить на каждой стадии — или итерации, — чтобы не откладывать их на конец, когда сроки и ресурсы уже поджимают. Ради этого вполне можно пожертвовать чем-то из запланированного, если основные задачи будут решены.
Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:
Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.
Что такое Scrum и Kanban
Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.
Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.
В отличие от scrum, kanban:
В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Пример доски Trello, созданной по принципам agile.
Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.
В каких компаниях используют Agile
Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.
Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.
Существует ли Agile в России
В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.
ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:
Нужен ли вашей команде Agile
Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:
Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.
Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.
Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.
Что такое 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 как платформу для самомодерирования отношения внутри команды – например, организовать открытый доступ к отчётам по активности работающей по проектам группы. «Все видят всех», полная прозрачность: такой подход увеличивает ответственность сотрудников и снижает вовлечённость руководителя, обеспечивая одновременный рост результатов.
Жёсткий прямой контроль уходит в прошлое. Сейчас наступило время гибких методологий и непрямого управления: попробуйте выстраивать работу по-новому, а наши инструменты вам в этом помогут.
Система учета рабочего времени
Будь гибким: как понять Scrum и создать agile-команду
Scrum — методология гибкого процесса разработки программного обеспечения. Сейчас этот метод управления популярен и активно применяется.
Прежде чем разобраться, что такое Scrum и как внедрить эту методологию, давайте посмотрим на предпосылки её возникновения.
Как и зачем появилась Scrum-методология
До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.
Разработчики согласовывали план работы с заказчиком и чётко следовали техническому заданию. Когда продукт был готов, его тестировали, но уже не было возможности что-то поменять. Поэтому, если выявлялись ошибки, приходилось начинать всё сначала, а сроки работы увеличивались.
Так было, пока группа новаторов не решила изменить ситуацию полностью. Они наблюдали за тем, как работают успешные команды: не срывая сроки и получая именно тот результат, который планировали. Оказалось, что успех обеспечивала гибкость процесса.
Выводы, которые были сделаны, помогли создать «Манифест гибкой разработки программного обеспечения». В него вошли всего четыре пункта, но они полностью изменили процесс.
Манифест гибкой разработки ПО
1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.
Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы 12 принципов, которые и сейчас используются в любой Agile-методологии.
12 принципов Agile
1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.
Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.
Создатели Scrum Джефф Сазерленд и Кен Швабер долгие годы наблюдали за работой американских военных, спецназовцев и даже регбистов. И заметили, что их успех основан на взаимодействии и командной работе. Сазерленд и Швабер поняли, что этого как раз и не хватает разработчикам программного обеспечения. Так появилась методология Scrum.
Принципы Scrum
Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.
Работа короткими циклами (спринтами)
Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта.
Гибкость. «Проверять и адаптироваться»
Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.
Участие заказчика и пользователей в создании продукта
Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу.
После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.
Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели.
О важности scrum-команды
Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трёх человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.
Состав команды
Принципы работы scrum-команды
Чтобы работать по методологии Scrum, команда разработчиков должна соблюдать три основных принципа.
Совершенствование продукта за счёт самосовершенствования сотрудника.
Каждый член команды отвечает за свою часть работы и за общий результат.
Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.
Процесс работы scrum-команды
Процесс работы scrum-команды проходит в несколько обязательных этапов.
Каждый спринт начинается с планирования. Scrum-мастер, владелец продукта и остальные члены команды вместе смотрят на бэклог продукта и выбирают направления, по которым будут работать в данном цикле. Так получается бэклог спринта, то есть список задач на этот период.
Дальше команда оценивает объём работ, оговаривает длительность спринта, в конце которого должен появиться результат, то есть готовый продукт.
Каждый день вся команда проводит короткую встречу, не более 15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:
Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.
Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.
Если кто-то из членов команды понимает, что не укладывается в спринт, он сообщает владельцу продукта, а тот распределяет время иначе. То же самое происходит, если команда понимает, что справится с задачей досрочно, — тогда можно добавить дополнительных задач из бэклога продукта.
Когда задачи спринта выполнены, команда должна продемонстрировать полностью работающую демоверсию той части ПО, над которой велась работа в спринте.
Как внедрить scrum-методологию
Сейчас методология Scrum находится на пике популярности. Вопрос о её пользе уже почти не звучит. Но как внедрить Scrum правильно, чтобы заметно улучшить ситуацию с продуктивностью и качеством итогового продукта?
Кажется, что всё просто. Нужны несколько последовательных действий.
Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.
2. Назначить владельца продукта
Это может быть заказчик или его представитель. Владелец продукта будет отвечать за взаимодействие с заказчиком и работать с пользователями на всех этапах разработки.
3. Выбрать scrum-мастера
Scrum-мастер — важная часть команды. От него зависит, насколько комфортно всем участникам процесса будет работать. Тут нужен опытный scrum-мастер, который хорошо знаком с методологией не только в теории.
4. Создать список требований к продукту
Прежде чем начать разработку, стоит подумать над списком требований и согласовать их. Получится своего рода техническое задание, которое будет направлять работу.
5. Спланировать спринт
Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.
6. Постоянно анализировать и оценивать результат
Подводить итоги после каждого спринта и оценивать результат. Переходить к следующему спринту, только если довольны результатом предыдущего.
Вот они — шесть шагов, которые ведут к увеличению продуктивности разработчиков, сокращению сроков работы и качественному программному обеспечению. Но так ли это просто, как кажется на первый взгляд? Как понять, успешно ли внедрён Scrum, и сделать так, чтобы не испортить показатели ещё больше?
Сейчас много scrum-теоретиков, которые плохо понимают, как работать с реальным продуктом. Поэтому важно учиться только у тех, кто знает, что такое Scrum, на практике, разбирается во всех тонкостях не только методологии, но и её внедрения в конкретную область. Ведь этот процесс сильно зависит от продукта, который вы собираетесь создавать с помощью Scrum.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Упорядоченный список задач, над которыми scrum-команда работает при создании продукта.