Всем привет! Меня зовут Сергей Титков я процессный менеджер в компании Ростелеком ИТ. В этой статье я хочу рассказать про две хорошие техники помогающие в планировании.

Введение

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

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

У рассматриваемых техник есть ограничения:

• эти техники применимы для оценки сложности;

• эти техники применимы для оценки полезности;

• если их использовать для оценки трудоемкости, то вы получите крайне удручающую картину.

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

Небольшое отступление.

В разработке программного обеспечения очень многие понятия обозначают, то чем они не являются. Для нашего примера это сложность, трудоемкость и время исполнения (за сколько сделаем) – очень часто считается, что это тождественные понятия и надо их измерять в человеко-днях. И это очень типичное заблуждение. Эти три понятия, в общем случае, очень мало, между собой связаны. Это разные фасеты. Точно также как “горячий”, “кислый”, “зеленый” тоже разные фасеты. Не надо путать тёплое с мягким, а трудоемкость с длительностью.

Разберем чуть подробнее.

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

Трудоемкость – это сколько времени нам надо потратить на выполнение задачи. Именно на выполнение. Разовьем тему с бензовозом . Заполнить цистерну бензовоза с помощью насоса не трудоемко, а вот с помощью наперстка весьма трудоемко. Много времени потратим на хождение туда, сюда.

Время исполнения (за сколько сделаем) – считается, что это то же самое, что и трудоемкость. Но это не так. Главное отличие состоит в том, что это не время которое мы потратили на задачу, а время, через которое мы можем сказать, да задача полностью выполнена. Наполнить наш бензовоз с помощью насоса можно, скажем за 1 час, и если все так просто. То через час + небольшой запас, мы можем сказать – да все готово. Но ситуация меняется когда надо наполнить бензовоз можно только, например, в присутствии комиссии, а собирается она раз в месяц. По факту наполнять мы его будем все тот же час, но поскольку нам ждать месяц, пока комиссия соберется, то время исполнения и будет месяц.

Покер планирования (Planning Poker)

Напомню, мы оцениваем СЛОЖНОСТЬ! И только ее! Суть ПП, заключается в том, что оцениваем то что нужно оценить в наших любимых относительных единицах – стори поинтах попугаях. Точность в виде крылышка нам не нужна. Поскольку это относительные единицы, то такая оценка уникальна для команды. Удав он 38 попугаев или 5 мартышек или 2 слона. Не забывайте об этом! Численные оценки должны использоваться для сравнения задач внутри команды, но никак для сравнения между командами.

Классическая колода для ПП содержит следующие карты с числам: 1, 1/2, 2, 3, 5, 8, 13, 20, 40, 100

Картинка взята из статьи википедии. Взяли числа Фибоначчи и немного изменили Оригинальные числа Фибоначчи: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

Такая последовательность чисел порождает большую проблему. Между самой простой и самой сложной задачей пропасть в два порядка - это очень много, это как если самая простая задача это детская педальная машинка, а самая сложная это гоночный болид “формулы 1”. Практика показывает, что когда люди сталкиваются с таким разбросом по сложности, то выше определенного уровня сложности они не производят анализ, а просто говорят, да это сложно и все, мы так думаем, в процессе порешаем… Но это означает, что мы вместо того чтобы подсветить проблемы их переносим на этап реализации, вместо снижения рисков, плодим их. Поэтому если что то ушло за 20 условных единиц, то не надо думать – отправляйте на декомпозицию, бывает, что одну и ту же сторю дробят раза три или четыре - это нормально. Декомпозиция - это отличный способ борьбы с неопределенностью и как следствие с рисками. Бывает правда, что задача ну не хочет делиться на меньшие, поздравляю вы нашли проблему уже в постановке, вы нашли потенциального черного лебедя и одно это уже полностью окупает время затраченное на проведение сессии.

Рекомендованная колода

Числа
1, 3, 5, 8, 13, 21. Этого более чем достаточно. Двойка выкинута по рекомендации Паши Озолина, а он фигни плохого не посоветует. Дело в том, что люди часто спорят насчет того что 1, а что 2.
А про ½ вообще лучше промолчать.

21 особое число - на повторную декомпозицию

Фигура Эшера
Мы вообще не понимаем как это можно сделать! Потенциальный черный лебедь. Отправляйте задачу на полный цикл анализа/постановки.

Тривиально
Просто сделать. Например, включить принтер.

Чай
Запрос на перерыв

Правила проведения сессии покерного планирования

Первое и самое важное!

Руководителя быть не должно.

На сессии его быть не должно, даже в уголке, даже если молчит. Во первых - это снизит безопасность встречи. Во вторых, если руководитель будет, то он своими действиями и своим авторитетом начнет влиять на результаты и адекватность оценки сильно снизиться. Есть экспериментальное доказательство этого: эксперимент Милгрэма. Есть вариант, при котором на сессии присутствует руководитель или безусловный лидер. Если он высказывается и открывает свою карту только после всех обсуждений и переголосований.

Остальные:

• Голосуем в темную. Исключаем подстройку под общее мнение. Каждый кладет карту перед собой и все вскрываются одновременно. После каждой сессии карты мешаются. Лучше под столом. Раскладывать карты нельзя.

• Менее авторитетные участники говорят первыми. Первым говорит стажёр.

• Первыми высказываются участники с наибольшим разбросом. Причем сначала высказывается тот у кого наименьший авторитет в команде.

• Высказывания должны быть короткими:

  • максимум 3 минуты;

  • идеально 1 – 2 минуты;

  • байки не травим

• Оцениваем СЛОЖНОСТЬ, а не трудоемкость

