Shutterstock

В 2021 году исполнилось 20 лет «Манифесту Agile». Подход зародился как бунт разработчиков против неповоротливых ИТ-корпораций. Разбираемся, что происходит с Agile сейчас и как его применяют в российских компаниях

1

Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.

Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели.

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

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

Термин Agile употребляют в двух основных значениях:

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

Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей.

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

Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.

Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.

2

Agile-манифест базируется на четырех главных ценностях:

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

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

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

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

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

3. Сотрудничество с заказчиком важнее соблюдения формальных условий.

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

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

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

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

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

Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:

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

Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.

3

Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер.

Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками.

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

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

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

Если они все же возникают, команда совместно решает, как оптимизировать процесс.

В отличие от scrum, kanban:

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

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

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

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

Пример доски Trello, созданной по принципам agile.

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

4

Где ломается гибкость (и заканчивается Agile) – Digital Enterprise

В последнее время в обсуждении одной модной темы часто натыкаюсь на непонимание (или неприятие?) одного и того же важного момента.

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

Здесь для краткости можно было бы написать «цифровая трансформация», «business agility» и т.п. Но мы же здесь все приличные люди ????

А момент вот какой.

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

Вытягивающая система, WIP-лимиты, всё, как написано в книжках про построение быстрого, равномерного потока. Большинство это знает/понимает. Те, кто работает в продуктовых командах так и работают… Или думают, что работают.

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

Два тезиса, к обсуждению которых обычно приходят такие дискуссии.

1. При условии, что мир недетерминированный (например, в терминах Cynefin) вы не построите равномерный поток, если на все (многие) задачи установлен чёткий срок решения. А значит уровень прогнозируемости будет очень плохим. Т.е никому, включая заказчика лучше не будет.Если у вас при увлечении дедлайнами поток таки быстрый и равномерный, то спешу обрадовать: вам не нужен поток. Вы живёте в детерминированном мире, где плюс-минус всё можно чётко рассчитать и распланировать. Все операции отнормированы; задачи могут быть и разнообразными, но по каждой всё чётко и понятно. С ресурсами всё тоже известно заранее. Вариативность? Не слышали. VUCA какая-то… Глупости всё это.

   Что тут можно сказать? Может быть, вам повезло. Но ущипните себя на всякий случай.

2. Дедлайны в заметной доле случаев не являются объективной потребностью. Это зачастую – механизм компенсации. Мы (и ИТ, и бизнес) не умеем управлять по-другому. Установка срока – это инструмент управления. Оказывается, можно без него (не без управления, а без дедлайна).

Последний тезис как-то совсем плохо заходит. Пожалуй, даже хуже чем идея о коллективной ответственности (продуктовой команды): ведь все же знают, что «коллективная ответственность – это безответственность» ©

В общем, то, что трансформация – это действительно серьёзно изменение (сдвиг парадигмы и вот это всё), ощущается даже на уровне разговоров. Разумеется, если разговоры о сути, а не про лозунги. И правдивость известной картинки подтверждается слишком часто.А как у вас?

Кризис Agile. Что делать?

m1rko 23 июн 2019 в 17:52 Ключевые моменты

• Многие организации устали от Agile
• Часть проблемы — в существовании большой коммерческой отрасли Agile
• Нужно вернуться к основам: простоте Манифеста и 12 принципов
• Примеры базовых и простых фреймворков: Heart of Agile и Modern Agile
• Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапия

«Agile agile Agile agile agile agile Agile agile». Мантра? Не совсем, хотя это может вызвать изменённое состояние сознания. «Ответ на главный вопрос жизни, вселенной и всего такого?» (Дуглас Адамс, «Путеводитель для путешествующих автостопом по галактике»). Может быть, смотря кого спросить. Это омонимы. Слова, которые выглядят и звучат одинаково, но имеют разные значения. Как это грамматически правильное предложение, состоящее из трёх совершенно разных слов: «Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo», Дмитрий Боргманн, «За пределами языка: путешествие слова и мысли» (фразу можно перевести так: «Буффальские бизоны, которых пугают буффальские бизоны, пугают других буффальских бизонов» — прим. пер.).

Риск чрезмерной омонимизации заключается в том, что слова начинают означать всё и вся, в то же время не означая ничего конкретного. Это психологический феномен, известный как «семантическое насыщение», форма ментальной усталости.

Как описывает психолог Леон Джеймс: Это называется реактивным торможением: когда нейрон срабатывает первый раз, то для второго импульса требуется больше энергии, и ещё больше в третий раз, и, наконец, в четвёртый раз он даже не ответит, если вы не подождёте несколько секунд… если повторять слово, значение продолжает повторяться, а затем становится невосприимчивым или более устойчивым к повторному вызову. Сегодня «Agile» означает всё и вся. Всё чаще это ничего не значит. Многие организации стали трудновосприимчивы или невосприимчивы к термину, как в предложении «Agile agile Agile agile agile agile Agile agile». И ситуация ещё хуже. «Когда слова теряют смысл, люди теряют свободу», — Конфуций. В некоторых организациях термин Agile стал означать «командно-контрольное управление». Кент Бек высказывает тревогу экспертов: Я был на конференции Agile Africa в ЮАР, ко мне кто-то подошёл и сказал: «Мы хотим заниматься разработкой программного обеспечения, но мы просто не можем выдержать все эти церемонии и штуки Agile. Мы просто хотим написать несколько программ». Я чуть не заплакал… как могло случиться, что мы вернулись на двадцать лет назад? (личная переписка, цитируется с разрешения). Это хороший и важный вопрос. И поднимает другие важные вопросы, например, «Что делать дальше?» Недавно Рон Джеффрис представил очень реальную возможность: Пришло время попробовать что-то новое, и вот оно: разработчики должны отказаться от Agile… я действительно начинаю думать, что никакие разработчики программного обеспечения не должны придерживаться никакого метода, который называется «Agile». Когда эти методы проявляются на местах, они слишком часто мешают, а не помогают хорошей разработке программного обеспечения. Что бы мы ни решили, давайте начнём с признания: многие из нас, активистов Agile, усугубляют ситуацию. Как Пого сказал Поркипайну: «Мы встретили врага — и оказалось, что это мы сами» (Уолтер Келли, «Пого»). Мартин Фаулер так выразился на конференции Agile Australia 2018: … Индустрия Agile (Agile Industrial Complex), навязывающая методы людям… это абсолютная пародия. Я собирался сказать «трагедия», но думаю, что «пародия» лучше подходит, потому что, в конце концов, в разработке программного обеспечения нет универсального подхода. Даже сторонники Agile говорят, что эта методология подходит не всем. Всё должна решать команда разработчиков. Это фундаментальный принцип Agile. Это даже означает, что если команда не хочет работать гибким способом, то Agile ей уже не подходит, а [отказ от Agile] — это для неё самый гибкий способ разработки, в каком-то странно искажённом мире логики. Итак, это первая проблема: индустрия Agile и навязывание одного самого лучшего способа работать. Это то, с чем мы должны бороться. Индустрия Agile. Тёмный Agile. Поддельный Agile. Зомби-Agile. И становится ещё хуже. Вот что говорит мой друг, организационный психолог: Agile — это вирус, распространяющийся по всему предприятию. И вы не должны удивляться растущему сопротивлению. Потому что это то, что антитела естественно делают, когда вторгается антиген. (личная переписка) Чего? Вот на что это похоже: вторжение. Потому что ваши «эксперты» по трансформации бизнеса на удивление мало знают об организационной динамике и психологии изменений. Один вопиющий пример: понимаете ли вы, какое сопротивление вы мгновенно создаёте — на нескольких уровнях — когда объявляете кого-то «мастером»? Особенно, когда единственное мастерство, которое у него есть, — это двухдневные курсы! (оттуда же) Ох. Я не посмел сказать ей, что «тренеров» тоже назначают после двухдневных курсов. Недавно я слышал, как один из этих «тренеров» спросил: «Для Agile нужен очень хороший менеджер проектов?» «Да, конечно, нужен первоклассный менеджер проектов, менеджер итераций, скрам-мастер, как бы вы его ни называли, который говорит тихо, но ходит с очень большой палкой!» Просто слёзы на глаза наворачиваются. Один из моих клиентов, изучив обширный ландшафт сертификации, открыл собственный сервис. Теперь десятки скрам-мастеров и владельцев продуктов с гордостью показывают его в своих кабинетах: Agile Yahoo. Что дальше?

Внутренняя политика — в мире Agile

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

В эпоху экспансии Agile — трансформации бизнеса — давайте сначала проясним, что мы подразумеваем под «Agile agile agile».

Чтобы сформулировать то, что должно быть очевидным, вот простой принцип: любой Agile должен явно или неявно ссылаться на четыре базовые ценности и 12 принципов Манифеста Agile. Он должен содержать «подсказки» Agile.

