Как Agile IT может трансформировать ИТ-индустрию?

Автор: Roger Morrison
Дата создания: 20 Сентябрь 2021
Дата обновления: 21 Июнь 2024
Anonim
Основы информатизации предприятий. Понятие ИТ-инфраструктуры
Видео: Основы информатизации предприятий. Понятие ИТ-инфраструктуры

Содержание



Источник: Дарковуйич / Dreamstime.com

вынос:

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

Гибкая методология разработки программного обеспечения может оказать положительное влияние на ИТ-индустрию. Результаты применения гибкой методологии можно измерить несколькими способами. Более быстрое выполнение запросов на изменение программного обеспечения, меньшее количество ошибок, количественное измерение производительности команды и узкие места - все это отражает успешную реализацию Agile. Чтобы успешно измерить влияние Agile, организации необходимо сравнить различные показатели, связанные с разработкой до Agile и после Agile. Реальное влияние Agile не может быть измерено только увеличением дохода или увеличением количества исправленных ошибок. Несколько внутренних параметров необходимо учитывать, чтобы понять реальное влияние. (Подробнее о гибкой разработке см. Agile Software Development 101.)


Почему Agile IT?

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

Проще говоря, модель водопада - это модель разработки программного обеспечения, в которой работа выполняется последовательно - один этап за другим. Эта модель имеет пять этапов: требования, проектирование, внедрение, проверка и обслуживание. Как правило, после завершения одного этапа трудно, если не невозможно, внести изменения в более ранний этап. Таким образом, предполагается, что требования в значительной степени фиксированы. Основное отличие модели Agile заключается в предположении, что требования не будут изменены. Agile предполагает, что деловые ситуации будут меняться, а также требования. Таким образом, программное обеспечение доставляется небольшими порциями по сравнению с ss, тогда как в модели с водопадом первая доставка или выпуск выполняется через длительное время. (Подробнее о разработке см. В разделе Как Apache Spark помогает быстрой разработке приложений.)


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

В другом примере Крейг Ларман, автор книги «Гибкая и итеративная разработка: руководство менеджера», указал на то, что ряд проектов, выполненных Министерством обороны (DoD) с использованием модели водопада в США, не смогли достичь своих целей. В течение 1980-х и 1990-х годов Министерство обороны требовало использовать модель водопада для своих проектов разработки программного обеспечения в соответствии со стандартами, опубликованными в DoD STD 2167. Шокирующая статистика показала, что 75% этих программных проектов никогда не использовались. После этого отчета была создана целевая группа под руководством доктора Фредерика Брукса, известного эксперта по разработке программного обеспечения. Целевая группа выступила с докладом, в котором говорилось: «DoD STD 2167 также нуждается в радикальном пересмотре, чтобы отразить лучшую современную практику. Эволюционное развитие лучше всего технически, оно экономит время и деньги ».

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

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

Как Agile методология решает проблемы модели водопада?

Методология Agile принципиально отличается от модели водопада, и это ясно из ее предположений:

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

Как Agile повлиял на ИТ-индустрию?

Agile внедряется во многих местах, в то время как многие компании планируют использовать Agile. Хотя Agile определенно внес фундаментальные изменения в ИТ-индустрию, факты и цифры все еще трудно получить. Но влияние Agile можно понять с помощью тематического исследования British Telecom (BT), приведенного ниже.

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


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

Причины BT перешли на гибкие практики

BT начала испытывать ряд проблем с практикой разработки программного обеспечения еще в 2004 году. BT разработала ряд программных проектов, как простых, так и сложных. Многие программные проекты не смогли разработать качественную продукцию в согласованные сроки. БТ обнаружил, что проблемы связаны с моделью водопада. Таким образом, укрепление модели водопада не собиралось помогать. Основные причины проблем приведены ниже:

Плохое управление требованиями

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

Плохой дизайн программного обеспечения

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

Ограничения развития

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

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

Что BT сделала для решения вышеуказанных проблем?

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

  • Вместо 12-месячного цикла разработки BT теперь поставляет работоспособные части программного обеспечения в 90-дневном цикле. Идея заключалась в том, чтобы сосредоточиться на одной или двух проблемах бизнеса и нацелить их на предоставление программного решения в течение 90 дней. Начало этого цикла было отмечено интенсивным обсуждением между различными заинтересованными сторонами, так что требования были четко определены, проанализированы и расставлены приоритеты.
  • Цель состояла в том, чтобы предоставить ясные, ощутимые бизнес-ценности Внутренний клиент был вынужден предоставить четкие требования. Таким образом, вместо смутных целей, истории пользователей давались с четкими критериями приемлемости.
  • Поставляемое программное обеспечение будет полностью протестировано и задокументировано. Программное обеспечение будет проходить частые интеграционные тесты, чтобы заранее идентифицировать проблемы.

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

Заключение

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