Ко всем урокам
Click to order
Оформление подписки
Total: 
Для удобства будет подключено автоматическое продление подписки. Его можно отключить в личном кабинете на странице оплаты.
Close
Задать вопрос
Напишите мне, если есть вопросы или предложения
Telegram
WhatsApp
12 неделя
12.3 Продуктовые разработка (Product Delivery)
Время усвоения: ~ 1 час
Цель урока
Понять основные практики, необходимые для организации процессов разработки продукта
Введение в Agile
В целом многие уже знакомы с Agile как методологией реализации проектов разработки. Часто приводят аналогию как на картинке ниже.


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

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

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

Теперь давайте переключим наше внимание на правую часть рисунка с деревом, на котором вместо качели висит кресло. Аналогия также объясняет ключевую концепцию Agile. Будьте проще. Создавайте минимум, который вам действительно нужен, чтобы предоставить то, что ожидает клиент (MVP), удовлетворяющий основному требованию.

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

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

Чем Agile отличается от традиционной разработки?

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


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


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


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

12 принципов 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. Но на самом деле мы говорим о том, что нам нужен процесс, соответствующий принципам ценностей. Просто наличие ценностей и принципов не принесет результата.


Давайте теперь быстро коснемся двух популярных методологий: Kanban и Scrum. Оба эти фреймворка используются для реализации Agile.

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

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

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

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



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

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


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


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


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


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


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

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


Таким образом, Story Point - это относительная оценка сложности задачи, в которой мы учитываем следующие составляющие:
  • Сложность работы
  • Объём работы
  • Риски и неопределенность

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

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

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

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


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


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


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

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


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


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


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

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

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

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


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


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

Confidence - очень часто расценивается, как наша вера в прогнозный Impact, но на самом деле - это вера в наш эксперимент по проверке гипотезы. И тут нам тоже нужна единая шкала (вот тут она была придумана).

Ease - как мы можем создать MVP: cколько ресурсов мы можем потратить, чтобы проверить гипотезу бережливо. Лёгкость реализации (Ease) — это оценка того, сколько усилий и ресурсов потребуется для реализации идеи. Для оценки критерия лёгкости реализации можно составить таблицу Story Points/Ease от 1 до 10. 10 баллов для Ease — это 0 SP и задачу, по сути, можно не делать.

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

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

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

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


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

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


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

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


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

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

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


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

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

Управление спринтом. Burndown chart и Agile board

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


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

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

Ритуалы в Agile (Scrum)

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

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

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


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


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

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


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


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

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

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


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


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