Учитывая что в Уфе зима приближается решительными марш-бросками, почему бы не поехать в конце октября на конференцию, куда-нибудь, где +20, и хоть немного, напоследок перед зимой, увидеть солнышко? Сказано-сделано: посмотрел конференции, сравнил докладчиков, посмотрел где еще есть early-bird access цены — и забронировал.

В этом году мы с коллегой разделились, и поехали на Agile Greece и Agile Turkey, дабы сравнить мероприятия, ну и рассказать что интересного было на каждой из них. Неоспоримы плюс Agile Turkey в этом году был открывающий доклад от Дейва Сноудена (создателя фреймворка cynefin, о которой вскользь писали на хабре). Обычно на подобных конференциях после докладов, спикеров облепляют заинтересованные, и свои вопросы задать и подискутировать не получается, что и было моим опасением, так как спросить надо было много.

Конференция и организация

Agile Turkey Summit проходит уже не первый год, в отеле Wyndham Grand Levent в Стамбуле (в активно строящемся небоскребно-деловом районе Maslak). Продолжается мероприятие всего 1 день (выпавший в этом году на 19 октября), хотя мастер-классы и воркшопы прошли еще 18-го числа. 4-й конференц-этаж отеля явно неспособен принять ~800 посетителей, что особенно очевидно, когда всех пытаются накормить.

Сами же доклады, кроме основных, на деле оказались на турецком (чего никто из англоговорящих явно не ожидал). По нашим подсчетам, 2/3 всех спикеров вещали на турецком, невзирая на возмущение в твиттере. Обратной стороной засилья турецкого было то, что все его не понимающие общались между собой, и никто нам не мешал.

Подарочки на мероприятии весьма низкого качества: сумка Shi(f)t happens be agile, блокнот с ручкой, и тонна рекламной макулатуры. Как заметили некоторые, похожий мерч раздают на конференциях в Индии, в каком-нибудь Бангалоре. Честно говоря, даже на родной UfaDevConf все цивильнее.

Доклад Дейва Сноудена

Для начала надо сказать, что Сноуден — один из очень немногих во всей этой IT Management тусовке, связанной с гибкими методологиями, у кого в голове присутствует здравый смысл. Он агностичен в плане методологий и фреймворков управления проектами, так как среди них нет универсально-работающих; конечная цель это просто сделать работу эффективнее, и учитывать антропологические аспекты, увязывая их с IT — и вот набор данных утверждений это то, за что я этого человека-парохода очень уважаю.

