Что нужно знать, чтобы стать devops-инженером: ключевые навыки

Как произвести расчеты инвестиций, которые потребуются для внедрения DevOps

Если компания понимает, какие убытки она несет за минуты недоступности в день или неделю отставания от конкурента, то финансовую целесообразность имплементации DevOps практик обосновать будет проще.

В процессе выпуска ПО есть 4 базовых метрики: частота обновления, время от идеи до ее выхода в продакшен, процент неуспешных изменений и время восстановления после сбоя.

Кроме этих метрик, в компании есть часть работы, которую называют «Unnecessary work». Ее можно прикинуть в часах — сколько лишней работы делают сотрудники. К такой работе относится, например, ручное обновление серверов. Автоматизация этой работы сэкономит рабочее время сотрудников. В данном случае можно заранее прикинуть, что внедрение технологии сэкономит 10 часов работы в неделю для инженера. От этого времени прикидывается, сколько новых фич инженер сможет сделать за неделю в освободившееся время. Если собрать такие расчеты по всей компании, то получится, что отказ от внедрения DevOps приводит к упущенной выгоде.

Про возврат инвестиций в DevOps хорошо написано в работе «Forecasting The Value Of DevOps Transformations» от организации DORA. Здесь описаны формулы расчетов, даны таблицы со средними показателями, по которым крупная компания может рассчитать, какие могут быть изменения после ликвидации «Unnecessary work» с помощью DevOps.

Чем занимается инженер по эксплуатационной надежности и сколько это стоит

Помимо автоматизации процессов администрирования и конфигурирования серверов, SRE-инженер также отвечает за скорость работы и доступность инфраструктуры . Чаще всего такие специалисты востребованы в крупных Big Data проектах, а также SaaS-, PaaS- и IaaS-провайдерами, которые должны обеспечивать безотказную работу своих сервисов в режиме 24 часа 7 дней в неделю и все 365 дней в году, ведь каждая минута простоя оборачивается серьезными потерями для бизнеса 1.

Основными рабочими обязанностями инженера по эксплуатационной надежности являются следующие :

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

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

В настоящее время по причине ограниченного количества крупных data-driven компаний уровня Google, Facebook, Amazon, Dropbox и т.д., спрос на инженеров по эксплуатационной надежности пока не слишком высок. Однако, постепенная цифровизация частных и государственных предприятий, их миграция в облака и получение сервисов от сторонних разработчиков повышают потребность в SRE-инженерах. По мере распространения технологий Big Data, DevOps и принятия Agile-принципов спрос на SRE будет расти, а роль эта начнет принимать все более четкие очертания 1..

Тем не менее, даже в условиях пока ограниченного спроса, SRE-инженеры являются самыми высокооплачиваемыми специалистами в ИТ-сфере. Например, в США на 1-ю половину 2019 года медиана зарплаты SRE-инженера находится в районе 85 тысяч долларов в год (около 500 тысяч рублей в месяц), тогда как DevOps зарабатывает примерно 71 тысячу долларов в год (около 400 тысяч рублей в месяц) . Сейчас в России инженеры по эксплуатационной надежности требуются в крупные ИТ-компании (Яндекс, Лаборатория Касперского), банки (Сбербанк, Тинькофф-банк) и ритейл-сектор (X5 Retail Group) с месячной зарплатой от 70 до 200 тысяч рублей (по данным рекрутинговой площадки HeadHunter).

SRE- и DevOps-инженеры — самые высокооплачиваемые ИТ-специалисты не только в области Big Data

Узнайте, как успешно использовать лучшие практики Agile, DevOps и SRE, не разорившись на дорогих специалистов, на обучающем курсе «Аналитика больших данных для менеджеров» в нашем учебном центре для руководителей, аналитиков, архитекторов, инженеров и исследователей Big Data в Москве.

Смотреть расписание
Записаться на курс

Источники

1. https://www.computerworld.ru/articles/Zachem-vam-nuzhen-SRE
2. https://realitsm.ru/2018/05/sre-vs-devops-konkuriruyushhie-standarty-ili-blizkie-druzya/
3. https://amazinghiring.ru/blog/2017/12/04/как-найти-и-нанять-инженера-эксплуата/
4. https://insights.stackoverflow.com/survey/2019

Гибкость против жесткости: Agile vs Waterfall

