Постигая agile: Постигая Agile. Ценности, принципы, методологии

Содержание

Читать онлайн «Постигая Agile» автора Грин Дженнифер — RuLit

(В дальнейшем вы больше узнаете о том, как работает Scrum и его методы.)

Вторая методология – экстремальное программирование (или XP). В книге Джеймса Шора и Шейна Уордена The Art of Agile Development так описывается XP: «Используя параллельные фазы, команда XP производит развертывание программного обеспечения каждую неделю. В каждой итерации команда анализирует, проектирует, кодирует, тестирует и разворачивает подмножество функций». (Многие XP-команды используют итерации, продолжающиеся одну неделю, а некоторые – две недели или месяц. Кроме того, XP может быть адаптирован для использования при различных продолжительностях итераций. Дальше в нашей книге вы узнаете больше об адаптации гибких методологий.) ХР устанавливает конкретные методы разработки, направленные на улучшение сотрудничества с пользователями, планирования и тестирования.

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

Scrum и XP имеют много общего, включая тот факт, что они итерационные. Это означает, что проект делится на итерации, в которых команда выполняет все активности полного проекта, необходимые, чтобы произвести развертывание программного обеспечения в конце каждой итерации. Некоторые XP-команды используют итерации, длящиеся неделю, а scrum-команды – длиною в месяц. Установка ограничений на продолжительность итераций называется таймбоксинг (timeboxing), и это помогает пользователям узнавать, когда они могут ожидать появления дополнительных функций у ПО.

Многие команды считают, что внедрение методологий – особенно Scrum и XP – плодотворнее, чем простое использование индивидуальных практик. Хотя последнее позволяет каждому участнику команды выбирать методы, характерные именно для его работы, внедрение единой методологии собирает всех членов команды вместе, чтобы выяснить, как выбранные по отдельности практики будут укладываться в рамки одной методологии.

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

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

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

Если приглядеться повнимательнее, то методы и приоритеты в XP отличаются от методов и приоритетов в Scrum. Lean и Канбан имеют различный подход к выбору практик и основных направлений. Почему эти непохожие друг на друга подходы к Agile, имеющие абсолютно разную направленность и практики, все еще считаются гибкими? Дело в том, что все гибкие методологии основываются на одних и тех же принципах, опираются на членов команды и на совместную работу над каждым аспектом проекта. Ценности и принципы Agile-манифеста – это то, что объединяет все методологии.

Рис. 2.5. Scrum, XP и Lean все в своей основе имеют agile-ценности и разделяют некоторые ценности, идеи и методы друг с другом

С чего начинать при работе с новой методологией

Приняв решение о цели внедрения методологии, каждый член команды начинает обсуждать с остальными методы, идеи и перспективы. Это противоположность раздробленного видения. Глядя на ситуацию в целом, команды начинают понимать, как индивидуальные практики взаимодействуют друг с другом. Вот где Брюс, Дэн, Джоанна и Том хотели бы быть! Но они не знают, как туда попасть.

Эндрю Стеллман, «Постигая Agile» | by Aleksey Kalina | Kalina

Так получилось, что недавно пришлось прочитать очень много про Agile и Scrum. Впервые книгу про Scrum прочитал еще год назад, но тема эта не исчерпана и до конца не изучена. И вообще, сразу скажу, что понял одно — чтобы изучить и понять Agile и одну из его методологий Scrum — надо жить в agile-среде, разделять его принципы и практиковать Scrum.

Давайте по порядку.

Книга «Постигая Agile» — крутая. Это ультимативный проводник и справочник в удивительный мир гибкого сознания, самоорганизации, прозрачности, диаграмм сгорания задач и вот всего этого. Если вы никогда и ничего не слышали про Scrum (что странно) или Lean, то «Постигая Agile» та книга, с которой стоит начать знакомство с гибкими методологиями.

Сам Agile выглядит просто. У Agile есть манифест из четырех ценностей:

Люди и их взаимодействие — выше, чем процессы и инструменты
Работающий продукт (ПО) важнее детальной документации
Сотрудничество с клиентом важнее контракта
Реакция на изменение важнее принятого плана

Agile — это набор методов и методологий, которые помогают вашей команде эффективнее мыслить, работать и принимать решения.

Еще есть 12 принципов гибкой разработки программного обеспечения:

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

Немного попахивает религиозностью, конечно.
На этом и основываются методологии гибкой разработки, которым в книге из 650 страниц уделено много внимания: XP (экспериментальное программирование), Lean (бережливое программирование), Канбан, Scrum.

Между методологиями много общего.

* приверженность (ответственность) — важная часть XP и Lean, но Scrum прямо называет это своей ценностью

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

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

Респонденты указали три основные причины провалов agile-проектов: «отсутствие опыта в использовании гибких методов», «философия компании расходится с agile-ценностями» и «внешнее давление со стороны тех, кто придерживается водопадной модели».

Agile надо сперва принять, а затем медленно и верно применять в работе, получая опыт и обучаясь на нем же. Уверен, что это мне предстоит пройти.

Рекомендую книгу тем, кто готов меняться, не ссылаясь на менталитет, жёсткую иерархию и вертикальную структуру компании.

10/10

Дженнифер Грин ★ Постигая Agile читать книгу онлайн бесплатно

Эндрю Стеллман, Дженнифер Грин

Постигая Agile. Ценности, принципы, методологии

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

* * *

Нише и Лизе, которые были очень терпеливы

Предисловие партнера

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

Agile не просто обобщает гибкие методы разработки программного обеспечения и заявляет о новом подходе к управлению ИТ-проектами. Употребляя этот термин, авторы книги говорят скорее о новой концепции мировоззрения.

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

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

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

Отдельно отмечу, что методы Agile работают фрагментарно. Если не получается следовать всем советам сразу, то польза от частичного внедрения этих методик все равно будет ощутимой.

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

Вывод из книги простой – будь гибким, чтобы не сломаться. Но пусть вас не смущает простота этого тезиса. Книга не просто отвечает на вопрос, зачем быть гибким, но и наглядно показывает как.

Кирилл Семенихин,директор Университета Иннополис

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

Сторонники немедленного перехода к практике считали, что постепенно придет и понимание. Если команда будет действовать гибко, то она станет гибкой. Усвоив такие практики, как парное программирование, автоматизация тестирования, непрерывная интеграция, использование итераций, тесное сотрудничество с заказчиком и прочее, команда непременно обретет понимание принципов гибких методологий.

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

Постигая Agile — Новости

Что такое Scrum и как с ним работать

В издательстве МИФ вышла книга «Постигая Agile», которая рассказывает о ценностях и принципах гибких методологий управления проектами. Выбрали для вас несколько любопытных моментов из книги, посвященных самой популярной Agile-методологии.

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

Что такое Scrum

Scrum — это наиболее популярная гибкая методология. В первую очередь, Scrum опирается на командную работу. Как правило, в мире предпринимательства в центре внимания находится исключительно индивид, хотя производство всегда существовало за счет групповых усилий. Блестящие сотрудники могут выполнять работу в десять раз быстрее остальных — и только. Но блестящие команды фантастически увеличат производительность всей компании. Именно поэтому для работы с этой методологией должна быть сформирована команда из 5-9 человек, где каждый будет отвечать за ту или иную функцию.

Подходит ли вам Scrum

Правила Scrum просты и легки для понимания, что позволяет многим командам, применяющим agile-методологии, использовать его в качестве отправной̆ точки. Вот основная схема scrum-проекта:

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

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

Как внедрить

Спринты и собрания на ходу — два важнейших инструмента методики Scrum.

Спринты — это короткие этапы в работе над проектом. Обычно они длятся одну или две недели, по истечении которых команда собирается и смотрит, что получилось. Для того чтобы каждый мог сам планировать свою работу, нужно повесить в кабинете доску и поделить ее на три колонки: «Бэклог», «В работе», «Сделано».

Перед каждым спринтом члены команды будут наклеивать в колонку «Бэклог» стикеры с задачами, которые могут выполнить за неделю. Когда кто-то из команды возьмется за какую-либо задачу, он переклеит стикер в колонку «В работе». А потом стикер переместится в колонку «Сделано».

