Наткнулся на прекрасную картинку, показывающую реальные связи между сотрудниками компаний, не объединённых единой миссией и ценностями. Хотя, в каком-то виде она валидна вообще для всех компаний. :)

Меня часто спрашивают, обязательно ли принимать инженерные практики и стандарты кода всей командой. Ведь, казалось бы, можно писать качественный код и тесты самому, не договариваясь с коллегами по разработке. А остальные увидят какой классный код вы пишете и тоже начнут следовать правильным практикам и подходам. К сожалению, так не работает.

Отбросим сейчас вопрос необходимости в конкретном продукте/проекте тратить время на качество и поддерживаемость кода. Будем считать, что у нас именно такой случай, когда инвестиции оправданы. Почему же положительный пример не становится заразительным и не меняет культуру команды? Дело в том, что большинство людей в первую очередь руководствуются личными интересами и целями, а не командными. А помогают им в этом принцип разбитых окон и отсутствие неизбежности наказания.

Приведу в пример оторванную от IT историю из жизни отдыхающих. Во всех отелях публикуют объявления с просьбами не занимать лежаки «на будущее» личными вещами и полотенцами. Очень хорошее и логичное правило, позволяющее обеспечить местами большее количество человек за счёт постоянной текучки. В результате, должно стать лучше всем отдыхающим. НО не конкретному человеку в конкретный момент времени. И тут начинают работать упомянутые выше принципы. Конкретный человек хочет обеспечить себе удобное место и «забивает» его с самого утра полотенцем. По принципу разбитых окон, другие отдыхающие видят такое поведение и думают: «чем я хуже?». И начинают действовать так же. А отсутствие неизбежности наказания лишь усугубляет проблему. Все начинают вести себя так, чтобы обеспечить себе личный комфорт. В итоге, большая часть лежаков в каждый момент времени не используется по назначению...

Ровно так же в разработке. Каждый стремится закрыть свою задачу побыстрее и вкладываться в «общее благо» - второстепенная цель, которая может быть принесена в жертву. И отличным оправданием становится подобное поведение у других членов команды. А отсутствие общих командных стандартов и «наказания» за их нарушение поддерживает тенденцию.

Для достижения успехов в области качества кода ключевыми элементами являются общие командные договорённости и жесткие (желательно максимально автоматизированные) проверки их соблюдения (quality gates, статический анализ, code review, внешние аудиты и т.д.). Без этих элементов все достижения будут очень хрупкими и недолговечными.

Один из самых некорректно используемых подходов в разработке - это BDD (Behavior Driven Development). Обиднее всего то, что за ним стоит прекрасная задумка, которая при правильной реализации дает много преимуществ. В помощь разработаны инструменты для разных языков программирования, которые облегчают техническую часть подхода. И при этом большая часть людей делает из него бессмысленный процесс, отнимающий время и не приносящий ровным счетом ничего.

Давайте начнём с задумки. Как следует из названия, BDD является подходом к РАЗРАБОТКЕ (а НЕ к тестированию), который основывается и базируется на сценариях использования системы. Изначально, сценарии использования знают только представители бизнеса. Поэтому на первом этапе они формализуются и обсуждаются совместно с инженерами из команды разработки. Формализация нужна для единого подхода к документированию сценариев, упрощению формата для избежания субъективных интерпретаций. Также, специфический формат помогает легче автоматизировать сценарии и превратить их в исполняемую документацию.

То есть, ключевая роль сценариев - задать четкие, понятные и согласованные критерии для команды разработки. Имея в наличие сценарии, команда разработки идёт реализовывать функциональность системы и автоматизировать сценарии для получения «живой документации». И тут очень важным становится второй принцип BDD: сценарии должны описывать поведение системы, а не техническую реализацию. В них не должно быть кнопок, API вызовов, БД и других технических терминов. Почему? Да для того чтобы снизить стоимость поддержки при развитии системы. Ведь бизнес сценарии меняются куда реже чем техническая реализация конкретной функции системы.

Что же мы видим в реальной жизни:

- бизнес не привлекается к формулировке сценариев, это делают тестировщики постфактум;
- разработчики вообще не используют сценарии в своей работе;
- инструменты из мира BDD применяются для тестирования API, UI и других технических моментов;
- сценарии пишутся как карго-культ и никто не может объяснить как они помогают и какую функцию несут;
- сценарии начинают напоминать обычный тест, но формализованный под формат given-when-then...