• Численные результаты НЕ ЗАПИСЫВАЕМ в протокол. Если записали, это стало трудочасами и тут вы потеряли производительность в полтора-два раза. Более детально почему так происходит отлично раскрыто у ДеМарко в военных играх.

Как проводим

Есть множество отличных статей и видео на тему КАК проводить сессию покерного планирования. В этой стать фокус сосредоточен на том, ЧТО нужно сделать и чему нужно следовать, чтобы сессия была успешной. Поэтому очень тезисно, как проводить:

• говорим, что будем оценивать;

• даем людям подумать не больше 5 минут;

• вскрываемся :) по правилам описанным выше;

• проводим сессию торговли;

• приходим к соглашению.

Что делаем с результатами?

После проведения сессии покерного планирования у нас есть следующие артефакты:

• список того что оценивали с оценкой сложности;

• список проблем и возможных их решений.

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

Белый слон (White Elephant)

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

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

Правила

Случайным образом выбираем случайный элемент из тех что хотим оценить. И все остальные элементы сравниваем с ним. Элемент сложнее?

• Да - Ставим, например, выше.

• Нет - Ставим, например, ниже.

В общем случае получаем два множества:

• элементов больше(выше);

• элементов меньше(ниже).

К получившимся подмножествам применяем ровно такой же подход. Повторяем ровно до тех пор пока не получим список упорядоченный по возрастанию сложности. По сути это вариация на тему быстрой сортировки. Сложность метода n*Log(n).

При проведении торговли, какая задача проще, а какая сложнее необходимо придерживаться следующим правилам:

• голосуем в темную! Если вы используете чат то можете использовать следующее простое правило: в начале торгов все набирают + или - и по команде ведущего нажимают ввод;

• менее авторитетные участники говорят первыми;

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

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

Пример

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

Случайным образом выбираем первый элемент, с которым будем сравнивать все остальные. В нашем случае это EPIC 3.

Сравниваем EPIC 1 с EPIC 3

EPIC 1 проще или сложнее EPIC 3? Проводим сессию торговли. По результатам торгов решили, что EPIC 1 сложнее EPIC 3. Размещаем EPIC 1 правее EPIC 3

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

Для эпиков 1, 2, 4 необходимо повторить процедуру сортировки. Выбираем новый опорный эпик для сравнения, пускай это будет EPIC 1

Проводим процедуру сравнение эпиков 2, 4 с ним. В результате проведения анализа, выяснилось, что оба эпика сложнее чем EPIC 1, результат представлен ниже на картинке.

Нам осталось выполнить сравнение двух оставшихся элементов: EPIC 2 и EPIC 4 и решить кто из них сложнее. В этом сравнение победил EPIC 4. Вот наш список эпиков отсортированный по сложности. Далее мы трансформируем его список работ, как это сделать будет описано ниже, в разделе про квадрант Кантора.

Сравнение покерного планирования и белого слона

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

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

• Нужно оценить больше 10 элементов.

• Команда “слажена” - время на споры вокруг числовых значений минимальны.

• Могу обеспечить “безопасность” проведения сессии.

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

Белый слон

• Нужно оценить до 10 элементов.

• То что нужно оценить являются абстрактными вещами. Например есть две задачи: описать политику качества для атрибута защищенность и описать политику качества для атрибута сопровождаемость.

• Когда необходимо провести сессию быстро.

• Сессия должна быть публичной.

Квадрант Кантора

Мало оценить сложность того что мы сделаем, нам надо это еще и доставить. Доставляем мы обычно пачками(релизами). Ниже будет описано в как определить последовательность реализации. Квадрант Кантора можно применять как для итерации, так и для всего проекта в целом. И это неудивительно, поскольку он является подмножеством универсальных матриц 2Х2. Более детальное описание можно найти в книге: Murray Cantor Object-Oriented Project Management with UML.

У нас есть элементы упорядоченные по сложности, для того чтобы произвести планирование нам надо добавить второе измерение - важность. Время у нас детерминировано, мы либо поставляем в этом релизе, либо в следующем или следующих - это у же не столь важно. Фактически есть:

• без этого не выпускаемся (если спринты упакованы по времени, то “то невыполнение этой задачи означает невыполнение цели спринта и как следствие его перезапуск”);

• вполне может быть перенесена в следующий спринт

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

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

Без этого не выпускаемся + сложные(задачи берутся с хвоста списка).

• По тому как решаются такие задачи можем сразу понять темп релиза….

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

Без этого не выпускаемся + простые

• Делаем просто потому, что это надо обязательно делать.

• Все, сделали это - уже хорошо.

Реализуем в следующий релиз + простые(задачи берутся с головы списка).

• Стараемся сделать наверняка и побольше, выполняем обязательства.

Реализуем в следующий релиз + сложные

• Обычно до этого квадранта дело уже не доходит.

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

Заключение

Борьба с вариативностью начинается уже на этапе планирование работы. Постоянное и планомерное уменьшение рисков - вот основная задача менеджера. Ряд подходов могут не уменьшать риски, а наоборот их маскировать. Если мы оцениваем только трудоемкость задач, то мы не получаем информации о возможных рисках при реализации и у нас не будет информации когда задача будет сделана, и к сожалению такая оценка вводит в заблуждение. Я предпочитаю работать с рисками и поэтому стараюсь выполнять планирование исходя из сложности задач. White Elephant и Planning Poker хорошие техники для обеспечения риск ориентированного планирования. Для формирования последовательности реализации можно использовать квадрант Кантора, он прекрасно дополняет вышеописанные техники.