Портал №1 по управлению цифровыми
и информационными технологиями

Экзамен SAFe Agilist: опыт сдачи

Лучший способ заставить себя прочесть книжку на 500 страниц —это решить подготовиться к экзамену (есть и ещё один способ, я расскажу о нём в самом конце заметки). Так я попал на базовый экзамен по SAFe.

Почему SAFe? Потому что с обычным Agile всё более-менее понятно. Манифест, команда, спринт и всё такое. А вот с применением Agile в компаниях среднего и крупного размеров вопросов гораздо больше. Scaled Agile Framework заявляет целью своего существования именно ответ на вызовы масштаба, так что пройти мимо ни в коем случае нельзя. Масштабы мы любим.

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

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

Второе, любопытное. Формат экзамена традиционный, выбор одного варианта ответа из нескольких предложенных. Но дальше следует непривычное: экзамен не ограничен по времени, его можно сдавать за несколько подходов, а при ответе не воспрещается пользоваться литературой. Насколько я понял затею, главным авторы-владельцы считают не проверку, а приобретение знаний. В том числе в процессе тестирования. То есть не сдать экзамен нельзя, вопрос только сколько баллов вы наберёте. У меня вышло 96% верных ответов, что означает, что в одном из вопросов я ошибся. Вот бы знать в каком! Эта история напомнила мне одно очень давнее наблюдение. Лет двадцать назад я увидел в Норвегии фотокамеру фиксации нарушения скоростного режима на дороге. А непосредственно перед ней стоял яркий, заметный знак: вас сейчас будут снимать (я понимаю, что теперь такое на каждом перекрёстке, но тогда у нас было не так). Я спросил у местных: в чём смысл? Водитель увидит знак, сбросит скорость и штрафа избежит. На что мне местные ответили – это именно то, что требуется. Не наказать, а чтобы скорость сбросил.

Третье, неудобное. Книжек по SAFe очень мало. Как теперь принято говорить, от слова "совсем". Интересующимся, которым недостаточно учебного курса (см.выше), предлагается читать web-сайт, нажимая в разные места общей схемы. Это удобно, если нужен справочник или глоссарий, и совершенно негодится, если требуется шаг за шагом разобраться в теме. Так что лучше поискать ту самую единственную книгу, которая недавно вышла.

И последнее, предметное. Сам SAFe мне понравился. По ходу изучения узнал много интересного. Большой пласт вопросов хорошо проработан, рецептов не навязывают, но предлагают дельные советы и варианты. Самое большое разочарование – всё та же проблема отделения разработки от остального мира ИТ. Ну то есть вы свою разработку выстраивайте гибко, чтоб работало быстро, и перекидывайте готовый код через стенку. Там, авось, кто-нибудь поймает и понесёт. Но мы-то знаем, что этого просто так не случится.

Удачи тем, кто соберётся сдавать этот экзамен!

PS.

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

 

Комментариев: 7

  • Андрей Косыгин

    п.1 сильно зависит от тренера. В моем случае это был практик, запускающий "поезда" ART, причем по самым знакомым продуктам. Много интересного дал.

    И там же не только про разработку. Ops там в явной форме присутствует

     

    • Андрей, очень согласен, что почти всё зависит от тренера. Мне вот не повезло…

      Про Ops очень интересно увидеть то место, где оно явно присутствует. Что-то не нашёл.

      • Андрей Косыгин

        Идея то как раз в том, что Ops в явной форме больше выделять не нужно. Общая ответственность за результат команды Dev+Ops (да, за инциденты). Ops теперь помогает Dev. Т.е. на схеме это команды DevOps, Sys Team и другие. Кто то же должен поддерживать эти Jenkins, Ansible, Chef, ALM Octane и остальное. Кстати в ближайшей версии 4.5 обещают раскрыть тему глубже.

  • Динс

    Коллеги, а как называется Та Самая Книжка и на какой курс надо сходить для допуска к экзамену?)

  • Денис

    Приветствую. А как вы проходили курс? Выезжали куда?
    Как сам экзамен проходит? На месте прослушивания курса?

    • Курс проходил одном из известных учебных центров в Москве. Как писал в заметке – впустую потраченные два дня, но не ходить нельзя, это обязательное требование для допуска к экзамену.

      Экзамен проходит так: через несколько недель (!) после окончания курса вам на email приходит куча писем, по которым можно зарегистрироваться на их сайте и сдать экзамен удалённо. На сдачу даётся, если я правильно помню, 30 дней после регистрации.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM