Контекст
После курса по бизнес аналитике, мне на работе поручили управлять ИТ департаментом компании. Как нибудь попозже расскажу, про задачи и проекты с которыми довелось работать на этой позиции. А пока оставлю отзыв о книге, которую мне дал почитать наш ведущий разработчик.
В принципе и без книги по гибкой разработке, мы использовали подходы похожие на Agile. Мне кажется, сейчас пришло время внедрить в компанию Agile методологию по рекомендациями из прочитанной книги. Это нам добавит прозрачности в планах релизов и итераций. Плюс все заинтересованные лица буду понимать, когда будут внедрены те или иные доработки и внедрения.
Предпосылки Agile
При разработке ПО и выпуске релизов в новых проектах, практически всегда существует высокая неопределенность. Agile методология называет это конусом неопределенности. Самая большая неопределенность на начальном этапе проекта, после 2-3 х итераций скорость команды стабилизируется и конус сужается, а следовательно неопределенность снижается. Ниже представлено графическое отображение конуса неопределенности.
Преимущество Agile подхода, перед классическими водопадными моделями, в возможности внесения изменений в пользу функциональности востребованной рынком. Agile команды готовы к неопределенности, и способны быстро реагировать на потребности пользователей.
Роли в Agile
В Agile проекте участвуют разные роли:
Владелец продукта — отвечает за формирование общего видения проекта и за определение очередности разработки функций.
Клиент, Инвестор, Заказчик — принимает решение о финансировании продукта и его последующей покупке.
А так же пользователи, разработчики, тестировщики, дизайнеры, аналитики и менеджеры.
Приоритезация функций
Работа разбивается на короткие ограниченные по времени итерации, каждая из которых завершается поставкой работоспособного продукта. Приоритетность пользовательских историй (функций) выбирается на основе их приоритетности для бизнеса. Это гарантирует первоочередную разработку наиболее важных для бизнеса функций.
В процессе приоритезации учитывают 4-е основных фактора:
- Финансовая стоимость (отдача) использования функции
- Затраты на разработку и поддержку новых функций
- Объем и значимость обучения и нового знания, создаваемого в результате разработки функции.
- Величена риска, ликвидированного в результате разработки функции
Показателями пригодными для оценки денежного потока от внедрения функции, является чистая приведенная стоимость NVP, внутренняя ставка доходности IRR или ROI, срок окупаемости и дисконтированный срок окупаемости.
Для приоритизации по желательности используют два подхода:
- Анализ Кано. На основе опроса потенциальных пользователей которым задают вопросы как бы они отнеслись к наличию определенной функции и как бы они отнеслись к ее отсутствию.
- Относительное взвешивание учитывает выгоды от реализации функции и потери в случае отсутствия.
Планирование в Agile
3 уровня планирования
Agile команды участвуют в планировании на 3-х уровнях:
- Планирование релиза охватывает срок от 3-х до 6-ти месяцев, можно чаше или реже в зависимости от типа ПО. Это итеративный процесс, начинается с условий удовлетворенности владельца продукта. К ним относятся календарный график, объем работ и ресурсы. Если нельзя спланировать проект так, чтобы удовлетворить все эти условия, то его урезают объем работ, расширяют график или привлекают дополнительный персонал. План резила обычно обновляют перед началом каждой итерации.
- Планирование итерации обычно охватывает срок от 2-х до 4-х недель. Пользовательские истории разбивают на задачи. Каждую задачу оценивают в количестве идеальных часов. Существуют два основных подхода планирования итерации: на основе скорости и планирование на основе обязательств. Подходы похожи и имеют много общих этапов. Выбор размера итерации зависит от: длинны релиза, уровня неопределенности, простоты получения обратной связи, продолжительность сохранения неизменности приоритетов, готовность продолжить работу без получения внешней обратной связи, издержки итерационного подхода, быстрота появления ощущения цейтнота.
- Ежедневное планирование включает в себя принятие обязательств по задачам «на сегодня» членами команды.
Оценки User Story в Agile
Оценка размера пользовательской истории происходит в пунктах. Пункты — это относительный показатель размер пользовательской истории. Для оценки сложности пользовательской истории обычно применяют числа Фибоначчи до 13 и далее большие карточки, 20, 50, 100. Пункты — это именно относительная величина, и значит она примерно, что история оцененная в 3 пункта в 1.6 раза меньше истории оцененной в 5 пунктов. Числа Фибоначчи гармонично описывают пропорции, по этому предлагается применять именно их.
В итерацию обычно беруться истории до 8 пунктов, которые можно реализовать за 2-х недельный срок. Истории из больших карточек в дальнейшем будут разбиты на более мелкие, предназначенные для реализации в рамках итерации. Для разбивки US (User Story — пользовательской истории) на более мелкие используют разбивку на CRUD (создание, чтение, обновление, редактирование) или выделения сквозной функциональности. А так же многие истории описывают две и более потребности.
По мимо пунктов, можно использовать и оценку в идеальных дня. Но мне больше нравится в пунктах.
Наилучшие оценки дают те кто выполняет работу. А т.к. в Agile команде исполнитель не известен заранее, оценку дает вся команда в целом. Хорошим инструментом является покер планирования. В покере планирования все участники команды выставляют оценки пользовательским историям, а потом показывают карты. Если есть разница в оценках, опрашивают того кто дал максимальную и минимальную оценки, для того чтобы они пояснили свой выбор. Далее процесс повторяется, пока вся команда не придет к единой оценке по US.
Скорость в Agile
Скорость — показатель темпа продвижения команды. Определяется как сумма завершенных задач в итерации. Срок проекта определяется делением суммарного количества пунктов из пользовательских историй релиза на скорость команды. Существует 3 способа определения скорости. Во-первых, исторические средние показатели при их наличии. Прежде чем их применять, необходимо учесть не изменилась ли команда, характер проекта, технологии и т.п. Во-вторых можно отложить оценку скорости, до выполнения нескольких итераций. Это обычно наилучший вариант. В-третьих можно спрогнозировать скорость путем разбивки US на задачи и определения объема работ, подходящего для итерации. Оценку скорости следует представлять в виде диапазона отражающего неопределенности. Конус неопределенности помогает с определением нужного диапазоне.
Для учета скорости используются именно фактически завершенные задачи. Либо задача сделана либо нет. Если сделана, то пункты можно зачесть.
Учет неопределенности в Agile
Проект следует защищать от неопределенности функций с помощью функционального и временного буферов. Временной буфер создается путем включения в календарный график дополнительного времени. Функциональный буфер подходит для проектов с четкой приоритизацией задач, в которых около 30% функционала можно считать опциональными. Лучший защитой проекта является комбинация временного и функционального буфера.
Работа нескольких Agile команд над одним проектом
В больших проектах стремятся избегать создания больших команд, вместо этого задействуют несколько Agile команд. В книге описано четыре приема, помогающие командам работать над одним и тем же проектом.
- Команды имеют единую систему оценки. В пунктах или идеальных дня. Они должны согласовать оценки оценив совместно несколько задачи.
- Командам надо быстро добавлять детали в пользовательские истории.
- Команды выигрывают от создания скользящего опережающего плана нескольких будущих итераций.
- В план полезно включать поддерживающий буфер. Это запас времени, который предотвращает задержку поставки результатов одной из команд, приводящую к задержке начала работ у другой команды.
Отчетность в Agile
Для отслеживания прогресса используют диаграмму или гистограмму выгорания релиза. Эти графики позволяют учесть скорость выполнения работ и изменение объема работ.
В книге написано про аналоговую доску задач для мониторинга итерации. Я предпочитаю Pyrus и Trello. При этом стоит учитывать именно скорость команды в целом, а не отдельные индивидуальные результаты ее участников.
По завершении итерации иногда публикуется письменный отчет который может включать в себя диаграммы и гистограммы выгорания релиза и итерации, а так же информацию о скорости движения проекта. А мне кажется круто было бы делать видео отчет в внедренным за период итерации функционалом.