Ежедневно все члены команды участвуют в короткой встрече (Daily Scrum — ежедневный scrum-митинг), чтобы рассказать друг другу о достижениях и обсудить то, что препятствует дальнейшей работе. Каждый человек отвечает на три вопроса: что я сделал с момента последнего ежедневного совещания? Что буду делать вплоть до следующего ежедневного совещания? Какие препятствия есть на моем пути?

Распространенные ошибки

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

— Усложнение системы. Зачастую, руководители команд хотят несколько изменить подход Scrum, из-за чего он становится сложнее. Лучше действовать наоборот — убедитесь, что внедрение и использование Scrum было как можно более простым и доступным. Ведь всё что вам нужно для начала — это теоретическая база, офисная доска и стикеры с написанными задачами.

— Отсутствие ежедневных встреч. Ежедневные собрания — одна из важнейших частей Scrum. Благодаря таким встречам участники команды понимают, кто над чем работает и с каким настроем делает своё дело. Именно поэтому каждый день команда должна на 15 минут собираться у доски и отвечать на вопросы, о которых мы писали выше.

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

Подробнее про Scrum и другие гибкие методологии управления проектами читайте в книге «Постигая Agile».

AGILE – гибкая система управления проектами

Приходилось ли вам когда-нибудь заниматься проектами или хотя бы принимать участие в проектной работе? Если да, то наверняка вы заметили, что наладить работу команды может быть достаточно сложно. И даже если она налажена, есть риск, что все усилия окажутся напрасными, ведь требования к необходимому результату часто меняются.

Однако существенно упростить работу над проектом и научиться им управлять, тем самым повысив эффективность команды, можно при помощи системы гибкого управления проектами под названием Agile («Аджайл» или «Эджайл»). Вообще, мы уже вкратце рассказывали о ней в нашем курсе по управлению проектами (четвертый урок), но сейчас поговорим на эту тему более подробно.

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

Идеи Agile:

Люди и их взаимодействие важнее, чем процессы и инструменты
Рабочее ПО важнее, чем документация
Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

Удовлетворять клиентов, заблаговременно и постоянно поставляя ПО (клиенты довольны, когда рабочее ПО поступает к ним регулярно и через одинаковые промежутки времени)
Изменять требования к конечному продукту в течение всего цикла его разработки
Поставлять рабочее ПО как можно чаще (раз в неделю, в две недели, в месяц и т.д.)
Поддерживать сотрудничество между разработчиками и заказчиком в течение всего цикла разработки
Поддерживать и мотивировать всех, кто вовлечен в проект (если команда мотивирована, она намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны)
Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации)
Измерять прогресс только посредством рабочего ПО (клиенты должны получать только функциональное и рабочее программное обеспечение)
Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)
Постоянно адаптироваться к меняющейся среде (благодаря этому конечный продукт будет более конкурентоспособен)

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

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

Ключевые моменты в применении Agile

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

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

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

Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым.

Еще одним важным моментом Agile-методологии является разделение всего объема проекта на несколько более мелких составных частей. Такой подход многократно упрощает процесс разработки, а отдельные группы команды могут фокусироваться каждая на своей конкретной задаче.

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

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

Если же мы разделим все время, отведенное на проект, на несколько спринтов, получим конкретное их количество; пусть их будет 15. Каждый спринт длится, к примеру, две недели. Вот как раз в течение этих двух недель (времени, отведенного на спринт) участники каждый день встречаются для обсуждения процесса и прогресса.

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

Что я делал вчера?
Чем я буду занят сегодня?
Что мешает мне работать?

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

Четко обозначается значение проекта
В процессе реализации активно участвует клиент
Общий объем работ выполняется пошагово
Ориентироваться следует на конкретный результат
Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Плюсы и минусы Agile

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

В первую очередь стоит отметить, что Agile-управление очень гибкое. Если, например, традиционная методология указывает на конкретные этапы работы, то Эджайл легко подстраивается под потребителя конечного продукта и требования заказчика.

Собственно, и в конечном продукте число дефектов минимизируется, ведь он является результатом тщательной проверки качества, которая проводится по завершении каждого этапа-спринта.

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Understanding Fake Agile

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

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

С растущим признанием того факта, что «Agile пожирает мир», опросы Deloitte и McKinsey показывают, что более 90% руководителей высшего звена уделяют первоочередное внимание гибкости, в то время как менее 10% считают свою фирму в настоящее время очень гибкой. Разрыв между устремлениями и реальностью привел к тому, что огромное количество менеджеров, консультантов и коучей заявили о своей гибкости и предложили помощь фирмам в гибкости. У многих фирм есть генеральные директора, которые спрашивают: «Почему мы не гибкие?»

В результате термин «гибкий» часто используется без какого-либо согласия относительно его значения.Его часто применяют к фирмам или частям фирм, которые не претендуют на какую-либо гибкость. Отчасти в результате фирмы, которые на самом деле очень гибкие, часто избегают ярлыка «гибкие» и используют свой собственный словарный запас, который кажется более аутентичным.

Определение гибкости

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

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

Итак, три закона Agile:

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

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

Agile без этикетки

В определении признается, что в некоторых из наиболее успешных реализаций Agile используется отечественная терминология. Другими словами, эти фирмы даже не называют себя Agile и уклоняются от стандартной лексики Agile, некоторые из которых (например, Scrum) преднамеренно создавались как непривлекательные для руководства. Таким образом, большинство крупнейших и наиболее быстрорастущих фирм на планете — Amazon, Apple, Facebook, Google, Netflix и Microsoft — во многом отличаются гибкостью, хотя обычно они не используют стандартный словарь Agile.Гибкость их бизнеса — важная причина, по которой они стали самыми дорогими фирмами в мире.

«Ранняя гибкость»

Agile — это путешествие. Ни одна крупная компания не может реализовать все элементы Agile в первый же день. Освоение различных аспектов Agile требует времени.Когда компания находится на ранней стадии Agile-пути, это можно назвать «Early-Stage Agile». Это не поддельный Agile: это неполный Agile. Если путешествие пойдет хорошо, то фирма постепенно овладеет всеми тремя законами гибкости, а также стратегической гибкости. Путешествие никогда не заканчивается: фирмы продолжают находить новые способы стать еще более гибкими.

Изображение: Стив Деннинг

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

В отличие от этого, Amazon с самого начала своего дебюта на фондовом рынке в 1997 году охватила одержимость потребителями, с явным обязательством посвятить себя первостепенной роли в создании ценности для клиентов и достижении доминирования на рынке.Лишь пять лет спустя, примерно в 2002 году, Amazon объединила свои усилия с «командами из двух пицц» и начала объединять команды в сеть, а не в иерархию сверху вниз. До этого было бы уместно назвать Amazon экземпляром Early-Stage Agile, хотя последовательность первых шагов на его пути отличалась от Microsoft. ‘

«Agile только по названию»

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

«Agile только по названию» также иногда применяется к фирмам, которые внедряют церемонии и процессы «Agile», но без Agile-мышления. Это , выполняющие Agile, а — Agile . Например, в Wal-Mart до 2016 года было много якобы гибких команд, но они не получали от этого особой пользы. Команды выполняли гибкие процессы, но сердца менеджеров были не в этом. Им не хватало гибкого мышления.

Только в 2016 году, когда Walmart купил Jet.com и нанял Марка Лора, чтобы возглавить усилия Wal-Mart, все начало «двигаться со скоростью стартапа», и выгоды начали поступать. В течение года Wal-Mart значительно расширила ассортимент продуктов, доступных в Интернете, предложила бесплатную двухдневную доставку без необходимости платить клиентам за членство в Amazon Prime и развернула свои магазины в качестве центров исполнения.Вскоре последовали лучшие финансовые результаты.

«Agile For Software Only»

Для многих agile-специалистов Манифест по гибкой разработке программного обеспечения 2001 года является северной звездой движения agile. Его 4 ценности и 12 принципов послужили руководством для сотен тысяч разработчиков программного обеспечения, заинтересованных в «раскрытии лучших способов разработки программного обеспечения, выполняя это и помогая другим в этом».

Манифест Agile часто также является отправной точкой для тех, кто стремится распространить идею гибкости за пределами разработки программного обеспечения, и поэтому также становится важным ориентиром для гибкости бизнеса.Собрание в 2011 году 10 первоначальных подписантов Манифеста не проявило склонности к изменению ни одного слова Манифеста или расширению его, чтобы выйти за рамки программного обеспечения. Манифест теперь имеет статус культового исторического документа, сродни Великой хартии вольностей или Декларации независимости. Хотя эти исторические документы сегодня не говорят последнее слово по соответствующим темам, они остаются постоянными маяками для тех, кто придет позже.

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

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

«Заблокированные Agile Journeys»

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

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

В какой-то момент лоббирование может раздражать высшее руководство, поскольку разработчики программного обеспечения бросают вызов устоявшимся методам управления. В результате руководство может закрыть внедрение Agile и уволить руководителей и тренеров Agile. Конечно, высшее руководство таких слов не использует. Вместо этого они объявляют о победе: «Мы уже подвижны. Нам не нужны гибкие лидеры, тренеры и многое другое ». В результате Agile-путешествие может остановиться, умереть или, по крайней мере, уйти в подполье.

Изображение: Стив Деннинг

Тем не менее, проблема на рынке, которая побудила фирму в первую очередь заняться Agile, все еще существует.Без Agile компания не сможет достаточно быстро разрабатывать и адаптировать программное обеспечение — серьезный недостаток в мире, который быстро переходит на цифровые технологии. Часто через несколько лет мы видим, как компания предпринимает новые усилия, чтобы «стать гибкой».

Дело не в том, что «гибкая разработка только для программного обеспечения» — это поддельная гибкость. Это не. Просто когда гибкое управление ограничивается только программным обеспечением, его продолжительность жизни ограничена. Конфликты с остальной частью организации неизбежны. Agile и бюрократия несовместимы: в среднесрочной перспективе выжить может только один.

«Agile под брендом»

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

Линн Казали

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

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

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

Можно посочувствовать разглагольствованию Люка Холливелла около десяти лет назад.

Мне это надоело. Я не могу дождаться того дня, когда все поймут, насколько модной диетой, религиозным культом и зарабатыванием денег это для группы консультантов. Я не могу дождаться, когда люди осознают тот факт, что единственные хорошие части Agile — это просто здравый смысл и не нуждаются в «манифесте» или евангелистах для их поддержки ».

Множественные формы брендированного Agile сбивают с толку и могут создать впечатление, что сам Agile может сбивать с толку.В целом, «фирменный Agile» включает в себя немного подлинного Agile и немного поддельного Agile. Главное предостережение здесь — остерегаться консультантов и инструкторов, которые настаивают на том, что их фирменная версия Agile является «единственным верным способом».

Рамки масштабирования: SAFe

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

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

Масштабируемая Agile Inc

Особенно тревожным вариантом является Scaled Agile Framework или SAFe.По сути, это систематизированная бюрократия, в которой заказчик практически полностью отсутствует. Теперь это широко распространено в крупных фирмах, потому что дает руководству мандат называть себя гибким и продолжать делать то, что они делали всегда. По сути, он подчиняет гибкие команды бюрократии, вместо того, чтобы делать то, что необходимо для достижения гибкости бизнеса, а именно, преобразовывать большие монолитные внутренне ориентированные системы в механизмы, в которых бюджеты, HR, финансы и т. Д. Являются гибкими и внешне ориентированными. для поддержки Agile-команд в работе.Незначительная роль клиента в приведенной выше таблице указывает на проблему.

Существует риск того, что SAFe дискредитирует подлинный Agile. Это иллюстрация закона Грешема: плохие деньги вытесняют хорошие. Когда это происходит, SAFe становится воплощением «поддельной Agile». Вполне возможно, что когда SAFe внедряется менеджерами с подлинным Agile-мышлением, его негативные побочные эффекты могут быть смягчены. У меня будет вопрос: зачем вообще кому-то с подлинным Agile-мышлением использовать SAFe?

«Agile Lite»

Еще одна тревожная форма Agile, которая начала появляться, — это так называемая Agile-lite.Это появилось в прошлогодней статье Harvard Business Review в статье, в которой объяснялось, как некоторые службы управления персоналом пытались найти способы стать гибкими. В статье был заголовок: «HR становится гибким». Но в тексте говорилось, что «HR переходят на« облегченную гибкость »». Мы узнали, что «HR применяет общие принципы Agile, не применяя все инструменты и протоколы из мира технологий». Судя по примерам, кажется, что «Agile lite» означает принятие инструментов и практик Agile без необходимости их развертывания с гибким мышлением.Без Agile-мышления Agile остается инертным, безжизненным набором церемоний.

И читайте также:

Почему Agile ест мир

Обеспечение гибкости всей фирмы

Понимание гибкого управления

Добро пожаловать на HBR IdeaCast от Harvard Business Review. Я Сара Грин Кармайкл. Сегодня я разговариваю с Дарреллом Ригби и Джеффом Сазерлендом. Даррелл — партнер Bain & Company и глава отдела глобальных инноваций и розничной торговли, и сегодня он присоединится ко мне здесь, в студии.Даррелл, большое спасибо, что пришли.

ДАРРЕЛЛ РИГБИ: Спасибо, Сара. Приятно быть с тобой.

САРА ГРИН КАРМИКЭЛ: Джефф Сазерленд является соавтором гибкой инновационной формы Scrum и генеральным директором Scrum, Inc., консалтинговой и обучающей фирмы. Джефф, большое спасибо за разговор с нами сегодня.

ДЖЕФФ САЗЕРЛЕНД: Спасибо, что пригласили меня. Жду разговора.

САРА ГРИН КАРМИКЭЛ: Дэрил и Джефф вместе с Хиротакой Такеучи из Гарвардской школы бизнеса являются соавторами новой статьи «Охват Agile: как овладеть процессом», которая трансформирует менеджмент.

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

Итак, для начала, что такое Agile? И Джефф, давай начнем с тебя. О чем мы здесь говорим?

ДЖЕФФ САЗЕРЛЕНД: Что ж, гибкость — это слово, пришедшее из встречи, на которой мы написали манифест Agile, который в то время был направлен на нашу разработку программного обеспечения, но в основном имел четыре ценности.

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

САРА ГРИН КАРМИХАЭЛ: И я думаю, у вас есть врезка в статье, в которой рассматриваются некоторые из этих принципов, такие как люди важнее процессов и инструментов, прототипы важнее документации, реакция на изменения вместо следования плану, а затем сотрудничество с клиентами вместо жестких контрактов. .

ДЖЕФФ САЗЕРЛЕНД: Совершенно верно. Да, это четыре ценности Agile в манифесте.

ДАРРЕЛЛ РИГБИ: Я могу просто добавить, думаю двумя словами, гибкие инновации. И я думаю, что мы определяем инновации как выгодное применение творчества. Так что это не просто блестящая идея. Он должен быть как творческим, так и коммерческим.

И когда мы говорим об Agile, мы действительно противопоставляем его прогнозным инновациям, которые пытаются угадать вначале все требования, которые потребуются в конце.Мы думаем, что agile более адаптивна. То есть вы не можете спрогнозировать все, что потребуется. Итак, вы должны начать с видения того, чего вы хотите достичь. Но будьте готовы сменить путь по пути и как туда добраться.

САРА ГРИН КАРМИХАИЛ: Пока мы говорим об этом, в головах людей могут возникать другие слова. Они могут думать: «Хорошо, так ловко». Мы говорили о бережливом производстве. Может быть, они слышали о Scrum и Kanban. И это может быть… для новичка, это может быть большой словарный запас, чтобы разобраться.

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

ДЖЕФФ САЗЕРЛЕНД: Да. Они определенно могут двигаться вперед, даже не зная всего этого. Но из-за некоторой путаницы, если бы профессор Такеучи был на линии, он бы сказал, что первая статья, написанная по Scrum в HBR в 1986 году, была написана после просмотра бережливых компаний, занимающихся разработкой оборудования, разработкой новых продуктов.И они работали так тесно вместе, что напомнили профессору Такеучи команды по регби. И поэтому он и его коллега профессор Нонака решили назвать это управление проектами Scrum.

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

SARAH GREEN CARMICHAEL: Итак, мы как бы продвигаемся немного назад и вперед по истории этой идеи, и это нормально.Но я хочу просто остановиться на мгновение и уточнить. Мы немного поговорили о программном и аппаратном обеспечении и немного об инновациях в более широком смысле. Прав ли я в этом, Даррелл, что некоторые компании действительно используют это только в своих ИТ-отделах. Другие компании используют его гораздо более продвинутыми способами, например, по всей компании.

ДАРРЕЛЛ РИГБИ: Да, на самом деле довольно забавно, что многие люди задаются вопросом, могут ли гибкие инновации работать вне ИТ, потому что в последние 25–30 лет они, вероятно, применялись именно здесь.Но я думаю, что ирония заключается в том, что изначально он был разработан вне IT.

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

И когда он писал статью в 1986 году, она была посвящена компаниям-производителям оборудования и производителям. И тогда Джефф мог рассказать вам эту историю лучше, чем я, еще в начале 1990-х, искал лучший способ разработки программного обеспечения. И он собирал передовой опыт из множества разных отраслей и из множества различных методологий. И когда он увидел статью Хиротаки, она стала краеугольным камнем его подхода, своего рода моментом эврики, который сказал: ах, теперь я понимаю, как соединить все эти элементы вместе.

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

САРА ГРИН КАРМИХАЕЛ: Ну, и это было интересно мне в статье.Одна из вещей, которые вы пишете, заключается в том, что если вы пытаетесь внедрить это в своей компании, не заставляйте всех использовать это. Это вроде как апробируют в нескольких местах, где люди в восторге от этого, а затем пусть энтузиазм распространится, когда люди увидят, насколько хорошо это работает.

ДЖЕФФ САЗЕРЛЕНД: Да, ну, это одна из проблем, потому что Скрам был назван в честь регби, а регби — это спорт. И нельзя просто выводить людей на поле и просить их поиграть в футбол, если они этого не хотят.Так что лучше всего, если люди будут работать волонтерами. Прелесть в том, что это намного веселее, активнее и интереснее, чем старый способ большого предварительного планирования, а затем долгой разработки без каких-либо видимых элементов. Так что людям это больше нравится, когда они в нем участвуют. Но людям действительно нужно хотеть это делать.

ДАРРЕЛЛ РИГБИ: И вы знаете, я думаю, что у Agile-инноваций было две основные цели, когда они только начинались. Во-первых, компании хотели лучших результатов. Но и сотрудники искали способ лучше выполнять свою работу.И если вы посмотрите на бережливое производство и другие концепции, я думаю, что одна из самых больших потерь в наши дни — это растрата таланта, поскольку многие люди в организации способны быть гораздо более инновационными, чем их когда-либо просили. .

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

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

ДЖЕФФ САЗЕРЛЕНД: Кроме того, это не просто раскрытие талантов, которыми обладают люди.Но, безусловно, за многие годы, которые мы проработали в игровой индустрии и подобных местах, лучшие люди не будут работать в среде, которая не является гибкой. Многие генеральные директора, которые приходят ко мне и говорят, говорят, как мы собираемся получить этот талант? Наши конкуренты — это Google, Apple и все эти другие компании, которые крадут всех наших лучших людей. Нам нужна среда, которая действительно нравится разработчикам, увлекательная, веселая и радикально инновационная.

SARAH GREEN CARMICHAEL: Вы упомянули, что много работали с игровой индустрией.Поэтому я не знаю, есть ли пример из того мира или, может быть, из любого примера, который вам особенно нравится, но просто история, которая поможет нам понять, как это действительно выглядит в действии. Я думаю, что большинство из нас, вероятно, уже имели некоторый опыт работы с Agile. Но как это должно работать? Как это должно выглядеть?

ДЖЕФФ САЗЕРЛЕНД: Что ж, вам нужно начать — в Scrum у нас есть product owner. Это человек, у которого есть видение того, что нужно построить. И он создает бэклог, список функций, которые должны отображаться в порядке их ценности для бизнеса.И он привлекает команду и мастера Scrum для работы с ним, чтобы выяснить, как это реализовать.

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

Таким образом, именно этот режим работы позволяет вам получить — как мы говорим в моей недавней книге: «Скрам — это искусство выполнять в два раза больше работы за половину времени». И это лучше, потому что это напрямую связано с желаниями, желаниями и чувствами клиентов по поводу того, что они действительно видят работающими. И

САРА ГРИН КАРМИХЕЙЛ: Даррелл, может, я брошу это тебе обратно. Такой способ работы, для каких компаний и отраслей он подходит? Есть ли другие, для которых он не работает так же хорошо? Я имею в виду, что у каждой системы есть свои плюсы и минусы.Что вы думаете?

ДАРРЕЛЛ РИГБИ: Да, и это не волшебное решение. Но я считаю, что это очень эффективно, особенно если вы ищете прорывные инновации. Когда я впервые поговорил с Джеффом о том, откуда он придумал эту идею для Scrum, он сказал, что на самом деле я пытался создать скунс в штаб-квартире. И поэтому большинство людей понимают, что если вы собираетесь совершить радикальный прорыв, вы должны разделить людей на некую замкнутую автономную единицу.Но когда вы это делаете, вы теряете часть преимущества возможности реинтегрировать эти идеи обратно в бизнес. И я думаю, что прелесть Скрама в том, что это интегрированная скунс-работа.

Итак, когда вы говорите с людьми о том, что вам нужно сделать, чтобы добиться впечатляющего скунса, это восходит к инновационному обновлению Lockheed P-38 * в 1940-х годах. Но Келли Джонсон перечислила 14 правил того, что вам нужно. И он говорил о таких вещах, как будто вы должны делегировать контроль, и вам нужна небольшая, но мощная и автономная команда.И вы должны ограничить доступ надзирателя к команде. И у вас должны быть простые и гибкие итерации.

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

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

САРА ГРИН КАРМИХАЭЛ: Итак, когда мы действительно вникаем в сорняки здесь — я думаю, что я виноват в этом — я могу сделать это более сложным, чем есть на самом деле. Я хочу подчеркнуть, что редакторы HBR успешно реализовали это со своими детьми, помогая им делать уроки.

ДЖЕФФ САЗЕРЛЕНД: Да. Одна из самых интересных областей образования — и я недавно был в Нидерландах, где они внедрили ее в школе, в средних школах и получили действительно отличные результаты. И дети сказали мне, мы не можем поверить, что ты изобрел это для взрослых. Идеально подходит для подростков.

SARAH GREEN CARMICHAEL: Ну, потому что им нравится видеть прогресс, и им нравится иметь возможность сказать, что это то, что меня блокирует, а это большая часть этого, что-то вроде всплытия на блокирующих, верно? В подростковом возрасте это действительно вдохновляет.

ДАРРЕЛЛ РИГБИ: Знаете, мне интересно наблюдать, как люди вообще не имеют опыта работы с Agile. Но если разбить их на эти команды, сначала они будут настроены немного скептически, и я не знаю, как это будет работать. Часто мы получаем такой комментарий: удачи в привлечении нашей управленческой команды к этому.

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

САРА ГРИН КАРМИХАЭЛ: Однако вы потратили значительную часть статьи, рассказывая о препятствиях и способах их преодоления. Так что, может быть, здесь мы тоже могли бы затронуть кое-что из этого. Какие ошибки делают люди и как их исправить? Джефф, может, начнем с тебя.

ДЖЕФФ САЗЕРЛЕНД: Что ж, самая большая проблема для традиционного менеджмента — который хочет иметь командный контроль, иерархический режим работы с линейными сроками и датами и произвольные обязательства, которые навязаны работникам — это похоже на тотальный сдвиг, потому что выход В контексте бережливого производства бережливое производство — это вытягивающая система.

