Re[10]: Scrum не подходит для программной разработки - О работе

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

HFT>>>>У меня за плечами десяток коммерческих релизов успешных разнообразных проектов на Agile-подобных методах за 12 лет, затюненных под конкретные сценарии, а тут вылазит какой-то хрен и мне рассказывает, что это не работает

HFT>>>>Ну обсуждайте с другими упоротыми, почему они не шмагли

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

МП>>>у меня за плечами 15 лет, очевидно не менее успешной, коммерческой разработки
МП>>>причем начинал, когда скрама ещё не было, есть с чем сравнить
HFT>>Ну у меня в 2002 году первый коммерческий код пошел, в 2003 году вообще в Диасофте работал по ватерфолу, как и потом в Артезио/Ланите в 2004-2006 годах, потом уже более agileподобные методы пошли в дело, так что я тоже могу много что и с чем сравнить

МП>ну давайте сравним передовой скрам с (фу-фу отсталым) вотерфолом
Скрам передовой?

Народ процесс уже давно по Kanban катает. Ну либо Lean, либо гибриды с собственными добавлениями.
МП>был случай, когда прогеры перешли на вотерфол
Поработай десяточку лет в Лаборатории Касперского либо другой крупной конторе с продуктовой линейкой ПО, да желательно на сложных релизах в дефиците ресурсов/времени, причем на уровне тим-лида(т.к. мнение рядовых исполнителей оно такое, специфическое), приходи, а обсуждать опыт ремесленников, занимающихся мелкими говноподелиями, которые после релиза выкидываются в мусор, т.к. не являются коробочным изделиями либо линейкой продуктов-не вижу смысла, мне уже все давно понятно, на собственной
шкуре.
МП>и я подозреваю, что выиграли по производительности
МП>объясню почему, пусть побольше мнений напишут
Ну пусть сразу пишут, сколько денег продукт/линейка продуктов принесла, размер кодовой базы, какой жизненный цикл(после релиза в мусор кодовая база или дальше пилится), сколько команд смежников еще участвовало.
Бытие непродуктовых шараг, занимающихся говноподелиями мне вообще не интересно.
Начинал с таких в 2001-2002 годах, на всю жизнь хватило.

МП>>ну давайте сравним передовой скрам с (фу-фу отсталым) вотерфолом
HFT>Скрам передовой?

HFT>Народ процесс уже давно по Kanban катает. Ну либо Lean, либо гибриды с собственными добавлениями.
МП>>был случай, когда прогеры перешли на вотерфол
HFT>Поработай десяточку лет в Лаборатории Касперского либо другой крупной конторе с продуктовой линейкой ПО, да желательно на сложных релизах в дефиците ресурсов/времени, причем на уровне тим-лида(т.к. мнение рядовых исполнителей оно такое, специфическое), приходи, а обсуждать опыт ремесленников, занимающихся мелкими говноподелиями, которые после релиза выкидываются в мусор, т.к. не являются коробочным изделиями либо линейкой продуктов-не вижу смысла, мне уже все давно понятно, на собственной
HFT>шкуре.
МП>>и я подозреваю, что выиграли по производительности
МП>>объясню почему, пусть побольше мнений напишут
HFT>Ну пусть сразу пишут, сколько денег продукт/линейка продуктов принесла, размер кодовой базы, какой жизненный цикл(после релиза в мусор кодовая база или дальше пилится), сколько команд смежников еще участвовало.
HFT>Бытие непродуктовых шараг, занимающихся говноподелиями мне вообще не интересно.
HFT>Начинал с таких в 2001-2002 годах, на всю жизнь хватило.

потерял понимание, почему вы тогда тут скрам защищаете?

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

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

У меня опыта настоящего scrum'а, как мне самому ни удивительно, мало. Ненастоящего — много, и он, действительно, не подходит.
Речь о ситуациях, когда каждый от scrum'а (или в более общем смысле от agile) решил взять только то, что удобно ему, сознательно игнорируя неудобные тезисы.
А также о ситуациях, когда некоторые члены команды не осознают (переоценивают либо субъективно, либо через оценку линейных менеджеров) своей степени готовности и подходимости проекту. У меня сложилось впечатление, что scrum не даёт однозначной рекомендации, как без ущерба скорости, качеству и духу совместной разработки в целом ограничивать энтузиазм таких коллег.

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

МП>>>ну давайте сравним передовой скрам с (фу-фу отсталым) вотерфолом
HFT>>Скрам передовой?

HFT>>Народ процесс уже давно по Kanban катает. Ну либо Lean, либо гибриды с собственными добавлениями.
МП>>>был случай, когда прогеры перешли на вотерфол
HFT>>Поработай десяточку лет в Лаборатории Касперского либо другой крупной конторе с продуктовой линейкой ПО, да желательно на сложных релизах в дефиците ресурсов/времени, причем на уровне тим-лида(т.к. мнение рядовых исполнителей оно такое, специфическое), приходи, а обсуждать опыт ремесленников, занимающихся мелкими говноподелиями, которые после релиза выкидываются в мусор, т.к. не являются коробочным изделиями либо линейкой продуктов-не вижу смысла, мне уже все давно понятно, на собственной
HFT>>шкуре.
МП>>>и я подозреваю, что выиграли по производительности
МП>>>объясню почему, пусть побольше мнений напишут
HFT>>Ну пусть сразу пишут, сколько денег продукт/линейка продуктов принесла, размер кодовой базы, какой жизненный цикл(после релиза в мусор кодовая база или дальше пилится), сколько команд смежников еще участвовало.
HFT>>Бытие непродуктовых шараг, занимающихся говноподелиями мне вообще не интересно.
HFT>>Начинал с таких в 2001-2002 годах, на всю жизнь хватило.

МП>потерял понимание, почему вы тогда тут скрам защищаете?

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

HFT>как и потом в Артезио/Ланите в 2004-2006 годах

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

UPD:
нашел точную цитату:
"Никаких онлайн-казино, финансовых пирамид или сайтов знакомств."

разрабатывать предлагалось некий новый язык программирования (который нахрена новый вообще людям сдался?)

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

HFT>>>У меня за плечами 12 лет
МП>>у меня за плечами 15 лет
HFT>Ну у меня в 2002 году первый коммерческий код пошел, так что я тоже могу много что и с чем сравнить

А у меня еще длиннее: 23 ~~сантиме~~ года коммерческой разработки, где здесь главный приз выдают?)

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

МП>разрабатывать предлагалось некий новый язык программирования (который нахрена новый вообще людям сдался?)

Кто такой Терком я хз, а вот JetBrains разработал весьма годный Kotlin.

--
WBR,
Serge.

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

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

Эта тема постоянно возникает на форуме. Из последнего обсуждения вынес две идеи:
1) В скраме многое взято от классических методов, а роли переименованы, но не удалены.
2) Гибкие методологии в книгах стали рекламировать те, кто работал по классике, водопадная, итеративная и прочие. Потом эти люди стали экспертами и поняли, что могут обходится без каких-то процессов. Иными словами, если ты эксперт, то у тебя и скрам будет работать, а если нет, то ничего не поможет. Ещё какая-то книга была, там тоже писали, что если у вас есть эксперты, но нет методологии, то у проекта есть шансы на успех, а если есть методология, но нет экспертов, то велик шанс провала.

МП>>разрабатывать предлагалось некий новый язык программирования (который нахрена новый вообще людям сдался?)

H>Кто такой Терком я хз, а вот JetBrains разработал весьма годный Kotlin.

кстати этот Бреслав Андрей одно время учился в моей школе, на 2 класса меня младше
некоторые отзывы о нём доходили "мальчик, заумный который"
но Kotlin я решил пока не изучать: нафиг он мне сдался, имея C#
он вроде полезен для JS фронтенда, но лично я жду пока весь легаси фронтенд устареет

JetBrains уважаю, решарпером пользуюсь с 2005
они меня правда на работу не взяли разок, не понятно почему
но хоть внутри у себя работают надеюсь не по скраму

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

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

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

HFT>>>>У меня за плечами 12 лет
МП>>>у меня за плечами 15 лет
HFT>>Ну у меня в 2002 году первый коммерческий код пошел, так что я тоже могу много что и с чем сравнить

J>А у меня еще длиннее: 23 ~~сантиме~~ года коммерческой разработки, где здесь главный приз выдают?)

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

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

МП>>Моё экспертное мнение — 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мя надёжными источниками — подтвердили.
МП>>Сверьте и вы.
МП>>Можем обсудить почему именно.

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, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

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

HFT>Я то думал, что чел в твоем лице вообще осознает, что такое Agile

Расскажи нам всем, что такое Аджайл. Мы тоже хотим осознать.

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

HFT>>Ну у меня в 2002 году первый коммерческий код пошел, так что я тоже могу много что и с чем сравнить

J>А у меня еще длиннее: 23 ~~сантиме~~ года коммерческой разработки, где здесь главный приз выдают?)

Дети, не сорьтесь.

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

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

В скраме эту задачу нужно разделить на 4 по 25 часов и раздать делать её разным людям.

Здравствуйте, СвободуАнжелеДевис, Вы писали:

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

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

То, что вы стали работать быстрее — это вовсе не предел скорости разработки, а хоть какое-то движение по сравнению с теми тормозами, которые были до этого.

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

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

Ты с темы-то не слезай.
Сам СТО притянул, вот и отвечай теперь
Еще раз, кто виноват в том, что слепошарый диагност, приговоривший колодки, умудрился не заметить, что и диски — тогось?
Кто виноват в том, что приемщик, вместо того, чтобы выставить работы по пробегу согласно рекомендациям производителя или опыту ("скорее всего там уже и диски и еще чего"), доверяет слепошарому диагносту?

Скрам в этом виноват?

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

IT>Я считаю, что процесс нужно организовывать под конкретный проект и руководствоваться прежде всего здравым смыслом.

Между прочим, именно это говорят во всех скрам тренингах.

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

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

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

IT>>Я считаю, что процесс нужно организовывать под конкретный проект и руководствоваться прежде всего здравым смыслом.
L>Между прочим, именно это говорят во всех скрам тренингах.

Это да.

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

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

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

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

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

IT>- Тогда давайте отменим статус митинги, или сократим их количество.

Там этих статус митингов — кот наплакал.

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

Ну, что правда, то правда. Аборигены Вануату с соломенным самолетом не дадут соврать.

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

IT>>- Тогда давайте отменим статус митинги, или сократим их количество.
L>Там этих статус митингов — кот наплакал.

Пять штук в неделю минимум. Хотя двух более чем достаточно. Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги.

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

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

IT>Пять штук в неделю минимум.

Ежедневная летучка на пару минут "сделал Х, буду делать У" — это ни о чем.

IT>Хотя двух более чем достаточно.

Делайте два раза в неделю, если для вас работает

IT>Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги.

Ну, сдуру можно еще и не то сломать.

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

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

По итогам обсуждения имеем:

1. На СТО работают слепошарые дебилы.
2. Кто-то срет в репозиторий багами.

Следовательно, скрам — овно.

Басню Крылова напомнить?

IT>>- Тогда давайте отменим статус митинги, или сократим их количество.
L>Там этих статус митингов — кот наплакал.

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

+ груминг, планирование, ретроспектива
видел когда планирование проводилось в 2х экземплярах — предварительное и чистовое

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

МП>+ груминг, планирование, ретроспектива
МП>видел когда планирование проводилось в 2х экземплярах — предварительное и чистовое

А мне рассказывали, что в иных компаниях по утрам гимн компании хором поют.

IT>>Пять штук в неделю минимум.
L>Ежедневная летучка на пару минут "сделал Х, буду делать У" — это ни о чем.

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

IT>>Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги.
L>Ну, сдуру можно еще и не то сломать.

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

МП>>Можем обсудить почему именно.
L>По итогам обсуждения имеем:

L>1. На СТО работают слепошарые дебилы.

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

L>2. Кто-то срет в репозиторий багами.

а кстати, что сделает скрам в этом случае?

L>Следовательно, скрам — овно.
L>Басню Крылова напомнить?

скрам противоречит технологии Software Engineering

МП>>+ груминг, планирование, ретроспектива
МП>>видел когда планирование проводилось в 2х экземплярах — предварительное и чистовое

L>А мне рассказывали, что в иных компаниях по утрам гимн компании хором поют.

мне тоже, вроде в LG
но в LG на собесе это опровергли (сам я им поверил не до конца)

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

