# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ: - ПРОЦЕССЫ | Почерпнуть мудрость | Факторы успешного внедрения | ЖЦ разработки ПО (SDLC) | Подход Waterfall | Методология RUP | Подход Agile (и метод SCRUM) | Методология Kanban + Управление + Теория ограничений + Водопад, этапы ТЕСТИРОВАНИЕ
Процессы
latest update of the page: 03-02-2024, 19:07 UTC
Почерпнуть мудрость

Пример применения "дерева текущей реальности" ("дерева проблем") для анализа ситуации

Схема строится сверху вниз:
  • вверху перечисляем проблемы, которые нас беспокоят;
  • по каждому блоку с проблемой задаём вопрос "А почему так происходит?", ответ на этот вопрос располагаем ниже, отведя стрелку вверх к блоку с проблемой;
  • затем задаём вопрос уже к этим ответам, и так пока не дойдём до "корней".
Весьма жизненный пример:

RACI-матрица — распределение ответственности в процессах

Используется для того, например, чтобы в (обслуживающих) бизнес-процессах не было "забыто" кто чем занимается и за что отвечает.
  • Responsible – ответственный за непосредственное исполнение задачи;
  • Accountable (Approver) – отвечающий за корректность и полное выполнение задачи, подтверждает выполнение задачи;
  • Consulted – тот (те), с кем проводятся консультации относительно задачи, чьё мнение должно учитываться;
  • Informed – информируемый о выполнении задачи;
Пример:
Процесс processname IT-отдел Хостинг
-провайдер
Бизнес Бухгалтерия Сервис
-менеджер
Разработчики
Разработка требований R C C A I
Дизайн A CI I R C
Разработка A I I I C R
Внедрение A R C I C C
Сопровождение A R I I C
Подробнее:
Факторы успешного внедрения

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

  1. Наличие "политической крыши" в организации = заинтересованных в проекте лиц с реальными рычагами управления и прямого влияния на причастные стороны, с возможностью выделения ресурсов. Если кто сталкивался с т.н. внутрикорпоративными войнами — объяснять не надо.
  2. Понятийный аппарат продукта (его объектной модели, архитектуры и спецификаций) должен пересекаться, а лучше — совпадатьс предметной областью, для которой предназначено решение. ИТ-специалист и бизнес-заказчик должны понимать друг-друга, "говорить" на одном языке об одних и тех же сущностях.
    См. концепцию DDD
  3. У Продукта должна быть команда (не путать с подчинёнными), а не один-единственный идейный вдохновитель и разработчик (как бывает в небольших организациях).
    Причины:
    • bus factor
    • водиночку очень трудно и времязатратно переключаться с вопросов предметной области на область ИТ-решения. Может привести к выгоранию и забросу проекта.
    • одиночка обладает довольно "узким каналом" генерации идей по сравнению с коллективом.
    • Для Бизнеса связываться с одиночками (покупать у такого Продукт) это всегда высокий риск.
  4. У ИТ-решения для Продука должна быть масштабируемая и НЕ переусложнённая архитектура. Звучит банально, однако в реальности мы встречаем очень всякое и даже разное...
  5. Заказчик (юрлицо/физлицо) и отдельные ЛПР (лица, принимающие решения) склонны следовать (или имитировать следование) карго-культу.
    Если вы разрабатываете системообразующий Сервис/Продукт для крупного бизнеса, то использование популярных и хорошо зарекомендовавших (надёжность) себя платформ/технологий ("передовые компании X, Y, Z используют технологию A!") будет вызывать больше доверия к проекту со стороны Клиента/Пользователя/Заказчика.
    Серьёзно влияет на вероятность выделения ресурсов под ваш проект.
  6. Уникальные фичи Продукта.
    То, чего нет ни у кого. Либо есть, но стоит дорого. Либо есть, но работает не так как нужно (медленно, с ошибками, нестабильно, потребляет много ресурсов, бесит пользователей).
  7. Сложность и/или стоимость лицензирования используемых платформ/технологии. Например, решения от IBM, Oracle, SAP и т.п. это дорого (хотя их support может того стоить). Сейчас все смотрят в сторону opensource-решений.

ЖЦ разработки ПО (SDLC)
Использованные ресурсы, что почитать на тему: Сокращения:
  • ЖЦ = Жизненный цикл.
  • SDLC = Software development lifecycle. Жизненный цикл разработки программного обеспечения.
  • ИС = информационная система, ИТ-система.

Для IT-продуктов мы можем построить расширенную V-диаграмму:

На V-диаграмме видно сколько всего работ должно быть выполнено до старта нашего проекта.
  • Слева — проектирование.
  • Справа — действия по окончательной валидации нашего предмета поставки.
Если мы работаем по Agile, то фактически все эти этапы выполняются в рамках работ по каждой пользовательской истории (user story) . Если у нас более длинные итерации, то по этим фазам проходит сразу целая очередь или подсистема.
Соответственно, результаты предшествующего проектирования должны поступить нам на вход (причем, не всегда "самотёком"), а действия по валидации будут вызывать запросы на изменения, поддержку или дефекты, выявленные после поставки.

