Основы Agile-методологий

Введение в Agile

В материале излагается суть гибкой методологии Agile: от этимологии термина и базовых определений до исторического контекста возникновения манифеста в 2001 году. Логика повествования строится от общего к частному: сначала раскрывается понятийный аппарат (фреймворк, итеративность), затем анализируются предпосылки появления Agile как реакции на кризис тяжеловесных методологий (каскадной и спиральной моделей). Далее детально разбираются четыре ценности и принципы Agile-манифеста, а также его эволюция до версии 2.0. Завершается изложение обзором практических областей применения и базовыми техниками работы.

Основные мысли

В результате изучения лекции слушатель будет способен:
1. Сформулировать сущность методологии Agile и объяснить значение термина «фреймворк» в контексте разработки.
2. Описать исторические предпосылки, которые привели к появлению гибких методологий в противовес каскадной модели.
3. Сравнить ключевые ценности классического Agile-манифеста с положениями его современной версии (Agile-манифест 2.0).
4. Проанализировать причины смещения фокуса с процессов и документации на людей и работающий продукт.
5. Соотнести конкретные техники (User Story, Daily Meeting) с решаемыми задачами в бизнесе и HR.
6. Оценить применимость принципов Agile в не-IT сферах, опираясь на критерии неопределенности требований и прототипирования.
Показывать лекцию целиком
Краткое изложение


О чем этот курс

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

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

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

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

Знание и умение оперировать понятиями и атрибутами Agile позволит менеджерам и профильным специалистам быть эффективными в мире создания программных продуктов любого объема и степени сложности.

Для кого предназначен этот курс

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

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

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

Актуальность Agile

Актуальность Agile обусловлена множеством различных технологических, организационных и социальных факторов.

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

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

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

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

Чем Agile может быть полезна для вашей компании

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

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

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

1.1. Введение

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

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

На текущий момент сложилось два основных противодействующих лагеря.

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

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

Все семейство гибких методологий на сегодняшний день находятся в непрерывном развитии:

1.2. Что такое Agile?

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

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

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

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

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

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

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

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

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

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

Главная задача, которую необходимо решать каждому предприятию, пришедшему к необходимости применения ИС, - это то, что процессами их внедрения, разработки и развития надо также управлять.

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

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

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

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

Agile - процессная методология, состоящая из серии подходов (Scrum, Kanban и пр.) к разработке программного обеспечения или информационного продукта, ориентированная на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации, в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

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

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

Agile - это framework для разработки и поддержки функционально сложных продуктов.

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

Agile - это framework, используемый для комплексного управления процессами.

Agile - это активно развивающаяся (с начала 90-x) процессная методология, цель которой заключается в оптимальной организации рабочего наукоемкого процесса, создании эффективных инструментов мониторинга и контроля за его исполнителями и производимыми результатами.

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

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

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

В утверждении, что Agile - это гибкий управленческий framework, нет лукавства. Это действительно так, что подтверждено на практике. Многие компании, основными процессами которых являются маркетинг, консалтинг и пр., уже успешно "живут" по Agile.

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

1.3. Немного из истории

В феврале, а точнее, в выходные с 11-е по 13-е, 2001 года на горнолыжном курорте в горном хребте Васатч, штат Юта (США), 17 человек, уважаемых специалистов в области разработки программного обеспечения, встретились пообщаться на общие темы (боль, идеи, надежды), покататься на лыжах и, конечно же, поесть…

Именно так, если верить авторитетным источникам, началась официальная история самого популярного отпрыска семейства Agile - Scrum.

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

Начиная с конца 80-х рынок информационных технологий, как в старушке Европе, так и в Соединенных Штатах Америки, начал готовиться (а вернее, его начали готовить именно те, кто в последующем станут авторами Agile) к прорыву.

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

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

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

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

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

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

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

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

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

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

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

1.4. Об авторах Agile

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

Англоязычные источники среди прочих выделяют следующих авторов:

Вэрд Кэнингхэм

Основатель одноименной компании, является директором в области исследований и разработок компании "Вэйт Программное обеспечение". Перед этим занимал пост главного инженера в компании "Научно-исследовательская компьютерная лаборатория Тектроникс".

Вэрд хорошо известен своим вкладом в разработку одной из практик объектно-ориентированного программирования, называемой экстремальным программированием, и созданной им технологией Wiki.

Джим Хэнгсмит

Главный разработчик метода "Адаптивной разработки", входящей в семейство Agile, и автор книги с одноименным названием. Он одним из первых начал публично пропагандировать использование Agile на международных конференциях по разработке ПО. Джим в соавторстве с Мартином Фаулером создал статью-исследование "The Agile" в популярном журнале "Разработка программного обеспечения". Джим и Алистер Кокберн работали над созданием многих ответвлений Agile-семейства, которые были опубликованы в издательстве Addison-Wesley в виде серии книг по Agile.

