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

[vit_r]

SCRUM is great: you don't have to measure quality and the Product Owner is a scapegoat for all epic failures.

Продолжение отходов от споров с агилитятами.

Я люблю SCRUM. Это гениальное нововведение. У него есть очень много несомненных достоинств:

1. Программисты рады и активно участвуют во всех ритуалах. (Не все, конечно, но для scrum это и не важно.)

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

3. Клиент платит за всё. Буквально за всё. Могут быть, конечно, какие-нибудь защищающие клиента метрики вроде компилируемости кода на конце цикла, но это совсем не значит, что код этот должен ратать, а исправленные ошибки не должны возвращаться. Грубо говоря, исполнитель каждый цикл начинает новый проект. С чистого листа. А куда всё это заведёт, не его забоата, а головная боль клиента.

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

5. Всё это выглядит как работающая и успешная система. Даже провалы и идиотизм переносятся в балансе в графу будущих задач.

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

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

8. Никого не надо ничему обучать. Не надо думать о выборе технологий. Да и вообще планировать не надо. На это есть Product Owner, который обычно не разбирается ни в предметной области, ни в процессах производства.

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

Но проповедникам знать это совершенно не обязательно. Раньше всё было плохо. Очень плохо. Просто ужасно и кошмарно. Но потом пришёл великий scrum и указал людям дорогу к свету.

10. Умникам, кстати, можно ещё и отомстить. Это раньше людей оценивали по результатам. Сейчас важна модность методик. (К тому же системы измерения этих самых результатов просто отменены.) Впрочем, умники уйдут сами, не выдержав напора прогрессивных методов.

11. Можно развести любую бюрократию. Можно даже довести agile процессы первого уровня до состояния культов. Если это названо agile, любые, пусть самые дурацкие требования становятся оправданными и логичными. Просто потому, что таков ритуал. Или понимание этого ритуала сбрендившим scrum мастером.

Короче, Да здравствуют новые светлые времена!

До scrum:

Клиент:

Сделайте мне машину как BMW

Исполнитель:

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

Scrum:

Клиент:

Сделайте мне машину как BMW

Исполнитель:

Без проблем! Мы по самой современной методике работаем. Вот вам самокат. Теперь сидите с нами и говорите, что добавить, а мы будем переделывать и каждую неделю вам новый результат для дальнейшего движения показывать.

Впрочем, иногда лучше делать дело.

Конкретный пример. В отличие от теоретической scrum болтологии совершенно реальный.

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

Мы с ответственными обсуждаем выпуск релиза. Я достаю бумажку и говорю:

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

- А это точно?

- Вот график.

- Хорошо. Когда мы можем выходить онлайн?

- Вот тут асимптота уходит в нуль. Здесь я бы заморозил разработку. Отсюда отложил бы неделю на тестирование и неожиданности.

- Хорошо, к этому прибавим ещё неделю. Вот здесь точно всё будет нормально? Ты за это отвечаешь?

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

ВСЁ.

Люди перепланируют. Переносят. Готовят нормально. И к назначенному моменту всё работает.

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

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

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

Comments

[bloody-icon.livejournal.com]

Потрясающе гибкая система!

[vit-r.livejournal.com]

Главное, чрезвычайно выгодная.

[bloody-icon.livejournal.com]

Как говорят выпускники MBA, эффективная :)

[norguhtar.livejournal.com]

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

[orleanz.livejournal.com]

и какая же альтернатива?

ну, кроме "раньше люди умели софт писать, а теперь не умеют, поэтому нанимайте старичков с водопадом, пока они живые"

[norguhtar.livejournal.com]

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

[old-radist.livejournal.com]

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

[norguhtar.livejournal.com]

Человек про альтернативу спрашивает, а не про скрещивание ужа с ежом. Которое я и описал. Технически и получается, что сначала один черт пишут ТЗ и прописывают архитектуру, а уже *потом* в рамках нее применяют scrum.

[old-radist.livejournal.com]

Конечно. При этом как правило оказывается, что "сначала" написанные ТЗ и архитектура заказываются под фестпрайс. Далее оказывается, что практически не бывает, что ТЗ и архитектура были фестпрайс, а сама разработка, наоборот, Т&М. То есть в нормальных ситуациях и скрам тоже загоняется в рамки, а не становится золотоносной курицей.

[norguhtar.livejournal.com]

Вот в итоге и получается, что весь scrum это технически профанация :) И банально это просто короткие релизные циклы :)

[vit-r.livejournal.com]

"Скрам загнанный в рамки" - это переводится только как "Конечно эта хрень не работает, но название очень хорошо для рекламы"

[vit-r.livejournal.com]

Есть варианты и без проектирования. Экспериментальная разработка, например.

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

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

[norguhtar.livejournal.com]

Есть варианты и без проектирования. Экспериментальная разработка, например.

Там как правило размер приложения не сильно большой из-за этого писать ТЗ смысла просто нет. Все и так понятно.


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

Тогда уж проще можно сформулировать. Не забывайте писать ТЗ, безжалостно выкидывайте говно :)

[vit-r.livejournal.com]

Смысл писать ТЗ есть всегда. Правда, в одном случае это годится как заметки в файле, в другом - только как подробная документация в правильном туле.

[norguhtar.livejournal.com]

Да я не спорю. Если разработка на насколько человек или возможны к ней возвраты, то имеет смысл изложить.

[vit-r.livejournal.com]

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

Альтернатив тоже дофига. Но тут нужен нормальный менеджмент. Чего сейчас найти чрезвычайно сложно.

[alll]

А вот кстати, можете порекомендовать такую книжку?

[vit-r.livejournal.com]

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

[alll]

Ага, спасибо.

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

[alll]

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

[vit-r.livejournal.com]

Почему "древняя"? Слово только в моду входит, а период полураспада минимум лет 10.

Потом, очень это выгодно для менеджеров. Отчётность великолепная, а ответственности никакой нет.

[alll]

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

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

[vit-r.livejournal.com]

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

[alll]

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

[vit-r.livejournal.com]

Митинги :-)