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

просто плохой был значит менеджер, ещё худший, чем скрамер

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


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

думаю вы просто стартовали от днища, поэтому скрам вам кажется теперь практикой мастера


САД>в целом же, весь процесс разработки, планирования, деливери, стал прозрачен для всех, для девов, для БА, для ПО, для бизнеса в целом.
САД>безусловно, те или иные аджайл практики, их нужно адаптировать под себя. но оно работает.
САД>намного хуже, когда никакой методологии нет вообще.

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


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

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


САД>и тут проблем дохрена.
САД>начиная от того, что такое переключение контекста, полсностью демотивирует девелопера.

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


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

СССР не к ночи тут помянутый работал всё же не по скраму
но со стратегическим планированием всё было неплохо


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

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

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