Содержание курса

2.  Этап 2. Имплементация проектного решения.

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

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

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

  • Обеспечить качество кода.

  • Обеспечить интеграцию компонентов.

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

  • Вносить изменения в требования к ПО, по результатам промежуточных версий.

  • Анализировать процесс разработки и при необходимости вносить в него корректировку.

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

PDCA (Plan-Do-Check-Act) - или цикл Деминга / Шухарта. Это фундаментальный подход к непрерывному улучшению процессов. В разработке ИТ-продуктов (особенно в гибких методологиях, DevOps и прочих) он очень четко прослеживается.

1)  PLAN (Планируй). Это этап превращения требований в конкретный (тактический) план работ. Здесь закладывается основа качества.

  • Отбор задач из бэклога для реализации в итерации.

  • Декомпозиция задач на: эпики → фичи → задачи; технические подзадачи; задачи по инфраструктуре и качеству.

  • Оценка трудозатрат (сторипоинты, часы).

  • Определение критериев приемки (Definition of Done) - список того, что должно быть сделано, чтобы задача считалась завершенной.

2)  DO (Делай / Реализуй / Выполняй). Это непосредственная имплементация того, что запланировали.

  • Написание кода (разработка функционала).

  • Написание юнит-тестов (модульное тестирование).

  • Настройка окружения (контейнеры, БД).

  • Самостоятельная проверка разработчиком (дымовое тестирование).

3) CHECK (Проверяй / Контролируй). Это этап оценки результата. Соответствует ли то, что мы сделали, тому, что мы планировали и работает ли это так, как нужно.

  • Code Review. Проверка кода коллегами.

  • Тестирование (QA). Функциональное, регрессионное, интеграционное, нагрузочное тестирование.

  • Сбор метрик. Прогон автотестов (CI/CD), проверка покрытия кода.

  • Демо заказчику. Показ результата, чтобы убедиться, что сделали именно то, что хотели (иногда выделяют в отдельный этап, но по сути это проверка гипотезы).

4)  ACT (Воздействуй / Корректируй / Действуй). На основе проверки принимается решение: либо внедрять результат (если все хорошо), либо дорабатывать (если есть ошибки).

  • Управление выходом (Release Management). Выкатка релиза в продуктив (production).

  • Стабилизация.

  • Анализ ошибок. Как продукта, так и процесса.

  • Обновление бэклога. Создание задач на исправление (баг-фикс) или задач по снижению технического долга.

  • Стандартизация. Если была найдена хорошая практика, она добавляется в стандарты команды (DoD, DoR, чек-листы код-ревью).

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

2.1. Организация работ стадии Разработки в методологии RUP

В предыдущей части, мы уже обсуждали методологию Rational Unified Process (RUP), использующую итеративный подход.

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

Наряду с тем, хотя Реализация идет в каждой итерации, ее фокус меняется в зависимости от того, в какой фазе проекта находится команда:

  • Начало (Inception): Реализация минимальна. Может создаваться "доказательство концепции" (технологический прототип), чтобы проверить осуществимость идеи и оценить риски.

  • Уточнение (Elaboration): Реализация направлена на создание исполняемого архитектурного каркаса. Команда кодирует "скелет" системы, реализуя самые сложные и рискованные сценарии. На этом этапе проверяется, что выбранная архитектура работает и выдерживает нагрузки.

  • Построение (Construction): Это фаза наиболее интенсивной реализации. Здесь, итерация за итерацией, на уже готовый архитектурный каркас нанизывает основную функциональность продукта.

  • Внедрение (Transition): Реализация фокусируется на исправлении ошибок, найденных в ходе бета-тестирования и доработке, необходимой для развертывания.

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

О том, как формализуются Прецеденты детально можно ознакомиться к курсе “Проектирование Информационных систем. Часть 5. Формализация потребностей заказчика”.

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

Например, Разработчик пишет код интерфейсов (контроллеры в MVC, boundary-классы в RUP), которые обрабатывают запросы от Акторов (пользователей), и код сущностей (entity classes), которые хранят состояние. При этом Прецедент становится основой для модульных тестов (Unit Tests). Тесты пишутся так, чтобы покрыть основной и все альтернативные потоки конкретного Прецедента.

Для тестировщиков подобный подход вообще является “золотой жилой”. Ведь Прецедент по существу представляет собой готовый тест-кейс. Управление Прецедентами становится эффективным инструментом и для других ролей в RUP.

Роль в RUP - это определение обязанностей и набора навыков для члена команды или группы. Один человек может исполнять несколько ролей, и одну роль могут исполнять несколько человек. RUP четко разделяет понятия роли: исполнителя (конкретного человека) и вида деятельности.

