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

В масштабировании я ничерта не понимаю. Но полагаю можно масштабировать и скрам и канбан. Здесь много обсуждали масштабирование скрама. Короче, я полагал, что вопрос масштабирования перпендикулярен скраму-канбану. Одну фичу могут делать несколько команд в том смысле что у вас функциональные команды? Ожни пилят бэк, другие - фронт(просто пример)?

А есть шанс, что через некоторое время дефектов станет меньше?

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

В масштабировании я ничерта не понимаю. Но полагаю можно масштабировать и скрам и канбан. Здесь много обсуждали масштабирование скрама. Короче, я полагал, что вопрос масштабирования перпендикулярен скраму-канбану. Одну фичу могут делать несколько команд в том смысле что у вас функциональные команды? Ожни пилят бэк, другие - фронт(просто пример)?

Да именно так, фронт, бэк. Канбан масштабируется легко, скрам, ну, наверно, успешного не видел

Да именно так, фронт, бэк. Канбан масштабируется легко, скрам, ну, наверно, успешного не видел

Хм, если я правильно понимаю, scrum вы толком не внедрили, но уже думаете как внедрить КанБан. И КанБан внедряете только потому что хотите увеличить число исполнителей.

Продукт перешел из complex/complicated в simple

Получается в этом кейсе cinefin framework тут не причем. Тут другая цель. В очередной раз убеждаюсь, что лучше задать вопрос почему и зачем, чем додумывать кейс:)

Да именно так, фронт, бэк. Канбан масштабируется легко, скрам, ну, наверно, успешного не видел

Спасибо за ответы. Сколько я видел коллективов и продуктов, где копятся проблемы, везде была одна исходная проблема - забили на обоснованность фич, коммуникации и внутреннее качество. Потом чтобы хоть как-то справляться приходилось дико раздувать штат. В два раза, бывало в три раза, полагаю в одном месте я даже видел штат раздутый в 4 раза. Потому что изначально взяли в оборот "прагматичные" установки. Прагматичные в том плане, что "главное результат", причем, краткосрочный. Т.е. полное отсутствие стратегического видения и понимания необходимости тенденции к улучшению. Чем больше люди концентрировались на тактических интересах, тем больше теряли в стратегичесих. Чем больше теряли в стратегических тем меньше было свободного времени и сил, тем меньше возможностей было удовлетворить хотя бы тактические интересы. В общем, положенные в основу установки, не учитывающие стратегические интересы, всегда приводили к падению через 2-5 лет. Говорю только про свой опыт.

Я бы перевел на более формальный язык: Обилие фич находится в равновесии по Парето с такой группой атрибутов качества, как модифицируемость (ГОСТ 25010). Ситуация описана в "Цель-3". Просто один в один. Настоящей же проблемой является то, что практически все команды в начале разработки забивают на все атрибуты качества, кроме объема фич. И SCRUM приводит к феерическим результатам. Не, сначала все хорошо. Зато потом... Справедливости ради добавим, что чем больше фич, тем хуже юзабилити. Тоже самое равновесие по Парето. Ситуация описана в "Психбольница в руках пациентов."

А про то как создавать стратегию разработки похоже вообще ни в одной книге нет.

Я бы перевел на более формальный язык: Обилие фич находится в равновесии по Парето с такой группой атрибутов качества, как модифицируемость (ГОСТ 25010). Ситуация описана в "Цель-3". Просто один в один. Настоящей же проблемой является то, что практически все команды в начале разработки забивают на все атрибуты качества, кроме объема фич. И SCRUM приводит к феерическим результатам. Не, сначала все хорошо. Зато потом... Справедливости ради добавим, что чем больше фич, тем хуже юзабилити. Тоже самое равновесие по Парето. Ситуация описана в "Психбольница в руках пациентов."

Скрам даёт инструменты для адаптации, в том числе и возможность обдумать текущую ситуацию и понять, что нужен кардинальный поворот или просто настройка процессов для улучшения качества (скорректировать критерии готовности фичи, к примеру). Его вина лишь в том, что он позволяет держать команду в тонусе. Но нельзя в этом обвинять скрам. Но если скрам это только активности и артефакты без внутреннего наполнения (карго культ) то да, феерические последствия вполне достижимы ?

