Лучший способ заставить себя прочесть книжку на 500 страниц —это решить подготовиться к экзамену (есть и ещё один способ, я расскажу о нём в самом конце заметки). Так я попал на базовый экзамен по SAFe.
Почему SAFe? Потому что с обычным Agile всё более-менее понятно. Манифест, команда, спринт и всё такое. А вот с применением Agile в компаниях среднего и крупного размеров вопросов гораздо больше. Scaled Agile Framework заявляет целью своего существования именно ответ на вызовы масштаба, так что пройти мимо ни в коем случае нельзя. Масштабы мы любим.
Не знаю, насколько популярна эта штука в России и ближайших странах. Возможно, что не очень – мне это было не так важно. Интереснее разобраться как работают гибкие подходы в командах из сотни-полутора разработчиков. Разобрался, сдал, готов поделиться опытом с теми, кто, возможно, пойдёт в ту же сторону.
Первое, важное. Для допуска к экзамену необходимо посетить соответствующий учебный курс в аккредитованной организации. Я привык, что наши курсы дают намного больше, чем требуется для экзамена. Я ожидал, что курс как минимум будет небесполезен. К большому сожалению, два дня потрачены без особой отдачи. Так что не ожидайте многого.
Второе, любопытное. Формат экзамена традиционный, выбор одного варианта ответа из нескольких предложенных. Но дальше следует непривычное: экзамен не ограничен по времени, его можно сдавать за несколько подходов, а при ответе не воспрещается пользоваться литературой. Насколько я понял затею, главным авторы-владельцы считают не проверку, а приобретение знаний. В том числе в процессе тестирования. То есть не сдать экзамен нельзя, вопрос только сколько баллов вы наберёте. У меня вышло 96% верных ответов, что означает, что в одном из вопросов я ошибся. Вот бы знать в каком! Эта история напомнила мне одно очень давнее наблюдение. Лет двадцать назад я увидел в Норвегии фотокамеру фиксации нарушения скоростного режима на дороге. А непосредственно перед ней стоял яркий, заметный знак: вас сейчас будут снимать (я понимаю, что теперь такое на каждом перекрёстке, но тогда у нас было не так). Я спросил у местных: в чём смысл? Водитель увидит знак, сбросит скорость и штрафа избежит. На что мне местные ответили – это именно то, что требуется. Не наказать, а чтобы скорость сбросил.
Третье, неудобное. Книжек по SAFe очень мало. Как теперь принято говорить, от слова "совсем". Интересующимся, которым недостаточно учебного курса (см.выше), предлагается читать web-сайт, нажимая в разные места общей схемы. Это удобно, если нужен справочник или глоссарий, и совершенно негодится, если требуется шаг за шагом разобраться в теме. Так что лучше поискать ту самую единственную книгу, которая недавно вышла.
И последнее, предметное. Сам SAFe мне понравился. По ходу изучения узнал много интересного. Большой пласт вопросов хорошо проработан, рецептов не навязывают, но предлагают дельные советы и варианты. Самое большое разочарование – всё та же проблема отделения разработки от остального мира ИТ. Ну то есть вы свою разработку выстраивайте гибко, чтоб работало быстро, и перекидывайте готовый код через стенку. Там, авось, кто-нибудь поймает и понесёт. Но мы-то знаем, что этого просто так не случится.
Удачи тем, кто соберётся сдавать этот экзамен!
PS.
Второй способ заставить себя прочесть толстую книжку — это обязаться подробно рассказать её содержание неподготовленной аудитории. Например, сотрудникам собственной компании на очередном обмене опытом. Я использую оба этих способа, работают они отлично. Рекомендую.
п.1 сильно зависит от тренера. В моем случае это был практик, запускающий "поезда" ART, причем по самым знакомым продуктам. Много интересного дал.
И там же не только про разработку. Ops там в явной форме присутствует