В отличие классического Project Management (PM), когда проект жестко регламентирован заранее установленными требованиями (контрактами), Agile предполагает быстроту реагирования, а также гибкую адаптацию к внешним и внутренним изменениям. Это достигается с помощью итеративной разработки продукта и эффективного межличностного общения. В водопадной (каскадной) модели PM, которая считалась стандартом де-факто, проект состоит из функциональных задач, где каждая последующая работа четко регламентирована и начинается строго после окончания предыдущей, например, тестирование начнется только после того, как написан весь код. Жесткая определенность и обилие регламентирующей документации обусловливают длину производственного цикла. При этом продукт считается готовым лишь после выполнения всех этапов .

Waterfall — водопадная (каскадная) модель разработки ПО

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

Гибкая разработка ПО серией итераций

Масштабирование DevOps на другие команды

О масштабировании подхода DevOps на всю компанию следует думать после того, как пилотная команда успешно завершила проект

Здесь важно понимать, что процесс внедрения DevOps долгий, и чтобы масштабировать его на всю компанию, нужно, чтобы другие команды понимали, к каким процессам и изменениям им стоит готовиться, какие новые инструменты нужно освоить, какую литературу изучить

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

На этапе масштабирования обычно сталкиваются с тем, что вводить изменения в 10 командах компании намного труднее, чем вести одну (пилотную) команду. Для этого нужны синхронизация и процессы контроля и управления изменениями. Это значит, что от инициатора внедрения подхода DevOps требуются отдельные управленческие компетенции.

В пилотную команду обычно идут самые инициативные ребята в компании. Но при масштабировании подхода DevOps на всех остальных часто выясняется, что не всем это нужно и интересно. Будьте честны, если вы можете сделать работу коллеги лучше — расскажите как это будет

Если нет, то расскажите, почему это важно для компании

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

Важно вытаскивать людей из приватов в публичное пространство, где все могут принять участие: спросить/дать совет, узнать/рассказать, что происходит — так происходит синхронизация

Речь о чатах, внутренних митапах, корпоративных каналах

Важно вытаскивать людей из приватов в публичное пространство, где все могут принять участие: спросить/дать совет, узнать/рассказать, что происходит — так происходит синхронизация

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

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

В этом случае лучше приготовиться к длительному и постепенному масштабированию. То есть не внедрять DevOps одновременно на всю компанию из 50 команд, а работать по очереди с каждой. И использовать опыт и результаты пилотной команды, чтобы сократить риски.

Особенности технологии Agile

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

• экстремальное программирование;
• scrum;
• scrumban;
• kanban и т.д.

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

1. упрощается коммуникация в команде;
2. улучшается взаимопонимание между ее членами;
3. ускоряется общий процесс разработки.

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

В такую «спринт»-версию чаще всего входит основной набор функций будущего программного обеспечения.

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

Основные отличия Agile и DevOps

В первую очередь Девопс отличается от Эджайл необходимостью тесного взаимодействия групп разработки и эксплуатации (development + operation) с последующей автоматизацией развертывания готового программного обеспечения наиболее надежным способом. Поэтому данная методология основывается на совместной работе членов сразу двух команд, которые должны постоянно общаться. Чаще всего они собираются в момент, когда выпускается релиз, чтобы обсудить особенности развертывания.

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

Хотя Agile предназначена исключительно для разработки ПО, она не всегда может предшествовать DevOps. Это объясняется тем, что две описываемые методологии используют различные методики и подходы, но при этом могут работать вместе.

5 разных мнений о DevOps

Хотя термину «DevOps» уже исполнилось более 10 лет, а самому понятию – и того больше, до сих пор существует 5 совершенно разных точек зрения на счет практического использования этого подхода:

1. DevOps – это просто раскрученный маркетинговый ход, всю работу дорогостоящего DevOps-инженера может сделать «продвинутый» системный администратор. Почему это не так и чем отличаются задачи этих специалистов, мы рассмотрели здесь.
2. DevOps – это лишь новое модное слово, а сама суть подхода давно и успешно применяется в промышленной разработке ПО. Это не может быть 100% истиной, т.к. само появление этого подхода обусловлено развитием Agile-методов, микросервисной архитектуры и повсеместной цифровизации бизнеса – факторами, возникшими не так давно, с начала 2000-х годов. Обо всем этом и роли девопс в Data Science проектах мы уже говорили.
3. DevOps – это устаревшее понятие, пора переходить на SRE – обеспечение эксплуатационной надежности. На практике это не совсем так: SRE дополняет и уточняет принципы DevOps, а не противостоит ему.
4. DevOps – это уже неактуально, следует стремиться к NoOps: сосредоточиться на разработке, полностью ликвидировав процессы эксплуатации. В чем суть этой концепции и почему она, на самом деле, не убивает DevOps, а переводит его на качественно новый уровень, мы рассмотрим далее.

