Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1132 / 176 | Длительность: 10:06:00
Лекция 3:

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

< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Аннотация: Третья глава будет содержать описание текущей ситуации в области разработки программного обеспечения. В ней приведено сравнение наиболее популярных и распространенных процессных направлений в области создания информационных систем. Существующие процессы и их недостатки, как следствие, привели к возникновению направления Agile и его последующей популярности. Рассматривать гибкие процессы в отрыве от тех предпосылок и последствий, которые послужили его распространению, было бы неправильно. Понимание корневых причин, на устранение которых направлена методология Agile, приведет к формированию адекватной комплексной точки зрения на эффективность процессов управления информационными технологиями.

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

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

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

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

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

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

Статистика проектов в разрезе процессных методологий за период с 2001 по 2010 г.

Рис. 3.1. Статистика проектов в разрезе процессных методологий за период с 2001 по 2010 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Александр Борисенко
Александр Борисенко

Мне кажется, или курс сыроват. При прочтении обнаруживается ощущения размытости, неточностей и прочего в том же роде. Например - "ЦФО - центр финансовых затрат" в пункте 2.4. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Дмитрий Марушко
Дмитрий Марушко
Беларусь, Минск
Александр Юрченко
Александр Юрченко
Россия, г. Москва