МП>вот именно — ни о чём, она не нужна

Ну, для удаленного саппорта говен мамонта и правда не нужна.

Для командной разработки софта — жизненно необходима.

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

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

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

МП>>вот именно — ни о чём, она не нужна
L>Ну, для удаленного саппорта говен мамонта и правда не нужна.

для саппорта она как раз не сможет навредить так сильно

L>Для командной разработки софта — жизненно необходима.

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

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

L>Короче, очередные стенания на тему "где бы не работать, лишь бы не работать".

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

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

вот так и работай

L>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам. Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.

восторженные мантры пошли

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

МП>для саппорта она как раз не сможет навредить так сильно

А в саппорте вообще сложно навредить.

L>>Для командной разработки софта — жизненно необходима.

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

Вот начинается.
Что значит "надо скоординировать работу"? Кто решает, что нужно "скоординировать работу"? Откуда эти два разработчка вообще узнают, что им нужно координировать работу?

МП>а не слушают по расписанию всю байду которую вещает весь отдел

Все ясно. Рабинович напел. карго-культ.

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

L>Вот начинается.
L>Что значит "надо скоординировать работу"? Кто решает, что нужно "скоординировать работу"? Откуда эти два разработчка вообще узнают, что им нужно координировать работу?

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

МП>>а не слушают по расписанию всю байду которую вещает весь отдел

L>Все ясно. Рабинович напел. карго-культ.

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

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

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

И результат всего этого — "почти готово", но за две недели до релиза аврал и перенос сроков на полгода.
Именно отсюда скрам-то и просочился разработку софта.
Не работает это "сами и решают".

МП>>>а не слушают по расписанию всю байду которую вещает весь отдел

L>>Все ясно. Рабинович напел. карго-культ.

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

Это и есть карго-культ. Битлы, напетые по телефону.

Короче, выходит, что ты скрама не видел.

Твоей вины, в общем, в этом нет. Но вот оснований заявлять, что "скрам не работает" у тебя тоже нет

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

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

L>Это и есть карго-культ. Битлы, напетые по телефону.
L>Короче, выходит, что ты скрама не видел.
L>Твоей вины, в общем, в этом нет. Но вот оснований заявлять, что "скрам не работает" у тебя тоже нет

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

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

L>Короче, выходит, что ты скрама не видел.
Ни один истинный шотландец... Каким хорошим может быть скрам, думаю, все и так знают. Проблема ж в применительной практике. И если традиционные методики выливаются в редкие авралы и перенос сроков, то "неправильный" (читай, тот, что будет в 90% компаний) скрам — ежедневый геморрой и раздражение. С точки зрения рядового исполнителя-программиста я не уверен, что второе предпочтительнее.

L>>Короче, выходит, что ты скрама не видел.
ECR>Ни один истинный шотландец... Каким хорошим может быть скрам, думаю, все и так знают. Проблема ж в применительной практике. И если традиционные методики выливаются в редкие авралы и перенос сроков, то "неправильный" (читай, тот, что будет в 90% компаний) скрам — ежедневый геморрой и раздражение. С точки зрения рядового исполнителя-программиста я не уверен, что второе предпочтительнее.

это не баг, это фича

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

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

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

Вот именно.
Нет такой замечательной идеи, которую не испортили бы реализацией.

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

IT>>Пять штук в неделю минимум.
L>Ежедневная летучка на пару минут "сделал Х, буду делать У" — это ни о чем.

Ни о чём — это когда тебе по скайпу босс спросит "ну что там?", а ты ему в свободную минутку "всё норм". Это ни о чём. А в аджайле профессионалы способны из любого ни о чём раздуть ого-го.

Например, митинг назначается на 9:30 утра, чтобы все выспались и все собрались. Это означает, что до этого времени никто ничем другим заниматься не будет. Далее в течении 15-20-ти минут 10 человек рассказывают друг другу ненужные и неинтересные вещи. При этом замечено, что чем меньше чел сделал, тем больше он об этом будет говорить.

Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.

IT>>Хотя двух более чем достаточно.
L>Делайте два раза в неделю, если для вас работает

Нельзя. Это ритуал. Если два раза, то это уже не аджайл. Начальство не поймёт. Да и половине команды нравится потрындеть вместо поработать.

IT>>Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги.
L>Ну, сдуру можно еще и не то сломать.

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

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

IT>Например, митинг назначается на 9:30 утра, чтобы все выспались и все собрались. Это означает, что до этого времени никто ничем другим заниматься не будет. Далее в течении 15-20-ти минут 10 человек рассказывают друг другу ненужные и неинтересные вещи. При этом замечено, что чем меньше чел сделал, тем больше он об этом будет говорить.

Ну вот такое дело, что если "ненужные и неинтересные вещи", то это не скрам. А карго-культ.
Ну и 15-20 минут тоже уже индикатор.

IT>Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.

А откуда у вас следующие митинги? А работать когда?

IT>Нельзя. Это ретаул. Если два раза, то это уже не аджайл. Начальство не поймёт. Да и половине команды нравится потрындеть вместо поработать.

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

IT>>>Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги.
L>>Ну, сдуру можно еще и не то сломать.

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

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

Тут не кровати надо переставлять, а, гхм, сотрудников, гхм, менять.

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

L>>1. На СТО работают слепошарые дебилы.
МП>начнём с того, что CTO вообще может не быть в компании

Здесь.

L>>2. Кто-то срет в репозиторий багами.
МП>а кстати, что сделает скрам в этом случае?

Попу точно не вытрет.

L>>Следовательно, скрам — овно.
L>>Басню Крылова напомнить?

МП>скрам противоречит технологии Software Engineering

Что такое "технология Software Engineering"?

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

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

А что по-твоему делает этот сложный инженерный процесс сложным?

L>Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.

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

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

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

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

IT>А что по-твоему делает этот сложный инженерный процесс сложным?

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

L>>Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.

IT>Это в большей степени проблемы менеджмента. Действительно вотерфол при плохом менеджменте скатывается в always 95% ready.
IT>Замена процесса на аджайл временно решает эту проблему, перекладывая ответственность с менеджера на девелоперов,

Что значит "перекладывая ответственность". А кто, по твоему, вообще должен отвечать за "готовность модуля"?

IT>а далее с них всех вместе взятых на заказчика.

Не перекладывает на заказчика, а вовлекает заказчика в итеративный процесс постоянного получения обратной связи.

IT>Это работает какое-то время, пока девелоперы не просекут фишку и потом это всё работает ещё медленнее, но более прогнозируемо.

Ну тут не кровати надо переставлять, а далее по тексту.

IT>Всё это решается гораздо проще — заменой менеджера в самом начале.

Ну заменил ты менеджера в самом начале. Чем это поможет?

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

МП>просто показателен факт, что разработчики порой предпочитают работать даже по нему, а не по скраму

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

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

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

Как правильно сказал С.А.Д., мнение разработчиков в этом вопросе мало кого волнует.

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

МП>но со стратегическим планированием всё было неплохо

Трудно было бы найти более неудачный пример. С планированием в СССР было очень плохо.

МП>>скрам противоречит технологии Software Engineering

L>Что такое "технология Software Engineering"?

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

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

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

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

МП>>просто показателен факт, что разработчики порой предпочитают работать даже по нему, а не по скраму

AK>Он совсем не показателен, а как раз наоборот — вполне предсказуем.
AK>Суть и цель скрама совсем не в том чтобы нравиться разработчикам. Напротив, это способ выжать из них всё что можно.
AK>Повышается уровень контроля за ходом выполнения задач, повышается уровень личной ответственности разработчиков, часть работы менеджеров фактически перекладывается на разработчиков. С чего бы им радоваться-то? Радоваться они могут в тех редких случаях, когда они материально заинтересованы в успешности проекта и стремятся сделать его быстрее и качественнее. Я таких случаев почти не видел.
AK>А так-то, программисту куда комфортнее как раз "водопад" — "вы там требования уточните до деталей, зафиксируйте сроки и следующие полгода ко мне не приставайте — я буду работать над этим фиксированным списком задач". Само допущение того, что требования будут меняться и это нормально — это уже дискомфорт для разработчиков.
AK>Как правильно сказал С.А.Д., мнение разработчиков в этом вопросе мало кого волнует.

это всё принимается
водопад потому и считается регрессивным процессом

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

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

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

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

МП>но только сильно недооценивается следующий фундаментальный фактор:
МП>моральные силы разработчика — это ценный, медленно возобновляемый ресурс
МП>нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день

Опять же, на скрам тренингах учат закладывать разумное время на продуктивную работу в день. Не более 4-6 часов в день.

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

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

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

Все это уже 100500 раз пройдено.

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

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

Психология это хорошо и полезно.
А вот про собственно технологию сколько часов получилось?

МП>кто на программиста учился сам, а также на непрофильной специальности — полнотой технологии скорее всего не владеет, хотя кое-что уже и понимает сам

Можно подумать, что программиста что-то в аспекте моральной энергии отличает от художника там или ученого.

P.S. А сколько часов нынче отводят на такую дисциплину, как "Анализ сценариев отказа и их последствий"?

МП>>но только сильно недооценивается следующий фундаментальный фактор:
МП>>моральные силы разработчика — это ценный, медленно возобновляемый ресурс
МП>>нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день

L>Опять же, на скрам тренингах учат закладывать разумное время на продуктивную работу в день. Не более 4-6 часов в день.

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

хинт: а не продуктивная не очень-то на самом деле и нужна

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

L>>Опять же, на скрам тренингах учат закладывать разумное время на продуктивную работу в день. Не более 4-6 часов в день.
МП>ыыыы
МП>вообще-то продуктивная работа должна максимизироваться
МП>соответственно, не менее 5-6 часов без сбитий контекста в свежем, не сонном состоянии

Ну удачи.

МП>хинт: а не продуктивная не очень-то на самом деле и нужна

У работников умственного труда без "не продуктивной" работы никакой особо продуктивной работы не получится. Разве вам в течение тех 68 часов об этом не рассказали?

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

L>Психология это хорошо и полезно.
L>А вот про собственно технологию сколько часов получилось?

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

по процессам — одно время работал в Deutsch Telecom, у них неплохой свой процесс и структурно изложенная книга по нему, называется "SE BoOK" — в 2008 мне она показалась вменяемой
на фоне скрама кажется вменяемой и сейчас, хотя все последние годы работаю в рамках того что у кого из работодателей есть, адаптируясь по обстоятельствам

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

МП>>кто на программиста учился сам, а также на непрофильной специальности — полнотой технологии скорее всего не владеет, хотя кое-что уже и понимает сам

L>

L>Можно подумать, что программиста что-то в аспекте моральной энергии отличает от художника там или ученого.

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

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

L>P.S. А сколько часов нынче отводят на такую дисциплину, как "Анализ сценариев отказа и их последствий"?

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

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

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

МП>но только сильно недооценивается следующий фундаментальный фактор:
МП>моральные силы разработчика — это ценный, медленно возобновляемый ресурс
МП>нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день

Так никто ж и не ожидает 8 часов работы.

Когда я работал в Microsoft, в моей команде были двухнедельные спринты и время на выполнение запланированных задач рассчитывалось как 25 рабочих часов в неделю. Остальное врем съедали митинги, переписка и прочее. И результат был вполне нормальным.

А вот в другой конторе я видел жуткую жуть на проекте со скрамом. Там как раз какой-то из вчерашних "скрам мастеров" получил должность директора и весь смысл работы свели к скраму ради скрама. Было много графиков, отчётов, митингов — весь менеджмент был в восторге. Вот только проект сдох.
Через год я поймал себя на мысли, что если я вообще перестану что-либо делать, то менеджмент заметит это не раньше чем через полгода. Менеджеры настолько запутались в требованиях, что за год мы этот проект три раза писали заново с нуля. Мне стало скучно, после третьего переписывания я ушёл. Коллеги потом сказали, что они ещё два раза всё переписали перед тем как проект окончательно закопали. Программисты разбежались, а менеджеры получили повышения и их всех вместе, целым подразделением, продали другой компании.

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

L>>>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам.
IT>>А что по-твоему делает этот сложный инженерный процесс сложным?
L>Ничего его не делает сложным.
L>Он такой есть. Изначально.
L>Если бы он был простым, уже давно вся разработка софта сводилась бы к набросу кубиков в чем-то вроде Rational Rose. Но пока все попытки упростить процесс его лишь усложняют.

