Видение кризиса инженерных подходов и зарождение идей гибкого управления ит-проектами
Основные проявления кризиса программного обеспечения:
разработка программного обеспечения была и остаётся мало предсказуемым и далеко не всегда успешным делом;
значительный процент проектов по созданию программного обеспечения по-прежнему заканчивается с превышением бюджета и сроков;
созданные в результате программные продукты часто не до конца отвечают требованиям пользователей либо приносят мало реальной пользы бизнесу.
Первоначальный подход к разработке ПО
Процесс Code-and-Fix (кодирование и исправление) - разработка программного обеспечения начинается непосредственно с кодирования (без предварительного планирования, анализа требований и проектирования). После этого найденные в коде проблемы (дефекты, несоответствие требованиям и т.п.) исправляются путём внесения множественных изменений в код
Традиционный подход к разработке ПО
Инженерные методологии разработки программного обеспечения (основанные на плане (plan-driven)) – в их основе лежит предположение о том, что процесс разработки программного обеспечения является детерминированным инженерным процессом, который можно спланировать от начала и до конца и выполнить в соответствии с планом, используя формальные инженерные подходы
Переход к строго формализованным подходам разработки ПО
Проявления конфликта уникальности программного обеспечения с подходами инженерных методологий:
недооценка роли человеческого фактора;
несоответствие водопадного жизненного цикла природе программного обеспечения.
Факторы, влияющие на производительность труда:
качество рабочего места;
психологическая обстановка в команде;
эффективные коммуникации и прочие социальные факторы.
Главная причина несоответствия водопадного жизненного цикла природе ПО
Уникальность и новизна практически любого программного продукта приводит к тому, что разработка ведётся в условиях высокой неопределённости, и попытка учесть все факторы в начале проекта (составить детальные требования, затем полностью разработать дизайн системы и т.д.) заранее обречена на провал
Гибкие методологии разработки. Манифест и принципы Agile. Семейство Agile-методологий
Принцип создания альтернативных методологий управления ИТ-проектами
В качестве альтернативы тяжеловесным и излишне формализованным инженерным методологиям новые методологии стремились предложить адаптивные, итерационные, ориентированные на человека подходы
Переход к семейству гибких методологий управления ИТ-проектами
Место альтернативных методологий управления ИТ-проектами
По степени формализации гибкие методологии занимают как бы промежуточное положение между двумя предшествующими подходами. Они не так жёстко формализованы, как инженерные, однако ни в коем случае не приветствуют хаотичную бессистемную разработку (как это иногда пытаются представить)
Момент формальной декларации гибких методологий управления ИТ-проектами
В феврале 2001 года на лыжном курорте Сноубёрд (штат Юта) впервые прогрессивные ценности человеческого фактора и принципы итерационной разработки были собраны вместе и рекомендованы уважаемыми специалистами в качестве проверенной и самодостаточной альтернативы традиционным подходам к разработке
Суть Agile-манифеста заключается в следующих положениях:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Данный манифест поддерживается следующими принципами:
наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения;
изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества;
работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев;
на протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе;
над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им;
непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды;
работающий продукт — основной показатель прогресса;
инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки;
постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта;
простота — искусство минимизации лишней работы — крайне необходима;
самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд;
команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
В качестве преимуществ такого подхода декларируются:
за очень короткий промежуток времени project manager и все члены команды могут оценить статус проекта;
все возникшие проблемы решаются очень быстро так как доносятся до всех участников проекта (среди которых потенциально есть компетентные в данном вопросе люди);
сотрудники учатся слушать других, понимать их, а также четко выражать свои собственные мысли;
участники проекта учатся ставить перед собой реальные задачи и отвечать за статус их выполнения.
На текущий момент в семейство Agile-методологий входят множество отдельных методологий, методов и подходов, примерами которых являются:
методология экстремального программирования (XP);
методология бережливой разработки ПО (Lean);
методология управления разработкой ИС для гибкой разработки ПО (Scrum);
методология разработки, управляемой функциональностью (FDD);
набор Agile-ориентированных подходов к отдельным видам работ по созданию ИС и ИТ (моделирование, унифицированные процессы разработки ПО и т.п.);
итеративно инкрементальный метод разработки ПО (OpenUP).