Ниже приведены ключевые роли в (RUP) и их основные характеристики:

  1. Архитектор системы (System Architect). Отвечает за определение архитектуры системы. Проектирует ключевые элементы системы, интерфейсы и взаимодействия.

  2. Бизнес-аналитик (Business Analyst). Отвечает за выявление бизнес-требований и целей заказчика. Анализирует бизнес-процессы заказчика, определяя, как технологии могут их улучшить.

  3. Разработчик (Implementer). Отвечает за написание кода, в соответствии с архитектурой и дизайном системы. Реализует функциональность на основе спецификаций требований. В профстандарте эта роль может быть представлена как: “Программист. Код_06.001”, “Разработчик Web и мультимедийных приложений. Код_06.035”, “Системный программист. Код_06.028”, “Специалист по информационным системам. Код_06.015”,

  4. Тестировщик (Tester). Осуществляет тестирование системы на соответствие требованиям и отсутствие ошибок. Создает тестовые сценарии и выполняет их, обеспечивая качество продукта. В профстандарте представлен как: “Специалист по тестированию в области информационных технологий. Код_06.004”,

  5. Менеджер проекта (Project Manager). Ответственен за планирование, мониторинг и контроль выполнения проекта. Координирует деятельность команды и управляет рисками.

  6. Архитектор базы данных (Database Architect). Проектирует структуру базы данных и обеспечивает ее производительность и надежность. Работает в тесном взаимодействии с разработчиками и архитектором системы. В профстандарте ближе всего: “Специалист по большим данным. Код_06.042” и “Администратор базы данных. Код_06.011”.

  7. Проектировщик пользовательских интерфейсов (UI Designer). Отвечает за проектирование интерфейсов системы, обеспечивая удобство и интуитивность использования. В профстандарте представлен как: “Специалист по дизайну графических пользовательских интерфейсов. Код_06.025”,

  8. Интегратор (Integrator). Собирает все компоненты системы в единое целое.
    Ответственен за управление версиями и сборку продукта. В профстандарте представлен как: “Специалист по интеграции прикладных решений. Код_06.041”.

  9. Конфигурационный менеджер (Configuration Manager). Отслеживает и контролирует изменения в проекте. Управляет версиями и артефактами проекта. В профстандарте ближе всего: “Менеджер по информационным технологиям. Код_06.014”.

  10. Специалист поддержки (Support). Помогает команде в решении технических проблем. Обеспечивает функционирование инструментов и средств разработки. В профстандарте представлен как: “Специалист по технической поддержке информационно-коммуникационных систем. Код_06.024”,

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

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

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

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

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

2.2.  Организация работ стадии Разработки в гибких методологиях

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

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

Также итеративный подход в гибком фреймворке Scrum оперирует понятием Пользовательская история или Stories (User Story), которая представляет собой минимальную единицу требований в Agile и зачастую детализирует Фичу.

Если история не помещается в один спринт или слишком крупная, ее называют Эпиком (Epic). Эпик - это большая пользовательская история, которая потом дробится на несколько мелких Фич или Сториз, используемых в качестве элементов контекста работ в Бэклог продукта (Product backlog). Бэклог продукта - приоритизированный, постоянно обновляемый список функциональности, который описывает общее предназначение (или развитие) ИТ-продукта.

Со способами подготовки этих артефактов детально можно ознакомиться к курсе “Проектирование Информационных систем. Часть 5. Формализация потребностей заказчика”.

Для реализации в коде, каждая Сториз разбивается на технические Задачи. Задача (Task) - это минимальная управляемая единица работы в проекте, описывающая активности команды разработки, необходимые для воплощения функциональности в целевом продукте. Например, разработка API; изменение модели данных; интеграция с внешним сервисом; написание тестов.

Таким образом выстраивается технологическая конструкция, преобразующая Требования в функциональность ИС: Epic → Feature → Stories → Tasks → Код.

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

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

Спринт (Sprint) - фиксированный по времени итерационный цикл разработки (в Scrum), в течение которого команда создает рабочий инкремент продукта.

Ключевые принципы Спринта (которыми не стоит пренебрегать):

1)  Фиксированная длительность. Спринт всегда строго определен по времени. Если выбрали двухнедельные спринты, они всегда заканчиваются через две недели, независимо от того, успели выполнить все или нет.

2)  Неизменность цели. Внутри спринта нельзя менять его цель (Sprint Goal). Если стало ясно, что работа бесполезна, спринт можно прервать досрочно, но нельзя просто добавить новые задачи в середине.

3)  Работающий результат. В конце спринта команда обязана показать работающий продукт, а не отчет о прогрессе.

Спринт по факту также является управляемым циклом улучшения, поэтому ему присущи все характеристики рассмотренного выше подхода PDCA:

1)  Планирование Спринта (Sprint Planning). Команда и Менеджер ,продукта договариваются, что будет сделано в течении итерации. Они берут Сториз из Бэклога продукта и формируют Бэклог спринта. По полученному списку функционала, который команда обязуется реализовать за Спринт, формируются конкретные задачи (Tasks) исполнителям, реализация которых и приведет к приросту запланированной функциональности.

2)  Разработка. Сама работа. Каждый день команда проводит короткий Daily Scrum (Ежедневное совещание) на 15 минут, чтобы синхронизироваться и ответить на три вопроса: "Что сделал вчера?", "Что буду делать сегодня?", "Какие есть препятствия?".

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

4)  Ретроспектива Спринта (Sprint Retrospective). Встреча команды для внутреннего пользования. Анализируется процесс: что пошло хорошо, что плохо, что будем улучшать в следующем спринте.

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

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

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

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

