Дисциплинированная гибкая доставка
 | Эта статья может чрезмерно полагаться на источники, слишком тесно связанные с предметом , что потенциально препятствует тому, чтобы статья была проверяемой и нейтральной . ( Ноябрь 2019 г. ) |
| Часть серии о |
| Разработка программного обеспечения |
|---|
Дисциплинированная гибкая доставка ( DAD ) — это часть набора инструментов Disciplined Agile Toolkit, относящаяся к разработке программного обеспечения. DAD позволяет командам принимать упрощенные технологические решения по поэтапной и итеративной доставке решений. DAD опирается на многие практики, поддерживаемые сторонниками гибкой разработки программного обеспечения , включая Scrum , гибкое моделирование , бережливую разработку программного обеспечения и другие.
Основным справочником по дисциплинированной гибкой реализации является книга « Выбери свой WoW!». , [1] сценарий Скотта Эмблера и Марка Лайнса. WoW означает «способ работы» или «способы работы». [2]
В частности, DAD рассматривается как средство выхода за пределы схватки. [3] По словам старшего консультанта Cutter Бхувана Унхелкара, «DAD предоставляет тщательно продуманный механизм, который не только оптимизирует ИТ-работу, но, что более важно, обеспечивает масштабирование». [4] Пол Горанс и Филипп Крухтен призывают к большей дисциплине при внедрении гибких подходов и указывают, что DAD, в качестве примера, представляет собой «гибридный гибкий подход к доставке корпоративных ИТ-решений, который обеспечивает прочную основу для масштабирования». [5]
История [ править ]
Скотт Эмблер и Марк Лайнс изначально руководили разработкой DAD и продолжают возглавлять ее развитие. DAD был разработан для обеспечения более целостного подхода к гибкой разработке программного обеспечения; тот, который пытается заполнить пробелы в процессах, которые (намеренно) игнорируются Scrum, и тот, который способен масштабироваться на уровне предприятия. По словам Эмблера, «многие гибкие методологии, включая Scrum, XP, AM, Agile Data, kanban и другие, фокусируются на подмножестве действий, необходимых для доставки решения от инициации проекта до его реализации. До того, как был разработан DAD, вам нужно было собрать свою собственную гибкую методологию для выполнения работы». [6]
DAD был разработан в результате наблюдения за общими закономерностями, в которых гибкость успешно применялась в масштабе. [7]
В 2015 году была разработана структура Disciplined Agile (DA), которая позже стала Disciplined Agile Toolkit. [8] Это называлось Disciplined Agile 2.x. DAD сформировал основу для DA. [ нужна ссылка ] Был добавлен второй уровень — дисциплинированный DevOps, а также третий уровень — дисциплинированные гибкие ИТ (DAIT). [ нужна ссылка ] Эти уровни, соответственно, касались того, как решать DevOps и ИТ-процессы в условиях корпоративного класса.
Версия Disciplined Agile 3.x была выпущена в августе 2017 года, чтобы представить четвертый уровень, Disciplined Agile Enterprise (DAE), для реализации всего диапазона процессов, необходимых для гибкости бизнеса. [9]
В декабре 2018 года был выпущен Disciplined Agile 4, который теперь называется Disciplined Agile Toolkit. [ нужна ссылка ] Основное внимание было уделено полностью обновленному описанию DAD и стратегии командного улучшения, называемой управляемым непрерывным улучшением (GCI). [ нужна ссылка ]
В августе 2019 года Disciplined Agile была приобретена Project Management Institute . [10]
Ключевые аспекты [ править ]
Многие из проблем, с которыми сталкиваются команды, выходят за рамки Scrum, и командам необходимо искать другие методы с дублирующими частями и противоречивой терминологией. DAD пытается решить эти проблемы, используя гибридный подход к предоставлению ИТ-решений, ориентированный на людей и ориентированный на обучение. [11]
Люди прежде всего [ править ]
Дисциплинированная гибкая доставка (DAD) определяет, что «Люди и то, как они взаимодействуют друг с другом, являются основным фактором, определяющим успех команды разработки решений». [12] DAD поддерживает надежный набор ролей (см. раздел ниже), прав и обязанностей, которые вы можете адаптировать в соответствии с потребностями вашей ситуации. DAD продвигает идеи о том, что члены команды должны тесно сотрудничать и учиться друг у друга, что команда должна прилагать усилия, чтобы учиться на своем опыте и развивать свой подход, и что отдельные люди также должны делать то же самое. [13]
Гибрид [ править ]
DAD — это гибридный набор инструментов, который принимает и адаптирует проверенные стратегии на основе существующих методов, таких как Scrum , экстремальное программирование (XP), SAFe , гибкое моделирование (AM), унифицированный процесс (UP), канбан , внешняя разработка программного обеспечения , гибкие данные (AD). ) и Spotify модель разработки . Вместо того, чтобы тратить время на адаптацию одной из этих существующих структур, с помощью DAD все усилия по объединению соответствующих частей каждого метода уже сделаны.
Полный цикл жизненный доставки
В отличие от гибких методов первого поколения, которые обычно фокусируются на аспектах жизненного цикла построения, DAD охватывает полный жизненный цикл поставки, от инициирования команды до доставки решения конечным пользователям.
Поддержка нескольких жизненных циклов [ править ]
DAD поддерживает шесть жизненных циклов на выбор: гибкий, экономичный, непрерывный, исследовательский и вариант жизненного цикла для большой команды. DAD не предписывает единый жизненный цикл, поскольку признает, что один подход не подходит всем.
Полный [ править ]
DAD показывает, как разработка, моделирование, архитектура, управление, требования/результаты, документация, управление и другие стратегии сочетаются в единое целое. DAD выполняет «тяжелую работу процесса», которую другие методы оставляют на ваше усмотрение.
Контекстно-зависимый [ править ]
Этот подход ориентирован на цели или результаты, а не на предписания. При этом DAD предоставляет контекстные советы относительно жизнеспособных альтернатив — что работает, что нет и, что более важно, почему — и их компромиссов, позволяя вам адаптировать свой способ работы для решения ситуации, в которой вы оказались, и сделать это. в упрощенном порядке.
Расходные решения вместо работающего программного обеспечения [ править ]
DAD постепенно переходит от простого производства программного обеспечения к предоставлению расходных решений, которые приносят реальную бизнес-ценность заинтересованным сторонам. Хотя программное обеспечение, несомненно, является важной частью конечного результата, сосредоточенность на решении означает целостное представление об общей проблеме. Это может привести к предложению обновлений в оборудовании, бизнес-процессах и организационных процессах, а также в общих организационных структурах.
Самоорганизация управлением соответствующим с
Гибкие и бережливые команды самоорганизуются, а это означает, что люди, выполняющие работу, — это те, кто ее планирует и оценивает. Они по-прежнему должны работать в духе предпринимательства, отражающем приоритеты их организации, а для этого им потребуется надлежащее управление со стороны высшего руководства.
Жизненные циклы [ править ]
Изначально Disciplined поддерживал гибкий (на основе Scrum) жизненный цикл проекта и жизненный цикл проекта Lean (на основе Канбана). С тех пор он был расширен для поддержки шести жизненных циклов:
- Гибкий . Трехэтапный жизненный цикл проекта, основанный на Scrum. Это следующие фазы: «Начало» (иногда называемое «Спринт 0»), «Строительство» и «Переход» (иногда называемое «Спринт релиза»).
- Наклонять . Трехэтапный жизненный цикл проекта, основанный на Канбане.
- Непрерывная доставка: Agile . Жизненный цикл продукта на основе Agile, который поддерживает непрерывный поток работы, приводящий к дополнительным выпускам (обычно один раз в неделю).
- Непрерывная поставка: бережливое производство . Экономичный жизненный цикл продукта, который поддерживает непрерывный поток работы.
- Исследовательский . Жизненный цикл, основанный на экспериментах, основанный на бережливом запуске , который был расширен для параллельной разработки минимально жизнеспособных продуктов в соответствии с рекомендациями Cynefin .
- Программа . Жизненный цикл координации команды команд.
Цели процесса [ править ]
DAD описывается как совокупность двадцати одной цели процесса или результатов процесса. [14] Эти цели помогают командам упростить процесс принятия решений, учитывающих контекст ситуации, с которой они сталкиваются. Это позволяет командам сосредоточиться на результатах, а не на соблюдении процессов и догадках о расширении гибких методов. Он обеспечивает масштабирование, предоставляя достаточно сложные стратегии для решения тех сложностей, с которыми вы сталкиваетесь.
| Начальный этап | Этап строительства | Переходный этап |
|---|---|---|
| Направьте команду в правильное русло. | Постепенно создайте расходное решение. | Запустить решение в производство. |
|
|
|
| Текущие цели | ||
Совершенствуйтесь и работайте с учетом требований предприятия. | ||
| ||
Роли [ править ]
Основные роли [ править ]
Эти пять основных ролей [15] в дисциплинированной гибкой доставке обычно встречаются независимо от масштаба.
- Заинтересованная сторона . Тот, на кого существенно влияет результат решения. Это больше, чем просто конечный пользователь или клиент, это любой, кто потенциально может быть затронут разработкой и развертыванием программного проекта.
- Владелец продукта . Человек в команде, который выступает «единым голосом клиента», представляя потребности сообщества заинтересованных сторон перед командой гибкой разработки.
- Член команды . Член команды фокусируется на создании реального решения для заинтересованных сторон, включая, помимо прочего: тестирование, анализ, архитектуру, проектирование, программирование, планирование и оценку. У них будет часть необходимых навыков, и они будут стремиться получить больше, чтобы стать специалистами широкого профиля.
- Руководитель команды . Руководитель группы — это руководитель принимающей стороны, а также коуч по agile, отвечающий за облегчение коммуникации, предоставление им возможности выбирать способ работы, а также за обеспечение команды необходимыми ресурсами и отсутствие препятствий.
- Владелец архитектуры . Владеет архитектурными решениями команды и способствует созданию и развитию общего дизайна решения.
Потенциальные роли второго плана [ править ]
Эти роли второго плана [16] вводятся (иногда на временной основе) для решения проблем масштабирования.
- Специалист . Хотя большинство членов agile-команды являются специалистами широкого профиля, [17] иногда требуются другие специалисты в зависимости от потребностей проекта.
- Эксперт по доменам . Хотя владелец продукта представляет широкий круг заинтересованных сторон, иногда требуется эксперт в предметной области для сложных областей, где требуется более детальное понимание.
- Технический эксперт . В случае возникновения особо сложной проблемы при необходимости может быть привлечен технический эксперт. Это могут быть мастера сборки, администраторы гибких баз данных, дизайнеры пользовательского опыта (UX) или эксперты по безопасности.
- Независимый тестер . Хотя большая часть тестирования выполняется членами команды DAD, в случаях со сложными областями или технологиями для параллельной работы может быть привлечена независимая группа тестирования для проверки работы.
- Интегратор . Для сложных технических решений большого масштаба можно использовать интегратор (или несколько интеграторов) для построения всей системы из ее различных подсистем.
Ссылки [ править ]
- ^ Эмблер, Скотт ; Линии, Марк (2019). Выбери свой WoW! Дисциплинированное руководство по гибкой реализации для оптимизации вашего способа работы . ISBN 978-1-7904-4784-8 .
- ^ Книга: Выбери свой WoW! – Дисциплинированный Agile (DA)
- ^ Эмблер, Скотт (2013). «Выходя за рамки Scrum: дисциплинированная гибкая доставка» .
- ^ Дисциплинированная гибкая доставка на предприятии (Cutter IT Journal, специальный выпуск, июнь 2013 г.)
- ^ Крухтен, Филипп ; Горанс, Пол (февраль 2014 г.). Руководство по критическим факторам успеха в гибкой реализации (отчет). IBM Центр государственного бизнеса. п. 14 . Проверено 1 февраля 2014 г.
гибридный гибкий подход к доставке корпоративных ИТ-решений, обеспечивающий прочную основу для масштабирования.
- ^ Дисциплинированная гибкая доставка соответствует CMMI (Cutter IT Journal, ноябрь 2013 г.)
- ^ «Дисциплинированная гибкая доставка» . Перекрестные помехи. Архивировано из оригинала 22 февраля 2014 г. Проверено 31 января 2014 г.
- ^ «Введение в дисциплинированный Agile» .
- ^ Эмблер, Скотт ; Линии, Марк (2017). Руководство для руководителей по дисциплинированному Agile . ISBN 978-1-5398-5296-4 .
- ^ «PMI объявляет о приобретении DA» .
- ^ Лайнс, Марк; Эмблер, Скотт (2019). Выбери свой WoW! Дисциплинированное руководство по гибкой реализации для оптимизации вашего способа работы . п. 41. ИСБН 978-1-7904-4784-8 .
- ^ Эмблер, Скотт. «Agility@Scale: стратегии масштабирования гибкой разработки программного обеспечения» . IBM DeveloperWorks . Программное обеспечение IBM.
- ^ «Дисциплинированная гибкая доставка: введение (информационный документ), стр. 7» (PDF) . Программное обеспечение IBM. Архивировано из оригинала (PDF) 29 мая 2013 г. Проверено 31 января 2014 г.
- ^ Скотт Эмблер; Марк Лайнс (2019). «Выбери свой WoW!» . п. 46.
- ^ Эмблер, Скотт. «Роли в командах DAD» . http://disciplinedagiledelivery.com .
- ^ Эмблер, Скотт. «Роли в командах DAD» . http://disciplinedagiledelivery.com .
- ^ «Обобщающие специалисты: как улучшить свои карьерные навыки в сфере ИТ» . Гибкое моделирование.
Дальнейшее чтение [ править ]
- Браун, Алан (2012). Доставка корпоративного программного обеспечения: обеспечение гибкости и эффективности глобальной цепочки поставок программного обеспечения . ISBN 978-0-321-80301-6 .
- Ройс, Уокер (2013). Гибкость в масштабе: экономическое управление, измеренное улучшение и дисциплинированная гибкая реализация . стр. 873–881. ISBN 978-1-4673-3076-3 .
- Поддержка управления в рамках дисциплинированной гибкой доставки с использованием неинвазивных измерений и интеллектуального анализа процессов (ноябрь 2013 г. , Cutter IT Journal , Астромискис, Джейнс, Силлитти, Суччи)
- 10 принципов успеха в распределенной гибкой доставке (ноябрь 2013 г., Cutter IT Journal , Bavani)
