Agile методология в менеджменте: Agile: как и когда применять этот метод — Независимое театральное объединение "Зрительские симпатии"

Содержание

Agile: как и когда применять этот метод

Agile: как и когда применять этот метод | Большие Идеи Операционное управление

Сергей Карпов

29 марта 2016

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

Agile, появившийся как метод разработки ПО в небольших командах лет 10—15 назад, сегодня становится новой культурой управления большими компаниями. Благодаря недавнему выступлению Германа Грефа термин Agile входит в лексикон всех современных российских менеджеров.

Что же такое Agile и почему этот метод называют чуть ли не единственно правильным?

Существует классический подход к созданию продуктов и сервисов, характерный в первую очередь для ИТ-индустрии.

Этот подход называется каскадная, или итеративная методология разработки. В английской терминологии такой подход называют waterfall development (от англ. — водопад). Почему его называют водопадом? Потому что при такой схеме разработки, однажды утвердив план программного продукта, вы не сможете этот план остановить или изменить до его создания.

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

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

Читайте материал по теме: Иерархия и Сеть: две структуры, одна организация

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

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

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

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

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

Передовой бизнес базируется на трех китах: опыт и знания в индустрии (в которой работает бизнес), разработка продуктов и сервисов по методологии Agile и самое главное — инновационная культура.

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

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

советуем прочитать

Юмор – лучший информатор

Стюарт Томас

Венчурные капиталисты: что для них важно на самом деле

Отдать бесплатно — и получить выгоду

Брайс Дэвид, Джеффри Дайер, Хэтч Найл

98% читателей HBR в восторге от этой статьи

Мартин Стив

Войдите на сайт, чтобы читать полную версию статьи

советуем прочитать

Чтобы быть увереннее в себе, обратитесь к своему прошлому

Мюриэл Уилкинс, Эми Джен Су

Фейсбучные споры — последнее дело

Антон Ходарев

Бизнес после эпохи роста

Спет Густав Джеймс

Руководители тоже смертны и должны с этим смириться

Манфред Кетс де Врис

Agile без идеализма.

Когда и как именно работает гибкий менеджмент. Политэкономический памфлет / Хабр

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

Цель данной статьи — поставить идеалистичное отношение к Agile с ног на голову — материалистически объяснить, когда Agile работает, как именно работают те или иные ценности и принципы; какой Agile идеалистический, а какой материалистический.

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

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

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

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

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

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

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

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

Ценности

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

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

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

Ценность Agile	Важнее чем	Прежняя ценность
Люди и их взаимодействие	Важнее чем	Процессы и инструменты
Работающий продукт	Важнее чем	Исчерпывающей документации
Взаимодействие с заказчиком	Важнее чем	Обсуждения контракта
Реагировать на изменения	Важнее чем	Следовать плану

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

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

Принципы

Конкурентное преимущество или увеличение цены продукта

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

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

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

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

Вовлечённость

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

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

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

Отчуждение проявляется в том что работник делает товар, которым не воспользуется, прибыль от которого он не получит. Третий способ мотивирования к двум описанным выше — материальный, И речь не совсем о заработной плате. Мы все живём в условиях рыночных товарно-денежных отношений и не можем быть от них совершенно свободными. Мотивация работника будет выше, когда премию свою он начнёт получать не за сроки и за объёмы, а за ту пользу, что заказчику принёс продукт. Что-бы так происходило, должен быть или премиальный фонд пропорциональный прибыли, или свопы. Такая мотивация может действенно снижать отчуждённость труда. Более скромный, но не менее действенный способ снизить отчуждённость работника — дать ему бесплатно пользоваться продуктом которым он занимается.

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

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

Отчуждение меньше, а вовлечённость больше там, где меньше работы посвящённой частной собственности, когда абсолютно все результаты работы присваиваются собственниками, материально и юридически. Между тем, для разработчиков есть особая форма предмета труда, где они действительно реализуются, понимая свою пользу — open source.

Возможно ли построить Agile снизу?

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

И кто-то скажет — «Неправда! У нас итерации, дейли митинги и все дела». Всё дело в профессии инженера, вступающей в антагонизм с управленцем. Инженер вынужден прибегать к планированию, так как сама природа производимого продукта такова, что такое планирование необходимо. Системы сложные, имеют различные составные части, на них накладываются различные ограничения. Однако если вашим заказчикам не нужен продукт с увеличенной потребительной стоимостью, задачи вы получаете от аналитика, а не от Product Owner’а, если ваша ответственность ограничена задачами, которые вам ставят — у вас нет ни Scrum, ни XP, ни Agile в принципе.

Является ли Enterprise ПО, виртуальным товаром?

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

Подходит ли Kanban для виртуальных продуктов?

Канбан является незрелым компромиссом между Aglile и Waterfall. Гибкие методологии стремятся не к порядку, а к повышению стоимости продукта, поэтому наиболее эффективны, когда их форма производства не органическая, а гетерогенная.

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

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

Возможно ли ускорить выход продукта, внедрив Agile?

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

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

Можно ли применять Agile вместо водопада для заказной разработки ПО (товаров)?

Можно, но это нецелесообразно. Производство товара подразумевает, что авансирующий капитал, понимает какую именно нужно вложить в товар работу. Гибкие методологии требуют траты ресурсов, на то, чтобы оценить направление работы и, если нужно, скорректировать. В итоге, если продукт разрабатывается под одного потребителя и не будет изменяться, применять Agile, следовать принципам и практикам SOLID, GRASP, DDD, TDD, KISS экономически нецелесообразно.