Так, стопэ. Т.е. 20 лет назад всё было просто. А "Сегодня разработка софта — это очень сложный инженерный процесс". Вот я и спрашиваю — что по-твоему этот сложный инженерный процесс делает (сделало за 20 лет) сложным? Ты сам-то 20 лет назад на каком уровне простоты находился?

L>Что значит "перекладывая ответственность". А кто, по твоему, вообще должен отвечать за "готовность модуля"?

В аджайле? Все. Аджайл — это коллективная ответственность. Ака колхоз.

IT>>а далее с них всех вместе взятых на заказчика.
L>Не перекладывает на заказчика, а вовлекает заказчика в итеративный процесс постоянного получения обратной связи.

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

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

Аджайл делает тоже самое, только ничего не объясняя сразу говорит — давайте все вместе. Нет никакого вовлечения. Если ты громогласно обозначил проблему, а заказчик при этом промолчал, то у тебя всегда есть возможность сказать, что я же говорил, а Ирина Ваисльевна при это молча согласилась. Хотя Ирина Васильевна может вообще вчера была принята на работу и молчала потому что вообще не понимала что тут происходит.

Манифеста — она вся такая. Там только про давайте все вместе. Дружный коллектив, нерушимая дружба, передовой колхоз.

IT>>Это работает какое-то время, пока девелоперы не просекут фишку и потом это всё работает ещё медленнее, но более прогнозируемо.
L>Ну тут не кровати надо переставлять, а далее по тексту.

Ы?

IT>>Всё это решается гораздо проще — заменой менеджера в самом начале.
L>Ну заменил ты менеджера в самом начале. Чем это поможет?

Тем, что аджайл не нужен.

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

IT>>Например, митинг назначается на 9:30 утра, чтобы все выспались и все собрались. Это означает, что до этого времени никто ничем другим заниматься не будет. Далее в течении 15-20-ти минут 10 человек рассказывают друг другу ненужные и неинтересные вещи. При этом замечено, что чем меньше чел сделал, тем больше он об этом будет говорить.

L>Ну вот такое дело, что если "ненужные и неинтересные вещи", то это не скрам. А карго-культ.
L>Ну и 15-20 минут тоже уже индикатор.

Оно карго-культ по определению. Как для тебя вотерфол — это already 95% ready. Так для меня аджайл на 99% — это религия. Успешные аджайл проекты возможны при условии: ровная команда, мелкий типовой проект, нелимитированные сроки, вменяемый менеджмент. Но тогда возникает вопрос — зачем?

IT>>Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.
L>А откуда у вас следующие митинги? А работать когда?

Вообще-то это мой вопрос. На который до сих пор никто не может ответить.

L>Так это, неплохо было бы определение аджайла почитать. Вообще, ежедневный скрам для аджайла совершенно не обязателен

Я тебя умоляю. Если мы сейчас начнём читать аджайлы и не дай бог манифесту, то ржать будем до утра.

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

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

L>Тут не кровати надо переставлять, а, гхм, сотрудников, гхм, менять.

Вот! Золотые слова. Нахер хреновых менеджеров и аджайл не нужен.

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

IT>Оно карго-культ по определению. Как для тебя вотерфол — это already 95% ready.

Есть люди, которые из чего угодно сделают карго-культ

IT>Так для меня аджайл на 99% — это религия.

Естественно. Молния — это тоже божий промысел. Для тех, кто в школе физику прогуливал.

IT>спешные аджайл проекты возможны при условии: ровная команда, мелкий типовой проект, нелимитированные сроки, вменяемый менеджмент. Но тогда возникает вопрос — зачем?

Зачем на типовой проект какая-то команда? Для типового проекта берется типовое решение из типовой коробки.

IT>>>Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.
L>>А откуда у вас следующие митинги? А работать когда?

IT>Вообще-то это мой вопрос. На который до сих пор никто не может ответить.

Вот именно — откуда у вас "следующие митинги" и каким боком тут аджайл?

L>>Так это, неплохо было бы определение аджайла почитать. Вообще, ежедневный скрам для аджайла совершенно не обязателен
IT>Я тебя умоляю. Если мы сейчас начнём читать аджайлы и не дай бог манифесту, то ржать будем до утра.

Так может стоит попробовать? Ну чтобы чиста поржать?

IT>Вроде я уже говорил, что это проблема менеджмента.
IT>Вот! Золотые слова. Нахер хреновых менеджеров и аджайл не нужен.

Короче, разработчики совсем неуиоаые, виноваты менеджеры.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

L>>Все это уже 100500 раз пройдено.

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

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

Gt_

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

L>>Все это уже 100500 раз пройдено.

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

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

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

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

IT>>Я считаю, что процесс нужно организовывать под конкретный проект и руководствоваться прежде всего здравым смыслом.
L>Между прочим, именно это говорят во всех скрам тренингах.

Есть супер классическая книга на эту тему «Цель: процесс непрерывного совершенствования» Голдратт, Кокс. Там был пример по оптимизации завода, когда покупка дорогого автоматизированного оборудования замедляла процесс и приводила к убыточности и срывам сроков. Там описывается подход на основе здравого смысла, есть даже что-то от разработки ПО, но в итоге оптимальный процесс становится очень похожим на оптимизацию ПО: ставится цель, выявляются узкие места, препятствующие её выполнению, они оптимизируются, осуществляется переход к следующему узкому месту. По книге оказывается не важным, как всё организуется, главное следовать цели, делать более важное и отбрасывать менее на основе показателей, характеризующих исключительно достижение цели.
Лично мне кажется, что процесс разработки ПО надо строить аналогичным способом. Главное — это Цель, а не методология. Если надо реализовать сложный алгоритм, который не факт что окажется работающим, то бросить всё, нанять умных чуваков и штурмами, а то и параллельными командами решать проблему. Писать тесты на качество/скорость алгоритма, но не на сам код, сидеть над задачей неделями и месяцами — это норм. Если не получается, но интуиция говорит, что может сработать — надо копать. Остальную предсказуемую и детерменированную часть послать нахер и делать по остаточному признаку. То есть при планировании таких проектов оперирую не столько сроками, сколько вероятностями.
Если проект предсказуемый, есть опыт разработки, то можно разворачивать скрам и делать всё кусочками, методично пожирая проблему.
Объяляя скрам универсальным средством, который такой гибкий, что подходит подо всё, ты автоматически превращаешь его в сову.

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

IT>>>Я считаю, что процесс нужно организовывать под конкретный проект и руководствоваться прежде всего здравым смыслом.
L>>Между прочим, именно это говорят во всех скрам тренингах.
N>Объяляя скрам универсальным средством, который такой гибкий, что подходит подо всё, ты автоматически превращаешь его в сову.

В первый же день на всех скрам тренингах говорится
1. Это не универсальное средство
2. Это не серебряная пуля
3. Если у вас уже есть процесс, который для вас работает — ~~You are lucky bastrads.~~ НИ В КОЕМ СЛУЧАЕ НЕ ТРОГАЙТЕ ЕГО.
4. Если пункт 3 в вашем случае не применим, то велкам на наш тренинг.

И кто тут ССЗБ, если методологию возводят в религию?

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

L>>Если бы он был простым, уже давно вся разработка софта сводилась бы к набросу кубиков в чем-то вроде Rational Rose. Но пока все попытки упростить процесс его лишь усложняют.

IT>Так, стопэ. Т.е. 20 лет назад всё было просто.

Скорее все же >25 лет назад.
Было еще сложнее. Ввиду отсутствия кучи инструментов, которые мы сейчас принимаем за само собой разумеющееся.
В среднем размер проектов и их масштаб был меньше.
Разработка укладывалась в подход, когда за определенную систему или ее части отвечал один человек, который был на этом проекте с самого начала, знал ее вдоль, поперек и по диагонали и мог точно сказать, что можно сделать в рамках текущей реализации, что можно реализовать относительно легко, я для чего придется все выкинуть и начать с чистого листа. И точно знал, как и что нужно менять, чтобы все не развалилось. Грубо говоря, и гуру и костыльмейстер в одном лице. Он всегда мог сказать, за какое время может добавить фичу х, и все, что манагеру нужно было — это умножить эту цифру на два и подвинуть сроки проекта таким образом, чтобы дедлайн не попадал на сезон отпусков.

Софт банально стал больше. Изменился рынок. Сроки стали поджимать чаще. Выезжать на авралах стало сложнее.
Плюс еще все меньшая пропорция кода стала оставаться под опекой специально выделенного гуру. По разным причинам.
Возникла необходимость разделять ответственность между людьми.
И вот тут уже начались грабли. Если в строительстве в общем случае добавлением второго экскаватора можно сократить время на копку котлована вдвое, то в разработке софта почему-то зачастую получалось очень даже наоборот.
Были попытки решить эту проблему формализацией. Дотошными ТЗ, на написание которых уходили годы, которые начинали противоречить реализации буквально после 10 коммитов.
Были попытки решать проблему дизайном вообще всего еще до начала разработки. Чтобы было как на стройке — вот это фундамент, вот это стены, а обои будем клеить в последнюю очередь. Результат все знают.

IT>А "Сегодня разработка софта — это очень сложный инженерный процесс". Вот я и спрашиваю — что по-твоему этот сложный инженерный процесс делает (сделало за 20 лет) сложным? Ты сам-то 20 лет назад на каком уровне простоты находился?

Переход на личности — некрасиво.

L>>Что значит "перекладывая ответственность". А кто, по твоему, вообще должен отвечать за "готовность модуля"?
IT>В аджайле? Все. Аджайл — это коллективная ответственность. Ака колхоз.

Ну говорю же, по телефону Рабинович напел.

IT>Ы?

IT>>>Всё это решается гораздо проще — заменой менеджера в самом начале.
L>>Ну заменил ты менеджера в самом начале. Чем это поможет?

IT>Тем, что аджайл не нужен.

Ну заменил ты менеджера. Проект опять в жопе. Причем тут аджайл?

AK>Так никто ж и не ожидает 8 часов работы.

AK>Когда я работал в Microsoft, в моей команде были двухнедельные спринты и время на выполнение запланированных задач рассчитывалось как 25 рабочих часов в неделю. Остальное врем съедали митинги, переписка и прочее. И результат был вполне нормальным.

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

AK>А вот в другой конторе я видел жуткую жуть на проекте со скрамом. Там как раз какой-то из вчерашних "скрам мастеров" получил должность директора и весь смысл работы свели к скраму ради скрама. Было много графиков, отчётов, митингов — весь менеджмент был в восторге. Вот только проект сдох.
AK>Через год я поймал себя на мысли, что если я вообще перестану что-либо делать, то менеджмент заметит это не раньше чем через полгода. Менеджеры настолько запутались в требованиях, что за год мы этот проект три раза писали заново с нуля. Мне стало скучно, после третьего переписывания я ушёл. Коллеги потом сказали, что они ещё два раза всё переписали перед тем как проект окончательно закопали. Программисты разбежались, а менеджеры получили повышения и их всех вместе, целым подразделением, продали другой компании.

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

неужели полгода стоит на это терять?

L>3. Если у вас уже есть процесс, который для вас работает — ~~You are lucky bastrads.~~ НИ В КОЕМ СЛУЧАЕ НЕ ТРОГАЙТЕ

мм эти слова дают понять, что автор не спец и плывёт в теме
представляю, если бы отношение к софту было таким же
либо автор не верит в достаточную компетентность в индустрии в целом, чтобы успешно менять процессы (что похоже на правду)
но так чтобы "НИ В КОЕМ СЛУЧАЕ"
почему? я может вижу как можно улучшить конкретный процесс...

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

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

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

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

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

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

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

N>Есть супер классическая книга на эту тему «Цель: процесс непрерывного совершенствования» Голдратт, Кокс. Там был пример по оптимизации завода, когда покупка дорогого автоматизированного оборудования замедляла процесс и приводила к убыточности и срывам сроков. Там описывается подход на основе здравого смысла, есть даже что-то от разработки ПО, но в итоге оптимальный процесс становится очень похожим на оптимизацию ПО: ставится цель, выявляются узкие места, препятствующие её выполнению, они оптимизируются, осуществляется переход к следующему узкому месту. По книге оказывается не важным, как всё организуется, главное следовать цели, делать более важное и отбрасывать менее на основе показателей, характеризующих исключительно достижение цели.
N>Лично мне кажется, что процесс разработки ПО надо строить аналогичным способом. Главное — это Цель, а не методология. Если надо реализовать сложный алгоритм, который не факт что окажется работающим, то бросить всё, нанять умных чуваков и штурмами, а то и параллельными командами решать проблему. Писать тесты на качество/скорость алгоритма, но не на сам код, сидеть над задачей неделями и месяцами — это норм. Если не получается, но интуиция говорит, что может сработать — надо копать. Остальную предсказуемую и детерменированную часть послать нахер и делать по остаточному признаку. То есть при планировании таких проектов оперирую не столько сроками, сколько вероятностями.
N>Если проект предсказуемый, есть опыт разработки, то можно разворачивать скрам и делать всё кусочками, методично пожирая проблему.
N>Объяляя скрам универсальным средством, который такой гибкий, что подходит подо всё, ты автоматически превращаешь его в сову.

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

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

