Оценка задач и проектов

1.

Оценка задач и
проектов

2.

Определение оценки
● Оценка — прогноз затрат времени или денег. (Проект с
большой вероятностью может быть завершен в июне-июле)
● Цель — сформулированная бизнес-задача. (Программу
нужно показать на выставке 1 сентября)
● Обязательство — обещание предоставить функциональност
ь с заданным качеством к конкретной дате. (Проект будет сдан
не позже 1 августа)

3.

Оценка
В контексте разработки ПО оценка может определять:
Срок реализации бэклога продукта.
Размер работы, необходимой для
реализации бэклога продукта.
Команда разработки сначала оценивает общий размер элементов бэклога продукта,
затем измеряет темп реализации, то есть суммарный размер реализованных за
итерацию элементов. Только после этого она делит общий размер элементов бэклога
продукта на темп реализации и называет срок реализации всего бэклога продукта.

4.

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

5.

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

6.

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

7.

Story Points
Story Points («баллы истории», сторипоинты) — это единица измерения общего
относительного размера элемента бэклога продукта. Сторипоинты выражаются цифрами и
числами, например 5 Story Points (5 баллов).
При использовании этой единицы измерения команда
разработки присваивает определённое количество
Story Points каждому элементу бэклога продукта.
Величина исходных размеров не играет никакой роли.
Важны относительные размеры. Элемент, которому
присвоено два Story Points, должен быть в два раза
больше, чем элемент, которому присвоен один Story
Point.
Количество Story Points, присвоенных элементу,
представляет общий размер работы над этим
элементом.
Формулы определения размера не существует —
каждая команда сама определяет, как выставлять
оценки.

8.

Что влияет на размер работы?
Story Points отражают общий размер работы, который необходимо выполнить
команде разработки, чтобы реализовать элемент бэклога продукта.
Размер в Story Points — это сочетание:
количества работы,
сложности работы,
рисков и неопределённости, присущих
этой работе.
Чтобы оценить размер элемента бэклога в
Story Points, нужно сравнить этот элемент
с другим, уже оценённым элементом. При
этом сравнивать их нужно по всем трём
факторам.
Каждый из факторов сказывается на размере работы, который необходимо выполнить
команде, чтобы реализовать элемент бэклога. Чем больше количество работы, которую
необходимо выполнить команде, тем выше оценка. Чем выше сложность работы, тем
выше оценка. Наличие сопутствующих рисков и неопределённости также
повышает оценку элемента бэклога.

9.

Количество работы
Чем больше работы требуется выполнить
для реализации элемента бэклога
продукта, тем больше будет оценка его
размера в Story Points.
Например, команде нужно вспахать землю для будущих посевов. Сравним
количество работы: вспахать одну грядку vs. вспахать одно поле.
Суть задачи одинакова — вспахивание земли. Но чтобы вспахать одну грядку,
потребуется значительно меньше работы, чем для целого поля.

10.

Сложность работы
Чем сложнее работа, тем больше будет
оценка ее размера в Story Points.
Представим, что команде необходимо обработать два поля земли. В этой
ситуации количество работы одинаково. Однако команда должна учесть новые
обстоятельства: Вспахать одно поле, усеянное камнями и пнями, vs. вспахать одно
чистое поле
В первом случае на пути к достижению цели перед командой лежат камни и пни,
которые однозначно усложняют задачу. Команда должна учесть эту сложность в оценке,
увеличив количество Story Points.

11.

Риски и неопределённость
Чем выше вероятность риска и
неопределенности, тем больше будет
оценка ее размера в Story Points.
Перед командой стоит всё та же задача — вспахать поле, но появились новые обстоятельства: Вспахать
одно поле, которое команда уже вспахивала в прошлом году, vs. вспахать одно поле, которое команда никог
да не видела.
Поле может быть усеяно деревьями, и команде придётся сначала срубить их и только п
отом приступать к вспахиванию — риск.
Команда не может определить, насколько непредсказуемым окажется процесс вспахива
ния неизвестного ей поля — неопределённость.
Например, если заинтересованные лица не уверены в своих ожиданиях от реализации
элемента бэклога продукта, то эта неопределённость должна увеличить количество
Story Points, присвоенных этому элементу.
Или если реализация элемента потребует изменений в незнакомом для разработчиков
программном коде, то соответствующая степень риска должна увеличить количество
Story Points, присвоенных этому элементу.

12.

Процесс оценки
Оценка в Story Points всегда проводится с участием всей команды разработки. Каждый
из членов команды выдвигает своё предположение о размере работы над элементом
бэклога, основываясь на объёме и сложности задачи, а также учитывая риски и неопре
делённость.
В процессе оценки предположения разных членов
команды могут отличаться друг от друга.
Представим, что половина участников предложила
оценку «3», а другая половина оценку «5».
Самое важное — не усреднять оценку и не записывать
«4».
Разница в оценках может быть сигналом о том, что не
все поняли размер работы или кто-то заметил
обстоятельства, которые не видны остальным. В таком
случае следует дать каждому члену команды возможн
ость высказаться и обосновать своё мнение, после
чего снова предложить свои оценки.
Оценку в Story Points можно представить в виде
шкалы, которая отражает возрастающий размер
работы, и команда разработки пытается найти место
на этой шкале для каждого элемента бэклога продукта.

13.

