Agile

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

Hewlett-Packard продвигает методологию DevOps как средство быстрого создания, обновления и доставки приложений.

Участник ITMF 2015 Александр Огнивцев делится опытом, как совместить Agile и ITSM.

Тенденции и комментарии

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

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

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

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

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

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

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

В феврале 2001 года семнадцать представителей нетрадиционных направлений программной инженерии сформулировали основные принципы «скорой» (agile) разработки в документе под названием Agile Manifesto. Среди авторов манифеста был Джеф Сазерленд — создатель самой первой agile-методологии Scrum.

Многие полагают, что итеративная и инкрементальная разработка (iterative and incremental development, IID) — явление новое. Однако на самом деле истоки этого метода восходят еще к середине 50-х годов. На протяжении последующих десятилетий в его пользу высказывались выдающиеся теоретики в области технологии программирования; метод находил успешное воплощение во многих проектах.