Что это вообще значит — «дисциплинированный Agile»?

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

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

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

И как же стать дисциплинированным?

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

Принципы Дисциплинированного Agile :

1. Восхищать клиентов. Мы восхищаем наших клиентов. Наши продукты и услуги не только соответствуют их потребностям и ожиданиям, но и превосходят их.
2. Быть крутыми. Крутые сильные команды построены вокруг мотивированных людей. Такие команды получают поддержку и сеттинг для достижения их целей.
3. Быть прагматичными. Давайте будем не просто гибкими, но и эффективными настолько, насколько сможем. 
4. Погружаться в контекст. Каждый человек, каждая команда и каждая организация уникальны. Давайте найдем и разработаем эффективную стратегию, учитывая актуальную ситуацию.
5. Наш выбор хорош! Разные контексты требуют разных стратегий. Команды должны иметь возможность владеть своим собственным процессом и экспериментировать. Это поможет выяснить, что для них на практике работает лучше с учетом конкретной ситуации. Полный анализ сильных и слабых сторон каждого эксперимента позволяет быстрее находить лучшую стратегию для вашей организации.
6. Оптимизировать процесс. Ваша организация представляет собой сложную систему взаимодействующих команд и групп, которые непрерывно развиваются и влияют друг на друга. Вы должны убедиться, что эти команды выровнены по процессам, и что их процессы будут такими же гармоничными и в дальнейшем. В идеале команды выравнивают и синхронизируют процессы на постоянной основе.
7. Знать, что происходит в компании. Когда люди осведомлены, куда их организация движется, они мотивированы учитывать общие потребности своей компании. Это помогает им убедиться, что то, что они делают, важно и для организации, а не только для их команды.

Как эти принципы связаны с Манифестом?

Они дополняют друг друга. В 2010 году началась разработка Манифеста DA, обновления для Agile Manifesto for Software Development. Манифест DA его расширил и дополнил, чтобы отразить реалии, с которыми сталкиваются современные организации. Вышеперечисленные семь принципов были разработаны на основе Манифеста DA и находились под влиянием как принципов Modern Agile Джошуа Кериевского, так и Heart of Agile Алистера Кокберна

Список используемой литературы:

An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility 

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

Наши ценности

Люди и взаимодействия важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану

Прозрачность важнее ложных прогнозов

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Принципы, лежащие в основе дисциплинированного Agile-манифеста

1. Наивысшим приоритетом является удовлетворение потребностей заинтересованных лиц, благодаря регулярной и ранней поставке ценных решений.
2. Новые требования приветствуются, даже на последних этапах жизненного цикла поставки решения. Agile-процессы позволяют использовать изменения для обеспечения  заказчику конкурентного преимущества.
3. Ценные решения необходимо выпускать непрерывно, с периодичностью от нескольких раз в день до каждых пару недель, с целью увеличения частоты поставки со временем.
4. Заинтересованные лица и разработчики должны активно сотрудничать для достижения результатов.
5. Создавайте команды вокруг мотивированных людей. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Самый эффективный и практичный способ обмена информацией как с самой командой, так и внутри команды — непосредственное общение, в идеале, вокруг доски.
7. Непрерывная поставка ценности — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс поставки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд, которые используют технологическую дорожную карту (roadmap) и поддержку.
12. Команда должна систематически анализировать возможные способы улучшения эффективности, затем пробовать, обучаться и соотвественно корректировать стиль своей работы.
13. Используйте и развивайте активы вашей организации, сотрудничайте с людьми, которые ответственны за эти активы.
14. Визуализируйте работу, чтобы постоянно поставлять ценность и свести к минимуму объем незавершенной работы.
15. Развивайте не только отдельных людей и команды, но и организацию в целом; поддерживайте не только Agile команды, но и другие.
16. Измеряйте работу и её результаты, предпочитайте автоматизированные метрики ручным вычислениям. Это позволит принимать решения на основе конкретных данных.
17. Обеспечивайте полную прозрачность для заинтересованных лиц во всем, что вы делаете и производите, чтобы поддерживать открытые, честные коммуникации и эффективное взаимодействие с командой.

Фреймворк «Дисциплинированный Agile» достаточно лёгок в применении. Он позволяет обеспечить основу для гибкости бизнеса, оптимизируя процессы в зависимости от контекста. Это достигается путем демонстрации совместной работы следующих видов деятельности: Delivery, DevOps, IT, Enterprise. Данный фреймворк описывает, зачем нужна каждая из перечисленных активностей, предоставляет ряд решений для их взаимодействия и описывает преимущества каждого из них.

Сферы применения DA

Разберем каждую часть диаграммы выше:

1. Поставка по Дисциплинированному Agile (DAD) предполагает потоковый способ поставки решения от начала до конца. Например: первоначальное моделирование и планирование, формирование команды, обеспечение финансирования, непрерывная архитектура, непрерывное тестирование, непрерывная разработка и управление на протяжении всей итерации. Фреймворк включает в себя поддержку множества жизненных циклов поставки, в том числе Scrum-итерации, Kanban-каденции и непрерывную поставку решений.
2. Дисциплинированный DevOps – это рационализация разработки IT-решений и IT-операций, а также поддержка деятельности IT-подразделений организации для повышения эффективности.
3. Дисциплинированный Agile IT (DAIT) рассматривает, как применять Agile и Lean практики ко всем аспектам IT – архитектуре предприятия, управлению данными, управлению продуктовым портфелем, управление IT и др.
4. Предприятие, основанное на Дисциплинированном Agile, способно предвидеть изменения на рынке и быстро на них реагировать. Это достигается благодаря организационной культуре и структуре, способствующей изменениям в контексте актуальной ситуации. Такие организации нуждаются в соответствующем стиле мышления в бизнесе, внедрении инноваций с помощью Agile и Lean практик.

Дисциплинированный Agile. Зачем?

Чтобы ответить на этот вопрос давайте рассмотрим ряд преимуществ, которыми обладает фреймворк DA.

1. «Поставка по Дисциплинированному Agile» описывает то, как Agile/Lean команды работают над продуктом от начала до конца в рамках своих компетенций. Этот фреймворк объединяет в себе все этапы поставки конечного решения (анализ, разработка, тестирование и тд.). Однако для достижения успеха команды зачастую должны взаимодействовать с внешними экспертами, такими как корпоративные архитекторы, операционные инженеры, управляющие, специалисты по управлению данными и тд. Для того, чтобы команда могла эффективно организовать свою работу на всех этапах, внешним экспертам необходимо также разделять идеи Agile.
2. DA обеспечивает согласованную Agile-стратегию для IT. Разработка программного обеспечения – это сложно. Управлять целым IT отделом – еще сложнее, ведь это сложные адаптивные организации. Под этим мы подразумеваем, что действия вашей команды напрямую влияют на деятельность команд, с которыми вы взаимодействуете, и наоборот. Если вы взаимодействуете с рабочими группами (что, к примеру, может быть частью вашей общей DevOps стратегии), следовательно, каждая из них должна адаптировать методы своей работы таким образом, чтобы эффективно сотрудничать друг с другом. В идеале каждая команда будет учиться у других, постоянно улучшая свою работу, тогда эти улучшения будут распространяться и на другие команды. Проблема заключается в том, что в каждой области IT есть своя совокупность знаний; в некоторых случаях публикуются «книги знаний», в которых содержатся рекомендации для людей, работающих в этих областях. К примеру, у менеджмента есть BMIBoK и Prince 2, у корпоративных архитекторов – TOGAF и Zachman Framework, у бизнес-аналитиков – IIBA BoK, у менеджеров данных – DAMA BoK. Эти отрасли и соответствующие им знания зачастую противоречат друг другуё. Иногда в этих книгах рекомендуются методы, не имеющие ничего общего с Agile/Lean. В итоге на уровне всего IT отдела образуется большая запутанность, что приводит к дисфункции как отдельных команд, так и всей организации. Дисциплинированный Agile и его структура показывает, как все вышеописанное может гибко и гармонично сочетаться в условиях сложных адаптивных систем.
3. Контекст имеет значение. Каждый человек, каждая команда и каждая организация уникальны. Это означает, что требуется такая структура, которая позволит делать выбор, адаптировать и развивать специфический подход к ситуации, с которой вы сталкиваетесь на практике. Такие предписывающие фреймворки как Nexus или SAFe, кажутся универсальными и могут показаться привлекательным и простым решением для оптимизации процессов. Зачастую в реальности они приносят больше вреда, чем пользы, для организаций, принявших решение ими воспользоваться.

История

На сегодняшний день существует несколько основных релизов этого фрейморка:

1. Дисциплинированная Agile-поставка 0.х. Изначально разрабатывался в IBM Rational с начала 2009 по июнь 2012 года. Команда IBM тесно сотрудничала с бизнес-партнерами, включая Марка Лайнса, и возглавлялась Скоттом Амблером. IBM Rational Method Composer (RMC) в настоящее время поддерживает более раннюю – 0,5 – версию фреймворка DAD.
2. Дисциплинированная Agile-поставка 1.х. Релиз DAD 1.0 состоялся в июне 2012 года, когда была опубликована первая книга DAD, Disciplined Agile Delivery. Начиная с августа 2012 года, продолжалась разработка и публикация фреймворка DAD. Право интеллектуальной собственности фактически перешло к Консорциуму Дисциплинированного Agile в октябре 2012 года, что было юридически признано IBM в июне 2014 года.
3. Дисциплинированный Agile 2.x. Эта версия фреймворка была выпущена в августе 2015. Как уже говорилось ранее, основное внимание здесь уделяется описанию гибкого, контекстуально-ориентированного подхода к IT процессам.
4. Дисциплинированный Agile 3.x. был выпущен в августе 2017. Основное внимание в этом релизе уделялось расширению фреймворка DA в сторону удовлетворения всех потребностей Дисциплинированного Agile-предприятия (DAE)
5. Дисциплинированный Agile 4.x. выпущен в ноябре 2018 с обновлением части фреймворка DAD с помощью книги Choose Your WoW!

Почему изменилось название?

Сфера применения фреймворка развилась от того, как быть эффективным в предоставлении IT-решений, до того, как быть эффективным в IT в целом, и наконец, во всей организации. В результате было решено, что название «Дисциплинированная Agile-поставка» больше не отражает сути фреймворка, более точным названием будет «Дисциплинированный Agile».

Многие по-прежнему говорят «Дисциплинированная Agile-поставка», что также допустимо.

Список используемой литературы

Оригинал текста