Что такое мышление в стиле agile
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.
Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.
Пропускная способность
Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.
Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.
Для того чтобы поддерживать этот ритм и чтобы не завязнуть в ручном регрессивном тестировании, команда усиленно работает над автоматическим тестированиеми постоянной интеграцией. Поэтому на каждую фичу приходится писать автотесты, и большая часть кода имеет встроенные автотесты.
Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.
Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.
Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.
Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.
Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”
Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.
Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.
Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.
Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.
Есть только один способ держать список задач под контролем — это слово “нет”
Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.
Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.
Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.
Принятие решений
Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.
Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.
Как владелец продукта определяет ценность и объем истории? Никак. Это игра в угадайку. И лучше в ней участвовать всем. Пэт постоянно общается с заинтересованными лицами, чтобы знать ценность каждой истории, общается с командой разработчиков, чтобы знать объем работ, но все это приблизительные догадки, никаких точных цифр. Вначале всегда будут промахи и это нормально. Гораздо большую ценность представляет общение, чем сверхточные цифры.
Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.
Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.
Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.
Владелец ИТ-продукта должен постоянно со всеми общаться
Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.
Баланс между сложностью разработки и ценностью пользовательской истории
На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.
Риски
Бизнес риск: «Правильную ли вещь мы делаем?»
Социальный риск: «Сможем ли мы сделать то что нужно?»
Технический риск: «Будет ли проект работать на данной платформе?»
Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»
Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,
Компромисс между ценностями знания и ценностями для клиента
С точки зрения заказчика кривая выглядит вот так:
С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.
Компромисс между краткосрочным и долгосрочным мышлением
Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.
Делать правильные вещи, делать вещи правильно или делать быстро?
В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.
Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.
Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.
Между ролями в Scrum существует здоровое противостояние
Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.
Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.
Компромисс между разработкой нового продукта и улучшением старого
Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.
Мышление в стиле Agile: гибкие методы в управлении проектами
25 Янв 2016
Гибкие методологии набирают популярность за пределами ИТ, крупные компании всё чаще рассматривают Scrum в качестве альтернативы классическому проектному управлению. Но прежде чем приступить к внедрению гибких методик управления проектами необходимо найти ответы не несколько вопросов, таких как: подходит ли Agile нашей компании? Подойдёт ли существующая организационная структура для таких изменений? Как измерить отдачу от внедрения?
Во многих ситуациях внедрение Agile может серьёзно повысить производительность и улучшить результативность всех членов команды. Однако недостаточно просто нанять «гибкого» менеджера проектов (Agile Project Manager (APM) – прим. пер.). Для успешного внедрения и использования гибких методологий необходимо изменение всей организации, метрик и образа мышления.
Хотите использовать гибкие методы? Вам нужна гибкая организация!
Одна из сильных сторон традиционной каскадной модели управления проектами состоит в том, что она основана на простом и проверенном временем наборе наглядных метрик, которые позволяют легко отслеживать прогресс проекта и его состояние. Поскольку каждая задача разбита на простые пакеты работ, отслеживать прогресс выполнения задачи достаточно просто. Гибкие методики, напротив, фокусируются больше на достижении цели, а не на метриках и документации. «Гибкий» менеджер проектов формирует видение проекта и управляет ожиданиями проекта, а самоорганизующиеся команды реализуют проект, принимая на себя ответственность и управление.
Часто члены команды работают одновременно над разными аспектами проекта, чтобы достичь поставленной цели. Это приводит к тому, что настоящий прогресс проекта достаточно трудно оценить и описать традиционными для каскадной модели методами. Однако и в гибких методиках есть способы измерения и отчётности.
Переосмысливая метрики проектов
«Гибкий» менеджер проекта должен понимать, насколько продвинулась команда в работе над проектом и предоставлять отчётность высшему руководству. Он может делать отчёт о состоянии всего проекта, в форме, например, диаграммы сгорания. Или о какой-то его части во время ежедневных встреч или в форме отчётов. Но важно понимать, что все усилия сконцентрированы на устранении препятствий в работе проекта, а не на подчинении его процессу отчётности.
Именно это и пугает организации с традиционным подходом – они уверены, что гибкие методики управления проектами хаотичны и не ориентированы на детали. Но это плата за освобождение менеджера проекта от рутины постоянного детального планирования и отчётности. Теперь руководитель может больше времени уделить работе над проектом, решению проблем, мотивации команды. В этом состоит основное отличие каскадных и гибких методологий с точки зрения функций руководителя проекта. «Гибкий менеджер» меньше занимается контролем, и больше – решением проблем и работой с командой. Если удастся привлечь к преобразованиям в сторону Agile руководство, компанию и клиентов, то точность «гибких» метрик может достичь того же уровня, что и у традиционных «каскадных» методологий, и даже превзойти их благодаря концентрации Agile на главных аспектах продукта.
Особенности Agile
Традиционные «каскадные» методики
Гибкие методики
Детальный график, иллюстрирующий расписание проекта. На нём отображены даты начала и конца каждого действия, а также зависимости между ними
Понятная с одного взгляда диаграмма, показывающая количество очков историй или задач на количество итераций проекта. Чем более крут график – тем быстрее исполняется проект. В редких случаях, при добавлении новых задач, может иметь положительный наклон
Чётко распланированная встреча, где менеджер проекта с командой разбирает каждую задачу, её статус, результаты и сроки, когда она будет выполнена. Руководитель ответственен за выполнение задач (тут авторы приводят какой-то свой пример, обычно на классических статус митингах разбирают примерно то же, что и на «встречах на ходу» — прим. пер.)
Короткие встречи с командой на ходу, на которой каждый из членов команды отвечает на 3 вопроса: «Что было сделано с последней встречи? Что должно быть сделано перед следующей? Какие препятствия мешают достичь цели?». Руководитель получает необходимую ему информацию, чтобы быть в курсе дел проекта, а член команды берёт на себя ответственность за выполнение задачи
Заказчик назначает цель проекта, а затем ожидает его завершения. Его информируют о состоянии бюджета или о срыве сроков, после того, как это происходит (но могут информировать заранее о рисках, которые могут привести к перерасходу средств или срыву сроков – прим. пер.)
В Agile Заказчик – активный участник проекта. Владелец продукта («product owner») присутствует на ежедневных встречах, участвует в принятии решений. Задача руководителя проекта состоит в поддержании тесных взаимоотношений с заказчиком и обучении его принципам работы с Agile
Авторы статьи в таблице привели примеры из своей практики. Однако в опыте компании «Проектные сервисы» встречались случаи применения инструментов, указанных в статье, как «гибкие», в традиционных методиках и компаниях – прим. пер.
Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.
Agile: что это такое и где используется, принципы и методология
В больших проектах, где работает много участников, организовать работу сложно без подготовки и единой системы. Чтобы повысить показатели при ведении проектов, научиться управлять командой, стоит присмотреться к системе гибкого управления Agile.
Что такое Agile
Agile – это набор методов для управления проектами в областях, требующих прикладной работы. Методология применяется для увеличения скорости создания продуктов, уменьшения рисков при разработке, увеличения уровня взаимодействия между членами команды. Она обеспечивает оперативную реакцию на происходящие изменения и позволяет корректировать отклонения.
Чем отличается от других методологий
Она не похожа на предыдущие подходы, описывающие создание продукта в деталях. Agile краток, в нем 4 ценности и 12 принципов. RUP в отличие от Agile – менее гибкая методология, при этом более объемная, описывает процесс работы на десятках страниц. RUP не подходит для небольших задач, состоит из итераций с продолжительностью от 2 до 6 недель.
OpenUP – преемница RUP. В этой методологии проект делится на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Методология недостаточно гибкая в сравнении с Agile, применима больше в IT-сфере.
Где используется Agile
Методика применялась в IT-индустрии и использовалась для разработки ПО. Суть сводилась к внедрению адаптивных методов, которые ускоряют создание продуктов через микропланирование и короткие производственные циклы. Однако впоследствии Agile стала использоваться и в других прикладных областях. Agile сейчас применяют компании: Netflix, Spotify, Magna International, General Electric, Accenture, М.Видео.
Подобные технологии стали достоянием команд, работающих над созданием клиентских продуктов.
Плюсы и минусы Agile
Манифест Agile
Идеи Agile
Ценности Agile говорят, что:
Гибкость методологии
Методы организации работы основаны на каскадной модели, в которой процессы реализуются поэтапно. Если требования к разработке продукта, конечной цели изменяются, нужно переделывать выполненную часть работы. На это готовы не все сотрудники: некоторые до последнего не сообщают начальству о необходимости корректировок в уже неработающем плане. Agile методология решает эту проблему с помощью имеющейся гибкости и адаптивности.
Принципы методологии
При выборе этой системы организация быстрее работает, мобильнее, разделяет сотрудников на небольшие команды. Принципы Agile выражают так: разделение задач на небольшие блоки, автономность сотрудников, прозрачность работы, обработка обратной связи от клиентов.
Работа над мини-блоками
Сложные проекты разделяют на маленькие задачи, каждая из которых помещается в отдельный блок. Целей достигают за короткий цикл, поэтому даже в многоступенчатом проекте виден прогресс в работе.
Маленькие кросс-функциональные команды
Сотрудники работают в небольших командах. Задача каждой в реализации одной из функций, которая важна для клиента. Численность и состав команд отличаются в зависимости от их задач. Число сотрудников в одной команде до 12 человек.
Ограничение объема незавершенной работы
Agile помогает командам концентрироваться на задачах, которые можно решить за небольшой промежуток времени. Уменьшение объема работы помогает быстрее справиться с мини-задачами, что сказывается на общей продуктивности.
Автономность команд
Перед началом работы над задачей составляют план. Затем каждая команда решает, как приступить к его выполнению. Задача руководителя ― определить базовые правила, сотрудники самостоятельно выбирают темп работы, условия, координируют действия.
Достижение стадии готовности
Проверка методологии – завершение задачи, итоги которой подводятся в конце каждого цикла. Благодаря разделению на небольшие блоки команды могут полностью завершить задачу, а не отмечать ее как «практически законченную». Причина медлительности в крупных проектах – задания, которые завершены частично, но в них еще ряд проблем. В результате они тянут время, ресурсы, внимание и отвлекают сотрудников от обязательств.
Беспрерывная работа
Задачи, поделенные на короткие циклы, имеют приоритеты, к которым нужно стремиться на каждом этапе. Благодаря чему работа беспрерывна, и сотрудники не отвлекаются на смежные задачи.
А чтобы не отвлекаться на рутинные отчеты, подключите сквозную аналитику Calltouch для вашего бизнеса и уделяйте время важным стратегическим задачам.
Полная прозрачность и использование досок со стикерами
Это помогает кратко, но емко описать работу, зафиксировать актуальную стадию, на которой находится команда, посмотреть на процесс глазами сотрудников, при необходимости определить источник проблем.
Обратная связь от пользователей на каждом цикле
Команды получают обратную связь от клиентов в конце каждого цикла. На основе сведений оценивают достижения, реализацию задачи. Информация учитывается в дальнейшем для планирования.
Ключевые моменты в применении
Методы Agile используются для решения разных бизнес-процессов. Поэтому перед их внедрением важно разобраться, как выглядит методология на практике.
Какие существуют роли по Agile
Иерархия компетенции в Agile
Структура команды горизонтальна, но в ней есть иерархия. Руководитель задает вектор, по которому сотрудники реализуют задачи. Особенность системы – иерархия построена на компетенции, а не власти, что определяет взаимодействие сотрудников с начальством.
Что такое пропускная способность
Пропускная способность – реализованное количество «пользовательских историй». Это пожелания клиентов, которые формируются в задачи. Например, установка фильтров поиска в приложении, улучшение обратной связи с клиентами, работа над службой техподдержки. Пропускная способность измеряется количеством отработанных пользовательских историй в неделю.
Как определить последовательность и приоритетность задач
Приоритетность задач зависит от направления компании. Например:
Как составить график решения задач
Для составления графика используют приложения с шаблонами для планирования проектов. Например, GanttPRO – сервис для постановки задач и их контроля. Он содержит шаблоны графиков, отслеживает цели по степени продвижения, отмечает слабые места.
Внедрение Agile
Для внедрения методологии выполняют комплекс мероприятий. Он основан на выборе главного метода в системе, после чего устанавливаются задачи, цели, сроки, численность команды. Сотрудники должны быть обучены применению методов на практике, а руководство должно понимать, что внедрение системы станет новым поворотом в развитии бизнеса.
Важно использовать опыт специалистов, которые уже работали с системой и знают, как реализовать ее. Их опыт помогает в формировании команды, подборе инструментов, аналитике.
Распространенные проблемы при реализации
Основные проблемы при внедрении Agile:
Популярные методы и средства управления проектами
Scrum
Здесь упор на контроль рабочего процесса, что разделяет разработку проекта на стадии. Эти стадии длятся от 2 до 4 недель. Процесс начинается с оценки масштабов работы, предполагает корректировку действий и планов с учетом промежуточных итогов. Скрам повышает производительность и ориентируется на сокращение времени для достижения цели.
Kanban
Метод основан на прозрачности процесса. Он функционально распределяет нагрузку на сотрудников, мотивирует членов команды на сотрудничество и обучение. Принципы строятся на: