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

Если это R&D то ни о каком скраме конечно же речи быть не может. А если адаптация готовых типовых решений под разных кастомеров, то почему бы и нет?

Здравствуйте, Министр Промышленности, Вы писали:

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

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

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

J>Я исхожу из того, что программисты и начальники не пытаются халтурить, все пытаются работать как могут, главное — просто согласовать их усилия. Если это не так, то работать в таком месте не нужно. А ускорить этот процесс особо не выйдет: если задача требует сто часов работы,то именно столько на нее и уйдет, запланирует это кто-то заранее или нет.

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

__>>то есть, суммируя все, скрамом проект не вытянешь. если у вас он давно и хорошо работает — отлично. если у вас проблемы и вы решили решить их скрамом — ничего не получится

САД>Странно, но, мы вытягивали.

возможно вы их вытягивали не благодаря скраму, а просто в его рамках

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

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

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

это если хайлевел.

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

намного хуже, когда никакой методологии нет вообще.

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

МП>как эксперт в теме, добавлю,

это так мило

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

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

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

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


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

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

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

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


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

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

нет, овертаймы это не по технологии
фундаментальная подоснова под этим следующая, упрощенно:
у разработчика моральные силы восстанавливаются довольно медленно
(моральные силы разработчика — это на самом деле главный показатель покруг которого и должен плясать процесс)
восстанавливаются не на 8 часов в день, а на 5-6
это усреднённый показатель, на деле эти силы тратятся на создание контекста, и меньше тратятся на его удержание и развитие, если нет отвлечений
соответственно, даже 8-часовой рабочий день в идеале выработает все силы раньше чем он закончится на 2-3 часа
а овертаймы тем более

Здравствуйте, IT, Вы писали:

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

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

вы осознаёте хоть что скрам != аджайл
и что ни то ни другое ничего не говорят о наличии фул кавередж или о тестировании?
про архитектуру тоже

МП>>а что если!
МП>>разработать новую методологию:
МП>>для заказчика это будет симуляция скрама, а внутри — нормальная проектная работа

AS>а смысл тратиться на контекстные переключения между внешним и внутренним ?

это будет делать менеджер
смысл в том, чтобы выманивать из заказчика бабло в рамках скрама, а делать в рамках здрава

Здравствуйте, __kot2, Вы писали:

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

Ага.
Скрам сидел и в репозиторий багами срал, да.

А разработчики совсем совсем неуиоатые.

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

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

МП>>Можем обсудить почему именно.
N>Все эти методологии нужны только для обучения. Научившись, каждый менеджер сам строит свою систему. Если у менеджера не хватает авторитета и лидерских качеств, то следование 'модной' методологии заставит вас работать, как ему нужно.

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


N>Это можно сравнить с шаблонами проектирования, которые также были придуманы для обучения. Потому не имеет смысла обсуждать, можно ли программировать только на шаблонах. В редких случаях, наверное, можно.

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

Здравствуйте, landerhigh, Вы писали:
L>Ага.
L>Скрам сидел и в репозиторий багами срал, да.
L>А разработчики совсем совсем неуиоатые.
для примера возьмем, например СТО. Туда приезжает машина с жалобой, что "что-то там скрипит". В дневные планы вписывается "получасовая диагностика", по результатам которой приговариваются колодки к замене и в расписание на следующий день кому-то ставится получасовая замена колодок. Сотдруник поднимает машину на подьемник, снимает колеса и вдруг видит, что и тормозные диски и суппорта нуждаются в замене. И тут сразу вылазит вся негибкость подхода — даже если это все есть в наличии, то на машину выделено всего полчаса, дальше все забито другой работой, нельзя просто взять и сделать, как надо, нужно делать как поручили. Человек меняет колодки и возвращает по сути неисправную машину, потрамтив неэффективно и свое время и время клиента. Разумеется, проблема не уходит. Машина продолжает стоять с проблемой, но на этот день все итак забито работой. На следующий эта работа поручается новому человеку, который не знает что там вообще нужно делать, он снова просит час на замену, например, дисков, снимает
колеса ...
то есть вроде что-то делается, проблема никуда не уходит. по ходу появляются новые. все бегают, как ужаленные, всем есть о чем отчитаться, но по факту старые проблемы нормально не закрываются, а постоянно перевылазят + добавляются новые

Здравствуйте, Министр Промышленности, Вы писали:

МП>Моё экспертное мнение — Scrum не подходит / (подходит с лишними издержками) для профессиональной разработки программного обеспечения.
МП>В данном случае это мнение я уже сверил с 2мя надёжными источниками — подтвердили.
МП>Сверьте и вы.
МП>Можем обсудить почему именно.

А вы что на нем программы пишите?

Здравствуйте, Министр Промышленности, Вы писали:

МП>Моё экспертное мнение — Scrum не подходит / (подходит с лишними издержками) для профессиональной разработки программного обеспечения.
МП>В данном случае это мнение я уже сверил с 2мя надёжными источниками — подтвердили.
МП>Сверьте и вы.
МП>Можем обсудить почему именно.

"Любая теория, которая успешно применяется за границей, попадая к нам, становится отвратительной"
(с) Лао Шэ. 1932

Здравствуйте, __kot2, Вы писали:

L>>Скрам сидел и в репозиторий багами срал, да.
L>>А разработчики совсем совсем неуиоатые.
__>для примера возьмем, например СТО. Туда приезжает машина с жалобой, что "что-то там скрипит". В дневные планы вписывается "получасовая диагностика", по результатам которой приговариваются колодки к замене и в расписание на следующий день кому-то ставится получасовая замена колодок. Сотдруник поднимает машину на подьемник, снимает колеса и вдруг видит, что и тормозные диски и суппорта нуждаются в замене.

Иными словами, в том, что на СТО держат слепошарого "диагноста" и приемщика-дебила, виноват кто угодно, но не слепошарый диагност, приемщик-дебил и его начальство.

Смотри выделенное, в общем.

Здравствуйте, landerhigh, Вы писали:
L>Иными словами, в том, что на СТО держат слепошарого "диагноста" и приемщика-дебила, виноват кто угодно, но не слепошарый диагност, приемщик-дебил и его начальство.
L>Смотри выделенное, в общем.
если я сейчас подкину монетку, зажму в руке и попрошу угадать, что выпало, то без разницы кто там насколько слепошара или дебил, никто не сможет это сделать больше чем случайное гадание. не надо думать, что можно диким умстревенным усилием вызвать рентгеновские лучи из глаз, которые позволят увидеть диагностировать любую проблему сразу

Здравствуйте, Kernan, Вы писали:

K>А как вы организовывали процесс тогда? Я понимаю что фул кавередж можно заменить на хорошее тестирование и т.п. Но остальное? Требования, приоритеты, архитектура, внедрение?

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