Более подробная развёртка по времени ЖЦ производства ИС в общем виде:

скачать схему в формате diagrams.net (бывший draw.io)

Этап реализации программного продукта (Процесс 10 из схемы выше) в общем виде выглядит так:

Подход Waterfall

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

Выбирают Waterfall, если заказчик:

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

Сравнение Waterfall ("Водопад") и Agile ("Гибкие методологии")
Чуть подробнее о:
Методология RUP

RUP (Rational Unified Process) = методология разработки программного обеспечения, идейно развившая "водопадную" модель до т.н. "каскадной".
Была целенаправленно разработана для создания больших программных систем. Автор — компания Rational Software.

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

Этап "Начальная стадия" (Inception). Итерация 1
Посвящена сбору требований будущих пользователей к системе. Пользователи рассказывают каждый свой кусочек работы (сценарий использования системы пользователем), а Аналитик из отдельных операций и процедур пытается собрать целый рабочий процесс.
Цель этой итерации выйти на бизнес-сценарий использования системы / будущий бизнес-процесс на основе ИС. Их может быть больше чем один, поэтому не стоит замыкаться на том чтобы был обязательно один.
Компания-Заказчик — это Банк. Он решает, что хочет начать предоставлять своим клиентам услугу по удаленной выдаче наличных при помощи банкоматов, установленных в офисах клиентов и на станциях метро.

Для оказания данной услуги, нужно разработать и доработать имеющееся у банка программное обеспечение. В ходе сбора требований и их анализа было выделено три крупных процедуры в бизнес-сценарии услуги:
  1. Загрузка наличных в банкомат Сотрудниками банка.
  2. Выдача наличных Клиенту по его запросу со счёта в банке.
  3. Учет количества загруженных и выданных купюр.
В этой итерации ещё нет работ связанных с проектированием архитектуры будущей системы, разработки программы, тестирования и доставки. RUP не ставит условий, что они обязательно нужны, но по своему усмотрению вы можете их выполнить.
Этап "Начальная стадия" (Inception). Итерация 2
После того как бизнес сценарии определены, собранные требования раскладываются по шагам бизнес-сценария и системным сценариям. На этом этапе также выявляются те шаги бизнес-сценариев, что были не выявлены в первой итерации.
В ходе второй итерации были выявлены две дополнительные процедуры к основному бизнес-сценарию:
  1. Мониторинг и нотификация, направляемая банкоматом в банк, об окончании в нём наличных.
  2. Мониторинг и нотификация о работоспособности банкомата или наличия на нем проблем/ошибок в работе.
Для обеспечения доступности услуги выдачи наличных в режиме 24/7.
Результатом этой итерации становятся:
  1. На 90% законченные бизнес-сценарии.
  2. Намеченные, но не детализированные системные сценарии использования по каждому бизнес-сценарию.
  3. Собранные требования структурированы по бизнес и системным сценариям.
Этап "Уточнение" (Elaboration). Итерация 3

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

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

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

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

Этап "Уточнение" (Elaboration). Итерация 4

Стартует параллельно третьей итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.

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

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

Результатом этой итерации станут:

  1. Архитектурные решения для каждого бизнес-сценария.
  2. Согласованный проект общей архитектуры системы 1.0
  3. Вторая версия прототипа с готовыми первыми шагами вторичных бизнес-сценариев в дополнение к первым шагам ключевого бизнес-сценария.

Этап "Конструирование" (Construction). Итерация 5

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

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

Результатом итерации становятся:

  1. Полностью реализованный ключевой бизнес сценарий.
  2. Согласованный проект общей архитектуры системы 2.0
  3. Третья версия системы, реализующая ключевой бизнес-сценарий и первые шаги для вторичных бизнес-сценариев.

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

Этап "Конструирование" (Construction). Итерация 6

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

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

Результатом итерации становятся:

  1. Полностью реализованные вторичные бизнес сценарии.
  2. Финальный проект общей архитектуры системы 3.0
  3. Четвертая версия системы, реализующая все бизнес-сценарии.

Начинается полноценная опытная эксплуатация системы бизнес-пользователями и примерка её под промышленное использование.

Этап "Внедрение" (Transition). Итерация 7

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

Этап "Внедрение" (Transition). Итерация 8

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

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

Основная идея RUP — выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев.
Так как доставка части Результата проекта (инкремента) осуществляется в конце каждой итерации, это позволяет начать получать выгоду от использования промежуточных версий Результата и возвращать вложения в проект ещё в ходе его реализации.

Новации RUP

  1. Бизнес-моделирование и связанные с ним Сценарии Использования (Use Case).
    Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою "чёрный ящик", который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
  2. На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
  3. Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.
Упрощённый концепт RUP:

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

Подход Agile (и метод SCRUM)

Гибкая методология разработки (Agile software development) = серия подходов к разработке ПО, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

Гибкий итеративный подход Agile не включает практик, он определяет ценности и принципы, базируясь на т.н. "agile-манифесте":

  • Люди и взаимодействие важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану
Подход нацелен на минимизацию рисков путём сведения разработки к серии коротких циклов (итераций), которые обычно длятся 2-3 недели.
Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации.
Подразумевается возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации. В итеративном подходе предполагается очень плотное участие заказчика в процессе, он буквально должен жить с командой разработки, а в случае срыва сроков делить с ней риски.

Вот схематическое изображение ЖЦ одного из самых распространённых методов гибкой работы, SCRUM:
scrum

Выбирают Agile, если:

  • заказчик готов отдать 80%-100% своего времени проекту с полным погружением;
  • заказчик обладает достаточной компетенцией и готов погружаться в разработку вместе с технарями;
  • заказчик готов разделить риски за срыв сроков или за невысокое качество работы подрядчика;
  • заказчик, как и разработчик, отлично понимают, что на данный момент нормально требования не собрать, потому что они еще не продуманы до конца, а работать начинать надо, потому что рынок, бизнес, и всё такое.
  • разработчиками являются высококлассные специалисты, за плечами у которых десятки больших реализованных проектов, которые способны в голове за 20 минут набросать диаграмму классов небольшого модуля, тут же прикинуть процессы меняющие их состояния, предположить критические зависимости и т.д. В этом случае можно попытаться обходиться без чётких требований и стадии анализа как таковой

Типичные ошибки при адаптации Scrum

  • Проектного менеджера хоть и окрестили Владельцем Продукта, однако он не получил необходимых полномочий и поэтому не вправе формировать видение продукта или менять приоритеты реализации.
    Как и раньше, он вынужден согласовывать каждый свой шаг с руководством, зажат в рамки требований по срокам и объёму работ.
    А значит, скорость принятия решений осталась прежней. Никакого ускорения или адаптации под меняющиеся условия.
  • Проектную команду хоть и назвали Scrum-командой, но люди, включённые в неё, по-прежнему могут числиться каждый в своём отделе и подчиняются непосредственно своим линейным руководителям.
    Соответственно, каждый из участников команды прежде всего делает то, что ему поручит его линейный руководитель, а не Владелец Продукта. Как следствие, задачи по продукту будут всегда ниже по приоритету, а значит, скорость реализации продукта, под который "собрали" Scrum-команду, никак не повысится.
  • Скорее всего, как и прежде, участники команды будут заняты и в других проектах.
    В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта.
    Если люди "поделены на проценты" между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлечённость, так и эффективность работы над каждым конкретным Проектом/Продуктом.

Сравнение Waterfall и Agile

Методология Kanban

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

Основы современного Канбан:

  1. Визуализировать поток поставки
  2. Ограничивать WIP-лимиты
  3. Измерять время выполнения задачи (Lead Time). Минимизировать его.
  4. Сделать правила работы явными и известными для всех участников процесса
  5. Помогать друг другу
  6. Собирать статистику по времени выполнения (Lead Time) разного типа задач для прогнозирования последующих поставок

WIP-лимиты (Work In Progress, WIP) = лимит на количество единовременно находящихся в производстве рабочих элементов. Ограничение незавершённой работы.

Критерии готовности (Definition of Done, DoD) = чёткие и понятные всем критерии, по которым рабочий элемент может считаться готовым после отработки.

Время производства (Lead Time, LT) = время выполнения задачи с момента принятия обязательств до момента поставки.

Обязательство (Commitment) = чётко сформулированное негласное соглашение между заказчиком и сервисом о следующем:

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

Канбан-Доска (Board)

Каденции (встречи, митинги)

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

Роли в Канбане

Менеджер Запросов для Сервиса (Service Request Manager, SRM) несёт ответственность за изучение потребностей и ожидания заказчиков, содействие выбору и приоритизации рабочих элементов на Собраниях по Пополнению.
Другие названия для данной роли: Менеджер Продукта, Владелец Продукта, Менеджер Сервиса.

Менеджер Поставки для Сервиса (Service Delivery Manager, SDM) несёт ответственность за поток работы, в ходе которого выбранных рабочие элементы поставляются заказчикам, за обеспечение проведения Канбан-Митингов и Собрание Планирования Поставки.
Другие названия роли: Менеджер Потока, Менеджер Поставок и даже Мастер Потока.

Стоимость задержки (Cost of Delay)

  1. Expedite --> несём потери уже сейчас.
    Делать поставку надо срочно.
  2. Fixed date --> начнём нести потери с определённой даты.
    Начинать разработку надо достаточно рано, чтобы обеспечить своевременную поставку.
  3. Regular / Standard --> стоимость задержки возрастает постепенно.
    Необходимо обеспечить разумные сроки ожидания поставки.
  4. Intangible --> стоимость задержки может оказаться значительной, но в отдалённой перспективе.
    Важно, но не срочно. Планировать поставку когда удобно.

Накопительная диаграмма потока (CFD)