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

Это формулировка общего принципа проектного подхода, а не только Scrum. При выполнении любого проекта прежде всего нужно определить стейкхолдеров проекта и их требования. Если этого не сделать, то риск провала проекта резко возрастает. Scrum меняет только работу команды проекта, но никак не отношения со стейкхолдерами. Product Backlog представляет список требований стейкхолдеров. В обычном проекте на основе требований стейкхолдеров разрабатывается описание системы, чаще всего, в виде архитектуры - наиболее общщего описания системы. В Scrum описание не делается - все ограничивается Product Backlog, из которого выбираются те требования, которые реализуются в системе в ходе спринта.

Вальчук Виктор Васильевич пишет: Возьми лучше стартап. Какой нибудь интернет сервис. Заказчик - ты сам. Если ты точно знаешь, какой он будет, твой сервис в конце концов - ты скорее всего будешь банкротом. Тебе лучше всего создавать его шаг за шагом, постоянно проверяя очередные фичи на потенциальных клиентах. И постоянно реагировать на обратную связь, то есть делать уже не то, что представлял изначально. .

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

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

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

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

Вальчук Виктор Васильевич пишет: Возьми лучше стартап. Какой нибудь интернет сервис. Заказчик - ты сам. Если ты точно знаешь, какой он будет, твой сервис в конце концов - ты скорее всего будешь банкротом. Тебе лучше всего создавать его шаг за шагом, постоянно проверяя очередные фичи на потенциальных клиентах. И постоянно реагировать на обратную связь, то есть делать уже не то, что представлял изначально. .

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

Согласен с Александром. Но опять же: Скрам в этом случае просто производство, которое обслуживает проект. Максимум что тянет в скраме на проект - это спринт. Дима Егоров для софтверной конторы делал CCPM. У них была проблема набивки спринта задачами. Слишком мало - простой, слишком много - не исполняли. Софтверная контора сама обратилась к Диме, так как уже осознали проблему и видели решение в CCPM. В итоге в начале спринта строилась критическая цепь на основе оценок команды, создавался буфер спринта. Ежедневно оценка оставшегося времени. В итоге по словам Димы были довольны, так как начали попадать в спринт. И заранее видели проблему сползания срока.

Роман Пантелеев пишет: В итоге в начале спринта строилась критическая цепь на основе оценок команды, создавался буфер спринта. Ежедневно оценка оставшегося времени. В итоге по словам Димы были довольны, так как начали попадать в спринт. И заранее видели проблему сползания срока.

Критическая цепь длиной в 1-2 недели - это нонсенс.

Роман Пантелеев пишет: Виктор, дело не в ожиданиях клиентов (на улице дождь). А в низкой компетентности (не взял зонт) стартапера в предметной области. Соответственно когда и подрядчик также мало компетентен - они не могут спланировать проект. Так как просто не знают что надо делать. И вот они дружно в скраме (потоке исполнения задач) повышают свою компетентность. О том что скрам нужен при низкой компетентности я писал в самом начале. Когда Заказчик компетентен в предметке - он потребует фикс кост и фиксированные сроки. Если компетентен Подрядчик - тогда Заказчик платит ему больше и они делают проект - опять фикскост.

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

Дело в том, что существуют задачи, в которых изначально никто некомпетентен. Стартап этому хороший пример. Если кто - то в таких задачах изначально выставляет себя компетентным, успех как правило много хуже (9 из 10 стартапов проваливаются). Выигрывают только те, кто изначально планировал учиться по ходу (есть аналогия с детальными планами, не находишь?). Другой пример такой задачи - создание новыхх продуктов. Наверняка ьебе известно, что огромная часть новых продуктов продается очень плохо или вообще не продается. Думаю именно потому, что кто - то "был компетентен".
В любом обычном проекте есть стадия жизненного цикла "разработка концепции". Про нее обычно умалчивают (в CCPM тоже). А ведь она всегда каким - то образом, эта концепция появляется, хотя там изначально очень много неизвестных.
Существуют задачи продвижения продуктов (услуг), решение которых изначально неочевидно. Профессионалы ошибаются. Нужны пробы и ошибки, без этого никуда.
Существует наконец такая область, как продажи. Уже есть примеры - самоорганизующаяся команда, работающая по скрам (пробуем - ошибаемся - снова пробуем) гораздо быстрее находит решения, чем профессионал (но он как правило продавал раньше что то совершенно другое).
И да, существуют задачи, в которых и заказчик и исполнитель не совсем компетентны. А делать надо - Королевых, Артемиев Лебедевых на всех не хватает. Да и денег на них нет. Что делать ?

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

А называть это проектом или другим словом - дело вкуса. На мой вкус - они имеют на это право. Если это и производство, то какое то странное... С узаконенным браком. С узаконенным изменением спецификации. С узаконенным изменением бюджета. Все таки это ближе к проектам. Или это проекты+!

Вальчук Виктор Васильевич пишет:

Роман Пантелеев пишет: В итоге в начале спринта строилась критическая цепь на основе оценок команды, создавался буфер спринта. Ежедневно оценка оставшегося времени. В итоге по словам Димы были довольны, так как начали попадать в спринт. И заранее видели проблему сползания срока.

Критическая цепь длиной в 1-2 недели - это нонсенс.

Ну во первых почему 2 недели нонсенс?! Во вторых спринт был (если правильно помню) - месяц

Виктор, Вы подменяете «компетентен» на «думает что компетентен». Или Вы уже утверждаете, что некомпетентность и слепой поиск лучше чем реальная компетентность?! Может быть плохих программистов нанять и по СКРАМ это будет супер результат?!

Роман Пантелеев пишет: Виктор, Вы подменяете «компетентен» на «думает что компетентен». Или Вы уже утверждаете, что некомпетентность и слепой поиск лучше чем реальная компетентность?! Может быть плохих программистов нанять и по СКРАМ это будет супер результат?!

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

Возьми Red line и Green line. Компетентный остается на зеленой линии, "компетентный+" имеет возможность перейти на красную. Правильно? Опыт нам мешает. "Компетентный" проигрывает "компетентному+"

Развитие бизнеса - это последовательный отказ от устаревших убеждений, верно? В этом суть ТОС. Но в бизнесе это требуется довольно редко - может быть максимум раз в год, но требуется. То есть иногда надо быть некомпетентным, стать "компетентным+".

Тогда надо принять, что есть ситуации, в которых отказаться от устаревших убеждений нужно прямо сейчас. Здесь и сейчас, иначе - провал! Просто потому, что ты задумал делать что - то совершенно новое, в новых условиях (рынок изменился, но ты не знаешь насколько, потребности изменились, но тоже неизвестно насколько, технологии изменились, но ты даже не знаешь - какие именно нужны). Это и есть ситуация "проект+". Для выполнения "проектов+" надо быть готовым очень быстро понимать, от каких убеждений отказаться. Иначе не будет успеха в этих проектах. Иначе стартап обанкротится, продукт не будет продаваться, рекламная кампания провалится....

Те программисты, которые создавали скрам, были не самые плохие. Они были из числа лучших, "компетентных". Но продемонстрировали "компетентность+".