Скрам даёт инструменты для адаптации, в том числе и возможность обдумать текущую ситуацию и понять, что нужен кардинальный поворот или просто настройка процессов для улучшения качества (скорректировать критерии готовности фичи, к примеру). Его вина лишь в том, что он позволяет держать команду в тонусе. Но нельзя в этом обвинять скрам. Но если скрам это только активности и артефакты без внутреннего наполнения (карго культ) то да, феерические последствия вполне достижимы ?

Не. Я здесь на стороне лидера по созданию аджайл манифеста и одновременно создателя линейки аджайл методологий. Он говорит: "Каждому проекту свою методологию". Он прав. Есть условно три сотни инженерных и с сотню управленческих практик. Смотрим на команду, смотрим на проект, собираем пазл. Все.

Не. Я здесь на стороне лидера по созданию аджайл манифеста и одновременно создателя линейки аджайл методологий. Он говорит: "Каждому проекту свою методологию". Он прав. Есть условно три сотни инженерных и с сотню управленческих практик. Смотрим на команду, смотрим на проект, собираем пазл. Все.

Я ж не спорю. Но и связи между феерическими последствиями и скрамом пока не вижу.

Я ж не спорю. Но и связи между феерическими последствиями и скрамом пока не вижу.

Я скажу так, скрам хорошо маскирует проблемы. Вот то самое, держит команду в тонусе. В скраме нет инструмента выявления проблем, они есть в процессах куда он встроился. Но если процессы вовремя не перестроены, то увы.

Я скажу так, скрам хорошо маскирует проблемы. Вот то самое, держит команду в тонусе. В скраме нет инструмента выявления проблем, они есть в процессах куда он встроился. Но если процессы вовремя не перестроены, то увы.

В чем заключаются основы скрама? И какие его элементы какие основы реализуют?

Я скажу так, скрам хорошо маскирует проблемы. Вот то самое, держит команду в тонусе. В скраме нет инструмента выявления проблем, они есть в процессах куда он встроился. Но если процессы вовремя не перестроены, то увы.

Вот это поворот

Коллеги. Это обсуждение не на день и не на два. И статьи тут тоже не хватит. Рекомендую книгу https://www.ozon.ru/context/detail/id/19730649/ С переводом названия книге точно не повезло, если кому удобней, читайте на английском. На мой взгляд, лучшая из книг по эджайлу. И внедрять скрам без чтения этой книги, право не стоит.

"Быстрая разработка программного обеспечения" Алистер Коберн

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

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

То что скрам коучи его продают, не означает, что он не работает :)) Пока я вижу хорошее такое непонимание скрама.

Но Agile, конечно, больше чем Scrum. И лучше случать коучей, которые продают Agile, а не Scrum. Немного по-ёрничаю, простите )

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

"Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения" Алистер Коберн - тоже крайне рекомендую.

http://rsdn.org/article/Methodologies/compeople.xml

"Что меня удивило во всех этих проектах? То, что они ясно свидетельствуют о следующем: * Практически любую методологию можно с успехом применять в каком-нибудь проекте. * Любая методология может привести к провалу проекта. * Тяжеловесные методологии тоже могут успешно применяться в работе. * Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией."

Спасибо! Собственно я с вами и не спорю, я это уже писал раньше. Напомню контекст. Я выяснил немного обстоятельств работы @SeaGullLingvinston, понял, что есть проблемы в понимании скрама. Собственно, не была реализована адаптация. И теперь предполагаю, что переход на канбан не решит проблем, а просто проблемы перестанут зудеть. К примеру, очень удобно переходить на канбан, если не удается завершить спринты вовремя. Или очень удобно переходить на канбан, если пожар и скоуп спринта удержать неизменным не получается. Про молотки, рубанки и гвозди - очень все очевидно. Про это и говорить особого смысла нет. Я, чаще всего, нахожусь в контексте стартапа или, как минимум, разработки нового продукта. Для меня скрам очень хорош.