Так, например, команда Prius в Toyota — хороший пример, о котором писал профессор Такеучи. Менеджеры ставят действительно агрессивные цели. Нам нужно вдвое больше бензина, и мы хотим, чтобы автомобиль проехал вдвое быстрее. И разработчик сказал, что это невозможно, если делать то, что мы когда-либо делали в Toyota. И руководство посоветовало сделать что-нибудь другое.

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

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

САРА ГРИН КАРМИХЕЙЛ: Даррелл, что-нибудь добавить к этому? Вы хотите выделить какие-либо другие ключевые вопросы?

ДАРРЕЛЛ РИГБИ: Что ж, я согласен с Джеффом в том, что, вероятно, самым сложным для управленческих команд научиться тому, что делегировать полномочия — это нормально.Я думаю, что многие из них выросли, считая, что 2% их времени более ценны, чем 100% кого-то, кто, возможно, младше, но ближе к клиенту, чем они.

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

Я тоже считаю, что эти гибкие системы сложно реализовать. Это не легко. А кое-где и не нужно. Так что есть места, где предиктивные инновации работают отлично. Если вы находитесь в очень стабильной прогностической среде, в которой требования клиентов не изменятся — вы можете спрогнозировать потребности, которые будут необходимы через 18–24 месяца, подробные спецификации, которые вы напишете заранее, будут соответствовать оставайтесь нетронутыми в течение этого двухлетнего периода — вы также можете пойти дальше и использовать традиционные методы инноваций.

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

Но это означает, что высшее руководство должно перестать отдавать приказы и контролировать то, что команда должна делать.И им нужно перестать раздроблять своих лучших сотрудников по такому количеству проектов. Для меня не редкость встретить очень способных руководителей высшего звена, у которых не более 5% или 10% своего времени уделяется бесчисленным проектам, и это просто катастрофа.

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

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

SARAH GREEN CARMICHAEL: Мне любопытно узнать, есть ли какие-то организационные культурные проблемы, о которых нужно знать, знаете ли, если людям не нравятся некоторые из требований прозрачности, требуемых Agile, следует ли вам проявлять осторожность при внедрении этого во всем своем бизнес? Или, если вы работаете в культуре, где людям действительно нравится иерархия, собираетесь ли вы с этим бороться?

ДЖЕФФ САЗЕРЛЕНД: Это, опять же, одно из больших препятствий, возможно, самое большое, которое возникает после того, как руководство изменило свое мышление.То есть Scrum в основном работает над прозрачностью. Он построен на том, чтобы сделать работу прозрачной. Почему? Потому что тогда команды могут организовать что-то таким образом, который иначе был бы невозможен. Они могут быстро увидеть результаты своей работы и очень быстро решить проблемы. А без прозрачности не получится.

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

САРА ГРИН КАРМИКЭЛ: Это такая вещь, когда кажется, что мы на словах говорим о том, что прозрачность — это всегда хорошо. Но на практике мы иногда ведем себя по-разному. Надеюсь, мы проделали хорошую работу по определению того, что такое Agile, как люди могут использовать его для улучшения инноваций, как преодолеть некоторые препятствия. Я знаю, что в статье гораздо больше.

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

ДЖЕФФ САЗЕРЛЕНД: Моя последняя книга «Скрам: искусство делать в два раза больше работы за половину времени» была написана для общего руководства в любой области, чтобы действительно понять основы и иметь возможность поговорить с командой и начать знакомить с некоторыми из них. основные принципы, вы знаете, короткие итерации, вовлечение людей и тому подобное.

И затем мы проводим обучение и консультируем компании по всему миру, помогая им двигаться в этом направлении. А agile — это путешествие. Это не пункт назначения. На самом деле это больше похоже на боевое искусство. Если ты получишь коричневый пояс, ты закончил тренировку по боевым искусствам? Нет, это черный пояс. Если ты получишь черный пояс, ты готов? Нет, есть 10 разных степеней черного пояса. И очень немногие когда-либо попадают в топ.

Итак, мы знаем компании, которые внедрили Scrum, а затем вернулись и снова внедрили его.А затем Cisco осуществляет свою третью крупную трансформацию за последние 10 лет, повторно внедряя ее в третий раз. И я уверен, что они думают, что так будет продолжаться до тех пор, пока компания будет успешной.

САРА ГРИН КАРМИХАЕЛ: Ну, это часть идеи, верно? Это похоже на постоянное улучшение. Так что только потому, что вы сделали это один раз или сделали это немного, нет причин не дорабатывать это и идти дальше.

ДАРРЕЛЛ РИГБИ: И я мог бы добавить к этому, я предпочитаю начинать с малого и создавать увлеченных послов, которые имеют такой большой опыт в этом, что им не терпится рассказать другим подразделениям организации, как это работает.И оттуда я бы сказал, выберите правильную проблему для атаки. Выберите что-то, что действительно требует творческого прорыва, и где, по вашему мнению, если вы соберете команду из очень вовлеченных, увлеченных членов команды, они добьются большего успеха, работая как автономная, кросс-функциональная, междисциплинарная команда, чем команда управления и контроля. команда будет.

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

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

И затем, после того, как вы запустите это в течение трех или четырех месяцев, и слухи начнут распространяться, вы не сможете остановить это, и вам не придется принуждать. Это не будет давить на организацию. Это будет тяга к организации, мы можем попробовать это? Конечно, позвольте нам помочь вам в этом. Но устраняйте преграды, которые стоят на их пути, и не пытайтесь принуждать их к этому.

SARAH GREEN CARMICHAEL: Что ж, похоже, также очень важно управлять, задавая вопросы, вместо того, чтобы пытаться вмешаться и исправить ситуацию, если что-то пойдет не так.

ДАРРЕЛЛ РИГБИ: Совершенно верно. И на мой взгляд — а я довольно высокопоставленный руководитель в Bain — всегда приятно, когда член команды приходит к вам и говорит: ну и дела, я застрял. Как вы думаете, какой будет ответ? И вы говорите, что, занимаясь этим 40 лет, позвольте мне сказать вам, каков будет ответ.

Но со временем я понял, что лучше сказать, что вы порекомендуете? Как вы думаете, какой будет ответ? А потом, когда они вернутся, скажем, как мы можем это проверить? Как бы вы порекомендовали нам разработать среду тестирования и обучения, чтобы выяснить, правильно это или нет?

Так что и у меня все по-другому.Но если я буду придерживаться этого, это будет намного веселее и продуктивнее.

ДЖЕФФ САЗЕРЛЕНД: Верно. Это способствующее лидерство и лидерство-слуга. И так работают лучшие компании, где у них есть руководство, которое воспитывает людей и обучает их становиться великими, а не быть великими лидерами, говорящими всем, что делать.

САРА ГРИН КАРМИХАЕЛ: Я думаю, это отличная записка, на которой можно закончить. Джефф и Даррелл, спасибо вам обоим за то, что нашли время сегодня.

ДАРРЕЛЛ РИГБИ: Спасибо.

ДЖЕФФ САЗЕРЛЕНД: Спасибо.

САРА ГРИН КАРМИХЕЙЛ: Это были Даррелл Ригби и Джефф Сазерленд. Вместе с Хиротакой Такаэути они являются соавторами новой статьи «Embracing Agile». Чтобы найти эту и другие статьи, посетите сайт hbr.org.

* Спикер попросил нас обновить стенограмму, чтобы отразить, что он имел в виду ссылку на обновление P-38, а не на его создание.

Что такое гибкая разработка программного обеспечения?

До 2001 г. — Практика и методы развиваются независимо на основе опыта

Многие люди связывают начало гибкой разработки программного обеспечения и, в некоторой степени, гибкой разработки в целом со встречей, которая произошла в 2001 году, когда был придуман термин «гибкая разработка программного обеспечения».