NoOps — это новый DevOps

Как сформировать команду по внедрению DevOps

Формирование выделенной DevOps-команды — антипаттерн. DevOps работает, если практики применяются всеми уже существующими у вас участниками создания и эксплуатации продуктов.

В современных технологичных компаниях выделяют несколько типов IT-команд:

• Stream-aligned-команда (продуктовая команда), которая нацелена на цепочку создания ценностей. Команда разрабатывает продукты и делает все для того, чтобы компания прямо или косвенно зарабатывала деньги.
• Platform team предоставляет сотрудникам продуктовых команд сервисы, необходимые для обеспечения процессов разработки, тестирования и эксплуатации. Это позволяет продуктовым командам не отвлекаться от создания ценности. Специалисты по платформе могут выступать консультантами и помощниками для продуктовых команд по вопросам применяемых инструментов, использованию сервисов облачных провайдеров и создают внутренние инструменты, полезные продуктовым командам.
• Enabling team — это команда экспертов по конкретным сферам, которые временно присоединяются к продуктовым командам и помогают им в формате менторства, анализа и решения технических задач. Enabling team дополняют продуктовые команды недостающими компетенциями.

О принципах формирования команд хорошо написано в книге «Team Topologies» а также на сайте DevOps Топологии. Другой вопрос, как из существующих продуктовых команд в компании выбрать ту, которая станет первопроходцем по внедрению DevOps практик.

Пилотная команда выбирается так, чтобы ее результаты были показательными. Например, можно внедрить автоматическую поставку, но если продукт обновляется раз в полгода, то это изменение не будет показательным для остальных команд. Также нельзя забывать про желания и инициативу сотрудников, готовность команды часть своего времени тратить на изменение, сместив на время фокус с развития продукта.

Коммуникация

Scrum — это одна из нескольких методологий гибкой разработки ПО

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

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

Книги Scrum, которые стоит прочитать

Набирает популярность одна из самых прогрессивных методик гибкой разработки проектов – Scrum (один из agile-подходов). И все русскоязычное пространство отчаянно нуждается в толковых учебниках, которые помогут научиться управлять проектами максимально просто и эффективно.

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

Книга автора методики Джеффа Сазерленда разворачивает мозги менеджеров в совершенно другом направлении и приводит к результатам, достичь которых старыми способами физически было невозможно. 

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

Метод Scrum универсален и применим в любом месте: в разработках программного обеспечения, ФБР, автопроизводстве, фармацевтике, и даже в отдельно взятой семье, которая планирует свой отдых или ремонт.

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

Книги по Scrum будут полезны:

• Управленцам и менеджерам проектов.
• ИТ-Разработчикам, аналитикам, тестировщикам.
• Скрам-мастеру, который отвечает за успех проекта и координирует усилия самоорганизующейся команды, создает атмосферу доверия и устраняет препятствия.
• Членам самоуправляемой группы, в которой оценивается не их отдельный вклад, а командная работа.

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

В них собраны ответы на самые распространенные вопросы:

• С чего начать внедрение методологии Scrum.
• Как запустить процесс.
• Помощь людям в освоении новых ролей.
• Как структурировать работу коллектива.
• Работа с коллективом в условиях рассредоточенности.
• Как преодолеть сопротивление переменам отдельных индивидов  в рамках метода Scrum.
• Вопросы руководства проектами, в которых задействовано несколько коллективов.

Как видите, в книгах по Scrum  полезную информацию найдут для себя специалисты самых разных направлений — менеджеры проектов, руководители всех рангов, ИТ-специалисты и другие.

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

Здесь можно скачать лучшие книги по скраму бесплатно для ознакомления, почитать онлайн или купить полную электронную версию в форматах FB2, PDF, EPUB, TXT, DOC, MOBI.

Только легальный контент от правообладателей!

Как связаны DevOps и Agile

В общем случае DevOps, как и Agile, — это набор практик для сокращения сроков выпуска конкурентоспособного программного обеспечения за счет взаимной интеграции процессов его разработки и эксплуатации путем эффективного взаимодействия профильных специалистов (аналитиков, программистов, тестировщиков, администраторов и т.д.)1. Этот термин стал популярным с начала 2010-х годов, в рамках развития микросервисной архитектуры, когда программный продукт строится как совокупность небольших взаимодействующих друг с другом слабосвязанных модулей. Это существенно ускоряет разработку решения, поскольку каждый модуль может автономно создаваться отдельным специалистом и интегрироваться с другими с помощью открытых API, например, REST . При этом в зоне ответственности разработчика (DevOps-инженера) находятся не только процессы написания и отладки программного кода, но и вопросы его тестирования, интеграционной сборки, выпуска, развертывания, использования и эксплуатационного мониторинга . Такой комплексный подход устраняет организационные барьеры между этапами создания и эксплуатации продукта, позволяя релиз за релизом быстро увеличивать его функциональность, что соответствует итерациям в методологии Agile.

