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

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

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

Комментарии

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

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

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

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

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

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

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

Понятно

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

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

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

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

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

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

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

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

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

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

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

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

Масштаб

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

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

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

Масштабы

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

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

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

Масштабы

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

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

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

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

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

Масштабы

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

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

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

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

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

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

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

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

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

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

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

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

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

На картинке

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

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

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