Вот вам пример статьи на тему нелепости использования BDD инструментов для API тестов: https://www.stickyminds.com/article/why-you-shouldnt-use-cucumber-api-testing.

#tests #testing #тестирование

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

20-21 сентября состоится QA Fest - крупнейшая конференция по тестированию в Украине. Она будет проводиться вот уже шестой год и в честь этого организаторы решили сделать ещё больше параллельных потоков с докладами. Участников ожидают два дня разнообразных докладов, море нетворкинга и отличное afterparty. Я 5 лет выступал на этом мероприятии, но в этом году видимо не успею подготовить доклад и постараюсь присоединиться в качестве участника.

Больше информации на сайте: http://bit.ly/2yG8B2N.

Ещё одной конференцией, на которую пал мой взгляд, стала Agile Rock Conference. В прошлом году там было действительно много интересных докладов и поднятых тем для обсуждения. Среди докладчиков собралось много евангелистов и Agile коучей из Европы. Думаю, в этом году будет не хуже. К сожалению, конференция также запланирована на 21-22 сентября и придётся делать непростой выбор. :(

https://www.agilerockconference.com/

#конференции #conferences

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

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

Примеров подобных ловушек вы можете найти немало вокруг: загрязнение морей и океанов, пляжей, лесов, пробки на дорогах, толпы в туристических местах... В IT мы ежедневно сталкиваемся с проявлением данной ловушки в общей кодовой базе. Каждый разработчик стремится побыстрее закончить задачу, поэтому где-то может «срезать углы» и добавить не очень качественный код. Ну что тут такого? Ведь база кода большая и его изменение крошечное на фоне всего объёма кода. Но когда так начинают поступать все, то код экспоненциально быстро превращается в унылое говно, с которым никто не хочет работать и обзывает legacy. :)

Что же делать с этой ловушкой? Вариантов не так много:

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

#системы #ловушки

После постов на этой неделе много кто спрашивал что почитать на тему системного мышления. Во многих книгах эта тема раскрывается косвенно, но я бы рекомендовал для базовых основ прочитать «Азбуку системного мышления». Автор отлично раскрывает основные определения из мира систем, на ярких примерах даёт понять, почему так важно применять системное мышление и уметь понимать устройство систем.

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

#books #книги

https://mustread.com.ua/shop/azbuka-sistemnogo-myshleniya.html?gclid=EAIaIQobChMIit_M8dn14wIVQeaaCh2J7QFZEAAYASAAEgLpVPD_BwE

Я знаю много управленцев разного уровня, которые очень сильно переживают за низкую загрузку своих сотрудников и постоянно следят, чтобы она соответствовала определенному уровню. При этом, их зачастую не так волнует общий результат работы, сколько отсутсвие «простоя». Это вполне натуральная ловушка отдавать предпочтение показателям, которые легко поддаются измерению и нормированию. А движет этим желание иметь контроль. Можешь измерить - сможешь контролировать. Скорость разработки или качество продукта измерить куда сложнее. А тут раз и сразу видимый результат! :) Ролик как раз об этом...

#менеджмент #эффективность

https://youtu.be/U8bqXcFY37Y

Я помню сколько сил мы убили последний раз для запуска полноценного высоконагруженного multi-master MySQL кластера в далёком 2014 году. И на сегодняшний день эта задача весьма нетривиальна, несмотря на большое количество выпущенных инструментов и прогресс в развитии самого MySQL. И вот Amazon анонсировал поддержку multi-master режима для своей облачной Aurora на базе MySQL.

Что это означает для рядового разработчика? Теперь есть возможность практически без усилий, но за много денег (по сравнению с самостоятельным хостингом MySQL на том же AWS), получить multi-master кластер любого масштаба. И сэкономить кучу времени на настройку и разгребание проблем своими руками.

Но не все так гладко, как кажется на первый взгляд. Для распределённого разруливания конфликтов разработчики Aurora использовали подход с версионированием страниц с записями. Это означает, что две параллельные транзакции на разных нодах, изменяющие одну и ту же страницу (не строки, а именно страницу), придут к конфликту и одна из них откатится с ошибкой. Поэтому прозрачно без изменений перейти на такое решение будет не так просто. Рекомендуется делать изменения на клиентской стороне для уменьшения вероятности такой проблемы, например применяя шардирование.

Ещё одна забавная особенность в том, что решение работает по-прежнему на движке MySQL 5.6... :)

#aws #базы_данных #mysql

https://aws.amazon.com/ru/blogs/database/building-highly-available-mysql-applications-using-amazon-aurora-mmsr/

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

Вот уже несколько лет наблюдается карго-культ микросервисов. Люди стартуют разработку MVP своих продуктов или просто hello world и «естественно» используют микросервисный архитектурный стиль. Причём, волна захлестнула уже все стеки и языки программирования. Почему я так негативно к этому отношусь? Да по ряду причин:

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

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

#архитектура #микросервисы

В отпуске я меньше следил за новостями и пропустил анонс от GitHub по поводу поддержки CI/CD в GitHub Actions. Теперь можно будет для большинства репозиториев иметь основные Workflow прямо в GitHub и не выделять для этого отдельной инфраструктуры. Основная фишка в том, что шаги являются кодом, а это значит можно их хранить в репозитории, использовать шаги от сторонних провайдеров, переиспользовать между разными проектами и т.д. Как обычно, для публичных репозиториев все бесплатно, для приватных будем стоить денежек. Похоже, Microsoft влияет на GitHub очень позитивно.

Сейчас доступна beta версия, официальный запуск запланирован на 13 ноября.

#github #ci_cd

Пора летних отпусков подходит к концу и скоро начнётся активный рабочий сезон. А мы наконец завершили задачу, которая стояла давным давно, но до неё никак не доходили руки. В далёком 2009 году мы начинали с тренингов и точечного консалтинга, потом запустили конференционное направление, а потом появились программы обучения, коучинг, разносторонний консалтинг, hands-on практическая помощь и другие услуги...

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

Работы над сайтом ещё не закончены, нужно ещё актуализировать каталог тренингов и обновить пару разделов. Мы будем рады услышать обратную связь!

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

Теперь прямо дисциплина требуется, чтобы регулярно смотреть какие новые фичи появились и как они делают жизнь лучше. В результате, очень много людей используют минимальный набор функций и учатся разве что от коллег или знакомых. Вот я на днях узнал о возможности шарить каналы в Slack между двумя организациями. Для меня это безумно полезная фича, потому что позволяет гораздо проще начать работать с компанией на начальном этапе, не добавляя себе ещё один воркспейс в Slack. И я тоже узнал о ней совершенно случайно. :(

Теперь хочу сделать список инструментов и сервисов, которые регулярно буду проверять на наличие новых интересных и полезных фичей. А ведь раньше RSS закрывал этот и кучу других вопросов. :(

22 августа случилось важное событие в мире Cloud Native Java. Компания VMWare решила укрепить позиции на рынке и прикупила известную каждому Java разработчику компанию Pivotal, а также занимающуюся безопасностью cloud native решений компанию Carbon Black. Благодаря покупкам, VMWare получила полный стек для продажи энтерпрайз сегменту.

Основная ставка делается на Kubernetes, поэтому поддержка его в Spring Boot и Spring Cloud по идее будет развиваться очень быстро. Java разработчики от этого должны оказаться в выигрыше, ведь до этого фокус на K8S у Pivotal был очень слабый и даже в Pivotal Cloud Foundry поддержка была добавлена не так давно. А вот останутся ли все сотрудники в компании и ждёт ли компанию реструктуризация - это открытые вопросы.

И ещё один интересный аквайринг в «горячей зоне» произошёл в августе. На этот раз компания Aqua Security присоединила к своему семейству инструментов open source сканер для Docker образов Trivy. Это был самый популярный инструмент в области безопасности контейнеров, которым пользовалось большое сообщество. По утверждению Aqua Securiry ничего не изменится и все будут счастливы, но обычно реальность выглядит несколько иначе. :)

На прошлой неделе проходил интересный вебинар под названием "Secrets of Top-performing DevOps Teams – at Google and Beyond" от докладчиков из Google. В вебинаре они рассказывали про определение DevOps в Google, как определенные процессы и практики позволяют добиваться скорости и надежности поставки функциональности конечным пользователям. И все это в масштабе огромной компании. Для тех, кто пропустил вебинар, уже доступны запись и слайды.

#devops #видео

В продолжение анонса покупки Pivotal со стороны VMWare мне прилетело много вопросов, мол зачем и почему? С приходом практически монополии Kubernetes на рынке инфраструктурных решений, каждый старается «запрыгнуть в паровоз возможностей» по максимуму. И в VMWare придумали очень интересный ход, трансформировав свою платформу vSphere в Kubernetes. Примерно как в том фильме: vSphere превращается, превращается... в Kubernetes. С учётом количества энтерпрайзов, сидящих на vSphere и ещё далёких от K8S, это очень сильный ход. Прямо в яблочко!

И вишенкой на торте становится Pivotal Cloud Foundry для тех, кому мало формального перевоплощения и хочется простой для разработчиков PaaS платформы. Очень интересная игра начинается! :)