Эндрю Хант

Один из авторов книги "The Pragmatic Programmers" и соавтор бестселлера "Прагматичный программист: путь от новичка до Мастера". Между написанием книг и статей, произнесением вдохновляющих речей и игрой на пианино Эндрю находит время для своего консультационного бизнеса, специализирующегося на Agile. Энди создает программное обеспечение профессионально с 80-х годов и успел погрузиться в такие отрасли, как телекоммуникации, банковская и финансовая сферы, утилизация, медицина, графическое искусство и, конечно же, создание сервисов в Интернете. Энди задействован в компании Raleigh NC и со своим соавтором Дэйвом Томасом занимается распространением наиболее эффективных и хорошо себя зарекомендовавших методов разработки программного обеспечения в США. Он также является президентом RTP, отделения независимой ассоциации компьютерных консультантов и членом ACM и IEEE.

Рон Джефрис

Основатель портала XProgramming.com, консультант компании Object Mentor и автор (совместно с Анной Эндерсон и Четом Хендриксоном) Extreme Programming, Рон был первым тренером по методологии Extreme Programming.

Джон Керн

Джон питает страсть к оказанию успешной помощи клиентам в достижении ими ценности от использования разработанного им программного обеспечения. Его разнообразная карьера растянулась с исследовательской деятельности по созданию двигателя для реактивных самолетов до разработки летательного симулятора, он стал евангелистом (приверженцем-распространителем) объектно-ориентированного подхода c 90-х годов, начав с использования C++ и затем приступив к Java. Он первым опубликовал описание использования итерационной разработки при создании Lotus Notes 4.5 и 5.0. Он был мотивирован мантрой, которую произносил его друг Питер Код: "Часто, осязаемо, дающее результат". Он получил степень доктора наук, основал собственную компанию (Lightship, Inc.). В 1999 году он присоединился к Питеру Коду в его стартапе "TogetherSoft", где он создал профессиональную группу консультантов и работал над разработкой программных продуктов. Джон - соавтор реализации Java, работал вместе с Питером и Джефом ДеЛука над FDD. Джон постоянно занят поиском наилучших методов достижения поставленных целей с точки зрения используемой методологии работы и используемых технологий. Вы можете найти его блог по адресу http://blogs.compuware.com/cs/blogs/jkern/.

Брайан Марик

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

Роберт С. Мартин

Специалист в области разработки программного обеспечения с 1970 года. Президент и основатель Object Mentor Inc. - компании, которая занимается глубокой экспертизой с помощью гибких методологий, разработке программного обеспечения, обучении и разработки систем и сервисов для крупных корпораций. В 1995 году написал бестселлер "Проектирование приложений на Object Oriented C++ с применением метода Буча". В 1997 году был главным редактором книги "Шаблоны проектирования языков программирования". В 1999 году был редактором книги "More C++ Gems". Соавтор книги "XP in Practice", изданной в 2001 году. Непосредственно работал над книгой "Принципы, шаблоны и практика разработки программного обеспечения по Agile", изданной в 2002 году. С 1996 по 1999 год был главным редактором отчетов по С++. Опубликовал множество статей в различных журналах и выступает в качестве постоянного докладчика на международных конференциях.

Майк Бидл

Основатель и исполнительный директор компании e-Architects Inc. Один из самых ранних евангелистов философии Agile. Майк специализируется на создании масштабных информационных систем, в работу над которыми, как правило, вовлекается множество распределенных команд.

Ари Ван Беннекум

Разработчик, консультант, практикующий тренер. Один из самых активных пропагандистов Agile-процессов. Внутренний двигатель Scrum-cообщества.

Алистер Кокберн

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

Мартин Фаулер

Исполнительный директор по исследованиям крупной компании в области разработки программного обеспечения и консалтинга. Автор книг по аналитическим шаблонам, использованию Uml, рефакторингу, планированию и другим видам активностей в направлении Agile. Несмотря на то, что Мартин Фаулер напрямую не участвовал в разработке и продвижении Agile, профессионалы относят его к числу тех, кто внес в ее развитие наибольший вклад.

Кен Швайбер

Президент компании ADM. Разработчик, проектный менеджер, консультант, инициировавший массовый переход от тяжеловесных методологий в сторону Agile. Один из авторов ответвления Scrum (вместе с Д. Сазерлендом), которое на сегодняшний день имеет наибольшую популярность среди Agile-направлений.

Джеф Сазерленд

Директор по технологиям крупной компании. Соавтор Scrum. Архитектор крупных информационных наукоемких систем.

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

1.5. Как развивалась Agile

Описание процесса зарождения и развития Agile стоит начать с ситуации, происходившей в отрасли в середине прошлого века.

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