Однако люди начали работать в стиле Agile еще до встречи 2001 года. Начиная с середины девяностых годов, были разные практики: либо люди, работающие внутри организаций, разрабатывающих программные продукты, либо консультанты, помогающие организациям создавать программное обеспечение, которые думали: «Знаете что? То, как мы создавали программное обеспечение, просто не работает для нас. Мы должны придумать что-то другое ».

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

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

Люди, создавшие эти методологии, посчитали, что другие могут быть заинтересованы в получении некоторых из тех же преимуществ, что и они, поэтому они создали основы для распространения идей среди других команд в других организациях и контекстах. Именно здесь и начали появляться такие фреймворки, как Scrum, Extreme Programming, Feature-Driven Development (FDD) и Dynamic Systems Development Method (DSDM).

Распространение идей в то время было очень органичным, и все эти различные подходы начали развиваться очень массово. Люди заимствовали исходные рамки и настраивали их с помощью различных практик, чтобы сделать их подходящими для своего собственного контекста.

2001 — Автор манифеста Agile

Не существовало единого способа описания этих различных способов разработки программного обеспечения, пока группа из 17 человек не подумала: «Мы все применяем разные подходы к разработке программного обеспечения.Мы должны собраться вместе и посмотреть, есть ли общие черты в том, о чем мы думаем ». Результатом стала встреча на горнолыжном курорте в Сноуберд, штат Юта, в 2001 году.

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

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

В последующие месяцы авторы расширили идеи Agile Manifesto на 12 принципов Agile Manifesto.

Некоторые авторы, в том числе Мартин Фаулер, Дэйв Томас, Джим Хайсмит и Боб Мартин, написали свои воспоминания о написании Agile Manifesto.16 из 17 авторов встретились на Agile2011 и поделились своими воспоминаниями о мероприятии и своими взглядами на состояние Agile на тот момент.

После 2001 г. — Принятие началось массово, стало мейнстримом

После того, как авторы вернулись из Snowbird, Уорд Каннингем опубликовал Agile Manifesto, а затем и 12 принципов на сайте AgileManifesto.org. Люди могли выйти в Интернет и подписать его, чтобы выразить свою поддержку.

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

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

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

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

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

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

Понимание гибкой методологии — подробный обзор

(статья обновлена в сентябре 2019 г.)

Agile-разработка уже давно используется командами по всему миру, поскольку она ориентирована на итерацию, общение и совместную работу.Принятие этой методологии помогло компаниям ускорить процессы вывода на рынок, снизить риски и потери, а также быстро реагировать на постоянно меняющиеся возможности и тенденции. Фактически, последний отчет «State of Agile» от VersionOne показал, что 97% программных команд и организаций сейчас практикуют гибкое управление проектами.

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

Давайте подробнее рассмотрим методологию Agile и то, как она может помочь вашей организации.

Что такое Agile?

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

Каждый принцип, которого придерживаются в управлении проектами Agile (например, Kanban, XP, Scrum и т. Д.), Взят из Agile Manifesto — краткого документа, который направляет разработку программного обеспечения Agile.Он основан на продуктивности команды, гибкости, поставке высококачественной продукции и постоянном улучшении.

Что такое гибкая методология?

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

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

Одно из основных направлений в Agile-методе — это способность работать итеративно.Итерационная работа завершается короткими циклами, когда небольшая часть всего проекта выполняется за один раз.

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

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

Связанное содержимое: гибкая разработка и тестирование программного обеспечения — различные методы

Гибкий процесс

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

1) Стратегическое совещание

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

2) Дорожная карта продукта

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

3) План выпуска

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

4) Планирование спринта

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

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

5) Ежедневная стойка

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

Стендап — на языке Agile — это 15-минутное ежедневное собрание, на котором ваша команда собирается, чтобы обсудить три основных момента:

Задачи, которые вы выполнили вчера
Задачи, над которыми вы работаете сегодня
Препятствия, которые могут встать у вас на пути

6) Обзор Sprints

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

7) Ретроспектива спринта

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

Завершение

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

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

Связанный контент: всестороннее сравнение методологий Agile, Scrum и Waterfall

Определение гибкой трансформации, понимание того, что значит быть гибкой, определение, что такое гибкая трансформация

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

Agile, поскольку он относится к управлению проектами при разработке программного обеспечения, иногда используется как синоним Scrum, Kanban или другого типа фреймворка.Это неправильный и вводящий в заблуждение способ описания того, что значит быть гибким. Agile — это набор принципов и ценностей, официально перечисленных в Agile Manifesto, принятом в 2001 году.

Четыре основных значения:

1. Люди и взаимодействия важнее процессов и инструментов
2. Рабочее программное обеспечение поверх исчерпывающей документации
3. Сотрудничество с клиентами в процессе переговоров по контракту
4. Реагирование на изменение в соответствии с планом

Чтобы предоставить дополнительные рекомендации, были созданы двенадцать принципов, поддерживающих четыре основные ценности, которые также перечислены как часть Agile Manifesto.

Авторы Agile Manifesto не дали рецепта или формулы, как стать гибким. В Манифесте не упоминается Scrum или какие-либо другие процессы или методологии. Они просто описали небольшой набор ценностей, записанных в виде простых утверждений, но большинству организаций все еще сложно их понять и принять.

Многие люди удивляются, узнав, что ошибочно полагать, что организация не может быть гибкой, если они применяют методологию водопада.Фактически, только в одном из заявлений о ценностях Agile Manifesto упоминается программное обеспечение, и ни в одном из них не упоминается методология. Также неверно предполагается, что Agile — это методология.

Agile лучше всего можно охарактеризовать как совокупность ценностей и принципов, включающую множество различных наборов структур, которые помогают организации достичь гибкости. Гибкость — это цель, в то время как Scrum, Lean, Kanban или другие типы фреймворков часто являются «как». Гибкая трансформация не означает предписания методологии.

Определение гибкой трансформации: что такое гибкая трансформация?

Определение гибкой трансформации

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

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

Agile Adoption vs Agile Transformation

Что такое гибкое внедрение и гибкая трансформация?

Термины «гибкое внедрение» и «гибкая трансформация» часто неправильно используются как взаимозаменяемые.Однако есть несколько существенных различий между внедрением и преобразованием.

Agile Adoption

Внедрение Agile означает «гибкость». «Принятие» — это акт принятия или претворения чего-либо в жизнь.

Распространенной реакцией коленного рефлекса является принятие Scrum, популярного фреймворка, потому что он предписывает определенный набор встреч (церемоний) и примерные программы того, что должно происходить на этих церемониях. Часто бывает проще осуществить организационное изменение чего-то, что напоминает «процесс», потому что «процессы» — это то, что кажется наиболее удобным и легким.

Термины «гибкое внедрение» и «гибкая трансформация» часто неправильно используются как взаимозаменяемые. Однако есть несколько существенных различий между внедрением и преобразованием.

Agile Adoption

Внедрение Agile означает «гибкость». «Принятие» — это акт принятия или претворения чего-либо в жизнь.

Распространенной реакцией коленного рефлекса является принятие Scrum, популярного фреймворка, потому что он предписывает определенный набор встреч (церемоний) и примерные программы того, что должно происходить на этих церемониях.Часто бывает проще осуществить организационное изменение чего-то, что напоминает «процесс», потому что «процессы» — это то, что кажется наиболее удобным и легким.

Организации часто терпят неудачу в гибкой трансформации из-за неправильного предположения, что, поскольку они «делают» — они «стали». Было бы преждевременно «принять» практику до того, как понять «почему» эта практика была создана.

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

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

Гибкая трансформация

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

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

Трансформация Agile Lean

Что такое Agile Lean Transformation?

Трансформация Agile Lean трансформируется в гибкость при внедрении и признании практик и ценностей Lean.Бережливое производство, изначально предназначенное для производства, позже было признано применимым и подходящим для разработки программного обеспечения. Основная цель Lean — максимизировать потребительскую ценность при минимизации потерь.

Ключевые принципы бережливого производства:

Lean имеет 7 ключевых принципов (иногда называемых «практиками»), которые применяются к разработке программного обеспечения:

