#метод 26

== Планирование спринтов ==
=== Правила планирования задач ===

1. Для каждой задачи НЕ может быть задан срок начала и конца завершения задачи. Это приводит к микроменеджменту и не имеет смысла, так, как нарушение сроков предыдущей задачи, сразу делает неактуальными сроки текущей.
2. Задача может быть оценена в идеальных человеко-днях. Где «идеальный человеко-день» это максимально продуктивный день, когда никто и ничто не отвлекает исполнителя от основного занятия.
3. При оценке задачи задаются оптимистичные и пессимистичные оценки длительности выполнения.
4. Сроки могут быть заданы только для проектов.
5. В объем проекта выполняемого уже заложен буфер расписания и буфер содержания.
6. Все задачи выполняются исполнителем последовательно и не могут быть остановлены.

Примечание:
При оценке задачи в “единицах сложности” - у вас не будет аргументации в случае если время выполнения задачи превысит ожидаемое. Ибо нельзя сравнивать “попугаев” с днями.

=== Правила планирования спринта ===

Спринт, итерация – минимальный квант времени (ритм) контроля выполнения проекта, синхронизации проектов и поставки результата. Планирование спринта - это планирование работ каждой команды в спринте и определение коротких, тактических, целей.
При планировании объёма работ в спринте необходимо решить несколько задач:
1. Определить, какие именно задачи необходимо делать
2. Определить, сколько задач сможет сделать команда за спринт.
3. Определить общую, понятную цель которую должна достигнуть команда в рамках спринта.

#дао_agile

Планирование загрузки ресурсов

Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.

==
§ 11
Тридцать спиц собираются в одной втулке, но использование повозки зависит от пустоты между ними. Форму и глину применяют при изготовлении сосуда, но использование сосуда зависит от пустоты внутри. Делают дверные проемы и створки дверей, чтобы построить помещение, но использование помещения зависит от внутреннего пространства. Получается, что оплачивают то, что есть, пользуются же тем, чего нет.
==

В применении к ИТ-проектам означает: Мы не должны планировать рабочее время инженера на 100%, и должны учитывать его свободное время. Эти пустоты дадут возможность Инженеру самому решить как улучшить Продукт с инженерной точки зрения. И этим мы сэкономим время проекта. Хороший инженер создает Продукт только тогда, когда ничего не делает руками. Инженер оценивая трудозатраты на выполнение работы, оценивает лишь то время, которое он планирует потратить на работу руками. но очень сложно оценить то время, когда он не должен работать руками.

#дао_agile

Внедрение Agile-подходов

Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.

==
§ 71

Знание собственного незнания—это прекрасно. Ужасно же «знание» невежды. Потому что знающий, что он болен,— на пути к выздоровлению. Таков мудрец—выздоравливает потому, что сознает что болен. Только поэтому.
==

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

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

#дао_agile

Управление изменениями

Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.

==
§ 36

Кто желает вдохнуть, непременно должен сначала выдохнуть. Кто желает ослабить, непременно должен сначала укрепить. Кто желает избавиться от чего-либо, непременно должен сначала это возвысить. Кто желает что-либо захватить, непременно должен сначала от этого отказаться. Это и называется тончайшим знанием: гибкое берет верх над жестким; слабое— над сильным. Рыба должна держаться на глубине. Так и в государстве: его самое острое оружие должно быть скрыто от людских взоров.
==

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

Отсутствие Закона - Анархия. Отсутствие Правил - неопределенность. Инженеры не любят неопределенность (Предприниматели в ней живут). В неопределенности теряется производительность.

2. Перед тем как менять правила, необходимо снизить требования по скорости поставки результатов. Боязнь ошибки и страх увольнения самое большое препятствие на пути внедрения изменений. Только бесстрашные камикадзе могут преодолеть эти страхи и вывести Продукт на новый уровень. Обычно таких мало.

На злобу дня )

Опубликовано видео с прошлогоднего РИТ++
Рассказываю о методе.

Как часто у вас возникает дилемма между "Нужно утилизировать ресурс" и "Нужно достигнуть текущие цели максимально быстро?"

https://tinyurl.com/y6xl7j8s

#метод 27

— Планирование содержания спринта ==

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

Факторы влияющие на планирование

