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

[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

[norguhtar.livejournal.com]

Они отличны. Особенно когда заказчик не понимает, что хочет от системы. Это позволяет экономить время как себе так и им. Но перед этим обязательно должна быть фаза начального проектирования с закладыванием легкого расширения и легкого изменения приложения. Причем сейчас с этим проще, можно брать фреймворки с поддержкой слабой связности и все довольно неплохо. Но к сожалению я такого не видел, для РСУБД. Т.е. есть классика вида третья нормальная форма и т.п. Но при возникновении ошибки проектирования БД, будет существенно больнее, чем при ошибке при проектировании приложения на базе фреймворка. Да эти штуки завязаны друг на друга, но в случае приложения часто исправить бывает проще.

[vit-r.livejournal.com]

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

[norguhtar.livejournal.com]

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

В любом случае идет общение с ручкой и бумагой. Проблема в том что часто заказчик не может выразить идею целиком. И я тоже не могу ее предложить так-как к примеру не владею полностью предметной областью или же мои предложения не нравятся заказчику. Что делать тогда в этом случае? До посинения добиваться от заказчика полной информации? Чаще проще выделить конкретный понятный сейчас заказчику законченный функционал и сделать его. Далее когда заказчик после использования этого софта понимает, что ему нужно еще раз выделяем ему законченный функционал. Да я в курсе что это фактически классический водопад :)

[vit-r.livejournal.com]

Вообще-то про Requirements Engineering полно книг. Некоторые из них, даже, полезные.

[norguhtar.livejournal.com]

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

[orleanz.livejournal.com]

" Проблема в том что часто заказчик не может выразить идею целиком.

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

[norguhtar.livejournal.com]

Недостаток понимания предметной области может быть и в той области что работаешь :) Это нормально.

[orleanz.livejournal.com]

дело не в знании предметной области.

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

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

[vit-r.livejournal.com]

Это бред.

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

[anonim-legion.livejournal.com]

Писатели и сценаристы пишут черновики, а потом переписывают. Это нормально.

[vit-r.livejournal.com]

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

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

[anonim-legion.livejournal.com]

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

Возможно, я вас не понимаю.

[vit-r.livejournal.com]

Писатели обычно не переписывают полностью, а поправляют.

Вопрос не только в том, чтобы выбросить прототип, но и чтобы выбрасываемые прототипы были максимально дёшевы.

[orleanz.livejournal.com]

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

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

[vit-r.livejournal.com]

В мире полно людей, которые могут разговаривать с заказчиками и формулировать ТЗ. Этому, даже, можно обучать.

Но это не выгодно. Проще поставить заказчика на деньги и гнать фигню. За которую тоже не надо отвечать, потому что сравнение качества идёт с ТЗ, которого в данном случае нет.

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

[norguhtar.livejournal.com]

В мире полно людей, которые могут разговаривать с заказчиками и формулировать ТЗ. Этому, даже, можно обучать.

Тут все упирается в то сколько это займет времени и сколько потом будут писать код. И не устареет ли к релизу готовое ПО.


Но это не выгодно. Проще поставить заказчика на деньги и гнать фигню. За которую тоже не надо отвечать, потому что сравнение качества идёт с ТЗ, которого в данном случае нет.

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

[vit-r.livejournal.com]

И не устареет ли к релизу готовое ПО.

Я не думаю, что правильно заменить эту неопределённость на "любое ПО, ушедшее в релиз, считается готовым"

Заказчику вообщем-то по фиг на качество, если это работает.

Обычно нет. И, даже, наоборот.

[norguhtar.livejournal.com]

Я не думаю, что правильно заменить эту неопределённость на "любое ПО, ушедшее в релиз, считается готовым"

Нет конечно.


Обычно нет. И, даже, наоборот.

Вопрос. Что подразумевается под качеством? Выполняет свои задачи как ожидает заказчик? Или внутри не говно? :)

[vit-r.livejournal.com]

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

[norguhtar.livejournal.com]

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

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

[vit-r.livejournal.com]

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

В общем случае это не так. Потому как ПО решающее половину задачи заказчику также бесполезно, как и не решающее задачу вообще.

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

[norguhtar.livejournal.com]

В общем случае это не так. Потому как ПО решающее половину задачи заказчику также бесполезно, как и не решающее задачу вообще.

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