Одним из факторов успешной работы команды разработки является эффективность оценки времени выполнения задач.
Это в том числе сильно влияет и на бизнес, т.к. прогноз времени выполнения необходим для планирования поставки функциональности пользователю.
Принято измерять задачи в часах или в стори пойнтах (Story Points).
Сама оценка может проводится индивидуально разработчиками, тим-лидом либо на активностях — типа покера планирования (Planing Poker).
Если в плане оценки часами все понятно — ставим ожидаемое время выполнения задачи в измеряемых единицах — часах. То в случае стори пойнтов мнения могут расходиться, однако обычно подразумевается сравнение очередной задачи с эталонными задачами, которые появляются эмпирическим путем.
Но речь сейчас не о самих стори пойнтах, а о методологии оценки задачи. В целом даже не важно, в каких единицах.
Другой способ
На своем опыте я убедился, что оценка задач методом планинг-покера не эффективна. Создает кучу лишней возни и лишних обсуждений. Да, возможно такая активность позволяет находить скрытые вопросы в задачах или дает еще какой-то ощутимый профит команде (если она это видит). Мой же опыт был хоть и веселым, но не эффективным.
В этой статье хочу поделиться методом оценки задач, которую вывел для себя и успешно пользуюсь последние 5 лет.
Такую простую и эффективную методику я назвал «Матрица оценки задач».
Работает практически мгновенно и на практике показывает попадание в ожидание — 85-100%. Без лишних обсуждений и движух.
Итак, как оценить задачу.
Матрица оценки задач
Моя матрица — двумерная, размером 3 на 3.
Первый фактор — знакомство с предметной областью.
Разворачивается в 3 градации:
- Работаю сейчас с этой областью.
- Работал с этой областью.
- Не работал с этой областью.
Второй фактор — размер задачи.
Разворачивается в 3 градации:
- Небольшая.
- Средняя.
- Большая.
В итоге имеем такую матрицу:
Теперь эту матрицу заполним единицами измерений. Возьмем, например, часы.
Матрица ограничена временем выполнения задачи в 24 часа, т.е. в 3 стандартных рабочих дня по 8 часов. Почему? Потому что если задача требует бОльшего количества времени, то ее нужно разбить на более простые задачи, ну вы в курсе.
Логика работы матрицы
Матрица оперирует двумя факторами (или измерениями, если хотите): знакомство с компонентом(и) и объемом задачи.
Если с объемом задачи все понятно, то о рабочей области можно сказать несколько слов.
Что требуется для выполнения задачи? Открыть редактор кода и начать писать код? Нет, на практике так не работает, конечно же. Прежде чем решить задачу, нужно вникнуть в контекст:
- осознать техническое задание
- оценить зону аффекта
- изучить используемые компоненты
- открыть нужные файлы в редакторе
- загрузить смысл открытых файлов в оперативную память мозга
Когда эти пункты выполнены, вы начинаете писать код. Не раньше.
Возвращение джедая
Стало быть, если вы сейчас работаете в определенной области кода и поступает новая задача, входящая в нее, вы без труда сможете ее сделать, т.к. не будете тратить время на вышеуказанные пункты.
Если вы когда-то уже работали в этой области, то вам потребуется потратить время на пункт:
- загрузить смысл открытых файлов в оперативную память мозга
Если же вы никогда не работали в этой области, вам сперва придется потратить время на пункты:
- оценить зону аффекта
- изучить используемые компоненты
а времени может уйти немало, если проект большой.
По поводу возвращения в контекст задачи и в состояние концентрации вы можете почитать в книге «Человеческий фактор» — Листер Тимоти, ДеМарко Том.
В совокупности с объемом решаемой задачи, фактор нахождения в контексте и формируют ожидаемое время выполнения задачи.
Выполнение задачи вовремя
Да, конечно, есть еще зависимость времени выполнения задачи от грейда и, кажется, стори пойнты нам позволяют оторваться от исполнителя и бла бла бла.
Но что происходит на практике? На практике мы просим Кешу выполнить задачу, спрашиваем, сколько времени ему нужно, а потом спрашиваем Кешу — почему он не уложился в срок и сколько ему нужно еще времени. А все потому, что Кеша не использовал матрицу оценки задач, а стоило бы попробовать!
Пожалуй, на этом остановлюсь. Думаю, смог описать метод и указать на его смысл. Пробуйте его использовать, калибруйте под свой проект и под свои единицы измерения, пишите фидбек в комментариях.
И кстати, еще на эффективность оценки задачи влияет Архитектура. Возможно потом дополню статью, связав метод оценки и с ней. 3-е измерение в матрице, так сказать.
На этом все. До новых встреч!
—
Читай релевантные статьи: Архитектура.
Изучай основы создания приложения в открытом курсе: Анатомия приложения.
—
Подписывайся на мой канал в соц. сетях:
Telegram: https://t.me/cantfailcode
Dzen: https://dzen.ru/cantfailcode