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

[vit_r]

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

Основная проблема agile в том, что нет различия между работой делаемой и сделанной. В процессах качества важным моментом является рапорт производителя или контролирующей инстанции об окончании работ. Это контрольная точка, с которой начинается user acceptance test. (Понятно, что писать надо по-английски, но оставил русский ради последней фразы, потому что agile сродни деревенской русской культуре очень русский разухабистый деревенский культ.)

User acceptance test - это когда архитектор встаёт на лодке под мостом и машет рукой, чтобы по нему пускали первый состав; когда инженер в присутствии заказчика замыкает рубильник и включает установку; когда повар пробует суп, кивает головой и говорит помощнику "Разливай!"

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

-- Ей, пользователь! Нам тут опять удалось скомпилировать. Ну, с богом!

Comments

[lxe]

Скомпилировать и прогнать тесты. (Покрытие тестами - это спектр, конечно.)

[vit_r]

Эти сказки можно рассказывать заказчику. Современные тесты сообщают не больше чем компилятор "Ой! Опять что-то работающее поломали!"

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

[lxe]

Ну, я же сказал "спектр".

[vit_r]

"Неполное покрытие" только на Managerish описывается красивым словом "спектр". Любой инженер для этого явления используется простой термин: "дыры".

[beldmit]

В хороших местах за это бьют.

[vit_r]

В хороших местах agile не бывает. Если вводят, то или agile рассасывается, или место прекращает быть хорошим.

[juan_gandhi]

Мне на днях пришла реклама на фесбуке. "Agile security solutions". Ну тут даже я, который так-то за аджайл (done right), подохуел. Понятно, что цель - ничто, движение - все. Но как-то жалко денег и данных.

[juan_gandhi]

Вот массовый пример из моей недавней практики. В конце тест-кейса (не содержащего ни одного ассерта) пишем System.assert(true, 'test passed');

[vit_r]

Если менеджмент будет требовать проценты, я тоже так писать буду.

- Сколько процентов сделано?

- Мы выполнили пятьсот двадцать семь тестов из них пятьсот четырнадцать успешных. Из критических ошибок осталась только одна: программа у пользователя не запускается.

- Мне не нужны подробности! Я спрашиваю, сколько выполнено в процентах.

[vit_r]

Может не "agile", а "adaptive".

А с безопасностью давно пора успокоиться: Все наши данные рано или поздно будут у китайцев и надо это правильно учитывать. Пусть подавятся.

[filin]

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

[juan_gandhi]

В той тулзе, что у нас, этот ассерт как раз "свидетельствует", что данные функции протестированы.

[lxe]

"Нарушение обмена веществ". Формально - верно.

[permeakra]

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

[vit_r]

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

А дальше уже начинается совсем другая тема.

[permeakra]

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

[vit_r]

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

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

[permeakra]

Гм. Не то чтобы это был не ответ, но это явно ответ на другой вопрос.

[veremeenko_alex]

1. Перестать называть это аджайлом
2. Как вариант - простенький канбан
3. Как еще вариант - сказать честно что это не проект, а рисёрч и делаем как можем

[permeakra]

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

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

[vit_r]

Канбан - это ритуал регулирования нагрузки, причём, стабильной нагрузки, но ни в коем случае не метод планирования.

[vit_r]

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

[permeakra]

Хорошо, переформулируем. Мне вот предложили канбан, и я собираюсь про этот подход внимательно почитать, потому что идея выглядит довольно полезной. Есть ли еще какие-то известные (== неоднократно обсужденные в литературе) подходы/методики/методологии/практики/системы убеждений касательно организации процесса разработки, про которые вы порекомендовали бы почитать? Особенно для работы в уловиях, когда проект или ресерч, или требования вынужденно уточняются/меняются по ходу дела (и до, и после первичной приемки) и это, как это ни противно, неотъемлимое свойство проекта?

[vit_r]

