Author

sokolov

Browsing

Гибкая разработка ПО сегодня встречается повсеместно, можно даже назвать это явление мейнстримом. Однако внедрение Agile в различных организациях характеризуется переменным успехом. Мы подозреваем, что одна из причин возможных неудач кроется в изначальной мотивации к началу Agile трансформации – почему вообще организация решила меняться. Мы расскажем о нескольких основных причинах внедрения Agile в организациях. Кроме того, мы предлагаем порассуждать о возможном влиянии этих причин на успешность трансформации.

Это делают все подряд

Некоторые организации начинают Agile трансформацию, опасаясь того, что в противном случае они окажутся в невыгодном положении по отношению к конкурентам. По сути корневая причина в данном случае звучит как «Все остальные это делают, вероятно, нам тоже стоит это сделать». Обычно это не является залогом успеха. 

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

Лучше, быстрее, дешевле

Некоторые организации используют Agile, желая увеличить скорость выхода на рынок, удовлетворить потребности клиентов или повысить производительность команды. Другими словами, эти организации стремятся к эффективности. Они хотят разрабатывать программное обеспечение лучше, быстрее и дешевле. К сожалению, вероятнее всего, их ждет разочарование.

Эти организации могут увеличить скорость и снизить затраты, убрав процессы, не несущие в себе ценность. Также они могут поставлять продукт быстрее, чем раньше. Если придерживаться практик экстремального программирования, можно разработать более качественное ПО. Но простое внедрение Agile не гарантирует, что эти организации будут действительно разрабатывать программное обеспечение лучше, быстрее и дешевле.

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

Средство для достижения цели

Некоторые организации стремятся улучшить свою деятельность по разработке ПО, деятельность IT в целом, усилить экспертизу в разных областях. Руководство этих организаций видит, что Agile, как и другие идеи, может им в этом помочь.

Эти организации не рассматривают Agile как цель. Скорее, они хотят более эффективной разработки ПО или решают какую-то конкретную проблему. Они находят Agile-подходы полезными для себя, потому что они позволяют их командам постоянно прогрессировать и использовать более эффективные практики разработки ПО. 

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

Почему ваша организация внедрила Agile?

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

Было ли целью вашей Agile трансформации не отставать от других организаций на вашем рынке? Ваша трансформация – больше про конкретные фреймворки и практики? Если это так, вам лучше сделать паузу и оценить, зачем вам внедрять Agile. Определите проблему, которую ваша организация хотела решить, и предложите несколько объективных способов узнать, когда и как вы ее решили. Вот подсказка: проблема не в том, что вы не использовали Agile.

Была ли ваша Agile трансформация начата в интересах повышения эффективности? Сосредоточены ли люди в вашей организации на увеличении скорости поставки продукта? Если это так, предположите, что основное внимание следует уделять не скорости производства. Скорее, стоит попытаться сосредоточиться на производстве правильных вещей. Учите свою организацию правильной приоритизации, подходите к работе над вашим продуктом с точки зрения решения конкретных проблем при наименьшем возможном объеме работы. Не нужно пытаться всегда выполнить все элементы бэклога.

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

Почему ваша организация решила использовать Agile? Вы получаете тот результат, на который рассчитывали? Поделитесь своим опытом в комментариях.

Список литературы

Оригинал статьи

Если вы интересуетесь современными тенденциями в работе и структуре организаций, вы наверняка слышали о так называемых Бирюзовых Организациях. Все любят классификации, вот и Фредерик Лалу, бывший партнер McKinsey & Company, а ныне консультант, коуч и фасилитатор, решил не отставать от трендов и создать свою. Лалу выделил несколько стадий развития общества, назвав их парадигмами и «раскрасив» в разные цвета, и на основе полученной классификации вывел еще одну, венцом которой как раз и являются бирюзовые организации.

В чем же идея бирюзовых организаций? По словам Лалу, «бирюзовая стадия» является высшей ступенью развития организации. Любая бирюзовая организация обладает следующими характеристиками:

  • Наличие эволюционной цели. Внимание: не путать с миссией. Миссия организации почти всегда неразрывно связано с целью заработать, тогда как эволюционная цель – это четкое представление о том, куда и зачем движется организация. Это флаг, вокруг которого собираются люди со схожими ценностями. Критерии успешности и количественные метрики здесь вторичны.
  • Целостность. Мы можем назвать человека целостным, если он не надевает маски, не пытается быть кем-то другим. Организация целостна, если она воспринимается как живой организм, со своими потребностями и эмоциями. Если в 20 веке самой подходящей метафорой для организации был механизм с людьми-винтиками, то сейчас это живое существо, которое комплексно развивается, следит за здоровьем каждого своего органа и воспринимается как единое целое.
  • Самоуправление. Это слово точно слышал каждый, многие, полагаю, даже имели какой-то релевантный опыт, с этим связанный. Отсутствие иерархии в коллективе, коллегиальное принятие решений, открытость и доступность всех данных – вот основные характеристики самоуправления. Далее мы подробно рассмотрим все вышеперечисленное.

