Agile-оценка в Scrum? Story Point и покер планирования

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

«Сначала сделайте это, а затем ищите лучшее», поэтому в индустрии программного обеспечения уже давно бытует мнение.

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

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

Проблемы

Шахта разработчика

«Это очень просто. Это не должно занять слишком много времени?»
Премьер-министр сказал вам сегодня: «Я должен сдать его до завтра. «Сделайте это, прежде чем искать качество»
ПМ тебе послезавтра сказал: «Почему качество программы такое плохое?»
Когда он задержался, другие коллеги: «Как вам нужно проводить столько времени? Это готовый код для справки. У этого есть хороший нижний слой, чтобы использовать. Почему ты не спросил меня?
Другие коллеги: «Мне нужен только один день, почему вы потратили столько дней?»
«Это здравый смысл! Если мы не упомянем требование, Вы должны знать, что делать.

шахта PM/PO

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

Результат

Ролевая враждебность: блок спроса и блок разработки больше не должны поставлять продукт, который может принести пользу пользователю, а атаковать друг друга в своих собственных целях, чтобы избежать необходимости нести дополнительные обязанности. Поэтому и сложилась ситуация, что блок спроса и блок разработки — это вообще не единая команда.
Ответственность: команда думает, что «я не ошибаюсь, поэтому задержка не является моей ответственностью», вместо того, чтобы расставлять приоритеты в потребностях пользователей.
Замораживание спроса: Разработчики вынуждены менять свои требования из-за сжатых сроков, в противном случае они будут задержаны, и ответственность будет возложена на разработчика. Следовательно, либо требуется сверхурочная работа, чтобы произвести что-то, скрывающее множество ошибок, либо сделать какую-то фичу, не отвечающую потребностям пользователей; и то, и другое снизит удовлетворенность пользователей.
Низкое качество: Статус PM часто выше, чем у разработчиков. Поэтому, чтобы уложиться в срок контракта или избежать штрафов и т. д., команде будет предложено «сначала сделать, а потом искать лучше», но в конечном итоге часто «сначала нет времени искать хорошее». ». Накопление технического долга увеличивается, и результатом является реальная модель цепочки ответственности, которая несет наибольшую ответственность и затраты в самом конце цепочки. Таким образом, команда похожа на стек, разработчики не могут поддерживать один за другим, что является одним из факторов, почему инженеры проектных компаний часто имеют высокую текучесть кадров.
Повышение веса кода: для оптимизации эффективности для оценки рабочего времени всегда используется позиция наиболее знакомого человека, поэтому человек, который лучше всего знаком с модулем и процессом, всегда будет заниматься соответствующими требованиями. . В конце концов, только эти люди могут поддерживать свой собственный код, это как ящик Пандоры, никогда не знаешь, какие коровы и призраки выбегут после открытия. Потому что черный ящик часто бывает грязным, а компания понятия не имела, как решить эту проблему. Вы также надеетесь, что он не уйдет, иначе часть кода не будет понята.

Решения

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

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

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

Единицей, используемой для оценки сложности спроса, здесь является стори-пойнт (относительная единица), а не рабочее время (абсолютная единица). Для этого есть несколько причин:

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

2. «Относительное» оценить легче, чем «Абсолютное»: если вы посмотрите на рабочие часы, вам нужно будет оценить абсолютное число, и вам нужно будет подумать о деталях реализации в процессе оценки. Чтобы использовать Story Point для оценки сложности, вам нужно только сравнить размер с другими требованиями.

Например, трудно однозначно сказать, что «Башня высотой в несколько метров», но проще указать, что «Эта Башня примерно в 2 раза выше того здания».

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

Хотя сложность спроса часто положительно связана с рабочими часами, из-за разных условий реализации все еще возможно иметь функцию с высоким стори-пойнтом, а спрос на рабочее время ниже, чем стори-пойнт. Но в Scrum вы можете использовать итерационный спринт, чтобы оценить, какую сложность может переварить каждая спринтерская команда. Для PO / PM вместо оценки неудачного хода времени лучше оценить более точный и объективный ход времени, чтобы они могли с первого раза понять, насколько далеко от ожидаемого хода проекта. Если ресурсы ограничены, как расставить приоритеты требований или обратиться за другой поддержкой.

Затем объясните различные аспекты решения.

Когда

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

ВОЗ

Только люди, которые делают вещи, чтобы оценить вместе: два ключевых момента:

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

какой

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

Покерная карта и последовательность Фибоначчи

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

Как показано выше, разрыв между 8 и 13 составляет 5, а разница между 13 и 20 — 7. Однако как это связано с оценкой сложности спроса? Мы не на уроке математики.

Характеристики оценки, связанные с последовательностью Фибоначчи

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

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

Поскольку большой цифровой разрыв велик (отношение разности между двумя передними и задними значениями ряда Ферми близко к 1,618), можно избежать оценки того, «равна ли эта сложность 20 или 21». «Хотите 13, хотите 20, хотите 40.

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

Специальные номера в покерной карте

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

0 может означать, что это требование вообще не нужно выполнять или оно уже выполнено.
Бесконечность означает, что потребность ясна, но число, превышающее максимальное число, указывает на то, что потребность должна быть разделена на несколько требований меньшего размера.
Знак вопроса указывает на то, что требование неясно и требует пояснений или разъяснений от PO/PM.

Как

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

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

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

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

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

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

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

Почему

Такой способ оценки имеет ряд преимуществ:

Человек, который работает вместе, принимает решение о разумном и объективном результате оценки, имеет чувство сопричастности и не имеет претензий.
Результатом решения является консенсус между PO и Team, что уменьшит возникновение ситуаций «око за око» в будущем.
Каждый может понять требование. В будущем каждый может действовать как человек, выполняющий требование. Когда требуется поддержка, люди также могут помогать или поддерживать друг друга.
Прежде чем вы это сделаете, вы можете прояснить ту часть требования, которая не ясна, и ту часть, которая вызывает сомнения.
Прежде чем вы сможете это сделать, вы можете найти лучший и наиболее эффективный способ работы в команде.
Если вся команда не является ненадежным человеком, это число отражает тот факт, что оценка разделяется командой, и PO может понять разрыв между спросом и оценкой.
Сравнивая относительный размер сложности между требованиями, будущий PO сможет пообещать, какой объем работы может быть выполнен за одну итерацию, и будет база для сравнения.

Заключение

Благодаря описанному выше процессу оценки такое решение является открытым, прозрачным, объективным и согласованным. На две роли:

Для ЗП/ПМ:

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

Для команды:

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

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