Процессы DevOps: Development Operation

Сколько вешать в граммах

Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.

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

Опыт:

1. до 3-х лет — Junior
2. до 6-ти лет — Middle
3. более 6-ти — Senior

Сайт поиска сотрудников предлагает:
System Adminsitrators:

1. Junior — 2 года — 50к руб.
2. Middle — 5 лет — 70к руб.
3. Senior — 11 лет — 100к руб.

DevOps Engineers:

1. Junior — 2 года — 100к руб.
2. Middle — 3 года — 160к руб.
3. Senior — 6 лет — 220к руб.

По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.

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

Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.

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

Так кто же они? DevOps’ы или жадные системные администраторы? =)

С какими трудностями можно столкнуться

Сам процесс внедрения потребует вложений. Это, скорее всего, приведет к замедлению в работе команд на какой-то период. Потому что у всех появится много новых задач и инструментов, будут меняться рабочие процессы. Отсутствие достаточной подготовки и компетенций по практикам и инструментам могут привести к увеличению количества ошибок, технических сбоев, проблем с использованием технологий. Желательно заранее договориться с руководством об увеличении бюджета ошибок и объема тестирования.

Многие процессы и разграничение зон ответственности могут заработать «со скрипом». В этой ситуации может понадобиться специалист для фасилитации и контроля процессов.

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

Дополнительно потребуются ресурсы на обучение: новые практики и инструменты требуют освоения, не лишним будет посещение конференций/митапов по теме DevOps. Учитывайте, что вам и вашим коллегам придется больше отрываться от текущих рабочих задач, чтобы пройти онлайн-курс или мастер-класс, посмотреть записи докладов.

Как руководитель может отнестись к идее о внедрении DevOps

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

За последние 10 лет по теме внедрения DevOps накопилось много материалов, книг, докладов и исследований от разных представителей IT-индустрии. Стоит ознакомиться с кейсами известных компаний, как русских, так и зарубежных — многие охотно рассказывают о результатах своей DevOps-трансформации. Также полезно почитать книгу «Accelerate», которая основана на 4-летнем исследовании DevOps. И если руководителя не убедил опыт других компаний, то, возможно, его сдерживают факторы, которые не очевидны для инициатора DevOps-трансформации.

Большинство руководителей понимают, что DevOps позволяет ускорить поставки, повысить качество, расширить позиции компании на рынке и подготовить инфраструктуру и процессы к охвату более широкой аудитории

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

И освободившееся от рутины время потратить на следующие этапы улучшений и демонстрировать руководителю результаты.

Если руководитель боится неопределенности, то можно пригласить помощь со стороны. На рынке много специалистов, которые могут построить индивидуальный для компании roadmap преобразований, провести анализ и сформировать рекомендации.

Где, как и кем используется Agile

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

• рост от продажи устройств на 45%;
• сокращение сроков запуска рекламных кампаний в 2 раза;
• рост плановой ежемесячной выручки от разработки продуктов на 20%;
• в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений . Подобным опытом делится Райффайзен-Банк и Сбербанк . Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам . Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях . В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах .

Источники

1. https://ru.m.wikipedia.org/wiki/Гибкая_методология_разработки
2. https://ru.wikipedia.org/wiki/Микросервисная_архитектура
3. https://ru.m.wikipedia.org/wiki/Каскадная_модель
4. https://rb.ru/story/agile-scrum-kanban/
5. https://habr.com/ru/company/dataart/blog/290340/
6. https://onagile.ru/industries/telecommunication/agile-in-telecom
7. http://www.tadviser.ru/index.php/Проект:Agile_в_Банке_России
8. http://www.tadviser.ru/index.php/ Статья:Интервью_с_CIO_Райффайзенбанка_Андреем_Поповым
9. https://vc.ru/sberbank/38179-agile-na-11-000-sotrudnikov
10. https://vc.ru/office/37191-shtab-kvartira-ofis-kompanii-gazprom-neft-v-sankt-peterburge
11. http://bujet.ru/article/375271.php
12. https://biz.mann-ivanov-ferber.ru/2016/05/24/kak-agile-ispolzuyut-v-pravitelstve-norvegii-novoj-zelandii-i-ssha-ili-o-vazhnosti-izmenenij/