Agile-команда. Какая она должна быть?

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

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

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

Head First Agile. Гибкое управление проектами | Стиллмен Эндрю, Грин Дженифер | ISBN 978-5-4461-0992-0
Адаптивный код: гибкое кодирование с помощью паттернов проектирования и принципов SOLID | Холл Гэри Маклин | ISBN 978-5-9909445-9-6
Четвертая промышленная революция | Шваб Клаус | ISBN 978-5-699-90556-0
Четвертая промышленная революция | Блуммарт Тью, Ван ден Брук Стефан, Колтоф Эрик | ISBN 978-5-9614-1536-0
Капитал: критика политической экономии. Том I | Карл Маркс | ISBN 978-5-699-95085-0
Почему программное обеспечение не всегда товар и откуда в IT прибыль
Экономическо-философские рукописи 1844 года | Карл Маркс

Гибкое управление проектами — руководство для начинающих

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

Но когда вы начнете исследовать, какая методология подходит именно вам, вы, вероятно, снова и снова увидите одно конкретное слово:

Agile.

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

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

Что такое гибкое управление проектами?

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

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

Простой в использовании, мощный, когда вам это нужно

Teamwork.com, которому доверяют 20 000 компаний и 6 000 агентств, позволяет легко управлять, отслеживать и настраивать несколько сложных проектов. Начните с бесплатной 30-дневной пробной версии.

Попробуйте Teamwork.com бесплатно

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

Но единой универсальной «гибкой методологии» не существует. Так откуда они все взялись?

Краткая история Agile

Большинство современных agile-методов управления проектами берут свое начало в разработке программного обеспечения. Еще в 1990-х команда разработчиков программного обеспечения обнаружила, что высокоструктурированные «тяжеловесные» традиционные методологии управления проектами (например, Waterfall) просто не подходят, когда дело доходит до того, как им нужно работать.

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

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

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

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

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

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

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

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

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

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

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

4 основных ценности Agile

Как упоминалось выше, самые ранние agile-методы управления проектами были сосредоточены на программном обеспечении, и Agile Manifesto был создан разработчиками программного обеспечения. Таким образом, вы увидите это слово и другие связанные с ним термины, такие как «разработчики» и «клиенты», повсюду.

Но не чувствуйте себя ограниченным этим.

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

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

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

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

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

12 принципов гибкого управления проектами

Согласно Agile Manifesto, существует 12 ключевых принципов гибкого управления проектами. По словам самого манифеста, это:

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

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

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

Каковы преимущества гибкого управления проектами?

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

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

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

Больше приспособляемости (и меньше рисков)

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

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

Повышение удовлетворенности клиентов

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

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

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

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

Более счастливые команды

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

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

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

Как стать гибкими

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

Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.

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

Итак, если вам интересно, как стать гибким, вот что вам нужно иметь в виду.

Привлеките к работе нужных людей

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

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

Как Teamwork.com использует Teamwork. com: рекрутинг и адаптация

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

Узнать больше

И привлечь к работе нужных людей

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

Организационная культура, противоречащая ценностям Agile
Общее сопротивление организации изменениям
Неадекватная управленческая поддержка и спонсорство

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

Получить сертификацию

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

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

Используйте правильные инструменты управления проектами

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

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

Agile и Scrum: в чем разница?

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

Scrum, несомненно, является одной из самых популярных гибких методологий, используемых сегодня: колоссальные 72% респондентов в последнем отчете State of Agile заявили, что они используют «Scrum или гибрид, включающий Scrum».

Как и другие agile-методологии управления проектами, Scrum придерживается основных agile-ценностей и принципов (итераций, реакции на изменения и всего того хорошего, о чем говорилось выше).

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

Agile-управление проектами с помощью Scrum

В Scrum-команде есть три основные роли:

Владелец продукта

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

Команда разработчиков

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

Scrum Master

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

Вот примерное представление о том, как это работает:

Все, что нужно сделать команде (например, все, что необходимо для продукта), перечисляется в бэклоге и ранжируется владельцем продукта в порядке приоритета. Задача Владельца Продукта состоит в том, чтобы оптимизировать работу Команды Разработки, следя за тем, чтобы Бэклог был лучшим из возможных (то есть четким, доступным и организованным для достижения успеха).
Scrum использует спринты фиксированной продолжительности (обычно несколько недель, всегда меньше месяца). У каждого спринта есть предопределенная цель спринта. Элементы из Бэклога идентифицируются и обрабатываются как часть каждого Спринта.
Перед тем, как начнется спринт, вам нужно выполнить планирование спринта, чтобы выяснить, какова будет ваша цель спринта и как вы собираетесь ее достичь.
После начала Спринта Команда Разработки проводит короткую ежедневную встречу, называемую Ежедневным Скрамом, чтобы сообщить о прогрессе за предыдущий день, о том, на чем они будут сосредоточены сегодня, и обо всех выявленных рисках.
В конце каждого Спринта команда проводит Обзор Спринта (что-то вроде итогового собрания для Спринта), чтобы оценить свою работу и сообщить о следующем раунде Планирования Спринта.
Повторять, повторять, повторять.

Какая гибкая методология мне подходит?

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