Очки Agile Story vs Hours: как лучше оценить разработку программного обеспечения

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

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

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

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

Так что же такое сюжетные точки и почему они появились, если у нас уже есть простая и понятная модель оценки?

Содержание:

1. Что такое очки истории?
2. Вот как рассчитываются очки истории в Agile
3. Преимущества оценивания в сюжетных пунктах
4. Недостатки оценки в сюжетных пунктах
5. Преимущества оценки в часах
6. Недостатки оценки в часах
7. Можете ли вы перевести очки истории в часы?
8. Очки против часов: что выбрать для разработки программного обеспечения?

Что такое очки истории?

Story points - это модель относительной оценки, присущая Agile и Scrum. Они оценивают усилия по созданию продукта , обращая внимание на три аспекта разработки:

• объем работы, который требует продукт

• сложность функций продукта

• риски и неопределенности, которые могут повлиять на развитие

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

На первый взгляд это выглядит достаточно просто, но кто определяет количество очков в каждой истории?

Вот как рассчитываются очки истории в Agile

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

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

1. Каждый разработчик получает набор карточек Planning Poker.

2. Разработчики выбирают пользовательскую историю и обсуждают ее сложность и необходимые усилия по разработке.

3. Каждый разработчик выдвигает карточку, соответствующую количеству баллов, которые они присвоили истории.

4. Если оценки в баллах совпадают, истории присваивается оценочное количество баллов.

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

6. Разработчики выбирают следующую пользовательскую историю.

7. Повторите шаги с 3 по 5.

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

Выглядит это примерно так:

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

Есть два часто используемых варианта оценки сюжетных точек. Вы можете назначить баллы:

• используя любые целые числа (1, 2, 3… 13,14,15 и т. д.)

• используя числа в последовательности Фибоначчи (1, 2, 3, 5, 8, 13… 55, 89, 144 и т. д.)

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

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

Преимущества оценивания в сюжетных точках

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

1. Сюжетные статьи не зависят от разработчика.

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

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

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

Сюжетные точки сводят к минимуму эту проблему . Назначенные несколькими разными разработчиками, они дают общее представление о том, насколько сложна конкретная пользовательская история. Очки истории работают для всех без исключения разработчиков в конкретной компании. (Хотя, пожалуйста, имейте в виду, что оценки Story Point не будут правильными для разных компаний.)

2. Сюжетные точки упрощают пересчет времени разработки.

При оценке времени Agile с помощью Story Points команды используют термин «скорость» для обозначения количества Story Points, набранных за один спринт.

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

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

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

3. Очки истории хороши для мониторинга работы команды.

Когда у вас есть команды, работающие над аналогичными проектами и / или задачами в разное время, скорость может легко показать вам прогресс, которого достигла каждая команда. Улучшились ли они и насколько? Какая команда или разработчик испытывают трудности и могут нуждаться в дополнительном обучении? Какая кривая обучения? Может, лучше играет другая команда?

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

4. Оценка времени запуска с помощью Story Points более точна.

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

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

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

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

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

6. Очки истории улучшают командную работу.

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

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

Недостатки оценки в сюжетных пунктах

У этого аргумента всегда есть обратная сторона: как рождаются великие системы. Оценка на основе сложности также имеет свои недостатки , и каждая команда должна решить для себя, перевешивают ли они преимущества.

1. Сюжетные баллы должны назначаться более чем одним разработчиком.

Преимущество модели «Story Points» - это ее объективность и ценность для будущих оценок. Но для того, чтобы это было правдой, оценка должна выполняться более чем одним разработчиком . Для небольших компаний с одной командой или компаний, где есть только один специалист в области (например, только один дизайнер или разработчик iOS), очки истории не приносят столько преимуществ. Такие небольшие компании традиционно выбирают в качестве модели оценки рабочее время.

2. Оценка в очках истории требует значительного отставания.

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

3. Истории сложнее для составления бюджета.

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

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

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

4. Скорость рассчитывается для каждой команды.

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

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

Преимущества оценки в часах

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

1. Часы - знакомая модель

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

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

2. Клиенты обычно платят за часы.

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

3. Оценка на основе часов может быть сделана одним разработчиком.

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

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

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

Недостатки оценки в часах

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

1. Единоличная ответственность за оценку - это большая нагрузка.

С одной стороны, может быть проще оценить ваши собственные временные потребности, поскольку вы полагаетесь только на себя.

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

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

2. Оценка одного разработчика всегда менее точна, чем оценка команды.

Индивидуальные оценки субъективны и связаны с эмоциональными и психологическими обстоятельствами оценщика.

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

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

3. Чем крупнее задача, тем сложнее ее оценить в часах.

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

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

4. Малая гибкость

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

Можете ли вы перевести очки истории в часы?

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

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

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

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

Вот пример.

История с одним очком (базовая история) занимает, скажем, два часа.

История из 13 пунктов может занять 26 часов в лучшем случае - если ничего не пойдет не так. Например, если используемый API идеально подходит, от конечной точки к конечной точке. Но если этого не произойдет, история может занять от 30 до 50 часов - в зависимости от количества несоответствий. Никто не может заранее сказать, как все пойдет, если разработчик еще не работал с рассматриваемым API.

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

Очки против часов: что выбрать для разработки программного обеспечения?

Как видите, и баллы рассказа, и часы - правильный выбор для разработчика при оценке проектов.

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

Компании, работающие с моделью фиксированной цены, обычно прибегают к оценке по часам. Команды, которые предпочитают Scrum, часто выбирают Story Points, поскольку они буквально родились из Scrum и являются родными для этой методологии.
За годы нашего опыта мы пришли к такому выводу:

• Если точная оценка даты запуска более важна, чем соответствие бюджету, используйте сюжетные линии.

• Если бюджет важнее точной даты запуска, подумайте о часах.

Или, что лучше всего, комбинируйте и то, и другое.

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

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

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