1. Мощность команды - весь объем работы который может выполнить команда за спринт. Мощность команды вычисляется на основе прошлого опыта (исторических данных) или экспертной оценкой.
2. Резерв мощности для задач не влияющих напрямую Реализацию функционала поставки, но влияющих на снижение стоимости поддержки Продукта.
3. Резерв мощности на неожиданные задачи
4. Резерв мощности на неопределённость содержания в случае если задачи в спринте не имеют типовых решений и требуются исследования.
Правила планирования спринта
1. Все задачи спринте одной команды должны касаться одного проекта.
2. Команда должна иметь возможность гарантированно успеть выполнить все взятые на спринт обязательства по поставке коммерчески ценного результата.
3. Команда должна иметь возможность выполнять работы по техническому совершенствованию Продукта.
4. Команда должна иметь понятную цель на спринт.

Алгоритм планирования содержания спринта:

1. Определите, максимальную мощность команды на основании 2-3 завершённых спринтов.
2. Определите, какой резерв нужен для незапланированных задач и рисков. В среднем это 20-30% мощности команды.
3. Определите, какой резерв нужен для выполнения технологических задач. Этот резерв может составлять от 10 до 80% максимальной мощности в зависимости от технологической зрелости команды.
4. Определите ключевую цель спринта.
5. На остаток мощности команды - доступную мощность команды, выберите приоритетные задачи имеющие ценность для бизнеса, результат выполнения которых вы хотели бы получить по завершению спринта и соответствующие цели спринта.
6. Определите правила вытягивания задач из нераспределенных.

Коллеги, BIPULSE стал еще доступнее. Программа вошла в Реестр российского ПО
https://reestr.minsvyaz.ru/reestr/162655/?sphrase_id=230199

Эшелонирование проектов.

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

В описание Метода "Pulse Management" крако указано про наличие ресурса-ограничения и эшелонирование.

Но покажу на примере:

* Проект "А" имеет критическую цепь длительностью 100 дней, стандартный буфер цепи 50 дней. Итого, полная пессимистичная длительность проекта (с буфером) составит 150 дней. В этом проекте есть ресурс-ограничение - Р , который, задействован в последней задаче (для простоты).

* Проект "Б" имеет критическую цепь длительностью 10 дней. И "Р" в нём начинает первую задачу. Это очень короткий, но очень важный проект. А так как он короткий, то мы должны его сделать точно во время.

Мы точно знаем, что "Р" не закончит работу на проекте "А" точно на 100-й день, это значит что сообщать кому-то, что мы начнем проект Б на 101 день - будет заведомым провалом, так как ресурс "Р" будет недоступен на 100-й день. Но мы точно не знаем когда на самом деле освободится "Р".

Поэтому, мы должны сдвинуть начало проекта "Б" на размер буфера проекта "А" - 50 дней , чтобы начать проект на 150 день с вероятностью 90%.
Сдвиг проекта "Б" обозначим как "буфер доступности ресурса" , Мы можем отслеживать расход этого буфера на основании потребления буфера проекта "Б", или на основании плановой загрузки ресурса "Р" . А если мы его разметим на 3 зоны по "светофору" то мы сможем начать беспокоиться вовремя чтобы не поставить под угрозу выполнение проекта Б.

также см. пункт 9. методички
https://pulsemanagement.org/rules-schedule/

В основе Метода "Pulse Management" лежит Теория Ограничений, она прошита не только как реализация Метода Критической Цепи для проектов с изменяющимся содержанием но и в мероприятиях Метода.

Дательней о применимости ТОС в Agile подходах и Scrum , которые совместимы с Методом я я написал в заметке: https://www.facebook.com/alexey.vasilyev.773/posts/2639248306316305

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

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

https://www.facebook.com/pulsemanagement.org/posts/3071441799640839

Мы выпустили новый модуль в BIPULSE - Финансовое планирование

Как работать с модулем рассказали в видео-инструкции
https://youtu.be/HUB7zVbWMFg

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

BIPULSE - управление проектами на основе национальных Принципов
Сегодня в 19:00 МСК пройдет вебинар Проектной Ассоциации. Успейте зарегистрироваться и принять участие!
https://projects.management/view-event.html?EventID=W25z11z2020T1900#Morning=1