Удаление отходов
Усиленное обучение
Позднее принятие решения
Быстрая доставка
Расширение возможностей команды
Встроенная целостность
Просмотр приложений в целом

Ценности и принципы Agile способствуют быстрому созданию работающего качественного программного обеспечения.Чтобы получить максимальную выгоду, программное обеспечение должно иметь определенную ценность для конечного пользователя.

Устранение потерь (деятельности, не приносящей ценности, например, дефекты, непродуктивные встречи, ожидание, инвентарь и т. Д.), Естественно, позволяет потратить время на деятельность, которая будет потрачена на ценные вещи.

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

Сочетание Lean и Agile помогает быстрее привести организацию к гибкости и бережливому мышлению, не предписывая конкретный набор действий (или процесса).

Понимание ценностей и принципов Agile

Введение в Agile Manifesto:

Наш предыдущий учебник по Agile-методологии подробно объяснил нам все модели и методологии Agile.

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

В этом руководстве мы углубимся в детали гибкой разработки и ее манифеста. Мы увидим, что говорится в манифесте и какие ценности и принципы в нем закреплены.

Введение

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

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

Это было сформулировано в виде 4 ценностей и 12 принципов, чтобы помочь практикам понять, обратиться к нему и применить на практике. И в то время никто из них и представить себе не мог, какое влияние это окажет на будущее управления проектами.

Agile Manifesto

Манифест был очень тщательно сформулирован, чтобы выразить суть Agile в минимальном количестве слов, и он гласит:

«Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это.Благодаря этой работе мы пришли к следующему значению:

Люди и взаимодействия важнее процессов и инструментов.
Рабочее программное обеспечение над исчерпывающей документацией.
Сотрудничество с клиентами по согласованию контрактов.
Реагирование на изменение в соответствии с планом.

То есть, хотя предметы справа имеют ценность, мы ценим предметы слева больше ».

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

Предпочитает:

Люди
Товар
Связь и
Отзывчивость

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

Четыре ценности Agile

Четыре ценности и 12 принципов определяют гибкую поставку программного обеспечения.Сейчас мы подробно обсудим каждую из ценностей.

# 1) Лица и взаимодействия над процессами и инструментами

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

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

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

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

# 2) Рабочее программное обеспечение поверх полной документации

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

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

Но это также усугубило проблемы с доставкой. Основное внимание было уделено документации до такой степени, потому что команды хотели получить готовый продукт, который на 100% соответствовал бы спецификациям. Вот почему основное внимание было уделено детальному отображению всех спецификаций.

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

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

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

3. Сотрудничество с клиентами в ходе переговоров по контракту

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

Сотрудничество подразумевает, что еще есть место для обсуждения, и общение продолжается.

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

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

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

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

4.Реагирование на изменения вместо следования плану

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

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

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

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

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

Agile также планирует, но также следует подходу «точно в срок», когда планирование выполняется ровно тогда, когда это необходимо. И планы всегда открыты для изменения по мере продвижения спринтов.

12 принципов Agile

Существует 12 принципов гибкой разработки, которые были добавлены после создания манифеста, чтобы помочь командам перейти к гибкой разработке и проверить, соответствуют ли методы, которым они следуют, культуре гибкой разработки.

Ниже приводится текст исходных 12 принципов, опубликованных в 2001 году Agile Alliance:

# 1) Нашим наивысшим приоритетом является удовлетворение потребностей клиентов посредством скорейшей и непрерывной поставки ценного программного обеспечения.

# 2) Приветствуем изменение требований даже на поздних стадиях разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.

# 3) Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков.

# 4) Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.

# 5) Создавайте проекты вокруг мотивированных людей.Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.

# 6) Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личный разговор.

# 7) Работающее программное обеспечение — это главный показатель прогресса.

# 8) Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп бесконечно.

# 9) Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.

# 10) Простота — искусство максимального увеличения объема незавершенной работы очень важно.

# 11) Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.

# 12) Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Эти гибкие принципы служат практическим руководством для команд разработчиков.

Еще один способ организации 12 принципов — разделить их на следующие четыре отдельные группы:

Удовлетворенность клиентов
Качество
Работа в команде
Управление проектами

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

Здесь заказчик может быть определен как спонсор проекта или человек, который платит за разработку. Конечный пользователь продукта также является покупателем, но мы можем провести различие между ними, поскольку конечный пользователь называется пользователем.

# 2) Приветствуем изменение требований даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента — Изменения могут быть внесены без особых задержек в общие сроки.

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

# 3) Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков — Об этом позаботятся команды, работающие в спринтах. Поскольку спринты представляют собой итерации с ограниченным сроком, и в конце каждого спринта предоставляется работающее программное обеспечение, клиенты регулярно получают представление о ходе выполнения

# 4) Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта — Лучшие решения принимаются, когда оба работают вместе и существует постоянная обратная связь между ними для корректировки курса и гибкости изменений.Коммуникация между заинтересованными сторонами всегда является ключом к гибкой разработке.

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

Один из способов сделать это — дать команде разработчиков возможность быть самоорганизованной и принимать собственные решения.

# 6) Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение — Коммуникация становится лучше и эффективнее, если команды находятся в одном месте и могут встречаться лицом к лицу. к лицу для обсуждения. Это помогает укрепить доверие и взаимопонимание между различными заинтересованными сторонами.

# 7) Работающее программное обеспечение является основным показателем прогресса — Работающее программное обеспечение превосходит все другие ключевые показатели эффективности и является лучшим индикатором проделанной работы.

# 8) Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп неограниченное время — Подчеркивается постоянство доставки. Команда должна быть в состоянии поддерживать свой темп на протяжении всего проекта и не выгорать после первых нескольких спринтов.

# 9) Постоянное внимание к техническому совершенству и хорошему дизайну повышает гибкость — Команда должна обладать всеми навыками и хорошим дизайном продукта, чтобы справиться с изменениями и произвести высококачественный продукт, имея при этом возможность вносить изменения

# 10) Простота — Искусство максимального увеличения объема незавершенной работы имеет важное значение, и его как раз достаточно, чтобы соответствовать определению «сделано».

# 11) Лучшие архитектуры, требования и проекты возникают из самоорганизующихся групп. — Самоорганизованные команды получают полномочия и берут на себя ответственность за свою работу. Это приводит к открытому общению и регулярному обмену идеями между членами команды.

# 12) Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение — Самосовершенствование приводит к более быстрым результатам и меньшему количеству доработок.

Заключение

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

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

Наш следующий учебник из этой серии расскажет больше о Scrum Team и их ролях !!

PREV Учебное пособие | СЛЕДУЮЩИЙ Учебник

Agile Project Management — Руководство для новичков

Что такое Agile-управление проектами?

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

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

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

Кто использует гибкое управление проектами?

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

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

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

Белая книга: Как стать Agile-агентством

Технический документ: Гибкий маркетинг для творческих команд

Каковы четыре основные ценности Agile?

Манифест Agile определяет 4 основные ценности и 12 руководящих принципов, которые служат путеводной звездой для любой команды, применяющей методологию Agile.

Четыре основных ценности Agile:

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

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

2. Рабочее программное обеспечение, а не исчерпывающая документация

Как бы ни была важна документация, гораздо важнее рабочее программное обеспечение.Это значение дает разработчикам именно то, что им нужно для выполнения работы, не перегружая их.

3. Сотрудничество с клиентами по согласованию контрактов

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

4. Реагирование на изменения в соответствии с планом

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

Каковы 12 принципов Agile?

Методологии

Agile могут быть столь же разнообразными и уникальными, как и каждая отдельная команда, но 12 принципов Agile всегда должны определять ваши решения и разработку продукта.

Нашим высшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения (или того, что вы доставляете).
Приветствуем меняющиеся требования даже на поздней стадии разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.
Выполняйте проекты часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.
Члены координационной группы должны работать вместе ежедневно на протяжении всего проекта.
Создавайте проекты вокруг мотивированных людей.Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.
Личный разговор — самый действенный и действенный метод передачи информации между разными командами и внутри них.
Конечный продукт — главный показатель прогресса.
Гибкие процессы способствуют устойчивому развитию. Все заинтересованные стороны должны иметь возможность поддерживать постоянный темп на неопределенный срок.
Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
Простота — искусство максимизировать объем незавершенной работы — очень важна.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Лист данных: Шпаргалка по гибкому маркетингу