Затем произошел прорыв развития электроники и, как следствие, увеличилась производительность компьютеров, а стоимость их стала резко снижаться. Ограничения на разработку, связанные с аппаратными средствами, стали исчезать или трансформироваться в ограничения на ПО. Таким образом, умение разрабатывать новые программы диссонировало с теми требованиями, которые заказчики предъявляли к этим самым программам. Это привело к тому, что разработка программного обеспечения перестала быть просто "кодированием", а стала формироваться в виде конкретных концепций, поддерживающих полный жизненный цикл разрабатываемых программ (формирование идеи, анализ требований, проектирование функциональности, разработка ПО, тестирование ПО, внедрение, поддержка с последующей утилизацией).

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

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

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

Если мы рассмотрим любую современную методологию управления проектом или моделями жизненного цикла проекта по разработке информационных систем, согласно SWEBOK, то выглядеть она будет следующим образом:

SWEBOK - документ, в котором описаны эталонные методики по всем стадиям разработки программного обеспечения.

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

Каскадная модель ( рис. 1.1) разработки программного обеспечения является первой и, как следствие, самой критикуемой. При работе с данной методологией предполагается последовательное выполнение этапов разработки. Такая структура не дает изменить требования к программному продукту до самого релиза.

Рис. 1.1. Каскадная модель разработки

Рис. 1.1. Каскадная модель разработки

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

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

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

Следующей по времени возникновения и эволюционному развитию стала спиральная модель (рис. 1.2). Как это часто бывает с последователем, в ней попытались исправить все основные проблемы ее предшественника.

Рис. 1.2. Спиральная модель разработки

Рис. 1.2. Спиральная модель разработки

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

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

Истоки концепции итеративной разработки прослеживаются в относящихся к 1930-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение спиральной методологии в значительной степени определило дальнейший успех проекта.

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

Стоит отметить, что Agile-семейство, по сути, является ответвлением итеративной модели разработки программного обеспечения. При описании любой из гибких методологий упоминается принцип разделения на итерации, который нашел отражение во многих артефактах, применяемых в Agile (task board и пр.).

Следующие вехи в развитии Agile заслуживают упоминания:

Crystal фокусируется на:

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

DSDM фокусируется на восьми основных принципах:

Основные практики, описанные в FDD, следующие:

Это адаптация бережливых принципов производства к разработке программного обеспечения. Рассматриваются семь основных принципов:

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

1.6. Agile Manifesto

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

