Можно утверждать что agile идеально подходит для

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

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

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

Agile как религия

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

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

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

Когда работает Agile

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

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

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

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

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

Как именно работает 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 (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако …

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

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

→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT

Чем Agile отличается от методологий

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

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

Метод — это способ достижения какой-либо цели.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

• Например, в гибкую методологию XP (экстремальное программирование) входят такие приемы как парное программирование и игра в планирование, которые указывают вполне конкретные алгоритмы действий.
• И даже гибкий фреймворк Scrum, который по определению «не является процессом, техникой или методом», все же предписывает применять несколько ролей, мероприятий и артефактов. Каждый элемент Скрама является обязательным для его успешного использования.

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

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2012), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.

Ценности Agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. люди,
2. работающий продукт,
3. сотрудничество с заказчиком,
4. готовность к изменениям.

Посмотрим, зачем нужны эти ценности Agile.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile — философия, Scrum — ее реализация

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

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

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

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

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

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Agile сложнее, чем 4 ценности

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

Во-вторых, в статье «Что такое Agile-подход и зачем он нужен бизнесу» вы найдете подробное изложение 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведу их здесь кратко:

1. Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
2. Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
3. Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
4. Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
5. Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
6. Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.

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

Кратко о том, что входит в Agile сегодня

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

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

Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.

Канбан отличается от Скрама по многим параметрам, в частности:

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

Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:

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

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

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

Область применения Agile

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

Судя по числу участников исследования Agile в России 2019, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

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

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

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

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Книги об Agile по-русски

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

Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban.

Авторы: Роб Коул, Эдвард Скотчер

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

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

Автор: Стивен Деннинг

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

Scrum. Революционный метод управления проектами.

Автор: Джефф Сазерленд

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

Scrum и Kanban: выжимаем максимум.

Авторы: Хенрик Книберг, Маттиас Скарин

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

Резюме. Место Agile среди родственных управленческих подходов

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

Это слово сейчас имеет два основных значения:

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

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.

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

1. сократить время вывода продуктов на рынок / время их поставки потребителю;
2. ускорить принятие решений на уровне команд и выше.

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

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

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

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

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

Agile-подход к управлению проектами

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

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

Концепция Agile-подхода к управлению проектами

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

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

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

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

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

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

Преимущества Agile-подхода к управлению проектами

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

Некоторые из наиболее очевидных преимуществ Agile-подхода:

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

Недостатки Agile-подхода к управлению проектами

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

Некоторые возможные недостатки Agile-подхода:

• Руководителям и клиентам может быть сложно утверждать и поддерживать проекты, для которых не составлены точные графики и сметы, а также не определен точный объем.
• Руководителям компаний трудно составлять долговременные планы, когда не ясно, будут ли ресурсы свободны для следующего проекта или задействованы в текущем Agile-проекте.
• Компании с ориентацией на рабочие процессы, с высоким уровнем бюрократии и большим документооборотом, скорее всего, будут отказываться от Agile-подхода, пока не внесут изменения в организационную структуру и корпоративную культуру.
• Бывает сложно оценивать ход выполнения из-за использования многочисленных спринтов, которые могут настраиваться и выполняться как отдельные мини-проекты.
• Выполнение Agile-проектов часто отнимает больше времени и сил, поскольку многие методолoгии требуют проведения ежедневных совещаний и постоянного взаимодействия с клиентом.
• Длительность и объем проекта могут выйти из-под контроля из-за отсутствия четких границ, которые не задаются изначально.
• Некоторые крупные и длительные проекты трудно разделить на краткие спринты.
• Поскольку упор делается на отчетные материалы, а не документацию, сокращаются объемы бумажной работы. Хотя иногда это можно считать достоинством, часто получается так, что участники команды не записывают информацию, которая могла бы помочь при выполнении следующих проектов.

Как внедрить Agile-подход к управлению проектами