L>>3. Если у вас уже есть процесс, который для вас работает — ~~You are lucky bastrads.~~ НИ В КОЕМ СЛУЧАЕ НЕ ТРОГАЙТЕ
МП>мм эти слова дают понять, что автор не спец и плывёт в теме

МП>почему? я может вижу как можно улучшить конкретный процесс...

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

МП>>почему? я может вижу как можно улучшить конкретный процесс...

L>Улучшай, кто тебе запрещает?
L>Только вот конкретных предложений от тебя не слышно. Только "Scrum не подходит для программной разработки"

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

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

L>>Только вот конкретных предложений от тебя не слышно. Только "Scrum не подходит для программной разработки"
МП>ну скрам улучшается радикальным сокращением митингов
МП>только после этого он перестанет быть скрамом по определению

В определении скрама нет никакого дикого количества митингов.

V>О, радует что кто-то еще работает по теории ограничения систем. А то все споры — scrum, водопад, нет бы взять лучшее из практик. Как будто в университетах не было предмета — Системология.

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

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

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

Проекты стали сложнее, конкуренции стало больше. Нужно делать макс. качественно и быстро.

IT>Аджайл делает тоже самое, только ничего не объясняя сразу говорит — давайте все вместе. Нет никакого вовлечения. Если ты громогласно обозначил проблему, а заказчик при этом промолчал, то у тебя всегда есть возможность сказать, что я же говорил, а Ирина Ваисльевна при это молча согласилась. Хотя Ирина Васильевна может вообще вчера была принята на работу и молчала потому что вообще не понимала что тут происходит.

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

Не знаю на сколько по аджайлу можно разрабатывать сложные инженерные продукты -- ОС, компиляторы, ядра бд,
поисковой движок, т.е. там на спринты не так легко задачи побить. Еще точнее, там, где для решения
задач нужна длительная работа штучных специалистов, возможно в команде. Ну скажет человек, что
сделает от 3 до 6 месяцев, ну ладно, а куда деваться?

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

IT>Вот! Золотые слова. Нахер хреновых менеджеров и аджайл не нужен.

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

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

N>Лично мне кажется, что процесс разработки ПО надо строить аналогичным способом. Главное — это Цель, а не методология. Если надо реализовать сложный алгоритм, который не факт что окажется работающим, то бросить всё, нанять умных чуваков и штурмами, а то и параллельными командами решать проблему. Писать тесты на качество/скорость алгоритма, но не на сам код, сидеть над задачей неделями и месяцами — это норм. Если не получается, но интуиция говорит, что может сработать — надо копать. Остальную предсказуемую и детерменированную часть послать нахер и делать по остаточному признаку. То есть при планировании таких проектов оперирую не столько сроками, сколько вероятностями.

Это вообще R&D проекты, при чем там скрам? Скрам как раз про детерменированные проекты, где нужно получить результат.
Т.е. как и где копать понятно, нужно просто эффективно копать.

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

МП>на дисциплину это не тянет

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

МП>>на дисциплину это не тянет

L>В одной малоизвестной компании, производящей летательные аппараты тяжелее воздуха, тоже недавно так думали.

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

а если речь про Boeing 737Max, то дело там даже не в том
мне рассказыавал ознакомившийся с материалами человек, типа компетентный Рабинович напел следующее:
был быдлокод
в частности методы на многие экраны, и прочие перлы,
но он подвергался кодеревью опытных специалистов
(отдельный вопрос к ревьерам, что они вообще годами терпели такой код в такой опасной отрасли)
но крах случился даже не потому, а по обычной капиталистической жадности:
менеджеры не вписывались в бюджет и загнали исполнителей в заведомо пагубные условия

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

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

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

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

IT>>Оно карго-культ по определению. Как для тебя вотерфол — это already 95% ready.
L>Есть люди, которые из чего угодно сделают карго-культ

Люди они такие. Особенно если оно им вовсе не надо, но в их жизнь лезут всякие миссионеры-коучеры со своим "и собрались 17 апостолов и написали они манифесту, аминь".

IT>>Так для меня аджайл на 99% — это религия.
L>Естественно. Молния — это тоже божий промысел. Для тех, кто в школе физику прогуливал.

Именно. Вот я не прогуливал и понимаю, что это в чистом виде религия.

IT>>Вообще-то это мой вопрос. На который до сих пор никто не может ответить.
L>Вот именно — откуда у вас "следующие митинги" и каким боком тут аджайл?

Sprint Planning на пару часиков. Tech Refinement по часу пару раз в неделю. Sprint Review/Demo два часа. Часик Sprint Retrospective. Это то, что быстро вспомнилось. Ещё top management любит раз-два в неделю эпически явить свой лик народу. Ну и по мелочи там всякого постоянно.

L>Так может стоит попробовать? Ну чтобы чиста поржать?

Попробуй. Я уже поржал.

L>Короче, разработчики совсем неуиоаые, виноваты менеджеры.

Ты этого не знал?

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

IT>>Так, стопэ. Т.е. 20 лет назад всё было просто.
L>Скорее все же >25 лет назад.

Давай сразу уже возьмём 45. Деревянные перфокарты, бумажные перфоленты...

L>Было еще сложнее. Ввиду отсутствия кучи инструментов, которые мы сейчас принимаем за само собой разумеющееся.

По большому счёту реально не хватало только SVC систем.

L>В среднем размер проектов и их масштаб был меньше.

Серьёзно?

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

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

L>Софт банально стал больше. Изменился рынок. Сроки стали поджимать чаще. Выезжать на авралах стало сложнее.

С чего бы?

L>Возникла необходимость разделять ответственность между людьми.

Эта необходимость была всегда.

IT>>А "Сегодня разработка софта — это очень сложный инженерный процесс". Вот я и спрашиваю — что по-твоему этот сложный инженерный процесс делает (сделало за 20 лет) сложным? Ты сам-то 20 лет назад на каком уровне простоты находился?
L>Переход на личности — некрасиво.

Некрасиво, но справедливо.

IT>>В аджайле? Все. Аджайл — это коллективная ответственность. Ака колхоз.
L>Ну говорю же, по телефону Рабинович напел.

Т.е. это вот так должно быть красиво?

IT>>Тем, что аджайл не нужен.
L>Ну заменил ты менеджера. Проект опять в жопе. Причем тут аджайл?

При том, что не надо что-либо заменять на аджайл. Нужно сразу менять менеджмент. И дешевле и производительней.

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

IT>Люди они такие. Особенно если оно им вовсе не надо, но в их жизнь лезут всякие миссионеры-коучеры со своим "и собрались 17 апостолов и написали они манифесту, аминь".

Ну так можно и не идти туда, где "миссионеры-коучеры".

IT>>>Так для меня аджайл на 99% — это религия.
L>>Естественно. Молния — это тоже божий промысел. Для тех, кто в школе физику прогуливал.
IT>Именно. Вот я не прогуливал и понимаю, что это в чистом виде религия.

Что? Молния?

IT>>>Вообще-то это мой вопрос. На который до сих пор никто не может ответить.
L>>Вот именно — откуда у вас "следующие митинги" и каким боком тут аджайл?
IT>Sprint Planning на пару часиков.

Это один раз в спринт. Равно как и ретроспектива.

IT>Tech Refinement по часу пару раз в неделю. Sprint Review/Demo два часа. Часик Sprint Retrospective. Это то, что быстро вспомнилось.

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

IT>Ещё top management любит раз-два в неделю эпически явить свой лик народу. Ну и по мелочи там всякого постоянно.

Ну, с этого и надо было начинать.

L>>Короче, разработчики совсем неуиоаые, виноваты менеджеры.
IT>Ты этого не знал?

А багами в репу насрали тоже манагеры?

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

L>>Переход на личности — некрасиво.
IT>Некрасиво, но справедливо.

В общем, я от темы отписываюсь.
Вы с министром правы, скрам — это религия, во всем виноваты менеджеры.

They Write the Right Stuff
As the 120-ton space shuttle sits surrounded by almost 4 million pounds of rocket fuel, exhaling noxious fumes, visibly impatient to defy gravity, its on-board computers take command.
https://www.fastcompany.com/28121/they-write-right-stuff

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

S>Проекты стали сложнее, конкуренции стало больше. Нужно делать макс. качественно и быстро.

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

S>У меня по аджайлу практически нету опыта, но по чтению лит-ры, обсуждений и проч. пришел к выводу, что
S>аджайла не только про ответственность. Это такой процесс, который улучшает контроль за происходящим
S>(project owner), активная обратная связь, погруженность всех и вся в контекст, активное общение и т.п.

Это всё в теории. Если бы всё было так как пишут в книжках, то Илон Маск жил бы уже давно на Марсе, а не скупал бы биточки.

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

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

S>Не знаю на сколько по аджайлу можно разрабатывать сложные инженерные продукты -- ОС, компиляторы, ядра бд,
S>поисковой движок, т.е. там на спринты не так легко задачи побить. Еще точнее, там, где для решения
S>задач нужна длительная работа штучных специалистов, возможно в команде. Ну скажет человек, что
S>сделает от 3 до 6 месяцев, ну ладно, а куда деваться?

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

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

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

скрам появился в начале нулевых и никуда вроде не собиратся, это не какая-то мода

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

у таких есть какие-то мысли, или только душнилово на тему собственной ислкючительности?
весь big-tech, всякие там FAANG-и и прочий крупняк, с проектами в которых участвуют сотни человек, длящиеся годами, моут в скрам, а вот всякая мелочь обычно не может осилить, ну и обычно там у мелочи находится какой-нибдуь Вася программист, который готов всем объяснить, что скрам это для слабаков, вот он — круой специалист, у него за плечами десятки проектов (джейсономолотилка для банка, конфигуратор генератора джейсона для склада и тд), поэтому он плевать хотел и ничего не будет делать, либо он — либо скрам

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

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

Буквально из моего предыдущего ответа цитирую себя любимого:

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

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

IT>>Люди они такие. Особенно если оно им вовсе не надо, но в их жизнь лезут всякие миссионеры-коучеры со своим "и собрались 17 апостолов и написали они манифесту, аминь".
L>Ну так можно и не идти туда, где "миссионеры-коучеры".

Они сами к нам пришли. Мы великолепно жили без них и их аджейла.

L>Что? Молния?

Что молния?

IT>>Sprint Planning на пару часиков.
L>Это один раз в спринт. Равно как и ретроспектива.

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

IT>>Tech Refinement по часу пару раз в неделю. Sprint Review/Demo два часа. Часик Sprint Retrospective. Это то, что быстро вспомнилось.
L>Ну так может быть, они имеют смысл? А если нет, то их и проводить совершенно необязательно.

Ты чо?

Это уже не аджайл! Церемонии священны!

IT>>Ещё top management любит раз-два в неделю эпически явить свой лик народу. Ну и по мелочи там всякого постоянно.
L>Ну, с этого и надо было начинать.

С чего именно?

L>А багами в репу насрали тоже манагеры?

С чего ты взял, что у нас баги в репу?

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

CK>скрам появился в начале нулевых и никуда вроде не собиратся, это не какая-то мода

До начала десятых до него никому не было дела и о нём никто не знал. В моду он стал входить в начале десятых.

CK>у таких есть какие-то мысли, или только душнилово на тему собственной ислкючительности?

Какая уж исключительность при аджайле?

CK>весь big-tech, всякие там FAANG-и и прочий крупняк, с проектами в которых участвуют сотни человек,

Сотни человек? Скрам? Ты ничего не путаешь? Погугли про размер эффективной скрам команды.

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

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

У вас есть рецепт как работать с большей эффективностью?

МП>может потому они больше и не лидеры

А кто лидер? И как считаем?

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

