В дебрях водопада

[vit_r]

Agile rituals have killed challenge.

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

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

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

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

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

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

Comments

[rdia.livejournal.com]

> Я пару дней назад пытался донести похожую мысль до agile идеологов

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

[jamhed]

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

[vit_r]

Так и оправдывают. Фильтруют негативную информацию и рассказывают миф о жутких проблемах тёмных веков.

[rdia.livejournal.com]

Ну какая разница, как они там оправдывают. Оправдание, как дырка в жопе, есть у каждого.

Вопрос - что с этим делать? Как определять, как предотвращать на ранних стадиях, и т.д.

[vit_r]

Ну что делать? Уматывать или использовать.

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

[jamhed]

А выглядит как преднамеренная диверсия: успешные студии и проекты превращаются в полное говно.

[vit_r]

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

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

[rdia.livejournal.com]

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

Модель абсолютно рационального человека в атомизированном обществе (homo economicus) - это отличное первое приближение для прикидок поведения. А из неё следует, что если ввести определённые, не вполне очевидные, правила, то да, будут писать отчёты и не работать.

[jamhed]

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

[rdia.livejournal.com]

Результат, хочу отметить, очевиден не сразу.

Осмысленно работать можно затем, что

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

2. Для обучения на перспективу. Чтобы научиться делать что-то хорошо, надо хотя бы пытаться это делать.

[vit_r]

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

[jamhed]

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

[(Anonymous)]

Спасибо за наводку на хабр, очень интересно.

Раньше хорошо о проектах писал gaperton в ЖЖ. Помогал своими текстами развивать мышление. Да и обсуждении под текстиками было на уровне. Собственно кусочек оттуда:
--
S>>> "Есть мнение, что проекты они и в африке проекты. И качественный ПМ одинаково хорошо разрулит проект разработки новой соц. сети и проект по постройке нового стадиона"
S_D>>Оно конечно качественный пм может и разрулит проект стадиона...

Вы всерьез готовы предположить, что "качественный ПМ" может что-то "разрулить" в проекте стадиона, не зная профильных ГОСТов, не имея понятия о том, что такое СНИП, не представляя основ техпроцесса, особенностей логистики данного типа проектов, и типовых проблем проблем строительства? Правда?

S>если ПМу нужно знать ГОСТы, то например, кирпичи класть ему тоже нужно уметь?

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

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

Возвращаясь к первой цитате, да уже и к собственному опыту. Человек не зная и не умея в профильной области полез смотреть решения на рынке. Ну как так-то, как так? А,допустим, дом он себе тоже будет строить методом нагугливания и постройки собственными силами не вникая в предметную область?
Лично я потратил примерно два года здоровья на попытку хоть что-то перевести на рельсы BPM. Сверху были люди совершенно не понимающие в бизнес-процессах, зато хотевшие звездочки. Ситуация закончилась печально. То что надо было, и возможно, автоматизировать не сделали. Потому что наверх не покажешь красивую картинку по этим процессам. А вот на автоматизации других процессов можно показать красивую картинку. Но плюсов это компании не принесет. А когда встал вопрос денег, даже не за работу а за ПО, на этом всё кончилось. Слишком дорого выходит а результат надо показать прямо сейчас. И результат это строка в бюджета которую можно срезать сразу по внедрению.
Но это так не закончилось конечно. Звездочек людям всё равно хотелось. Начали подтаскивать всё что есть на рынке ПО(как тот наивный писатель). Единственный критерий был стоимость ПО и насколько хорошие у компании презенташки. Пришлось делать так что бы эти системы случайно тонули на стадии тестирования. Мне просто потом людям в глаза стыдно было бы смотреть.

Что печально - всех всё устраивает. Отношение лишь бы не было войны.

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

[rdia.livejournal.com]

> А,допустим, дом он себе тоже будет строить методом нагугливания и постройки собственными силами не вникая в предметную область?

Ну это общее - обзор требований народ не делает в принципе. Даже не подозревает, что это можно и желательно сделать. Причём "всё украдено до нас" - есть шаблоны, есть ТРИЗовская 9-ти экранка (очень эффективный метод). Но народ даже разучился использовать ручку и бумажку, причём хвастается этим.

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

На тему управления и мотивации много худлита писал Терри Пратчетт.

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

> Что печально - всех всё устраивает. Отношение лишь бы не было войны.

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

[(Anonymous)]

Спасибо за отдельные наводки. Часть из этого начинал читать, но времени всё не было.

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

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

[rdia.livejournal.com]

> У меня есть только одно объяснение. Человек думает что не сможет нормально работать, и решил "съесть" коллег любыми средствами. Такой крысиный король.

Может быть он хочет стать незаменимым в конторе? Ну, таким старпёром с job security? Это вполне понятное желание.

> Какое же тут равновесие.

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

[(Anonymous)]

> Может быть он хочет стать незаменимым в конторе?

Естественно эта версия практически на 100% верна. А учитывая параноидальность человека она остается единственной. Беда в том что это размен вменяемой 5ки из 8-9 часов, с редкими переработками, и возможностью в любой момент отбегать по делам, на значительное увеличение рабочего времени с захватом выходных. Из говна и палок делает же. А плюсов к зарплате никаких. Морковка маячит в неизвестном будущем. Состоит из, возможно, небольшого повышения в деньгах и увеличенной вероятности остаться при оптимизациях.

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

Беда в том что он это отлично понимает. И всё было приговорено с ним тет-а-тет. Но у человека реально параноидальные мыслишки. Пару раз прорывалась мысль, на вполне безобидные действия, "ты что - меня подставить хочешь?". И есть у меня подозрения что делать он такое начал после стуканья в голову мнения - все вокруг враги, меня хотят выкинуть на мороз.

[rdia.livejournal.com]

> Естественно эта версия практически на 100% верна. А учитывая параноидальность человека она остается единственной.

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

Собственно, всё обсуждение agile у ув. vit-r'а бегает вокруг сего нехитрого факта.

> Из говна и палок делает же.

В данном случае, чем больше говна и палок, тем лучше для субъекта.

> увеличенной вероятности остаться при оптимизациях.

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

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

[vit_r]

Собственно, всё обсуждение agile у ув. vit-r'а бегает вокруг сего нехитрого факта.

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

[jamhed]

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

[rdia.livejournal.com]

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

[vit_r]

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

Если обсуждение на самом деле нужно, на него могут тратить и 90% времени, чтобы потом реализовать запланированное без ошибок. Это гораздо эффективнее муравейника разработчиков, которые быстро-быстро на коленке пилят в разные стороны.

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

[rdia.livejournal.com]

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

[vit_r]

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

В этом случае регулярные ритуалы всё-таки лучше, чем ничего. До тех пор, конечно, пока они не становятся самоцелью.

[jamhed]

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