Преимущества Agile-методологии

Сейчас много говорят об Agile-методологии.

И это справедливо.

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

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

Что это значит?

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

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

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

В ЧЕМ ПРЕИМУЩЕСТВА AGILE-МЕТОДОЛОГИИ?

• Для заказчиков. Они обнаруживают, что поставщик более оперативно реагирует на запросы разработчиков. Ценные функции разрабатываются и поставляются быстрее, с более короткими циклами по сравнению с длинными циклами, которые применяются в традиционных водопадных методологиях.
• Для вендоров. Поставщики сокращают потери, концентрируя усилия по разработке на высокоценных функциях и тем самым сокращая время выхода на рынок. В результате снижаются затраты и повышается эффективность. В результате повышение удовлетворенности клиентов приводит к увеличению их удержания и положительных отзывов о поставщике.
• Для команды разработчиков. Члены команды получают удовольствие от разработки и хотят видеть, что их труд используется и ценится. Scrum приносит пользу членам команды, сокращая непродуктивную работу (например, написание спецификаций или других артефактов, которые никто не использует) и дает им больше времени на работу, которая им нравится. Члены команды также знают, что их работа ценится, потому что требования подбираются так, чтобы максимизировать ценность для клиентов.
• Для менеджеров по продукту. Менеджеры по продукту, которые обычно выполняют роль владельца продукта, отвечают за то, чтобы клиенты были довольны, обеспечивая соответствие работы над проектом потребностям клиентов. Scrum облегчает это согласование, предоставляя частые возможности для изменения приоритетов в работе, чтобы обеспечить поставку продукта с максимальной ценностью.
• Для менеджеров проектов. Руководители проектов в роли ScrumMaster обнаруживают, что планирование и отслеживание стали проще и конкретнее по сравнению с водопадными процессами. Фокус на отслеживании выполнения задач, использование диаграмм Burndown для отображения ежедневного прогресса и ежедневные Scrum-совещания — все это дает менеджеру проекта огромную осведомленность о статусе проекта в любой момент времени. Эта осведомленность необходима для мониторинга проекта и быстрого выявления и решения проблем.
• Для PMO и руководителей уровня C. Scrum обеспечивает высокую ежедневную видимость статуса разработки проекта. Внешние заинтересованные стороны, такие как директора высшего звена и сотрудники PMO, могут использовать эту видимость для более эффективного планирования и корректировки своих стратегий на основе более надежной информации и с меньшим количеством домыслов.

Что такое SCRUM?

Scrum — это подмножество Agile. Это наиболее широко используемая и легкая технологическая схема для agile-разработки.

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

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

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

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

КАКОВЫ ТРЕБОВАНИЯ К SCRUM?

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

Пользовательская история

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

История

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

По умолчанию

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

КАКОВЫ РОЛИ В SCRUM?

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

ScrumMaster

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

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

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

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

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

Команда

Команда — это самоорганизованная и кросс-функциональная группа людей, которые выполняют практическую работу по разработке и тестированию продукта. Поскольку команда отвечает за производство продукта, она также должна иметь право принимать решения о том, как будет выполняться работа. Поэтому команда является самоорганизующейся: члены команды решают, как разделить работу на задачи и как распределить задачи между людьми в течение спринта. Размер команды по возможности должен быть в пределах от пяти до девяти человек. (Большее число мешает общению, а меньшее приводит к низкой продуктивности и хрупкости). Примечание: Очень похожий термин, «Scrum Team», обозначает команду плюс ScrumMaster и Product Owner.

КАКИЕ МЕТРИКИ AGILE МОЖНО ИСПОЛЬЗОВАТЬ ДЛЯ ОТЧЕТНОСТИ?

Что измерять в Agile — это давний вопрос. Прежде чем что-то измерять, мы должны задать себе два основных фильтра: «Ускорит ли эта метрика доставку ценности?» и «Повысит ли это измерение доверие?». и «Повысит ли это измерение доверие?».

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

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

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

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

Пример операционных показателей

• Время выполнения
• Время цикла
• Графики убывания

Образцы выходных значений

• Пропускная способность
• Модель оценки гибкости
• Техническое качество / измерение дефектов / покрытие кода
• # количество функций и т.д.

Выборочный результат/значение

• Моральный дух команды
• Удовлетворенность клиентов / NPS
• Стоимость бизнеса

КАКОВ НАИЛУЧШИЙ ЦЕЛОСТНЫЙ ПОДХОД К ВНЕДРЕНИЮ AGILE-МЕТОДОЛОГИИ?

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

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

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

Например, бухгалтерия переходит от учета затрат к бережливому учету. Другой пример — когда отдел кадров рассматривает возможность перехода на OKR и отказа от MBO и KPI. Enterprise Value фокусируется на метриках, которые соотносятся с получением ценности, а не с результатом.

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