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

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

Agile как религия

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

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

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

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

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

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

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

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

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

Как именно работает Agile

Ценности

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

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

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

Принципы

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

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

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

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

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

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

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

Насущные вопросы

Возможно ли построить 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 прибыль