Методология аджайл: Scrum — что это такое, как это работает и в чем преимущества

Scrum — что это такое, как это работает и в чем преимущества

Что такое Scrum?

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

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

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

Статьи по теме Scrum

Сравнение Agile и Scrum

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

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

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

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

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

Методика Scrum

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

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

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

Владелец продукта Scrum

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

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

Scrum-мастер

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

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

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

На scrum-команды ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные scrum-команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос: в команде должно быть столько участников, чтобы им хватало двух пицц.

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

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

Артефакты Scrum

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

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

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

Собрания или мероприятия Scrum

Методика Scrum включает практики, церемонии или собрания, которые регулярно проводят scrum-команды. Именно в Agile-собраниях заметнее всего проявляются различия между командами. Некоторым командам в тягость проводить однообразные собрания; в других рабочие встречи обязательны. Если вы только начинаете знакомство со Scrum, рекомендуется в течение первых двух спринтов провести все собрания, чтобы понять свое отношение к ним. После этого можно организовать короткую ретроспективу, чтобы решить, что нужно скорректировать.

Перечислим основные собрания, в которых может принять участие команда Scrum.

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

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

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

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

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

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

   Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

   Чаще всего в рамках стендапа каждому участнику команды предлагается ответить на следующие три вопроса, связанные с достижением цели спринта:

   • Что мне удалось сделать вчера?
   • Что я планирую сделать сегодня?
   • Может ли мне что-то помешать?

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

5. Обзор итогов спринта. В конце спринта команда собирается для просмотра демонстрации инкремента (или для его изучения) в неформальной обстановке. Команда разработчиков представляет заинтересованным сторонам и коллегам завершенные рабочие задачи из бэклога, чтобы собрать отзывы. Владелец продукта решает, стоит ли выпускать инкремент, хотя в большинстве случаев команда получает зеленый свет.

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

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

Начните бесплатно с шаблоном Scrum для Jira

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

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

Ценности Scrum

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

Подтверждение

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

Смелость

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

Ключевая деятельность

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

Открытость

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

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

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

Уважение

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методика, что слова Scrum и Agile многие ошибочно используют как синонимы. Но есть и другие популярные методики, например Kanban. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

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

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

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

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

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

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

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

Чтобы изучить Scrum с помощью Jira Software, прочитайте это руководство.

Claire Drumond

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

Kanban: краткое знакомство | Atlassian

Хотя методика Kanban зародилась более 50 лет назад, она невероятно популярна среди современных Agile- и DevOps-команд разработчиков. В конце сороковых годов XX века компания «Тойота» начала использовать модель заполнения полок в супермаркетах, чтобы оптимизировать технологический процесс. Супермаркеты выставляют ограниченное количество товаров, которого при этом достаточно для удовлетворения потребительского спроса. Таким образом оптимизируется поток товаров между супермаркетом и потребителем. Если уровень запасов соответствует потребительскому спросу, значительно увеличивается эффективность управления складом, ведь избыточных запасов — которые тоже нужно где-то хранить — становится меньше. При этом супермаркет по-прежнему гарантирует, что нужный потребителю товар всегда есть в наличии.

Компания «Тойота» применила эту систему в своих цехах, чтобы лучше соотнести внушительные складские запасы и реально используемые в производстве материалы. Для отслеживания объемов производства в цехе (и взаимодействия с поставщиками) в режиме реального времени использовалась специальная карточка, или Kanban, которую рабочие передавали между командами. Когда в корзине заканчивались используемые на участке производства материалы, на склад передавали Kanban с указанием необходимого материала, нужного количества и т. д. На складе уже стояла новая корзина с этим материалом: ее отправляли в цех, а складские работники отсылали поставщику свой Kanban. У поставщика корзина с этим материалом тоже была готова, и он отправлял ее на склад. Конечно, в современном мире сообщения передаются совсем не так, как в сороковых, но смысл остается тем же — все основано на процессе «своевременного» производства (JIT).

Kanban для команд разработчиков ПО

В наши дни agile-команды разработчиков ПО используют принцип JIT, чтобы добиться соответствия между объемом незавершенной работы (WIP) и производительностью команды. Это дает командам больше гибкости при планировании, позволяет быстрее получать результаты, облегчает концентрацию на работе и обеспечивает прозрачность всего цикла разработки.

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

Kanban-доски

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

Доски нужны, чтобы визуализировать работу команды, стандартизировать процесс, а также найти и устранить блокеры и зависимости. И не важно, в какой форме они представлены — в физической или в цифровой. На стандартной Kanban-доске процесс состоит из трех шагов: «Запланировано», «В работе» и «Сделано». Однако доску можно настроить в соответствии с процессом, принятым в той или иной команде, в зависимости от ее размеров, структуры и целей.

Методология Kanban основана на полной прозрачности работы и обсуждении производительности в режиме реального времени. Поэтому доска Kanban должна стать единственным достоверным источником информации о работе команды.

Kanban-карточки

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

Зачем отображать работу в виде карточки на Kanban-доске? Благодаря такому наглядному представлению членам команды будет проще и удобнее отслеживать жизненный цикл рабочих задач. На Kanban-карточках отображается важная информация о конкретной рабочей задаче, доступная всей команде: имя ответственного за выполнение задачи, краткое описание выполненной работы, оценка необходимого времени и т. д. На виртуальных Kanban-досках в карточки также часто добавляют снимки экрана и другие важные для исполнителя технические детали. Когда все члены команды видят состояние каждой рабочей задачи в любой момент времени, а также всю связанную с ней информацию, повышается концентрация, обеспечивается полная прозрачность, быстрее выявляются блокеры и зависимости.

Преимущества Kanban

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

Гибкость планирования

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

Сокращение времени цикла

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

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

В методологии Kanban все члены команды отвечают за то, чтобы рабочие процессы протекали без сучка, без задоринки.

Меньше узких мест

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

К примеру, типичная команда разработчиков ПО может использовать четыре состояния процесса разработки: «Запланировано», «В работе», «Проверка кода» и «Сделано». Для состояния проверки кода можно установить лимит WIP, равный 2. Число может показаться маленьким, но на все есть свои причины: разработчики предпочитают писать собственный код, а не проверять чужой. Низкий лимит стимулирует команду уделять особое внимание задачам в состоянии проверки, а также проверять чужую работу, прежде чем создавать свои задачи на проверку кода. В конечном итоге это сокращает общее время цикла.

Наглядность

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

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

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

Непрерывная поставка

Непрерывная поставка (CD) предполагает частую поставку релизов продукта клиентам. Непрерывная интеграция (CI) — это практика инкрементной автоматизированной сборки и тестирования кода в течение дня. Вместе они образуют конвейер CI/CD, без которого сложно обойтись командам разработчиков (особенно командам DevOps), если они хотят быстрее выпускать качественное ПО.

Kanban и CD идеально дополняют друг друга, поскольку обе методики основаны на своевременной (и последовательной) поставке ценности. Чем быстрее команда сможет выпустить инновационное решение на рынок, тем более конкурентоспособным будет ее продукт. Kanban-команды сконцентрированы именно на оптимизации процесса поставки продуктов клиентам.

Сравнение Scrum и Kanban

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

Некоторые команды объединяют идеалы Scrum и Kanban в Scrumban. Из Scrum берут роли и спринты фиксированной длительности, а из Kanban — ориентацию на время цикла и лимиты незавершенной работы. Но если ваша команда только начинает использовать Agile, мы настоятельно рекомендуем выбрать одну методологию и некоторое время следовать только ей. Поэкспериментировать вы всегда успеете.

Начало работы с гибким управлением проектами

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

Обзор тем

Что такое гибкое управление проектами?

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

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

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

ЧИТАЙТЕ НИЖЕ

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

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

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

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

Гибкая структура управления проектами 1: Scrum

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

Все начинается с невыполненной работы или объема работы, которую необходимо выполнить. В скраме есть два бэклога: один — бэклог продукта (принадлежит владельцу продукта), который представляет собой список приоритетных функций, а другой — бэклог спринта, который заполняется путем выбора задач из верхней части бэклога продукта до тех пор, пока мощность для следующего спринта достигнута. Скрам-команды имеют уникальные роли, зависящие от их участия в процессе. Обычно в команде есть мастер схватки или сторонник метода схватки; владелец продукта, голос продукта; и команда Scrum, которая часто является межфункциональной командой, отвечающей за выполнение s@#$.

Четыре церемонии схватки

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

Скрам-доска

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

Гибкая структура управления проектами 2: Канбан

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

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

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

Канбан-доска

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

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

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

Оценка проекта Agile

Оценка проекта является чрезвычайно важным аспектом управления проектами как по канбану, так и по методу схватки. Для канбана многие команды устанавливают свой лимит незавершенного производства для каждого штата на основе своего предыдущего опыта и размера команды. Скрам-команды используют оценку проекта, чтобы определить, какой объем работы можно выполнить за конкретный спринт. Многие agile-команды используют уникальные методы оценки, такие как покер планирования, идеальные часы или стори-пойнты, чтобы определить числовое значение для поставленной задачи. Это дает agile-командам точку отсчета, на которую можно ссылаться во время ретроспективы спринта, чтобы увидеть, как их команда выступила. Программное обеспечение Jira можно настроить так, чтобы оно собирало уникальные оценки проектов ваших команд.

Agile-отчетность

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

Управление невыполненными работами и подготовка

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

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

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

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

Используйте шаблон

Клэр Драмонд

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

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

Вклад редакции: Лаурели Маллек, руководитель программы

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

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

Что такое гибкое управление проектами?

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

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

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

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

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

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

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

Модель водопада может усугубить некоторые из известных проблем строительных материалов:

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

Преимущества водопада

• Требуется меньше координации из-за четко определенных фаз последовательных процессов
• Четкая фаза проекта помогает четко определить зависимости работы.
• Стоимость проекта может быть оценена после определения требований
• Лучшее внимание к документации проектов и требований
• Этап проектирования более методичен и структурирован до написания любого программного обеспечения

Недостатки водопада

• Труднее разделить и разделить работу из-за более строгой последовательности фаз. Команды более специализированы.
• Риск потери времени из-за задержек и неудач во время фазовых переходов. функциональный состав команды.
• Дополнительные затраты на связь во время переключения между фазовыми переходами
• Владение продуктом и вовлеченность могут быть не такими сильными по сравнению с agile, поскольку основное внимание уделяется текущей фазе.

Agile против водопада

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

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

Итеративные выпуски открывают для команды множество возможностей:

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

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

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

Принципы Agile

• Agile-проект разбит на несколько поэтапных шагов, которые включают регулярные интервалы обратной связи.
• Требование к проекту разбивается на более мелкие части, которым затем присваивается приоритет по важности.
• Способствует сотрудничеству, особенно с заказчиком.
• Регулярные корректировки для обеспечения удовлетворения потребностей клиента
• Объединяет планирование с исполнением, что позволяет команде эффективно реагировать на меняющиеся требования 0197
• Обозначает проблем раньше
• Более высокий потенциал для удовлетворения потребностей клиентов
• Время выхода на рынок значительно сокращается
• Улучшение прозрачности и подотчетности
• Выделенные команды со временем повышают производительность
• Гибкая расстановка приоритетов, ориентированная на получение ценности

Недостатки Agile

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

Элементы, которые необходимо учитывать при переходе на agile

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

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

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

Дорожные карты

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

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

Требования

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

Журнал невыполненных работ

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

Agile-метрики

Agile-команды добиваются успеха благодаря метрикам. Ограничения незавершенного производства (WIP) позволяют команде и бизнесу сосредоточиться на выполнении работы с наивысшим приоритетом. Графики, такие как диаграммы выгорания и контрольные диаграммы, помогают команде предсказать скорость доставки, а диаграммы непрерывного потока помогают выявить узкие места. Эти метрики и артефакты заставляют всех сосредоточиться на больших целях и повышают уверенность в способности команды выполнять будущую работу.

Agile работает на доверии

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

В заключение…

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

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

Дэн Радиган

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