Будь гибким: как понять Scrum и создать agile-команду

Определение

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?

Agile – это подход к управлению проектами или разработке программного обеспечения. В рамках Agile требования и решения развиваются благодаря итерациям и совместным усилиям многофункциональных самоорганизующихся команд и бизнес-пользователей. Agile приветствует меняющиеся требования, даже на более поздних этапах. Клиенты, участники бизнеса и разработчики работают вместе во всем проекте. Гибкие команды корректируют свое поведение в соответствии с меняющимися потребностями проекта.

Agile – это философия или ориентация (Griffin). Agile широко служит ориентиром для приближения к проектной работе. Гибкая методология подчеркивает итерацию разработки, а также тестирование в жизненном цикле разработки программного обеспечения (SDLC). Agile разбивает целый продукт или проект на небольшие сборки. В методологии Agile разработка или тестирование происходит одновременно. Agile поддерживает совместную работу, а также прямую связь.

Что такое Scrum?

Scrum является основой для управления проектом или разработкой программного обеспечения. Scrum – один из гибких процессов. Scrum фокусируется на предоставлении бизнес-стоимости бизнес-пользователям в минимальное время. Проекты делятся на спринты, которые обычно продолжаются от одной до трех недель. Scrum имеет три основные роли: мастер схватки, владелец продукта и члены команды.

Scrum подчеркивает самоорганизацию и совместное владение членами команды. Он рассматривает управление проектами как процесс создания общей ценности; и подчеркивает совместную работу и Итеративное развитие для эффективного управления изменениями и создания лучших продуктов для удовлетворения потребностей клиентов. Scrum рассматривает время как ограничение. Он подчеркивает время-бокс и использует ежедневные совещания по планированию и обзору спринта.

Сходство между Agile и Scrum:

Agile и scrum, оба связаны с управлением проектами и разработкой программного обеспечения. Поскольку Scrum является одним из способов реализации Agile, у них обоих есть несколько сходств. Оба подчеркивают оптимальное использование ресурсов. Оба акцентируют внимание на эффективном и эффективном управлении различными задачами.

Agile и scrum, оба нацелены на то, чтобы максимально использовать бизнес-пользователей. Они стараются обеспечить доставку продукта или проекта бизнес-пользователям в течение минимально возможного времени. Оба подчеркивают постоянное совершенствование, сотрудничество, открытое общение и т. Д.

Природа Agile и Scrum:

Agile – это методология разработки и основанная на инкрементном и итеративном подходе; в то время как Scrum является одной из многих схем внедрения или процессов гибкой методологии.

Scrum предоставляет инкрементные модули клиенту каждую неделю или две недели.

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.

(Из перевода колонки Forbes на Rusbase)

Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Как и зачем появилась scrum-методология

До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.

  1. Определить требования к продукту.
  2. Спланировать весь проект от начала до конца.
  3. Написать код.
  4. Протестировать продукт.

Разработчики согласовывали план работы с заказчиком и четко следовали техническому заданию. Когда продукт был готов, его тестировали, но уже не было возможности что-то поменять. Поэтому если выявлялись ошибки, приходилось начинать все сначала, а сроки работы увеличивались.

Так было, пока группа новаторов не решила изменить ситуацию полностью. Они наблюдали за тем, как работают успешные команды: не срывая сроки и получая именно тот результат, который планировали. Оказалось, что успех заключался в гибкости процесса.

Выводы, которые были сделаны, помогли создать «Манифест гибкой разработки программного обеспечения». В него вошли всего четыре пункта, но они полностью изменили процесс.

Манифест гибкой разработки ПО

1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.

Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы12 принципов, которые и сейчас используются в любой agile-методологии.

12 принципов Agile

1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.

Agile и водопад, весы

Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.

Создатели Scrum Джефф Сазерленд и Кен Швабер долгие годы наблюдали за работой американских военных, спецназовцев и даже регбистов. И заметили, что их успех основан на взаимодействии и командной работе. Сазерленд и Швабер поняли, что этого как раз и не хватает разработчикам программного обеспечения. Так появилась методология Scrum.

Основные принципы Scrum

Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.

Работа короткими циклами (спринтами)

Планируйте один спринт, а не весь проект сразу. Каждый спринт — период времени, за который команда работает над полностью законченной частью продукта.

Гибкость. «Проверять и адаптироваться»

Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идет не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог БэклогУпорядоченный список задач, над которыми scrum-команда работает при создании продукта.продукта.

Участие заказчика и пользователей в создании продукта.

Заказчик не стоит в стороне, а полностью задействован в работе. Для это существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведется короткими этапами, пользователи подключаются к тестированию почти сразу.

После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.

Взаимодействие команды

Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к одной общей цели.

О важности scrum-команды

Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трех человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.

Состав команды

  • Владелец продукта. Человек, который представляет продукт и является посредником между заказчиком, пользователями и командой разработчиков. Иногда им может быть сам заказчик.
  • Scrum-мастер. Чаще всего — специально нанятый сотрудник, который ведет команду к результату. Он не управляет командой, но наблюдает за исполнением основных принципов Scrum. Его задача — не давить, не делать всю работу самому и не распределять обязанности, но помогать, направлять и решать вопросы, которые тормозят процесс разработки.
  • Разработчики. В составе scrum-команды всегда есть люди с разным набором навыков. Так, команда из пяти-девяти человек ведет весь проект от начала до конца. Одна команда — один готовый продукт.
