Предпосылки возникновения Agile

3.1. Состояние области процессов разработки программного обеспечения

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

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

В качестве примера приведем исследование Standish group, проведенное в 2015 году. Оно было выполнено по результатам анализа данных о внедрении программных продуктов за период с 2001 по 2010 год. Фундаментом исследования послужила информация по более чем 10 000 проведенных проектов различной степени сложности (рис 3.1).

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

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

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

Затруднительно представить направление деятельности, в котором зависимость от информационных систем была бы незначительна. Технологичные продукты, автоматизирующие операционные процессы, выполняют все те функции, которые возлагали на них в самом фантастичном фильме, созданном не более 10 лет назад. Фантастика становится реальностью. Информатизация материализуется не только в виде социотехнических систем, но и в виде повсеместно используемых сервисов.

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

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

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

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

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

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

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

В то же время итерационный процесс позволит:

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

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

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

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

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

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

На решение и управление перечисленными факторами и направлена Agile. Ее применение позволит решить обозначенные проблемы.

3.2. Сравнение каскадного/итерационного/Agile процессов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве сильных сторон водопадной модели следует выделить следующие:

Agile, в свою очередь, обладает следующими сильными сторонами:

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

"Каскад":

Agile:

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

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

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

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

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

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

Согласно недавнему опросу, 80% решений о внедрении в компании Agile-методологий и идей, принадлежат менеджерам высшего и среднего звена.

3.3. Эффективная таблетка от болезней?

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

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

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

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

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

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

3.4. Для кого подходит, а для кого нет?

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

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

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

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

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

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

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

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

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

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

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

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

В последующих главах курса мы дополним, раскроем и детализируем приведенный список факторов.

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

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

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

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