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

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

Почему мы делаем ошибки

Есть несколько объективных причин, по которым мы ошибаемся в оценке времени и пропускаем дедлайны:

  • Люди совершают ошибки. На мой взгляд, причина номер один в том, что люди склонны делать ошибки. Мы не роботы, мы можем отвлекаться, уставать, болеть, не уделять достаточно внимания важным деталям.
  • Непонимание и недостаток информации. Еще одна важная причина - непонимание того, что следует делать. Обычно это происходит потому, что описание задачи слишком короткое, и вы просто не можете получить более подробную информацию, когда делаете оценку.
  • Игнорирование рисков. Всегда есть риск, что вы потратите на задачу больше времени, чем ожидали. Просто попробуйте вспомнить, когда в последний раз вы потратили несколько часов на небольшую 15-минутную задачу, и вы поймете, что может пойти не так, если числа будут в тысячах часов.
  • Новое сложно оценить. Признаемся, сложно оценить новое (исследования, сторонние технологии и API). И это еще одна причина ошибок в оценке.
  • У людей разные знания и опыт. Когда вы работаете в команде, иногда легко забыть, что не все разработчики обладают одинаковыми навыками и опытом. Кто-то мог быть хорошим и плохим в чем-то. Например, вы являетесь мастером интеграции api, и ваш коллега может быть действительно хорош в создании структуры модели данных. Кроме того, существует разница между младшим и старшим разработчиком.
  • Ответственность. Последняя распространенная причина, которая больше применима к менее опытным разработчикам. Это происходит, когда разработчик не имеет полного представления о том, насколько важно число, которое он дал.

Не бойся просить о помощи

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

Оценка времени - это не предсказание

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

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

Давайте поговорим о Story Points / размере футболки, кто представляет?

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

Плохой способ использования этой концепции: 1 сюжетная точка может представлять диапазон от 4 до 12 часов, 2 сюжетной линии - 10-20 часов и так далее.

Определите базовую историю

Story Points в Agile - это сложная единица, которая включает в себя три элемента: риск, сложность и повторение.

Время концентрации

Важно определить имеющееся у нас время для концентрации в день; Например, в день без встреч у меня есть только 6 часов, доступных исключительно для решения задач, из этих часов я создаю 2 блока по 3 часа, и это блоки концентрации, которые У меня за день.

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

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

Матрица оценки

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

Попробуйте добавить задачу обнаружения, чтобы лучше понять объем работы.

BumpUps - Тестирование

  • Базовый уровень → Отсутствие дополнительных усилий по тестированию сверх стандартной практики.
  • +1 шаг → Усилия по тестированию превышают стандартную практику и равны усилиям по реализации.

Подъемы - Риск

  • Базовый уровень → Все риски, не связанные с этой заявкой, приняты, устранены или улучшены.
  • +1 шаг → Риск от низкого до умеренного принимается и принимается как часть этой задачи.

В обоих случаях задача переходит от XS → S всякий раз, когда необходимо увеличить шаг. Условия принадлежат и приняты относятся к риску ROAM (Scaled Agile Framework -SAFe-)

Включите другие действия помимо программирования.

Другая часть оценки - риски застройщика. Помните, что вы не тратите 100% своего времени на программирование. Помимо кодирования, вы обычно занимаетесь множеством вещей:

  • Ознакомиться с документацией и описанием задачи;
  • Разверните и потратьте время на проверку кода.
  • У вас есть встречи или онлайн-звонки с командой и / или клиентом.
  • Вы, вероятно, читали какие-то ресурсы, чтобы улучшить свои навыки в целом.
  • И, конечно же, вы пьете кофе / чай, едите печенье, читаете и отправляете электронную почту, беседуете с коллегами в течение дня.

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

Заключение

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

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

Пример репозитория



soyjuanmalopez / матричная оценка
1 XS Незначительный, одна строка заменяет или не получает ресурс Обиусно, ноль неизвестных Упрощенно, я мог бы сделать многие из них за… github.com



использованная литература