Мы должны вернуться к основам. Agile нуждается в перезагрузке. «Гибкие» команды должны регулярно пересматривать Манифест и 12 принципов: что это значит? Как у нас дела? Как продолжать двигаться в этом направлении? Частично это означает постоянно ограничивать собственные гибкие практики, чтобы они оставались гибкими. «Простота крайне необходима» (12 принципов) является «ключом» Agile, и мы обязаны следовать собственным принципам. Всё действительно просто, очень просто, говорит Дэйв Томас: Узнайте, где вы находитесь. Сделайте маленький шаг к цели. Скорректируйте своё понимание на основе того, что вы узнали. Повторите. Точно так же Heart of Agile Алистера Кокберна — это агностический подход, основанный на простой структуре: сотрудничать, доставлять, отражать и улучшать. Modern Agile Джошуа Кериевского основан на четырёх простых принципах: сделать людей удивительными, сделать безопасность обязательным условием, быстро экспериментировать и учиться и постоянно приносить пользу.

Внешняя политика — за пределами мира Agile

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

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

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

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

Более того, следует остерегаться собственной ассимиляции, подобно некогда грозным викингам, исчезнувшим в тумане легенд. Например, я принадлежу к растущему всемирному движению за интеграцию Agile с позитивной психологией, направленным самосовершенствованием (Appreciative Inquiry) и решение-ориентированной терапией (Solution Focused Brief Therapy), см. мою статью по решение-ориентированному Agile. В то же время, всё больше моих коллег вообще убирают слово «Agile», поскольку полностью ассимилировались в другой мир.

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

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

Это пример действия эффекта Медичи. Одноимённая книга Франса Йоханссона 2006 года сильно повлияла на моё мышление. Эффект Медичи, названный в честь итальянской семьи 14-го века, которая вызвала европейский Ренессанс, упоминает прорывное мышление и прорывные инновации, которые часто образуются из большого взрыва на стыке различных дисциплин, культур и отраслей промышленности. Я сразу уловил идею, потому что проводил эксперименты со взрывами ещё с набором юного химика в детстве. Эффект Медичи отвечает на вопрос, который мне иногда задают: почему я редко посещаю Agile-мероприятия? Сообщество Agile имеет важное значение. Но эффект Медичи заставил меня постоянно выходить за пределы того, что я уже знаю. И я быстро обнаружил, что для меня просветление и прорывы чаще вызваны взаимодействием с военными офицерами, религиозными лидерами, поэтами, философами, биологами и психологами. Большая часть работы в моей жизни стала соединением точек между этими связанными, иногда не связанными дисциплинами и экспериментированием с новыми и различными способами работы.

Вывод

Междисциплинарные исследования, принципы и практика — это будущее Agile. Именно поэтому настолько важно не терять связи с корнями, пока мы продолжаем использовать слово Agile. Пожалуйста, прекратите это «Agile Agile Agile бла-бла-бла».

Манифест agile все еще имеет вес?

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

Сам Манифест появился в то время, когда требовалось найти точки соприкосновения между Scrum, экстремальным программированием, Crystal Clear и другими методиками.

«Они начали понимать, что делают что-то похожее. Но на тот момент они очень сильно конкурировали друг с другом, по крайней мере в том, что касается идей, — говорит Ян Бьюкенен, главный инженер по решениям DevOps в Atlassian. — С учетом обстоятельств то, что они вообще смогли договориться о некоем наборе принципов, уже само по себе знаменательно».

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

Вот этот набор.

• Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим.
• Благодаря проделанной работе мы смогли осознать следующее.
• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования плану.
• То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Кент Бек	Джеймс Греннинг	Роберт С. Мартин
Майк Бидл	Джим Хайсмит	Стив Меллор
Эри ван Беннекум	Эндрю Хант	Кен Швабер
Алистер Кокберн	Рон Джефрис	Джефф Сазерленд
Уорд Каннингем	Джон Керн	Дейв Томас
Мартин Фаулер	Брайан Марик

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

Это все. С тех пор веб-сайт с Манифестом Agile практически не изменился (а может, не менялся вовсе), чего не скажешь о мире вокруг Agile.

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

Особая благодарность Аманде О'Каллаган, Иэну Бьюкенену, Дэну Радигану, Дэвиду Уэсту и Таннеру Уортэму за то, что поделились своими мыслями и опытом для этой статьи.

