Александр Филонов пишет: но и вопрос резковат.

А тут, я прошу поподробнее))) А какую форму вопроса вы бы порекомендовали?

Ну хорошо, согласен - я погорячился и допустил некорректность. Согласен, хотя сути это не поменяет.

Если вы за точность (а это всегда хорошо), тогда вернусь к заявлению Александра.

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

Слово "получится" пишется без мягкого знака.

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

Далее: "ТОС это метод устранения проблем (5 направляющих шагов)". Что это? Вы не знаете, что 5 направляющих шагов - это инструмент работы с ограничением? Какие к черту проблемы?

Далее: "ТОС это способ управления потоком" Так все - таки ТОС это способ управления или нет? В предыдущем предложении вы утверждали что нет! Это во- первых. Во - вторых неверно утверждать, что "ТОС это способ управления потоком". Можно сказать, что "ТОС в том числе способ управления потоком". В предыдущем предложении вы совершенно верно заметили, что это еще и метод анализа проблем (и метод принятия решений, я бы добавил. И не только).

"Опасность сопоставления ТОС и SCRUM в формальном соответствии разных по сути процессов. Аналогия может обмануть.)))" О боже мой, как страшно! Сами придумали и сами пугаете! Теперь у вас ТОС - это процесс, а не метод? SCRUM теперь процесс, а не метод? Два предложения назад было по- другому. Тогда сначала определите, что такое ТОС как процесс и SCRUM как процесс, а потом пугайте. И с чего вы вазяли, что кто - то формально их сопоставляет? О каком использовании аналогии вы говорите?

Вальчук Виктор Васильевич пишет: Значит вы утверждаете, что "SCRUM - это управление проектом, а ТОС - это не управление". Но вы же прекрасно знаете, что метод управления проектами по критической цепи (CCPM) - это часть ТОС!

Согласен, что в моем провокационном вопросе много неточностей. Однако, я не понимаю зачем рассматривать SCRUM, если в ТОС есть решение управление проектами CCPM. Что SCRUM добавляет к CCPM или что CCPM добавляет в SCRUM?
Нашел ответы в Вашей статье "Критическая цепь и SCRUM – общие черты и глубокое различие". В статье делается вывод "Если есть решение, значит, есть проблема. Если решение – scrum, то в чем была проблема? Что именно убрал scrum? На мой взгляд – иерархию".
Таким образом, Вы увидели в появлении SCRUM отказ от иерархии в управлении проектами. Если проанализировать Agile манифест, то в нем говориться о следующих принципах:
1. Люди и взаимодействие важнее процессов и инструментов.
2.Работающий продукт важнее исчерпывающей документации.
3.Сотрудничество с заказчиком важнее согласования условий контракта.
4.Готовность к изменениям важнее следования первоначальному плану.
Как мы видим - ни одного слова про иерархию.
Специалисты считают, что гибкие подходы в разработке появились как способ преодоления недостатков простейшей модели жизненного цикла проекта - водопадной модели, когда работы выполняются последовательно. В итоге появились более совершенные модели жизненного цикла проекта - спиральная модель, горбатая диаграмма. Самым важным в этих моделях был переход от чисто менеджерского подхода к инженерному, когда в центре внимания находятся не этапы проекта, а те практики, которые используются.
Таким образом, сегодня наибольшую эффективность имеют подходы обоснованные на управлении жизненным циклом. Наиболее полно это подход рассмотрен в стандарте OMG Essence.

Александр Запорожцев пишет:

Вальчук Виктор Васильевич пишет: Значит вы утверждаете, что "SCRUM - это управление проектом, а ТОС - это не управление". Но вы же прекрасно знаете, что метод управления проектами по критической цепи (CCPM) - это часть ТОС!

Согласен, что в моем провокационном вопросе много неточностей. Однако, я не понимаю зачем рассматривать SCRUM, если в ТОС есть решение управление проектами CCPM. Что SCRUM добавляет к CCPM или что CCPM добавляет в SCRUM?

CCPM - решение для многопроектных сред. SCRUM - решение для однопроектной среды (одна или несколько команд работают над одним проектом).
CCPM - решение для сред с определенным результатом (или результат имеет невысокую неопределенность).
SCRUM создан как раз для высокой неопределенности в результате.

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

Есть мнение, что ТОС - это метод, последовательно ставящий под сомнение убеждения компании (если помните мой доклад, то он об этом). Так вот, очередное убеждение, которое пришла пора поставить в ТОС - это то, что решения не могут принимать обычные работники, их должны принимать начальники. Я пришел к выводу (на практических примерах), что без отказа от этого убеждения в некоторых случаях уже не обойтись. И именно такое убеждение опровергает методика SCRUM (и не только она). Как она это делает? Внедряя работу в самоорганизующихся командах.

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

Все, что я сказал о CCPM, можно сказать о ББК, управлении запасами и т.д.

Александр Запорожцев пишет: Как мы видим - ни одного слова про иерархию.

Читайте дальше (принципы SCRUM ):
"Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им".
"Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд".

Кроме того, посмотрите на практику SCRUM:
"Работа выполняется автономной, самоорганизующейся крос – функциональной командой".
"Команда является единственным участником разработки и отвечает за результат как единое целое".
"Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта".
"Разработчик – единственная роль в команде разработки, несмотря на специализацию".
"Задачи для выполения целей спринта формулирует команда"

В любом методе, любом подходе есть скрытые исходные посылки. Их надо видеть.

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

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

Вальчук Виктор Васильевич пишет: "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им".

Кто должен создать условия и обеспечить поддержку?

Александр Запорожцев пишет: ///
Кто должен создать условия и обеспечить поддержку?

Александр, правильно ли понимаю, что у вас нет опыта практического использования и целевой подготовки по SСRUM ? Просто вопрос из области обучения, а на форумах зарекся уже кого-либо чему-либо учить

... навеяло. Градский, разговор со Стингом: «Вы из России, очень приятно» – и так с опаской смотрит. Спрашивает: что вам больше всего понравилось в концерте? Отвечаю: концерт очень понравился, а больше всего понравилась пьеса с переменным размером – 7/8, 9/8 и 11/8. Как в русской музыке. Стинг говорит: да, как у Стравинского. Я говорю: да, как в «Весне священной». Стинг: да, как в такой-то части. Отвечаю: да, как в аллегро. Он мне: «Я знаю, кто ты такой и чего стоишь»

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

Александр Запорожцев пишет: ///
Кто должен создать условия и обеспечить поддержку?

Александр, правильно ли понимаю, что у вас нет опыта практического использования и целевой подготовки по SСRUM ? Просто вопрос из области обучения, а на форумах зарекся уже кого-либо чему-либо учить

Вы совершенно точно определили - практического опыта использования SСRUM у меня нет. Я больше вам скажу - я пока не вижу, что SСRUM чем то отличается от того метода, который я использовал в разработке своих программных систем (15 лет работал начальником отдела АСУ). Какие то элементы гибкого подхода мы использовали, но все это рождалось из практической потребности разработки, а не как использование модной практики. Свой подход я изложил в книге "Системный подход в проектировании организационно-технических систем". На лекциях по системной инженерии я даю SСRUM как один из видов жизненного цикла среди многих других видов. В каждой проектной организации должна быть разработана своя версия гибкого подхода, учитывающая особенности проектов этой организации. Считаю обязательным проводить адаптацию известной практики для конкретных условий.
Ваш вопрос возможно был навеян моим вопросом о том, кто должен создать условия. Задавая вопрос, я имел ввиду вполне конкретную практику жизненного цикла проекта - лидерство. Системное лидерство - это отдельная тема для разговора и эта практика никак не соответствует наиболее распространенному пониманию лидерства.