1. Узнайте об Agile-процессах и концепциях. Уделите время сбору информации об Agile-методологиях, их структуре, принципах и основных концепциях. Затем поделитесь этим знанием с командой, клиентами и всеми участниками проекта.
2. Выясните, когда этот подход нельзя использовать. Прежде чем приступать к работе над новым проектом, стоит рассмотреть достоинства и недостатки Agile-методологии и решить, подойдет ли она в данном случае. Agile-подход — не панацея, и попытка применить его при выполнении неподходящего проекта может привести к большим проблемам.
3. Устраните препятствия. Своевременно информируйте сотрудников, постарайтесь сплотить команду и укрепить совместную работу, позаботьтесь, чтобы у вас было подходящее решение для управления Agile-проектами.
4. Заручитесь поддержкой руководства. Даже самые лучшие инструменты для управления Agile-проектами ничем вам не помогут, если руководители компании не будут с вами на одной стороне. Руководители должны поддерживать принципы Agile-управления и формировать Agile-среду.
5. Начните с малого. Очень важно начинать с небольших проектов. Добейтесь успеха, а затем уже используйте свои наработки с большим числом команд и при выполнении проектов большего объема.
6. Вносите изменения и корректировки. Если после выполнения первого Agile-проекта что-то пошло не так, можно попробовать другую Agile-методологию или внести исправления.

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

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

Что такое Agile, �� — ценности, принципы и Agile–манифест + кейсы от компаний, которые применяют Agile

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

Редактировать

Что такое Agile?

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

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

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

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

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

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

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

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

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

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

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

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

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

Редактировать

Founder, Executive Partner
Переквалификация в IT
Станьте руководителем Digital–продукта в Enterprise
Начать обучение →

Зачем нужен Agile?

Существует множество преимуществ agile–подхода, включая:

• повышенная гибкость
• повышение эффективности и производительности
• повышение качества работы
• расширение сотрудничества между командами

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

Особенно хорошо Agile показывает себя в условиях работы в условиях высокой неопределенности.

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

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

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

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

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

Редактировать

Founder, Executive Partner

Как работать по Agile?

Сократите количество узкоспециализированных специалистов, начните искать и развивать T-Shaped специалистов. Начните работать кроссфункциональными командами. Сократите количество «компонентных» команд (работающих с отдельными частями продукта) и повысьте количество функциональных команд (которые разрабатывают продукт end-to-end).

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

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

Чтобы работать в Agile, вам необходимо:

• Планировать свою работу на короткие циклы (спринты)
• Работать кросс–функционально с членами вашей команды
• Использовать быстрые циклы обратной связи для принятия решений

Редактировать

Founder, Executive Partner

Без чего Agile не будет работать?

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

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

Но какой смысл в наличии процесса, если вы не знаете, что это такое?

Вот четыре вещи, без которых Agile не будет работать:

1. Видение вашего продукта, включая особенности и функциональность
2. План того, как ваша команда будет реализовывать это видение.
3. Коммуникация между всеми, кто участвует в создании продукта (например, клиентами, менеджерами).
4. Способ измерения результатов

Agile — невероятно мощная методология, но и у нее есть свои ограничения.

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

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

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

Agile не будет работать без четкого видения продукта и способности донести это видение до команды.

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

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

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

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

Редактировать

Founder, Executive Partner

С чего начать внедрение Agile в компании?

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

Первым шагом во внедрении agile является оценка текущей ситуации. Какие процессы у вас существуют? Хорошо ли они работают? Не сломаны ли они?

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

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

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

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

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

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

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

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

Редактировать

Founder, Executive Partner

Сколько стоит внедрение Agile?

Хорошие консультанты Agile стоят дорого. Давайте примерно рассчитаем: Допустим, 1 команда живет под наблюдением и помощью консультанта Agile хотя бы пол года (за это время приходит понимание, в нужную ли сторону идет команда), доукомплектовываем команду хорошими скрам–мастерами. В сумме получится от 1.000.000 руб. минимум. В среднем около 2.500.000.

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

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

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

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

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

В среднем, компании, внедряющие Agile, получают возврат инвестиций (ROI) около 300%. Именно так — они в три раза увеличивают свои инвестиции менее чем за год.

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

Редактировать

Founder, Executive Partner

Разница между Agile Coach и Scrum Master?

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

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

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

Разница между Agile–коучем и Scrum–мастером зависит от компании.

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

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

Редактировать

Founder, Executive Partner

Примеры того, что вы работаете в соответствии с принципами Agile

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

• Собираете обратную связь у клиента и пользователей на каждом этапе работы над продуктом.
• Разбиваете работу над проектом на задачи и подзадачи.
• Меняете нагрузку на членов команды, если кто–то не справляется, разбираетесь в причинах и думаете, как сделать лучше в следующий раз.
• Показываете часть продукта клиенту, после каждого этапа работы. Один этап длится 2-3 недели.
• Расставляете приоритеты. То, что продвинет проект вперед, делаете первым. То, что не так важно для прогресса подождет до завтра.
• Меняете продукт на любом этапе, если изменился бизнес клиента, требования рынка или он не решает задачи пользователей.