Эпоха Agile Как умные компании меняются и достигают результатов

Эпоха Agile Как умные компании меняются и достигают результатов. Стивен Деннинг

В эпоху стре­ми­тель­ных перемен тра­ди­ци­он­ные управ­лен­че­ские методы перестают работать. Именно по этой причине многие компании внедряют принципы Agile-управ­ле­ния. В 2001 году пионеры этого подхода опуб­ли­ко­ва­ли “Манифест гибкой разработки про­грамм­но­го обеспечения”.

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

Специалист по управлению Стивен Деннинг просто и доступно объясняет в своей книге истоки и принципы Agile-ме­недж­мен­та, разбирая множество конкретных примеров из биз­нес-прак­ти­ки.

• В 2003 году оперативная группа Сухопутных войск США не смогла победить плохо вооруженных иракских экс­тре­ми­стов: военная машина оказалась бессильной против гибкой сети боевиков.
• Как и вооруженные силы, в XXI веке бизнес начал осознавать, что гибкость – главное оружие в борьбе за выживание в мире, где царит неопре­де­лен­ность.
• Современные компании должны быстро и эффективно создавать ценность.
• Сложные проекты часто за­кан­чи­ва­ют­ся провалом из-за неспо­соб­но­сти бизнеса оперативно кор­рек­ти­ро­вать планы.
• Решить эту проблему можно с помощью методов Agile-ме­недж­мен­та, возникшего в сфере разработки ПО.
• Компании, принимающие философию Agile, уменьшают размер команд и сужают рамки проектов. Все внимание они уделяют клиенту.
• Agile-ко­ман­ды работают над конкретными небольшими задачами, которые они способны выполнить за короткое время.
• При­вер­жен­цам тра­ди­ци­он­ных методов управления бывает сложно принять новое мышление, необходимое для перестройки работы организации по принципам Agile.

• Армия США и Agile-ме­недж­мент
• “Способность адап­ти­ро­вать­ся к постоянным непред­ска­зу­е­мым переменам важнее тщательно под­го­тов­лен­ных планов”.
• “Оперативная группа Сухопутных войск США в Ираке в конце 2003 года была, возможно, самым опытным боевым под­раз­де­ле­ни­ем в мире”.
•  Выживет самый гибкий

“Мгновенная, налаженная, пер­со­на­ли­зи­ро­ван­ная ценность в большом масштабе пре­вра­ти­лась в новый стандарт кор­по­ра­тив­ной де­я­тель­но­сти. Сначала потребители ожидали ее, а затем стали требовать”.

“Agile-ма­ни­фест”

“На рынке произошла эпохальная перемена: продавец уступил место покупателю. Компания перестала быть устойчивым центром ком­мер­че­ской вселенной”.

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

Принципы Agile

1. “Закон мик­ро­ко­ман­ды”

• “Работа над ми­ни-бло­ка­ми”. 
•  “Маленькие кросс-функ­ци­о­наль­ные команды”. 
•  “Ограничение объема неза­вер­шен­ной работы”. 
•  “Ав­то­ном­ность команд”. 
•  Достижение стадии готовности
• “Бес­пре­рыв­ная работа
• “Ежедневные стендапы
• Полная про­зрач­ность
• Обратная связь от поль­зо­ва­те­лей на каждом цикле
• Ре­тро­спек­тив­ный обзор

1. “Закон мик­ро­ко­ман­ды под­ра­зу­ме­ва­ет образ мышления, а не конкретный набор ин­стру­мен­тов и процессов, которые можно перечислить в прак­ти­че­ском руководстве”.
2. 2. “Закон потребителя”
3. “Выплаты в виде опционов на акции стали нормой для ру­ко­во­ди­те­лей, акционерная стоимость – прописной истиной аме­ри­кан­ско­го капитализма”.

• “Определите целевую аудиторию”
•  “Постоянно экс­пе­ри­мен­ти­руй­те

• Со­труд­ни­чай­те со стартапами”.
•  “Повысьте гибкость продукта
• Создавайте инновации короткими циклами
• Проводите оценку
• Не бойтесь разо­ча­ро­вы­вать
• Поставляйте ценность быстрее
• Ин­ди­ви­ду­а­ли­зи­руй­те
• 3. “Закон сети”
• Приверженцы Agile рас­смат­ри­ва­ют свою организацию как гибкую и прозрачную сеть игроков, вза­и­мо­дей­ству­ю­щих друг с другом ради общей цели – приносить клиентам радость”.

