SCRUM. Джефф Сазерленд. Часть VI: как спланировать, оценить, дать задание и измерить динамику

Планирование

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

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

=> превратить кипу бумаг в понятные задачи
Как съесть слона? По кусочку.

1) Выписать все задачи, которые нужны для завершения
2) Определить, сколько работы потребует каждая (не как долго, а сколько работы)
3) Дописать критерии, по которым поймём, что задача выполнена
4) Определить приоритеты. Что принесёт проекту наибольшую ценность?
5) Начинаем выполнение плана с действительно важных вещей.

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

Оценка затрат

Сколько потребуется усилий, времени и денег на этот проект?
Люди плохо справляются с таким расчётами.
Но мы делаем хорошо другое - сравниваем один размер с другим (определяем относительную оценку)

Пример: размеры футболок (S, M, L) или собачьи баллы (чихуахуа, пудель, лабрадор)
Более серьезная оценка - последовательность Фибоначчи - 1, 2, 3, 5, 8, 13
Каждое число в этой последовательности - сумма двух предыдущих

Числа последовательность Фибоначчи достаточно далеки друг от другу => легче заметить различия.
Если человек оценит один объект как 5, а другой как 8, мы интуитивно почувствуем разницу. Но когда другой объект оценивается как 6, становится сложнее.
Мы лучше осознаём резкие прыжки из одного состояния в другое, а не плавные переходы.

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

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

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

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

Чтобы получить независимые мнения и общую оценку одновременно используйте метод Дельфи

Его можно совмещать с покером планирования
1) Каждому участнику даётся колода карт с числами Фибоначчи
2) Каждая единица работы, которая должна быть оценена, выкладывается на стол.
3) Участники оценивают единицу работы картой, но кладёт её на стол рубашкой вверх
4) После все одновременно открывают карты
5) Если расхождение не более чем на две карты (пять, две восьмёрки и тринадцать), то берём среднее арифметическое.
6) Если расхождение более чем на три карты, тогда те, кто положил самое большое и самое маленькое значение, объясняют, почему они так сделали.
7) Заново оцениваем ту же задачу.

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

Как правильно давать задания?

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

Перед началом задания на ответить на вопросы:
1) Для кого это делаю?
2) Что хочу сделать в первую очередь?
3) Почему выбранный персонаж хочет эту вещь?

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

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

Сценарий считается готовым, когда он соответствует критериям:
1) Завершённость, выполнимость, независимость
Абсолютно завершённый, осуществимый на практике и независимый от других историй
2) Открытость
Для общего обсуждения => любой участник группы может внести поправки
3) Ценность
Сценарий увеличивает ценность проекта для заказчиков, пользователей и других заинтересованных лиц
4) Оценочность
Удобен для оценки объёма работ
5) Лаконичность
Краткий, компактно изложенный и конкретный
6) Тестируемость
Должен пройти проверку на практике => заранее составить список критериев, которым должен соответствовать законченный сценарий

Динамика производительности

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

В этом поможет понимание динамики производительности команды.
Пользовательские сценарии состоят из задач => участники оценили их объём => в конце спринта подсчитываем все завершённые сценарии и общее количество очков, на которое они были оценены => узнаём текущую динамику => считаем несделанные сценарии => складываем очки => смотрим, когда завершим проект.

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

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

+вопросы для ускорения
1) Можем ли мы начать делать что-то иначе, чтобы ещё ускорить темпы?
2) Можем мы вычеркнуть что-то из списка заданий? Распределить часть заданий по разным группам?
3) Можно ли что-то не делать? Можем уменьшить объём работ?

Начать дискуссию