Этим документом является Agile Manifesto. По сути, его и документом назвать сложно. Это, скорее, небольшая памятка, которая содержит 4 ценности и 12 принципов работы. Далее мы приведем полное содержание Agile Manifesto, как оно представлено на официальном сайте (http://agilemanifesto.org/) разработавшего его консорциума.

Ценности:

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

Таким образом, не отрицая важности того, что справа, все-таки больше ценится то, что слева.

Основные принципы:

  1. Наивысшим приоритетом является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
  2. Изменение требований приветствуется даже на поздних стадиях разработки.
  3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
  4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
  5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
  6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией, как с самой командой, так и внутри команды.
  7. Работающий продукт - основной показатель прогресса.
  8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
  9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
  10. Простота - искусство минимизации лишней работы - крайне необходима.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

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

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

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

1.7. Применение в различных предметных областях

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

Одним из основных постулатов использования Agile является разработка эффективного конечного продукта.

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

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

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

В последнее время получает широкое распространение способ управления, называемый холакратией. Это подход к управлению и распределению ответственности, который позволяет избавиться от иерархии в компании. Каждый сотрудник (холакратия предлагает вместо слова "сотрудник" использовать слово "партнер") попадает в условия, которые на постсоветском пространстве называются "работать, как для себя", непрерывно что-то изменяет и улучшает в той части бизнеса, за которую он ответственен. И это не просто слова, это логическое продолжение Agile, которое имеет примеры успешного применения (проект "Кнопка").

Основное в применении Agile - это желание учиться и развиваться. Профессионалы, которые стремятся к использованию новых идей и передовых практик, как правило, с удовольствием становятся на рельсы Agile.

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

1.8. Краткие выводы

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

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

Сущность Agile
Agile — это гибкая процессная методология, представляющая собой серию подходов к разработке ПО. Она основана на итеративной разработке и динамическом формировании требований за счет взаимодействия в самоорганизующихся группах из специалистов разного профиля.
В практическом смысле Agile — это фреймворк. Фреймворк — набор методов и инструментов, который очерчивает границы рабочего процесса. С управленческой точки зрения это инструмент для комплексного управления, который ценят за простоту внедрения и адаптивность к изменениям. Методология нацелена на организацию наукоемкого процесса для создания конкурентоспособных продуктов и применима практически в любой сфере.

Исторический контекст
В начале 2000-х годов развитие IT достигло точки, когда тяжеловесные методы разработки стали тормозом. Скорость изменений требовала выпуска продуктов без долгого планирования и многотомной документации, так как продукт мог устареть еще на этапе создания. В 2001 году 17 профессионалов встретились в Юте и сформулировали Agile-манифест.
Ключевые основатели направления:
• Джим Хайсмит: метод адаптивной разработки.
• Рон Джеффрис: экстремальное программирование.
• Роберт Мартин («Дядя Боб») : принципы архитектуры и дизайна ПО.
• Мартин Фаулер: рефакторинг и аналитические шаблоны.
• Кен Швабер и Джефф Сазерленд: создатели Scrum — самого популярного метода в семействе Agile.

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

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

Ценности и эволюция манифеста
Основной документ Agile включает четыре ключевые ценности (левая часть весомее правой):
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования контракта.
4. Готовность к изменениям важнее следования плану.
Это манифест приоритета живого общения над бюрократией и прибыли над формальностями. Позже появился Agile-манифест 2.0, сместивший акценты на уровень команды и бизнес-ценностей:
• Командная ответственность выше индивидуальной.
• Ценность для бизнеса выше просто рабочего кода.
• Развитие партнерств выше простого сотрудничества.
• Проактивная подготовка к переменам выше реактивного реагирования.

Применение на практике
Agile из методологии разработки превратился в культуру управления для HR, маркетинга и других сфер. Идеальным состоянием является «эквилибриум» стартапов, где каждый вовлечен во все процессы. Базовый рабочий цикл (реинкарнация цикла Деминга) выглядит так: слушать рынок → проводить работы → измерять результат → вносить правки. И все это за одну-две недели.
Ключевые техники:
• User Story (Пользовательская история): техника фиксации требований, фокусирующаяся не на техзадании, а на описании действий клиента для достижения его цели. Помогает кроссфункциональной команде работать слаженно.
• Daily Meeting: 10-минутная ежедневная синхронизация для удержания фокуса на улучшении потребительской ценности.
Agile наиболее эффективен в проектах с нечеткими требованиями, где заказчик готов идти путем прототипирования в роли владельца продукта. Суть в том, что любой сотрудник конвейера разработки может остановить процесс ради ценного улучшения, становясь инноватором, а не просто исполнителем.

Выводы

1. Agile — это не конкретный набор ритуалов, а философия или фреймворк, задающий границы рабочего процесса.
2. Методология фокусируется на эмпирическом контроле и адаптации, противопоставляя себя детерминированному планированию.
3. Приоритет человека и взаимодействия над процессами означает, что коммуникация важнее регламентов.
4. Ценность определяется работающим продуктом, приносящим прибыль здесь и сейчас, а не томами спецификаций.
5. Сотрудничество с заказчиком выгоднее жестких контрактов, так как позволяет уточнять требования по ходу разработки.
6. Готовность к изменениям — это не тактический ход, а стратегический ресурс выживания в условиях неопределенности.
7. Исторически Agile стал реакцией на кризис тяжеловесных методологий, при котором продукт морально устаревал до релиза.
8. Итеративная инкрементальная разработка позволяет получать обратную связь на ранних этапах и минимизировать риски.
9. Техники вроде User Story и Daily Meeting являются практическими инструментами удержания фокуса на нуждах пользователя.
10. Эволюция до Манифеста 2.0 смещает акцент с личной эффективности на командную ответственность и партнерство.
11. Методология применима вне IT (HR, маркетинг) в процессах, где нужна быстрая проверка гипотез и прототипирование.
12. Успех внедрения зависит не от копирования инструментов, а от создания среды, где каждый участник вовлечен в улучшение общего дела.

Вопросы для самопроверки

1. Чем определение Agile как «фреймворка» отличается от определения его как «методологии»?
2. Почему акцент на работающем продукте стал критичным в конце XX века?
3. В чем заключается ограничение каскадной модели при изменении требований заказчика?
4. Какие психологические аспекты работы в самоорганизующихся группах использует Agile?
5. Почему в Agile-манифесте сотрудничество с заказчиком ставится выше условий контракта?
6. Какое ключевое смещение приоритетов произошло при переходе к версии Agile-манифест 2.0?
7. На основе чего формируется ценность создаваемого продукта в итеративной разработке?
8. Как состояние «эквилибриум» в стартапах связано с ценностями гибкого подхода?
9. Каким образом техника «User Story» решает проблему сбора требований без детального ТЗ?
10. Чем работа короткими циклами (спринтами) помогает избегать риска устаревания продукта?
11. Почему модель непрерывной интеграции и инкремента ускоряет общий выпуск продукта?
12. Может ли конвейерный принцип производства сочетаться с философией Agile?
Вернуться к учебному плану