МП>я только что уволился из этого сразу же, на испытательном сроке
МП>неужели полгода стоит на это терять?

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

Плюс, были другие причины задержаться. Я получил довольно хороший sign-in bonus — около $50K, если б я ушёл менее чем через год, то мне пришлось бы его вернуть. А когда полгода уже проработал, то терять бонус из-за нескольких месяцев уже не хотелось. Плюс, несмотря на совершенно профнепригодный проектный менеджмент, технический директор там был вполне толковый мужик, я с ним сдружился и потом ещё с ним в другой конторе работал. Сейчас он директорствует где-то в Salesforce и может быть ещё когда-нибудь с ним пересекусь.

И часть разработчиков была очень толковая, я многому у них научился из облачных технологий — аутентификация и авторизация облачных сервисов сама по себе тема непростая, а когда на это накладывается ещё и "multi-tenancy", то получается довольно заковыристо. Ну сейчас я уже понимаю, что такой же набор требований лежит в основе любого SaaS-стартапа, но на тот момент для меня это было в новинку, получил ценный опыт. А ещё освоил Angular, это был мой первый удачный опыт использования JavaScript. До этого мне приходилось сталкиваться с KnockoutJS в Microsoft и для меня это был ужас ужасный, я выработал в себе резкое отвращение к JavaScript и был уверен, что вообще никогда не соглашусь потрогать это снова. Но в той конторе был хороший UI-архитектор, он дал нам проработанный UI каркас приложения на основе AngularJS, на который мы уже потом прикручивали нужный функционал.

Так что за год работы я набрался ценного опыта и знаний, что мне потом очень пригодилось в дальнейшей карьере. Пришёл я туда обычным синьором, а ушёл через год уже претендуя на должности staff/principal.

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

IT>До начала десятых до него никому не было дела и о нём никто не знал. В моду он стал входить в начале десятых.

даже если так, 10+ лет

CK>>у таких есть какие-то мысли, или только душнилово на тему собственной ислкючительности?
IT>Какая уж исключительность при аджайле?

мой поинт как раз в том, что некоторым не нравится отсутствие исключительности

CK>>весь big-tech, всякие там FAANG-и и прочий крупняк, с проектами в которых участвуют сотни человек,
IT>Сотни человек? Скрам? Ты ничего не путаешь? Погугли про размер эффективной скрам команды.

само собой не в одной команде

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

МП>>>на дисциплину это не тянет

L>>В одной малоизвестной компании, производящей летательные аппараты тяжелее воздуха, тоже недавно так думали.

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

МП>а если речь про Boeing 737Max, то дело там даже не в том
МП>мне рассказыавал ознакомившийся с материалами человек, типа компетентный Рабинович напел следующее:
МП>был быдлокод
МП>в частности методы на многие экраны, и прочие перлы,
МП>но он подвергался кодеревью опытных специалистов
МП>(отдельный вопрос к ревьерам, что они вообще годами терпели такой код в такой опасной отрасли)
МП>но крах случился даже не потому, а по обычной капиталистической жадности:
МП>менеджеры не вписывались в бюджет и загнали исполнителей в заведомо пагубные условия

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

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

TG>У вас есть рецепт как работать с большей эффективностью?

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

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

Кажется работоспособным процесс из Deutsch Telecom, называется "SE BoOK"
Мне самому быстрее работать не по нему, но средние команды могли бы его использовать

UPD: осознал, что ответил в общем, не применительно к MS, продолжу:
в Майкрософте работают не средние, соответственно, можно было бы оптимизировать работу для раскрытия по возможности не 5 часов моральных сил, а 6
ну и как-то предусмотреть возможности для полёта мысли, когда разработчик входит в поток и может выдавать большую производительность
нужно закрепить возможность нажать кнопку "отъехать", переключающую режим в "не беспокоить", чтобы бюрократические процессы не вредили
хотя похоже они там забюрократизировались уже давно, на эту мысль наводили ещё в нулевых детали реализаций разных частей, описанных в MSDN
там местами хороший разработчик так бы вообще мыслить не стал, но чувствовалась поступь надёжного программирования, с результатом, даже если не изящно

МП>>может потому они больше и не лидеры

TG>А кто лидер? И как считаем?

кажется Гугл
но в эту войну я не хочу вступать

МП>>я только что уволился из этого сразу же, на испытательном сроке
МП>>неужели полгода стоит на это терять?

AK>За неделю я мало что понял. Всю первую неделю, когда я пришёл туда, мы вообще провели за "планированием" на последующие несколько месяцев. Что происходит с проектом, я начал понимать только через полгода, когда стало очевидно, что менеджмент забыл обсудить детали интеграции с партнёрской компанией и пока мы разрабатывали сервисы для первой версии партнёрской платформы, те выкатили новую версию, совершенно несовместимую с предыдущей. Потом, кстати, эта же история повторилась ещё раз, ещё через полгода. Архитектором на проект почему-то поставили совершеннейшего дол...ба, который в разработке софта вообще не разбирался, он по профессии был электриком.

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

AK>Плюс, были другие причины задержаться. Я получил довольно хороший sign-in bonus — около $50K, если б я ушёл менее чем через год, то мне пришлось бы его вернуть. А когда полгода уже проработал, то терять бонус из-за нескольких месяцев уже не хотелось. Плюс, несмотря на совершенно профнепригодный проектный менеджмент, технический директор там был вполне толковый мужик, я с ним сдружился и потом ещё с ним в другой конторе работал. Сейчас он директорствует где-то в Salesforce и может быть ещё когда-нибудь с ним пересекусь.
AK>И часть разработчиков была очень толковая, я многому у них научился из облачных технологий — аутентификация и авторизация облачных сервисов сама по себе тема непростая, а когда на это накладывается ещё и "multi-tenancy", то получается довольно заковыристо. Ну сейчас я уже понимаю, что такой же набор требований лежит в основе любого SaaS-стартапа, но на тот момент для меня это было в новинку, получил ценный опыт. А ещё освоил Angular, это был мой первый удачный опыт использования JavaScript. До этого мне приходилось сталкиваться с KnockoutJS в Microsoft и для меня это был ужас ужасный, я выработал в себе резкое отвращение к JavaScript и был уверен, что вообще никогда не соглашусь потрогать это снова. Но в той конторе был хороший UI-архитектор, он дал нам проработанный UI каркас приложения на основе AngularJS, на который мы уже потом прикручивали нужный функционал.
AK>Так что за год работы я набрался ценного опыта и знаний, что мне потом очень пригодилось в дальнейшей карьере. Пришёл я туда обычным синьором, а ушёл через год уже претендуя на должности staff/principal.

понятно, имело смысл

но моё шоу сорвалось

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

IT>>До начала десятых до него никому не было дела и о нём никто не знал. В моду он стал входить в начале десятых.
CK>даже если так, 10+ лет

Ну и? У нас он уже года 4. Нам его навязали сверху, типа попробуйте. Но так как образцовая команда даже такую хрень способна пережить, то опыт объявили успешным и решили распространять. Наши доводы про резкое снижение производительности в игнор. Зато ведь транспаренси! А кто вам это транспаренси рисует? Мы же сами и рисуем. Мы же не идиоты показывать негативные цифры тем, от кого зависит наш бонус.

Если 10+ — это такие как у нас, то это в чистом виде очковтирательство. Аджайл — методология очковтирательства.

IT>>Какая уж исключительность при аджайле?
CK>мой поинт как раз в том, что некоторым не нравится отсутствие исключительности

От, блин, вам исключительности не нравятся. Почитай хотя бы Роберта Гласса "Факты и заблуждения профессионального программирования". А конкретно

Факт 2.
По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть, что оплата их труда никогда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО.

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

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

CK>>>весь big-tech, всякие там FAANG-и и прочий крупняк, с проектами в которых участвуют сотни человек,
IT>>Сотни человек? Скрам? Ты ничего не путаешь? Погугли про размер эффективной скрам команды.
CK>само собой не в одной команде

Т.е. сотни человек — это больше не аргумент в пользу аджайла?

IT>Ну и? У нас он уже года 4. Нам его навязали сверху, типа попробуйте. Но так как образцовая команда даже такую хрень способна пережить, то опыт объявили успешным и решили распространять. Наши доводы про резкое снижение производительности в игнор. Зато ведь транспаренси! А кто вам это транспаренси рисует? Мы же сами и рисуем. Мы же не идиоты показывать негативные цифры тем, от кого зависит наш бонус.

IT>Если 10+ — это такие как у нас, то это в чистом виде очковтирательство. Аджайл — методология очковтирательства.

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

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

IT>Буквально из моего предыдущего ответа цитирую себя любимого:
IT>Покажите мне какой механизм в аджайле и каким волшебным образом делает из толпы бездельников и лаботрясов, возглавляемых тупым выскочкой высокопроизводительную команду профессионалов, управляемую эффективным менеджером. Вот конкретно. Покажите.
Обратная связь по числу закрытых тикетов и выполненных milestone'ов. Очень объективные метрики.

Здравствуйте, Cyberax, Вы писали:
IT>>Буквально из моего предыдущего ответа цитирую себя любимого:
IT>>Покажите мне какой механизм в аджайле и каким волшебным образом делает из толпы бездельников и лаботрясов, возглавляемых тупым выскочкой высокопроизводительную команду профессионалов, управляемую эффективным менеджером. Вот конкретно. Покажите.
C>Обратная связь по числу закрытых тикетов и выполненных milestone'ов. Очень объективные метрики.
это часто превращается в игру "налепи заплатку, закрой тикет и перекинь проблему на другого"

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

IT>>>Покажите мне какой механизм в аджайле и каким волшебным образом делает из толпы бездельников и лаботрясов, возглавляемых тупым выскочкой высокопроизводительную команду профессионалов, управляемую эффективным менеджером. Вот конкретно. Покажите.
C>>Обратная связь по числу закрытых тикетов и выполненных milestone'ов. Очень объективные метрики.
__>это часто превращается в игру "налепи заплатку, закрой тикет и перекинь проблему на другого"
Такое обычно быстро ловится вышестоящими менеджерами.

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

Я работал с RUP в начале 2000-х. Это был кошмар из-за того, что внесение изменений практически было невозможно без тонн геморроя.

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

IT>Именно. Вот я не прогуливал и понимаю, что это в чистом виде религия.

Что-то ты точно прогуливал, поскольку не отличаешь скрам от аджайла.
Скрам это один из фреймворков (и точно не везде подходит), а аджайл — методология.

IT>Sprint Planning на пару часиков. Tech Refinement по часу пару раз в неделю. Sprint Review/Demo два часа. Часик Sprint Retrospective. Это то, что быстро вспомнилось. Ещё top management любит раз-два в неделю эпически явить свой лик народу. Ну и по мелочи там всякого постоянно.
Тут проблема не в скраме, а отсутствии контроля времени. У нас, например, на планирование в неделю тратиться 15-30 минут, на рефайнмент 1 час, 15 минут на демо и 15-45 минут на ревью.
Ты, критикуя, предлагай. Чем ты бы это заменил? Случайным выбиранием задания из бэклога? Или вообще из головы, потому что бэклог это уже аджайл? Чем заменить рефйнмент? Революционным чутьем или пачкой формальной документации на каждую задачу? Опиши свой идеальный процесс.

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

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

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

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

IT>Ну и? У нас он уже года 4. Нам его навязали сверху, типа попробуйте. Но так как образцовая команда даже такую хрень способна пережить, то опыт объявили успешным и решили распространять. Наши доводы про резкое снижение производительности в игнор. Зато ведь транспаренси! А кто вам это транспаренси рисует? Мы же сами и рисуем. Мы же не идиоты показывать негативные цифры тем, от кого зависит наш бонус.

ну это говорит не в вашу пльзу

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

IT>Если 10+ — это такие как у нас, то это в чистом виде очковтирательство. Аджайл — методология очковтирательства.

не такие как у вас, поверь

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

CK>>мой поинт как раз в том, что некоторым не нравится отсутствие исключительности

IT>От, блин, вам исключительности не нравятся. Почитай хотя бы Роберта Гласса "Факты и заблуждения профессионального программирования". А конкретно

IT>

IT>Факт 2.
IT>По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть, что оплата их труда никогда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО.

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

