#дао_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

BIPULSE интегрируется с Bitrix24 по REST API и обеспечивает уровень управления проектами с надежным планированием и контролем поверх существующих задач.

По информации партнеров Bitrix24 с 1 января 2021 года меняются условия для бесплатных тарифов. REST API становится доступным только на коммерческих тарифах.

Если Вы планируете использовать этот режим интеграции с BIPULSE планируйте расходы.

Напоминаем, что в BIPULSE есть интеграции с разными системами https://bipulse.ru/integrations в двунаправленном режиме. Это обеспечивает старт с применением ресурсного планирования и Метода Критической Цепи (CCPM) на имеющихся данных.


https://www.facebook.com/bipulsetool/posts/3634023073351081

#bipulse