Кейноут назывался "Сложность, культура и запутанность". Сноуден вкратце изложил модель cynefin и как он работает с различными системами при проектной работе (тут стоит заметить, что после прочтения о самой модели, мы в работе над разными проектами в SkuVault мы невозбранно (и пост-фактум) натягивали cynefin почти на все, и причинно-следственные связи позволяли категоризировать и анализировать ход проекта достаточно четко. Именно поэтому я считаю cynefin такой хорошей моделью, опирающейся на sense-making (или, грубо говоря, систематизации эмпирических данных). Также подчеркивались тезисы того, каким образом надо работать с клиентами и пользователями, и создавать образ компании в головах пользователей, не игнорируя их критику.

Основные тезисы доклада:

• Образ компании в головах пользователей важен больше, чем "гибкий" склад ума у сотрудников компании: Мышление не становится "гибким", после того как внезапно команда/лидер/менеджмент объявляет, что они теперь 'Agile'. Начинать необходимо потихоньку, улучшая процессы, коммуникацию и прозрачность — так, со временем, командная работа становится более гладкой, прозрачной, эффективной, и приближается к "гибкости".
• Из этого вытекает, что как только компания объявляет что она теперь 'Agile' — она моментально теряет всю гибкость и становится скорее противоположностью этой гибкости.
• Между простыми и хаотичными системами в cynefin очень тонкая грань. Часто, находясь в хаосе, с вашей стороны будет казаться, что вы находитесь в simple квадранте, и только во время факапа к вам придет понимание что все тлен.
• Необходимо непрестанно работать над образом компании среди своих пользователей. Весь негатив запоминают, в отличии от положительных моментов. Общайтесь с пользователями и клиентами, спрашивая "что мы можем сделать, для того, чтобы в следующий раз так нас подобным образом не критиковали", вместо рационализации и оправдания текущего состояния.
• Культура компании наследуется, и нужно постоянно помнить о коммуникационных каналах между основателями компании, и новыми сотрудниками, чтобы все делились как хорошим, так и плохим опытом из жизни компании. Тогда у всех будет понимание компании и ее решений в исторической ретроспективы, а ведь именно этим и характеризуется та же модель cynefin (так как переводится она, если грубо, то "место обитания со всем его культурно-историческим пластом").
• SAFe / NEXUS (фреймворки для мастабирования Scrum) перестают быть динамическими, когда мастабируются. И не это ли разве само противопоставление изначальной идеи Agile? (да, это противопоставление, но кушать scrum.org / scrumalliance хочется!).
• Waterfall это не плохо, хватит его демонизировать, он отлично подходит для проектов, где нет никаких сложностей и неопределенностей (а у нас их львиная доля в работе).

Доклад Курта Биттнера (Scrum.org)

Биттнер гоняет по земному шару с одним докладом "5 шагов, для масшабирования принятия Agile".
Основные пять тезисов, помогающих, по мнению scrum.org полюбить и понять полезность agile это

• Управлять проектами с учетом возможностей, которые они дают после реализации (а не самого факта выкатки на прод);
• Помогать командам и стейкхолдерам самоорганизовываться;
• Поддерживать и защищать ценности Agile, показывая пример будучи сильным лидером;
• Систематически избавляться от лишних прослоек в коммуникации и стадиях одобрения, чтоб ускорить процессы и повысить прозрачность и эффективность;
• Измерять и улучшать ценность релизнутых фич при помощи частой обратной связью от клиентов (принципы Agile: Inspect and Adapt).

Q: После доклада я решил в лоб спросить его, насколько же хорошо scrum подходит в ситуациях с языковым барьером, разницей в часовых поясах в 9-10 часов, и географической разделенности команды? Тот же cynefin натягивается и позволяет работать с теми методологиями и фреймворками, которые лучше подходят, в то время как формально, у scrum, более строгий подход и набор требований.

A: Порешили на том, что scrum работает, но эффективность сильно зависит от того, насколько удобно в целом команде работать по скраму, ведь у каждого есть более удобный подход, и здесь главное не мешать друг другу делать хорошую работу. Ну и в зависимости от ограничений, которые индивидуальны каждой организации, каждый эмпирически решает как удобнее.

Q: Недавно мы мигрировали наш монолитный .net проект на более легковесное решение (ну и подготовились к микросервисам + Go), в свете всех шишек, набитых в ходе работы (хаос, полностью новая архитектура, кривые фолбэки, полетевшие счетчики и уходящие клиенты), было интересно, насколько scrum хорошо вписался бы в это все

A: Обсудили и пришли к выводу, что учитывая что прогнозирования, кроме основного плана не было, ровно как и понимания когда что закончится, слишком уж непредсказуемо все было, можно было бы попробовать использовать микро-спринты в 1 день, и без артефактов (как в некоторых случаях делает NASA, правда очень измененный), но лучше было не усложнять, так как это совсем не скрам получается. Получился такой хардкорный R&D проект, который без ручного управления никак не взлетит, если делается впервые.

Q: Эстимейты, и какова их роль в scrum (потому что в последней редакции Scrum from the Trenches пересморена идея эстимирования, планнинг покер и стори поинты).

A: В целом сейчас в scrum.org нет больших фанатов эстимейтов ради эстимейтов и фокус-факторов. Хорошо прикидывать время, в случае если надо дать среднесрочную перспективу на завершение модуля, но большинство продуктов все равно разрабатывается с учетом дедлайна, и эстимейт просто выполнит прикладную функцию ориентира, при приближении к фазе проекта.

Q: Считают ли в scrum.org что есть проблема пересертификации (очень много людей владеет шильдиком CSM, но ничерта во фреймворке и менеджменте в целом не разбирается, зато любит оным шильдиком перед всеми махать)? И есть ли понимание того, что количество сертифицированных, но слабых специалистов понижает ценность CSM (на этом моменте я не мог не скрывать ехидную улыбку, как весело такие вопросы задавать представителю scrum.org)?

A: В целом, получение сертификата CSM значит, что человек ознакомлен с базовыми понятиями. Он ни в коем случае не указывает, что у сертифицированного специалиста есть хоть какой-то боевой опыт. Внедрять scrum такой специалист может, но лучше под наздором, чтоб не поломать дров.

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