Книжки в гудридс себе добавлю.

Спасибо! Собственно я с вами и не спорю, я это уже писал раньше. Напомню контекст. Я выяснил немного обстоятельств работы @SeaGullLingvinston, понял, что есть проблемы в понимании скрама. Собственно, не была реализована адаптация. И теперь предполагаю, что переход на канбан не решит проблем, а просто проблемы перестанут зудеть. К примеру, очень удобно переходить на канбан, если не удается завершить спринты вовремя. Или очень удобно переходить на канбан, если пожар и скоуп спринта удержать неизменным не получается. Про молотки, рубанки и гвозди - очень все очевидно. Про это и говорить особого смысла нет. Я, чаще всего, нахожусь в контексте стартапа или, как минимум, разработки нового продукта. Для меня скрам очень хорош.

Я бы так не сказал :) Понимаем мы скрам, но для нас это фреймворк, который мы используем в контексте наших процессов. Когда мы вышли за границы применимости фреймворка, мы переходим на другие инструменты. Мы же энтерпрайз. Переход вызван сменой фазы развития продукта. Решения принимаются не на пустом месте, у нас есть метрики процессов. И видно что поскольку лавинообразно возрастает количество сквозных работ, спринты перестают работать и начинают мешать. Это одна из причин.

"Мы же энтерпрайз." – первый раз слышу, чтобы эту фразу кто-то произносил в положительном контексте.

Вот это поворот

Я пошел за попкорном :)

Меня лично прет от Скрама,тем, что он светит все проблемы как прожектор у пограничников. ничегошеньки не ускользает.

Выше писали о том, что он скрывает проблемы.

Так и я об этом

не Вскрывает, а скрывает

Накину ещё немного - Scrum is Your Mother-in-Law =)

Он всегда укажет на твои промахи, сразу же =)

У Сергея кажется ватерфолл замаскированный под скрам.

От тещи ничего не скроешь :))))

даааа ;)

Выше писали о том, что он скрывает проблемы.

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

Хорошо сказал. Я так не умею.

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

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

Разве что чисто механически

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

с этим не поспоришь :) более того - при майндсете, который подразумевается за манифестом уже и не так важно Scrum у вас или Kanban - люди будут использовать их, потому что хотят ценность нанести и уважают друг друга со всеми теми проблемами и талантами, которые они накопили за долгие годы.

с этим не поспоришь :) более того - при майндсете, который подразумевается за манифестом уже и не так важно Scrum у вас или Kanban - люди будут использовать их, потому что хотят ценность нанести и уважают друг друга со всеми теми проблемами и талантами, которые они накопили за долгие годы.

Тык, если майндсет уже такой как в манифесте, то это стадия ри. Конкретные преактики, пожалуй, уже не имеют значения.

Тык, если майндсет уже такой как в манифесте, то это стадия ри. Конкретные преактики, пожалуй, уже не имеют значения.

вот тут не соглашусь. Ри это все же стадия овладевания навыком. Майндсет != навык. Ты можешь быть офигенно дружелюбным и очень гореть продуктом, набрать правильных людей в компанию, но с инструментами, с тем КАК это все делать каждый день у вас могут быть проблемы. И у меня в практике и такие компании были. Им гораздо проще, чем другим - они быстро всё впитывают, не ломают практики в угоду своей действительности и в итоге получают от них максимум, как и задумано

вот тут не соглашусь. Ри это все же стадия овладевания навыком. Майндсет != навык. Ты можешь быть офигенно дружелюбным и очень гореть продуктом, набрать правильных людей в компанию, но с инструментами, с тем КАК это все делать каждый день у вас могут быть проблемы. И у меня в практике и такие компании были. Им гораздо проще, чем другим - они быстро всё впитывают, не ломают практики в угоду своей действительности и в итоге получают от них максимум, как и задумано

Спасибо.

Книжки в гудридс себе добавлю.

Ловите. Регулярно просят:

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

