МП>>Моё экспертное мнение — Scrum не подходит для разработки программного обеспечения.

Б>Если на scrum, то что? Не представляю разработку без agile


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

вот и весь процесс

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

МП>выскажись-ка лучше на обсуждаемую тему

Это сложнее.) Последний раз потимлидствовать я пробовал в нулевых еще, тогда в ходу еще были Rational Unified Process (водопад) и eXtreme Programming (тогдашний прото-agile).) С тех пор в процессе участвую только снизу, но к скраму отношусь скорее положительно: по субъективным ощущениям он позволяет ловко отгрызать кусочки от выглядящих неподъемными куч.)

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

МП>Моё экспертное мнение — Scrum не подходит для разработки программного обеспечения.

Может и заработать при определённых условиях. Например:

— На мелких проектах, как у HFTMan (за плечами десяток коммерческих релизов успешных разнообразных проектов на Agile-подобных методах за 12 лет). Такие типовые пет-шопы где мозгов много не надо на скраме делаются на ура.
— У тебя ровная команда середнячков или хаев. Без примеси бездельников и балаболов.
— Ты не лимитирован сроками.

Если всё это есть, то скрам будет работать. Правда не понятно зачем? Пользы от него немного и недолго.

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

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

William Edwards Deming, "Out of the Crisis", pages 180-181.

Дальше идёт спираль, упоминаемая обычно agile-консультантами в побасёнках про то, что строили-строили Хеопсу сарай, а в результате навалили целую пирамиду. Опять же, прослеживаются некоторые отличия.

Fig. 10. The helix. Continue the cycle, over and over, with never-ending improvement of quality, at lower and lower cost.

Последнее -- это основное отличие инженерного подхода от agile, в котором на конце каждого витка спирали добавления feature громко раздаётся "Дай ещё денег!"

https://vit-r.dreamwidth.org/1109541.html

МП>Можем обсудить почему именно.

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

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

МП>вот и весь процесс

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

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

МП>>вот и весь процесс

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

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

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

МП>>Можем обсудить почему именно.

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

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


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

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

МП>>выскажись-ка лучше на обсуждаемую тему

J>Это сложнее.) Последний раз потимлидствовать я пробовал в нулевых еще, тогда в ходу еще были Rational Unified Process (водопад) и eXtreme Programming (тогдашний прото-agile).) С тех пор в процессе участвую только снизу, но к скраму отношусь скорее положительно: по субъективным ощущениям он позволяет ловко отгрызать кусочки от выглядящих неподъемными куч.)

мм.. я думал что RUP это свой собственный процесс, а не водопад
в теории проходили, но я по нему не поработал

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

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

МП>это обычная обратная связь, СССР тут ни при чём
МП>и описанный мной подход довольно эффективен как есть на вменяемых исполнителях, без дополнительных заточек

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

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

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

IT>Может и заработать при определённых условиях. Например:
IT>- На мелких проектах, как у HFTMan (за плечами десяток коммерческих релизов успешных разнообразных проектов на Agile-подобных методах за 12 лет). Такие типовые пет-шопы где мозгов много не надо на скраме делаются на ура.
IT>- У тебя ровная команда середнячков или хаев. Без примеси бездельников и балаболов.
IT>- Ты не лимитирован сроками.

IT>Если всё это есть, то скрам будет работать. Правда не понятно зачем? Пользы от него немного и недолго.

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

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

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

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

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

МП>ща все участники выскажутся, и я изложу фундаментальную теорию всё ставящую на свои места

ты выскажишь лишь свой неудачный опыт неосилятора.

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

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

agile — это черная дыра по высасыванию денег

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

AS>agile — это черная дыра по высасыванию денег

у меня такая же мысль бывает

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

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

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

AS>>agile — это черная дыра по высасыванию денег

МП>у меня такая же мысль бывает

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

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

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

МП>Моё экспертное мнение — Scrum не подходит для разработки программного обеспечения.

А вот не знает ли кто почему в лавочке Agile Manifesto приток клиентов не наблюдается ровно с июля 2016
https://agilemanifesto.org/display/index.html
?

Что там случилось?

Здравствуйте, HFTMan, Вы писали:
HFT>Поржал в голос.
HFT>У меня за плечами десяток коммерческих релизов успешных разнообразных проектов на Agile-подобных методах за 12 лет, затюненных под конкретные сценарии, а тут вылазит какой-то хрен и мне рассказывает, что это не работает
HFT>Ну обсуждайте с другими упоротыми, почему они не шмагли
да как бы можно по нему работать, но есть некоторые вещи, которые меня лично в нем раздражжают
самая, как мне кажется, ужасная проблема это когда проект становится неуправляемым. когда число багов месяц от месяца только растет и никто уже не понимает как все это вообще работает. и вот я дважды видел, когда скрам в таких, топовых конторах, доводил проект до такого состояния. но тем не менее сейчас все по нему работают все равно и хочешь или нет, знать его надо. но вообще если я увижу слово скрам и растущее количество тикетов от релиза к релизу, то я предпочту свалить оттуда поскорее, чем пытаться вытягивать проект

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

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

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

И делать при этом умное табло лицо.

Моему текущему проекту без всяких аджайлов чтобы добраться до релиза понадобилось три года в режиме давай-быстрей-быстрей-давай девелопмента. Без фул кавереджей, ретроспективов, раз-два в неделю статус митингов. Но правда с жирным бюджетом и более менее сносной документацией. Девиз проекта был — парни, банк теряет миллионы каждый код и может потерять репутацию, постарайтесь. Мы постарались. Банк больше не теряет миллионы, а если проблемы с репутацией, то точно не по нашей вине. После внедрения аджайлов производительность команды уменьшилась примервно в 3-5 раз. Т.е. если бы аджайл был с самого начала, то мы бы ещё даже не вышли в продакшин и банк продолжал бы терять и бабки и репутацию.

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

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

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

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