IT>Как ты думаешь, если у этих ребят зарплата не в 28 раз выше, то чем они её добирают? Правильно, прокачкой доминантности. Аджайл таких ребят очень быстро вымывает из команды. И по факту в ней остаются одни посредственности. И они то как раз горой за аджайл, ведь он теперь позволяет им прокачивать их доминантность и чувствовать себя как минимум не хуже хайев на митингах, а если ещё и язык подвешен, то у такой вчерашней посредственности вообще всё хорошо.

самые ТОП люди с которыми я работал и работаю — очень простые ребята, в этот список входят, например, несколькло членов коммитета стандартизации с++ и разаботчики СУБД с кучей публикаций в профильных журналах вроде vldb, jpdc итд

IT>Т.е. сотни человек — это больше не аргумент в пользу аджайла?

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

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

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

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

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

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

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

МП>можно основные тезисы?

Ну, конкретно предмет Системология — это теория организации систем в общем случае и способы управления этими системами.Правда, это было пару десятков лет назад, сейчас, скорее всего, название изменилось.
А тезисы теории ограничения систем (Theory of Constraints), они сводятся к нескольким направлениям:
— управление проектами по методу критической цепи (это просто тот же самый способ управления по критическому пути но при загрузке ресурсов при межпроектном взаимодействии)
— управление потоком работ по методу Барабан-Буфер-Канат

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

В книге, которую упомянул Nuzhny, конечно, про IT нет ни слова, да и она художественная, служит просто для заманихи в тему, но если дальше литературу копнуть, там выделяются общие принципы управления системами, в том числе и организации разработки и внедрения ПО.

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

C>Обратная связь по числу закрытых тикетов и выполненных milestone'ов. Очень объективные метрики.

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

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

PJ>Что-то ты точно прогуливал, поскольку не отличаешь скрам от аджайла.
PJ>Скрам это один из фреймворков (и точно не везде подходит), а аджайл — методология.

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

PJ>Тут проблема не в скраме, а отсутствии контроля времени. У нас, например, на планирование в неделю тратиться 15-30 минут, на рефайнмент 1 час, 15 минут на демо и 15-45 минут на ревью.

А почему не 5-7 минут или 20-30?

PJ>Ты, критикуя, предлагай. Чем ты бы это заменил? Случайным выбиранием задания из бэклога? Или вообще из головы, потому что бэклог это уже аджайл? Чем заменить рефйнмент? Революционным чутьем или пачкой формальной документации на каждую задачу? Опиши свой идеальный процесс.

Я уже предлагал. Почитай тему внимательно.

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

CK>самые ТОП люди с которыми я работал и работаю — очень простые ребята, в этот список входят, например, несколькло членов коммитета стандартизации с++ и разаботчики СУБД с кучей публикаций в профильных журналах вроде vldb, jpdc итд

В "и т. д." входят журналы, издаваемые в Лондоне?

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

IT>>Если 10+ — это такие как у нас, то это в чистом виде очковтирательство. Аджайл — методология очковтирательства.
CK>не такие как у вас, поверь

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

О! Мне пять лет всякие недо-коучеры втирают про правильный аджайл, но куда им до тебя. Давай теперь ты расскажи. Может я проникнусь и осознаю.

История из жизни про правильное.

Лет 15 назад на этом самом форуме периодически появлялись всякие умники и с умным видом поглядывая на всё это сборище свысока произносили:

— Вы все ничего не понимаете, функциональное программирование — вот это круто!

Им отвечали:

— О! Класс! Расскажи нам, что есть ФП?
— ФП — это круто!
— Это понятно, но что это такое?
— ФП — это... вы ничего не понимаете!

И так далее по кругу.

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

CK>странно что не в 280 или не в 2800,

Не странно. Советую поинтересоваться вопросами морфологии мозга. В частности количественными и структурными различиями всяких там зон/подзон. Тебя же не смущает тот факт, что есть люди с абсолютным слухом, а есть которым медведь на ухо наступил.

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

Бывает. Только сдаётся мне тебе за исключительность как раз гонор и выдавали. Есть такие уники.

CK>самые ТОП люди с которыми я работал и работаю — очень простые ребята, в этот список входят, например, несколькло членов коммитета стандартизации с++ и разаботчики СУБД с кучей публикаций в профильных журналах вроде vldb, jpdc итд

Ты забыл упомянуть про их компенсацию.

IT>>Т.е. сотни человек — это больше не аргумент в пользу аджайла?

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

Но в одной команде всего 10 человек? И команды между собой взаимодействуют не с помощью аджайлов, так? Т.е. ещё раз спрашиваю, сотни человек — это больше не аргумент в пользу аджайла?

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

S>Вы же ниже сами отвечаете себе -- надзорные механизмы. Вот только задача увеличить производительность как можно дольше. Т.е. бездельникам и лоботрясам при скраме будет оченно неуютно и они либо возьмутся за дело, либо (их) свалят.

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

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

S>Интересное наблюдение, но вот мне кажется, что за счет уравнивания (почему, кстати, по худшему, а не по среднему?)

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

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

К сожалению предсказательность растёт вместе со сроками. Как у нас. Предсказательность толи выросла, толи нет. А скроки точно выросли в 3-5 раз.

Здравствуйте, Cyberax, Вы писали:
C>>>Обратная связь по числу закрытых тикетов и выполненных milestone'ов. Очень объективные метрики.
__>>это часто превращается в игру "налепи заплатку, закрой тикет и перекинь проблему на другого"
C>Такое обычно быстро ловится вышестоящими менеджерами.
сильно сомневаюсь

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

C>Я работал с RUP в начале 2000-х. Это был кошмар из-за того, что внесение изменений практически было невозможно без тонн геморроя.
ой, про это вообще забыть стоит

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

о правильном аджайле может знать только Герман Оскарович Греф
"Аджъаййллл"
только сегодня звонила дочка Сбера просили рассмотреть их вакансию
я как услышал Сбер, сразу стал отказываться
женщина пожаловалась, что многие сразу отказываются

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

CK>>самые ТОП люди с которыми я работал и работаю — очень простые ребята, в этот список входят, например, несколькло членов коммитета стандартизации с++ и разаботчики СУБД с кучей публикаций в профильных журналах вроде vldb, jpdc итд

mgu>В "и т. д." входят журналы, издаваемые в Лондоне?

научные журналы хоть?

IT>Лет 15 назад на этом самом форуме периодически появлялись всякие умники и с умным видом поглядывая на всё это сборище свысока произносили:

IT>- Вы все ничего не понимаете, функциональное программирование — вот это круто!
IT>Им отвечали:
IT>- О! Класс! Расскажи нам, что есть ФП?
IT>- ФП — это круто!
IT>- Это понятно, но что это такое?
IT>- ФП — это... вы ничего не понимаете!

IT>И так далее по кругу.

я тут могу всё сейчас объяснить:
ФП — это Хаскель, из которого взяли LINQ и внедрили в C#

это ФП оказалось довольно миленьким и полезным, что не напрашивалось, глядя только на Хаскель

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

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

L>>>Все это уже 100500 раз пройдено.

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

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

L>>>Все это уже 100500 раз пройдено.

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

МП>я тут могу всё сейчас объяснить:
МП>ФП — это Хаскель, из которого взяли LINQ и внедрили в C#
МП>это ФП оказалось довольно миленьким и полезным, что не напрашивалось, глядя только на Хаскель

Может ты ещё и монады внятно объяснишь?

МП>Можем обсудить почему именно.
Ну, например, см "Черная книга Скрам" http://scrumblackbook.pmlead.ru/
Я давно говорю, что Скрам — это не для программистов. Это для бизнеса и менеджеров.

P.S. У нас из-за некоторой специфики прижился канбан. Точнее "типа Канбан" (или как его называют "протоКанбан") Лично мне он комфортнее.

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

C>Я работал с RUP в начале 2000-х. Это был кошмар из-за того, что внесение изменений практически было невозможно без тонн геморроя.

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

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

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

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

IT>А почему не 5-7 минут или 20-30?
Потому что 30 максимум и достаточно, а 15 обычно хватает. Если 30 минут недостаточно чтобы решить, что делать на неделе, то проблема явно не в скраме.

IT>Я уже предлагал. Почитай тему внимательно.
Я читал, не нашел. Пальцем покажи. Выгнать менеджера это не метод.

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

IT>- О! Класс! Расскажи нам, что есть ФП?
IT>- ФП — это круто!
IT>- Это понятно, но что это такое?
IT>- ФП — это... вы ничего не понимаете!

IT>И так далее по кругу.

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

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

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

I>Почему это в аджайлле не получится? Как раз получится. По вотерфолу все таски сделал и сдал проект. А по аджайлу будешь генерировать новые таски быстрее, чем команда будет с текущими справляться.

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

Gt_

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

IT>>С этой хрени начинается любая методичка по скраму. Но боюсь, большиство не смогут кратко и внятно объяснить, что значит эта мантра. Ты сможешь?
PJ>Одно про цель, которую хочется достигнуть, а второе это способ как именно ее достигать. Путей, разумеется, больше одного.

Я бы сказал что одно это теория, а второе это её практическое воплощение. И чем наши определения отличаются?

IT>>А почему не 5-7 минут или 20-30?
PJ>Потому что 30 максимум и достаточно, а 15 обычно хватает. Если 30 минут недостаточно чтобы решить, что делать на неделе, то проблема явно не в скраме.

Это очень субъективно. Лично мне и 3-х минут один раз в неделю достаточно, чтобы решить, что делать. А если речь идёт о новой большой задаче, то запросто может уйти пару дней на обсуждение. Почему я должен обязательно тратить именно в день именно 15-30 минут?

IT>>Я уже предлагал. Почитай тему внимательно.
PJ>Я читал, не нашел. Пальцем покажи. Выгнать менеджера это не метод.

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

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

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

Я был не один такой. Или ты всех тогдашних посетителей этого форума считаешь круглими идиотами?

Ещё Лев Николаич сказал:

Неясность слова есть неизменный признак неясности мысли

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

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

IT>Я бы сказал что одно это теория, а второе это её практическое воплощение. И чем наши определения отличаются?

Ну какая же это теория?! Это просто набор принципов, которые многие находят для себя важными.
Паттерн и фреймворк для его реализации. Можно допиливать под себя, можно выбрать другой, для тех же целей.

IT>Это очень субъективно. Лично мне и 3-х минут один раз в неделю достаточно, чтобы решить, что делать. А если речь идёт о новой большой задаче, то запросто может уйти пару дней на обсуждение. Почему я должен обязательно тратить именно в день именно 15-30 минут?
Два дня обсуждать брать ее на спринт или не брать?

Планирование оно вот об этом.

IT>Хорошо. Специально для тебя ещё раз. Я считаю, что методология разработки должна подбираться под конкретный проект и под конкретную команду
Ну это же не ответ. Мышки, станьте ежиками. Как подбирать, из чего подбирать? Что будет полезно, что вредно?

IT>и не ограничиваться дебильными рамками или следовать обязательным, но бесполезным церемониям, придуманныи непонятно кем непонятно для чего.
Ну так скрам ничего не делает обязательным. Это фреймворк, который по-определению должен затачиваться под команду. И вполне может не подойти совсем. Например, спринт — фиксированное окно разработки, ложится далеко не на все проекты.
Что значит непонятно для чего? Что конкретно тебе в скраме непонятно для чего?

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

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

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

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

IT>>Я бы сказал что одно это теория, а второе это её практическое воплощение. И чем наши определения отличаются?
PJ>Ну какая же это теория?! Это просто набор принципов, которые многие находят для себя важными.
PJ>Паттерн и фреймворк для его реализации. Можно допиливать под себя, можно выбрать другой, для тех же целей.

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

PJ>Два дня обсуждать брать ее на спринт или не брать?

Планирование оно вот об этом.

А при чём тут спринт? Попробуй абстрагироваться от аджайлов. Или ты когда кофе варишь, то считаешь во сколько поинтов тебе это обойдётся?

IT>>Хорошо. Специально для тебя ещё раз. Я считаю, что методология разработки должна подбираться под конкретный проект и под конкретную команду
PJ>Ну это же не ответ. Мышки, станьте ежиками. Как подбирать, из чего подбирать? Что будет полезно, что вредно?

Извини, забыл. Вы же без священного писания шагу ступить не можете. Нужно, что бы вам заранее рассказали, что вам будет полезно, а что вредно.

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

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

PJ>Это фреймворк, который

Этот термин на программистском форуме вообще-то имеет несколько другой контекст. Впрочем, в аджайле всё равно нет ничего своего. Всё откуда-то спи***но.

