Стивен Деннинг - Эпоха Agile

Разумеется, неожиданности происходят и на совещаниях: «О, так вы уже начали работать над этим? Мы не знали! Надо обсудить нюансы». Задача менеджеров – убедиться в том, что команды встретились, пообщались и разобрались в ситуации.

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

Каждые три месяца проходит стендап под названием «Встреча функциональных команд», во время которого каждая делится своими планами. Подопечным Бьйорка отводится 90 минут на выступления, то есть каждая команда должна уложиться в 10–15 минут. В этом мероприятии участвуют все «боевые единицы». Эта регулярная «церемония» предоставляет руководству подразделения разработки возможность вникнуть в текущую ситуацию и подстроиться под нее.

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

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

В целом все работали в одной и той же ветке. Это означает, что каждая команда проводила свои изменения в программе под названием Git. Но нельзя работать автономно в течение трех недель в надежде объединить результаты позже – необходимо ежедневное сотрудничество. Допустив нарушения в текущем варианте программы, команда должна моментально его исправлять. Чем дольше команде приходится ждать объединения кода, тем выше риск технической и интеграционной задолженности – и катастрофы.

Команды используют так называемые функциональные флажки. При новой разработке они первым делом изолируют код, который необходимо менять, и делают переключатель к нему. В базе данных он отмечается флажком, что означает изменение конфигурации. Команда пишет новый код за пределами версии, зафиксированной флажком. Предполагая, что работа завершена, она переключает код только для себя. Этот переключатель не глобальный. Он служит своего рода демонстрацией в системе и действует только «для своих». Если все идет хорошо, команда активирует его для конкретных пользователей, чтобы его протестировали и таким образом помогли выявить баги и проблемы. По окончательном завершении задания команда готовит анонс выпуска и объявляет о переходе на новую версию для всех пользователей. Затем она рефакторит прежний код, чтобы коллеги могли продолжать работать над ним, не мешая друг другу.

В конце каждого спринта команда рассылает электронные письма всем 500 сотрудникам группы Visual Studio Team Services и руководству. В них сообщается о том, что она выполнила за этот спринт и что планирует выполнить в течение следующего спринта. Члены команды записывают видео на три-пять минут, которое заменяет присутствие на демо.

«Раньше, – рассказывает Бьйорк, – написав код, команда устраивала вечеринку и отмечала успех – как потом выяснялось, преждевременный: в реальности они тонули в багах, которые после праздника приходилось искать и исправлять. Таким образом, до поставки ПО команду по-прежнему отделяли многие месяцы. Это был кошмар».

«Сегодня предельное количество багов установлено официально, – продолжает Бьйорк. – Это ограничение рассчитывается как количество разработчиков в команде, умноженное на четыре. То есть у 10 разработчиков ограничение составляет 40. Достигнув лимита, команда прекращает работать над новыми функциями и следующим спринтом и занимается устранением багов. Таким образом мы можем поставлять продукт бесперебойно».

При методе DevOps разработка и эксплуатация объединяются. Команды занимаются планированием, выполнением, поставкой и рабочими процессами для каждой новой функции.

«Если сервис перестает работать, – объясняет Бьйорк, – команда должна сделать остановку и решить проблему. Многие привыкли, что этим занимается отдельная служба поддержки. Но кому приятно тратить свое время на исправление чужих ошибок? Сквозная ответственность за качество улучшает результат. Команды управляют жизненным циклом каждой функции. Если сервис часто выходит из строя, значит, возникла проблема с качеством кода. Необходимость остановки мотивирует людей писать отличный код. Между тем винить в проблемах некого: команды сами являются владельцами созданных функций. Сотрудники поэтапно выполняют работу и решают проблемы по мере их появления».

«Постановка новых сроков кардинально изменила ситуацию. Теперь работу нужно выполнять за три недели, – продолжает Бьйорк. – Три недели – это нормально. Раньше у сотрудников было лишь две возможности. Тем, кто их упускал, приходилось ждать два года. Теперь все происходит иначе. Если инкремент недостаточного качества, то вы его не выпускаете. Команда разочаровывается и обсуждает проблемы на ретроспективе. Сделала ли она что-то неправильно? Или недостаточно оценила уровень сложности? Или что-то упустила? Лучше провести конструктивный разговор, чем устраивать тревогу, наказывать команду за то, что она не выполнила обещанное или, что еще хуже, выпустила некачественный продукт. Раньше на виновника багов указывали пальцем. Теперь команда сама обнаруживает их, исправляет и забывает о них. Срок корректировки багов сократился».

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

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