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

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

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

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

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

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

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

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

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

PS.

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

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

DevOps: погружение

Новый корпоративный семинар
 

Комментарии и мнения

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

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

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

     

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

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28