Редактировать

Founder, Executive Partner

Примеры не Agile — когда вы и ваши процессы не соответствуют принципам и методам Agile

Если вы узнаете в этом себя и свою команду — то вам стоит задуматься о том, как внедрение Agile может помочь вам повысить производительность и увеличить Time to Market. Вы далеки от agile, если вы:

• Собираете требования клиента на старте проекта и следуете им до его завершения.
• Работаете по плану: три недели на дизайн, месяц на программирование и верстку, десять дней на тестирование.
• Заранее планируете нагрузку на членов команды. Объем задач определяете на старте проекта и не отходите от него. Если кто–то не успевает, сдвигаете сроки всего проекта или подгоняете команду.
• Показываете клиенту продукт, когда все работы по нему завершены. Или демонстрируете результат после каждого большого этапа: сделали дизайн — показали, сделали верстку — показали.
• Работаете по плану, который согласовали с клиентом на старте проекта. Выпускаете продукт в том виде, в каком он был в самом начале согласован с заказчиком.

Редактировать

Founder, Executive Partner

История создания Agile-манифеста

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

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

Команда использовала форму Agile–метода под названием «Экстремальное программирование» (XP), которая показала свою эффективность в работе. Они решили кодифицировать этот метод в набор принципов, которые можно было бы применять в разных отраслях и контекстах. Результатом стал Манифест Agile, который был опубликован в Интернете в 2001 году.

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

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

Метод Scrum появился в 1995 году. Он основан на отказе от долговременного планирования. Вместо этого Скрам предлагает делить разработку на короткие этапы. Каждый этап заканчивается экспресс–оценкой и внесением правок. Важное место в Скрам отводят расстановке приоритетов.

Метод экстремального программирования — XP возник в 1996-1999 году. В этом методе работа над продуктом строится на пользовательских историях — User Stories. Это сценарии, которые пользователь проходит в продукте. Например, загрузить фотографию на аватар или оформить заказ товара в корзине. В XP зародились и продуктовые релизы. Это результат каждого этапа работы над продуктом.

У каждого из этих методов есть свои авторы — разработчики и инженеры. Двадцать лет назад они собрались на горнолыжном курорте Сноуберд в США.

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

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

Редактировать

Founder, Executive Partner

Что такое Agile Manifesto простыми словами

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

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

Манифест построен вокруг четырех ценностей:

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

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

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

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

Цель разработки — принести пользу клиентам. Каждая задача дает ценность. Нет разработке ради разработки.

Редактировать

Founder, Executive Partner

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

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

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

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

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

В Scrum–команду входит Product owner (владелец продукта) и Скрам–мастер. Product owner выступает в роли руководителя, он общается с заказчиком, ставит задачи команде. Scrum master планирует и организует совещания, он отвечает за соблюдение правил Скрам, устраняет препятствия, которые мешают команде работать.

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

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

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

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

Пример: есть приложение онлайн–стилист. Нужно добавить к нему функционал онлайн–шопинга со стилистом.

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

Метод Lean помогает разобраться, в каком месте компания теряет ресурсы, время и деньги.

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

Пример: при работе над приложением онлайн–стилист команда потратила время на дизайн кнопок. Для пользователей было важнее наладить поиск одежды по брендовым магазинам.

Редактировать

Founder, Executive Partner

Когда нужен Agile?

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

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

Agile помогает стартапам быстро получить рабочую версию продукта или MVP (минимальный жизнеспособный продукт). Это не гарантирует, что вы не провалитесь через год. Но гарантирует, что этот год вы потратите с умом и получите опыт.

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

Редактировать

Founder, Executive Partner

Как Agile планирование помогает в условиях неопределенности?

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

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

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

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

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

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

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

Agile–планирование — это методология, которая особенно хорошо подходит для ситуаций крайней неопределенности.

Agile–планирование в условиях крайней неопределенности включает в себя следующие шаги:

1. Определить все возможные риски и возможности, связанные с проектом.
2. Для каждого риска или возможности определить вероятность его возникновения и его влияние, если он возникнет.
3. Присвоить каждому риску или возможности значение, основанное на их вероятности и воздействии, используя один из нескольких методов (например, средневзвешенное значение 1/3).
4. Используя средневзвешенное значение, определите общую стоимость каждого риска или возможности. Это общее значение представляет собой ожидаемое влияние на успех проекта и должно использоваться вместо единой точечной оценки при принятии решений о распределении ресурсов для оценки объема, графика и стоимости проекта.

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

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

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