Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

История [ править ]

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

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

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

Дисциплинированная гибкая версия 3.x была выпущена в августе 2017 года, чтобы представить четвертый уровень, дисциплинированное гибкое предприятие (DAE), охватывающий весь спектр процессов, необходимых для гибкости бизнеса. [8]

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

В августе 2019 года Project Management Institute приобрел дисциплинированную Agile . [9]

Ключевые аспекты [ править ]

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

Сначала люди [ править ]

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

Гибрид [ править ]

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 описывается как набор из двадцати одной цели процесса или результатов процесса. [13] Эти цели помогают командам принимать более рациональные решения, учитывающие контекст ситуации, с которой они сталкиваются. Это позволяет командам сосредоточиться на результатах, а не на соблюдении процессов и предположениях о расширении гибких методов. Это позволяет масштабировать, предоставляя достаточно сложные стратегии для решения проблем, с которыми вы сталкиваетесь.

Роли [ править ]

Основные роли [ править ]

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

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

Возможные второстепенные роли [ править ]

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

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

Ссылки [ править ]

  1. ^ Эмблер, Скотт ; Линии, Марк (2019). Выбери свой WoW! Справочник по дисциплинированной гибкой доставке для оптимизации вашего образа работы . ISBN 978-1790447848.
  2. ^ Эмблер, Скотт (2013). «Выход за рамки Scrum: дисциплинированная гибкая доставка» (PDF) .
  3. ^ Дисциплинированная гибкая доставка на предприятии (Cutter IT Journal, специальный выпуск, июнь 2013 г.)
  4. ^ Крухтен, Филипп ; Горанс, Пол (февраль 2014 г.). Руководство по критическим факторам успеха в гибкой доставке (отчет). Центр IBM для бизнеса в правительстве. п. 14 . Проверено 1 февраля 2014 года . Гибридный гибкий подход к предоставлению корпоративных ИТ-решений, который обеспечивает прочную основу для масштабирования
  5. ^ Дисциплинированная гибкая доставка соответствует CMMI (Cutter IT Journal, ноябрь 2013 г.)
  6. ^ «Дисциплинированная гибкая доставка» . Перекрестные помехи. Архивировано из оригинала на 2014-02-22 . Проверено 31 января 2014 .
  7. ^ "Введение в дисциплинированную Agile" .
  8. ^ Эмблер, Скотт ; Линии, Марк (2017). Руководство по дисциплинированной Agile для руководителей . ISBN 978-1539852964.
  9. ^ «PMI объявляет о приобретении DA» .
  10. ^ Линии, Марка; Эмблер, Скотт (2019). Выбери свой WoW! Справочник по дисциплинированной гибкой доставке для оптимизации вашего образа работы . п. 41. ISBN 978-1790447848.
  11. ^ Эмблер, Скотт. «Agility @ Scale: стратегии масштабирования гибкой разработки программного обеспечения» . IBM developerWorks . Программное обеспечение IBM.
  12. ^ «Дисциплинированная гибкая доставка: введение (технический документ), стр. 7» (PDF) . Программное обеспечение IBM. Архивировано из оригинального (PDF) 29 мая 2013 года . Проверено 31 января 2014 .
  13. ^ Ambler & Lines (2019). "Выбери свой WoW!" . п. 46.CS1 maint: использует параметр авторов ( ссылка )
  14. ^ Эмблер, Скотт. «Роли в командах DAD» . disciplinedagiledelivery.com .
  15. ^ Эмблер, Скотт. «Роли в командах DAD» . disciplinedagiledelivery.com .
  16. ^ «Специалисты по обобщению: улучшение навыков вашей карьеры в сфере ИТ» . Гибкое моделирование.

Дальнейшее чтение [ править ]

  • Браун, Алан (2012). Доставка корпоративного программного обеспечения: повышение гибкости и эффективности глобальной цепочки поставок программного обеспечения . ISBN 978-0321803016.
  • Ройс, Уокер (2013). «Гибкость в масштабе: экономическое управление, измеряемое улучшение и дисциплинированная гибкая доставка» .
  • Поддержка управления в дисциплинированной гибкой доставке с использованием неинвазивных измерений и анализа процессов (ноябрь 2013 г., Cutter IT Journal , Astromiskis, Janes, Sillitti, Succi)
  • 10 принципов успеха в распределенной гибкой доставке (ноябрь 2013 г., Cutter IT Journal , Бавани)