Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …
Coaching Advanced Scrum (часть 1)
Продвинутые Scrum команды - какие они? Что они делают по-другому? Их процесс проще или сложнее? Как они стали такими, какими они есть? И что ещё более важно - как нам двигаться в правильную сторону?
20 лют. 2019Кто пропустил подкаст на эту тему - смотреть и слушать здесь.
Preface
Так вышло, что эта статья переросла все допустимые размеры статей, и её пришлось разбить на части. Перед вами первая часть, посвящённая святая святых продвинутых Scrum команд - продвинутым инженерным практикам .
Почему тема продвинутых команд так важна?
"If you don’t know where you’re going, any road can take you there", - старая английская пословица. Мы часто слышим, что Agile – это не цель, это путь. И что Scrum – будучи каркасом и мета-процессом - это не процесс работы, это процесс построения процесса работы. Это так и есть. И я уверен, что при этом всё же очень важно понимать куда мы хотим прийти. Пусть даже наше понимание со временем сто раз изменится.
Это как с видением продукта. Оно чертовски важно и без него никак, хоть и мы знаем, что оно будет меняться и уточняться. Видение суперских команд и компаний должно помогать тем, кто на пути не застрять в «мы уже и так ОК», не потерять свою мотивацию улучшаться и иметь принципы развития компании.
Да и просто интересно понять, что же это такое быть офигенской Скрам командой. Короче, это важно.
А ещё это важно вот почему
Вы слышали про "мрачный скрам" (статья на рус.)? А про "вялый скрам" (статья на англ.).
Многие хорошие разработчики ненавидят скрам (тут я пишу 'скрам' именно с маленькой буквы, вялый ведь он ...). Это очень печальный факт. И кого в этом винить? Пожалуй в первую очередь коучей и консультантов (которым являюсь я и, будь воно неладно) - тех, кто насаждают мрак и жах в компании, помогая менеджерам использовать скрам, как ещё один инструмент давления над инженерами.
Я лично видел, как скрам при самых хороших побуждениях снижал качество кода и тормозил развитие технической базы у команд. За счёт чего? За счёт гонки за новыми фичами, амбициозными планами спринтов и подчисткой хвостов в самом конце спринта.
Качество нельзя встроить в продукт в конце спринта. Нельзя вчера и сегодня писать продукт некачественно, а завтра быстренько нагнать долги. Это так не работает.
Кого же винить или "availability bias" коучей
Описаны десятки т.н. когнитивных иллюзий («cognitive biases”), которым подвержен наш мозг и умение принимать рациональные решения.
К примеру, какую игру вы выберете:
вам дают 200 грн и потом вы кидаете монетку: выпадает «решка» – получаете ещё 200 грн, «орёл» – и теряете все 400 грн.
Вам с нуля дают кинуть монетку: «решка» – получаете 400 грн, «орёл» – не получаете ничего.
Какую игру вы выберете? Какая кажется менее рискованной? Какая более справедливой?
Я лично выберу 2), хотя и точно понимаю, что обе игры равнозначны и с 50% вероятностью дают выиграть 400 грн. В этом и состоит сила иллюзий, даже зная правильный ответ, вы будете видеть мир не таким какой он есть.
- Доктора, видя только больных людей, считают, что у народа в целом нехорошо со здоровьем.
- Видя в новостях о падении самолётов, вы делаете вывод, что это небозопасный вид транспорта.
- Живя в плохом районе города, мы считаем, что в стране повышается криминал.
Также и у коучей, у консультантов – мы видим только те команды и компании, которые обратились за нашими услугами (это по определению так), но при этом считаем, что знаем как оно вообще в индустрии. «В мире сейчас популярен Scrum», - говорят Скрам-коучи. В их иллюзорном мире это так, ведь всё, что они видят – это команды, которые используют Скрам.
Кажется, это называется по-научному "availability bias": делать широкий вывод по узкой выборке наблюдаемых ситуаций. "All you see is what there is" - из книги Канемана "Thinking fast and slow".
Именно эта иллюзия есть и у меня. Видел ли я очень крутые advanced Scrum команды? Едва ли, практически нет, одним глазком, недолго, издалека... А почему? Да потому что такие команды не зовут к себе коучей. У них и так уже всё хорошо, зачем им ещё новые коучи!
Но откуда тогда у них крутой Скрам? Хороший вопрос. Наверное, всё таки какие-то коучи там когда-то были... Но, пожалуй, только 0.001% населения всех коучей мира посчастливилось видеть крутые-прекрутые команды разик за свою карьеру. Остальные же ковыряют стикером скрамно...
Простите, увлёкся. Не хотел никого обидеть. Figure of speech, так сказать. Проехали.
И так, что же отличает обалденные Скрам команды от всех остальных?
Advanced Engineering Practices
Если Scrum стоит на китах, то одним из них, самым жирным и упитанным являются инженерные практики.
"Но постойте!" - скажет внимательный читатель, "в Скраме ведь нет инженерных практик, и, тем самым, его можно использовать вне IT, практически где-угодно."
Можно. Наверное можно. Скорее всего точно можно. Но эта статья про продвинутый Скрам. А в нём без технической базы никуда.
(Если вы используете Скрам вне IT, вне разработки, вне софта - ищите свои продвинутые производственные практики. В этой статье я вас, пожалуй, потеряю. Но обещайте, что вернётесь прочесть следующие части, они будут вам точно полезны.)
Крутые команды автоматизируют «як скажені»
И точка.
Процесс выпуска продукта с технической точки зрения – это скучная рутина. Нажатие одной кнопки.
И кто был на моих Скрам сертификациях видел такой слайд:
Здесь, спринт – это ритм планирования ("planning cadence"), и с выпуском продукта вообще никак не связан. Так понимают спринты продвинутые команды.
Фичи же выпускаются постоянно.
И никакой код никакой незавершённой фичи не валяется где-то в стороне (фича бранчи - порочная практика). Весь код постоянно проинтегрирован. Весь код проходит автоматическое тестирование и выливается на production или приближённые к нему среды. Это "code shipment" - сугубо техническое действие, которым 100% управляет команда.
При этом, не все фичи могут быть видны всем пользователям. Фичи включаются по мере готовности. Это "feature release".
Заметьте:
Code Shipped != Feature Released
В такой системе фичи выпускаются, включаются и раскатываются по необходимости и обычно, так быстро, как это возможно. Но при этом безопасно и с учётом нужного уровня качества.
- У вас есть такая система выпуска кода?
- Весь ваш код выпускается много раз в неделю?
- Вы отслеживаете поведения кода в реальном времени и можете откатить релиз автоматически?
- Вы постоянно улучшаете вашу систему выпуска?
- И этими улучшениями занимается сама же команда разработки?
Значит в ключе инженерии вы смело можете заявлять о себе, что вы "крутая Scrum команда".
Что же это даёт?
Планировали планировали и не выпланировали
Представьте, что каждая фича, которая сегодня ночью приснилась вашему владельцу продукта может быть выпущена уже через пару дней - в простейшем работающем варианте, на 2% живых пользователей, на полчаса.
Нужно ли вам тратить время на эстимацию и детальное планирование?
Ответ очевиден. Лучше это время использовать на понимание того, что именно нужно сделать. Чтобы получилось наверняка то, что нужно. И не пришлось потом откатывать и сильно переделывать.
Вот так думают звёздные Скрам команды: меньше планирования, больше проработки требований.
И ещё
Представьте, что вместо того, чтобы спорить на backlog refinement какого размера, цвета, местоположения нужно делать баннера, вы просто делаете все адекватные варианты, выпускаете их и через пару часов (дней, недель) выбираете победителей по живой статистике конверсии?
Вот так делают продвинутые Скрам команды: меньше планирования, больше данных.
Manual testing is immoral
Я как-то помогал одной небольшой компании. Команда работала двух-недельными спринтами. Много хорошего там было. Но код выпускался тогда, когда главный product owner прогонял end-to-end тесты (по сценариям, описанным им же на wiki). Его звали Antoine.
Это end-to-end тестирование не доверялось никому из команды (так считала команда). И лишь бедный Антуан, как самый последний в цепочке принятия решения "ну что, выпускаем?.." должен был прогнать эти тесты и выдать вердикт.
Соответственно такой вид тестирования я предложил им называть "антуан тестированием". Оно занимало 2-3 часа за релиз, если его "сесть и сделать". Но как вы можете предположить, это не самая приятная работа. Поэтому она часто откладывалась...
- В чьих же руках находятся все "антуан тесты" в продвинутых Скрам командах?
- В руках команды.
- Кто их автоматизирует?
- Команды (ибо им лень прогонять тесты мануально, к тому же это тупо неэффективно).
- Кто в этом случае решает - готов ли билд к поставке?
- Автоматическая система.
- Как часто в такой системе можно прогонять полный набор тестов и выпускать продукт?
- Так часто как нужно. В идеале много раз в день.
В такой системе выпуск билда - это сугубо технический вопрос. Каждый билд прогоняется по конвейеру тестов ("build & release pipeline"), негодные билды отбраковываются, а каждый "green build" отправляется на деплой. Как минимум отобранные билды деплоятся на staging (практика "continuous delivery"). Как максимум - на production (практика "continuous deployment").
А что с выпуском фич (включение их для пользователей)? Выпуск фичи - это продуктовый вопрос, где последней инстанцией является product owner.
Но product owner не решает, выпускать ли билд. Если команда получила зелёный билд, он выпускается автоматически, сразу.
Последний гвоздь
В таком процессе, как вы видите, от Скрама остались лишь рожки да ножки, вернее - спринты, как циклы планирования; ретроспективы - как циклы улучшения; роли - как формальные зоны разграничения принятия решений; беклог - как удобная концепция приоритезирования работы... В общем осталось всё, что в нём есть (см. ScrumGuide)!
Ушла шелуха: "предпланирования", "детальные оценки сложности", "планы спринтов с тикетами", "митинги по выпуску релизов" с "релиз инженерами" - всё ненужное бла-бла, которое не имеет никакого отношения к выпуску продукта.
Остался простой каркас, который напоминает о важности живого общения, бизнес приоритетах и частом выпуске качественных продуктов.
Когда и откуда в командах появляется такая техническая зрелость?
А как вы думаете?
Система автоматизации выпуска продукта - сама по себе продукт. И за него отвечает команда (или команды). Он не появляется внезапно, он не покупается. Он проектируется, пишется и развивается параллельно с выпуском клиентских продуктов.
Как команда находит на это время? Автоматизацию выпуска - это часть работы, неотделимая от выпуска конечных продуктов. Продвинутые команды каждый день, каждый спринт, каждый релиз улучшают её. Точно так же как и любой другой код.
Как же туда прийти?..
У вас нет системы автоматизации выпусков или она хилая? У вас нет каркаса для A/B тестирования? Нет технологии real-time feature toggling?
Но вы видите в этом ценность?
Начните добавлять эти инфраструктурные работы в беклог продукта на равне с фичами продукта. Придумайте себе внутренние релизы инфраструктуры - как продукта с майлстоунами, целями, метриками.. И делайте их каждый спринт.
Другого пути нет. И владелец продукта и менеджмент должен понимать ценность и быть готовыми инвестировать в разработку инфраструктуры.
"Они" не готовы? Задача продвинутых инженеров помочь всем в компании увидеть эту ценность. Она есть. И она велика. Любой адекватный продукт менеджер поймёт, может не с полуслова, но поймёт.
И ничего так не помогает увидеть пользу продукта, как демо продукта. Демонстрируйте ваши технические достижения на каждом sprint review. Пусть все начнуть понимать важность и ценность этой внутренней разработки.
На моём опыте - большинство менеджеров современных компаний, если и писали код, то 20 лет назад. Тогда не то что про continuous delivery не слышали - тогда ночных автоматических сборок ещё не было!
Покажи им, как это круто! Продемонстрируйте, обучите, замотивируйте.
Plan it or hack it
Plan it!
У вас есть практики квартального релиз планирования продукта? Тогда инженеры должны туда прийти с вижином инфраструктуры, которая поддерживает цели конечного продукта. И цели и работы по инфраструктуре должны стать частью релиза продукта.
Hack it!
Нет такого планирования? Менеджмент не понимает ценности автоматизации? Продакт менеджер гонится за фичами?
Что ж. Пишите инфраструктуру "под столом". Делайте это как "часть фичи". Начните делать это в неурочное время. Тут важно начать и показать, как это круто помогает выпускать лучшие продукты. Только не жалуйтесь, что вам не дают это делать - это настоящий тупик вашей профессии.
Автоматизация выпуска - часть профессии разработки софта.
И тут важно помнить: никого ещё не уволили за профессионализм! Ваш продакт менеджер не пойдёт к своему менеджеру жаловаться на команду за то, что она "уделяет слишком много внимания качеству". Это нонсенс. Пользуйтесь этим. Вы здесь рулите. Так рулите же!
Final words
В подкасте, на который я ссылся в начале статьи, мы лишь немного зацепили этот вопрос - как же стать advanced командой?
В разрезе инженерных практик:
- всячески растить инженерную культуру;
- проводите хакатоны, посвящённые этой теме;
- при старте новой разработки целями первых спринтов должны быть не фичи продукта, а инфраструктура;
- приглашать инженерных коучей для спарринга с командами;
- инвестировать сколько нужно в улучшение инфраструктуры разработки и выпуска;
- давать команде время в каждом спринте ("slack time") на тех улучшения;
- нанимать разработчиков с пониманием continuous delivery;
- уволнять - без желания понимать...
- иметь на стороне менеджмента сторонников сильной инженерии (это работа CTO и инженерых директоров, к примеру);
- смотреть на компанию, как на инженерно-продуктовую (примеры на поверхности: Google, Facebook, Twitter).
P.S. Где же взять advanced Scrum коучей для advanced Scrum?
Пожалуй, если вы хотите Advanced Scrum в IT вам нужен Scrum коуч с хорошим опытом разработки.
Super mega senior developer? Нет. Но как минимум коуч с хорошим пониманием инженерки (и да, таких крайне мало). Иначе вас ждёт мрачный и вялый скрам. А это - путь в никуда.
Альтернатива - связка коучей: процессный и инженерный. Но именно как пара коучей с одинаковым пониманием критериев успеха.