Самая первая оценка
Если оценка проводится в первый раз, то определить относительную
оценку размера элемента бэклога продукта на данном этапе не
представляется возможным: ни один из элементов бэклога продукта
ещё не оценён.
В таком случае рекомендуется взять приблизительно
средний по размеру элемент среди прочих и присвоить ему
среднее значение из выбранной шкалы Story Points.
Например, команда разработки решила использовать для
оценки ряд Фибоначчи. Тогда среднему элементу она
может присвоить 4 Story Points. Предположим, что
следующий элемент оказался явно меньше. Сравнив его
со средним, команда может предположить, что он
примерно в два раза меньше первого, и присвоить ему
оценку 2 Story Points. И так далее.
Таким образом, после нескольких оценённых элементов
бэклога продукта команда сможет сформировать общее
понимание шкалы оценок в Story Points.

14.

Команда оценивает бэклог в течение проекта
Если команда уже проводила оценку, то каждый новый элемент бэклога продукта
будет оцениваться относительно ранее оценённых. Причём лучше работает не
поиск похожих по размеру элементов и присвоение аналогичной оценки, а
сравнение оцениваемого элемента с несколькими другими.
Такой метод называется триангуляцией.
Его суть заключается в сравнении оцениваемого
элемента бэклога с двумя другими: меньшего и больш
его размера.
Например, команде разработки необходимо оценить новую пользовательскую историю.
Внимательно посмотрев на неё, команда понимает, что её размер явно больше размера
дефекта с оценкой 1 Story Point, но меньше, чем пользовательская история с оценкой в
3 Story Points. Таким образом, команда может оценить новую пользовательскую историю
в 2 Story Points.

15.

Сравнение оценок разных команд
Представим две разные команды разработки, которые
используют Story Points для оценки элементов своих
бэклогов продуктов. У каждой из этих команд есть по
одной истории с оценкой 1 Story Point. Эти истории
имеют одинаковые оценки, но они не будут иметь
одинаковый размер относительно друг друга, потому что
их оценивали разные команды относительно разных
историй: первая команда относительно своих, а вторая
команда относительно других.

16.

Скорость команды разработки
Сумма всех Story Points, присвоенных каждому элементу бэклога продукта,
которую команда разработки реализовала в течение итерации, называется
скоростью (velocity). Скорость может быть фактическая и прогнозируемая.
Фактическая скорость отражает
размер всех элементов бэклога
продукта (функций, дефектов,
технической работы и работы для
получения знаний), которые
команда разработки успела
реализовать за итерацию.
Прогнозируемая скорость отражае
т предположение команды разработ
ки о том, сколько элементов бэклога
продукта она успеет реализовать в б
удущей итерации.
Например, если она реализует десять элементов, каждый из которых оценивается в 3 Story
Points, то её скорость будет равна 30. Если команда разработки выполнила работу размером
30 Story Points в течение предыдущей итерации, то она может предположить, что в следующей
итерации она также выполнит работу размером 30 Story Points.

17.

Айсберг бэклога продукта
Автор DEEP-критериев Майк Кон предложил метафору айсберга,
которая отражает состав бэклога продукта, соответствующего
этим критериям
Представим бэклог продукта в виде
и разделим его на четыре части:
Верхушка.
Средняя часть.
Подножие.
Подводная часть.
Чем ближе элемент к верхушке айсберга, тем выше его приоритет, тем больше о нём известно
команде разработки и тем больше он ей понятен. И наоборот: чем ближе к поверхности воды
находятся элементы, тем ниже их приоритет и тем больше связанной с ними неопределённости.
В подводной части скрываются ещё неизвестные команде разработки элементы. Их суть и прио
ритет непредсказуемы.

18.

Айсберг бэклога продукта
Размер элементов, расположенных в подводной
части, команде разработки неизвестен.
ВЕРХУШКА
Верхушку айсберга образуют небольшие
элементы бэклога продукта. Это самые
важные на текущий момент элементы.
Так же они более понятны команде и более
детально описаны.
Команда разработки включает в бэклог
итерации только элементы, расположенные
на верхушке айсберга.
Когда составляется бэклог итерации,
верхушка как будто «срезается». После
этого айсберг бэклога продукта напоминает
скорее плато.

19.

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

20.

Айсберг бэклога продукта
СРЕДНЯЯ ЧАСТЬ
Середину видимой части айсберга образуют элементы
среднего размера. Это менее важные на текущий
момент элементы бэклога, которые команда планирует
включить в следующие итерации. Они менее понятны
команде разработки и содержат меньше деталей, чем
элементы верхушки айсберга.
Посмотрите на элементы среднего уровня, направленные
на достижение целей заинтересованных лиц. Они слишком
большого размера, чтобы команда разработки могла
включить их в итерацию без вертикальной декомпозиции.

21.

Айсберг бэклога продукта
ПОДНОЖИЕ
У подножия видимой части айсберга расположены
элементы большого размера. Это элементы бэклога
продукта, которые команда разработки планирует
реализовать через несколько итераций. Они содержат
ещё меньше деталей, чем элементы средней части
айсберга.

22.

Айсберг бэклога продукта
ПОДВОДНАЯ ЧАСТЬ
Тёмные воды моря скрывают будущие элементы
бэклога продукта от команды разработки и даже
заказчиков и пользователей, но вполне могут в
какой-то момент всплыть на поверхность. Новые
элементы могут быть любого уровня: низкого, сре
днегоднего или высокого.

23.

Домашнее задание
Из задач, которые были выполнены в течение обучения
требуется:
1. Сформировать бэклог
2. Оценить задачи
3. Приоретизировать задачи
4. Распределить задачи по спринтам

24.

Thanks !