Оценка

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

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

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

Нет необходимости работать в выходные дни, чтобы компенсировать недооценку части работы. Тем не менее, давайте рассмотрим некоторые способы сделать agile оценки максимально точными.

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

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

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

Agile оценка - командный вид спорта

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

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

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

 

Хотите попробовать сюжетные точки? Сначала зарегистрируйтесь или войдите в Jira Software >>

• Попробуйте этот интерактивный учебник, чтобы настроить свой первый Scrum-проект.
• Узнайте, как настроить оценку сюжетных точек и отслеживать ваши пользовательские истории.

Сюжетные точки против часов

Традиционные команды разработчиков программного обеспечения дают оценки в формате времени: дни, недели, месяцы. Многие agile команды, однако, перешли к сюжетным точкам. Рассказы оценивают относительные усилия работы в формате, подобном Фибоначчи: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Это может показаться нелогичным, но эта абстракция на самом деле полезна, потому что она подталкивает команду к принятию более жестких решений относительно сложности работы. Вот несколько причин использовать сюжетные очки:

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

Сюжетные точки и планирование покера

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

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

• Установите это приложение планирование покера.
• Узнайте больше о планировании покера здесь.

Оцениваете умнее, а не сложнее

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

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

Учитесь на прошлых оценках

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

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

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

По материалам Agile Coach "Estimation"