Управление проектами по методологии Agile [В чем его суть и с чего начать]

Как использовать методологию agile для вашей команды разработчиков

Просмотр тем

Что такое управление проектами по методике agile?

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

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

Вот что вам нужно знать, чтобы начать работу с agile или использовать эту методику эффективнее.

ЧИТАЙТЕ НИЖЕ

Статьи об agile-управлении проектами

[ПРОДОЛЖЕНИЕ]

Краткая история управления проектами по гибкой методологии Agile

Команды разработчиков ПО создали методику agile, чтобы избавиться от лишних операций, повысить прозрачность процессов и быстро удовлетворять меняющиеся потребности клиентов. На ее создание их вдохновила концепция бережливого производства, возникшая в компании Toyota в 1940-х годах. Agile существенно отличается от каскадного метода, ориентированного на разработку в рамках крупных проектов. Благодаря этой методике улучшается качество совместной работы, а инновации внедряются невероятно быстро.

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

Методика 1 для управления проектами по Agile: Scrum

Scrum — это одна из методологий agile для управления проектами. В ее основе лежат серии итераций фиксированной продолжительности, называемые спринтами. Структура спринта состоит из четырех составляющих.

Все начинается с бэклога — списка работ, которые необходимо выполнить. В Scrum есть два бэклога. Первый — это бэклог продукта (принадлежит владельцу продукта), или список функциональных возможностей, расставленных с учетом приоритета. Второй — бэклог спринта, в который попадают задачи из верхней части бэклога продукта, пока возможности нового спринта не будут исчерпаны. В Scrum у всех членов команды есть уникальные роли, которые зависят от того, как именно они участвуют в процессе. Как правило, в команде есть scrum-мастер (он отвечает за реализацию scrum-методологии), владелец продукта (он представляет продукт) и scrum-команда, зачастую состоящая из специалистов разного профиля, которые и выполняют поставленные задачи.

Четыре составляющих Scrum

Планирование спринтов	ДЕМОНСТРАЦИЯ СПРИНТА	Ежедневные стэндапы	Ретроспектива
Собрание команды по планированию для определения объема работы на следующий спринт.	Общее собрание с демонстрацией результатов, достигнутых командой в ходе работы над последним спринтом.	Известно также как «стендап»: короткое 15-минутное совещание для синхронизации работы команды.	Обзор удачных и неудачных событий текущего спринта и обсуждение действий для улучшения следующего спринта.

Scrum-доска

Доска Scrum используется для визуализации работы в рамках спринта. В ходе собрания по планированию спринта команда перемещает элементы из бэклога продукта в бэклог спринта. На досках Scrum рабочие процессы представляются по этапам, например Сделать, В работе и Готово. Доски Scrum — это ключевой компонент для повышения прозрачности при agile-управлении проектами. Начните использовать доску Scrum в нашем бесплатном шаблоне Scrum для Jira.

Методика 2 для управления проектами по Agile: Kanban

Kanban представляет собой agile-методику управления проектами, в которой работа сопоставляется с ресурсами команды. Ее цель — выполнять работу как можно быстрее, поэтому kanban-команды могут реагировать на изменения даже оперативнее, чем scrum-разработчики.

В отличие от scrum, в kanban-методологии обычно нет бэклогов. Вся работа находится в столбце «Сделать». Благодаря этому kanban-команды могут создавать непрерывные процессы и выпускать релизы в любой момент. Вся работа видна, подсчитана и готова к выполнению, поэтому по завершении одной задачи команда сразу же переходит к следующей. Команда получает определенный объем работ, исходя из лимитов WIP — заранее определенного количества задач, которые могут одновременно находиться в одном столбце (за исключением столбца «Сделать»). Kanban-методология подразумевает четыре компонента.

Четыре компонента Kanban

Список работы (истории)	Столбцы или полосы	Лимиты задач в работе (WIP)	Непрерывные релизы
Список работы (истории) — это проблемы или задачи, которые необходимо решить.	Используются в kanban-досках для разделения задач, соответствующих различным рабочим процессам, пользователям, проектам и т. д.	Правило для ограничения объема работы на основании ресурсов команды.	Команда работает над определенным числом историй в пределах лимита WIP и может выпустить релиз в любое время.

Kanban-доска

Доска Kanban используется для визуализации выполняемой работы. Она также полезна при планировании ресурсов, поскольку менеджеры проектов видят задачи и могут определить соответствующие сроки. Доска Kanban состоит из столбцов и полос, по которым истории движутся по мере выполнения. Истории остаются в столбце «Сделать» до тех пор, пока лимит WIP не позволит перейти к следующему заданию. Список работ необходимо разделять на относительно небольшие задачи и располагать в порядке приоритета. Как видно из этого примера, с помощью полос можно отделять более приоритетные задачи от «всего остального». Начните использовать доску Kanban в нашем бесплатном шаблоне Kanban для Jira.

Обязанности менеджеров agile-проектов

Чтобы планировать новые задачи или спринты, необходимо как-то отслеживать ход работы команды. При этом неважно, какая методология agile-разработки ПО была выбрана. Благодаря оценке проектов по agile-методике командам, использующим scrum или kanban, проще оценивать свои ресурсы. В agile-отчетах показано, как движется работа в команде. А ведение бэклога помогает руководителям проектов подготовить для команды список актуальных задач.

Оценка проекта по методике agile

Оценка проекта — это необычайно важный аспект управления проектами и в Kanban, и в Scrum. Kanban-команды в большинстве своем устанавливают лимиты WIP для каждого этапа работы, исходя из своего опыта и размера команды. Scrum-команды определяют, сколько работы можно сделать в рамках одного спринта, путем оценки проекта. Многие agile-команды для вычисления этого значения используют уникальные методики, такие как покер планирования, оценка в идеальных часах или в очках за истории. Это дает точку отсчета, благодаря которой в процессе ретроспективы спринта становится понятно, как идет работа. Jira Software можно настроить с учетом уникальной системы оценки проекта, используемой той или иной командой.

Agile-отчеты

Оценку проекта следует выполнять в начале и в конце каждого спринта. Таким образом, в начале спринта команда определяет, что можно сделать, а в конце — насколько точной была первоначальная оценка. Agile-отчеты, например диаграммы сгорания, показывают, сколько «очков за историю» будет отработано в течение спринта. Jira Software предлагает десятки встроенных отчетов, в которых эффективность команды отображается в режиме реального времени. Данные, на которые можно опираться в ретроспективах, открывают перед вами невероятные возможности по улучшению своей работы.

Бэклог: ведение и управление

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

Благодаря бэклогам, содержимое которых непрерывно меняется в соответствии с ресурсами команды и актуальными бизнес-задачами, командам проще достигать долгосрочных целей. С Jira Software можно вести огромные бэклоги с разноплановыми иерархиями и сортировать пользовательские истории и баги, просто перетаскивая задачи. Искать нужную историю или баг можно с помощью фильтров и гибкого поиска Jira Software.

Effective stakeholder communication

Agile project managers also have to report the right amount of context to different stakeholders and teams — including senior leadership — on the status of the projects they’re responsible for.

With Atlas, project managers can share curated weekly updates on the progress of work, where it’s happening, and call out key blockers, changes, and updates.

Начните бесплатно с шаблона для управления проектами Jira

Управляйте любыми проектами с помощью мощных инструментов для управления заданиями и удобной расстановки приоритетов.

Использовать шаблон

Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Квартальное agile-планирование — 8 шагов для начала работы

Отправляясь на очередное рабочее совещание по квартальному agile-планированию, я поняла, что тоже работаю над долгосрочным проектом: строю дом. Создание программного обеспечения и строительство дома во многом похожи: это долгосрочные проекты, в которых нескольким командам необходимо согласовывать действия друг с другом, и к тому же (тут меня поймет любой домовладелец) они никогда не заканчиваются. Всегда может понадобиться внести улучшения, что-нибудь починить или поменять с учетом новых рыночных тенденций. Без плана вы рискуете столкнуться с потенциальными блокерами и вечно отодвигать дату въезда.

У разработки программного продукта есть одно выгодное отличие от строительства — возможность применения agile-методологии. Она позволяет нескольким командам быстро реагировать на изменения. Но как agile‑методология, в основе которой лежат частые и непрерывные поставки, может сосуществовать с долгосрочным планированием проекта? Можно ли создать реалистичный прогноз на длительный период, зная, что единственная постоянная — это изменение?

