Убить дракона: тернистый путь к Agile



    Пару-тройку лет назад мы тоже с энтузиазмом взялись переходить на гибкие методологии разработки, а по-простому: внедрять Agile. Наняли внешних консультантов, выделили для обкатки процесса кусочек большого продукта, с воодушевлением начали быстро и качественно делать. Делали-делали, а потом поняли, что получается какая-то ерунда, а не Agile, как в том анекдоте про секретаршу и 1000 знаков. И вроде бы все молодцы, работают как раньше, люди опытные, и продукт работает, только всё как-то «не по Agile-у».

    Мотивация в команде упала. Заказчики в растерянности от того, что предполагаемые «волшебные» сроки не сбываются, и вообще заявляют, что Agile не место в приличном обществе. В результате маленькая группка «Agile-трансформаторов» села и устроила мозговой штурм, почему же у нас ничего не выходит? Начали выписывать любые мешающие нам ограничения. Их оказалось очень много, и мы назвали их драконами.

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

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



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

    По каждому из «драконов» мы заводили в Jira отдельные раздел, куда заносили относящиеся к этому дракону user story. Как только они все закрывались, дракон считался побеждённым.

    Одним из самых вредных драконов в нашем случае оказались контракты с фиксированной суммой, которые мы заключали с подрядчиками. Неизменность общей суммы контракта подразумевала, что в какой-то момент поставки любых изменений в production могли быть просто заморожены. То есть все расценки были прописаны когда-то давно, а раз вы собрались внедрять какой-то там Agile, то хороший конечный результат никто не гарантирует, потому что объём работ может увеличиться, а сумма контракта — нет. Этого дракона мы и прибили в первую очередь: изменили принцип работы с подрядчиками, и начали покупать не конечный продукт или услугу, а ресурсы команд разработчиков, то есть перешли со всеми на итеративную разработку.

    Второй дракон, за которого мы взялись — отсутствие процесса разработки GitFlow. Agile подразумевает постоянные итеративные изменения, а у нас вместо нормального GitFlow был огромный, неповоротливый трёх-пятимесячный релиз, и потом сразу в production. Не было ни end-to-end тестирования, ни модульного тестирования, даже не было унифицированных тестовых данных. Всё прогонялось вручную, поэтому этап тестирования тянулся непозволительно долго. Сразу три дракона!

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

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

    Среди поголовья драконов затесалось и неумение делиться знаниями и навыками с коллегами. Кто-то что-то сделал — и побежал дальше. Мало внимания уделялось созданию подробной документации, да хотя бы просто передаче сакральных знаний «из уст в уста». Для борьбы с этим драконом мы внедрили процессы обмена опытом между специалистами внутри подразделений, наладили в Agile-команде процесс еженедельного рецензирования кода, запустили регулярные мероприятия по комплексному обучению и развитию специалистов.

    А вот драконов «прозрачность» и “CI/CD” мы до сих пор никак не победим. Хотя ситуация гораздо лучше, чем два года назад, победа близка.

    Что подразумевается под прозрачностью? Например, владелец продукта получает задание от заказчика и приносит команде. Обратно от команды он приносит заказчику сроки, понимание, реализацию. Этакое передаточное звено в отсутствие проектного менеджера. И до сих пор заказчики плохо понимают, как управлять, скажем, сроками.

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

    Что касается CI/CD, то мы настроили уведомления о любых проблемах при тестировании, ввели категории релизов и для каждой из них разработали чек-листы, реализовали возможность развернуть любую ветку кода в любом окружении, полностью автоматизировали выкатывание в production.

    А что с Agile?


    С ним всё прекрасно, он работает, и сейчас мы масштабируем на всю компанию, взяв за основу SAFe. У нас уже появляются кросс-продуктовые команды, что намного повышает сложность, и в том числе из-за этого возникают новые драконы, которых приходится дружно душить. У нас даже устоялось внутреннее корпоративное название для встреч, на которых обсуждаются различные трудности и способы их преодоления — «убивать драконов». Термин прижился и в тех командах, которые не работают по Agile. Всё, что мешает работать, начали называть драконами, подразумевая, что с ними надо бороться. Был курьёзный случай, когда один из сотрудников так и записал в своём рабочем отчёте: убивал драконов. То есть присутствовал на обсуждении текущей ситуации и дальнейших шагов. Его начальник прочитал, «хорошо, молодец», но, когда отчёт пошёл через юристов-финансистов-методологов, те пришли к начальнику и спросили, всё ли у нас в порядке, если мы в рабочее время мочим драконов.

    Пришлось рассказывать о нелёгких буднях борцов с крылатыми гадами.
    М.Видео 106,17
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 19
      0
      Всякий кто смотрел кино, не говоря уж про более глубокие культурно-исторические изыскания, помнит, что убивший дракона сам становится драконом. Так что ассоциации специфические, хе-хе.
        0
        Это да, чувствую :) Хорошее замечание, даже у ребят спрашиваю, не стал ли я драконом, не мешаю ли в чем то, говорите открыто :)
        +2
        Даже если результата нет — зато все при деле.
          +1
          Эх, убиваете редких зверушек почем зря… :)

          А что мешало внедрить все выше описанное без agile? Agile это одно, а покрытие тестами, CI/CD, GitFlow — это из другой плоскости. А и главное какие результаты внедрения Agile, стало ли проще (точнее) спрогнозировать время когда будет реализован необходимый функционал, повысилось ли качество продукта (меньше багов стали проявляться при использовании в продакшене), хотя учитывая что вы стали использовать юнит/авто тесты, то должно было повыситься?

          У меня создается впечатление, что это удобно, когда заказчик «внутренний», создается коробочный продукт и можно предсказать что войдет в очередной релиз, а что нет. А когда есть четкие сроки и бюджет, то гибкие методологии терпят фиаско? Интересен практический результат, что получилось, так как в теории гибкие методологии помогают контролировать процесс, дают возможность вовремя принять меры и предотвратить срыв сроков, выход за рамки бюджета.
            0
            О, это уже отдельная статья, по результатам. В абсолютных величинах если говорить, то:
            1. при тех же временных рамках разработка стала в 2 раза дешевле при том что в тех же временных рамках количество получаемого стало в 3-4 раза больше.
            2. TTM сократился в 4-5 раз, и это не предел
            3. Чистота кода повысилась намного
            4. Контролируемость и предсказуемость всего процесса появилась
            5. Появилась возможность пробовать!!! Ошибаться!
            Заказчики у нас как внешние, так и внутренние
              0

              Спасибо, звучит очень заманчиво. Можете пояснить несколько моментов?


              1. при тех же временных рамках разработка стала в 2 раза дешевле при том что в тех же временных рамках количество получаемого стало в 3-4 раза больше.

              Имеете ввиду, что трудозатраты на аналогичные задачи снизились в 2 раза? И что понимается под количеством?


              1. TTM сократился в 4-5 раз, и это не предел

              Я не смог расшифровать "ТТМ". :(


              Было бы здорово, если у Вас появятся время и настроение написать статью по результатам.

                0
                1. перефразирую: Ежемесячные поставки, которые стали в 3-4 раза больше, стали стоить в 2 раза дешевле, чем за аналогичный временной промежуток ранее, но с меньшими обьёмами поставки. К сожалению я не могу в цифрах говорить, коммерческая тайна. Надеюсь так понятнее.
                2. Time To Market

                есть не статья, но запись одного из выступлений, которые было на Agile Days 17:
                www.youtube.com/watch?v=34gApPj1OI8
                тут раскрываются и аспекты, результаты внедрения.
                  0
                  Спасибо!
                    0
                    >разработка стала в 2 раза дешевле

                    А за счет чего? Если сдельная работа — так при увеличении поставки наоборот должна вырасти, стоимость часа понизили или оклады или людей сократили?! Команда в штате или аутсорс?
                    Т.е. работал Вася за 1р и делал 1 работу, а стал сделать 4 работы за 50 копеек?!
                      0
                      По факту Да, в 2 раза сократилось количество людей. Команд А смешанные и аутсорс И штат.
                  0

                  Поддерживай! Достигаем примерно схожих результатов!

                0

                Прозрачность, CI/CD — это не "драконы" ;-) Извините за занудство

                0
                Большое спасибо за любопытную статью, было очень интересно читать.

                У меня получилось 27 вопросов, если вы не против, я отправлю их вам в личку.

                Любопытно узнать ваше мнение. Вот вы говорите что используете SAFe,
                а SAFe это lean-agile. Так вот, не кажется ли вам некоторым лицемерием
                тот факт что у методологии, одним из ключевых принципов которой является
                «Люди важнее процессов», на первой странице сайта размещена дигарамма процессов
                размером со стену. Не видите ли вы в этом какого то подвоха?
                  0
                  К сожалению, тут ошибка распространенная. В оригинале везде используется слово «over», что не переводится как «важнее». А просто «выше». То есть при: достаточных процессах, при достаточной документации и так далее.
                  0

                  А конкретизируйте пожалуйста как решили вопрос с передачей знаний внутри команды?

                    0
                    Тут тоже отдельная статья должна быть :))) я выше давал ссылку на мое видео выступление, там есть немного про это. Во первых посадить в одну комнату, если это возможно. Если нет, то разные другие фишки.
                    0

                    Классно что удалось привлечь вендоров на T&M.


                    По поводу "Например, владелец продукта получает задание от заказчика и приносит команде. Обратно от команды он приносит заказчику сроки, понимание, реализацию." По-моему, дело в том что владелец продукта на самом деле им не является. Мне кажется, тут надо подумать как прилечь бизнес в процесс разработки, как сделать чтобы реальный владелец продукта стал членом команды, с соответствующими полномочиями.

                      0
                      В больших компаниях это нереально. Реальных визионеров всего ничего… это ТОП -ы обычно. Зато в маленьких компаниях до 80-100 человек — вполне реально и работает

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое