Про Agile говорят и пишут много. Кто-то рассказывает о своих победах, показывает фотки с довольными заказчиками и советует делать итерации не больше двух недель, для других Agile — это синоним боли, мук и страдания. Вот и я решила оглянуться назад и посмотреть на историю одного проекта, Agile которого не интересовал более 10 лет и, в котором Scrum и ежедневные стандапы внезапно стали яблоком раздора, причиной поиска нового места работы и самой обсуждаемой темой в курилке.
Началось все с того, что руководство со стороны заказчика приняло волевое решение и занялось поисками нового руководителя, способного изменить устоявшееся положение вещей. Не могу точно сказать, какие изменения были до меня, но в момент моего появления на проекте была следующая картина:
— люди устали от бесконечных перемен;
— слово Agile и Scrum вызывало раздражение и мучительные гримасы;
— бесконечные срывы сроков;
— недовольный заказчик;
— регулярная доставка различных фиксов патчами в релиз из-за необходимости срочно исправить дефекты и внезапные подготовки новых Service Pack-ов;
— общий хаос и неразбериха.
И вот в этот момент говорят – добрый день, это Анна, ваш новый проект-менеджер. Думаю, многие согласятся, что тяжело приходить новичком в уже состоявшийся коллектив. И еще тяжелей может только быть, если Вам необходимо настроить процессы в таком коллективе, вывести людей из их зоны комфорта и все поменять. К слову, проект был достаточно большим (более 80 участников), софт разрабатывался более 10 лет и был это кровавый энтерпрайз=).
По окончания своего менеджерского медового месяца, у меня вырисовалась следующая картина:
1. Одновременно работали 7 девелоперских команд и 4 команды мануальных тестировщиков, 1 команда автоматических и много отдельных людей или групп людей, которые выполняют прочие задачи и подпроекты. Команды разработчиков были более – менее разбиты по модулям, тестировщики делились скорее всего исторически по принципу кто что лучше знает.
2. Были 4-х недельные итерации, которые руководство требовало закрывать полностью и которые никак не удавалось закрыть к установленному сроку. Система планирования была какая-то своя, основанная на производительность каждого конкретного человека в команде (она же может быть темой отдельной статьи).
3. Множество Kanban бордов с невероятным количеством колонок и жестким воркфоу работы с задачами и дефектами. Интересный момент, что на одну и ту же команду таких бордов могло быть несколько – какие-то для текущей итерации, какие для прошлой незаконченной, какие-то для патч-реквестов, отдельный борд для Service Pack-ов и т.п.
4. Часть документации в гуглдоках, часть залита на локальный диск, часть хранится в письмах.
5. Каждая команда работала по какой-то своей схеме со своими «процессами».
Мне были поставлены всего лишь (!) две задачи: вывести работу команд по Scrum-у и сделать, чтобы запланированный объем работ выполнялся вовремя.
Посмотрев на концепт планирования, который использовали в командах (стоит сказать, что идея могла бы быть вполне жизнеспособной), было совсем не очевидно, куда уходит время. Поэтому первым делом пришлось ввести обязательную систему тайм-трекинга в Jira. Задача состояла в том, что нужно было понять на какие виды работ сколько уходит времени. К концу 3 месяца статистика была более актуальной.
Вместе с этим процессом начали формировать Scrum команды. Не могу точно сказать, какую бы методологию выбрала, если бы этот выбор не был предопределен заказчиком, да и я все еще придерживаюсь концепции, что не столь принципиальна методология, сколь важна правильная ее эксплуатация, однако стоит сказать, что данный процесс оказался уж очень тяжелым. Было множество проблем реальных и надуманных командами, споров, недовольств, угроз на увольнение… К самыми сложными среди всех можно отнести следующие:
— один и тот же тестировщик отвечал за модули разных девелоперских команд;
— модули взаимосвязаны и изменения одной команды могло повлиять на работу другой;
— очень неожиданным препятствием этого процесса оказалась сопротивление размещения одной команды в одной комнате;
— проблема сопротивления лидами команд (страх потерять свою позицию, непонимание зачем и для чего все это нужно).
Перестроить всех и сразу казалось нереальным, поэтому начали с команд, с которых в принципе начать было проще.
Что в итоге было сделано: первичное разделение осуществили по логическим модулям, чтобы максимально команды были независимыми. Объединение разработчиков и тестировщиков осуществляли с позиций знания модуля, опыта работы с определенной командой, ограниченного количество участников в командах, успешности данных команды в прошлом, концентрация владельцев продукта на 1 команде (так как за различные модули отвечали различные владельцы продукта (product owners)). В итоге, у нас сформировались 8 Scrum команд, обособлено осталась команда автоматических тестировщиков.
Чтобы немного ослабить сопротивление людей Scrum-у и вообще Agile-у, организовали на регулярной основе слоты для инициации митингов. Идея была в том, что если какой-то команде нужны разъяснения по процессам, то оно могла забронировать данный слот, описать проблему и всей командой прийти на митинг. Обычно 20-30 минут хватало, чтобы ответить на все вопросы.
Также вспомнили про тим билдинги, мотивацию и прочие утехи, чтобы подружить людей в командах. Так кто-то получил повышение, кого-то отправили на оплачиваемые курсы, кого-то по их запросу перевели на другой вид работ или в другую команду.
После завершения формирования и запуск команд в Scrum полет, стало понятно, что планировать спринт длиной в 4 недели очень сложно, трудозатратно и временами не эффективно, т.к. люди за такой срок попросту забывают, что «напланировали». Так что итерации сократили до 2-х недель.
Однако сокращение итераций привело к обнаружению еще одной проблемы. Текущая система сборки и доставки билдов оказалось слишком медленной для новых условий (свежий билд предоставляли раз в неделю). Сократили срок доставки (до 2-х раз в неделю), однако и это оказалось слишком редко и особенно это ощущалось ближе к концу спринта, когда результаты фиксов нужно было видеть каждый день. Решили, что любой успешный билд, который прошел определенный набор тестов, будем размещать, но и это простое решение не дало результатов, т.к.:
1. в 30% случаях ломалась компиляция;
2. в 30% тесты падали по причине того, что они не были обновлены;
3. в 20% тесты падали из-за ошибок;
4. 20% приходилось на ошибки билд инженеров.
И в итоге чаще 2 раза в неделю развертывания билда не случалось. От поиска легких решений, перешли к изменению всей систему сборки билдов. Нашли отличной решение в связке (git + gerrit+Jenkins). Проблема №1 решилась достаточно просто – настроили компиляцию в pull-requests бранчах.
Решение проблему №2 и №3 также вынести на pull-requests branch таким образом, чтобы падения тестов можно было осуществлять предварительно и исправлять до поступления кода в общую ветвь.
В итоге к 5 месяцу мы пришли к определенным результатам. Самый главный — запланированный объем работ все команды начали доставлять в срок. Следующим немаловажным пунктом стало то, что удалось уйти от авралов во время работы и переработок. Все команды начали работать по одной схеме, результаты стали более предсказуемыми. Лояльность заказчика также повысилось, он стал мягче относиться к каким-либо нашим упущениям, меньше контролировать проект. Между прочим, никто так и не уволился.
Так или иначе, процесс еще не окончен и следующим большим этапом будет работа с владельцами продукта (product owners), исправление ситуации с выпусками большого числа Service Pack-ов, переводом всей документации в Confluence, модулизацией проекта, разработкой методики повышения производительности.
Думаю, это не первый и не последний проект, которой переживает трансформацию и поэтому какие-то идеи могут оказаться полезными и смогут помочь на других проектах.
ссылка на оригинал статьи http://megamozg.ru/post/11078/
Добавить комментарий