PJ>Что значит непонятно для чего? Что конкретно тебе в скраме непонятно для чего?

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

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

Ребята слились. Теперь давай ты.

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

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

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

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

HFT>>Я то думал, что чел в твоем лице вообще осознает, что такое Agile

IT>Расскажи нам всем, что такое Аджайл. Мы тоже хотим осознать.

Ох, видать ты давно звонков от телемаркетеров не получал

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

IT>Даже так? Я готов с тобой забиться на сотку баксов, что если мы спросим несведущего человека в чём разница между Аджайл и Скрам, то после твоего объеснения он будет делать круглые глаза и мычать, а в моё врубится мгновенно.
Это не делает твое объяснение правильным. Так-то заранее согласен. Тут ключевое слове несведующий. А дуракам всегда простоее объяснение предпочительнее.

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

IT>Или ты когда кофе варишь, то считаешь во сколько поинтов тебе это обойдётся?
Это и в скрам не обязательно считать. Внезапно.

IT>Извини, забыл. Вы же без священного писания шагу ступить не можете. Нужно, что бы вам заранее рассказали, что вам будет полезно, а что вредно.
Ну т.е. велосипед изобретать. К концу проекта может оказаться, что колеса были квадраные, а лыжи плохо ехали по асфальту.
Будь последовательным, в остальном тоже надо отрицать священные писанияю. Нах все эти паттерны и прочие архитектуры. По ходу кривая выведет...

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

IT>Здрасьте. Где это ты такой скрам видел. Вот у меня в конторе тысячи разработчиков, сотни команд. И никто не может без последствий скажем отменить статус митинги.

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

IT>Этот термин на программистском форуме вообще-то имеет несколько другой контекст. Впрочем, в аджайле всё равно нет ничего своего. Всё откуда-то спи***но.
Я полагаю, что на программистком форуме люди достаточно сообразительные, чтобы применять правильный контекст.

IT>

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

IT>Ребята слились. Теперь давай ты.Это
Если задать тупой вопрос, то можно получить только тупой же ответ и потом им размахивать. Никаким, поскольку скрам не решает проблемы толпы бездельников и лоботрясов. У него нет такой цели. Точно так же как он не решает проблему голода в африке. И водопад ее не решит. Это вот это ты называешь серьезными аргументами?

Спикеры дебилы, коллеги бездельники и лоботрясы, эффективные менеджеры... Есть ли в твоем окружении нормальные люди? Ну, кроме, понятно, тебя?

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

IT>С чего бы мне выставлять спикеров форумов идиотами, если это мой форум? По той же причине я могу говорить если и не за всех, то за многих. Уж точно больше, чем за двоих.
Понятия не имею. Но то, что ты выставляешь их идиотами это просто факт, и незнание мной мотивации не имеет тут никакого значения. Может ты просто ФП не любишь.

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

C>>Я работал с RUP в начале 2000-х. Это был кошмар из-за того, что внесение изменений практически было невозможно без тонн геморроя.
IT>Зато со скрамом отрефакторить накопленный тех. долг невозможно без тонн геморроя.
Это ещё почему? Точно так же бьём на задачи и вперёд. В прошлой команде мы так полностью модернизировали крупную подсистему AWS.

Заодно это предотвращает идиотства вида: "А давайте мы с нуля перепишем всё, чтоб было круто!"

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

I>>Почему это в аджайлле не получится? Как раз получится. По вотерфолу все таски сделал и сдал проект. А по аджайлу будешь генерировать новые таски быстрее, чем команда будет с текущими справляться.

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

I>А говорю я про то, что если в вотерфале скоп работ фиксированный, то в аджайле наша цель этот скоп работ увеличивать ежедневно.
Нет такой цели.

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

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

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

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

Gt_

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

IT>По большому счёту реально не хватало только SVC систем.
Не только. Еще виртуализация и облачные сервисы для сборки и тестирования.

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

PJ>Это не делает твое объяснение правильным. Так-то заранее согласен. Тут ключевое слове несведующий. А дуракам всегда простоее объяснение предпочительнее.

Ясно. Всё же тебе привычней всех вокруг считать дураками. Жить не страшно среди дураков?

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

IT>>Зато со скрамом отрефакторить накопленный тех. долг невозможно без тонн геморроя.
C>Это ещё почему? Точно так же бьём на задачи и вперёд. В прошлой команде мы так полностью модернизировали крупную подсистему AWS.

Как заказчик на это отреагировал? Что сказал про нецелевую растрату бюждета?

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

IT>>По большому счёту реально не хватало только SVC систем.
S>Не только. Еще виртуализация и облачные сервисы для сборки и тестирования.

А в чём проблема? Ставишь сервак и вперёд. Мы и сейчас как-то без всего это обходимся.

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

IT>Ясно. Всё же тебе привычней всех вокруг считать дураками. Жить не страшно среди дураков?
У меня, спасибо, все хорошо. Я не живу среди дураков. Отличные коллеги, не лоботрясы и не бездельники, адекватные менеджеры, нормальные спикеры на конференциях, и, внезапно, работающий скрам.

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

МП>>>скрам противоречит технологии Software Engineering
L>>Что такое "технология Software Engineering"?
МП>там проходят про моральную энергию разработчика, сбивку контекста, разные другие психологические аспекты работы и способы их оптимизации
МП>кто на программиста учился сам, а также на непрофильной специальности — полнотой технологии скорее всего не владеет, хотя кое-что уже и понимает сам
МП>думаю нужно провести ликбез в новой теме, создам вскоре с нуля

Ну и, где тема?

МП>>>>скрам противоречит технологии Software Engineering
L>>>Что такое "технология Software Engineering"?
МП>>там проходят про моральную энергию разработчика, сбивку контекста, разные другие психологические аспекты работы и способы их оптимизации
МП>>кто на программиста учился сам, а также на непрофильной специальности — полнотой технологии скорее всего не владеет, хотя кое-что уже и понимает сам
МП>>думаю нужно провести ликбез в новой теме, создам вскоре с нуля

S>Ну и, где тема?

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

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

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

IT>>>По большому счёту реально не хватало только SVC систем.
S>>Не только. Еще виртуализация и облачные сервисы для сборки и тестирования.
IT>А в чём проблема?
Кто сказал проблема? Infrastructure as code — это УДОБНО.

IT>Ставишь сервак и вперёд. Мы и сейчас как-то без всего это обходимся.
Ну т.е. когда надо что-то запустить на "чистой" машине вы ручками переустанавливаете ОС?

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

IT>>>Зато со скрамом отрефакторить накопленный тех. долг невозможно без тонн геморроя.
C>>Это ещё почему? Точно так же бьём на задачи и вперёд. В прошлой команде мы так полностью модернизировали крупную подсистему AWS.
IT>Как заказчик на это отреагировал? Что сказал про нецелевую растрату бюждета?
Если заказчик невменяем, так и без Scrum'а будет то же самое.

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

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

МП>я как услышал Сбер, сразу стал отказываться

А что так?

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

МП>>я как услышал Сбер, сразу стал отказываться
A>А что так?

Возможно по нравственно-моральным принципам.

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

AS>Возможно по нравственно-моральным принципам.

Интересно, какое представление, на основе чего о Сбере сейчас у автора. Хотя это, наверное, оффтопик.

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

A>Интересно, какое представление, на основе чего о Сбере сейчас у автора. Хотя это, наверное, оффтопик.

Он то ли социалист, то ли анархист и в принципе не любит банки

МП>>>я как услышал Сбер, сразу стал отказываться
A>>А что так?

AS>Возможно по нравственно-моральным принципам.

ну в общем да
причём сразу по двум линиям:
1) обычное кредитное ростовщичество
2) активное участие в построении цифрового концлагеря

и кроме того:
так и не открыл отделения в Крыму

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

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

L>Комфортность водопада заканчивается в тот самый момент, когда выясняется, что согласованный, утвержденный и принятый заказчиком фреймворк не позволяет реализовать следующую по списку фичу иначе, как стоя. В гамаке и противогазе.

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

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

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

__>>это часто превращается в игру "налепи заплатку, закрой тикет и перекинь проблему на другого"
C>Такое обычно быстро ловится вышестоящими менеджерами.

Ага, щаз. Вышестоящим менеджерам больше заняться нечем, кроме как разбираться, кто именно накосячил в иерархии на два уровня ниже их. Максимум, что они могут сделать — это вынести мозг нижестоящему менеджеру за пролюбленный из-за сломавшейся заплатки дедлайн. Если поверх заплатки удалось вовремя налепить другую заплатку и к концу спринта ничего не упало — с вероятностью 99% о проблеме не узнает никто, кроме программистов, которых ради этого заставили до трех часов ночи "быстрее-быстрее" эту заплатку пилить.

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

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

Gt_>в том то и дело, что то уже не вотерфол, а нечто ближе к идеологии аджайла.

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

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

Оно, конечно, да. Но фидбек бывает разный:

Вариант 1

Исполнитель: Итак, вы хотите заказать у нас строительство здания. Давайте обсудим подробности.
Заказчик: Мне нужен двухэтажный дом из пеноблоков с утепленной мансардой.
--- прошел месяц ---
Исполнитель: Мы выровняли участок и залили фундамент, хотите проконтролировать?
Заказчик: Да, конечно. Хм... Отличный фундамент, принято!
--- прошел месяц ---
Исполнитель: Мы положили стены и перекрытия, вас всё устраивает, можем приступать к мансарде и кровле?
Заказчик: Нет, простите... Я подумал и решил, что на втором этаже мне нужно не окно, а балкон. Вы можете переделать эту стену?
Исполнитель: Нет проблем, нам нужно неделю и N рублей денег.
--- прошел месяц ---
Исполнитель: Балкон и мансарда готовы. Чем крышу будем крыть — профлистом или черепицей?
Заказчик: А чем, по-вашему, лучше?
Исполнитель: Вот преимущества профлиста, вот смета. Вот то же самое по черепице. Выбирайте.
Заказчик: Выбираю профлист.
--- прошел месяц ---
Исполнитель: Здание готово! Вас все устраивает, можно приступать к прокладке коммуникаций и отделке?
Заказчик: Да, давайте! Не терпится уже поскорее въехать!
--- прошел месяц ---
Исполнитель: Мы закончили, проверяйте все и можете вселяться.
Заказчик: Ура, наконец-то!!! Кстати, меня тут осенило: а что если под зданием вырыть подземный гараж?
Исполнитель: Нет, извините, мы на такое не подпишемся — конструкция здания такого не предполагает, это будет опасно и потребует кучу дополнительных работ.
Заказчик: Но я купил машину, мне нужен гараж...
Исполнитель: Что ж, можем предложить вам построить его отдельно рядом с зданием, а проход закрыть от дождя навесом из поликарбоната.
Заказчик: Эх... Ну ладно, пусть так... Главное — это ведь новый дом, а он у меня теперь есть! Если надумаю строить новый — буду сразу проектировать с подземным машиноместом, а пока и так сойдет.

Вариант 2

