В Agile MVP - это минимально жизнеспособный продукт, и в основном это означает самый минимум, который вы можете предоставить, чтобы оправдать ожидания вашего клиента:

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

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

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

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

1. наивысшим приоритетом признается удовлетворение заказчика за счёт ранней и бесперебойной поставки ценного программного обеспечения;
2. изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
3. частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода);
4. общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта;
5. проекты следует строить вокруг заинтересованных людей, которых следует обеспечить нужными условиями работы, поддержкой и доверием;
6. самый эффективный метод обмена информацией в команде — личная встреча;
7. работающее программное обеспечение — лучший измеритель прогресса;
8. спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
9. постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость;
10. простота, как искусство не делать лишней работы, очень важна;
11. лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд;
12. команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс.

4 ценности Agile:

Люди и взаимодействия важнее процессов и инструментов

Работающее программное обеспечение над исчерпывающей документацией

Сотрудничество с клиентами в ходе переговоров по контракту

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

Многие люди думают, что Agile — это что-то новое, и что оно в основном предназначено для ИТ-проектов, разработчиков и менеджеров проектов. На самом деле Agile восходит к 50-м годам, но настоящим переломным моментом стал выпуск Agile Manifesto в 2001 году. Манифест — это, по сути, суть Agile.

Дополнительно про методологию можно почитать тут: https://habr.com/ru/company/vk/blog/272237/

У нас есть наши ценности и принципы, идущие от Agile, Agile Manifesto от 2001 года описывает их ценности и принципы. У нас есть четыре ценности и 12 принципов. Однако на самом деле они не описывают выполнение работы, то есть сам процесс. Таким образом, когда люди решают использовать Agile как концепцию, которой они будут руководствоваться, они должны делать это только с процессом выполнения работы. В этом смысле мы склонны думать об Agile как об зонтике. Он работает над всеми различными процессами, которые, как вы могли бы подумать, относятся к нему. Наиболее распространенными являются Scrum, Kanban, LeSS, SAFe. Но на самом деле мы говорим о том, что нам нужен процесс, соответствующий принципам ценностей. Просто наличие ценностей и принципов не принесет результата.

Бэклог продукта содержит все пользовательские истории продукта.

User Story (пользовательская история) — короткая формулировка намерения пользователя и того, что продукт должен сделать для него.

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

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

Для составления Бэклога Спринта команда берет пользовательские истории из Бэклога продукта, добавляет их в спринт и обязуется доставить эти пользовательские истории в этом спринте, то есть это объем работы, которую разработка выполнит за эти две недели.

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

Баллы или очки (Story Points), они обозначают уровень сложности пользовательской истории. Таким образом, вы назначаете баллы за каждую созданную вами пользовательскую историю: 1 — низкая сложность, 3 — средняя сложность и 5 — высокая сложность.

Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software:

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

• Сложность работы
• Объём работы
• Риски и неопределенность

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

Теперь давайте рассмотрим концепцию скорости. Velocity относится к скорости выполнения.

В конце каждой итерации команда суммирует оценки усилий, связанные с пользовательскими историями, которые были завершены во время этой итерации. Эта сумма называется скоростью, то есть это количество Story Points, которое команда реализует за спринт. Таким образом, в начале вы как бы предполагаете или оцениваете, сколько очков Story вы можете набрать за спринт, но после пары спринтов вы сможете усреднить количество очков Story, а затем сделать вывод, например, что в среднем ваша команда может набрать 20 баллов за спринт, и это ваша скорость.

Вы всегда сможете рассчитать свою скорость в конце спринта после того, как просмотрите то, что вы сделали, по сравнению с тем, что вы запланировали. Ваша скорость — это не то, что вы запланировали или что, как вы думали, вы сможете реализовать. Это то, что вы на самом деле представили в Story Points.

Пример бэклога можно посмотреть тут.

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

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

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

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

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

RICE - один из самых распространенных и простых непонятных способов приоритизации. Точнее он кажется понятным, так все просто - давайте проставим баллы:)

Reach - сколько пользователей почувствуют изменения.

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

1. Прозрачность расстановки приоритетов

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

2. Не усредняйте оценки, чтобы получить итоговую.

Это самая частая ошибка. Ваня оценил как 5, Женя как 100, Вася как 40. Итого среднее: 48.3. Если вы видите такой разброс в оценках, то либо люди чего-то не понимают, либо нет общего мнения и вам сначала нужно прояснить ситуацию. Это также поощряет диалог, потому что, возможно, у Жени есть информация, которая оправдывает более высокую оценку. Если человек не может убедить кого-то передумать, вам нужно использовать меньшее значение, то есть если Женя не может убедить Ваню увеличить оценку, то нужно ввести понижающий коэффициент для Жени.

3. Помните о зависимостях

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

4. Мы переоцениваем IMPACT, недооценивая EFFORT

Почти всегда.

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

5. Сначала здравый смысл, потом оценки

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

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

Таким образом, вы видите количество Story points, которые команда набирает с течением времени, то есть скорость команды. По оси X отложены ваши спринты, а по оси Y — Story points. Этот инструмент эффективен за счет того, что прогресс оценивается не в контексте потраченного времени, а в контексте оставшейся работы. Рекомендуется, чтобы оставшаяся работа уменьшалась более-менее равномерно по ходу спринта. Это ведет к уменьшению числа параллельных задач, стимулирует команду помогать друг другу ради скорейшего перехода задач в «Готово» и в итоге ведет к повышению эффективности команды.

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

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

• планирование спринта,
• ежедневные стендапы,
• обзор спринта или демонстрационные сессии и
• ретроспективы.

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

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

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

Здесь можно посмотреть симуляцию ежедневных стендапов.

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

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

• Что прошло хорошо?
• Что не сделали?
• Что вы должны сделать по-другому в следующем спринте?

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

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

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