{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

На смерть Agile

Вы, наверное, уже слышали о методологии (или если вам будет угодно, философии) Agile и о том, что это единственный способ эффективно разрабатывать программное обеспечение. Но как же так получается, что выдающиеся компании и продукты создаются без Agile? Почему в SpaceX нет scrum-мастеров, а в Apple нет специалистов по Agile-коучингу? Молодые успешные стартапы не кичатся тем, что у них свой уникальный подход к гибким методологиям разработки, который дает им уникальное преимущество в скорости разработки. С другой стороны, компаниям среднего уровня и крупным аутсорсерам продают Agile-трансформацию, а некоторые региональные банки кичатся своими Agile-методологиями. Мы, те, кто приносит ценность пользователям, уже поняли, что Agile не является серебряной пулей. Но чем же он является?

Agile — это секулярная религия.

  • Есть манифест наших великих предков. (вспомните несколько пунктов из него? Вот и с заповедями так же…)
  • Есть обязательные ритуалы, которые нужно выполнять.
  • Есть жрецы.
  • Существуют различные церкви, которые сертифицируют жрецов (например, ICAgile, Scrum Alliance и т.д.).

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

Религия начинается из благих побуждений

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

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

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

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

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

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

Да, терапия принятия ответственности требует не менее 10 сессий (в реальной жизни — минимум полгода), чтобы изменить отношение человека к ответственности, и проводится специалистом, который учился годы с полного согласия и желания пациента. Однако Scrum мастер и ритуалы Agile быстро научат людей принимать ответственность! Кроме того, они мотивируют, поскольку мы знаем, что даже наличие акций не всегда способствует мотивации работать на благо компании. А в данном случае человек сам оценил задачу и сам выбрал метод ее решения и теперь уж точно он кровью и плотью связан с компанией и ее целями.

Но если все так почему так много людей на это покупаются?

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

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

Лично мне никогда не требовалось НАСТОЛЬКО много внимания, поэтому я хочу просто ставить задачи и чтобы они были выполнены. Однако я осознаю, что мой стиль управления токсичный, потому что я не даю переносить задачу из спринта в спринт с умным видом people-focused лидера.

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

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

Но ведь Аджайл это в первую очередь модель коммуникации, а вопрос коммуникации все равно встанет с ростом коллектива

В данной модели церковные деятели отвечают за менеджмент, и каждому менеджеру приписывается “agile-священник”. К недовольным такому соседству отправляют инквизицию. Цель заключается в служении закону божьему (аджайлу), а не в том чтобы делать продукт.

Люди найдут способ общаться между собой, если:

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

Но ведь аджайл ставит впереди всего пользователей и продукт

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

Командам нужен фасилитатор чтобы коммуницировать эффективно.

Фасилитатор это независимый человек. Не из компании. Человек работающий в компании уже не может быть фасилитатором, потому что у него есть интересы в этой компании. Но я бы задумался зачем нужен фасилитатор в команде. У вас бракоразводный процесс? Корпоративный конфликт? Кто-то взял кого-то в заложники? Если люди не могут делать свою ежедневную работу без фасилитации — единственная фасилитация которая нужна это фасилитация переговоров об увольнении.

А как же самоорганизация?

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

Причем здесь смерть?

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

А как нам тогда жить, скажи отец?

Это каждый пусть решает сам. Но есть несколько общих рекомендаций.

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

Подписывайтесь на мой телеграм-канал @dailykuznetsov. Я публикую в нем короткие заметки о том, как веду международный бизнес, а также о цифровых продуктах и финансах.

0
60 комментариев
Написать комментарий...
Santiago
Если бы ваши сотрудники могли бы эффективно самоорганизоваться они бы на вас не работали, а открыли бы свой бизнес.

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

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

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

Ответить
Развернуть ветку
boomzilla

Вы плохо искали исследования. The Standish Group каждый год публикуют отчет о статистике успешных ИТ проектов. Картина примерно следующая.

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

Да нормально искал. Тут я думаю тоже методология не выдерживает никакой критики. Но где я, а где сраная advisory group которая делит всю разработку на agile и waterfall. ))

Ответить
Развернуть ветку
Eozvarit

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

Ответить
Развернуть ветку
5 комментариев
Тимофей Нецветаев

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

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

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

Ответить
Развернуть ветку
Eozvarit

Какой-то ментальный фруктовый салат фрустрированного разраба, которого попросили быть менеджером.
Для начала аджайл - это не метология и даже не фреймворк, а набор эмпирических принципов. Причем самый потенциально холиварный принцип - продукт важнее документации - поддержат не глядя большинство разрабов. Собственно "вам шашечки или ехать?" это основной принцип взаимоотношения исполнителей со стейкхолдерами в России.
Фреймворком, т.е. набором ритуалов, является Scrum. И самое важное в Scrum не дэйли, не демо и не ретро, а наличие обособленной продуктовой команды, целиком закрывающей продукт. А где вы это видели в целиком линейной российской энтерпрайз иерархии, где даже внедрение матричной структуры является прорывом? Где вы видели в России Продакт Оунера, который может отказать руководителям подразделений раздуть скоуп, вставить в продукт реализацию ничем необоснованных требований или просто забрать полкоманды на срочный проект для акционера?
У вас же аджайл, мальчики, быстро все запилите, я вон в 2004 году вдвоем с другом автоматизацию лакокрасочной фабрики сделал!

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

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

"У вас же аджайл, мальчики, быстро все запилите, я вон в 2004 году вдвоем с другом автоматизацию лакокрасочной фабрики сделал!" — это прямо мои слова

Ответить
Развернуть ветку
Борис Еремихин

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

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

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

Ответить
Развернуть ветку
2 комментария
123

пффф, точно нет

Ответить
Развернуть ветку
2 комментария
Buddha

RUP и наследник его DAD - более приближены к реалиям производства, «промышленной» разработки, на мой взгляд.

Agile (Scrum) в чистом виде подходит для маленьких команд на этапе MVP, проверки гипотез - там ок. Каждому блюду - свой прибор. Хотя я всегда ратовал за более последовательный подход к разработке даже с экстремально-маленькими командами.

Ответить
Развернуть ветку
Eozvarit

Аджайл - это ценности и принципы, Scrum - это фреймворк, а методолгии это XP и RUP. И во всех известных мне командах применяется xp, обернутая в ритуалы scrum и с попыткой использовать принципы аджайл.
Но все это разбивается о неспособность топ-менеджмента выстраивать эффективные вертикальные структуры.

Ответить
Развернуть ветку
3 комментария
Николай Гончаров

"Делегировать проекты вместо задач" - правильная мысль

Ответить
Развернуть ветку
Eozvarit

Да, это называется Scrum. Сюрприз!!!

Ответить
Развернуть ветку
29 комментариев
Sergey Belikov

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

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

да

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

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

Ответить
Развернуть ветку
57 комментариев
Раскрывать всегда