Комментарии 16
вопросами сертификации по SAFe занимается компания Scaled Agile, Inc.
Как раз об этом рассказывал Dave Thomas в своем выразительном критическом выступлении
Смысл Agile разработки вовсе не в сертификации, KPI, общем планировании и единых планах. Смысл сводится к четырем простым слоганам выраженных в манифесте.
Бесспорно, равно как и то, что Agile есть прилагательное, и если его употреблять как прилагательное, можно многих ловушек избежать.
Если Agile — это в первую очередь идея, то SAFe — инструмент. Не надо его возводить в ранг чего-то высокого. Т.е. сертификация SAFe лишь на уровне понимания фреймворка. В этом плане он честнее чем CSM.
Если интересно, посмотрите на их сайте, все что там написано немыслимо постичь, без принятия образа мышления описанного в манифесте, ну и без понимания Lean.
Я читал дважды за последнее время его статью, видео не смотрел раньше, посмотрел сейчас, спасибо, не все сказанное на видео было в блоге.
Есть один момент, которым я был недоволен раньше и укрепился в своем мнении сейчас. Dave критикует индустрию «Agile», но совершенно не признает, что именно благодаря ей, настоящих последователей гибких методик стало очень много, т.е. Людей которые поняли в чем идея. Да, побочно, что есть люди которые считают Agile отличной методикой. Но так бывает с любым знанием, что оно искажается.
Поэтому, когда кто-то ругает инструмент, или людей которые его придумали, и огорчается, что он не это имел в виду, мне становится неприятно. Черт возьми, если считаешь, что все исказили и неправильно делают, помоги, объясни как надо. А если не знаешь как, то не мешай тем кто пусть и топорными методами, с точки зрения критикующего, но все же помогает, т.е. реально результаты проектов разработки улучшаются.
Все кто в теме знают, что на большую организацию эти подходы не ложатся просто так. Есть спрос на это знание и опыт. Его кто-то и как-то заполняет. Очевидно, что под копирку это знание не работает. То вот KPI какой-то мешается, то планирование сложное.
Можно всегда что-то улучшить.
Может быть с этого все же можно начать? Сделать на одном проекте, посмотреть как получилось, понять что не так, что-то изменить, повторить цикл. Так родится собственный набор правил конкретной организации. Я не прав?
Или дело в зависти?
Если Agile — это в первую очередь идея, то SAFe — инструмент. Не надо его возводить в ранг чего-то высокого. Т.е. сертификация SAFe лишь на уровне понимания фреймворка. В этом плане он честнее чем CSM.
Если интересно, посмотрите на их сайте, все что там написано немыслимо постичь, без принятия образа мышления описанного в манифесте, ну и без понимания Lean.
Я читал дважды за последнее время его статью, видео не смотрел раньше, посмотрел сейчас, спасибо, не все сказанное на видео было в блоге.
Есть один момент, которым я был недоволен раньше и укрепился в своем мнении сейчас. Dave критикует индустрию «Agile», но совершенно не признает, что именно благодаря ей, настоящих последователей гибких методик стало очень много, т.е. Людей которые поняли в чем идея. Да, побочно, что есть люди которые считают Agile отличной методикой. Но так бывает с любым знанием, что оно искажается.
Поэтому, когда кто-то ругает инструмент, или людей которые его придумали, и огорчается, что он не это имел в виду, мне становится неприятно. Черт возьми, если считаешь, что все исказили и неправильно делают, помоги, объясни как надо. А если не знаешь как, то не мешай тем кто пусть и топорными методами, с точки зрения критикующего, но все же помогает, т.е. реально результаты проектов разработки улучшаются.
Все кто в теме знают, что на большую организацию эти подходы не ложатся просто так. Есть спрос на это знание и опыт. Его кто-то и как-то заполняет. Очевидно, что под копирку это знание не работает. То вот KPI какой-то мешается, то планирование сложное.
Можно всегда что-то улучшить.
Может быть с этого все же можно начать? Сделать на одном проекте, посмотреть как получилось, понять что не так, что-то изменить, повторить цикл. Так родится собственный набор правил конкретной организации. Я не прав?
Или дело в зависти?
странная система комментирования, :( хотел доразвить мысль, и подкорректировать неясности, сказала, что поздно. Подозрительно напоминает системы helpdesk \ crm где ничего нельзя менять… Или после нескольких минут это все куда-то отсылается ;)?
посмотрите на их сайте, все что там написано немыслимо постичь,
И это не случайно. Чтобы постичь (а тем более внедрить) нужно нанять консультантов. И обязательно сертифицированных. А то будет agile не православный.
Я согласен, что последователей стало много, Scrum это модно. Но вот насчет
«людей которые поняли в чем идея» не уверен. Во всех организациях, в которых я наблюдал внедрение Scrum, менеджеры начинали с утреннего standup и planning сессий. При этом все остальное они оставляют как было. Ни вам создания cross-functional команд и делегирования им полномочий. Ни сосредоточения у product owner'у права расставлять приоритет. Ни retrospections. Вишенкой на торте обычно является совмещение роли product owner и scrum-master.
В общем, не согласен я с аргументом «зато agile идет в массы». Идет смещение акцента с ценностей в сторону инструментов. А смысл agile как раз в изменении ценностей. Прежде чем внедрять новые инструменты (не забыв демонтировать старые) менеджеры должны переосмыслить свое понимание процесса. Принять ценности. Это первично.
… объясни как надо.
Вот он и объясняет)
Сделать на одном проекте, посмотреть как получилось, понять что не так, что-то изменить, повторить цикл. Так родится собственный набор правил конкретной организации. Я не прав?
вы объяснили в точности то, что предлагает Dave. И заметьте, для того чтобы донести суть, вы не использовали SAF.
Определенно с менеджерами Вам не очень везло.
К слову, не смотря на то, что на сайте действительно описано как-то сложно, на деле все очень логично и просто. Уровни есть в любой компании, просто для Agile — методологий о них пару слов вскользь. Частично поэтому SAFe кажется необычным и громоздким, ну и также, конечно, за счет масштабов.
К слову, не смотря на то, что на сайте действительно описано как-то сложно, на деле все очень логично и просто. Уровни есть в любой компании, просто для Agile — методологий о них пару слов вскользь. Частично поэтому SAFe кажется необычным и громоздким, ну и также, конечно, за счет масштабов.
Во всех организациях, в которых я наблюдал внедрение Scrum, менеджеры начинали с утреннего standup и planning сессий. При этом все остальное они оставляют как было. Ни вам создания cross-functional команд и делегирования им полномочий. Ни сосредоточения у product owner'у права расставлять приоритет. Ни retrospections. Вишенкой на торте обычно является совмещение роли product owner и scrum-master.
Согласен, Некоторые люди полагают, что гибкость заключается в том, чтобы внедрить Scrum частично. Жаль, что они не поняли идею.
Но есть ведь и другая сторона:
Организация включающая хотя бы 100 разработчиков с менеджерами, директором, руководителями PM'ами, и иже с ними, закосневшая в годовых релизах и управляемая прямой иерархией не сможет воспринять эти четыре ценности. Даже если владелец послушал Германа Оскаровича, и очень хочет чтобы его компания стала феноменально гибкой.
Иногда нужно пнуть, чтоб полетело. За это и платят деньги. Я как-то имел бесплодный диспут с разработчиком банка, я ему про идеи Scrum, как это работает в маленькой команде, про психологию самоорганизации, а он все гнет про то, что как это без руководства и утверждения планов, непорядок…
Ну не виноваты разработчики SAFe, что в манифесте нет ответа на то, как масштабировать эти принципы на большую организацию и как подтягивать уровень зрелости людей. Эволюционно получается медленно. Революционно — плохо. Что делать-то?
… Идет смещение акцента с ценностей в сторону инструментов.
Смещение от ценностей в сторону инструментов присутствует, но с SAFe это никак не связано, тут скорее жажда наживы, как и всегда было до этого, ну вот хоть с ITIL. Или наивная надежда, что начнем как нибудь, а там стерпится — слюбится.
вы объяснили в точности то, что предлагает Dave. И заметьте, для того чтобы донести суть, вы не использовали SAF.
Мне приятно, разумеется, что я как-то сумел переформулировать цикл Деминга.
Но как PDCA применить к большой организации, предположим вы приглашенный гуру подписавший манифест и вот перед вами сидят эти самые, полные скепсиса, 100 разработчиков, весь управленческий состав и PMO. И вы рисуете этот круг и говорите — вот цикл, и четыре ценности в манифесте. Это все что нужно. Стряхиваете мел с рук и говорите немому залу — какие будут вопросы. Думаю будет тишина, затем шум отодвигаемых стульев.
Люди не смогут этому следовать, в это нужно поверить и желательно попробовать как ребенок, под контролем, провести ретроспективу с опытным гуру, осознать ошибки в восприятии предмета, еще раз, и еще, и еще. И так полетит. CSM тренинг не напоминает? Ну а SAFe, чуть сложнее.
Может быть это я наивен и не видел трэш тренингов по Scrum где ценность и идея отодвинуты на задний план? Мне даже интересно есть ли такие примеры?
Организация включающая хотя бы 100 разработчиков с менеджерами, директором, руководителями PM'ами, и иже с ними, закосневшая в годовых релизах и управляемая прямой иерархией не сможет воспринять эти четыре ценности.
Так им не нужна agile разработка. Их устраивает текущая организация и система управления.
И вы рисуете этот круг и говорите — вот цикл, и четыре ценности в манифесте. Это все что нужно. Стряхиваете мел с рук и говорите немому залу — какие будут вопросы. Думаю будет тишина, затем шум отодвигаемых стульев.
И неудивительно. Потому что у них у всех будет один вопрос «А где в этой системе мы?»
Вы почему то решили, что решение о переходе к agile разработке должно быть «продано» менеджерам среднего звена. Это было бы нужно только для того, чтобы потом делегировать им внедрение. Но на месте владельца будет большой ошибкой поручать внедрение agile разработки нижестоящим менеджерам. Потому что весь смысл этой реорганизации в том, чтобы делегировать полноту принятия решения непосредственно в команды. Перейти от иерархии к сетевой структуре. У кого мы забираем власть в данном случае? У всех менеджеров, включая владельца. Мотив владельца понятен, вырастет эффективность, упадут издержки, компания станет расти лучше, стоить больше. А вот у остальных менеджеров есть мотив всячески саботировать этот переход.
Поэтому это решение принимает владелец. Остальные менеджеры либо подстраиваются под новые правила, находя себе новые роли в организации (становятся product-owner'ами, scrum-master'ами, coach'ами, консультантами или, например senior-разработчиками) либо замещаются новыми лидерами.
Остальные менеджеры либо подстраиваются под новые правила,
Задача топ-руководителя, на мой взгляд, в этом как раз и состоит — чтобы научить и настроить процесс принятия управленческих решений таким образом, чтобы существующая команда перешла на новые рельсы, т.е. они не сами должны всё-таки перейти, а руководитель должен их туда перевести.
В целом, считаю, что для действительно крупных и сложных компаний — любой фреймворк — это скорее, отправная точка для построения собственной эффективной модели управления.
Я считаю, что тот же Agile, в том, старом смысле, он действительно предназначен для малых команд, в то время как для больших имеет смысл строить свои модели управления на основе Lean, JIT, ТОC и т.д. — они просто оперируют большими уровнями абстракции в соответствии с увеличением количества уровней принятия решения в компании и, соответственно, уровня сложности организации.
Кстати, если посмотреть внимательно — тот же Agile взял многое из как раз таких «тяжелых» инструментов и приспособил полезное для небольших команд, но маркетологи от консалтинга, к сожалению, сейчас пытаются найти новые способы привлечь к себе внимание за счёт раскрученного бренда Agile
Да, фреймворк хорош на верхнем уровне, при попытке спустить его вниз и залезть в каждую деталь усилия перевешивают результат. Как экосистемы получают устойчивость за счет биоразнообразия, так и в большой организации важно обеспечить единообразие при интеграции общих усилий и возможности разнообразия для удобства конкретных команд.
А маркетологи ..., работа у них такая :) «Не ругайте пианиста»
А маркетологи ..., работа у них такая :) «Не ругайте пианиста»
Статья интересная, полезная, есть что пообсуждать :)
Было бы интересно увидеть в окончании некий вывод/заключение по итогам описанного.
— когда именно нужно использовать бережливые и Agile-подходы — отдельная тема, но неплохо бы дать ссылку на материал, если такой имеется. Поскольку сложные продукты создают уже довольно давно, когда понятия Agile еще не было.
— какие другие фреймворки можно привести в пример? Я могу припомнить разве что работы Scott Ambler по Disciplined Agile Delivery (DAD) и Agile Scaling Model (ASM) — http://www.ambysoft.com/scottAmbler.html#sthash.2q9wuhmZ.dpuf
Было бы интересно увидеть в окончании некий вывод/заключение по итогам описанного.
Что же касается крупных компаний, то, если речь идет о создании по-настоящему сложных продуктов с использованием бережливых и Agile-подходов, альтернативы SAFe у них фактически нет, поскольку другие фреймворкипо этой цитате 2 вопроса:
— когда именно нужно использовать бережливые и Agile-подходы — отдельная тема, но неплохо бы дать ссылку на материал, если такой имеется. Поскольку сложные продукты создают уже довольно давно, когда понятия Agile еще не было.
— какие другие фреймворки можно привести в пример? Я могу припомнить разве что работы Scott Ambler по Disciplined Agile Delivery (DAD) и Agile Scaling Model (ASM) — http://www.ambysoft.com/scottAmbler.html#sthash.2q9wuhmZ.dpuf
При внимательном прочтении не нашел четкого раскрытия темы:
отсюда я вижу, что цепочка — направление — отдельный ART-коллектив
а выше было
т.е. я вижу уравнивание по коллективу уровня программы и уровня цепочки. получается что и там и там может работать отдельный ART-коллектив.
тогда чем они отличаются? хотелось бы более подробно разобраться в этом.
Цепочка добавленной стоимости — это, по сути, некий процесс, обеспечивающий создание определенного продукта или изделия в интересах одного из бизнес-направлений. Примерами такой цепочки могут служить кредитный конвейер банка или бизнес-процесс интернет-банкинга. Каждым направлением будет заниматься отдельный ART-коллектив, в составе которого — множество команд разработки.
отсюда я вижу, что цепочка — направление — отдельный ART-коллектив
а выше было
На уровне программ, втором по иерархии, формируются виртуальные коллективы, название которых — Agile Release Trains
т.е. я вижу уравнивание по коллективу уровня программы и уровня цепочки. получается что и там и там может работать отдельный ART-коллектив.
тогда чем они отличаются? хотелось бы более подробно разобраться в этом.
посмотрите на картинку. цепочка добавленной стоимости — это, подозреваю, value stream.
а программа это уровень на котором работают несколько команд и составляют Agile release train.
Из картинки видно, что несколько ART составляют VS.
а программа это уровень на котором работают несколько команд и составляют Agile release train.
Из картинки видно, что несколько ART составляют VS.
Картинки бывают разные и каждый по своему понимает, что там нарисовано. Например, тут http://dougdockery.com/wp-content/uploads/2014/10/SAFe-3.0-8.5x11_print.jpg мы находим VS на уровне портфелей.
Я в статье не нашел для себя ясного понимания зачем введен новый уровень для VS. То что он не обязателен — еще более затуманивает для меня этот вопрос.
Ответ «не хотите — не используйте» меня не устроит :) Хотелось бы разобраться, что нового и полезного он может дать. Пока не увидел.
Я в статье не нашел для себя ясного понимания зачем введен новый уровень для VS. То что он не обязателен — еще более затуманивает для меня этот вопрос.
Ответ «не хотите — не используйте» меня не устроит :) Хотелось бы разобраться, что нового и полезного он может дать. Пока не увидел.
Именно про эту картинку я и говорил.
Вы вначале про «зачем» не спрашивали)
Вы вначале про «зачем» не спрашивали)
Только чем ART от VS отличается). Кстати, на этой же картинке есть VS из одного ART, а есть из двух.
Зачем все эти уровни? На мой взгляд их придумывают для того, чтобы декларируя переход к self-managment командам на деле сохранить иерархическую модель в организации.
Зачем все эти уровни? На мой взгляд их придумывают для того, чтобы декларируя переход к self-managment командам на деле сохранить иерархическую модель в организации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Цепочки добавленной стоимости в SAFe