Исполнитель: Итак, вы хотите заказать у нас строительство здания. Отлично! Давайте подпишем контракт, и через месяц мы предоставим вам первую версию!
Заказчик: Через месяц — дом?! И я даже смогу в нем жить? Но остальные компании за это время обещают только фундамент!
Исполнитель: Мы работаем по новой технологии HIOM, что значит House In One Month, она позволяет построить первую версию дома именно за месяц, а потом неограниченно улучшать его в соответствии с вашими пожеланиями. И главное — вы сможете уже через месяц в него вселиться, нам это совершенно не помешает!
Заказчик: Восхитительно, скорее начинайте!
--- прошел месяц ---
Исполнитель: Вот первая версия вашего дома, принимайте!
Заказчик: Эм-м-м... Но это же вигвам?!
Исполнитель: Именно так! Вигвам — это наш типовой дом на одну семью, построенный по экологичной технологии HIOM, предполагающей строительство дома всего за месяц!
Заказчик: Но слушайте, в нем же будет холодно и темно зимой... Мне нужен дом с теплыми стенами и отоплением...
Исполнитель: Не беда, мы ведь уже говорили — технология HIOM позволяет неограниченно модифицировать любое готовое здание. Приходите через месяц!
--- прошел месяц ---
Исполнитель: Итак, вот новая версия вашего дома — с электричеством и отоплением!
Заказчик: Но позвольте... Вы сделали электропроводку без контура заземления, а в качестве отопительного прибора у вас буржуйка. И... кажется само строение не изменилось — это по прежнему тот же шалаш, только обложенный снаружи минватой для утепления? Как мы можем сюда вселиться?
Исполнитель: Запросто — сейчас ведь июль, и вам пока еще не нужно отопление! Смело вселяйтесь и живите, а мы пока построим вокруг капитальное здание! Наша технология HIOM позволяет нам сделать это так, что вы и ваша семья нам совершенно не помешаете!
--- прошел месяц ---
Заказчик: Да-да, я уже слышал, что наш вигвам мешал вам при укладке полов, и поэтому его понадобилось срочно закопать под новым зданием. Но неужели нельзя было нас об этом хотя бы предупредить, прежде чем крушить его в пять утра бульдозером? Мы же уже вселились и были внутри, вам об этом отлично известно!
Исполнитель: Конечно известно, точно как и то, что ваша семья никак не помешала нашему бульдозеру.
Заказчик: Но он разбил наш телевизор и раздавил собаку!
Исполнитель: Что ж, спишем это на непрофессионализм бульдозериста — мы вычтем сумму из его зарплаты. Давайте лучше сосредоточимся на новом здании.
Заказчик: Да! Здание! Это же не дом, это сарай! Стены толщиной в одну доску, обитые внутри тонким утеплителем — и это в Сибири-то! А в качестве отопления опять все та же буржуйка!
Исполнитель: Знаете, это ведь типовой HIOM-проект, причем зарубежный — более пяти тысяч подобных HIOM-домов уже много лет успешно эксплуатируются в штате Флорида и северной Австралии. Впрочем, если вы хотите — мы готовы принять ваш фидбек, ведь технология HIOM позволяет сделать в течение месяца любые изменения
--- прошел месяц ---
Исполнитель: Итак, все как вы хотели — стены из пеноблока, два этажа с мансардой, крыша из профлиста
Заказчик: Ребята, я устал... Нет, правда, сколько можно? Стены из пеноблока, уложенного без раствора, второй этаж без окон, профлист на кровлю прибит гвоздями, которые торчат внутрь мансарды. К отоплению еще даже не приступали, наша семья по-прежнему живет в подвале с буржуйкой.
Исполнитель: Модульные стены — это одна из самых эффективных фич HIOM-технологии! Именно благодаря тому, что они сложены без раствора, мы и сможем сделать окна второго этажа в любом месте, в каком вы только пожелаете! Про отопление также можете не сомневаться — первая версия "русская печь" будет готова уже к концу текущей итерации, и вы несомненно сможете как угодно изменить ее в будущем. Кстати, как вы хотите решить проблему гвоздей в мансарде — нам лучше загнуть их молотком или отпилить болгаркой? Да-да, не сомневайтесь — мы можем сделать это за месяц, разумеется — по нашей-то совершенной HIOM-технологии!
--- прошел месяц ---
Заказчик: Да вашу мать... Где фундамент?! Куда вы дели фундамент?!!
Исполнитель: Просто он оказался слегка несовместимым с нынешней версией вашего дома. Не беда, технология HIOM позволяет всего за один месяц...
--- прошел месяц ---
--- прошел месяц ---
--- прошел месяц ---

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

Gt_>>в том то и дело, что то уже не вотерфол, а нечто ближе к идеологии аджайла.

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

если не надо было внедрять, значит не было итераций.

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

П>Оно, конечно, да. Но фидбек бывает разный:

там обоих надо гнать. как можно обещать убрать стену без анализа, без прототипа ?

A>>Интересно, какое представление, на основе чего о Сбере сейчас у автора. Хотя это, наверное, оффтопик.

N>Он то ли социалист, то ли анархист и в принципе не любит банки

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

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

Gt_>если не надо было внедрять, значит не было итераций.

В понимании agile — не было, а так — вполне себе:
анализ требований -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
анализ фидбека -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
анализ фидбека -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
анализ фидбека -> постановка задач -> разработка -> тестирование -> показ пред-релизной версии заказчику ->
финальное исправление косяков -> тестирование -> показ заказчику -> релиз

Я ж говорю, главная претензия к agile — то, что каждые две недели (в особо извращенных случаях — неделю) за каким-то чертом заставляют непременно релизиться, из-за чего работа моментально превращается в соковыжималку, а проект перманентно пребывает в состоянии "фиг знает, где тут что работает, а что [уже/еще] нет". Если это безумное требование из методологии убрать — по ней можно вполне комфортно и эффективно работать... ...вот только это получается уже не agile.

Gt_>там обоих надо гнать. как можно обещать убрать стену без анализа, без прототипа ?

В строительстве — никак. В разработке софта — запросто, о том и речь.

(Здесь была картинка про "... — и в продакшен", но так как правилами кывта запрещены матерные выражения, я ее на всякий случай удалил)

_AN>Помню 15 лет назад он был ого-го! Собирался автоматизированный социализм строить. Сейчас постарел, сидит в бункере, брюзжит бессвязно на весь белый свет.

постарел — это неверная характеристика
был год когда у меня умерло 2 родственника и ещё пара бед подобных случилась
я стал более реалистичен с тех пор и может циничен

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

и я могу теперь абстрагироваться от работы и осуществить автоматизацию

П>В понимании agile — не было, а так — вполне себе:
П>анализ требований -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->

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

П>Я ж говорю, главная претензия к agile — то, что каждые две недели (в особо извращенных случаях — неделю) за каким-то чертом заставляют непременно релизиться, из-за чего работа моментально превращается в соковыжималку, а проект перманентно пребывает в состоянии "фиг знает, где тут что работает, а что [уже/еще] нет". Если это безумное требование из методологии убрать — по ней можно вполне комфортно и эффективно работать... ...вот только это получается уже не agile.

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

П>В строительстве — никак. В разработке софта — запросто, о том и речь.

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

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

П>Я ж говорю, главная претензия к agile — то, что каждые две недели (в особо извращенных случаях — неделю) за каким-то чертом заставляют непременно релизиться, из-за чего работа моментально превращается в соковыжималку, а проект перманентно пребывает в состоянии "фиг знает, где тут что работает, а что [уже/еще] нет". Если это безумное требование из методологии убрать — по ней можно вполне комфортно и эффективно работать... ...вот только это получается уже не agile.

Без регулярных релизов и фокуса на работающем софте не будет agile.
Если у вас "фиг знает, где тут что работает, а что [уже/еще] нет", то у вас проблемы с definition of done и фокусом на работающем софте.

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

G>Без регулярных релизов и фокуса на работающем софте не будет agile.

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

G>Если у вас "фиг знает, где тут что работает, а что [уже/еще] нет", то у вас проблемы с definition of done и фокусом на работающем софте.

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

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

П>>анализ требований -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
Gt_>это и есть релиз.

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

Gt_>очень близко к agile

Опять же нет. В сравнении с agile это намного более нервосберегающий и менее склонный к превращению в соковыжималку процесс.

Gt_>никто в здравом уме не выполняет все ритуалы agile дословно. релизьте на uat, если уж так хочется.

Не спорю, можно и не выполнять — релизиться на UAT, делать спринты не по две недели, не играть в planning poker, не двигать тикеты по доске, и т.п... Тут только понять бы — на каком этапе эту "обезритуаленную" методику мы уже можем перестать называть agile? У меня есть такое смутное подозрение, что для апологетов методики она будет оставаться agile ровно до тех пор, пока будет успешно работать. А как только перестанет — так сразу и выяснится, что именно несоблюдение какого-то из ритуалов и вызвало крах.

Gt_>в урюпенске может и запросто, на наших широтах такое не встречал.

Что ж, может и в самом деле это провинциалы во всем виноваты. Криворукие и не знают, как пользоваться вундервафлей. Ok, вон тут IT в теме рядом, он аж из самих Штатов сюда пишет, и тоже почему-то не в восторге от scrum.

П>Не спорю, можно и не выполнять — релизиться на UAT, делать спринты не по две недели, не играть в planning poker, не двигать тикеты по доске, и т.п... Тут только понять бы — на каком этапе эту "обезритуаленную" методику мы уже можем перестать называть agile? У меня есть такое смутное подозрение, что для апологетов методики она будет оставаться agile ровно до тех пор, пока будет успешно работать. А как только перестанет — так сразу и выяснится, что именно несоблюдение какого-то из ритуалов и вызвало крах.

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

П>Что ж, может и в самом деле это провинциалы во всем виноваты. Криворукие и не знают, как пользоваться вундервафлей. Ok, вон тут IT в теме рядом, он аж из самих Штатов сюда пишет, и тоже почему-то не в восторге от scrum.

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

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

Gt_>к чему эта болтология и жонглирование терминами ?

Вот и мне интересно...

Gt_>чувак делал интерации и показывал клиенту. для чего ? что бы получить фидбэк и изменить план.

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

Gt_>все. эта гибкость уже полная противоположность вотерфолу.

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

Gt_>мигрант в сша это 99% унылое легаси донашивать.

Ну понятно — "все вокруг дурак, кроме только я". Почему-то мне начинает казаться, что этот разговор уже можно заканчивать.

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

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

Мне кажется, что проповедники аджайл ввели в заблуждение целую индустрию. Теперь почему-то все считают, что по ватерфолу нельзя работать итерационно и собирать фидбеки от заказчика. Так вот — можно! И всегда было можно. Аджайл не открыл тут америку.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

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

L>Ты с темы-то не слезай.
L>Сам СТО притянул, вот и отвечай теперь
L>Еще раз, кто виноват в том, что слепошарый диагност, приговоривший колодки, умудрился не заметить, что и диски — тогось?
L>Кто виноват в том, что приемщик, вместо того, чтобы выставить работы по пробегу согласно рекомендациям производителя или опыту ("скорее всего там уже и диски и еще чего"), доверяет слепошарому диагносту?

L>Скрам в этом виноват?

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

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

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

Gt_>>если не надо было внедрять, значит не было итераций.

П>В понимании agile — не было, а так — вполне себе:
П>анализ требований -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
П>анализ фидбека -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
П>анализ фидбека -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
П>анализ фидбека -> постановка задач -> разработка -> тестирование -> показ пред-релизной версии заказчику ->
П>финальное исправление косяков -> тестирование -> показ заказчику -> релиз

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

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

П>Да. Но не чтобы немедленно внедрить ПО в эксплуатацию. Получить фидбек на промежуточном этапе и что-то спокойно исправить к релизу — это нормально.

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

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

видимо, что бы как в ссср не получить, когда сдача аэс под дату подгоняется, а не под готовность объекта. (намек на чаэс)

П>Ну понятно — "все вокруг дурак, кроме только я". Почему-то мне начинает казаться, что этот разговор уже можно заканчивать.

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

	От:	Министр Промышленности
	Дата:	05.03.21 13:12
	Оценка:	+2 -3

	От:	HFTMan
	Дата:	05.03.21 13:32
	Оценка:	+5 -2

	От:	HFTMan
	Дата:	05.03.21 13:39
	Оценка:

	От:	Министр Промышленности
	Дата:	05.03.21 13:40
	Оценка:

	От:	HFTMan
	Дата:	05.03.21 13:43
	Оценка:

От:	velkin	https://kisa.biz
Дата:	05.03.21 14:27
Оценка:	17 (2) +9

	От:	Буравчик
	Дата:	05.03.21 14:37
	Оценка:

От:	IT	linq2db.com
Дата:	05.03.21 17:13
Оценка:	10 (2) +6

	От:	СвободуАнжелеДевис
	Дата:	05.03.21 19:44
	Оценка:

	От:	__kot2
	Дата:	06.03.21 00:05
	Оценка:	12 (2) +1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	06.03.21 16:47
Оценка:

	От:	landerhigh
	Дата:	08.03.21 11:04
	Оценка:	4 (1) +3 -1

От:	Dziman	http://github.com/Dziman
Дата:	08.03.21 18:11
Оценка:

	От:	El Camino Real
	Дата:	08.03.21 18:28
	Оценка:	+2

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	08.03.21 23:45
Оценка:	4 (1) +1

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	09.03.21 10:41
Оценка:

	От:	chaotic-kotik
	Дата:	09.03.21 11:47
	Оценка:	12 (1) +4

	От:	Пацак
	Дата:	28.03.21 11:48
	Оценка:	1 (1) +1

От:	_AND	За Русский мир! За Русь святую!
Дата:	28.03.21 17:02
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	29.03.21 13:46
Оценка:

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	17.04.21 05:21
Оценка: