"Научный аспект №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, то у любого продукта есть свой владелец продукта, который:
Команда разработки — это ответственные люди, которые могут самостоятельно и независимо разрабатывать продукт. В команде должны быть все компетенции, которые необходимы для достижения результата. Внешними зависимостями лучше не управлять, от них нужно избавляться включением или обучением нужных людей в команде.
В продуктово-ориентированной организации назначается ответственность за создание ценности для потребителей – по горизонтали, по всем бизнес-функциям.
Сегодня способность организации к быстрым изменениям имеет огромное значение.
Еще одно ограничение, которое признано на уровне социальной закономерности, что при проектировании информационных систем сложность заключается в том, что структура созданной системы отражает структуру связей в организации. Структура программного интерфейса системы будет отражать социальные границы организации, которые её создали, по которой сложнее общение между людьми.
Кросс-функциональные и кросс-компонентные команды позволяют обойти такое ограничение.
Для того чтобы справится с масштабированием роста компании важно использовать практики межкомандного взаимодействия. Одна из наиболее эффективных практик – это коммуникации через программный код. Она работает, когда в компании внедряются широкие практики автоматизации поставки и проверки качества программного обеспечения. Релизы становятся по требованию.
Один из главных моментов для перехода к эффективного взаимодействию между бизнес-департаментом, разработчики и специалистами поддержки – это использование эффективной аналитики на всех уровнях. Начиная от веб-аналитики поведения пользования, заканчивая событийной аналитикой всех технических систем в реальном времени и с агрегированными данными.
Переход к микро сервисной архитектуре программного обеспечения и разработке с использованием техник уменьшения кодовой базы при разработке приводят к кардинальному снижению издержек на вносимые изменения.
Сегодняшний мир несёт в себе много новых вызовов. Двигаясь эволюционно, от поиска узких мест к оптимизации процессов, можно прийти к фундаментальным изменениям, связанным с изменением организационного дизайна компании, ландшафта ИТ-архитектуры, внедрения инкрементального подхода к созданию и управлению целями организации. Только подобные серьёзные качественные и количественные изменения могут дать скачок в повышение эффективности организации, справится с социальными и технологиями ограничениями в управлении бизнесом.
Список литературы