Определяющее слово

В книге "Зубы дракона" (про советские 1930-е годы) нашел полузабытое, но очень точное слово, характеризующее "гибкие"-agile методы разработки. Тем больше сходства, что применялось оно тогда в контексте кинопроизводства.

Слово это "штурмовщина".

Комментарии

Все несколько сложнее...

Одна из сторон проблемы состоит в том, что Agile мимикрирует, не признаваясь в этом публично. Тут ситуация напоминает генетику - то что было базовыми понятиями генетики в 20х-30х годах сейчас у знающего человека вызовет только приступ смеха, однако они аккуратно (и главное тихо) втянули в себя ДНК, а в 2000х "нео-генетики" взяли нобелевку за соматическое наследование (то есть за то, наличие чего доказывал генетикам еще Трофим Лысенко). При этом генетика светится всем лицом, а руководители советской науки и Лысенко объявляются сборищем узколобых ретроградов.

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

При этом Agile-адепты всячески избегают реально методологически сложных ситуаций, связанных с проявлением разработчиками инициативной ответсвенности и проактивного анализа развития ситуации в условиях крайнего ограничения времени и ресурсов при туманных исходных условиях - тут в бой идут туповатые старики, которые не боятся сказать "бизнес будет делать так", не тратят время на игры (именно игры) в планирование и прочую шелуху и знают в отличие от молодых, что величина синуса в критических условиях может достигать 3. И получают в устойчивый результат за нужные 20 дней, а не коллективную падучую недоделку за 4 месяца.

Потому что мы с Вами хорошо учились и знаем, что если система гибкая (Agile), то она не может быть быстро реагирующей - системы с быстрой реакцией - жесткие (Stiff). Чем гибче система, тем больше время переходного процесса и, следовательно, выхода в устойчивое состояние. И, наоборот, больше вероятность перехода в состояние спорадической автогенерации.

Посему - за Stiff (True solution iniciative fast forsing, ну буковки переставил, нам можно)!

Изображение пользователя Serguei_Tarassov.

Понятно

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

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

Собственно - да.

"Правильные" методики собственно и есть целевые(ограниченные) - как при определенных исходных условиях и определенных характеристиках "объекта управления" получить определенный результат.

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

исходные условия:
- команда программистов невысокой квалификации "с улицы" (т.е. не понимающих предметную область)
- потенциальная текучесть команды
- коммерческий заказчик с ограниченным бюджетом

Результат - сглаживание кривой затрат по сравнению с бытовавшими тогда методами коммерческой разработки.

И все. Честно, конкретно, никаких чудес.

Понятно, что если у вас не 10 "индусов", а два-три спеца с 10-летним опытом разработки в данной предметной области, то применение XP - это идиотизм чистой воды.

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

При чем, мне кажется, немалая популярность таких "индусоорганизующих" методов связанна с записными тим-лидами, которым жить так проще и кучерявее. Поясню. Предположим у нас есть экскаватор с самосвалом и, скажем, пятьдесят таджиков с тачками. Ясно, что по всем показателям ЭиС производительнее и эффективнее... Но, это если Вы умеете организовать их работу - правильно планировать участки работ, оптимизировать переходы между ними, следить, чтобы ширина траншеи соответствовала ширине ковша и так далее и тому подобное. А с таджиками с тачками таких проблем нет - они и канаву в один штык выроют и через забор перелезут и поделить их можно в отношении практически любом между участками работ. И навыков никаких особых им не нужно. Что бы ими управлять нужно только громкий голос и доска - карточки передвигать...

Изображение пользователя Serguei_Tarassov.

Масштаб

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

Дальнейший масштаб - аджайл зацикливается на стадии кодирования. Водопад - тоже, но на стадиях проектирования.

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

Масштабы

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

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

Изображение пользователя Serguei_Tarassov.

Масштабы

Хорошим примером предельного масштаба является программа расчета зарплаты для крупного предприятия. На котором в своё время и выехало "экстремальное программирование".

Если оценивать в каких-то метриках, то это будут примерно:

  • одна предметная область
  • многие десятки - сотня+ таблиц в РБД
  • примерно столько же классов для реализации сущностей предметной области
  • многие десятки - единицы сотен тысяч строк кода на ЯВУ уровня Ява или Сишарп (без учета тестов всех уровней)
  • единицы человеко-лет трудозатрат до первой сдачи в эксплуатацию

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

Это типовая картинка для аджайлов в такой ситуации. Она соответствует понятию "лоскутная автоматизация" времен, когда "гибкие программисты" работали в штате отделов ИТ (АСУ) предприятий и занимались домашней автоматизацией (inhouse development) и бесконечным сопровождением своих лоскутков.

Масштабы

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

Кстати, иногда повсеместное внедрение ажаля зачастую идет под флагом "долой лоскутную автоматизацию"...

Изображение пользователя Serguei_Tarassov.

Конечно же нет

Конечно же нет, оценить примерные количественные метрики для таких индикаторов, как экранные формы и отчетность, интеграция, таблицы, бизнес-классы можно и нужно на начальном этапе. Для этого в спиральных и каскадных методиках имеется стадия концепции (scope view), которая в рамках короткого документа раскрывает основную суть проекта и предполагаемые методы реализации. Ограничения - необходимость привлечения к этой работе системных аналитиков и ведущих специалистов. В аджайлах нет ни соответствующего этапа, ни специалистов.

Применимость

На самом деле меня пугает концепция, широко тиражируемая вот на этой картинке:

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

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

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

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

(твоя капча - это ад)

Изображение пользователя Serguei_Tarassov.

На картинке

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

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

"Холакратия" с её метафорой города - попытка натянуть аджайлы на весь контур управления предприятием. Хайп совершенно аналогичный. Атака тоже совершенно аналогичная по уровню логики и спекуляций: "Водопады проваливаются, а у нас есть успешные проекты".