Характерной чертой гибких подходов (Agile) является использование досок задач (Kanban board, Scrum board, Task board). Это один из самых наглядных и практичных инструментов. Доска визуализирует поток работ и делает процесс прозрачным для всей команды. Обычно это физическая доска со стикерами или цифровая, разделенная на колонки. Каждая колонка представляет собой этап жизненного цикла задачи, обозначающего ее статус (например, “Нужно сделать”, “В работе”, “На проверке”, “Готово”). Карточки (стикеры/тикеты), которые передвигают по колонкам, представляют собой работу (User Story, Task, Bug).

Так же иногда используется элемент - лимит WIP (Work in Progress), устанавливающий ограничения на количество задач, которые могут одновременно находиться в одной колонке (чаще используется в Канбан).

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

2.3. Управление коллективной разработкой

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

В методологии RUP эта область называется “Управление конфигурациями и изменениями (Configuration & Change Management)”. В современном мире DevOps это звучит как Platform Engineering или InnerSource.

В данном контексте обычно рассматривают две плоскости:

  • Информационные активы: исходный код; проектная документация; требования; модели данных; тесты; конфигурации; сборки и релизы.

  • Единое пространство: централизованное хранение; управляемый доступ; контроль версий; прозрачная история изменений.

Архитектурный и процессный подход к решению подобных задач, объединяющий лучшие практики RUP и современные реалии можно кратко выразить в следующих направлениях:

1)  Единое пространство информационных активов (Single Source of Truth)

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

А. Репозиторий исходного кода (SCM — Software Configuration Management). Централизованное или распределенное хранилище, в котором хранится весь исходный код проекта, а также полная история его изменений. Это фундамент, игнорирование которым неизбежно ведет к хаосу.

  • Инструмент: Git (стандарт индустрии).

  • Платформа: GitLab / GitHub / Bitbucket (они дают не только гит, но и веб-интерфейс, CI/CD, Wiki).

  • Политика: Ветвление (Branching Strategy). Например, Git Flow (для сложных продуктов с релизами); Trunk-Based Development (для непрерывной поставки).

Б. Управление требованиями и задачами (Work Items). Код сам по себе - это просто текст. необходимо связать его с теми артефактами, для реализации которых он написан.

В. Документация (Living Documentation). В современном мире документирование стараются автоматизировать и результаты хранить рядом с кодом.

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

А. Управление качеством входа (Code Reviews). Ни один код не должен попасть в основную ветку без проверки коллегой (или роботом).

Б. Фабрика сборки - CI/CD (Continuous Integration & Continuous Delivery). Автоматизация проверки и доставки - это квинтэссенция синхронной работы, к тому же обеспечивающая непрерывную интеграцию. Все наработки должны постоянно сливаться воедино и проверяться.

В. Переключатели функций (Feature Toggles). Позволяют хранить незаконченный код в основной ветке, не ломая продукт для пользователей.

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

А. Разделение на подсистемы и команды (Architectural Boundaries).  Один из ключевых принципов масштабирования разработки, который позволяет множеству команд эффективно работать над одним продуктом, не мешая друг другу. Этот подход также известен как "разделение по границам контекста" (Bounded Context) в Domain-Driven Design (DDD) или микросервисная архитектура.

Б. Владельцы кода (Code Owners). Механизм защиты и управления качеством кода, который позволяет автоматически назначать ответственных за определенные части кода. Обеспечивает комфортное и эффективное масштабирование разработки.

В. Единый стандарт кодирования. Стандартизация и регламентирование работы с кодом, автоматизация проверки (linting, formatting), использование паттернов проектирования и прочие меры, обеспечивающие преемственность кода и прозрачность решений.

3. Этап 3. Передача (согласование) финального релиза заказчику.

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

В методологиях (RUP, Agile и прочих) этот этап называется по-разному, но суть одна: заказчик, совместно со специалистами исполнителя, производит оценку полученного результата и подтверждает то, что результат соответствует ожиданиям и готов к использованию (или не готов).

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

Почему так важно провести согласование финального релиза до фазы Внедрения?

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

В подавляющем большинстве договоров на разработку ИС (особенно в модели Fixed Price) моментом сдачи работ является подписание Акта сдачи-приемки (или Acceptance Certificate) в конце стадии Разработки. Этот факт становится основанием для оплаты уже выполненных работ и юридической фиксации обязательств сторон.

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

Стадия Внедрения - это всегда стресс для инфраструктуры заказчика и для его сотрудников. Там могут возникать свои особенности, уязвимости, “костыли” и дополнительные неучтенные активности. Команда будет вынуждена разрываться между доработками и оказанием помощи во внедрении. Это все с высокой долей вероятности может привести к смене настроения и лояльности заказчика. Но об этом всем мы подробнее поговорим в следующей части курса.

4. Итоги стадии Разработки  

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

Критерии успешного прохождения стадии Разработки:

  1. Готовность продукта. Система полностью реализует все запланированные функции (прецеденты).

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

  3. Готовность документации. В основном завершена подготовка пользовательской документации.

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