P.S.: Ну и чтобы закрепиться в головах разработчиков, VMWare запустили бесплатный обучающий проект Kubernetes Academy.

#pivotal #kubernetes #инфраструктура

Вчера я побывал на unconference, посвящённой тематике Agile. Помимо приятных встреч со старыми знакомыми, мне запомнился доклад про применение философии Кайдзен в Салатерии. Это сеть ресторанов общепита со здоровой пищей. Что же меня так впечатлило?

Во-первых, само применение практик Кайдзен в украинском бизнесе - просто дикая редкость. Обычно все делается по наитию и топорно, с полной уверенностью в том, что начальник знает как вести дела. В результате, места с адекватным сервисом и ориентацией на value для клиента можно перечислить по пальцам. А тут ребята построили систему внедрения изменений на основании идей сотрудников, постоянно ищут потери и оптимизируют value stream, классифицируют клиентов и улучшают клиентский опыт. Да, это пока эксперимент на базе пары ресторанов, но с желанием масштабировать на всю сеть.

Во-вторых, я был впечатлён сложностью условий, в которых им нужно растить Кайдзен культуру. Ведь текучка кадров в сфере составляет 140-200% (это означает, что много людей работает по кварталу или полгода), а большая часть работающих сотрудников не имеет нормального образования. При этом задача стоит выстроить процесс постоянных улучшений и правильную систему мотивации с большой вовлеченностью этих самых сотрудников. В IT многие не могут построить такую культуру даже с долгосрочными отношениями среди образованных людей...

Ну и наконец, я был рад увидеть, насколько энергия и энтузиазм одного человека, желающего «догнать и причинить добро», может сквозь все преграды добиваться результата. Это реально круто!

P.S.: Кто начитался книг про Кайдзен, вокруг видит одни потери. (с)

#agile #кайдзен

Ещё одна сессия на unconference была посвящена применению story points. Совершенно понятно, что это один из самых популярных карго-культов в современной разработке. Многие команды используют без понимания сути инструмента или применяют не по месту, жалуясь что нет никакого позитивного результата.

Вот несколько важных моментов, которые обсуждались:

- Story Points лучше заменить на Complexity Points для лучшего фокуса на цели применения и большей «серьезности».
- Однозначно не стоит применять для уровня задач, тут название даже намекает.
- Оценки обязательно должны быть относительными с заранее приговорёнными примерами для базовых единиц сложности.
- Для планирования итераций лучше использовать capacity driven подход с часами и разбивкой по специализации, так как Story Points скрывает разбивку и рассчитан на сильно взаимозаменяемых людей в команде. А это уже давно слабо достижимая цель.
- Story Points помогают в долгосрочном планировании релизов и составлении дорожной карты продукта. Если вы этим не занимаетесь, то стоит задуматься о том, нужен ни инструмент в принципе.
- Самая большая ценность Story Points заключается в диалоге и обсуждении всех элементов сложности, которые видят разные члены команды. Когда оценивает вся команда, то благодаря мнению каждого ничего не будет упущено. В оценку нужно закладывать риски, усилия по разработке, неопределенности и т.д. При этом, нет смысла вводить формулы, достаточно чтобы каждый говорил о своих ощущениях и отталкивался от уже оценённых задач.
- Полезно на ретро затрагивать вопрос о правильности оценок, чтобы в случае ошибок учиться на них и добавлять новые факторы в процесс оценивания.

Ну и наконец, перед использованием инструмента было бы здорово прочитать видение и изначальную задумку автора инструмента Майка Кона. Это можно сделать в его блоге или книге “Agile Estimating and Planning”. При этом стоит учитывать, что со временем разработка существенно поменялась (например, сильно выросла специализация членов команды), поэтому стоит адаптировать идею под реалии, а не следовать карго-культу.

#agile #scrum #story_points #планирование #оценки

​​Не мог пройти мимо такого шикарного комикса на болезненную тему. Уже второму клиенту советую большую часть псевдо-микросервисов свернуть в монолит.

#микросервисы #архитектура