# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы 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: 01-03-2023, 21:31 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. Наличие "политической крыши" в организации = заинтересованных в проекте лиц с реальными рычагами управления и давления на причастные стороны, с возможностью выделения ресурсов (cм. внутрикорпоративные войны)
  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)