Использование таблиц Agile для оценки открытий

Эта статья включает предварительно отформатированную электронную таблицу, которая поможет вам разработать оценки обнаружения Agile. Он также содержит информацию, которая поможет вам следовать показанному примеру. Вы можете сделать редактируемую копию (Файл>Создать копию или Файл>Загрузить) из шаблона здесь.

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

Введите Agile-таблицу.

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

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

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

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

Сначала займитесь концепцией продукта и дорожной картой

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

Мне нравится формат видения продукта Scrum.org за его интуитивно понятный стиль повествования. Вот как это выглядит:

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

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

Чтобы использовать Microsoft в качестве примера: Windows 8, вероятно, была версией дорожной карты. Windows 10 была еще одной версией дорожной карты, в которой было много новых и желаемых функций.

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

Обсуждайте функции MVP с помощью диаграммы тройных ограничений

Это момент, когда нужно формировать ожидания вашего клиента относительно времени и расходов, используя диаграмму тройного ограничения:

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

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

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

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

Начните с определения размера футболки

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

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

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

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

Установите свои параметры

Теперь вы готовы приступить к работе с электронной таблицей и рассчитать смету. Начните с создания вкладки «Параметры». Это послужит ключом для ваших расчетов, а значения, которые вы здесь введете, будут использованы в формулах, используемых на вкладках Backlog/User Stories и Estimate Summary by Release.

Вот все, что вам нужно на вкладке «Параметры»:

Валюта. Здесь вы вводите конвертацию валюты. Например, если бюджет клиента указан в бразильских реалах, вы можете указать текущий коэффициент конвертации в долларах или евро.

Дата начала. Ожидаемая дата начала разработки будет использоваться для создания графика проекта. В каждом примере наша дата начала — 25 октября.

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

Размер футболки. Введите размеры футболок в виде таблицы и назначьте баллы и диапазон часов для каждой комбинации размеров. В этом примере мы используем от одного до двух часов для SS и от 33 до 48 часов для LL.

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

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

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

Непредвиденные обстоятельства. Это указывает на потенциальное отклонение в вашей оценке. Начиная с непредвиденных обстоятельств 0%, вы увидите наилучший (т.е. маловероятный) бюджет и сроки с учетом значений, которые вы ввели в электронную таблицу. Позже в нашем примере мы увеличим непредвиденные обстоятельства до примерного порядка величины (ROM) дисперсии 50%, чтобы показать потенциальный верхний предел затрат и продолжительности проекта. Непредвиденные обстоятельства будут уменьшаться по мере того, как вы будете получать более точные цифры.

Размер каждого релиза с эпиками

Мы начинаем с приблизительной оценки всего продукта, чтобы не тратить время и деньги клиента. В зависимости от того, насколько приблизится размер к предложенному бюджету и срокам, клиент может принять решение отказаться от проекта или инвестировать в более подробные оценки. Поскольку на данный момент у нас нет подробностей, мы вводим основные функции в виде эпиков на вкладке Backlog/User Stories. Затем для каждого эпика мы вводим количество часов, которое МСП и руководители разработки предложили для каждого стека разработки на основе таблицы размеров футболок на вкладке «Параметры».

Сначала выберите столбец «EPIC?» и убедитесь, что выбран только «Epic».

Затем напишите эпическое описание и введите количество часов для каждого столбца стека разработки. Например, эпопея «Безопасное соединение и вход» займет около восьми часов разработки пользовательского интерфейса, 40 — для серверной части и так далее.

Обратите внимание, что в большинстве случаев в ячейках столбца «Точка» отображается «34*». Если вы вернетесь на вкладку «Параметры», вы увидите, что 34 балла соответствуют часовому диапазону от 33 до 48 часов. Это количество часов слишком велико, если продолжительность нашего спринта составляет всего одну неделю.

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

Теперь перейдите на вкладку Estimate Summary by Release. В верхней части электронной таблицы вы увидите значения «Накладные расходы» и «Непредвиденные расходы», указанные на вкладке «Параметры». Также есть кнопка, которую вы можете выбрать, чтобы показать оценки по эпикам или пользовательским историям.

Поскольку у нас пока нет пользовательских историй для отображения, установите флажок «Эпический режим».

Теперь вы можете увидеть приблизительную стоимость и сроки для MVP, а также менее срочные функции и обновления в будущих выпусках (R3 и R4). В этом примере второй выпуск (R2) пуст, поскольку клиент запросил запуск всех эпиков MVP в первой версии.

Теперь вы можете увидеть самую оптимистичную совокупную стоимость: 28 810 долларов. Эта цифра представляет собой сумму стоимости каждого выпуска от MVP до R4.

У нас также есть оценка кратчайшего срока поставки продукта, который соответствует последней дате завершения в стеке разработки R4. Руководители проектов называют эти более медленные стеки разработки «критическими путями», потому что они определяют скорость всего выпуска.

В этом случае критическим путем является разработка интерфейса с датой завершения 31 января.

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

Отрегулируйте непредвиденные обстоятельства до 50%

Мы по-прежнему относительно мало знаем о требованиях к продукту, требующих усилий и опыта, поэтому мы добавим ПЗУ на непредвиденные обстоятельства в размере 50% на вкладке «Параметры». Непредвиденные обстоятельства будут уменьшаться по мере того, как мы узнаем больше подробностей о проекте.

Опять же, вот общая оценка проекта при 0% непредвиденных обстоятельств.

И здесь это на 50% непредвиденных обстоятельств.

Это означает, что оценка ROM для всего проекта составляет от 28 810 до 41 860 долларов. В лучшем и худшем случаях бюджета клиента в 20 000 долларов будет недостаточно, чтобы включить все функции в его список пожеланий.

Полная дата завершения проекта при 50% непредвиденных обстоятельствах теперь приходится на 14 марта, на шесть недель позже даты завершения 0% непредвиденных обстоятельств.

Между тем, MVP будет готов 10 января.

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

Переставьте приоритеты, чтобы уложиться в сроки

Предположим, клиент устанавливает целевую дату 25 декабря для MVP, через два месяца после запуска 25 октября.

Чтобы перенести текущую дату завершения MVP 10 января, клиент согласился отложить два эпика MVP до следующего выпуска (R2).

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

Основываясь на этой информации, вы можете решить добавить еще двух разработчиков, чтобы согласовать даты завершения клиентской и конечной части с другими стеками разработки. Для этого увеличьте количество часов с 40 до 80 в строке MVP «Часы в неделю».

И фронтенд-, и бэкэнд-разработка теперь заканчиваются в ноябре, и QA становится новым критическим путем (с датой завершения 20 декабря). Обратите внимание, что стоимость не меняется. Это связано с тем, что общее количество часов работы в каждом стеке остается неизменным. Вместо одного разработчика, работающего две недели (80 часов), два разработчика работают одну неделю (80 часов).

В электронной таблице также учитываются различия между работой на полный и неполный рабочий день. Предположим, что разработчик пользовательского интерфейса будет работать неполный рабочий день. Мы можем изменить пользовательский интерфейс «Часов проектирования в неделю» на 20, чтобы имитировать задержку доставки.

По штатному расписанию UX/UI будет завершено 29 ноября.

По графику с частичной занятостью UX/UI завершится 27 декабря.

Опять же, стоимость не меняется, но UX/UI становится новым критическим путем, продлевая временную шкалу MVP до 27 декабря.

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

Уточните свою оценку с помощью пользовательских историй

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

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

Затем настройте значения на вкладке «Параметры» на основе любой новой информации. Например, ваши малые и средние предприятия и команда разработчиков могут иметь более точный набор ставок для каждой роли, а также могут захотеть скорректировать размеры футболок и назначения баллов. Благодаря этим новым параметрам вы можете быть более уверены в своих расчетах и ​​снизить вероятность непредвиденных обстоятельств до 25%.

Давайте посмотрим, как мы разбили эпики на более мелкие и подробные пользовательские истории:

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

В разделе «Размеры футболок» на вкладке «Журнал невыполненных работ/пользовательские истории» введите комбинацию размеров, назначенную вашими разработчиками и малым и средним предприятиям для их стеков для каждой истории. Оттуда формула электронной таблицы автоматически заполнит соответствующие часы на вкладке «Параметры». Помните, что самый большой размер, LL, должен оставаться ниже 34 баллов, чтобы его можно было выполнить в течение согласованной продолжительности спринта. Любые истории, которые по-прежнему оцениваются в 34 балла или выше, должны быть разделены.

Убедившись, что всем историям присвоено менее 34 баллов, снимите флажок «Эпический режим» на вкладке «Сводка оценок по выпускам», чтобы просмотреть только «Историю».

Теперь вы увидите новый набор чисел:

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

Сделай это своим

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

В этой статье была рассмотрена оценка обнаружения, но вы можете использовать ту же электронную таблицу для создания диаграмм выгорания/выгорания, корректировки сроков и расчета оценок на основе скорости и спринтов для более поздних этапов. Я использую свои настраиваемые электронные таблицы в дополнение к таким приложениям, как Jira, Asana и Trello, и утверждаю, что они являются мощным инструментом в моем комплекте управления проектами. Я надеюсь, что они окажутся столь же полезными и универсальными для вас.

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