Как выглядит scrum-команда

Распределение ролей

Скрам работает, когда есть распределение ролей. Всего их три.

Команда. Это самоорганизованная группа из 3−9 человек. Вклад отдельного сотрудника не оценивается. Важно только то, какого результата добилась команда совместными усилиями.

Владелец продукта. Обычно это предприниматель, который знает свой бизнес и понимает потребности покупателей. У него достаточно опыта, чтобы знать, каким должен быть готовый продукт. Владелец продукта — связующее звено между командой, потребителем и производством. Он работает с обратной связью, принимает важные решения и следит за бюджетом проекта. Владелец продукта не говорит команде, по какому пути идти, а смотрит только на результат.

Скрам-мастер или лидер команды. Скрам-мастер отвечает за успех команды. Он не принимает решений и не руководит. Его задача — сделать так, чтобы команда работала без управленческих рычагов. Скрам-мастер — это клей, который скрепляет команду.

Инструменты Скрама

Скрам (Scrum) — методика гибкого планирования, которая подходит для любых проектов. С её помощью можно увеличить производительность компании и достичь лучшего результата. Например, раньше на задачу команда тратила месяц, а на доработки — полмесяца. Теперь на эту же задачу уйдёт 2 недели, а доработок, скорее всего, не будет.

Инструкция: как использовать Скрам, чтобы работать по Аджайлу

Скрам проще других фреймворков. Он даёт инструменты и подсказывает, в какой последовательности их применять, чтобы добиться результата.

Скрам предлагает делать так:

  1. Прокачать теоретическую базу: почитать книги по теме и посмотреть видеолекции. Записи с конференций Agiledays есть на Ютубе на канале . В сообществе последователи Скрам делятся опытом — можно поучиться у них.
  2. Выбрать владельца продукта. Это человек, который в деталях представляет готовый продукт. Он же будет оценивать риски, выгоды и принимать стратегические решения.
  3. Собрать команду из 3−9 человек. В команде должны быть люди, у которых достаточно знаний и навыков, чтобы работать над проектом.
  4. Назначить скрам-мастера или пригласить на эту роль профессионала из консалтингового агентства.
  5. Предложить владельцу продукта прописать бэклог и дать команде его оценить. Отлично, если команда оценит его не в часах, а в относительных единицах.
  6. Запланировать спринт. У него должна быть фиксированная продолжительность и точный список задач, который нельзя дополнять.
  7. Сделать работу прозрачной. Каждый член команды должен видеть, какие задачи уже решены, а над какими ещё нужно поработать. Для этого нужны инструменты: скрам-доска или диаграмма сгорания задач.
  8. Проводить ежедневные общекомандные собрания — ежедневный Скрам. На встречах участники команды сверяются с результатами друг друга, смотрят, на каком этапе находится проект и решают, как дальше двигаться к цели. Собрание длится 15 минут. Если получается дольше, значит, команда и скрам-мастер что-то делают не так.
  9. Завершить спринт обзором. Обзор спринта — встреча, на которой присутствуют любые заинтересованные лица: потребитель, заказчик, владелец продукта, скрам-мастер. На встрече команда показывает готовый продукт или его часть. Неважно, что это будет, главное — чтобы оно выполняло свою функцию.
  10. Провести ретроспективное собрание сразу после обзора спринта. Когда команда показала работающий продукт, все садятся за стол и анализируют спринт. Что прошло хорошо? Что можно улучшить? Какие препятствия преодолела команда? В конце собрания скрам-мастер и команда должны подумать, как сделать следующий спринт ещё лучше.
  11. Немедленно назначить новый спринт!

Кому подойдёт Аджайл

Аджайл меняет подход к жизни и предпринимательству. Он учит быстро реагировать на обстоятельства и подстраиваться под них.

Аджайл работает везде: в менеджменте, торговле, сфере услуг. Кто-то использует его, чтобы управлять собственной жизнью и всё успевать.

Но никто не даст гарантии, что он поможет конкретной компании. Если компания небольшая, поменять сознание людей проще. Большим корпорациям труднее: когда есть несколько отделов, а в каждом — свой руководитель, внедрение Аджайл может затянуться. Коллектив будет сопротивляться изменениям. Чтобы было проще, такие компании приглашают Аджайл-коучей.

Аджайл не подойдёт тем, кто много лет подряд делают типовой продукт. Таким компаниям выгоднее сделать тысячу одинаковых стульев за один раз: заказы всё равно будут. Но как только появляется заказчик с особыми пожеланиями — нужен точно такой же стул, но ножки пусть будут пошире, а обивка поярче — Аджайл необходим.

Слово экспертам

Владимир Овелян

В зависимости от задач мы применяем разные методы в рамках философии – 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 это не нужно.
Источники

  • https://rb.ru/story/agile-scrum-kanban/
  • https://ru.esdifferent.com/difference-between-agile-and-scrum
  • https://skillbox.ru/media/management/kak_ponyat_scrum/
  • https://allo.tochka.com/agile-scrum

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Лайфхаки на каждый день, полезные советы
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: