Когда вы начинаете изучать Agile, может показаться, что вы попали в другую страну. Люди говорят на странном языке, зачастую используя английские термины, измеряют время в сторипойнтах, а их библия — это манифест.
По мере того, как вы будете проводить больше времени с местными жителями мира Agile, вы заметите тонкие различия между его жителями, которые говорят на нескольких разных диалектах. Некоторые используют разные термины для выражения одного и того же понятия, в то время как другие используют одно и то же слово для обозначения разных вещей.
Чтобы помочь вам сориентироваться, мы составили обзор терминологии Agile, разделенный на четыре раздела:
Мы собрали все популярные слова в обзор, и постарались объяснить их простым языком.
Гибкий (Agile) подход - это, прежде всего, философия. Если вы только начинаете изучать методологию Agile, то можете пропустить этот раздел и перейти к более практическим советам, но лишь на некоторое время. Чтобы понять, почему люди делают то, что делают, вам потребуется понять основы.
В 2001 году 17 разработчиков встретились, чтобы определить лучший способ разработки программного обеспечения. Из этой встречи родился манифест Agile. Его принципы вдохновили команды по всему миру создавать новые практики для своей повседневной работы. Некоторые из наиболее важных принципов:
🤷♀️ Распространенные заблуждения
Учитывая широкое влияние, которое он внёс, манифест Agile удивительно краток и не даёт конкретных рекомендаций. Если бы это была карта, она показала бы местонахождение Agile, но не дала бы направлений, как туда попасть.
Несколько известных фреймворков, таких как Scrum и Extreme Programming (XP), не возникли из манифеста, а их создатели уже работали над этими подходами в 90-х годах. Их работа вдохновила некоторые элементы манифеста Agile.
ℹ️ Больше информации
Agile менталитет означает веру в принципы и ценности манифеста Agile и восприятие мира сквозь эту призму. Такой менталитет противоречит традиционным подходам к управлению проектами и организациям, таким как «waterfall (водопад)» и Taylorism (Тейлоризм) (научное управление).
На практике, иметь Agile менталитет означает верить в следующее:
🤷♀️ Распространенные заблуждения
Метафизический термин, подобный "менталитет", легко вызывает скептицизм, особенно в мире менеджеров, которые привыкли к конкретным планам, числам и структурам. Однако, внедрение гибких процессов без гибкого менталитета может привести команду к провалу, именно поэтому некоторые гибкие подходы терпят неудачу.
Принцип Agile — это один из 12 ценностей, определенных в манифесте Agile.
Самые известные и влиятельные из них:
Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
🤷♀️ Распространенные заблуждения
Некоторые гибкие фреймворки, такие как Scrum, определяют свои собственные ценности, но они не являются принципами Agile в прямом смысле этого слова, поскольку они не вытекают из манифеста Agile. Однако, если быть очень догматичным, такие принципы можно считать гибкими, с маленькой буквы “г”, в том смысле, что они следуют духу 12 принципов Agile из манифеста.
Ритм в Agile относится к устойчивому и повторяемому темпу и процессу работы. Идея происходит из одного из 12 принципов Agile:
Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
Необходимость в устойчивом ритме возникает как противоядие против “критического времени”, спешки в последний момент с большим количеством переработки, которая характерна для традиционных программных проектов. Команды могут определить свой ритм в соответствии с продолжительностью спринта.
🤷♀️ Распространенные заблуждения
Некоторые команды обнаруживают, что Agile-фреймворки, такие как Scrum, приводят к переработке, поскольку команды усиленно трудятся, чтобы завершить работу к концу спринта. В таких случаях настоящая проблема часто заключается в том, что команда или организация следуют гибким процессам, но не их ценностям. Например, они могут проводить встречи Scrum, но Cadence и темп работы неподдерживаемы, слишком много работы намечено на каждый спринт.
Постоянное совершенствование означает постоянный поиск способов улучшения рабочих процессов. Джефф Сазерленд, один из создателей Scrum, в своей книге с тем же названием выражает это следующим образом:
«Не стоит просто улучшаться один раз; постоянно улучшайтесь».
Практика постоянного совершенствования происходит из Toyota Production System, разработанной в 1940-х годах в компании Toyota в Японии, и управления Lean. Она также известна как "Кайдзен" на японском, что в переводе означает "хорошее изменение".
Конкретным проявлением этой идеи является встреча Sprint Retrospective (Ретроспектива спринта), которую многие гибкие команды проводят в конце каждого спринта или цикла работы, чтобы обсудить свою работу вместе и найти способы устранения препятствий, сокращения потерь и улучшения рабочего процесса.
Аарон Дигнан, автор книги "Смелая новая работа", прекрасно описывает необходимость постоянного совершенствования:
«Несколько людей изо всех сил пытаются тащить телегу, полную камней, вверх по холму. У телеги удивительно квадратные колеса. Другой человек, который случайно оказался поблизости, предлагает новшество: круглые колеса. "Нет, спасибо!" - говорят они. "У нас слишком много дел". Это ваша команда. Это почти каждая команда, с которой я когда-либо работал... Постоянное совершенствование - это не волшебство; это дисциплина. Это то, что мы делаем. И, как и все ценные вещи, это требует времени. Средняя команда даже не тратит тридцать минут в неделю на размышления о том, как они работают вместе».
Команда, в которой все необходимые навыки для выполнения работы сосредоточены внутри группы. Такой состав снижает узкие места, вызванные зависимостью от других команд. Это также обеспечивает плавный поток работы, так как нет передачи работы между группами.
Например, в традиционных компаниях часто есть отделы продукта, маркетинга и продаж. Гибкая организация соответственно имеет экспертов по продукту, маркетингу и продажам в каждой группе.
Связанный термин: Самоуправляемая команда.
Концепция потока происходит из исследований психолога Михайя Чиксентмихайи, который придумал этот термин в своей книге с таким же названием. Поток — это состояние погружения в сложную деятельность, при котором мы теряем чувство времени и окружающей обстановки. Люди обычно входят в состояние потока, преследуя цель, которая расширяет их способности.
В Agile, в основном используется идея потока в методе Канбан, но с большей близостью к естественному значению слова, как движение воды по реке, в соответствии с определением, которое автор Даниэль Ваканти дает в своей книге "Действенные метрики Agile для прогнозируемости":
«Поток - это движение и доставка ценности для клиента через процесс. В интеллектуальной работе наша основная цель — доставка ценности клиенту. Поэтому логично, что весь наш процесс должен быть ориентирован на оптимизацию потока».
Многие практики Канбан направлены на оптимизацию потока. Ограничение числа элементов, над которыми команда одновременно может работать, является одним из примеров. Другим примером является сама доска Канбан, которая помогает визуализировать рабочий процесс команды, чтобы легко обнаружить узкие места и избыточную сложность в рабочем процессе.
🤷♀️ Распространенные заблуждения
Люди могут ошибочно путать использование понятия "поток" в методе Канбан с исходным определением Чиксентмихайи. Такое заблуждение возникает, когда люди знакомы только с использованием термина "поток" в контексте способности отдельного человека оптимально концентрироваться, а не в контексте плавного движения рабочих элементов через систему, что является основным применением метода Канбан.
Смотрите Continuous improvement.
Подход под названием Lean - это рабочий подход, который максимизирует ценность для клиента, дает командам полномочия, снижает потери и стремится к непрерывному совершенствованию. Одним из ключевых отличий подхода Lean от других гибких способов работы является фокус на доставку в нужное время. Концепция происходит из Toyota Production System и является для производства тем же, что Agile для разработки программного обеспечения.
Эти общие основы не случайны. Практики подхода Lean, унаследованные из производственной отрасли, вдохновили множество принципов Agile и некоторые из его популярных фреймворков, таких как Scrum.
🤷♀️ Распространенные заблуждения
Подход Lean не является гибким фреймворком, и вам не нужно выбирать между подходом Lean или Agile для вашей организации. Когда вы работаете с одним из них, вы почти наверняка используете принципы и практики и другого также.
ℹ️ Больше информации
Самоуправляемая команда - это коллектив, который вместе решает, над чем работать далее, кто работает над этим, когда и как, без вмешательства менеджера. Некоторые Agile-фреймворки, такие как Scrum, явно предписывают, что команды должны быть самоуправляемыми. Манифест Agile этого не делает, но два его принципа на это намекают:
🤷♀️ Распространенные заблуждения
Ранее Scrum Guide относился к командам Scrum как «самоорганизующиеся», что означает, что они могут выбирать только способы выполнения своей работы. В 2020 году Scrum Guide был обновлен, чтобы вместо этого использовать термин «самоуправляемые».
Смотрите Cadence.
Технический долг - это цена, которую команда платит за создание более простых и быстрых решений сейчас вместо более надежного подхода, который займет больше времени для завершения. Технический долг представляет собой дополнительную работу, которую придется выполнить в будущем после выбора более простого решения. Обычно такой долг проявляется через ошибки, которые команде нужно исправить позже, или через архитектуру, которая не масштабируется.
Технический долг является важным понятием в Agile, потому что многие фреймворки, такие как Scrum и XP, специально направлены на устранение или минимизацию его накопления, например, путем включения тестирования и исправления ошибок в определение выполненной работы для спринта или критериев приемки функционала.
Таймбокс - это практика установки строгого временного лимита для определенных активностей. Таймбокс помогает участникам команды сосредоточиться на завершении задач в определенный период времени. Он также часто используется для разделения различных частей Agile-встреч, чтобы обсудить все необходимое.
Таймбокс используется в нескольких Agile-фреймворках двумя способами:
Термин "рабочее программное обеспечение" означает программный продукт, который может быть использован заказчиком или конечным пользователем, в отличие от статической демонстрации или визуализации.
Термин происходит из Agile-манифеста, где одним из ценностей является: "Рабочее программное обеспечение выше исчерпывающей документации". Это предполагает, что частая поставка ценности внешним клиентам предпочтительнее наличия подробной документации для внутренних заинтересованных сторон.
Многие концепции, процессы и результаты Agile непосредственно проистекают из идеи оценки рабочего программного обеспечения, например:
ℹ️ Больше информации
Из Agile философии и менталитета возникли конкретные фреймворки и методологии. Они все общаются в непрерывной итерации рабочих процессов и стремлении доставлять ценность клиентам быстро и часто. Однако каждая из них предлагает свой собственный оттенок гибкости, и полезна в определенных обстоятельствах.
На приведенном выше изображении подчеркивается различие между agile рамками, методологиями и самой философией.
Дисциплинированная гибкая разработка (DAD) — это всесторонняя коллекция стратегий и практик, взятых из гибких фреймворков и других методологий, таких как Lean и Waterfall. Можно представить ее как меню "а ля карт", в то время как Scrum — это фиксированное трех-блюдное меню.
DA предоставляет командам знания и инструменты для выбора гибких практик и создания персонализированного подхода к их ситуации. DA гораздо менее предписывающая, чем большинство других фреймворков. Это хороший вариант для организаций, которые считают Scaled Agile Framework Enterprise (SAFe) слишком громоздким, а другие масштабируемые фреймворки — слишком легкими.
DevOps занимается важными техническими аспектами разработки программного обеспечения, включая инфраструктуру (серверы + сетевое взаимодействие), развертывание (сборка + тестирование + обновление), мониторинг, контроль качества (обнаружение ошибок, нарушений безопасности, проблем производительности и т. д.).
Некоторые люди называют DevOps фреймворком или методологией. На самом деле, это скорее дисциплина или компетенция, подобная маркетингу или дизайну.
DevOps является важным элементом гибкой разработки программного обеспечения, поскольку он помогает командам быстро и часто выпускать работающее программное обеспечение для клиентов. Это возможно только при условии наличия технической инфраструктуры и процессов, способных обеспечить это. DevOps, сфокусированный на инфраструктуре, обеспечивает это.
ℹ️ Больше информации
🤷♀️ Распространенные заблуждения
Некоторые люди считают DevOps фреймворком, тесно связанным с XP и Kanban. Однако он больше похож на дисциплину. Добавление DevOps в список Agile-фреймворков похоже на сравнение Scrum-фреймворка с такой дисциплиной, как Design.
Kanban использует центральную доску с колонками для визуализации рабочего процесса команды. В самой базовой реализации доска содержит как минимум три колонки: "Задачи в очереди" (либо Backlog), "В процессе" и "Готово". Карточки, представляющие задачи, перемещаются через эти колонки в зависимости от их статуса. Когда участник команды завершает предыдущую задачу, он выбирает новую задачу сверху колонки "Задачи в очереди".
Kanban более гибок, чем большинство других agile-фреймворков, потому что вы можете добавлять или менять приоритеты задач в любое время. Kanban подходит для команд, которым необходимо быстро реагировать на входящие запросы или у которых быстро изменяются требования к продукту.
🤷♀️ Распространенные заблуждения
Kanban - это не просто доска с карточками. Это фреймворк со своими собственными правилами, основанный на концепциях, таких как системы "тянущего" производства, теория очередей и поток работ. При использовании Kanban, например, участники команды ограничивают количество задач в колонках "В процессе" или "Выполняются" для избегания перегрузки и выявления узких мест.
В LeSS многочисленные agile-команды работают как единое целое, чтобы создать совместный поставляемый продукт. Например, вы создаете комплексное мобильное приложение. В LeSS каждая команда отвечает за свою отдельную часть продукта, но приложение выпускается вместе в одной общей поставке в конце каждого Спринта.
LeSS является легкой альтернативой SAFe. Он хорошо работает для организаций с множеством автономных команд, которые уже используют процесс Scrum и сотрудничают над одним большим продуктом или доставкой. Он упрощает масштабирование Scrum.
🤷♀️ Распространенные заблуждения
В то время как обычные команды Scrum используют один Product Backlog на каждую команду, организации, использующие LeSS, имеют один Product Backlog и одного Владельца продукта для всего продукта во всех отдельных командах.
SAFe более детализирован, чем другие фреймворки, и предлагает решение для вызова масштабирования процессов Agile. Он объединяет элементы Agile, Lean-управления и системного мышления в модули.
Он также включает в себя традиционные практики управления, например, квартальный плановый процесс. SAFe оставляет меньше места для экспериментов внутри команд, поэтому некоторые практики Agile считают его только частично Agile, а другие считают его противоречащим Agile.
🤷♀️ Распространенные заблуждения
SAFe - это огромный и масштабный фреймворк. Он часто наиболее привлекателен для людей на высших уровнях организации - руководителей и программных менеджеров, потому что он предлагает ощущение контроля. Однако это ощущение контроля часто достигается за счет того, что команды и организация не становятся по-настоящему гибкими.
Scrum - самый популярный фреймворк Agile, используемый 66% Agile-команд.
В рамках Scrum команды работают в циклах, называемых Спринтами, которые создают устойчивый ритм регулярного выпуска маленьких, ценных инкрементов работы. Scrum также предоставляет возможность для размышлений и адаптации через Ретроспективы Спринта, которые помогают командам практиковать непрерывное улучшение. Команды Scrum организуют своих участников по трем различным ролям - разработчики, создающие продукт, Владелец Продукта, определяющий приоритеты работы, и Скрам-мастер, помогающий команде понять и практиковать Scrum.
Легковесный фреймворк Scrum дает командам достаточно инструкций, чтобы быстро начать работу, но не настолько, чтобы они ощутили перегрузку. Это отличный способ начать работу с Agile, особенно для небольших организаций.
🤷♀️ Распространенные заблуждения
Термины Scrum и Agile используются взаимозаменяемо даже людьми, практикующими Scrum, что вносит путаницу. Agile — это о том, почему и что улучшать в разработке программного обеспечения, в то время как Scrum — это о том, как это делать.
Scrumban сочетает в себе Scrum и Kanban. Нет "официального" или прописанного руководства о том, какие части Scrum и Kanban составляют Scrumban, поэтому командам предоставляется возможность выбирать элементы, которые наилучшим образом служат им.
Почти все команды, принимающие Scrumban, обычно сохраняют доску Kanban и ограничивают WIP. Большинство практиков Scrumban также внедряют рабочий цикл, который принимает Спринты и другие события Scrum для создания ритма.
Scrumban идеально подходит для команд с опытом в Agile, которые считают Scrum слишком жестким или Kanban слишком свободным.
🤷♀️ Распространенные заблуждения
Поскольку нет формального руководства о том, что считается Scrumban и что нет, существуют разные интерпретации того, что включает в себя этот подход. Некоторые утверждают, что есть правильный и неправильный способ применения Scrumban. Игнорируйте подобные заявления и занимайтесь работой, которая имеет значение, чтобы найти элементы из обоих подходов, которые работают для вашей команды и приносят наибольшую ценность вашим клиентам.
Модель Spotify отличается от других фреймворков путем организации команд в матричной структуре. Команды называются "Сквады" и могут выбирать свой собственный гибкий метод работы, такой как Scrum или Kanban. Связанные Сквады организуются в более крупные группы, называемые "Tribes (Племена)". У каждого Племени есть Владелец продукта, Agile-коуч и Технический лидер.
К этой структуре Squads (Сквадов) и Tribes (Племен) модель Spotify добавляет "Chapters (Главы)" и "Guilds (Гильдии)". Это группы людей с одной компетенцией, например, тестировщики, маркетологи или разработчики программного обеспечения.
Модель Spotify является альтернативой SAFe, потому что она не является чрезмерно предписывающей, но все же предоставляет достаточное руководство по организации большого количества команд.
🤷♀️ Распространенные заблуждения
Модель Spotify имеет ярых критиков, потому что она была разработана для конкретной организации в определенный момент времени. Сам Spotify отказался от этой модели. Но хотя копирование и внедрение данной рамки в точности может быть неудачным решением, другие организации, такие как ING, нашли много ценности в матричной структуре глав и цехов.
В рамках Scrum о Scrum'ах каждая команда сохраняет свои существующие элементы Scrum — Product Backlog, встречи и обязанности, но представители каждой команды встречаются раз в день на так называемом SoS. В ходе этой встречи они обсуждают предстоящую работу, чтобы создать общее понимание на уровне группы и управлять зависимостями между командами.
Scrum о Scrum'ах подходит для команд, которые выходят за рамки Scrum и нуждаются в дополнительном уровне координации между ними, но не требуется много другого. Scrum о Scrum'ах отлично подходит для организаций, которые хотят сохранить Scrum на индивидуальном уровне команд.
🤷♀️ Распространенные заблуждения
Scrum о Scrum'ах отличается от LeSS тем, что каждая команда сохраняет свой собственный Product Backlog, обязанности и встречи. В то время как в LeSS несколько команд работают с одним общим Product Backlog и Владельцем продукта.
XP - это гибкая методология, которая улучшает проекты по разработке программного обеспечения благодаря набору определенных ценностей и технических практик. Как и Scrum, она подчеркивает включение заказчиков в весь процесс, предусматривает работу в циклах продолжительностью от одной до двух недель с частыми релизами и планировочными сессиями, а также включает в себя ежедневные дэйли митинги в начале каждого дня.
Одним из важных отличительных черт XP является парное программирование. Команды смешанного состава, включая начинающих и более опытных разработчиков, могут найти это ценным. XP появилось раньше манифеста Agile.
🤷♀️ Распространенные заблуждения
Наиболее отличительные ценности и технические практики, которые делают XP отличным от Scrum, включают парное программирование, разработку через тестирование и непрерывную интеграцию.
Повседневная жизнь и работа Agile-команд вращается вокруг конкретных обязанностей, различных типов встреч и оптимизированных рабочих процессов. Некоторые из них различаются в зависимости от Agile-фреймворка или вообще не используются в конкретной модели. Но этот список охватывает все, что вам нужно знать, чтобы понять Agile роли, встречи и процессы, независимо от того, используете ли вы их в своей организации или нет!
Приемочное тестирование — это процесс, в котором проходит заинтересованная сторона, чтобы убедиться, что новая функция работает и ведет себя так, как ожидается, прежде чем она будет запущена в продуктовую среду (продакшен). Приемочные тесты помогают командам выявлять любые проблемы, а также получать отзывы о продукте с точки зрения клиента или конечного пользователя до его запуска.
🤷♀️ Распространенные заблуждения
Приемочные тесты должны проводиться заказчиком или конечным пользователем. Это не внутренние тесты и не QA-тесты для поиска ошибок. Вместо этого они определяют, построила ли команда то, что ожидал получить заказчик.
Оценка сходства — это метод, который команды используют для оценки того, сколько усилий требуется для завершения пользовательской истории. При оценке сходства члены команды сначала ранжируют пользовательские истории или другие рабочие элементы от больших к меньшим или помещают их в сегменты разного размера. Как только это будет сделано, члены команды назначают более конкретные оценки, такие как баллы или размеры футболок. Это эффективный подход для быстрого прохождения большого количества неоцененных элементов бэклога продукта.
🤷♀️ Распространенные заблуждения
Оценку сходства часто путают с относительной оценкой. Но оценка сходства — это особый подход к относительной оценке.
Антипаттерн — это, казалось бы, очевидный, но неправильный ответ на распространенную проблему. Это неэффективное решение, часто с негативными последствиями. Простой пример — «Смерть от планирования» — вера в то, что большее планирование приведет к меньшему риску и, следовательно, к лучшему или более предсказуемому результату проекта.
Agile команды могут выполнять специальные упражнения для выявления антипаттернов или «плохих привычек» в своей работе. Agile-коучи или Scrum-мастера также могут работать с командами над устранением встроенных антипаттернов.
Антоним антипаттерна — это шаблон проектирования, простое и эффективное решение распространенной проблемы.
Грумминг бэклога — это процесс управления, определения приоритетов и добавления деталей к элементам в бэклоге продукта с использованием различных методов приоритизации и оценки, таких как размер футболки, WSJF или оценка покером. Это непрерывный процесс, в котором сотрудничают владелец продукта и разработчики.
Грумминг бэклога помогает командам разработать более детализированный бэклог продукта, который содержит всю необходимую информацию для достаточной детализации каждого элемента.
Во время уточнения бэклога многие команды решают добавить оценки в историях и, когда отдельные элементы бэклога продукта слишком большие, их могут разбить на более мелкие, более управляемые части с четким списком определенных задач.
Грумминг бэклога позволяет командам иметь более ясные приоритеты, улучшенную скорость спринта и более реалистичное представление о том, сколько работы можно взять на следующий спринт.
Команда сама решает, когда проводить грумминг бэклога, как часто проводить такие встречи и какие методы использовать для грумминга.
Церемония — это причудливое слово для Agile-встречи:
Термин "церемония" охватывает различные практики Agile, от событий Scrum до практик, таких как оценка покера или еженедельные циклические собрания из XP, или собрания наполнения задач в Канбан.
🤷♀️ Распространенные заблуждения
Не совсем ясно, откуда появилось использование термина "церемония" в Agile. Некоторые говорят, что в Scrum Guide 2011 года термин был заменен на "события", тогда как другие - и наши собственные исследования - предполагают, что слово "церемония" даже не появлялось в первом официальном Scrum Guide 2010 года.
Единственное упоминание "церемонии" можно найти в книге "Scrum", написанной одним из ее создателей, Джеффом Сазерлендом. Он использует этот термин, ссылаясь на "хака", церемонию маори-воинов, которую сборная Новой Зеландии по регби "All Blacks" исполняет перед каждым матчем.
Для еще большей путаницы люди часто используют термин "Agile-церемонии", когда на самом деле они имеют в виду пять событий Scrum без учета спринта. 🤯
Непрерывная интеграция — это когда разработчики интегрируют код в кодовую базу команды не реже одного раза в день. Хотя это кажется несущественной практикой разработчиков, она способствует применению принципов Agile.
Когда вы ежедневно выкатываете в продакшен свой код, вы должны разбить свою работу на небольшие куски и не можете откладывать её на потом. А также, когда ваша команда часто выпускает обновления, вы активируете цикл обратной связи с клиентами по программному обеспечению.
🤷♀️ Распространенные заблуждения
Люди иногда путают непрерывную интеграцию с непрерывной доставкой. Но при непрерывной доставке обновленная кодовая база для всего продукта также регулярно выпускается для конечных пользователей.
Daily Scrum — одно из пяти официальных мероприятий Scrum. Это 15-минутное совещание, которое каждый рабочий день спринта проводится в одно и то же время и в одном и том же месте командой разработки. Большинство команд встают во время ежедневного скрама, чтобы он был коротким. Вот почему многие называют это ежедневной встречей стендапа.
Цель ежедневного скрама — сосредоточить команду на цели спринта и уменьшить потребность в других встречах. Во время ежедневных сборов команда может обмениваться информацией о своей работе, корректировать свои планы и участвовать в быстром решении проблем, чтобы разблокировать друг друга.
85% agile-команд проводят ежедневные стендап-встречи, и, как и в спорте, команда должна выйти из совещаний с чувством энергии и ясности в отношении стратегии и тактики для дневного «матча».
🤷♀️ Распространенные заблуждения
В отличие от предыдущих версий руководства по Scrum, издание 2020 года больше не предписывает задавать эти три вопроса во время встречи:
Вместо этого команды сами решают, как они хотят структурировать свои собственные встречи Daily Scrum или Daily Standup.
Определение готовности (DoD) определяет стандарты, которым должен соответствовать каждый элемент в бэклоге спринта, чтобы Инкремент считался выполненным. Он применяется ко всем задачам или пользовательским историям, которые вместе образуют один Инкремент.
Вот пример:
Согласно руководству по Scrum, «если элемент бэклога продукта не соответствует определению готовности, он не может быть выпущен или даже представлен на обзоре спринта. Вместо этого он возвращается в бэклог продукта для дальнейшего рассмотрения».
Команды обычно устанавливают DoD на уровне команды, но рекомендуется применять один и тот же DoD к нескольким командам, если они работают над одним и тем же продуктом.
🤷♀️ Распространенные заблуждения
Люди часто путают определение готовности и критерии приемки, но DoD применяется на уровне бэклога продукта, а критерии приемки применяются к отдельным элементам бэклога.
Итерация — это цикл выполнения, то, что вы постоянно делаете. Часто, когда некоторые практики Scrum используют без дополнительного контекста, итерация относится к одному спринту.
🤷♀️ Распространенные заблуждения
«Итерация» и «Инкремент» иногда путают. Но в Scrum инкремент — это результат — часть работающего программного обеспечения — результат одной итерации.
Парное программирование — это когда два разработчика работают вместе за одним компьютером для решения задач и обмена знаниями. Эта концепция восходит к фреймворку Extreme Programming (XP). Сторонники XP говорят, что эта практика приводит к более качественным решениям и уменьшает количество ошибок, потому что два разума обдумывают проблемы, а не один.
В книге «Мир без электронной почты» давний программист Кремниевой долины Грег Вудворд говорит:
«Непросвещенные менеджеры могут подумать, что вы получите пятьдесят процентов производительности, если два разработчика будут работать над одним и тем же на одном компьютере… На самом деле вы получаете в три-четыре раза больше производительности».
Причина, по словам Вудворда, в том, что вместе вы находите лучшие решения проблем, что является сутью программирования, прежде чем приступить к фактическому кодированию.
Покер планирование — это гибкий метод оценки задач и проектов. Команды собираются вместе, чтобы оценить, насколько велики или малы различные рабочие элементы, используя набор покерных карт с присвоенными им различными значениями.
При покер планировании команды просматривают выборку пользовательских историй или задач из бэклога продукта. Затем каждый участник индивидуально оценивает, сколько усилий потребуется для этого рабочего элемента, играя в карты с разными значениями из настроенной колоды.
Каждый выбирает свою карту анонимно, а затем все они раскрываются одновременно. Далее следует обсуждение оценок каждого, чтобы команды могли прийти к единому мнению относительно усилий, необходимых для выполнения части работы. 58% Agile-команд сообщают, что они проводят покерную оценку.
Владельцы продукта разрабатывают и поддерживают видение продукта — какие проблемы он решает и для кого. Владелец продукта представляет голос клиента и бизнеса в процессе Scrum. Они проводят много времени с обеими сторонами, чтобы понять их потребности.
Владелец продукта отвечает за постоянное обновление и расстановку приоритетов в бэклоге продукта, а также за решение того, что команда будет создавать дальше.
Владелец продукта также дает заинтересованным сторонам представление о том, над чем работает команда, сейчас и в ближайшем будущем, поскольку заинтересованные стороны могут обращаться к бэклогу продукта, за который отвечает владелец продукта. Поддержание журнала невыполненных работ в актуальном состоянии также имеет решающее значение для обеспечения достаточной детализации и актуальности элементов для каждого совещания по планированию спринта.
🤷♀️ Распространенные заблуждения
Термины «Владелец продукта» и «Менеджер продукта» иногда путают, потому что в крупных организациях могут использоваться оба термина. В этом случае роль владельца продукта отчитывается перед менеджером по продукту (PM). Затем PM обычно управляет видением, потребностями клиентов и бизнеса. PO фокусируется только на бэклоге продукта и работе с командой разработчиков, чтобы воплотить видение продукта в реальность.
Обеспечение качества (QA) — это процесс предотвращения ошибок и дефектов в продуктах или услугах, которые вы предоставляете. В негибкой среде такая профилактика выполняется в конце производственного процесса специальной группой контроля качества.
В agile-команде QA — это непрерывный процесс, за который отвечает каждый или хотя бы один член команды. Такой подход позволяет командам брать на себя ответственность за качество своей работы, а не передавать ее другому отделу, что часто приводит к небрежной работе. Непрерывный контроль качества также помогает командам избежать накопления технического долга.
Относительная оценка — это метод оценки сторипойнтов. Относительная оценка включает в себя оценку размера рабочего элемента путем сравнения его с другим, а затем присвоение ему значения, такого как сторипойнты или размер футболки.
Это звучит примерно так: «Если эта задача 2-го размера, то эта наверняка должна быть 4-го размера, так как она в два раза сложнее». Относительная оценка намного проще и быстрее, чем другие методы, когда команде необходимо сделать оценки на основе неполной информации или непредсказуемых зависимостей от других задач и членов команды.
🤷♀️ Распространенные заблуждения
Оценка на основе времени естественна для большинства людей. Мы постоянно оцениваем абсолютные значения — сколько что-то может стоить, весить или сколько времени потребуется, чтобы добраться из точки А в точку Б.
Из-за этой привычки члены команды могут давать «относительную» оценку, сначала вычисляя время в уме, вместо того, чтобы действительно учитывать сложность задачи, сравнивая ее с другим элементом по шкале, не основанной на времени.
В каждую Скрам-команду входит один Скрам-мастер. Скрам-мастер помогает команде практиковать Скрам, подсказывая им, как работать вместе более эффективно и постоянно улучшать свои рабочие процессы. Скрам-мастер является экспертом по Скраму и выступает в роли тренера, который обучает, помогает и защищает процесс Скрама.
Скрам-мастер защищает команду, помогая решать проблемы и устраняя препятствия, находящиеся вне его контроля. Скрам-мастера также обучают и тренируют более широкую организацию по внедрению Скрама, чтобы помочь командам стать самоуправляемыми.
🤷♀️ Распространенные заблуждения
Некоторые Скрам-мастера недостаточно расширяют возможности команды посредством обучения и коучинга, чтобы взять на себя процесс Скрама. Вместо этого они делают процесс зависимым от себя, обычно беря на себя — и сохраняя — контроль над ведением собраний и другими командными ритуалами.
ℹ️ Больше информации
Смотрите Ceremonies.
Скрам-команды распределяют своих участников по трем разным ролям: разработчики, владелец продукта и скрам-мастер. Группа является самоуправляемой и многофункциональной, поэтому у них есть все навыки для выполнения своей работы. Обычно Scrum-команда состоит из трех-девяти человек без каких-либо подкоманд или иерархий.
🤷♀️ Распространенные заблуждения
В последнем издании Руководства по Scrum роли и обязанности команды Scrum называются «ответственность».
Спринты — это двух-четырехнедельные циклы работы, в течение которых Agile-команды завершают элементы в Журнале Спринта, чтобы создать Инкремент продукта и получить отзывы заинтересованных сторон. Каждый спринт включает в себя несколько мероприятий, часто называемых «церемониями», которые устраняют необходимость в других встречах, добавляя ритм и структуру в рабочий процесс.
Смотрите Sprint Review.
Во время планирования спринта Agile-команды берут на себя задачи, которые они будут выполнять в предстоящем спринте. Они делают это, перемещая элементы из бэклога продукта в бэклог спринта.
Когда команда выбирает задачи для спринта, они уточняют, что означает каждый пункт и кто будет над ним работать. Планирование спринта завершается, когда команда считает, что выбранная работа примерно соответствует тому, чего они могут достичь в ходе одного спринта.
Совещание по планированию спринта происходит в начале спринта. Двухнедельный спринт может длиться от одного до двух часов.
🤷♀️ Распространенные заблуждения
Планирование спринта — это не то же самое, что совещание по оценке задач/пользовательских историй. Хотя команды могут принять решение провести некоторую оценку задач во время планирования спринта, обычно это происходит постоянно — посредством уточнения невыполненной работы. Команды также могут провести отдельное совещание по оценке задач в рамках совещания по уточнению невыполненной работы. Многие команды предпочитают делать это после ретроспективы спринта и перед собранием по планированию спринта.
Ретроспектива спринта — это встречи, на которых Agile-команды собираются вместе, чтобы проанализировать свою работу и определить улучшения процессов. Ретроспективы Спринта проводятся в конце каждого cпринта. Во время hетроспективы cпринта рабочие отношения, взаимодействие, процессы, инструменты — все это подлежит рассмотрению и обсуждению.
Ретроспектива спринта помогает командам выработать привычку к постоянному совершенствованию.
Все члены команды сначала предлагают темы для обсуждения, обычно записывая свои мысли на карточках для размышлений. Затем они объединяют их в общие темы, и вся команда голосует за то, какие из них они хотят обсудить.
🤷♀️ Распространенные заблуждения
Как и ревью спринта, ретроспектива спринта проводится в конце спринта. Но его внимание сосредоточено на улучшении процессов, тогда как обзоры спринтов сосредоточены на продукте.
ℹ️ Больше информации
На Sprint Review команда Scrum демонстрирует то, что они достигли в течение спринта. Sprint Review происходит в конце спринта, перед ретроспективой спринта.
Во время Sprint Review команда собирает обратную связь от заинтересованных сторон по их работе. В ходе этого собрания вы определите, достигли ли вы цели спринта, и обсудите, как дальше улучшать продукт в будущих спринтах.
Работа, продемонстрированная во время Sprint Review, должна быть рабочим программным обеспечением. Поэтому Sprint Review иногда называют Sprint Demo.
Sprint Review позволяет заинтересованным сторонам давать обратную связь рано и часто, а не редко и поздно.
🤷♀️ Распространенные заблуждения
Некоторые команды сводят Sprint Review к простому демонстрированию проделанной работы. Хотя демонстрация рабочего программного обеспечения является основой этого собрания, правильный Sprint Review оставляет место для обсуждения и времени для взгляда вперед с заинтересованными сторонами (стейкхолдерами).
ℹ️ Больше информации
Заинтересованный сторонник (stakeholder) – это любой человек вне команды Agile, которому интересен и на которого оказывает влияние конечный продукт. Клиенты являются наиболее важными заинтересованными сторонами, но также примерами могут быть руководители, инвесторы и команды по продажам.
🤷♀️ Распространенные заблуждения
Владелец продукта (Product Owner, PO) не является заинтересованной стороной, а является членом Agile-команды, хотя владелец продукта представляет взгляды заинтересованных сторон в продуктовом видении.
Story mapping – это процесс организации пользовательских историй в порядке, в котором пользователь наиболее вероятно с ними столкнется – фактически следуя пути пользователя.
Предположим, вы создаете карту для процесса регистрации и входа нового клиента. Вы бы сгруппировали все истории, связанные с регистрацией пользователя, обычно слева на доске, а затем те, которые связаны с подтверждающим электронным письмом, которое пользователь должен щелкнуть, справа от них, и так далее. Story mapping позволяет Agile-командам визуально разбить весь путь клиента или пользователя.
Команды могут выполнять картографирование историй цифровыми средствами или организовывать физические карточки на стене, на доске или на полу.
Story splitting (или разделение историй) – это процесс преобразования одной большой пользовательской истории в несколько меньших историй. Эта практика полезна по нескольким причинам:
Разделение историй обычно является частью процесса грумминга бэклога. Команды также могут обнаружить, что история слишком большая во время упражнений, таких как покер планирование, оценка схожести или относительная оценка.
🤷♀️ Распространенные заблуждения
Хотя разделение историй – это простая концепция, даже опытные команды часто создают истории, которые можно было бы разделить на более мелкие. Существуют несколько методов, которые помогают в этом, такие как метод гамбургера и даже диаграмма разделения историй.
Практики Agile называют конкретные входы и выходы своей работы артефактами. И поскольку Agile отличается от других подходов к работе, сотрудничеству и управлению, команды Agile измеряют свои артефакты и производительность с помощью ряда необычных метрик.
Критерии приемки определяют, как проверить завершенность задачи или пользовательской истории. Вот пример из нашего бэклога продукта:
Когда пользователь авторизовывается с еще не подтвержденного адреса электронной почты, Retrius отображает сообщение об ошибке, и просит подтвердить email.
Критерии приемки обычно документируются внутри каждого элемента бэклога и часто выглядят как список критериев, которым должен соответствовать продукт, прежде чем задача может быть считаться завершенной.
🤷♀️ Распространенные заблуждения
Поскольку критерии приемки и определение готовности (Definition of Done, DoD) оба определяют, когда что-то считается завершенным и при каких условиях, люди часто используют эти термины взаимозаменяемо. Однако критерии приемки применяются на уровне задачи и пользовательской истории, в то время как DoD применяется к целой итерации - таким образом, ко всем завершенным функциям в рамках одной спринтовой итерации.
Бэклог - это упорядоченный список работ, поддерживаемый Agile-командой. Существуют два типа бэклогов: Бэклог продукта (Product Backlog), который представляет собой список всех потенциальных работ, которые могут быть выполнены, и Бэклог спринта (Sprint Backlog), который включает все задачи, запланированные для выполнения в текущей спринтовой итерации. Бэклог продукта управляется Владельцем продукта (Product Owner), в то время как бэклог спринта управляется командой Разработчиков и Скрам-мастером.
Если дорожная карта продукта сообщает команде, куда стремится продукт, то бэклог представляет собой приоритизированный список всех работ, необходимых для достижения этой цели.
Бэклог помогает команде понять, что является важным, и создает прозрачность относительно следующих работ. Бэклог определяет и приоритизирует все индивидуальные усилия, необходимые для достижения различных целей и вех. За составление бэклога продукта отвечает Владелец продукта.
🤷♀️ Распространенные заблуждения
Существуют два типа бэклогов: Бэклог продукта (Product Backlog) и Бэклог спринта (Sprint Backlog). Бэклог продукта содержит все идеи, которые могут быть реализованы для вашего продукта. Бэклог спринта содержит только элементы, которые вы выбрали из бэклога продукта для выполнения в рамках одной спринтовой итерации. Люди часто путают Бэклог продукта и Бэклог спринта, потому что оба используют термин "бэклог".
Также легко перепутать Бэклог продукта и дорожную карту продукта. Дорожная карта продукта сообщает команде на высоком уровне, что им нужно создать и почему. Бэклог продукта показывает, как достичь целей дорожной карты продукта.
График снижения остатка показывает, сколько историй (story points) команда завершила и сколько осталось, и обычно строится на протяжении спринта ("График снижения остатка спринта"). Обычно на графике также отображается "идеальная линия снижения остатка", которая показывает прогресс, к которому команда стремится, чтобы завершить работы к концу спринта или другого периода отчетности.
Команды также могут использовать эти графики для отображения данных из предыдущих спринтов. Те же самые графики могут быть использованы на разных масштабах для отслеживания прогресса в выполнении эпика. В этом случае он называется графиком снижения остатка эпика.
🤷♀️ Распространенные заблуждения
График снижения остатка показывает только, сколько историй команда завершила и сколько осталось. Например, он не предоставляет контекста о том, были ли завершены наиболее важные элементы или почему были добавлены новые элементы в Backlog. График снижения остатка сам по себе не достаточен для определения того, насколько хорошо команда выполняет свою работу. Однако он может служить инструментом для обнаружения проблем или явлений, которые требуют дальнейшего изучения.
График увеличения движется в противоположном направлении по сравнению с графиком снижения остатка (Burndown chart): вверх. Он имеет линию, отображающую количество завершенных историй (story points), а также линию, отображающую количество оставшихся историй.
График увеличения лучше визуализирует изменения объема работ по сравнению с графиком снижения остатка. Предположим, что во время периода, который вы отслеживаете на вашем графике, был добавлен новый элемент объемом 20 историй. В графике увеличения (Burnup chart) такое изменение будет отображено в виде всплеска на графике, как показано на синей линии в приведенном выше примере.
В графике снижения остатка (Burndown chart) такое изменение будет учтено в линии, представляющей оставшиеся истории. Предположим, что в тот же день, когда было добавлено 20 историй, вы завершили 30 историй. Ваш график снижения остатка будет уменьшаться только на 10 историй в этот день (30 - 20), что может создать впечатление, что ваша команда менее продуктивна, чем на самом деле.
Эпик - это большая пользовательская история, которая разбивается на несколько более мелких пользовательских историй. Эпик может представлять собой отдельную функциональность в вашем продукте, в то время как пользовательские истории внутри этого эпика разбивают цель эпика на более мелкие задачи.
Команды используют эпики в Product Backlog, чтобы отслеживать более крупные, часто высокоуровневые идеи. Когда команды готовы к более детальной проработке, они разбивают эпики на более мелкие пользовательские истории, которые могут быть выполнены в рамках одной итерации.
Эпики могут охватывать несколько спринтов и изменяться в процессе на основе отзывов пользователей и другой информации, собранной командой.
🤷♀️ Распространенные заблуждения
У эпиков нет строго установленного формата, поэтому вам нужно определить свой собственный формат. Разные команды могут иметь совершенно разные подходы и структуру для своих эпиков.
ℹ️ Больше информации
Оценка в Agile - это приближенная оценка разработчиков команды по объему работы, который может потребоваться для завершения user story или задачи. В отличие от оценок в неагильных рабочих средах, которые часто дают люди, не выполняющие фактическую работу, такие как менеджеры, оценки в Agile все равно являются обязательными.
Agile предлагает различные уникальные методы оценки и измерения, чтобы быстрее получить более точные оценки, чем в традиционных методах планирования. Некоторые из наиболее популярных методов включают покер планирования, относительную оценку и оценку аффинитета.
🤷♀️ Распространенные заблуждения
Даже в Agile рабочих средах оценки иногда рассматриваются как обязательства или сроки. И некоторые в Agile-сообществе считают, что все оценки являются формой ресурсов, поскольку они не создают ценности для клиента. Это мнение привело к движению #NoEstimates, которое призывает отказаться от оценок полностью.
Последовательность Фибоначчи - это ряд чисел, растущих экспоненциально, поскольку каждое число является суммой двух предыдущих чисел: 0, 1, 2, 3, 5, 8, 13, 21 и так далее.
Agile-команды часто используют последовательность Фибоначчи для оценки "размера" задач и пользовательских историй для предстоящего спринта. Цель Фибоначчи заключается в том, чтобы ускорить процесс оценки более крупных и сложных задач, избегая траты времени на мелкие различия.
Предположим, что вашей команде необходимо оценить усилия, требуемые для большой задачи в Product Backlog, например, добавление новой функции в ваше приложение. Предположим, что вы оцениваете свои истории по шкале от 1 до 50. Когда вы обсуждаете элемент Product Backlog с командой, один выбирает 31, другой 36, а третий 38. Когда разница между каждой оценкой составляет только одно целое число, сложно делать уверенные оценки. Похоже, что оценки должны быть очень точными.
С помощью чисел Фибоначчи такой ситуации можно избежать, поскольку последовательность заставляет вас выбирать числа с более широким расстоянием между ними. В этом примере все, вероятно, выбрали бы число 34 в последовательности Фибоначчи, поскольку альтернативы состояли бы из чисел 21 или 55.
🤷♀️ Распространенные заблуждения
Часто Фибоначчи путаются со Story Points. Хотя эти два понятия тесно связаны - команды обычно оценивают рабочие элементы с помощью Story Points, следующих шкале Фибоначчи, - вы можете использовать одно без другого.
Препятствие - это то, что блокирует или замедляет прогресс команды в Agile. Это может быть ненужное совещание, техническая проблема или недостаток в предоставлении команде полномочий для принятия решений. Препятствием является буквально любое препятствие для работы команды.
Поскольку Agile стремится минимизировать потери, удаление препятствий является основной задачей для команд Agile. Устранение препятствий является одной из основных обязанностей Scrum-мастера и общей целью ретроспективных встреч.
Инкремент - это небольшая часть работающего продукта, которым может воспользоваться клиент. Основной фокус большинства методологий Agile состоит в создании небольших инкрементов работающего программного обеспечения на каждом спринте.
Результатом выполнения всех элементов бэклога спринта обычно является выпуск программного обеспечения или обновление продукта, которое называется инкрементом. Многие команды также называют этот результат "целью спринта".
Канбана доска - это динамическая доска с колонками, предназначенная для визуализации состояния работы команды. В ее наиболее простой реализации доска содержит как минимум три колонки - «Бэклог», «В процессе» и «Готово». Индивидуальные карточки задач перемещаются по этим колонкам в зависимости от их статуса. Некоторые команды также добавляют колонку «Застрял», чтобы обозначить задачи, требующие разблокировки.
Основным требованием для эффективной доски Канбана является наличие колонки для каждого этапа рабочего процесса команды. При такой настройке доска помогает выявлять узкие места и способствует упрощению рабочего процесса. Она также способствует прозрачности, поскольку каждый может видеть, над чем работает команда и где члены команды могут застревать.
🤷♀️ Распространенные заблуждения
Доска Канбана не является исключительной для методологии Канбан. Несколько других гибких методологий также часто используют доску Канбана для отражения статуса элементов работы, например, Scrum и Scrumban.
Смотрите Backlog.
PBI — это отдельный рабочий элемент в вашем Бэклоге Продукта.
Примеры элементов Бэклога Продукта включают:
План релиза - это обзор функций, которые планируется включить в один или несколько предстоящих релизов. Он может включать обратную связь от предыдущих итераций и графики временных рамок для будущих релизов.
🤷♀️ Распространенные заблуждения
Некоторые практики Agile считают план релиза слишком жестким и формой излишества, утверждая, что Бэклог продукта в сочетании с регулярным планированием спринта предоставляет достаточное направление для команды разработки, одновременно позволяя реагировать на изменяющиеся потребности клиента.
См. Доску Канбан, поскольку практически нет разницы между доской Scrum и доской Канбан, за исключением описанного ниже недопонимания.
🤷♀️ Распространенные заблуждения
Фреймворки Scrum и Kanban используют доску по-разному и применяют свои собственные правила. Канбан, например, обычно устанавливает ограничение на количество элементов работы, которые могут быть в процессе выполнения одновременно. Scrum использует новую доску для каждого спринта, тогда как в Канбан работа продолжается без прерываний, и нет заранее определенных циклов, как в Scrum.
Бэклог спринта содержит элементы, которые команда выбрала из бэклога продукта во время планирования спринта, чтобы работать над ними в течение текущего спринта. В то время как вы можете непрерывно расширять и уточнять бэклог продукта, во время спринта нельзя добавлять элементы в бэклог спринта.
Бэклог спринта обычно состоит из user story, разбитых на задачи с оценками.
🤷♀️ Распространенные заблуждения
В Agile, разработчики, а не владельцы продукта, скрам-мастера или другие менеджеры, несут ответственность за принятие решения о том, какие элементы попадают в бэклог спринта. Другими словами, команда решает, над какой работой и сколько ее они будут выполнять в следующем спринте.
См. Инкремент.
Story points измеряют предполагаемый размер работы, где размер является суммой нескольких факторов, которые могут влиять на завершение задачи:
Команды могут использовать баллы истории во время грумминга бэклога или встреч по оценке, чтобы получить более ясное представление о том, сколько работы они могут выполнить в каждом спринте.
🤷♀️ Распространенные заблуждения
Зачастую искушение заключается в связывании сторипойнтов со временем - "один балл истории = один день", но это противоречит их назначению. Как только вы это делаете, сторипойнты отражают абсолютное измерение времени, а не относительный размер на основе комбинации факторов.
Также часто путают сторипойнты с оценкой по Фибоначчи. Хотя они тесно связаны - команды обычно оценивают рабочие элементы с использованием сторипойнтов, следующих за шкалой Фибоначчи, - вы можете использовать одно без другого.
См. Kanban Board.
Как и подразумевает название, эта техника оценки в адаптивной методологии использует размеры футболок: Extra Small, Small, Medium, Large, Extra Large или XS, S, M, L, XL. Это форма относительной оценки, при которой команды определяют размер user story или задачи, сравнивая его с другими элементами, а не присваивая абсолютное значение, например, время.
Изначально вы можете ожидать продолжительных обсуждений, поскольку ваша адаптивная команда ищет правильное "подходящее" значение для каждой задачи. Оценка размеров становится проще, когда у вас есть базовая точка на нескольких элементах, которые вы можете использовать в качестве ориентиров.
User story (история пользователя) — это краткое описание функциональности, написанное с точки зрения предполагаемого пользователя, часто в следующем формате:
Как <тип пользователя или персона>, я хочу <цель>, чтобы <причина>.
User story служат отправной точкой для обсуждения всей команды, чтобы определить наиболее подходящее и эффективное решение для потребностей пользователей. Они также помогают команде разработки лучше понять пользователя и сосредоточить свои усилия на доставке ценности для клиента.
Хотя ответственность за то, чтобы в Product Backlog содержались хорошие юзер стори, лежит на product owner (владельце продукта), любой член команды может и должен их писать.
🤷♀️ Распространенные заблуждения
Иногда user story записываются в виде требований или спецификаций, когда люди добавляют слишком много инструкций или технических деталей. Следование вышеуказанным правилам помогает обеспечить их ясность и краткость.
ℹ️ Больше информации
Velocity (скорость) - это количество оцененных user stories (в story points) или работы, которую команда завершает за определенный период, обычно измеряемый за одну итерацию (Sprint). Или, как выразился Леон Трантер в своем Ultimate Guide to Agile Metrics, velocity"просто показывает, сколько 'штук' было перемещено с одной стороны доски на другую".
Как подразумевает определение Трантера, velocity является спорной метрикой. В теории она может помочь команде прогнозировать, сколько работы они могут выполнить за одну итерацию и указывать на проблемы или области для улучшения. Но на практике использование и измерение скорости становится проблематичным, когда другие за пределами команды начинают использовать эту цифру, чтобы:
Когда происходит любое из этих вещей, решения, основанные на этих числах, будут неверными, или команда может манипулировать метрикой. Поскольку команда устанавливает значение story points и оценивает истории и задачи во время планирования итерации, им несложно искусственно изменить это число.
🤷♀️ Распространенные заблуждения
Более высокая скорость не всегда означает лучший результат. Все зависит от целей, которые вы устанавливаете в качестве команды. Предположим, вы вносите улучшения в рабочий процесс, чтобы завершать больше историй пользователей за одну итерацию. В этом случае вы действительно хотите видеть рост скорости. Но вы также можете решить взять на себя меньше работы за одну итерацию, чтобы повысить качество вашего продукта. Это снизит вашу скорость, но уменьшение будет положительным и соответствовать вашей цели.
ℹ️ Больше информации
Work In Progress (WIP) (работа в процессе) отражает общее количество задач, над которыми в данный момент работает команда, обычно представленное одной или несколькими колонками на доске Канбан.
WIP является важной метрикой для поддержания фокуса команды и обеспечения непрерывного потока работы. Высокое значение WIP часто сигнализирует о том, что команда перегружена работой и ее внимание разделено между несколькими задачами. С другой стороны, низкое значение WIP указывает на то, что задачи проходят через систему быстро, и команда выполняет много работы без слишком большого переключения контекста.
В методологии Канбан устанавливается ограничение на WIP, то есть максимальное количество задач, которые могут одновременно находиться в столбце WIP. Если срочная задача должна войти, но достигнуто ограничение WIP, другая задача должна сначала покинуть столбец. Это может произойти путем завершения задачи или перемещения ее обратно в Backlog.
🤷♀️ Распространенные заблуждения
WIP сам по себе не дает полной картины о продуктивности команды и состоянии ее процессов. Допустим, например, команда быстро переводит задачи в статус "Готово", но затем обнаруживает ошибки. Член команды все равно должен будет заниматься этими ошибками, и они могут не отражаться в столбцах WIP.
В этом случае WIP остается низким, но и скорость работы команды также низкая. Поэтому всегда нужно рассматривать WIP в сочетании с другими метриками, такими как скорость выполнения задач (velocity) и, желательно, метрикой, отражающей удовлетворенность клиентов, например, NPS.
Также может потребоваться определить, когда задача перемещается в статус WIP: когда начинается фактическая работа над задачей или когда вы принимаете обязательство работать над ней? Здесь нет неправильного ответа, но важно указать такие параметры для вашего WIP.
86% команд разработчиков программного обеспечения в 2021 году заявляют, что они используют Agile.
Вероятно, вы уже посетили страну Agile хотя бы один раз или сделаете это в ближайшем будущем.
Мы надеемся, что приведенное выше руководство окажется полезным в вашем путешествии.
Один последний совет: помните, что здесь ничто не является законом. Дух этого места заключается в стремлении к непрерывному совершенствованию. Любое правило может быть нарушено, изменено, удалено или заменено - несмотря на то, что могут сказать некоторые ворчливые старожилы или неизбежные мошенники.
Если вы нашли этот ресурс полезным, добавьте его в закладки для будущего использования или поделитесь им со своей командой!
