\


\

да тут одни макакеры

>>718672 (OP)
Если вкратце, то нужно чтобы макаки ебашили, скрам их загоняет в узкие рамки. Вот такие дела.

>>718672 (OP)
Несколько раз в двух конторах наблюдал попытки ввести практики аджайла, и оба раза все заканчивалось пшиком. В основном потому что эти практики идут вразрез с необходимостями бизнеса типа "клиент сказал что надо сделать вот это и это, причем уже вчера".

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


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

>>721057
>Клиент сказал что надо сделать вот это и это, причем уже вчера
Если так, то нужно использовать Канбан.

>>718672 (OP)
Работаем по схему: менеджеру в жопу ужалило и он пришел и начил ДОВИТЬ на всех, чтобы было ПОЕГОНОМУ, рассказывать чтобы всякую хуйню делали все. На завтра менеджер все забывает, что говорил, и куда-то пропадает по своим делам.

>>721128
Ещё там всякие компоненты психологические включаются, типо ВЫ ПЛОХО РАБОТАЕТЕ, НЕ ВИЖУ РЕЗУЛЬТАТОВ, вот всякое такое полоскание мозгов для рабов. Кто что делает и когда закончат знают с трудом.

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

>>718672 (OP)
На мой взгляд идеалом является непрерывная разработка, т.е. когда бизнес получает результаты сразу после того, как они закодены и сразу может корректировать последующую разработку. Т.е. что-то вроде Kanban. Аджайл слишком сосредоточен на фиксированных спринтах, в итоге получается следующее противоречие:
1. Бизнес, ставя задачу, понимает, что любые коррекции он вможет внести не ранее, чем окончится спринт, в итоге бизнес стремится сделать спринты короче, например, в 1 неделю.
2. Слишком короткие спринты вредят программистам, многие задачи они не могут выполнить в рамках одного спринта, слишком много времени уходит на всякие встречи, связанные со сдачей функциональности, программировать времени не остаётся. Поэтому программисты стремятся сделать спринты подлиннее. Ну ты сам можешь взглянуть на свою картинку и подумать над тем, можно ли это уложить, скажем, в неделю, и сколько времени в итоге останется на программирование.

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

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

Когда ПМ звонит по телефону и просит что-то быстро добавить на сайт, это аджайл?

>>721634
Это непрерывная разработка.

>>721634
лол