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

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

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

Agile это религия

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

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

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

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

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

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

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

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

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

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

Как работают ценности Agile

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

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

Если рассматривать ценности кратко, то получается следующая картина:

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

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

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

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

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

Основные принципы Agile, влияющие на конкурентное преимущество такие:

Мотивация и вовлеченность

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

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

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

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

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

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

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

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

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

Если попытаться подытожить, то получится вот такая картина:

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

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

Кто-то конечно же скажет, «Но у нас же итерации, дейли митинги и все дела. Что значит у нас не Agile?».

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

Enterprise ПО может быть виртуальным товаром?

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

Подходит ли Kanban?

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

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

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

Ускорить выход продукта, внедрив Agile

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

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

Agile вместо водопада для заказной разработки ПО

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

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

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

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