Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.
Все решают проблему по-разному, но обычно все сводится к автоматизации тестирования. Разрабатываются тесты на заглушках, общие правила формирования бэклогов соседних команд — фреймворки для межкомандного взаимодействия типа SAFe. В итоге благодаря синхронизации бэклогов команды смежных продуктов могут вместе писать и проводить тесты, в том числе интеграционные. Такие фреймворки есть и у нас.
Но теперь поставим себя на место владельца сложной и высококритичной банковской системы. Кто все-таки ответственен за качество всего этого продукта, если им занимается сразу десяток по-своему ответственных agile-команд? Нужна уверенность, что в продакшене ничего не завалится. Вводить дополнительные тестирования? Привет, waterfall, и пока, TTM.
Идеального решения здесь нет. В этой ситуации мы всегда будет иметь конфликт между принципами методологии и гарантированной надежностью результата. Вот какой компромисс нашли мы.
Если специфика вашего продукта предполагает, что он не полностью изолирован от других, то в точках соприкосновения вы должны играть по одним правилам — соблюдать минимальный уровень качества. Код должен покрываться модульными тестами, не должен содержать критичных дефектов ИБ, дистрибутивы по мере поставки должны проходить смоук-тесты. Никакой жести, но требования обязательны для всех. Их выполнение — это пропуск к общему тестированию.
Так, в общем, и выглядит практика Quality Gates — набор автоматизированных проверок, встроенных в devops-пайплайн каждой системы. По сути она отражает тенденцию к шифт-лефт тестированию, о которой сейчас частенько говорят в рамках девопса.
Мы договорились со всеми командами о ряде проверок, quality gates, которые они должны проходить в ходе прохождения этапов жизненного цикла.
Перед сборкой кода нужен обязательный статический анализ, проверка кода на соответствие стандартам конкретного языка программирования. А также на полноту покрытия модульными тестами. Для этого существуют разные инструменты. Мы, например, любим SonarQube. Пройдя этот quality gate, команды могут быть уверены, что не нарушили ряд базовых правил еще на раннем этапе. Например, избежали значительного дублирования, которое увеличивает сложность кода и вероятность проблем.
Вторая проверка перед сборкой — это проверка ИБ. Есть общепринятые практики по выявлению проблем ИБ в коде и инструменты, которые могут просканировать код и выявить опасные места. Например, некорректно объявленная переменная может привести к проблемам в продакшене. Здесь мы договорились не допускать все, что можно выявить на этапе написания кода, до пентестов и более сложных проверок.
При сборке дистрибутива мы обязательно проверяем результат: что сборка прошла корректно, что все службы запустились и работают как надо, что дистрибутив можно установить на нужную среду, и он заработает. Такой buiild verification test исключает потенциальное непонимание между тестировщиком и разработчиком. В waterfall-практике, бывало, разработчик заканчивал работу, передавал дистрибутив тестерам, а при установке на стенд выяснялось, что сборка даже не запускается. Тогда весь цикл нарушался, разработка растягивалась и вообще ничего хорошего не происходило.
У нас интеграционное взаимодействие выстроено очень непросто. Важно не сломать стенд, на котором могут проверяться и другие команды. Мы можем сделать это из-за плохого дистрибутива, и соседи по стенду узнают об этом раньше нас — мы просто нарушим им весь процесс работы. Кроме того, так можно испортить тестовые данные. А их подготовка тоже стоит денег и занимает немалое время. Особенно когда речь идет об обезличенных данных пользователей.
По мере установки дистрибутива на каждый стенд тестирования он проходит ряд простых смоук-тестов. На стенде системного тестирования тестируется функциональность дистрибутива. Дальше дистрибутив ставится на стенд интеграционного тестирования, где тестируются интеграционные взаимодействия. На нем тоже выполняется набор смоук-тестов. Если дистрибутив их не проходит, он не может перейти на следующий этап.
С помощью этих quality gates мы получаем первичное представление о качестве дистрибутива. Если смоук-тесты прошли успешно, команда приступает к тестированию. Если дистрибутив не прошел смоук-тесты на этом этапе, он, скорее всего, не пройдет и мануальное тестирование. Здесь мы назначаем его только в том случае, когда сборка потенциально готова пойти в пром.
Мы стремимся к тому, чтобы quality gates стали полноценным фреймворком для управления качеством разработки большого количества продуктов в agile. Если какая-то команда постоянно не проходит даже обязательные quality gates — это сигнал о наличии проблем, которые нужно обсудить и решить. С другой стороны, если какая-то команда уже освоилась с базовыми quality gates и встроила их во внутренние процедуры, она может пойти дальше и включить дополнительные quality gates.
В будущем мы планируем выкатывать новые наборы обязательных quality gates. А также необязательных, чтобы каждая команда с достаточным уровнем зрелости могла выбрать, что ей нужно. Например, если стоит прорабатывать стабильность дистрибутива на интеграционных полигонах, команда возьмет одни quality gates. Если нужно следить, чтобы сложная и многокомпонентная сборка не затрудняла деплой — возьмет другие. У кого-то уклон в безопасность на фронте, у кого-то в сторону проверок нагрузочного тестирования, доступности стендов, отклика, у кого-то впереди интеграция или проверка на какие-то данные. Каждая команда сможет найти quality gates для своего случая.
Важно отметить, что quality gates — это не замена тестирования, а инструмент первичного контроля. Тестирование никто не отменяет. Главная задача здесь — как можно раньше минимизировать ущерб другим командам от низкого качества продукта.
Пример стороннего пайплайна, включающего quality gates
В первую очередь, мы увеличили стабильность производственного цикла. Шифт-лефт в действии, мы можем сразу обнаруживать критичные баги функциональности. Меньше времени уходит на различные итерации тестирования, раньше обнаруживаются дефекты, так что их устранение обходится дешевле.
Уменьшился лид-тайм — время от начала кодинга фичи до ее внедрения в продакшн. Стабильность инженерного этапа ТТМ повысилась за счет того, что мы уменьшили простои в процессе поставки дистрибутива в промышленную среду. Чистое время на тестирование мы тратим такое же, но при этом у нас нет простоев из-за того, что развалился стенд, что нужно ждать пересборки дистрибутива.
Выросло время доступности сред для тестирования. Раньше ты мог поставить на нее сборку и забыть о ней на неделю. А тем временем смежные команды не могли протестироваться в этой среде, потому что твоя сборка дефективна и ты узнаешь об этом только через неделю. Теперь, когда ты ставишь сборку на полигон, то сам тестируешь ее на самые распространенные проблемы, при необходимости откатываешься, допиливаешь, возвращаешь обратно. И шанс никому не помешать становится гораздо выше. Внедрение quality gates также приведет к сокращению костов на восстановление стендов и переподготовку данных для тестирования.
Как мы говорили в начале, противоречие между принципами agile и комплексной разработкой нельзя разрубить как гордиев узел. Можно лишь стремиться к тому, чтобы оно приносило как можно меньше проблем. В нашем случае помогает практика quality gates, но, конечно, мы не считаем ее идеальной. А как решаете эту проблему вы? Нам было бы очень интересно обсудить этот вопрос.
Николай Воробьев-Сарматов, Сбербанк-Технологии, Sberworks
Спасибо Михаилу Бижану за помощь в подготовке статьи!
Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.
Все решают проблему по-разному, но обычно все сводится к автоматизации тестирования. Разрабатываются тесты на заглушках, общие правила формирования бэклогов соседних команд — фреймворки для межкомандного взаимодействия типа SAFe. В итоге благодаря синхронизации бэклогов команды смежных продуктов могут вместе писать и проводить тесты, в том числе интеграционные. Такие фреймворки есть и у нас.
Но теперь поставим себя на место владельца сложной и высококритичной банковской системы. Кто все-таки ответственен за качество всего этого продукта, если им занимается сразу десяток по-своему ответственных agile-команд? Нужна уверенность, что в продакшене ничего не завалится. Вводить дополнительные тестирования? Привет, waterfall, и пока, TTM.
Идеального решения здесь нет. В этой ситуации мы всегда будет иметь конфликт между принципами методологии и гарантированной надежностью результата. Вот какой компромисс нашли мы.
Quality Gates
Если специфика вашего продукта предполагает, что он не полностью изолирован от других, то в точках соприкосновения вы должны играть по одним правилам — соблюдать минимальный уровень качества. Код должен покрываться модульными тестами, не должен содержать критичных дефектов ИБ, дистрибутивы по мере поставки должны проходить смоук-тесты. Никакой жести, но требования обязательны для всех. Их выполнение — это пропуск к общему тестированию.
Так, в общем, и выглядит практика Quality Gates — набор автоматизированных проверок, встроенных в devops-пайплайн каждой системы. По сути она отражает тенденцию к шифт-лефт тестированию, о которой сейчас частенько говорят в рамках девопса.
Мы договорились со всеми командами о ряде проверок, quality gates, которые они должны проходить в ходе прохождения этапов жизненного цикла.
Кодинг
Перед сборкой кода нужен обязательный статический анализ, проверка кода на соответствие стандартам конкретного языка программирования. А также на полноту покрытия модульными тестами. Для этого существуют разные инструменты. Мы, например, любим SonarQube. Пройдя этот quality gate, команды могут быть уверены, что не нарушили ряд базовых правил еще на раннем этапе. Например, избежали значительного дублирования, которое увеличивает сложность кода и вероятность проблем.
Вторая проверка перед сборкой — это проверка ИБ. Есть общепринятые практики по выявлению проблем ИБ в коде и инструменты, которые могут просканировать код и выявить опасные места. Например, некорректно объявленная переменная может привести к проблемам в продакшене. Здесь мы договорились не допускать все, что можно выявить на этапе написания кода, до пентестов и более сложных проверок.
Сборка дистрибутива
При сборке дистрибутива мы обязательно проверяем результат: что сборка прошла корректно, что все службы запустились и работают как надо, что дистрибутив можно установить на нужную среду, и он заработает. Такой buiild verification test исключает потенциальное непонимание между тестировщиком и разработчиком. В waterfall-практике, бывало, разработчик заканчивал работу, передавал дистрибутив тестерам, а при установке на стенд выяснялось, что сборка даже не запускается. Тогда весь цикл нарушался, разработка растягивалась и вообще ничего хорошего не происходило.
У нас интеграционное взаимодействие выстроено очень непросто. Важно не сломать стенд, на котором могут проверяться и другие команды. Мы можем сделать это из-за плохого дистрибутива, и соседи по стенду узнают об этом раньше нас — мы просто нарушим им весь процесс работы. Кроме того, так можно испортить тестовые данные. А их подготовка тоже стоит денег и занимает немалое время. Особенно когда речь идет об обезличенных данных пользователей.
Смоук-тесты
По мере установки дистрибутива на каждый стенд тестирования он проходит ряд простых смоук-тестов. На стенде системного тестирования тестируется функциональность дистрибутива. Дальше дистрибутив ставится на стенд интеграционного тестирования, где тестируются интеграционные взаимодействия. На нем тоже выполняется набор смоук-тестов. Если дистрибутив их не проходит, он не может перейти на следующий этап.
С помощью этих quality gates мы получаем первичное представление о качестве дистрибутива. Если смоук-тесты прошли успешно, команда приступает к тестированию. Если дистрибутив не прошел смоук-тесты на этом этапе, он, скорее всего, не пройдет и мануальное тестирование. Здесь мы назначаем его только в том случае, когда сборка потенциально готова пойти в пром.
Quality gates как фреймворк
Мы стремимся к тому, чтобы quality gates стали полноценным фреймворком для управления качеством разработки большого количества продуктов в agile. Если какая-то команда постоянно не проходит даже обязательные quality gates — это сигнал о наличии проблем, которые нужно обсудить и решить. С другой стороны, если какая-то команда уже освоилась с базовыми quality gates и встроила их во внутренние процедуры, она может пойти дальше и включить дополнительные quality gates.
В будущем мы планируем выкатывать новые наборы обязательных quality gates. А также необязательных, чтобы каждая команда с достаточным уровнем зрелости могла выбрать, что ей нужно. Например, если стоит прорабатывать стабильность дистрибутива на интеграционных полигонах, команда возьмет одни quality gates. Если нужно следить, чтобы сложная и многокомпонентная сборка не затрудняла деплой — возьмет другие. У кого-то уклон в безопасность на фронте, у кого-то в сторону проверок нагрузочного тестирования, доступности стендов, отклика, у кого-то впереди интеграция или проверка на какие-то данные. Каждая команда сможет найти quality gates для своего случая.
Важно отметить, что quality gates — это не замена тестирования, а инструмент первичного контроля. Тестирование никто не отменяет. Главная задача здесь — как можно раньше минимизировать ущерб другим командам от низкого качества продукта.
Пример стороннего пайплайна, включающего quality gates
Итоги внедрения quality gates
В первую очередь, мы увеличили стабильность производственного цикла. Шифт-лефт в действии, мы можем сразу обнаруживать критичные баги функциональности. Меньше времени уходит на различные итерации тестирования, раньше обнаруживаются дефекты, так что их устранение обходится дешевле.
Уменьшился лид-тайм — время от начала кодинга фичи до ее внедрения в продакшн. Стабильность инженерного этапа ТТМ повысилась за счет того, что мы уменьшили простои в процессе поставки дистрибутива в промышленную среду. Чистое время на тестирование мы тратим такое же, но при этом у нас нет простоев из-за того, что развалился стенд, что нужно ждать пересборки дистрибутива.
Выросло время доступности сред для тестирования. Раньше ты мог поставить на нее сборку и забыть о ней на неделю. А тем временем смежные команды не могли протестироваться в этой среде, потому что твоя сборка дефективна и ты узнаешь об этом только через неделю. Теперь, когда ты ставишь сборку на полигон, то сам тестируешь ее на самые распространенные проблемы, при необходимости откатываешься, допиливаешь, возвращаешь обратно. И шанс никому не помешать становится гораздо выше. Внедрение quality gates также приведет к сокращению костов на восстановление стендов и переподготовку данных для тестирования.
Ваше мнение?
Как мы говорили в начале, противоречие между принципами agile и комплексной разработкой нельзя разрубить как гордиев узел. Можно лишь стремиться к тому, чтобы оно приносило как можно меньше проблем. В нашем случае помогает практика quality gates, но, конечно, мы не считаем ее идеальной. А как решаете эту проблему вы? Нам было бы очень интересно обсудить этот вопрос.
Николай Воробьев-Сарматов, Сбербанк-Технологии, Sberworks
Спасибо Михаилу Бижану за помощь в подготовке статьи!
Комментарии (6)
ky0
27.11.2018 21:41+1Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Вот прям разработчики? Разработчики-разработчики? :)
vyatsek
29.11.2018 01:01Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки
В сбербанке шел 95 год…
Для справки. MSF 94 год, RUP 2003. Waterfall была первая попытка формализовать процесс разработки, стандартом разработки он никогда не был.
Методология agile
это не методология. Agile вообще ничего не привнес, просто написали слово agile, а под ним здравый смысл, который на порядок, чем сам agile. Искренне не понимаю чего все носятся с ним как с писаной торбой.
Все решают проблему по-разному, но обычно все сводится к автоматизации тестирования. далее по тексту
Вы это сами выдумали или откуда-то взяли, кто эти все? Очень слабое обоснование.
Quality Gates
это называется ОТК, вообще знание управления производством может много подсказать при разработке взаимосвязанных систем большой группой людей.
Например, избежали значительного дублирования, которое увеличивает сложность кода и вероятность проблем.
Может научиться нанимать «правильных пчел», чем постоянно бороться с «непраивльным медом»?
Мы стремимся к тому, чтобы quality gates стали полноценным фреймворком для управления качеством разработки большого количества продуктов в agile.
почти бинго))
В будущем мы планируем выкатывать новые наборы обязательных quality gates.
Что за вредителей вы нанимаете, которые постоянно все ломают?
Попытка сберагербалайфомфреймворкомвылечить всех людейулучшить качество всех проектов, ну-ну, очередная имитация бурной деятельности менеджеров среднего звена.
Итого
Нет никакого обоснования проблемы, техники сбора данных, группировок проблем, подходов и эволюции их решений, аналитики.
Непонятно, неужели люди пишущие критическую систему не способны сами определить критерии качества, чтобы не наносить ущерб другим? Почему менджмент не пытается устранить источник проблемы и на разработку критичных систем ставить адекватных людей с адекватной компенсацией, в том числе и на менеджерские позиции.
И почему Quality Gates нужным всем, что у всех все плохо? Почему не используете принцип: работает — не трогай?
dplsoft
Как мы это решаем?.. гм. А никак не решаем.
Буквально — не прменяем agile в том виде и формах, как это предлагается «идеологами легковесных технологий».
Как работаем?
«Вспоминаем классиков»Пытаемся применять принципы масштабирования процесса разработки, заложенные в RUP, причем как это было описано в версиях от Rational (пока методологию еще не испортил IBM своими нововведениями и «принципами бизнес-ориентированной разработки» ).т.е. вместо того, что бы пытаться адаптировать agile к процессам, которые выходят за границы его применимости, мы сразу берем немного другие принципы/артефакты и «утяжеляем» процесс разработки в зависимости от масштаба / сложности / особенностей проекта. И того, как он развивается.
В начале набор фич, названий usecase, архитектурный прототип (который исполняемая архитектура).
По мере развития проекта и его усложнения или измения границ — утяжеляем / расширяем те или иные стадии или процессы, детализируем артефакты, усложняем процесс работы с ними.
Тут главное не слепо копировать техники «описанные в трудах классиков», а понимать какой артефакт, какой процесс в какой из своих форм тебе сейчас нужен и _достаточен_. Те же usecase могут оставаться в форме кратких описаний до конца проекта, если проект не большой и с заказчиком доверенные отношения. Где то хорошо заходят сквозные сценарии, а где то надо хорошо проработать модель данных и вывернуть процесс разработки от моделирования. 6де то надо у заказчика сидеть, а где то надо строго отрабатывать по этапам.
А за ваш опыт — спасибо. Почитаем про описанные вами техники подробнее, глядишь, где и приложится.
ky0
Сейчас вам расскажут, что вот это-то и есть — настоящий аджайл! :)
dplsoft
да уж )))
и спорить с ними будет
бесполезнотрудно.каким должен быть правильный эджайл — нигде толком конкретно, по полочкам, системно не написано. до уровня методики или методологии, сравнимой по степени проработанности с RUP, эти процессы так никем и не проработаны. (ошибаюсь? ткните меня, пожалуйста, в «самое эталонное описание»… ).
у меня такое впечатление, что сегодня «эджайл» — это уже бренд, марка, лейбл, которым клеймят всё
что-ни-попадя, что по мнению авторов должно быть «модно молодежным итеративным». Каждый дудит в свою дуду, у каждого есть своя правда и свой набор успешных проектов…Каждый _Мастер_ говорит, что «его кунг-фу лучше других кунг-фу»)))
«Мода вокруг эджайл» дошла до того, что в проектном менеджменте уже тоже «используют эджайл»…
вот лет 30 как не эджайл, оказывается; Тернер планирование по вехам не описывал, и итеративную поэтапную работу никто не использовал, о планировании «набегающей волной» тоже никто не слышал («действительно… ведь в PMBoK же нет»… или есть? поправьте если упустил что… вот у Тернера и в НТК от Совнет / IPMA это точно есть ),
И тут бац —
откровение: ЭДЖАЙЛ в проектном менеджменте… ээх.
Конечно, понятно, там совсем-совсем не тот «эджайл» что в статье у автора, и некоторые идеи предлагаемые под этим лейблом там тоже есть — и новые, и жизнеспособные… Но степень «истерии вокруг» и «оторванности вообще» сегодняшнего термина «эджайл» от внятного понимания «что же это такое» — это, имхо, иллюстрирует как нельзя лучше.
PS: и это мы еще про «прогрессивный» «девопс» не говорили )))