Дисциплинированная гибкая доставка - Disciplined agile delivery

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Основным справочником по дисциплинированной Agile-разработке является книга « Выбери свой WoW»! , написанный Скоттом Эмблером и Марком Лайнсом.

В частности, DAD был определен как средство выхода за рамки Scrum. По словам старшего консультанта Cutter Бхувана Унхелкара, «DAD предоставляет тщательно продуманный механизм, который не только оптимизирует работу ИТ, но, что более важно, позволяет масштабировать». Пол Горанс и Филипп Крухтен призывают к большей дисциплине в реализации гибких подходов и указывают, что DAD, в качестве примера структуры, представляет собой «гибридный гибкий подход к доставке корпоративных ИТ-решений, который обеспечивает прочную основу для масштабирования».

История

Скотт Эмблер и Марк Лайнс изначально руководили разработкой DAD. Эмблер и Лайнс продолжают возглавлять эволюцию DAD. DAD был разработан, чтобы обеспечить более целостный подход к гибкой разработке программного обеспечения; тот, который пытается заполнить пробелы в процессах, которые (намеренно) игнорируются Scrum, и тот, который способен масштабироваться на уровне предприятия. По словам Амблера, «многие гибкие методологии, в том числе Scrum, XP, AM, Agile Data, Kanban и другие, сосредоточены на подмножестве действий, необходимых для доставки решения от начала проекта до его доставки. До того, как была разработана DAD, вам нужно было создайте собственную гибкую методологию, чтобы выполнить свою работу ».

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

В 2015 году была разработана структура Discipeled Agile (DA), которая позже стала набором инструментов Discipeled Agile Toolkit. Это называлось дисциплинированной Agile 2.x. DAD лег в основу DA. Второй уровень, дисциплинированный DevOps, был добавлен, как и третий уровень под названием Disciplined Agile IT (DAIT). Эти уровни, соответственно, касались того, как решать DevOps и ИТ-процессы в условиях корпоративного класса.

В августе 2017 года был выпущен Disciplined Agile 3.x, в котором был представлен четвертый уровень, Disciplined Agile Enterprise (DAE), который охватывает весь спектр процессов, необходимых для гибкости бизнеса.

В декабре 2018 года был выпущен Disciplined Agile 4, теперь называемый Disciplined Agile Toolkit. В нем основное внимание уделялось полностью обновленному описанию DAD и командной стратегии улучшения, называемой управляемым непрерывным улучшением (GCI).

В августе 2019 года Disciplined Agile был приобретен Project Management Institute .

Ключевые аспекты

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

Люди прежде всего

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

Гибридный

DAD - это гибридный инструментарий, который адаптирует проверенные стратегии на основе существующих методов, таких как Scrum , экстремальное программирование (XP), SAFe , гибкое моделирование (AM), унифицированный процесс (UP), Kanban , внешняя разработка программного обеспечения , гибкие данные (AD ) и модель разработки Spotify . Вместо того, чтобы тратить время на адаптацию одной из этих существующих структур, с DAD все усилия по объединению соответствующих частей каждой техники уже сделаны.

Полный жизненный цикл доставки

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

Поддержка нескольких жизненных циклов

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

Полный

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

Контекстно-зависимый

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

Расходуемые решения вместо рабочего программного обеспечения

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

Самоорганизация с соответствующим управлением

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

Жизненные циклы

Изначально Disciplined поддерживала жизненный цикл проекта Agile (на основе Scrum) и жизненный цикл проекта Lean (на основе Kanban). С тех пор он был расширен для поддержки шести жизненных циклов:

  1. Agile . Трехэтапный жизненный цикл проекта на основе Scrum. Фазы - это начало (то, что иногда называют «спринтом 0»), строительство и переход (то, что иногда называют спринтом выпуска).
  2. Lean . Трехэтапный жизненный цикл проекта на основе Канбан.
  3. Непрерывная доставка: гибкая . Жизненный цикл продукта на основе Agile, который поддерживает непрерывный поток работы, приводящий к инкрементным выпускам (обычно один раз в неделю).
  4. Непрерывная доставка: бережливое производство . Жизненный цикл продукта на основе бережливого производства, который поддерживает непрерывный поток работы.
  5. Исследовательский . Жизненный цикл на основе экспериментов, основанный на бережливом запуске , который был расширен для решения параллельной разработки минимально жизнеспособных продуктов в соответствии с рекомендациями cynefin .
  6. Программа . Жизненный цикл для координации команды команд.

Цели процесса

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

Начальная фаза Этап строительства Переходная фаза
Направьте команду в правильном направлении. Постепенно создавайте расходные материалы. Запустите решение в производство.
  • Форма Команда
  • Согласоваться с корпоративным направлением
  • Разработка общего видения проекта
  • Изучить Сфера
  • Определить стратегию архитектуры
  • Планируйте выпуск
  • Разработка стратегии тестирования
  • Развивайте общее видение
  • Безопасное финансирование
  • Докажите архитектуру на ранней стадии
  • Обращение к меняющимся потребностям заинтересованных сторон
  • Производство потенциально расходуемого раствора
  • Улучшить качество
  • Ускорение доставки ценности
  • Обеспечение готовности производства
  • Разверните решение
Текущие цели

Совершенствуйтесь и работайте с учетом требований предприятия.

  • Увеличить количество членов команды
  • Координировать деятельность
  • Адресный риск
  • Развивать WoW
  • Используйте и улучшайте существующую инфраструктуру
  • Команда доставки управления

Роли

Основные роли

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

  • Заинтересованная сторона . Тот, на кого результат решения существенно повлияет. Это не просто конечный пользователь или заказчик, это любой человек, на которого может повлиять разработка и развертывание программного проекта.
  • Владелец продукта . Человек в команде, который выступает «единым голосом клиента», представляя потребности сообщества заинтересованных сторон перед командой Agile-доставки.
  • Член команды . Член команды сосредотачивается на создании реального решения для заинтересованных сторон, включая, помимо прочего: тестирование, анализ, архитектуру, дизайн, программирование, планирование и оценку. У них будет часть общих необходимых навыков, и они будут стремиться получить больше, чтобы стать специалистами по обобщению.
  • Руководитель группы . Руководитель группы - это ведущий руководитель, а также гибкий коуч, ответственный за содействие общению, предоставление им возможности выбирать свой способ работы и обеспечение команды необходимыми ресурсами и отсутствие препятствий.
  • Владелец архитектуры . Владеет архитектурными решениями для команды и способствует созданию и развитию общего дизайна решения.

Возможные второстепенные роли

Эти вспомогательные роли вводятся (иногда на временной основе) для решения проблем масштабирования.

  • Специалист . Хотя большинство гибких членов команды являются специалистами по обобщению, иногда требуются другие специалисты в зависимости от потребностей проекта.
  • Эксперт домена . Владелец продукта представляет широкий круг заинтересованных сторон, но для сложных областей, где требуется более тонкое понимание, иногда требуется эксперт по предметной области.
  • Технический эксперт . В случаях, когда возникает особенно сложная проблема, при необходимости может быть привлечен технический специалист. Это могут быть мастера сборки, администраторы гибких баз данных, разработчики пользовательского интерфейса (UX) или эксперты по безопасности.
  • Независимый тестировщик . Хотя большая часть тестирования выполняется членами группы DAD, в случаях со сложными областями или технологиями может быть задействована независимая группа тестирования для параллельной работы для проверки работы.
  • Интегратор . Для комплексных технических решений в масштабе можно использовать интегратор (или несколько интеграторов) для построения всей системы из ее различных подсистем.

использованная литература

дальнейшее чтение