Само собой, со стороны многочисленных менеджеров «старого образца» моментально обрушился шквал критики такой организационной модели. Людям, привыкшим делить сотрудников на «трудолюбивых» и «лентяев», считать KPI и строго регламентировать условия работы, довольно сложно поверить в бирюзовую модель; они считают ее утопичной и нежизнеспособной. Попробуем разобраться, так ли это на самом деле.

Мондрагонская Кооперативная Кооперация

Удивительно, что Лалу в своем главном труде «Открывая организации будущего» обошел вниманием Мондрагонскую Кооперативную Кооперацию. По сути именно эта организация является прототипом всех «бирюзовых». Эта федерация кооперативов работников была основана молодым священником Хосе-Мария Арисмендиарриетой в 1956 году и базируется в Испании, в стране басков. В настоящее время это седьмая по выручке испанская компания и ведущая бизнес-группа в стране басков.

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

  • Открытый доступ
  • Демократическая организация
  • Суверенитет труда
  • Инструментальный и подчиненный характер капитала
  • Участие в управлении
  • Солидарность в оплате
  • Многостороннее сотрудничество
  • Социальные преобразования
  • Универсальность
  • Образование

Кроме того, для Мондрагонских кооперативов характерны следующие четыре корпоративные ценности:

  • Сотрудничество
  • Действия в качестве как собственников, так и работников
  • Вовлеченность в руководство
  • Социальная ответственность (распределение богатства, основанное на солидарности; инновации; постоянное обновление во всех областях)

Нетрудно заметить огромное количество общих черт между принципами работы Мондрагонских кооперативов образца 1956 года и моделью, предложенной Лалу в 2014. Сам факт появления данной организации почти 65 лет назад и ее успешного развития можно считать сильным ударом по критике бирюзовых организаций с точки зрения их утопичности. Понятно, что идеи Лалу не совпадают полностью с идеями Арисмендиарриеты, но проследить тренд и доказать жизнеспособность модели видится вполне возможным на основании такого анализа.

Так что же мешает организации стать бирюзовой? Разве что ригидность мышления и взглядов сотрудников/руководства этой организации. В действительности, текущая стадия развития человечества является прямым предиктором возникновения и успеха бирюзовых организаций. В эпоху глобализации и неограниченного доступа к любой информации происходит следующее:

Люди избавлены от априорных истин и идеалов.

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

Труд интеллектуализирован.

Если в ХХ веке, в эпоху индустриализации, труд был по большей части ручным, и для успешной работы предприятия было необходимо соблюдать четкий регламент, то в нынешних реалиях большая часть механической работы автоматизирована. От специалистов высокого уровня же требуется в большей степени интеллектуальная работа – принятие решений, оценка рисков и т.д. В таком сеттинге строгая иерархическая структура скорее ограничивает ресурсы, нежели поддерживает грамотную и полезную для организации деятельность.

Нивелируется проблема мотивации.

Если не нивелируется, то, как минимум, переживает кардинальные преобразования. Есть ли смысл тратить колоссальные ресурсы на контроль деятельности сотрудников, считать их KPI и премировать «лучших», если команда может состоять из изначально заинтересованных специалистов, способных самостоятельно ставить цели и следить за процессом их достижения? Во-первых, такая команда в состоянии самостоятельно вычислить «лентяя» или не замотивированного сотрудника. Во-вторых, этому сотруднику будет изначально некомфортно работать в таких условиях, он либо поменяет свою позицию, либо найдет другую работу. Давно прошли времена, когда сын гончара в 99% случаев становился гончаром. Актуальная эпоха позволяет обучиться и практиковаться в том, что человеку действительно интересно.

Осознанность (Mindfulness).

В ноябре 2017 года это слово достигло рекорда своей популярности в Google запросах. Действительно, осознанность – это тренд. Всё та же всеобщая доступность информации приводит к тому, что люди становятся более рефлексивны. Мы чаще задумываемся, что мы делаем, как, а главное – зачем. Мы прислушиваемся к себе и спрашиваем себя, нравится ли нам то, что мы делаем, видим ли мы в этом смысл. Бирюзовая организация – это формат, позволяющий и поощряющий такую модель поведения, поскольку внутри этого фрейма организация воспринимается как живой организм.

Что вы думаете о бирюзовых организациях? Поддерживает ли компания, в которой вы работаете (которой вы управляете) «бирюзовые идеалы»? Напишите свои мысли в комментариях.

Фреймворк «Дисциплинированный 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-поставка», что также допустимо.

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

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

Любое нестандартное событие или препятствие в команде является вызовом для Скрам Мастера. От него всегда требуется грамотная и своевременная реакция — нужно задать вектор позитивных изменений, при этом не сломав процесс.

Сможете ли вы справиться с распространенными проблемными кейсами, возникающими в Скрам Команде? Мы составили тест, с помощью которого вы можете проверить себя!

Loading