Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Отсутствуют сертификации EXIN ACF, ACPO, ACSM. Авторитетный Европейский сертификационный центр.
> Для того, чтобы пройти фильтр работодателей
Единственное основания проходить сертификацию. И это, к сожалению, болезнь индустрии.
Agile это всего лишь подход к организации разработки, описанный в 4 ценностях и 12 принципах. Больше ничего. Вам не нужно проходить сертификацию для того, чтобы изменить подход. И наоборот, сертификация не изменит вашего подхода автомотически.
Авторы манифеста многократно критиковали сертификацию. Примеры: Alistair Cockburn и Dave Thomas
Единственное основания проходить сертификацию. И это, к сожалению, болезнь индустрии.
Agile это всего лишь подход к организации разработки, описанный в 4 ценностях и 12 принципах. Больше ничего. Вам не нужно проходить сертификацию для того, чтобы изменить подход. И наоборот, сертификация не изменит вашего подхода автомотически.
Авторы манифеста многократно критиковали сертификацию. Примеры: Alistair Cockburn и Dave Thomas
Да, сертификация конечно не изменит подхода, да и вряд ли вообще поможет в реальной ситуации. Но, все-таки, когда человек начинает на эджайл конференции с рассказа о себе, и у него есть сертификаты, хотя бы не ждешь треш и угар.
В этом году я был на конференции, на которой спикер заявил — в манифесте написано «Люди и взаимоотношения важнее результата!», и, увы, его не остановили модераторы, а времени на вопросы он предусмотрительно не оставил. Или, компания, которая внедряла продукт по эджайл и хвасталась этим на хабре — мол, наши ПМы стали СМами, команду мы били палками только за то, что она не бьет себя сама, а планерки по утрам заменили на дейли скрам. И это читаешь, и плакать хочется.
Так что для меня, наверное, серт — это скорее доказательство адекватности, а вот мериться ими смысла точно нет.
P.S. За примеры спасибо, не видел видео с этого события.
В этом году я был на конференции, на которой спикер заявил — в манифесте написано «Люди и взаимоотношения важнее результата!», и, увы, его не остановили модераторы, а времени на вопросы он предусмотрительно не оставил. Или, компания, которая внедряла продукт по эджайл и хвасталась этим на хабре — мол, наши ПМы стали СМами, команду мы били палками только за то, что она не бьет себя сама, а планерки по утрам заменили на дейли скрам. И это читаешь, и плакать хочется.
Так что для меня, наверное, серт — это скорее доказательство адекватности, а вот мериться ими смысла точно нет.
P.S. За примеры спасибо, не видел видео с этого события.
Товарищи, господа, дамы, PM, PO, CIO!
Ну прочтите Мифический человеко-месяц Брукса и особенно 16 главу — Серебряной пули нет.
Поймите что это писалось в 1986, что проблемы и вопросы поставленные тогда ни куда не делались и не решились. Что улучшилось только понимание проблемы, но не способы решения проблем. Начните честно признаваться с первых слов что у Scrum есть куча ограничений честно их и СРАЗУ заявите! Что гибкие методики тоже не применимы в 100%.
P.S. Перестаньте насиловать мозги.
Ну прочтите Мифический человеко-месяц Брукса и особенно 16 главу — Серебряной пули нет.
Поймите что это писалось в 1986, что проблемы и вопросы поставленные тогда ни куда не делались и не решились. Что улучшилось только понимание проблемы, но не способы решения проблем. Начните честно признаваться с первых слов что у Scrum есть куча ограничений честно их и СРАЗУ заявите! Что гибкие методики тоже не применимы в 100%.
P.S. Перестаньте насиловать мозги.
Хм, возможно дело в переводе. На русском эти книги даже читать не стоит, они переведены по принципу «Что знали, перевели, что непонятно выкинули, как поняли так и поняли».
Например, книга «Scrum: The Art of Doing Twice the Work in Half the Time» легко и непринужденно переведена на русский как «Scrum. Революционный метод управления проектами». Ну а потом, на конференциях начинаются споры — «Мы попробовали скрам по книжке, не пошло, фигня этот ваш скрам!».
Для того что бы начать внедрять Скрам (Принс2, ITIL, авторитарное управление и что угодно еще) мало прочитать 1-2-3 книжки. Мое мнение — надо звать тренера который уже не одну трансформацию провел, что бы он оценил — применимы ли к вашей компании вообще гибкие методологии и будет ли профит, а потом уже внедрять что то.
Например, книга «Scrum: The Art of Doing Twice the Work in Half the Time» легко и непринужденно переведена на русский как «Scrum. Революционный метод управления проектами». Ну а потом, на конференциях начинаются споры — «Мы попробовали скрам по книжке, не пошло, фигня этот ваш скрам!».
Для того что бы начать внедрять Скрам (Принс2, ITIL, авторитарное управление и что угодно еще) мало прочитать 1-2-3 книжки. Мое мнение — надо звать тренера который уже не одну трансформацию провел, что бы он оценил — применимы ли к вашей компании вообще гибкие методологии и будет ли профит, а потом уже внедрять что то.
Странно, вроде Сазерленд — автор скрам, и я был уверен что такого не напишет. Хотя, кто знает… Я не хотел такие книги читать, и теперь еще более убедился что не надо. Если хочется узнать о технологии — надо скачать справочник, пообщаться с тем кто использовал это на практике и пробовать самому. Книги по 500 страниц с историями и пояснениями на мой взгляд не так полезны…
Но, советую скачать скрамгайд. Он бесплатный, 16 страниц всего — стоит прочитать в любом случае.
Но, советую скачать скрамгайд. Он бесплатный, 16 страниц всего — стоит прочитать в любом случае.
В одной книжке для подготовки к сертификациям, я нашел исчерпывающую картинку с тем, когда хорошо заходит Agile, а когда нет.
Думаю, любой опытный ПМ\АЛ понимает, что кесарю кесарево.
Думаю, любой опытный ПМ\АЛ понимает, что кесарю кесарево.
Для некоторых областей гибкие подходы не подходят. И дело не в сложности. Вы считаете, к примеру, проектирование и сооружение моста простой задачей?
Проектирование моста непростая задача.
Но, заметьте, что на графике выше — не просто сложность, а сложность по определенным критериями.
Согласно графику, эджайл хорошо заходит в проектах, где все плохо с пониманием того, что делать, и пониманием того, как делать.
Если понимания, куда строить мост нет — наверное, его не надо начинать строить. Так же, если не понимать как именно его строить — мост это, туннель под водой, или, скажем, телепорт, начинать его строить нет смысла.
Именно поэтому мост по эджайл строить не нужно — здесь все в порядке с тем, что мы понимаем что надо построить и куда надо построить.
В разработке софта же все не так. Очень часто приложение или портал, которое мы делаем, будет меняться в процессе изготовления. Например ФБ задумывался как сеть для студентов, но рынок определил ему другую участь, Windows задумана как оболочка над операционкой МС ДОС, но выросла в полноценную ОС, телеграм задумывался как мессенджер, но по сути уже целая социальная сеть и т.д. и т.п.
Тоже и с технологиями — можно взять и спланировать приложение (UML например), но это будет очень дорого и не факт что эффективно. Даже в самом кровавом энтерпрайсе я видел документацию к приложениям в виде концепции или техзадания + описание проекта + руководств. Конечно, они не включали в себя описания классов, стандарты кодирования, расшифровки комментариев, и конечно были написаны уже по факту написания кода.
В итоге — строить мост по эджайлу можно, но ни к чему (определенность и использование известных технологий). Строить софт по вотерфоллу — всегда пожалуйста, просто дороже и не факт что это кому то будет нужно.
Но, заметьте, что на графике выше — не просто сложность, а сложность по определенным критериями.
Согласно графику, эджайл хорошо заходит в проектах, где все плохо с пониманием того, что делать, и пониманием того, как делать.
Если понимания, куда строить мост нет — наверное, его не надо начинать строить. Так же, если не понимать как именно его строить — мост это, туннель под водой, или, скажем, телепорт, начинать его строить нет смысла.
Именно поэтому мост по эджайл строить не нужно — здесь все в порядке с тем, что мы понимаем что надо построить и куда надо построить.
В разработке софта же все не так. Очень часто приложение или портал, которое мы делаем, будет меняться в процессе изготовления. Например ФБ задумывался как сеть для студентов, но рынок определил ему другую участь, Windows задумана как оболочка над операционкой МС ДОС, но выросла в полноценную ОС, телеграм задумывался как мессенджер, но по сути уже целая социальная сеть и т.д. и т.п.
Тоже и с технологиями — можно взять и спланировать приложение (UML например), но это будет очень дорого и не факт что эффективно. Даже в самом кровавом энтерпрайсе я видел документацию к приложениям в виде концепции или техзадания + описание проекта + руководств. Конечно, они не включали в себя описания классов, стандарты кодирования, расшифровки комментариев, и конечно были написаны уже по факту написания кода.
В итоге — строить мост по эджайлу можно, но ни к чему (определенность и использование известных технологий). Строить софт по вотерфоллу — всегда пожалуйста, просто дороже и не факт что это кому то будет нужно.
Disagreement — не совсем верное слово. Disorder — правильное.
Anarchy тоже подразумевает "люди так захотели". Не совсем так, верно Chaos.
Neither will work — неправда, многое работает и в этом квадранте.
Общее впечатление — автор картинки извратил Cynefin.
Вопрос по сертификации PMI-ACP.
Что мне даёт сам факт подачи заявки, кроме того, что я могу записаться на экзамен и что начинает тикать время?
Можно ли подготовиться, а потом уже подавать заявку? А то читаю опыт других — все подают заявку и начинают усиленно готовиться, чтоб уложиться в 1 год.
Что мне даёт сам факт подачи заявки, кроме того, что я могу записаться на экзамен и что начинает тикать время?
Можно ли подготовиться, а потом уже подавать заявку? А то читаю опыт других — все подают заявку и начинают усиленно готовиться, чтоб уложиться в 1 год.
На мой взгляд лучше подготовиться сначала, ибо в процессе подготовки может появиться понимание что сертификация не нужна. Если решили окончательно и 100% сдавать — можно подать заявку и оплатить, если на горизонте много времени. Если нет, лучше все таки сделать расписание подготовки и следовать ему, сдать в случае отсутствия форс-мажоров ничего не помешает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение сертификаций по Agile, часть 1 — ICAgile, Scrum.org, ScrumAlliance и PMI