gototopgototop

"Научный аспект №2-2019" - Технические науки

Комплексные системы как причина перехода к гибкой разработке

Шумаков Андрей Андреевич – старший преподаватель Финансового университета при правительстве РФ.

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

Ключевые слова: Управление проектами, методы, модель Кеневин, Cenefin framework, Complexity theory, scrum, agile, гибкие практики.

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

Модель Кеневин

Модель Кеневин была сформулирована в 2003 году экспертом компании IBM Дейвом Сноуденом[10]. Согласно модели Кеневин, принятие решения и методика выработки этого решения должна зависеть от состояния системы, в которой это решение принимается. Система — это множество элементов, находящихся в отношениях и связях друг с другом, которые образуют определенную целостность и единство.

Сноуден подразделяет все системы на 4 категории: простые системы — характеризуются очевидностью своей структуры и действующих взаимосвязей. В простых системах причинно-следственные связи очевидны любому агенту системы, они просты, предсказуемы, повторяемы и понятны. Управление процессами в таких системах требует необходимости придерживаться согласованного порядка действий. [8]

Комплексные системы — отличаются наличием причинно-следственных связей, но уже не таких очевидных как в простых системах. Это домен, в котором правят эксперты. Определение причинно-следственных связей в упорядоченных системах требует уже специальных экспертных знаний и практического опыта, при наличии которых эти связи удается обнаружить и описать. В упорядоченных системах уже нет единственной наилучшей практики, но есть хорошие практики. [9]

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

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

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

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

Целеполагание

Чтобы достигнуть целей компании нужно правильно выбирать целеполагание. Важно начать с целей всей организации. Затем перейти к целям по выбранному направлению. После выбора целей по направлению нужно понять как их оптимальным образом достигать. Лучшим выбором будет продуктовый подход к достижению результата. Для этого надо определиться, что такое продукт и какую ценность он несёт клиенту. Составить финансовую модель продукта с прозрачными метриками успеха. Если будет продукт, то можно сформировать измеримые и достижимые цели продукта. Чтобы достигнуть целей продукта большинство компаний используют инкрементальный подход. Инкремент, как прирост функционала продукта, достигается через итерации одинаковой длины. У каждой итерации есть своя цель. Нужно помнить, что любая цель должна быть конкретной, измеримой, достижимой, значимой и со сроками.

Гибкая разработка

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

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

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

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

Фреймворк Scrum [2,3] определяет основу для гибкой разработки программного обеспечения. Скрам команда включает в себя три роли: многофункциональную команду разработчиков, владельца продукта и Scrum-мастера. Команда разработчиков отвечает за все технические аспекты и развитие, владелец продукта направляет проект к бизнес-целям через сортировку требований, и scrum-мастер заботится об адаптации процесса и помогает взаимодействию людей в команде. Разработка продолжается длительное время в виде серии итераций (спринтов) и члены команды координируют свою работу на событиях, которые повторяются каждый спринт и ежедневно. В основе Scrum лежит управление развитием людей, структурой команд и событиями, а не процессом разработки или артефактами проекта.

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

Если мы будем рассматривать Фреймворк гибкой разработки Scrum, то у любого продукта есть свой владелец продукта, который:

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

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

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

Сегодня способность организации к быстрым изменениям имеет огромное значение.

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

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

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

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

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

Заключение

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

Список литературы

  1. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D.: Manifesto for agile software development (2001).
  2. Schwaber, K., Beedle, M.: Agile Software Development with Scrum. Agile Software Development. Prentice Hall (2002).
  3. Schwaber, K., Sutherland, J.: The Scrum guide. http://scrumguides.org/ (July 2013).
  4. Williams, L.: What agile teams think of agile principles. Commun. ACM 55(4) (April 2012) 71–76.
  5. Williams, L., Brown, G., Meltzer, A., Nagappan, N.: Scrum + engineering practices: Experiences of three Microsoft teams. In: Empirical Software Engineering and Measurement (ESEM), 2011 International Symposium on. (2011) 463–471.
  6. Highsmith, J., Cockburn, A.: Agile software development: the business of innovation. Computer 34(9) (Sep 2001) 120–127.
  7. Cockburn, A., Highsmith, J.: Agile software development, the people factor. Computer 34(11) (Nov 2001) 131–133.
  8. The Harvard Business Review Leader's Handbook, A Leader’s Framework for Decision Making, november 2007.
  9. Кривоногов С. О. Определение метода управления проектами на основе модели Кеневин // Молодой ученый. — 2017. — №50. — С. 167-169. — URL https://moluch.ru/archive/184/47240/ (дата обращения: 21.05.2019).
  10. The New Dynamics of Strategy: Sense-Making in a Complex and Complicated World / Cynthia Kurtz and David Snowden. IBM Systems Journal. 42 (3) // 2003. pp. 462–483.
Интересная статья? Поделись ей с другими:

Внимание, откроется в новом окне. PDFПечатьE-mail

Отправить статью

...

Форма оплаты

Номер статьи, присвоенный редакцией
Количество страниц в статье
Количество экземпляров журнала
Доставка: РФСНГ
Скидка (%)
Заказать свидетельство о публикации
1. Стоимость публикации каждой страницы статьи составляет 200 рублей.
2. Стоимость каждого экземпляра журнала, включая его изготовление и доставку, составляет 300 рублей для России и 600 рублей для стран СНГ.
3. Стоимость печатного свидетельства о публикации составляет 100 рублей

Реквизиты для оплаты через банк