В дебрях водопада

[vit_r]

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

В Мюнхене будет проходить конференция Agile Contracts, на которой расскажут, что «делать» - это хорошее слово, а «сделать» - плохое.

Мой личный фаворит - воркоп «Kontrolle ist gut – Vertrauen ist besser» (Я бы перевёл «Зачем контролировать, когда можно верить»)

Comments

[lexicore.livejournal.com]

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

[vit-r.livejournal.com]

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

[white-bars.livejournal.com]

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

> «делать» - это хорошее слово, а «сделать» - плохое.

Вообще говоря, теория Agile говорит прямо противоположное :) "Agile goals are specific, tangible and measurable". На входе - планирование и целеполагание. На выходе должно быть продемонстрировано законченное решение, удовлетворяющее специфической цели, вносящей измеряемый вклад. Решение должно быть принято юзерами - как по частям (по окончании каждого спринта), так и в целом (по окончании фазы).
Если этого не происходит, Product Owner может/должен прекратить разврат ("abandon sprint", "nuclear option" и так далее).

> «Зачем контролировать, когда можно верить»

Это кто-то неправильно понял принципы Lean Agile, похоже... Для контроля и существуют time-boxed goals, burnup chart-ы и прочие способы скрам-контроля. Опять же, аджильный принцип гласит "если не знаешь, чему верить, верь данным" ("if you don't know whom to trust, trust data").

В общем, использование слова "Agile" для обозначения творческого бардака, цветет бурным цветом :)

[vit-r.livejournal.com]

Product Owner - это некая мифическая личность, которая как бог всё знает и за всё отвечает. Я ещё ни одного случая не видел, где бы исправление ошибок не перешло бы в самоцель. (За исключением тех случаев, где в процессы встроены элементы "устаревших моделей".)

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

[white-bars.livejournal.com]

> Я ещё ни одного случая не видел, где бы исправление ошибок не перешло бы в самоцель.

Я видел :) Правда, на предыдущем этаме это и правда было самоцелью.

> Качество измерять невозможно, потому что не с чем сравнивать.

Эээ... Всяко бывает. Agile (как форма религии) обычно действительно тянет за собой DevOps, как способ борьбы за качествоа, а вовсе не Kano model... Но с этим как раз можно бороться в два хода. Вначале нужно подсунуть определение качества как "количество и серьезность (severity) ошибок, с которыми сталкиваются конечные пользователи". Если это проглатывают (а - для серьезных проектов - куда деться), то дальше можно начать скармливать что-нибудь правильное. Обычно аджильники поначалу верещат, что предлагаемое не аджильно... Это тот самый момент, когда надо начать бить их по морде цитатами из клиентов, у которых ничего не работает или что-то срывается. Работает в 90% случаев ;)

[vit-r.livejournal.com]

Обычно аджильники поначалу верещат, что предлагаемое не аджильно...

Если мы смотрим не то, что называется третим уровнем, а agile карго-гульт, то они правы.

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