Зачем компании проводят Agile-трансформации

Антон Кобельков пишет: ....то Agile конечно проиграет перед процессами

Высказав какие-то свои или чужие умозаключения, вы задаёте вопрос, чтобы опираясь на эту вашу базу я стал что-то доказывать? )))

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

Вы опираетесь на дискурс авторов этой компании (во всех статьях) или на свой опыт?

Если открыть поиск на эту тему, то этот дискурс давно избавился от полемики и звучит почти как у Маяковского:

"Мы говорим Agile, подразумеваем Scrum, мы говорим Scrum, подразумеваем Agile )))

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

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

----------

Суть Agile и, в частности. Scrum (и да, Scrum это не весь Agile) в самоорганизации команды. То есть под каждую задачу команда устанавливает внутри себя систему отношений, оптимальную именно для этой задачи. Для следующей задачи будут другая система отношений. Это резко отличается от процессного подхода, в котором роли и отношения заранее определены.

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

Антон Кобельков пишет: Моя отрасль - управленческий консалтинг и организационное развитие. Плюс моими быстро становятся отрасли партнеров, которые приглашают меня поучаствовать в их развитии.

Это очень обще. Тогда можно было просто посмотреть примеры почему получается только Макет на выходе для методологии Srum, о которых писали в этой дискуссии и других по поводу разработки программных продуктов на этом ресурсе - введите в поиске Scrum )))

Agile появился практически одновременно с появлением средств RAD - Rapid Application Development - быстрая разработка приложений. Это позволяло уже на самом начальном этапе показывать результаты работы и уточнять ТЗ.

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

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

Иначе в простых задачах использование Scrum - это как микроскопом или телескопом гвозди забивать.

Антон Кобельков пишет: Суть Agile и, в частности. Scrum (и да, Scrum это не весь Agile) в самоорганизации команды. То есть под каждую задачу команда устанавливает внутри себя систему отношений,

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

На мой взгляд у всех методологий входящих в семейство Agile есть жёсткий каркас, и Scrum не является исключением.

Что такое ранняя поставка в Манифесте Agile - это Макет для обсуждения с заказчиком и передаче его потом в производство - Когда приходите сейчас заказывать встроенную кухонную мебель, и консультант строит для вас c помощью компьютерной программы Макет будущей кухни - это тоже Agile , когда мебельная фабрика вышла не "передовую" )))

И теперь можно заново прочитать по поводу сути Agile - Agile Manifesto:

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

2. Изменение требований приветствуется, даже на поздних стадиях разработки.

...

______________________

P.S Пишут: после каждого спринта в Scrum получают "работающую программу" ))) - читайте получаем работающий Макет, на котором можно что-то показать клиенту. Потом некачественный код в Scrum переписывается в основном заново - нет чудес. Программист не заинтересован писать качественный код - завтра будет всё иначе, и цели другие. Но есть и другие методологии Agile, где качественный код ценится с самого начала, но это уже не Scrum.

Кто там сказал про "пятница, вечер?"))) Уже среда, утро!

Если серьезно, о ЧЕМ вообще речь? (или о КОМ). Некая кампания, "Scrumtrek" разместила рекламную статью. Вы уже сходили на их сайт? Весьма любопытно. Я бы не отказался, чтобы моя компания стала КРУТОЙ.

Тем более, что они уже помогли:

Альфабанку

Альфастрахованию

Банку Home Credit

Минздравсоцразвитию

МТС банку

"Открытие" банку

и др.

Но вот поверхностная проверка говорит о следующем - ПУСТЫШКА.

Компания существует менее месяца. О чем мы разговариваем???

И ученые мужи всего бизнес-сообщества ломают мечи в схатках за "справедливость".

Андрей Радионов пишет:

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

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

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

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

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

"Вам шашечки, или ехать?"

Зачем Вы пытались убедить людей "ярлычком Agile", вместо того, чтобы говорить с ними на одном языке "повышение продуктивности" (правда я до сих пор не знаю, что это такое :-) ). Термины "производительность" и "эффективность" - я понимаю, они определены ГОСТами. "Продуктивность" - не понимаю.

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

Если Вы думаете, что 15-20 лет назад я говорил нефтяным компаниям "Сейчас я внедрю вам ИСО 9000 и будет вам счастье", то Вы глубоко ошибаетесь. Они даже не догадывались о том, что референтную модель управления я взял из ИСО 9001:2000 и ИСО 9004:2000 (+ 9000-1:1994). Главное было в том, что они видели понятные для них шаги по изменению системы управления, распределения полномочий, новую систему бюджетирования (из ИСО 9004:2000) и строгие правила отчетности + регламентацию работ. А откуда это было взято, никого не интересовало.

И наоборот, в городе С*** собственник загорелся идеей "внедрите нам 12-процессную модель APQC". 2 дня ушло на то, чтобы убедить его не гнаться за "звучным, заграничным best practic".

P.S. О том, "чей ярлычок круче" спорят только неофиты и апологеты. Профессионалы используют то, что лучше всего подходит для данной ситуации (кстати, однажды, для нефтяников пришлось применить IDEF5, эта нотация оказалась самой убедительной).

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

Вопрос в том, через какое время измерять результат - через 5 недель или через 5 лет. Да, практики могут вставить затычку проблемы, которая даст результат быстро, а в долгосрочной перспективе станет препятствием для развития. Так что, если заказчик грамотный, то теоретических дискуссий ему не избежать. А неграмотные так и будут получать затычки.

Лично я совершенно не удовлетворен состоянием "теории" в управленческом/организационном консалтинге, поэтому активно интересуюсь.

Андрей Радионов пишет:
P.S Пишут: после каждого спринта в Scrum получают "работающую программу" ))) - читайте получаем работающий Макет, на котором можно что-то показать клиенту. Потом некачественный код в Scrum переписывается в основном заново - нет чудес. Программист не заинтересован писать качественный код - завтра будет всё иначе, и цели другие. Но есть и другие методологии Agile, где качественный код ценится с самого начала, но это уже не Scrum.

Андрей, если прислушаться к здравому смыслу, выраженному Виталием Елиферовым - не навешивать ярлыки и не привязываться к авторитетам, то Вы описали ситуацию, которую я предлагаю решить следующим образом.

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

Задачей проектной группы является на основе, допустим уже установленного дискомфорта клиента в определенной ситуации разработать решение, позволяющее клиенту чувствовать себя более комфортно. Если решение готовится для бизнеса, еще и зарабатывать больше денег. На основании установленных данных можно составить дерево решений. Затем создать несколько прототипов решения задач. Для именно этой задачи - прототипом может быть техническое задание на программирование. Специалист по программированию, входящий в группу оценивает и описывает где, какими силами и в какие сроки может быть выполнен проект, с учетом всех нюансов имеющегося опыта по его внедрению. На основе этих данных можно составить представление о себестоимости проекта. Назначив цену, тоже с учетом опыта предыдущих проектов можно понять с каким из прототипов можно идти к клиенту у которого был выявлен дискомфорт. Показать клиенту решение задачи в виде описания того, каким образом ему будет облегчена ситуация. Сказать в какую сумму выльется это решение и готов ли он заплатить. В случае если он не готов платить, то либо это не тот дискомфорт и следовательно проект на который стоит тратить дальше усилия и ресурсы. Либо он скажет что еще нужно сделать чтобы он был готов заплатить запрашиваемую сумму. Либо скажет, что дискомфорт не такой большой и он оценивает её в меньшую сумму. Уточнив это можно снова вернуться к доработке или запуску в жизнь прототипа.