“Главные решения основаны на компетенции, а не на власти – в противном случае сеть перестает быть сетью. Она вновь становится бюрократией”.

Четыре ценности и 12 принципов Agile-управления проектами

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

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

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

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

Что представляет собой Agile-методология управления проектами?

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

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

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

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

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

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

Каковы основные ценности и принципы, составляющие методологию Agile? Давайте рассмотрим их.

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

Сначала о ценностях Agile.

1. Люди и взаимодействие важнее процессов и инструментов То, что общение и межличностные отношения важнее, чем строгие процессы — краеугольный камень Agile-управления проектами. Agile рекомендует персонализированный подход к управлению проектами, когда команды ориентируются на постоянное общение, а не на жестко распланированный выпуск обновлений.
2. Работающий продукт важнее исчерпывающей документации Agile-команды не очень любят бумажную работу. Для управления данными, отчетами и обновлениями статуса они предпочитают использовать гибкие программные решения, а не традиционную документацию.
3. Сотрудничество с заказчиком важнее согласования условий контракта Agile-команды любят сотрудничество — включая регулярные обновления и обратную связь о том, как продвигается проект, от клиентов и заинтересованных сторон. Чего Agile-команды не любят, так это долгих согласований объемных контрактов.
4. Готовность к изменениям важнее следования первоначальному плану Эта ценность прежде всего характеризует Agile-управление проектами. Agile-команды чутко реагируют на изменения и успешно адаптируются к новым условиям и вызовам.

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

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

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

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения Главное для Agile-команды — удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени, а не заставляют заказчиков ждать финального результата в конце проекта.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения конкурентного преимущества заказчика В этом их преимущество перед традиционными командами, которым обычно не так легко управлять изменениями.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от двух недель до двух месяцев Вспомним, что Agile-команды ценят постоянное общение, а не жестко распланированный выпуск обновлений, которые могут слишком далеко отстоять друг от друга по времени, что может оказаться неприемлемым для клиентов. Команды Scrum, которые тоже работают по методологии Agile, разбивают свою работу на периоды от одной до четырех недель, известные, как спринты.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе Сотрудничество — краеугольный камень Agile, причем имеется в виду не только сотрудничество между членами команды, но и сотрудничество с заинтересованными сторонами, разработчиками, клиентами и другими партнерами.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте им условия, обеспечьте поддержку — и полностью им доверьтесьAgile-команды успешны, потому что в них работают только те люди, которые необходимы для проекта. Если участники Agile-команды получат поддержку, возможность работать вместе и инструменты, необходимые для работы, все остальное приложится.
6. Непосредственное общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды Все мы знаем, что главное в управлении проектами — личное сотрудничество. Этот принцип применим и во времена «новой нормы», при гибридных и удаленных моделях работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, а в ключевых точках проекта возможны и личные встречи команд.
7. Работающий продукт — основной показатель прогресса Смысл принципа, который называет работающий продукт основным показателем прогресса, в том, что главная цель команды всегда остается одна — предоставить клиенту как можно более высококачественный результат. Когда клиент доволен, это и есть главный показатель успеха проекта.
8. Agile помогает наладить устойчивый процесс разработки. Инвесторы, разработчики и пользователи должны иметь возможность бесконечно поддерживать постоянный ритм Многие команды поначалу показывают бурный прогресс, который не получается сохранить до конца проекта.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта Agile не работает по принципу «раз — и готово». Каждый новый проект — это возможность для инноваций, а не для повтора одних и тех же идей.
10. Простота как искусство сократить до минимума лишнюю работу крайне необходима Команды Agile не занимаются переусложнением — они просто соблюдают проектные требования и хорошо выполняют свою работу, а затем переходят к следующему проекту.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд Лучшие команды — это те команды, у которых есть лидер, предоставляющий им свободу самовыражения. Микроменеджмент редко делает команды лучше или продуктивнее, и Agile-команды — отличный пример того, чего можно добиться без микроменеджмента.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы Непрерывное совершенствование — сама суть Agile, и регулярные проверки эффективности команды в целом могут помочь избавиться от вредных привычек и добиваться бо́льшего.

Как внедрить цености и принципы Agile в ваше проектное управление

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

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

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

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

ПО Wrike поддержит вашу Agile-команду на пути к успеху. Загрузите бесплатную двухнедельную пробную версию прямо сейчас!

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

Настройки файлов cookie