Скрам (англ. Scram) — один из гибких методов управления проектами. Он помогает командам перестроить свою работу по-новому: с помощью особого разделения ролей и настройки работы на определенный ритм команда может начать выдавать более стабильный результат и стать более слаженной. Из чего состоит скрам? В видео Михаил расскажет о том, какие роли должны быть в команде и как устроены рабочие процессы, когда вы работаете по скраму.
Спринтами к финишу
Спринт — это отрезок времени, за который скрам-команда создает часть продукта, готовую к показу и ценную для клиента. На спринте завязано несколько событий в скраме:
- Планирование спринта — скрам-команда встречается и формирует бэклог спринта на основе своего предсказания о том, сколько они успеют сделать за спринт.
- Ежедневный скрам — 15-минутная встреча, когда команда должна понять, где они находятся, обсудить текущие проблемы и наметить пути их решения.
- Обзор спринта — событие, когда скрам-команда приглашает всех заинтересованных лиц, чтобы получить обратную связь по сделанному инкременту.
- Ретроспектива спринта — встреча, на которой скрам-команда обсуждает собственные процессы работы, где были болевые точки и почему. Хорошая команда, конечно, будет работать над фактом доставлен/не доставлен инкремент, скорость увеличивается/уменьшается, качество продукта растет/не растет, лучше ли мы попадаем в ожидания пользователя/хуже ли мы попадаем в ожидания пользователя.
Как понять, что мы правильно работаем? Практики скрама
В скраме также есть практики, которые помогают понять, правильно ли работает ваша команда. И вообще, то ли мы делаем.
Как правильно достигать цели спринта
Первая практика — цель спринта. Например, к концу спринта вы должны сделать отчет или добавить новую функцию. Как правило, цель спринта начинающим скрам-командам ставит владелец продукта. Опытная команда в состоянии определить цель самостоятельно и менять задачи внутри спринта на свое усмотрение.
Казалось бы, зачем нужна цель, если есть бэклог спринта, в котором и так написано, что нужно делать? На самом деле цели можно достичь разными путями, для этого необязательно решать все задачи в том порядке, в котором у вас записано.
Например, вы работаете над рекламной кампанией. На очередном спринте нужно сделать видеоролик — это цель спринта. Бэклог состоит из следующих задач: написать сценарий, найти актеров и т. д. Но вдруг что-то идет не так: актеры заболели, съемки срываются. Что делать? Ждать выздоровления актеров или искать новых?
В любом случае вы теряете время.
Тут и помогает цель спринта — она помогает вам сфокусироваться на результате. Если вы продолжите цепляться за бэклог, то цель не получится достичь вовремя. Цель спринта — сделать рекламный ролик, но там нет ни слова об актерах. Значит, вы можете привлечь иллюстратора и сделать ролик в срок без актеров.
Как критерии готовности помогают понять, что цель достигнута
Вторая практика — «критерий готовности». Когда задача или инкремент «готовы», нужно иметь четкий параметр, чтобы проверить, так ли это в действительности.
Критерий готовности может быть разным. Например, ваш критерий готовности инкремента такой: заказчик может дать отзыв. Предположим, у нас с вами есть задача сделать рекламный ролик. Чтобы ваш заказчик мог посмотреть его целиком и дать свой отзыв, ролик должен быть снят, смонтирован, озвучен, к нему должна быть добавлена графика и т.д. Получив обратную связь, вы отправитесь на доработку.
Может быть и другой критерий готовности: например, ролик должен быть протестирован на фокус-группах или транслироваться по телевизору. В этом случае, даже есть ролик готов, но с фокус-группой или трансляцией вы не успели, задача не выполнена.
Распространенные ошибки в скраме
Когда методика или подход становятся популярными, многие внедряют их в свою работу, допуская ошибки. Неправильно понятый скрам может причинить гораздо больше вреда, чем пользы.
Итак, вот основные ошибки, которые могут возникнуть в скраме:
- Внедрять скрам частично.
- Копить технический долг.
- Работать «по скраму», но без правильных выделенных ролей или без самодостаточной команды.
- Не давать планировать спринты команде самостоятельно.
Ценности скрама
Вы уже знаете, как устроен скрам. Осталось только узнать ценности, без внедрения которых методология провалится. Так что это за ценности?
Умение держать фокус
Держать фокус — значит эффективно использовать имеющиеся ресурсы.
Как может проявляться:
- Вы берете одну задачу и доводите ее до конца, получаете по ней обратную связь и уходите на доработку или принимаетесь за другую. Нельзя работать над десятью задачами одновременно.
- Вы знаете своих клиентов и понимаете требования к продукту. Если появляется какая-то модная технология или тренд, то вы можете распознать, что в этом не будет пользы для продукта, и не будете отвлекаться на ее изучение.
Смелость говорить «нет» и признавать ошибки.
Как может проявляться:
- Команда имеет смелость отказать владельцу продукта, если видит, что задачи расходятся с целью спринта, или понимает, что требуемые задачи невозможно сделать к определенному сроку.
- Член команды признает свои ошибки, проблемы или отсутствие экспертизы в каком-то вопросе.
- Владелец продукта говорит «нет» заказчикам, если их запросы противоречат цели текущего спринта или разработанной им стратегии развития продукта.
Коммитмент (по-русски «приверженность») — это обязательство и приверженность какой-то цели.
Как может проявляться:
- Самое главное, что обязуется делать команда, — быть профессионалами: использовать максимум своих знаний, опыта и навыков, для того чтобы инкремент получился. Команда может «коммититься» на цель спринта — это значит, что они приложат все усилия, чтобы цель была достигнута.
- Обещать достичь цели к определенному сроку — неправильно, потому что мы работаем в условиях неопределенности. Мы можем лишь правильно приоритизировать бэклог и планировать.
Уважение — базовое свойство команды, без которого она не может существовать.
Как может проявляться:
- Есть правило, что после формирования бэклога спринта никто, включая владельца продукта, не может туда ничего добавить. Но при этом, например, если действительно происходит форс-мажор, то владелец может прибежать к команде и попросить помочь. Команда, которая уважает владельца, разумеется, поможет.
- В обратную сторону это тоже работает. Владелец продукта в схожей ситуации должен уважать команду и убрать из бэклога спринта соразмерные задачи.
Открытость позволяет сделать прозрачными процессы внутри компании и снизить организационную неопределенность.
Как может проявляться:
- Вы уже знаете, что в скраме происходят регулярные встречи. Если в команде нет открытости, то такие встречи быстро превратятся в отчетные, когда каждый будет бояться рассказать о своих проблемах.
- Открытость позволяет понятно разделить зоны ответственности и сделать так, чтобы все в команде их понимали. Это исключает ситуации, когда мы не знаем, к кому мы должны идти с конкретным рабочим вопросом, и снижает время на передачу задачи от сотрудника к сотруднику.
Проверьте, насколько хорошо вы усвоили материал:
Источник: nplus1.ru
Scrum — Введение
Scrum — это эффективная структура основанная на гибких принципах, в рамках которой вы можете разрабатывать программное обеспечение с коллективной работой.
Agile стала одним из самых больших моментов в индустрии разработки программного обеспечения. Но что такое гибкое развитие? Проще говоря, гибкая разработка — это другой способ выполнения команд и проектов разработки программного обеспечения.
Чтобы понять, что нового, давайте вспомним традиционные методы. В обычной разработке программного обеспечения требования к продукту дорабатываются до начала разработки.
Модель водопада
Наиболее часто используемой моделью разработки программного обеспечения с этой характеристикой является модель водопада, как показано на следующей диаграмме. Однако в большинстве случаев новые функции добавляются, а также могут меняться более ранние требования. Модель «Водопад» не структурирована для учета таких постоянных изменений требований. Кроме того, пользователь не будет иметь ясности в отношении функциональности продукта, пока продукт не станет доступен в полном объеме.
Итеративная инкрементальная модель
В итеративной инкрементной модели разработка начинается с ограниченного количества финализированных и приоритетных требований. Конечный результат — это рабочий прирост продукта. Набор действий, начиная от требований к разработке кода, называется итерацией.
Основываясь на функциональности приращения и любых или всех новых, измененных, ожидающих требования, следующая партия требований предоставляется последующей итерации. Результатом последующей итерации является улучшенный рабочий прирост продукта. Это повторяется до тех пор, пока продукт не выполнит требуемые функции.
Пользователь обычно не участвует в разработке, и это может привести к сбоям в работе, что приводит к неправильным функциям. Участие позитивно для команды разработчиков, но требует вовремя команды и может добавить задержки. Кроме того, любые неформальные требования меняются во время итерации, что может привести к путанице и может также создавать сползания области. С этой предпосылкой возникла разработка Agile.
Agile Development
Гибкое развитие основано на итеративном поэтапном развитии, в котором требования и решения развиваются благодаря коллективному сотрудничеству. Он рекомендует использовать итеративный подход с временным интервалом и поощряет быстрое и гибкое реагирование на изменения. Это теоретическая основа и не указывает какой-либо конкретной практики, которой должна следовать команда разработчиков.
Scrum — это специфическая гибкая структура процесса, которая определяет методы, которым необходимо следовать.
Гибкий манифест
Манифест Agile был опубликован группой разработчиков программного обеспечения в 2001 году, в котором подчеркивается важность, которую необходимо уделять команде разработчиков, с учетом меняющихся требований, участия клиентов.
Магический манифест выглядит следующим образом:
«Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим в этом. Благодаря этой работе мы стали ценить:
- Физические лица и взаимодействия над процессами и инструментами
- Рабочее программное обеспечение по полной документации
- Сотрудничество с клиентами по заключению договоров
- Реагирование на изменение в соответствии с планом
Определение элементов гибкого манифеста
Элементы манифеста слева можно описать следующим образом:
- самоорганизация и самомотивация членов команды
- непрерывное взаимодействие для работы, разъяснения, информация среди членов команды
Ключевым элементом Agile Manifesto является то, что мы должны доверять людям и их способности сотрудничать. По этой причине разработанные конкретные гибкие методологии выявили возможности членов команды, подчеркнув совместную работу и сотрудничество на протяжении всего жизненного цикла проекта.
Основные принципы гибкой
Agile Manifesto основывается на следующих принципах:
| Удовлетворение и доставка | Удовлетворенность клиентов через раннее и непрерывное рабочее программное обеспечение. |
| Приветственное изменение | Приветствуем меняющиеся требования, даже на более поздних этапах разработки. |
| Доставить часто | Доставляйте рабочее программное обеспечение часто (еженедельно, а не ежемесячно). |
| Связь — это ключ | Обеспечьте тесную связь разработчиков с деловыми людьми на ежедневной основе. |
| Экология и доверие | Создавайте проекты вокруг мотивированных людей.Дайте им необходимую поддержку и верьте им. |
| Лицевая связь | Поощряйте личную беседу, чтобы обеспечить эффективную и эффективную связь. |
| Программное обеспечение как меру прогресса | Рабочее программное обеспечение является основным показателем прогресса. |
| Устойчивое развитие | Содействовать устойчивому развитию с возможностью поддерживать постоянный темп развития. |
| Внимание к деталям | Постоянное внимание к техническому совершенству и хорошему дизайну. |
| Сила меньше | Простота важна. |
| Самоорганизующиеся команды | Регулярное внимание команды к эффективному изменению ситуации. |
Гибкие методологии
Методология разработки динамической системы (DSDM)
Это гибкая структура для программных проектов. Он использовался для тонкой настройки традиционных подходов. Самая последняя версия DSDM называется DSDM Atern. Название Atern — это сокращение от Arctic Tern — морская птица, которая может путешествовать на огромные расстояния, что представляет многие особенности метода, которые являются естественными способами работы, такими как установление приоритетов и сотрудничество.
Scrum
Это самая популярная гибкая структура, в которой особое внимание уделяется тому, как управлять задачами в командной среде разработки на основе команд. Scrum использует итеративную и инкрементную модель разработки с меньшей продолжительностью итераций. Scrum относительно прост для реализации и фокусируется на быстрых и частых поставках.
Экстремальное программирование (XP)
Это тип гибкой разработки программного обеспечения. Он выступает за частые выпуски в короткие циклы разработки, которые направлены на повышение производительности и внедрение контрольно-пропускных пунктов, где могут быть приняты новые требования клиентов. Методология берет свое название от идеи, что полезные элементы традиционной практики разработки программного обеспечения принимаются на экстремальных уровнях. (Экстремальное программирование — это дисциплина разработки программного обеспечения, которая позволяет людям производить более качественное программное обеспечение более продуктивно.) XP рассматривает фазы анализа, разработки и тестирования с новыми подходами, которые существенно влияют на качество конечного продукта.
Тестируемое развитие (TDD)
Это процесс разработки программного обеспечения, который основан на повторении очень короткого цикла разработки: сначала разработчик пишет автоматизированный тестовый пример, который определяет желаемое улучшение или новую функцию, затем он производит наименьшее количество кода для прохождения этого теста и наконец, привносит новый код в приемлемые стандарты.
Опираться
Это производственная практика, которая учитывает расходование ресурсов по любой цели, кроме создания ценности для конечного потребителя, которая является расточительной и, следовательно, является целью ликвидации. Работая с точки зрения клиента, который потребляет продукт или услугу, термин значение определяется как любое действие или процесс, который клиент готов заплатить. Lean сосредоточен на сохранении ценности с меньшим количеством работы.
Kanban
Это система для улучшения и поддержания высокого уровня производства. Канбан — это один из методов, благодаря которому «Just-In-Time» (JIT), стратегия, которую организации используют для контроля затрат на инвентаризацию, достигается. Канбан стал эффективным инструментом поддержки функционирования всей системы производства, и это оказалось отличным способом для улучшения.
Источник: unetway.com
Система 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 стоит на личной ответственности человека, а не на отлаживании внутренних процессов.
(Из статьи на VC.ru)
Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.
(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)
Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
(Из перевода колонки Forbes на Rusbase)
Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.
(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)
Слово экспертам
В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность.
Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников.
Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.
Владимир Овелян
Владелец и генеральный директор Dostаевский
Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота.
По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.
Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»
Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок.
Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.
Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring
Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”.
Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.
Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.
Евгений Россинский Директор по технологии в онлайн-кинотеатре ivi
Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей. Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.
Ирина Черепанова
Директор по продукту uKit Group
Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно.
Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.
Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова
Что почитать по теме?
- Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
- Дж. Сазерленд «Scrum. Революционный метод управления проектами»
- Д. Андерсон «Канбан. Альтернативный путь в Agile»
- Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
- K. Schwaber, J. Sutherland “The Scrum Guide”
- M. Cohn “Agile estimating and planning”
RB.RU организует встречу проекта Founders’ Mondays для начинающих и опытных предпринимателей. Дважды в месяц по понедельникам.
Текст: Александр Петров.
Источник: rb.ru