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_>чувак делал интерации и показывал клиенту. для чего ? что бы получить фидбэк и изменить план. все. эта гибкость уже полная противоположность вотерфолу. пусть это и не каноничный аджаил, но это точно много ближе к нему, чем к вотерфолу.

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

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

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

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

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

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

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

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

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

Gt_>>если не надо было внедрять, значит не было итераций.

П>В понимании agile — не было, а так — вполне себе:
П>анализ требований -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
П>анализ фидбека -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
П>анализ фидбека -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->
П>анализ фидбека -> постановка задач -> разработка -> тестирование -> показ пред-релизной версии заказчику ->
П>финальное исправление косяков -> тестирование -> показ заказчику -> релиз

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

П>Да. Но не чтобы немедленно внедрить ПО в эксплуатацию. Получить фидбек на промежуточном этапе и что-то спокойно исправить к релизу — это нормально.

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

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

видимо, что бы как в ссср не получить, когда сдача аэс под дату подгоняется, а не под готовность объекта. (намек на чаэс)

П>Ну понятно — "все вокруг дурак, кроме только я". Почему-то мне начинает казаться, что этот разговор уже можно заканчивать.

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

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

I>Мне кажется, что проповедники аджайл ввели в заблуждение целую индустрию. Теперь почему-то все считают, что по ватерфолу нельзя работать итерационно и собирать фидбеки от заказчика. Так вот — можно! И всегда было можно. Аджайл не открыл тут америку.

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

МП>и меня раздражает, как Греф произносит слово "Аджайл"
И как?
Мне нравится произносить "АГИЛ"

Может, примирит:
История страха в IT

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

Системный взгляд от инженера старой закалки.

МП>>и меня раздражает, как Греф произносит слово "Аджайл"
S>И как?
S>Мне нравится произносить "АГИЛ"

хорошо что не на И начинается

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

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

МП>>>и меня раздражает, как Греф произносит слово "Аджайл"
S>>И как?
S>>Мне нравится произносить "АГИЛ"

МП>хорошо что не на И начинается

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

Почему было омерзительно?

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

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