Способ оценки деятельности задач agile проекта

Что такое Agile: методология, команда, оценка эффективности

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

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

Неудобные вопросы

• Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
• Как сделать так, чтобы разработка плана проекта не занимала до 30% времени от всего объёма его реализации?
• Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

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

Делай сразу!

Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это как в знаменитой мотивирующей формуле: «„Сделано“ — это лучше, чем „идеально“». Реализуйте первую функцию и начните тестировать её, создавая следующую, и так раз за разом — вот главное правило.

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

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

Горизонтальная организация

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

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

Ещё одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.

Важно!
Но иметь базовые знания о смежных специализациях в гибкой разработке необходимо.

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

Как внедрить Agile?

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

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

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

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

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

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми в сферах от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы вы сможете, пройдя курс «Руководитель digital-проектов» от Skillbox.

Охотник за авторским контентом — ищет спикеров, помогает им делать авторские колонки, берёт интервью. Писал тексты для TJournal, vc.ru, Reed.media, Apparat, «Секрета фирмы», Accent.

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Источник

Как планировать и оценивать проекты в Agile?

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

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

Когда я в первый раз провел игру-раскраску на одном из мастер-классов местной ПМ-тусовки, даже не ожидал, что достаточно консервативные менеджеры проведут так весело время и получат объяснение „Что такое относительный стори поинт? В чем его ценность?“. С тех пор я провел эту игру на многих тренингах и нескольких конференциях, включая SECR-2015 и Agile Days Russia 2016».

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

Время

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

• 15 минут – оценка
• 35 минут – завершить закрашивание (длительность итерации = 1 минута)
• 10 минут – обсуждение

Подготовка:

• Разбить группу на команды из 3-5 человек
• Команды должны сидеть за столом
• Один чистый лист флип-чарт бумаги на команду
• Один флип-чарт маркер на одного участника

Инструкции

Оценка

1. Для каждой группы подготовить одинаковые флип-чарты с пустыми фигурками. См. пример ниже

2. Ведущий игры подготавливает на флип-чарте таблицу, в которой он будет фиксировать метрики всех команд:

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

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

Выполнение

1. Длина одной итерации не больше минуты.

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

3. Запускаем первую итерацию:

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

5. Частично сделанная работа переоценивается в стори-поинтах в сторону уменьшения, но разница не добавляется в суммарную скорость (т.е. скорость показывает только принятую работу). У меня часто спрашивают «почему»? Я понимаю, что обидно терять поинты, когда история в конце спринта закончена на 90% (поинты пройдут как-бы мимо команды). Вопрос только в том чего хочет команда, показать высокую скорость или завысить ожидания заказчика? Возможно в этой незаконченной истории действительно осталось 10% работ. Но вдруг, доделывая эти 10%, вы обнаруживаете дефект, на решение которого вы потратите еще +50% вашего времени. А заказчикам то уже показали высокую скорость? Именно поэтому сообщество скрам-практиков не рекомендует включать в скорость (Velocity) любые недоделанные истории.

6. Команда пересчитывает сумму оставшихся стори-поинтов на флип-чарте и прогнозирует срок выполнения проекта по формуле.

Скорее всего срок выполнения будет отличаться от изначально запланированного

7. Повторяем шаги 1-6 до выполнения проекта по закраске:

8. Команда празднует завершение проекта.

Обсуждение

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

2. Если команды не заработали очков после первой итерации. Обсудите почему важно в конце итерации иметь готовый инкремент? Почему наполовину готовый инкремент не показывает прогресс? Почему наполовину готовый инкремент может дать большие погрешности в подсчете прогноза выполнения проекта?

3. Продемонстрируйте как нарисовать Release Burn-Down Chart, используя данные из таблицы.

4. Обсудите почему важно приучать заказчика к тому, что скорость команды может постоянно изменяться под воздействием непредвиденных обстоятельств?

5. Собрать и зафиксировать обратную связь от участников. Что они узнали нового? Чему научились? Что из упражнения можно пробовать в реальной жизни?

6. Ведущий убеждается что участники поняли как относительные попугаи помогли считать реальное время выполнения проекта.

7. Исследуйте ценность разделения больших задач\историй (фигур) и как команды улучшались между итерациями.

Источник

Оценка сложности историй

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

Просмотр тем

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

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

Взаимодействие с владельцем продукта

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

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

Agile-оценка — это командная работа

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

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

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

Оценка сложности в очках и часах

При традиционном подходе команды разработчиков ПО дают оценку в единицах измерения времени: днях, неделях и месяцах. Однако многие команды agile предпочитают оценку сложности в очках. Очки сложности отражают общие трудозатраты, необходимые, чтобы полностью реализовать элемент бэклога продукта или выполнить любую другую рабочую задачу. Команды начисляют очки в зависимости от сложности и объема работы, а также сопутствующих рисков или неопределенности. Эти числовые значения нужны для того, чтобы более эффективно разбить работу на небольшие части и избавиться от неопределенности. Благодаря такому подходу со временем команды понимают, сколько они могут сделать за отведенное время, вырабатывают общее представление и придерживаются его. Может показаться, что это далеко не самый понятный способ, однако его польза в том, что он подталкивает команды к принятию более точных решений о сложности работы. У этой системы оценки есть и другие преимущества.

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

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

Оценка сложности и покер планирования

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

Готовы попробовать?

Будьте умнее — не мудрите

Отдельное задание не должно занимать более 16 часов работы (если вы оцениваете сложность в очках, можете договориться о верхнем пределе, скажем, в 20 очков). Оценить более сложные рабочие задачи с должной долей уверенности практически невозможно. А уверенность очень важна, особенно когда речь идет о задачах с наиболее высоким приоритетом в бэклоге. Если сложность какой-либо задачи выходит за верхний предел команды (16 часов или 20 очков), это сигнал, что ее нужно разбить на более мелкие составляющие и провести оценку повторно.

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

Извлекайте уроки из прошлых оценок

Ретроспективы существуют для того, чтобы команда могла взять на вооружение ценную информацию из прошлых итераций, включая факторы, повлиявшие на точность оценок. Многие agile-инструменты (например, Jira Software) отслеживают очки за истории, значительно упрощая анализ и оптимизацию оценок. Возьмите, например, последние 5 пользовательских историй, которым команда присвоила по 8 очков. Обсудите, какие из этих задач потребовали одинаковое количество усилий. Если разные случаи потребовали разных усилий, обсудите причины этого. Используйте полученные выводы в процессе оценки сложности в будущем.

Как и все в методике agile, оценка — это практика. С каждым разом вы будете справляться лучше и лучше.

Источник