Вебинар: Что удерживает маркетологов от гибкости?

Ключевые компоненты гибкого управления проектами

Истории пользователей

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

Спринты

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

Stand-up встречи

Ежедневные встречи (до 10 минут), также известные как «ежедневные встречи по Скраму», — отличный способ убедиться, что все находятся на верном пути и информированы. Эти ежедневные взаимодействия известны как «встать», потому что участники должны оставаться стоя, что помогает сделать встречи короткими и конкретными.

Доска Agile

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

Задержка

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

Различные методологии Agile могут потребовать определенных командных ролей для соблюдения структуры или могут не требовать каких-либо определенных ролей. Хотя индивидуальная реализация Agile может не требовать всех этих ролей, вот несколько общих ролей, которые вы можете найти:

Скрам Мастер. Scrum Master гарантирует, что каждый спринт идет по графику и помогает устранить или решить любые проблемы или проблемы, которые могут возникнуть.Они защитники команды.
Владелец продукта. Роль product owner-а состоит в том, чтобы определять цели каждого спринта, управлять бэклогом команды и расставлять приоритеты, а также быть голосом клиента или внутренней заинтересованной стороны.
Члены команды. Люди в этой команде — это те, кто выполняет работу в каждом спринте. Эти команды, обычно состоящие из трех-семи человек, могут состоять из разных специальностей и сильных сторон, или они могут быть командами людей с одинаковыми ролями.
Заинтересованные стороны. Это только информационная роль. Заинтересованные стороны должны быть в курсе о продукте и целях спринта, иметь возможность проверять и утверждать работу во время спринта, а также предоставлять обратную связь во время ретроспективы спринта.

Каждая методология Agile имеет свой собственный уникальный список членов команды и ролей, и хотя названия могут меняться, существует несколько универсальных ролевых характеристик, которые должны иметь большинство структур Agile-команд:

Т-образный: Ценный член Agile-команды обладает обширными базовыми знаниями по своему предмету, но также обладает глубокими знаниями, опытом и способностями в одной (или нескольких) конкретных областях.
Кросс-функциональный: Межфункциональный Члены Agile-команды обладают навыками, выходящими за рамки их традиционных областей. Они могут знать некоторые основные принципы графического дизайна и анализа данных или даже немного HTML / CSS.
Адаптируемость: Если у них есть разноплановый набор навыков, они знают, как им пользоваться. Независимо от окружающей среды, их результат остается неизменным.
Любопытно: Часть оптимизации и повышения эффективности — это задавать правильные вопросы и бросать вызов тому, как всегда было, когда это уместно.
Предприниматель: Член Agile-команды — это тот, кто не ждет, чтобы ему сказали, что делать. Они готовы заполнять и разрабатывать кампании там, где они видят необходимость.
Ориентация на команду: Командные игроки ставят успех команды выше своей личной славы. Если все работают вовремя и хорошо синхронизируются, они видят в этом победу.
Стремление к совершенству: Одно из ключевых преимуществ Agile-проектов — быстрое выполнение качественной работы.Члены команды, стремящиеся к совершенству, не соглашаются на среднее. Они не зациклены на совершенстве, но всегда стремятся создавать свои лучшие работы.

Подробнее об Agile-командах

Каковы 6 шагов в методологии Agile?

Цель Agile — обеспечить более короткие циклы разработки и более частые выпуски продуктов, чем при традиционном каскадном управлении проектами. Эти более короткие временные рамки позволяют проектным группам более эффективно реагировать на изменения в потребностях клиента.

Как мы уже говорили, вы можете использовать несколько разных Agile-фреймворков — Scrum и Kanban — две из самых распространенных. Но каждая методология Agile будет следовать одному и тому же базовому процессу, который включает:

1. Планирование проекта

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

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

2. Создание дорожной карты продукта

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

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

3. Планирование выпуска

В традиционном управлении проектами водопада существует одна дата реализации, которая наступает после того, как весь проект был разработан. Однако при использовании Agile в вашем проекте используются более короткие циклы разработки (называемые спринтами) с функциями, выпускаемыми в конце каждого цикла.

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

4. Планирование спринта

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

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

5. Ежедневные выступления

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

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

6. Обзор и ретроспектива спринта

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

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

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

Подробнее: Workfront для управления проектами

Блог: Agile vs Waterfall

Переход на гибкое управление проектами

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

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

Если они изо всех сил пытаются бежать с той же скоростью, что и раньше, что может вызывать эти проблемы? Если команда не обновляет истории с их текущим статусом, были ли эти статусы четко определены?

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

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

Подробнее: Внедрение Agile в масштабе

Начать работу с гибким управлением проектами

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

Постигая agile: Постигая Agile. Ценности, принципы, методологии

Читать онлайн «Постигая Agile» автора Грин Дженнифер — RuLit

Эндрю Стеллман, «Постигая Agile» | by Aleksey Kalina | Kalina

Agile — это набор методов и методологий, которые помогают вашей команде эффективнее мыслить, работать и принимать решения.

Дженнифер Грин ★ Постигая Agile читать книгу онлайн бесплатно

Постигая Agile — Новости

Что такое Scrum

Подходит ли вам Scrum

Как внедрить

Распространенные ошибки

AGILE – гибкая система управления проектами

Метод Agile: определение и краткая история

Манифест Agile

Ключевые моменты в применении Agile

Популярные методы управления проектами

Метод Scrum

Метод Kanban

Плюсы и минусы Agile

Внедрение Agile

Заключение

Understanding Fake Agile

Понимание гибкого управления

Что такое гибкая разработка программного обеспечения?

До 2001 г. — Практика и методы развиваются независимо на основе опыта

2001 — Автор манифеста Agile

После 2001 г. — Принятие началось массово, стало мейнстримом

Понимание гибкой методологии — подробный обзор

Что такое Agile?

Что такое гибкая методология?

Связанное содержимое: гибкая разработка и тестирование программного обеспечения — различные методы

Гибкий процесс

1) Стратегическое совещание

2) Дорожная карта продукта

3) План выпуска

4) Планирование спринта

5) Ежедневная стойка

6) Обзор Sprints

7) Ретроспектива спринта

Завершение

Связанный контент: всестороннее сравнение методологий Agile, Scrum и Waterfall

Определение гибкой трансформации, понимание того, что значит быть гибкой, определение, что такое гибкая трансформация

Определение гибкой трансформации: что такое гибкая трансформация?

Определение гибкой трансформации

Agile Adoption vs Agile Transformation

Что такое гибкое внедрение и гибкая трансформация?

Agile Adoption

Agile Adoption

Трансформация Agile Lean

Что такое Agile Lean Transformation?

Понимание ценностей и принципов Agile

Введение

Agile Manifesto

Четыре ценности Agile

# 1) Лица и взаимодействия над процессами и инструментами

# 2) Рабочее программное обеспечение поверх полной документации

3. Сотрудничество с клиентами в ходе переговоров по контракту

4.Реагирование на изменения вместо следования плану

12 принципов Agile

Заключение

Agile Project Management — Руководство для новичков

Что такое Agile-управление проектами?

Кто использует гибкое управление проектами?

Каковы четыре основные ценности Agile?

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

2. Рабочее программное обеспечение, а не исчерпывающая документация

3. Сотрудничество с клиентами по согласованию контрактов

4. Реагирование на изменения в соответствии с планом

Каковы 12 принципов Agile?

Ключевые компоненты гибкого управления проектами

Истории пользователей

Спринты

Stand-up встречи

Доска Agile

Задержка

Каковы 6 шагов в методологии Agile?

1. Планирование проекта

2. Создание дорожной карты продукта

3. Планирование выпуска

4. Планирование спринта

5. Ежедневные выступления