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

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

Применение Метода критической цепи для проектов по разработке ПО

В наборе инструментов Теории Ограничений (ТОС) есть Метод Критической цепи (CCPM). Это улучшенный метод календарного планирования проекта и контроля исполнения проекта обеспечивающий сокращение сроков выполнения проекта и своевременность его исполнения. А чем быстрее и в срок компания выполняет проекты тем больше компания сможет заработать за год.

Если принять что 70% проектов проваливает сроки из за чего менеджеров заменяют и компания терпит убытки, то применение CCPM выглядит очень перспективным.

Давайте посмотрим на предпосылки метода:

1. Инженеры нам сообщают профицитную оценку трудеомкости работ, чтобы их не били по голове за ошибки в прогнозах.
2. Закон Паркинсона работает: Всякая работа занимает все отведенное на неё время.
3. Студенческий синдром у всех есть – времени же профицитно заложили, можно начать попозже... за 10% до срока.
4. Ресурс одного инженера конечен, он не может делать две работы сразу.
5. Риски срабатывают. – Нам нужно как управлять проектом и принимать решения об изменении.
6. Частые переключения между задачами разных проектов приводят к потерям времени – нужно заново погружаться в контекст.
7. Объем проекта заранее известен и понятен.

И исходя из этих предпосылок есть правила:

1. Порезать оценку в два раза (вероятность завершения 50%) и не бить инженера по голове если он опоздал, а вместо этого
2. Каждый день спрашивать "Когда закончишь?" (Это может включить осознанность, и полученную цифру мы используем для расчета потребления буфера цепи.)
3. Последовательность работ учитывает последовательность выполнения работ на ресурсе.
4. Выделить самую длинную последовательность работ с учетом ресурсных связей и назвать её Критическая Цепь.
5. Выделить буфер цепи в размере 50% полученной оценки цепи. (Расписание проекта будет сжато на 25%, если говорить в терминах PMBoK)
6. Регулярно оценивать сколько мы потратили буфера критической цепи и корректировать проект на основе сигнализации буфера.
7. Выполнять проекты последовательно.

Кажется, что всё просто, есть предпосылки и метод противодействия им. И большая часть предпосылок есть в сфере проектирования зданий или создания типовых изделий. Но так ли это в сфере разработки программного обеспечения?

Давайте внимательно посмотрим на сам процесс разработки:

1. Разработчики ПО, как свободные художники, не любят никаких рамок, границ и процессов, если это несет угрозу их творчеству.
2. Они оптимисты, и всегда дают оптимистичную оценку трудоемкости работы. Пытаются уйти от оценки в часах в оценку в попугаях, Story points, или идеальных человеко днях. То есть, "За сколько я бы сделал задачу, если бы меня никто не отвлекал и я бы писал код в Потоке.". В среднем, точность оценки 70-80% от факта.
3. Если мы назначим оценку сверху, это убьет ответственность исполнителя. Ответственность умирает с незаметных "я так сказал", "я оценил, ты выполняешь" и потом приводит к "я ни за что не отвечаю".
4. Спонтанность. Очередность выполнения задач как это придумал менеджер их вообще не волнует. Разработчик будет делать задачу которая ему наиболее 'интересна', а не ту, которая лежит на критической цепи.
5. "Дальнесрочное планирование задач? Не, не слышал. " У заказчика может поменяться приоритет, поэтому конкретное наполнение спринта (1-2-3 недельной итерации) можем вообще меняться. Хотя общий объем работ примерно понятен.
6. Проектирование архитектуры это сложная задача, и не интересная, поэтому архитекторов мало. А значит, обязательно в процессе реализации, вылезет дополнительный объем работ.
7. А еще есть Дефекты! И это хорошо, если их будет 5% но может доходить до 90% работы. Но в среднем +30% к объему.
8. И при всем этом, жесткие сроки никто не отменял. Заказчик хочет получить работающий продукт в срок.
9. Если внедрен Scrum, XP или какой либо другой Agile метод, то есть ежедневные совещания "летучки" по фокусировке на задачах и целях. То есть "пинать балду" пару дней не получится, у команды возникнут вопросы.

Если кратко подвести итог, то получается, что:

1. Ресурс не известен – мы не можем построить саму цепь
2. Оценка оптимистична – нечего уполовинивать.
3. Объем проекта меняется
4. Фокусировка на "что делать сейчас" и так есть если внедрен Agile.
5. Управленческий резерв который закладывали куда-то дели.

Таким образом, ключевые предпосылки 1 и 7 использования метода Критической цепи не выполняются. Но сроки то жесткие, А мы как-то хотим управлять проектом. И метод критической Цепи решает проблему сроков.

Как бы так сделать когда нельзя, но очень хочется?

Если

1. Мы сделаем замену Ресурс = Инженер на Ресурс = Команда, где команда обладает емкостью, то вся цепь вырождается в простую последовательность работ.

2. Размер задач оставляем как оценены, но добавляем буфер проекта в размере 50% оцененного объема.

3. Учитываем точность планирования при построении расписания проекта.

То, мы получим, что буфер проекта будет реагировать только на частный случай вариабельности тем самым защищать расписание проекта.

В этом примере, мы очень сильно изменили сам метод Критической Цепи, от которого остался только Буфер проекта работающий по тем же принципам и вопросы для "летучки" фокусирующие на важном.

Итого

Мы получили не совсем то, что сказал Автор. А с другой стороны сама базовая идея удержания фокуса на сроках проекта и своевременная корректировка проекта на основе данных Буфера проекта выполняется. Что позволяет применить этот подход для выполнения ИТ проектов в срок.

Что есть в BIPULSE 

В BIPULSE реализовано

• Полноценный метод Критической  цепи для одного проекта. 
• Вышеописанный метод критической цепи для проектов высокой неопредленностью по объему работ. (ИТ проекты, Agile проекты)
• Вычисление расписания проектов с учетом загрузки ресурсов с автоматическим вычислением ограничения.
• Прогнозирование сроков заврешения проекта.