Александр Запорожцев пишет: ...что конкретно из ТОС должно встроиться в Agile-методы: мыслительные процессы, работа с ограничениями или управление потоками (буферы)?

... "что конкретно" могу только сказать, исходя из нашей практики. Из проекта в проект обязательно:

1. Организационная структура проекта
2. Перечень задач и оценка затрат на их выполнение (Product Backlog и Sprint Backlog)
3. Определение Ресурса Ограниченной Мощности (РОМ) портфеля проекта и РОМ-а конкретных проектов
3. Контроль на каждом Спринте РОМ-а (4-х шаговый метод)
4. Визуализация хода проекта при помощи Enhanced Burn-Down Chart
5. Методическая поддержка команды (прежде всего Скрам-мастера (Scrum Master)) в качестве планировщиков проекта, участие в Планирование спринта (Sprint Planning Meeting) при удержании в фокусе РОМ-а

Примечание: Для поиска узких мест - точнее РОМ-а - используем ТРИЗ, а никак не ТОСовские мыслительные процессы (для меня это более эффективный алгоритм )

Игорь Балакерский пишет: 1. Организационная структура проекта
2. Перечень задач и оценка затрат на их выполнение (Product Backlog и Sprint Backlog)
3. Определение Ресурса Ограниченной Мощности (РОМ) портфеля проекта и РОМ-а конкретных проектов
3. Контроль на каждом Спринте РОМ-а (4-х шаговый метод)
4. Визуализация хода проекта при помощи Enhanced Burn-Down Chart
5. Методическая поддержка команды (прежде всего Скрам-мастера (Scrum Master)) в качестве планировщиков проекта, участие в Планирование спринта (Sprint Planning Meeting) при удержании в фокусе РОМ-а

Большое спасибо за конкретность.
Один уточняющий вопрос - если речь идет о РОМ, то имеется ввиду некоторый поток. Здесь имеется ввиду поток работ или что то другое?
Кстати, формируется ли буфер проекта в том виде, как это предусмотрено в методе критической цепи? Вроде бы не должен, если используется Scrum.

Вальчук Виктор Васильевич пишет: Но кто сказал, что то, что создано для высокой неопределенности в результате не может использоваться в среде, в которой эта неопределенность невысокая?

Конечно можно использовать что то не по прямому назначению, но вопрос в том - рационально ли это?

Александр Запорожцев пишет: ....Кстати, формируется ли буфер проекта в том виде, как это предусмотрено в методе критической цепи? Вроде бы не должен, если используется Scrum. .

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

Игорь Балакерский пишет:

Александр Запорожцев пишет: ....Кстати, формируется ли буфер проекта в том виде, как это предусмотрено в методе критической цепи? Вроде бы не должен, если используется Scrum. .

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

У меня нет своего мнения по поводу буфера в методе критической цепи. Собственно поэтому я и задаю вопросы, чтобы понять. Если бы я сам мог ответить или найти информацию, то и вопроса бы не задавал.
А что по поводу РОМ?

CCPM вполне готовое решение. Единственное требует программной поддержки. Не надо недостоверные слухи о якобы "неприменимости ТОС" распространять. От того что Вы не изучили должным образом решение не означает, что оно ущербное.

А вот по SCRUM я бы спросил - какие такие исходные посылки требуют его использования? Невозможность планировать? Увы это неотличимо от НЕЖЕЛАНИЯ планировать. Реально проектов, где невозможно планировать - единицы. В основном же причины: некомпетентность, лень, страх. За все это почему то должен платить Заказчик и радоваться что экономит (ему так сказали, что с Agile дешевле).

Роман Пантелеев пишет: А вот по SCRUM я бы спросил - какие такие исходные посылки требуют его использования? Невозможность планировать?

Исходная посылка очень простая - классический подход к созданию систем предполагает разделение проекта на этапы и переход к следующему этапу возможен только после окончания всех работ по предыдущему этапу.
Эта идеальная схема на практике не работает. Отсюда переход на гибкие технологии - запускать все этапы параллельно с целью как можно раньше получить результат, и предъявить его потребителю.
Роман, а как Вы организуете свои проекты? Контролируете ли Вы РОМ в этих проектах?