Независимо от того, на каком этапе agile-пути вы находитесь, используете вы kanban, scrum или только начинаете практиковать agile-подход при любом масштабе, в процессе разработки долгосрочного стратегического видения вам все равно требуется управлять кадрами, объемами работы и сроками. При разработке программного обеспечения сложно создать концепцию развития с помощью изолированных инструментов вроде диаграмм Ганта, электронных таблиц и всевозможных сочетаний инструментов управления портфелем проектов (PPM). Либо, как это было в случае с моим подрядчиком, мешанина из электронных таблиц, писем и текстовых сообщений становится просто непригодной к использованию.

Прежде чем говорить о решениях для динамического прогнозирования, давайте рассмотрим шаги по созданию долгосрочного agile-плана на примере строительства дома.

Шаг 1. Начните с комплексного представления проекта.

Как при строительстве дома, так и при выпуске продукта нужно определить видение и выделить стратегические темы. Представьте, что темы — это основные направления деятельности в рамках организации. На чем вы хотите сосредоточиться в течение следующего квартала, шести месяцев, года? Чему вы хотите посвятить время и ресурсы? Производительность, взаимодействие с пользователем, безопасность, новые конкурентоспособные возможности (кто-нибудь хочет джакузи?) или сразу несколько пунктов из этого перечня?

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

Шаг 2. Определите самые важные составляющие.

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

Шаг 3. Разбейте работу на части.

Что именно необходимо сделать для установки новых надежных окон? Разбейте крупные участки работы на более мелкие, типа эпиков, которые помогут в квартальном agile-планировании. Это даст вам подробное представление обо всех шагах, необходимых для выполнения задуманного.

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

Он поможет на следующем, самом важном этапе процесса планирования: оценке.

Шаг 4. Проведите оценку.

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

Здесь имеет значение опыт работы подрядчика (или менеджеров по продукту и разработке). Просмотрев аналогичные уже выполненные работы, можно получить ясное представление о том, что нужно для завершения каждого эпика.

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

Чуть позже вы передадите конечный вариант дорожной карты команде (разработчикам, установщикам окон и т. д.), и они укажут более точное время выполнения работ.

Шаг 5. Создайте умные релизы.

При использовании agile-методик разработки команды обычно поставляют работающую часть программного обеспечения в конце каждого спринта в виде релиза (или версии). Однако при долгосрочном планировании и составлении дорожной карты необходимо определить примерные точки релизов, чтобы вы могли прикинуть даты релизов в следующем квартале с помощью квартального agile-планирования. Такой точкой может быть «Завершение наружных работ по строительству дома», куда входят работы, связанные с установкой надежных окон, включая рамы, покраску, изоляцию и т. д.

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

Шаг 6. Создайте дорожную карту.

Теперь у вас есть предварительный бэклог, релизы и команды с определенной производительностью. Традиционный треугольник планирования показывает, что план имеет три переменные: объем работы (что вы хотите сделать), время (сколько времени это займет) и ресурсы (кто может это сделать). У вас есть все необходимое для создания реалистичной дорожной карты. Наконец-то подрядчик сможет сообщить примерную дату фактического заселения!

Профессиональный совет. Чтобы создать реалистичную дорожную карту для команд, принимать решения на основе имеющихся данных и постоянно информировать заинтересованные стороны о ходе работы в командах, можно воспользоваться таким инструментом, как дорожные карты в Jira Software.

Шаг 7. Поделитесь картой с командой и подтвердите ее.

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

Шаг 8. Продолжайте оптимизировать.

Agile-методология, как и владение домом, не предполагает окончания проекта. Непрерывное подкрепление ценности с помощью пошаговых улучшений позволяет внедрять инновации и делать свой дом шикарным. Используйте дорожную карту для наполнения и оптимизации дальнейших дорожных карт. Получая отзывы от клиентов или членов своей семьи, продолжайте регулярно тестировать и постоянно улучшать проект.

Хотите создать дорожную карту, чтобы обозначить цели на перспективу? Эта возможность предусмотрена в таких продуктах Jira Software, как Advanced Roadmaps и Jira Align. Посмотрите, чем они отличаются, и определите, какой из них оптимально подходит для вашего бизнеса.

Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Что такое Agile? | Atlassian

Что такое методология Agile?

Методология Agile — это подход к управлению проектами, который включает разбиение проекта на этапы и делает упор на постоянное сотрудничество и совершенствование. Команды следуют циклу планирования, выполнения и оценки.

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

Agile не определяется набором церемоний или конкретными методами разработки. Скорее, agile — это группа методологий, демонстрирующих приверженность тесным циклам обратной связи и постоянному совершенствованию.

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

Почему стоит выбрать Agile?

Команды выбирают Agile, чтобы они могли быстро реагировать на изменения на рынке или отзывы клиентов, не нарушая годовой план. Планирование «достаточно» и поставка небольшими частыми частями позволяют вашей команде собирать отзывы о каждом изменении и интегрировать их в будущие планы с минимальными затратами.

Но это не просто игра с числами — в первую очередь речь идет о людях. Как описано в Манифесте Agile, подлинное человеческое взаимодействие важнее жестких процессов. Сотрудничество с клиентами и товарищами по команде важнее заранее определенных договоренностей. И предоставление работающего решения проблемы клиента важнее сверхдетальной документации.

Agile-команда объединяется под общим видением, а затем воплощает его в жизнь так, как считает нужным. Каждая команда устанавливает собственные стандарты качества, удобства использования и полноты. Затем их «определение готовности» информирует о том, как быстро они будут выполнять работу. Хотя поначалу это может быть пугающим, руководители компаний обнаруживают, что, когда они доверяют гибкой команде, эта команда чувствует большее чувство сопричастности и поднимается, чтобы соответствовать (или превосходить) ожиданиям руководства.

Agile вчера, сегодня и завтра

Публикация Agile Manifesto в 2001 году знаменует собой рождение Agile как методологии. С тех пор появилось множество гибких фреймворков, таких как scrum, kanban, Lean и Extreme Programming (XP). Каждый по-своему воплощает в себе основные принципы частого повторения, непрерывного обучения и высокого качества. Scrum и XP предпочитают команды разработчиков программного обеспечения, в то время как канбан — любимец команд, ориентированных на обслуживание, таких как ИТ или отдел кадров.

Сегодня многие agile-команды комбинируют практики из нескольких разных фреймворков, приправляя их уникальными для команды практиками. Некоторые команды применяют некоторые agile-ритуалы (например, регулярные стендапы, ретроспективы, невыполненные работы и т.  д.), в то время как другие создают новую agile-практику (команды agile-маркетологов, которые придерживаются манифеста Agile-маркетинга).

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

Atlassian об agile

Способ применения agile каждой командой должен соответствовать их потребностям и культуре. Действительно, нет двух команд внутри Atlassian с одинаковыми agile-методами.

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

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

Ключ к правильному использованию agile — постоянное совершенствование. Экспериментируйте с различными практиками и открыто и честно обсуждайте их со своей командой. Оставьте те, которые работают, и выбросьте те, которые не работают.

Как пользоваться этим сайтом

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

Вы также найдете руководства по сочетанию этих практик с Jira Software, нашим инструментом управления проектами для гибких команд разработчиков. Хотите настроить канбан-доску? Получить информацию из отчета о скорости вашей команды? Все это есть в учебниках.

Вы на правильном пути. Продолжать идти!

Что это такое, как это работает и с чего начать

Что такое скрам?

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

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

В этой статье мы обсудим, как устроена традиционная среда Scrum, с помощью Руководства по Scrum и Дэвида Уэста, генерального директора Scrum.org. Мы также включим примеры того, как наши клиенты отклоняются от этих основ, чтобы соответствовать их конкретным потребностям. Для этого наша собственная Меган Кук, менеджер группы продуктов Jira Software и бывший коуч по Agile, даст советы и рекомендации в нашей серии видеороликов Agile Coach:

Agile против Scrum

Люди часто думают, что scrum и agile — это одно и то же, потому что Scrum основан на постоянном совершенствовании, которое является основным принципом Agile. Однако скрам — это основа для выполнения работы, тогда как agile — это философия. Философия Agile сосредоточена на постоянном постепенном улучшении посредством небольших и частых выпусков. Вы не можете по-настоящему «стать гибким», так как требуется самоотверженность всей команды, чтобы изменить то, как они думают о предоставлении ценности вашим клиентам. Но вы можете использовать такой фреймворк, как скрам, чтобы начать думать таким образом и практиковать внедрение agile-принципов в повседневное общение и работу.

Разницу между Agile и определением scrum можно найти в руководстве по Scrum и в манифесте Agile. Agile-манифест выделяет четыре ценности:

• Люди и взаимодействие важнее процессов и инструментов
• Работающее программное обеспечение важнее подробной документации
• Сотрудничество с клиентами важнее переговоров по контракту
• Реагирование на изменения важнее следования плану

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

Хотя схватка структурирована, она не является полностью жесткой. Его исполнение может быть адаптировано к потребностям любой организации. Существует множество теорий о том, как именно должны работать скрам-команды, чтобы добиться успеха. Однако за более чем десятилетний опыт помощи agile-командам в Atlassian мы поняли, что четкая коммуникация, прозрачность и стремление к постоянному совершенствованию всегда должны оставаться в центре любой выбранной вами платформы. А остальное зависит от вас.

Структура scrum

Структура scrum описывает набор ценностей, принципов и практик, которым следуют команды scrum для предоставления продукта или услуги. В нем подробно описаны члены скрам-команды и их обязанности, «артефакты», которые определяют продукт и работу по созданию продукта, а также скрам-церемонии, которые направляют скрам-команду в работе.

Члены scrum-команды

scrum-команда — это небольшая и гибкая команда, занимающаяся созданием обязательных приращений продукта. Размер скрам-команды обычно невелик, около 10 человек, но этого достаточно, чтобы выполнить значительный объем работы за спринт. Скрам-команде нужны три конкретные роли: владелец продукта, скрам-мастер и команда разработчиков. А поскольку скрам-команды являются кросс-функциональными, в команду разработчиков помимо разработчиков входят тестировщики, дизайнеры, специалисты по пользовательскому опыту и операционные инженеры.

Владелец продукта схватки

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

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

Скрам-мастер

Скрам-мастера — чемпионы по скраму в своих командах. Они тренируют команды, владельцев продуктов и бизнес по процессу схватки и ищут способы улучшить свою практику.

Эффективный скрам-мастер глубоко понимает работу, выполняемую командой, и может помочь команде оптимизировать их прозрачность и поток доставки. Как главный фасилитатор, он/она планирует необходимые ресурсы (как человеческие, так и материально-технические) для планирования спринта, стендапа, обзора спринта и ретроспективы спринта.

Команда разработчиков Scrum

Команда Scrum выполняет s*%&. Они являются чемпионами по практике устойчивого развития. Наиболее эффективные скрам-команды сплочены, расположены в одном месте и состоят обычно из пяти-семи человек. Один из способов определить размер команды — использовать знаменитое «правило двух пицц», придуманное Джеффом Безосом, генеральным директором Amazon (команда должна быть достаточно маленькой, чтобы разделить две пиццы).

Члены команды имеют разные наборы навыков и взаимно обучают друг друга, чтобы ни один человек не стал узким местом в выполнении работы. Сильные скрам-команды самоорганизуются и подходят к своим проектам с четким отношением «мы». Все члены команды помогают друг другу, чтобы обеспечить успешное завершение спринта.

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

Скрам-артефакты

Скрам-артефакты — это важная информация, используемая скрам-командой, которая помогает определить продукт и то, какую работу необходимо выполнить для его создания. В скраме есть три артефакта: бэклог продукта, бэклог спринта и приращение с вашим определением «готово». Это три константы, над которыми скрам-команда должна размышлять во время спринтов и с течением времени.

• Бэклог продукта — это основной список работ, которые должен выполнять и поддерживать владелец продукта или менеджер по продукту. Это динамический список функций, требований, улучшений и исправлений, который служит входными данными для невыполненной работы спринта. По сути, это список дел команды. Бэклог продукта постоянно пересматривается, переприоритизируется и поддерживается владельцем продукта, поскольку по мере того, как мы узнаем больше или по мере изменения рынка, элементы могут перестать быть актуальными или проблемы могут быть решены другими способами.
• Бэклог спринта — это список элементов, пользовательских историй или исправлений ошибок, выбранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом на совещании по планированию спринта (которое мы обсудим позже в этой статье) команда выбирает, над какими элементами она будет работать в течение спринта, из бэклога продукта. Бэклог спринта может быть гибким и развиваться в течение спринта. Однако основная цель спринта — чего команда хочет достичь в текущем спринте — не может быть поставлена ​​под угрозу.
• Инкремент (или цель спринта) — это полезный конечный продукт спринта. В Atlassian мы обычно демонстрируем «приращение» во время демонстрации в конце спринта, когда команда показывает, что было выполнено в спринте. Вы можете не слышать слова «инкремент» в мире, так как его часто называют командным определением «Готово», вехой, целью спринта или даже полной версией или выпущенным эпиком. Это просто зависит от того, как ваши команды определяют «Готово» и как вы определяете свои цели спринта. Например, некоторые команды предпочитают выпускать что-то для своих клиентов в конце каждого спринта. Таким образом, их определение «готово» будет «отправлено». Однако это может быть нереалистичным для других типов команд. Допустим, вы работаете над серверным продуктом, который может поставляться вашим клиентам только раз в квартал. Вы по-прежнему можете работать двухнедельными спринтами, но ваше определение «готовости» может заключаться в завершении части более крупной версии, которую вы планируете выпустить вместе. Но, конечно, чем больше времени требуется для выпуска программного обеспечения, тем выше риск того, что программное обеспечение не достигнет цели.

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

Скрам-церемонии или мероприятия

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

 

Ниже приведен список всех ключевых церемоний, в которых может участвовать скрам-команда:

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

2. Планирование спринта : Работа, которая должна быть выполнена (объем) в течение текущего спринта, планируется на этой встрече всей командой разработчиков. Это совещание проводится скрам-мастером, и на нем команда определяет цель спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. Эти истории всегда согласуются с целью, а также согласовываются командой Scrum, чтобы их можно было реализовать во время спринта.

   В конце встречи по планированию каждый участник схватки должен четко понимать, что можно сделать в спринте и как можно реализовать приращение.

3. Спринт : Спринт — это фактический период времени, когда скрам-команда работает вместе, чтобы завершить инкремент. Две недели — довольно типичная продолжительность спринта, хотя некоторые команды считают, что неделя будет проще для определения масштаба, а месяц — для того, чтобы сделать ценный шаг вперед. Дэйв Уэст из Scrum.org советует, что чем сложнее работа и чем больше неизвестных, тем короче должен быть спринт. Но это действительно зависит от вашей команды, и вы не должны бояться изменить его, если он не работает! В течение этого периода область действия может быть повторно согласована между владельцем продукта и командой разработчиков, если это необходимо. Это составляет суть эмпирической природы схватки.

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

4. Ежедневная схватка или стендап : Это ежедневная суперкороткая встреча, которая проводится в одно и то же время (обычно по утрам) и место для простоты. Многие команды пытаются завершить встречу за 15 минут, но это всего лишь рекомендация. Эту встречу также называют «ежедневным стендапом», подчеркивая, что она должна быть быстрой. Цель ежедневного скрама состоит в том, чтобы все в команде были на одной волне, соответствовали цели спринта и составили план на следующие 24 часа.

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

   Обычный способ проведения стендапа состоит в том, чтобы каждый член команды ответил на три вопроса в контексте достижения цели спринта:

   •      Что я делал вчера?
   •      Что я планирую делать сегодня?
   •      Есть ли препятствия?

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

5. Обзор спринта : В конце спринта команда собирается на неофициальную сессию, чтобы просмотреть демонстрацию или проверить инкремент. Команда разработчиков демонстрирует элементы невыполненной работы, которые теперь «Готово», заинтересованным сторонам и товарищам по команде для обратной связи. Владелец продукта может решить, выпускать инкремент или нет, хотя в большинстве случаев инкремент выпускается.

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

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

Начните бесплатно с помощью шаблона Jira scrum

Оптимизируйте свой проект и легко планируйте, отслеживайте и управляйте работой между спринтами. Скрам-шаблон Jira включает в себя доски, невыполненные работы, дорожные карты, отчеты и многое другое!

Использовать шаблон

Значения Scrum

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

Приверженность

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

Смелость

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

Фокус

В основе рабочего процесса скрам-команды лежит спринт — целенаправленный и определенный период времени, в течение которого команда выполняет определенный объем работы. Спринт обеспечивает структуру, но также фокусирует внимание на выполнении запланированного объема работы.

Открытость

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

• Над чем я работал вчера?
• Над чем я работаю сегодня?
• Какие проблемы блокируют меня?

Это помогает выделять прогресс и выявлять блокираторы. Это также помогает укрепить команду, когда все делятся прогрессом.

Уважение

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

Scrum, канбан и agile

Scrum настолько популярен в agile-фреймворке, что Scrum и agile часто ошибочно принимают за одно и то же. Но есть и другие фреймворки, такие как канбан, который является популярной альтернативой. Некоторые компании даже предпочитают следовать гибридной модели scrum и kanban, которая получила название «Scrumban» или «Kanplan», что означает Kanban с отставанием.

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

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

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

Начало работы с scrum

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

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

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