Разница в том, что происходит после разработки
Когда ПО только начали разрабатывать, процесс разработки не подходил ни под один вид управления. Затем появился водопад, который ввел идею о том, что разработка ПО может быть определена временем создания или сборки приложения.
Раньше тестирование и развертывание ПО занимало гораздо больше времени, чем сейчас, так как во время процесса разработки не было никакого баланса и проверок на промежуточных этапах. В результате мы получали ПО низкого качества с ошибками и багами, сделанное сильно позже установленных сроков. Основное внимание уделялось долгим и затяжным планированием проектов.
Водопадные проекты были связаны с моделью тройного ограничения, которую еще называют треугольником управления проектами. Каждая сторона треугольника представляет собой одно из ограничений управления проектами: масштаб, время и стоимость. Как пишет Анджело Беретта, модель тройного ограничения утверждает, что «стоимость является функцией времени и объема, а эти три фактора связаны определенным и предсказуемым образом… Если мы хотим сократить сроки выполнения плана (время), мы должны увеличить стоимость. Модель также подразумевает, что если мы хотим увеличить объем, то должны увеличить стоимость или сроки выполнения.»
Водопад пришел к нам из производства и машиностроения, которые сложно представить без линейного процесса. Прежде чем строить крышу, вы строите стены. Проблемы разработки ПО тоже рассматривались как нечто, что можно было решить с помощью планирования.
В конце концов, водопад был признан вредным подходом, противоречащим интуитивному подходу к разработке ПО. Очень часто ценность проекта не могла быть определена до самого конца проектного цикла. Во многих случаях проекты терпели неудачу. Кроме того, заказчик не видел ни одного рабочего ПО до конца проекта.
Agile подразумевает другой подход, который отходит от планирования всего проекта, привязки к предполагаемым датам и отчетам. Гибкая методология предполагает неопределенность и учитывает ее. Она призывает реагировать на изменения вместо того, чтобы их игнорировать. Изменения рассматриваются как способ удовлетворения потребностей клиента.
Agile регулируется Agile манифестом. Вот его 12 принципов:
4 основные идеи Agile:
Этот подход сильно отличается от жесткого водопада. В Agile клиент является членом команды разработчиков. В водопаде он участвует только в начале, при определении бизнес-требований, и в конце, при рассмотрении конечного продукта. В Agile клиент помогает команде написать критерии приемлемости продукта и остается вовлеченным на протяжении всего процесса. Кроме того, Agile требует изменений и постоянных улучшений от всех членов организации. Команда разработчиков работает с другими командами, включая менеджеров проекта и тестировщиков. Кто что делает и когда зависит от назначенной роли и обсуждается со всей командой.
Разработка ПО по Agile требует адаптивного планирования, эволюционной разработки и доставки конечного продукта. Многие методологии, структуры и практики разработки ПО относятся к категории гибких, в том числе:
Все они используются сами по себе или в сочетании с другими методологиями для разработки и развертывания ПО. Наиболее распространенными являются Scrum, Kanban (или комбинация, называемая Scrumban) и DevOps.
Scrum — это фреймворк, в котором команда работает самостоятельно и кросс-функционально, чтобы увеличить скорость получения готового продукта и повысить ценность бизнеса клиента. Команда обычно состоит из Scrum-мастера, менеджера продукта и разработчиков. Основное внимание в Scrum уделяется более быстрым итерациям с меньшими улучшениями.
Kanban — это фреймворк Agile, который еще иногда называют системой управления рабочим процессом. Он помогает команде визуализировать свою работу и увеличить эффективность (оставаясь при этом гибкой методологией). Kanban обычно представляет собой цифровую или физическую доску. Задачи команды перемещаются по доске в зависимости от стадии: задача еще не начиналась, в процессе, тестируется, окончена. Kanban позволяет каждому члену команды видеть состояние задач.
DevOps это культура, образ мышления, способ разработки ПО или инфраструктуры, а также способ создания и развертывания ПО и приложений. Операции и разработка не разделены; они работают одновременно, не препятствуя друг другу
DevOps основан на двух других областях: Lean и Agile. DevOps это не название и не роль в компании. На самом деле это обязательство, которое организация или команда берет на себя в отношении непрерывной доставки продукта, его развертывания и интеграции. По словам Джин Ким, автора проектов The Phoenix и The Unicorn Project, существует три «пути», которые определяют принципы DevOps:
DevOps это гибкая практика. В своей истинной форме она представляет собой общую культуру и мышление в отношении разработки ПО и внедрения информационных технологий или инфраструктуры.
Когда вы думаете об автоматизации, облаке, микросервисах, вы думаете о DevOps.
Николь Форсгрен, Джез Хамбл и Джин Ким написали книгу «Ускоряйся! Как создавать и масштабировать высокопроизводительные организации». В одном из интервью они объяснили что же такое DevOps:
Несмотря на сходство, DevOps и Agile далеко не одно и то же. Некоторые утверждают, что DevOps лучше, чем Agile. Чтобы избежать путаницы, важно докопаться до сути.
Сходства
Различия
Agile и DevOps это разные вещи, хотя их сходства заставляют многих думать, что это одно и то же. Подобное непонимание оказывает Agile и DevOps медвежью услугу.
Я работала по Agile и из своего опыта могу сказать, что командам и организациям очень важно понимать, что из себя представляют DevOps и Agile. Нужно также понимать каким образом они помогают командам работать быстрее и эффективнее, обеспечивать качество продукта и повышать удовлетворенность клиентов.
Agile и DevOps ни в коем случае не соперники друг другу (по крайней мере поводов пока нет). Они скорее союзники, чем враги на поле гибких методологий. Agile и DevOps могут работать эксклюзивно и инклюзивно, что позволяет им существовать в одном пространстве.
Перевод: Диана Шеремьёва
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:
Когда ПО только начали разрабатывать, процесс разработки не подходил ни под один вид управления. Затем появился водопад, который ввел идею о том, что разработка ПО может быть определена временем создания или сборки приложения.
Раньше тестирование и развертывание ПО занимало гораздо больше времени, чем сейчас, так как во время процесса разработки не было никакого баланса и проверок на промежуточных этапах. В результате мы получали ПО низкого качества с ошибками и багами, сделанное сильно позже установленных сроков. Основное внимание уделялось долгим и затяжным планированием проектов.
Водопадные проекты были связаны с моделью тройного ограничения, которую еще называют треугольником управления проектами. Каждая сторона треугольника представляет собой одно из ограничений управления проектами: масштаб, время и стоимость. Как пишет Анджело Беретта, модель тройного ограничения утверждает, что «стоимость является функцией времени и объема, а эти три фактора связаны определенным и предсказуемым образом… Если мы хотим сократить сроки выполнения плана (время), мы должны увеличить стоимость. Модель также подразумевает, что если мы хотим увеличить объем, то должны увеличить стоимость или сроки выполнения.»
Переход от водопада к Agile
Водопад пришел к нам из производства и машиностроения, которые сложно представить без линейного процесса. Прежде чем строить крышу, вы строите стены. Проблемы разработки ПО тоже рассматривались как нечто, что можно было решить с помощью планирования.
В конце концов, водопад был признан вредным подходом, противоречащим интуитивному подходу к разработке ПО. Очень часто ценность проекта не могла быть определена до самого конца проектного цикла. Во многих случаях проекты терпели неудачу. Кроме того, заказчик не видел ни одного рабочего ПО до конца проекта.
Agile подразумевает другой подход, который отходит от планирования всего проекта, привязки к предполагаемым датам и отчетам. Гибкая методология предполагает неопределенность и учитывает ее. Она призывает реагировать на изменения вместо того, чтобы их игнорировать. Изменения рассматриваются как способ удовлетворения потребностей клиента.
Ценности Agile
Agile регулируется Agile манифестом. Вот его 12 принципов:
- Наивысшим приоритетом является удовлетворение потребностей клиента.
- Изменение требований приветствуется, даже на поздних стадиях разработки.
- Работающий продукт следует выпускать как можно чаще.
- Разработчики и представители бизнеса должны работать вместе.
- Над проектом должны работать мотивированные профессионалы.
- Общение вживую является наиболее практичным и эффективным способом обмена информацией.
- Работающий продукт — основной показатель прогресса.
- Agile процессы содействуют устойчивому развитию.
- Важно уделять внимание техническому совершенству и хорошему дизайну.
- Простота необходима.
- Лучшие архитектурные решения, требования и идеи дизайна появляются у самоорганизующихся команд.
- Регулярно рефлексируйте на тему способов улучшения эффективности и корректируйте стиль своей работы.
4 основные идеи Agile:
- люди и взаимодействие важнее процессов и инструментов,
- работающий продукт важнее исчерпывающей документации,
- сотрудничество с заказчиком важнее согласования условий контракта,
- готовность к изменениям важнее следования первоначальному плану.
Этот подход сильно отличается от жесткого водопада. В Agile клиент является членом команды разработчиков. В водопаде он участвует только в начале, при определении бизнес-требований, и в конце, при рассмотрении конечного продукта. В Agile клиент помогает команде написать критерии приемлемости продукта и остается вовлеченным на протяжении всего процесса. Кроме того, Agile требует изменений и постоянных улучшений от всех членов организации. Команда разработчиков работает с другими командами, включая менеджеров проекта и тестировщиков. Кто что делает и когда зависит от назначенной роли и обсуждается со всей командой.
Разработка ПО по Agile
Разработка ПО по Agile требует адаптивного планирования, эволюционной разработки и доставки конечного продукта. Многие методологии, структуры и практики разработки ПО относятся к категории гибких, в том числе:
- Scrum
- Kanban (визуальный рабочий процесс)
- XP (экстремальное программирование)
- Lean
- DevOps
- FDD (разработка с акцентом на фичи)
- TDD (разработка с акцентом на тестировании)
- Crystal
- DSDM (Метод разработки динамических систем)
- ASD (Адаптивная разработка программного обеспечения)
Все они используются сами по себе или в сочетании с другими методологиями для разработки и развертывания ПО. Наиболее распространенными являются Scrum, Kanban (или комбинация, называемая Scrumban) и DevOps.
Scrum — это фреймворк, в котором команда работает самостоятельно и кросс-функционально, чтобы увеличить скорость получения готового продукта и повысить ценность бизнеса клиента. Команда обычно состоит из Scrum-мастера, менеджера продукта и разработчиков. Основное внимание в Scrum уделяется более быстрым итерациям с меньшими улучшениями.
Kanban — это фреймворк Agile, который еще иногда называют системой управления рабочим процессом. Он помогает команде визуализировать свою работу и увеличить эффективность (оставаясь при этом гибкой методологией). Kanban обычно представляет собой цифровую или физическую доску. Задачи команды перемещаются по доске в зависимости от стадии: задача еще не начиналась, в процессе, тестируется, окончена. Kanban позволяет каждому члену команды видеть состояние задач.
Ценности DevOps
DevOps это культура, образ мышления, способ разработки ПО или инфраструктуры, а также способ создания и развертывания ПО и приложений. Операции и разработка не разделены; они работают одновременно, не препятствуя друг другу
DevOps основан на двух других областях: Lean и Agile. DevOps это не название и не роль в компании. На самом деле это обязательство, которое организация или команда берет на себя в отношении непрерывной доставки продукта, его развертывания и интеграции. По словам Джин Ким, автора проектов The Phoenix и The Unicorn Project, существует три «пути», которые определяют принципы DevOps:
- принципы потока,
- принципы фидбэка,
- принципы бесконечного обучения.
Разработка ПО по DevOps
DevOps это гибкая практика. В своей истинной форме она представляет собой общую культуру и мышление в отношении разработки ПО и внедрения информационных технологий или инфраструктуры.
Когда вы думаете об автоматизации, облаке, микросервисах, вы думаете о DevOps.
Николь Форсгрен, Джез Хамбл и Джин Ким написали книгу «Ускоряйся! Как создавать и масштабировать высокопроизводительные организации». В одном из интервью они объяснили что же такое DevOps:
- Эффективность поставки ПО имеет значение. Она оказывает существенное влияние на прибыльность, долю рынка, качество, удовлетворенность клиентов, достижение целей организации и миссии.
- Компании с высокой эффективностью достигают высокой скорости разработки, стабильности, качества. Им не приходится ничем жертвовать, чтобы достичь всего этого.
- Вы можете улучшить свою эффективность, внедряя принципы DevOps и практики из Lean, Agile.
- Реализация этих практик и возможностей также влияет на вашу организационную культуру. Она, в свою очередь, влияет как на эффективность вашего ПО, так и на производительность организации.
- Требуется много работать, чтобы понять как улучшить эффективность.
DevOps и Agile
Несмотря на сходство, DevOps и Agile далеко не одно и то же. Некоторые утверждают, что DevOps лучше, чем Agile. Чтобы избежать путаницы, важно докопаться до сути.
Сходства
- И то, и другое это методологии разработки ПО, с этим не поспоришь.
- Agile существует уже более 20 лет, DevOps тоже появилась относительно недавно.
- Оба подхода верят в быструю разработку ПО. Их принципы основаны на том, как быстро разрабатывать ПО, не причиняя вреда клиенту или операциям.
Различия
- Разница в том, что происходит после разработки.
- Разработка, тестирование и развертывание ПО происходят как в DevOps, так и в Agile. Тем не менее, чистый Agile подразумевает, что процесс останавливается после этих трех этапов. DevOps, в свою очередь, включает в себя операции, которые происходят постоянно. Поэтому мониторинг и разработка ПО продолжаются и после получения заказчиком готового продукта.
- В Agile разные люди отвечают за разработку, тестирование и развертывание ПО. В DevOps человек, исполняющий роль инженера DevOps отвечает за все. Разработка это операции, а операции это разработка.
- DevOps больше ассоциируется с сокращением затрат, а Agile с бережливой разработкой и сокращением излишних трат. Также Agile поддерживает идею MVP (минимального жизнеспособного продукта) и учет гибких проектов.
- Agile про эмпирический подход — адаптация, прозрачность и проверка вместо приблизительного прогноза.
| Agile | DevOps |
|---|---|
| Фидбэк от заказчика | Фидбэк от себя |
| Меньше циклы релизов | Меньше циклы релизов, моментальный фидбэк |
| Ставка на скорость | Ставка на скорость и автоматизацию |
| Не лучшее решение для бизнеса | Лучшее решение для бизнеса |
Заключение
Agile и DevOps это разные вещи, хотя их сходства заставляют многих думать, что это одно и то же. Подобное непонимание оказывает Agile и DevOps медвежью услугу.
Я работала по Agile и из своего опыта могу сказать, что командам и организациям очень важно понимать, что из себя представляют DevOps и Agile. Нужно также понимать каким образом они помогают командам работать быстрее и эффективнее, обеспечивать качество продукта и повышать удовлетворенность клиентов.
Agile и DevOps ни в коем случае не соперники друг другу (по крайней мере поводов пока нет). Они скорее союзники, чем враги на поле гибких методологий. Agile и DevOps могут работать эксклюзивно и инклюзивно, что позволяет им существовать в одном пространстве.
Перевод: Диана Шеремьёва
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:
- Курс по DevOps (12 месяцев)
Ещё курсы
- Курс по Machine Learning (12 недель)
- Обучение профессии Data Science с нуля (12 месяцев)
- Профессия аналитика с любым стартовым уровнем (9 месяцев)
- Курс «Python для веб-разработки» (9 месяцев)