Лет десять или двенадцать с того разговора прошло. Но я все больше убеждаюсь: "Если говорить правду, то слона не продать."

Сергей, вы напрасно по одному опыту экстраполируете характеристики на всех остальных.

Только правду. Вскрывать все. Все работает. Проверено.

Прозрачность один из китов. Открытость и смелость в ценностях. Они меняются. Они становятся другими. Магия .....

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

Есть очень мало «проектов», в которых серам не работает. Есть очень много проектов, в которых серам не смогли завести из-за уверенности в уникальности проекта и необходимости немедленной адаптации :)

*скрам. Писать с мобилки неудобно

Есть очень мало «проектов», в которых серам не работает. Есть очень много проектов, в которых серам не смогли завести из-за уверенности в уникальности проекта и необходимости немедленной адаптации :)

Плюсую данного автора. Если начинать с "не, нам чистый скрам не подойдёт" и начинать его "адаптировать" с первого спринта получается не скрам а ...

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

А ещё прикольней, когда через энное время адаптации приходят к классическому скрам.

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

Определенный набор инструментов и есть фреймворк.

Плюсую данного автора. Если начинать с "не, нам чистый скрам не подойдёт" и начинать его "адаптировать" с первого спринта получается не скрам а ...

А Кен Швабер тоже так считает? По моим сведениям - нет.

Определенный набор инструментов и есть фреймворк.

А его определил?)

А его определил?)

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

А Кен Швабер тоже так считает? По моим сведениям - нет.

При всем уважении к Кену Швайберу, его понимание "можно адаптировать" очень отличается от понимания "можно адаптировать" людей, которые, собственно, и начинают адаптировать, а потом жаловаться, что "скрам на нашем проекте не работает".

А Кен Швабер тоже так считает? По моим сведениям - нет.

в скрам гайде этот момент описан вполне четко Швабер его автор

Скрам "не работает" в хаотик. Но в хаотик и проекта как такоового нет, там вообще мало что "работает".

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

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

Ооо.Я где-то определил набор инструментов?)

Ооо.Я где-то определил набор инструментов?)

нет, в изначальном сообщение речь шла про "фреймворк"

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

Есть очень мало «проектов», в которых серам не работает. Есть очень много проектов, в которых серам не смогли завести из-за уверенности в уникальности проекта и необходимости немедленной адаптации :)

Вопрос в границах применимости фреймворка. Больше пяти сотен человек, поставка прогоамно аппаратного комплекса раз в пару лет. Внутри все по ieee. Предлагаете адаптировать под фреймворк?

Сергей, вполне.

+Объем кода, если распечатать - фура.

Более того, я в похожих условиях это делал :)

50 000 дефектов в бэклоге.

Более того, я в похожих условиях это делал :)

А зачем?

Более того, я в похожих условиях это делал :)

Я про деньги. Я про рои

Потмоу что это эффективней, чем, гм, более традиционные методы работы с таким проектом: меньше затраты, более четко отделяется RnD от разработки, тайм ту маркет ниже, возможность анализировать результаты и вносить изменения в соответствии с требованиями рынка - выше

ROI это свойство конечного продукта, а не "проекта".

Что такое традиционные методы? И что такое традиционные методологии, о которых так много говорят?

Лет десять или двенадцать с того разговора прошло. Но я все больше убеждаюсь: "Если говорить правду, то слона не продать."

А на протяжении 10 лет что то у тренера поменялось?

PMBoK, классический SDLC, Six Sigma, RUP

PMBoK в первую очередь

классический SDLC, кстати, это тот самый "водопад", с которым так любят воевать адепты agile :)

ROI это свойство конечного продукта, а не "проекта".

Голратт с вами не согласен. ROI опоеделяется изменением 3 (трех) финпоказателей фирмы. Все.

Сергей, при всем уважении, нельзя применить ROI к проекту. ROI возникает, когда продукт вышел на рынок.

Проекция ROI даже в теории ограничений, требует учета рынка и применяется для _операционной_ деятельности системы.

Не для проекта изолированно.