Александр, классический подход (как я понимаю Вы имеете ввиду водопад) - это не о последовательности, а SCRUM - не о параллельности. И тот и другой позволяют делать параллельные задачи. SCRUM в отличие от водопада отказывается планировать дальше одного спринта, сваливая все будущие требования в кучу без какого либо временного отнесения. Строго говоря такую среду нельзя назвать проектом. Так как не известен конечный результат. Не известно окончание "проекта". Все что позволяет SCRUM - это управляя потоком задач иметь эффективную загрузку команды (команд). Это ближе к среде, в которой ограничение - ресурс и нам надо его эффективно использовать. Т.е. с точки зрения аутсорсинговой компании SCRUM хорош, так как помогает зарабатывать больше денег. Однако с точки зрения Заказчика - это отсутствие бюджета, отсутствие сроков, отсутствие конечной спецификации. Если затраты не существенны, на каждой итерации надо иметь какой то конечный результат, нам все равно что в итоге получится - то этот вариант подходит и Заказчику. Однако таких задач не так уж много - не просто так большинство Заказчиков вынуждают своих SCRUM-подрядчиков все чаще использовать fixcost даже несмотря на то, что они при этом могут переплатить.

Роман Пантелеев пишет: SCRUM в отличие от водопада отказывается планировать дальше одного спринта, сваливая все будущие требования в кучу без какого либо временного отнесения. Строго говоря такую среду нельзя назвать проектом. Так как не известен конечный результат. Не известно окончание "проекта".

Я бы не был столь категоричен.
Во - первых один из создателей SCRUM (Сазерленд ) считает scrum методом управления проектами.
Во - вторых, scrum даже включен в последнюю редакцию PMBOK (правда сам не видел)
В третьих, как известно SCRUM позволяет выполнить уникальную задачу (с уникальным содержанием) за ограниченные деньги и в ограниченное время.
Все критерии проекта налицо.

Водопад с этим не справляется. Критическая цепь - если только содержание все - таки как то будет более - менее определено. По крайней мере с небольшими вариациями.

А вот scrum, как известно, справляется.
Почему же ему отказывать в гордом звании "метод управления проектами"? Он справляется причем с такими проектами, с которыми другие методы не справляются.

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

-Полная чушь!

В SCRUM есть два набора задач:
1. Product Backlog - список задач на весь проект. На его основе рассчитывается по специальной методике оценки производительности команды количество необходимых спринтов, и это количество требуемых спринтов буферизируется
2. Sprint Backlog - список задач на ближайший спринт

В SCRUM- команде есть обязательно представитель подразделения, который является владельцем разрабатываемого продукта (Product Owner). Этот представитель Заказчика, который:
- формулирует требования и очерёдность реализации этих требований в промежуточных продуктах во времени
- приоретезирует и корректирует требования на каждом спринте и в целом по списку задач на весь проект
- несёт персональную ответственность за ценность требований для рынка/пользователя
отвечает за взаимодействие с рынком и т.д.
- (чуть ли не самое главное!) несёт персональную ответственность за сроки проекта, рассчитанных в количестве требуемых спринтов на основе Product Backlog

Так как в SCRUM реакция на изменения важнее, чем следование плану, то в этом методе приветствуется, когда заказчик и пользователи вносят новые требования , чтобы сделать продукт более конкурентоспособным. НО... каждый раз, когда реализуется "пользовательская история" (это отдельный и очень интересный термин), так вот, когда реализуется пользовательская история у неё появляется ещё несколько идей, а из этих идей ещё больше возникает запросов. Справиться с этим очень трудно, если не применять спец. методики. Мы используем Канбан (Доска Канбан), где любые новые требования "тянут" ровно ту задачу из Product Backlog , формируя задачи очередного спринта. При этом, в отличие от ТОС, где борьба со "студенческим синдромом" , в том числе, идёт поздним стартом задач, здесь всё наоборот - применяется ранний старт и предельно плотный набор задач в спринте. В таких условиях, если не предусмотреть специальные механизмы от перегрузки , если команда берётся за большое количество задач, чем может выполнить, то не выполнит и те задачи , которые могла бы выполнить. Канбан очень эффективный инструмент урегулирования этих противоречивых требований во времени и без Product Backlog - список задач на весь проект - этот механизм не работает и т.д.

Ну, в общем, совет могу только дать Роману просто поближе практически познакомиться с этим методом вовсе не отрицающим ТОС, а наоборот весьма эффективно встраивающим ТОС в свою ткань применения