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

[vit_r]

Agile rituals have killed challenge.

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

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

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

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

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

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

Comments

[straktor]

эджайл практики абсолютно адекватны для своей ниши

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

когда нет смысла делать фичи, потому что всё 100 раз поменяется

[vit_r]

когда команда пишет вебсайт для некой бизнес-задумки,

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

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

[straktor]

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


мотивация -- "мы в этом спринте зарелизили крутейшую фичу! юзеры в восторге! 2 тыщи лайков, 30 благодарностей! 20 тыщ новых юзеров за 2 недели!"

[vit_r]

никогда (почти) тебе юзер не выдаст глубинные хотелки, потому что сам их обычно не знает

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

Да, я редкий зверь по нынешним временам. Почти как динозавр в курятнике.

"мы в этом спринте зарелизили крутейшую фичу! юзеры в восторге! 2 тыщи лайков, 30 благодарностей! 20 тыщ новых юзеров за 2 недели!"

Если поставить на картинку голую бабу, будет больше.

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

[rdia.livejournal.com]

> когда нет смысла делать фичи, потому что всё 100 раз поменяется

Есть такая штука - аналитика. Берёте карандаш, бумажку и идёте беседовать с людьми. Используете стандартную 9-ти экранную схему из ТРИЗ для описания системы, которую разрабатываете/чините; при чём, естественно, в надсистемах включаете людей (в подсистемах обычно людей нет, хотя бывает по-разному).

Но большая часть уебщиков ведь даже писать разучилась.

[straktor]

вы знаете, что вне энтерпрайза существует внешний мир?
вот эджайл это туда

например убер -- с кем ему беседовать? или например порно-вебкамеры? та же чатрулетка? платформа "метнись кабанчиком"?

[rdia.livejournal.com]

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

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

[anonim_legion]

С моделями можно побеседовать.

[(Anonymous)]

Все так.

Аджайл полное говно.

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

[vit_r]

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

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

[rdia.livejournal.com]

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

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

Расскажите, оно очень интересно.

> Когда разберусь с моделью мотивации, будет подробно, красиво и структурировано.

А это будет опубликовано, или как всегда полунамёками?

[vit_r]

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

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

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

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

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

Руководитель разработчиков просто бегает вокруг и создаёт видимость деятельности.

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

А над всем этим Эксперты. У них на всё элементарная оговорка "They do not have Agile Mindset."

А это будет опубликовано, или как всегда полунамёками?

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

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

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

[nnz]

Все так.

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

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

[vit_r]

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

Угу

[(Anonymous)]

1. Переименовіваем обічную человеческую глупость и нерадивость в базз-ворд
2. Спускаем всех собак на єтот баз-ворд
...
ПРОФИТ!!!!!

[rdia.livejournal.com]

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

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

[nnz]

Цель проекта.

[nnz]

Все так.

Аджайл полное говно.

Важно четкое понимание цели. Четкое понимание набора действий для достижения цели. Возмоможность менять цель и набор действий. Изменение цели и набора действий возможно только при четком понимании последствий от изменения.

[jamhed]

Я пару дней назад пытался донести похожую мысль до agile идеологов: вот мы перескакиваем от user stories к scrum epics даже без попытки задуматься о продукте/сервисе как о целом, где место для модели в этом чудном процессе? Кто ответственный за понимание? Ответом было что команда решает, и в командах должны быть solution architects.

[vit_r]

Ответом было что команда решает

Угу. Коллективное бессознательное.

Не надо задавать провокационные вопросы о том, кто будет думать. Этого в системе не предусмотрено.

[rdia.livejournal.com]

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

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

[jamhed]

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

[straktor]

> где место для модели в этом чудном процессе?

модели чего?
иногда продукт удовлетворят одну схему в одном, э-э, процессе, и тогда можно что-то моделировать
в 90% продуктом пользуются 3-5-10-20 разных групп юзеров по-разному в разное время
что вы там моделировать будете?

> Кто ответственный за понимание?

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

> Ответом было что команда решает, и в командах должны быть solution architects

угу
в команде есть лиды, иногда -- все (зрелые и опытные, если бабок дохрена)
они читают код, доку, и всё понимают сами себе
сами изобретают "в целом"

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

за год продуктом рулят 3-4 гуру, которые стремительным вихрем пролетают, изменяют и перепрыгивают на другое
какое там может быть видение? юзер сторю вкрячил как понял и как нравится, и наплевать на всё
бизнес снимет сливки и быстро сдохнет
жизненный цикл насекомых

[vit_r]

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

О! Пошли стандартные отмазки.

[jamhed]

> перед кем ответственный, и кому нужен ответ?

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

> бизнес снимет сливки и быстро сдохнет

И чем же это хорошо, позвольте спросить?

> бизнес всё равно в технике не понимает

Вы знаете, есть очень разные бизнесы, и не ко всем из них ваше описание применимо.