Канбан - это не методика разработки. Это способ минимизации и оптимизации складских запасов. Если открыть "The Toyota Way"... сейчас возьму с полки... это относится к реализации третьего принципа: Use "Pull" Systems to Avoid Overproduction (Глава 9).

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

Нету волшебной методики, которая заменит опыт и знания. Особенно, опыт и знания необходимые для разработки в условиях быстрой адаптации.

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

Agile security solutions

[live_on_tormans]

Ой, это уже из разряда первоапрельского с ebanoe.it :
"Wreck driven development:Agile in construncting real time embedded systems. Edited by Dmitriy Rogozin. Pre-order only 14.88$ "

[rdia.livejournal.com]

Дай бог, чтобы там хоть какие-то были интеграционными. Но вообще есть ещё принципиально не тестируемые автоматически вещи.

[rdia.livejournal.com]

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

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

Да, господи, я находил ошибку в Самоучителе языка F* - требуем одно, а доказываем другое. И ведь это игрушечная задача, опытнейшие люди.

[(Anonymous)]

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

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

[vit_r]

Philip B. Crosby, "Quality Is Free", 1980

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

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

[vit_r]

Тесты в современном IT -- это культура сдачи учебных заданий университетскому преподавателю.

Тесты, включённые в индустриальную систему контроля качества, -- это совсем другая культура. Сейчас почти вымершая.

[veremeenko_alex]

Так планирования у них и нет, поэтому и советую привести процессы к реальности
Что на доске нарисовали - то и делаем

[vit_r]

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

[rdia.livejournal.com]

Да, но тесты, вклюённые в индустриальную систему контроля, боюсь, целиком не автоматизируешь. Вот что делать с эстетическими требованиями API? Или с требованиями внятно написанных комментов?

[vit_r]

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

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

[(Anonymous)]

Я уже читал довольно глубоко (кстати, спасибо, довольно интересно пишете).

По теме обсуждения - можно провести сегментацию по тому, кто 'заказчик' (и как платят)
- если платят за один проект, ограниченный по срокам - то да, 'hamster wheel' довольно привлекательно... но оно ограничевается тем, что заказчики могут прекратить платить вот конкретно тебе за топтание на месте, и отдать решение задач кому-то ещё.
- если 'заказчик' - это обощённая аудитория (от сотен до миллиардов), и ты сам (или твоя организация) пытаешься понять, что им нужно и за что они заплатят. И вот тут вот - мой основной аргумент - казалось бы написал раз (дешево и хорошо), и продавай сотни/тысячи/миллионы раз... но нет, в реальности не получается, сложность систем уже слишком велика, и конкурентов много, и пользователи всё время хотят больше, быстрее, дешевле (а лучше вообще бесплатно).

[vit_r]

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

Опять же, об этом я писал пять лет назад. T_нас и T_нах

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

А про то, почему хорошее быстро умирает, есть классический текст "Worse is better". Хороший софт работает и следующую версию никто покупать не спешит. Постепенно у фирмы заканчиваются деньги на развитие и её покупают бракоделы, которые раз в год трясут мошну пользователей. (Понятно, что картина немного сложнее, но сейчас дальше углубляться не буду.)

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

А массовый рынок банально забивается рекламой, а не качеством.

[permeakra]

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

[vit_r]

Нельзя говорить "в рамках аналогии". Аналогия -- это аналогия. А тут просто иллюстрация.

Кто-то намёк понял, кто-то нет. Дальше уже не мои проблемы.

[permeakra]

>Кто-то намёк понял, кто-то нет.

Причем, если понял, то в рамках своей мизантропии. Как водится.

[vit_r]

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

[permeakra]

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

[vit_r]

Вот, про "парочку ключевых слов для самостоятельного писка" надо запомнить. Очень хорошо получилось.

А информацию в сети сейчас искать всё бесполезнее. Проблема, даже, не в цензуре и кривизне поисковиков. Проблема в мусоре.

[permeakra]

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