===== Agile и другие сказки =====
=== By David Longstreet ===


===== Основная часть =====

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

Charles Mackey – 1852, (Экстраординарные распространенные заблуждения и Безумство толп)//

Вскоре индустрия программного обеспечения осознает, что движение к Agile – это ошибка. Это произойдет не впервые: уже была широко раздутая проблема 2000 года, и бум доткомов. 

=== Происхождение ===
Я посвятил более 2 десятилетий жизни идее улучшения эффективности и качества ПО. Я работал в организациях различных масштабов и направлений деятельности, так или иначе связанных с ПО. С годами, я не ограничивал себя индустрией разработки, но и пытался перенять опыт из архитектуры, инженерного дела, медицины, пытаясь перенять профессионализм и принести его в разработку ПО.  Программное обеспечение – такая же индустрия как и все другие, поэтому к ней применимо большинство методов улучшения качества бизнес-процессов. 
До работы консультантом, я начинал разработчиком. Работал на таких языках, как ассемблер,  FORTRAN(для теоретической физики), COBOL, C, C++, Java. Также, я участвовал в написании книги DOS 5.0, ныне устаревшей. Также я управлял командами разработчкиов и участвовал в конференциях посвященных менеджменту.
Узнать больше о авторе, можно на www.SoftwareMetrics.Com/client.htm и www.SoftwareMetrics.Com/david.htm
  
=== Давным давно… ===
в Вене жил доктор Игнац Семмельвайс. Он верил в то, что методы статистики можно применять в медицине и, что наблюдения и систематическое изучение могут дать информацию, необходимую для устранения недуга. В то время, распространение инфекций и лихорадки было значительной проблемой госпиталей. Семмельвайс предположил, что вина в этом в значительной мере лежит на самих врачах, так как они не проходили никакой дизенфекции от перехода от пациента к пациенту. Порой они даже не мыли руки между вскрытием зараженного трупа и обследования живого пациента. Однако, коллеги высмеяли его, а его взгляды стоили Семмельвайсу докторской практики. После представления его идеи на конференции, большинство с ним не согласились и был выдвинут тезис, что даже если бактерии реально существуют, мытье рук заняло бы слишком много времени. 
Как и Игнац, я пришел к выводу, что разработчики сами виноваты в своих проблемах. Большинство работников сферы ссылаются на то, что процесс слишком непредсказуем и сложен, поэтому единственным решением является смириться с хаосом и становиться Agile, вместо введения организации и дисциплину в процесс разработки продукта.
Agile формализует небрежность в разработке, что приводит к проблемам, вроде Y2K. Я призываю IT-индустрию остепениться.
Мое предложение простое – я добавляю профессионализма и стогости индустрии и надеюсь, что вы мне поможете.

=== Дождь из требований ===

Наиболее популярный аргумент сторонников Agile – постоянно меняющиеся требования, к которым невозможно подготовиться. Однако, такое же встречается и в других индустриях, почти никогда не возможно ожидать, что же потребуется в следующий момент. Из этого можно сделать вывод, что, возможно, проблема кроется в самой IT индустрии, которая не может(не хочет) решить эту проблему другим путем.
=== Изучение потребителя ===

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

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

Сторонники Agile часто отсылают к имени Бабатюнда Огунайке, промышленного инженера с PhD. в химической инженерии. Пересказ его истории встречается в книге Крейга Лармана Agile & Iterative Development: A Manager’s Guide. В ней, он утверждает, что разработка систем настолько сложна и непредсказуема, что она должна управлятся моделью контроля процессов, называемой эмпирической. В данном случае, как это часто бывает с Agile, идея контроля эмпирических  процессов и, особенно, эмпирического моделирования, была неправильно понята и интерпретирована.
Обычно, методы Agile предлагают свою интерпретацию слова “эмпирический”, отличающуюся от используемой инженерами. 
Идея разработки эмпирической модели состоит в том, чтобы помочь изучению проблемы, когда мало актуальных эмпирических знаний или “определенной” теории. Эмпирическая модель не расчитана на то, чтобы строить продукты, но чтобы разобраться и построить определенную теорию. Огунайке пишет:”Помните, что задача моделирования – это не конец, а средство его достижения”. Полученная теория применяется для достижения результата, однако она требует актуальных знаний.
Аргументы Agile основываются на том, что систематическое изучение не работает в случае разработки ПО. Поэтому разработка рассматривается, как случайный процесс и считается целесообразным использовать “эмпирический процесс”. В большинстве публикаций о Agile, термины эмпирический процесс и эмпирическое моделирование перепутаны.
Хаос в организациях, занимающихся разработкой ПО – основная причина сложности для измерений. Хаос отличается от случайности. Каждый раз, проект разработки проходит иначе, документы не собираются в каталоги и их не организуют. Согласованное использование терминов и символов между проектами, внутри проектов или даже в одном документе с требованиями также отсутствует.
=== Контроль эмпирического процесса ===

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

Идея парного программирования, когда один человек пишет код, а второй проверяет его на ошибки, переодически обмениваясь ролями не решает какой-либо значимой задачи и вообще выглядит нелепо. Обычно, ошибки в коде составляют менее 10% от общего количества.
=== Итерации Код/Тест ===

Концепция Agile делает чередование написания кода и тестирования бессмысленным, так как из-за отсутствия четких требований, невозможно проверить полученный результат на валидность.
=== Креативность ===
За последнее десятилетие я наблюдал за развитием различных компаний. Как оказалось, наиболее успешными стали наиболее дисциплинированные. Это касается не только IT. Возможность планировать есть всегда, но для этого нужно приложить усилия по контролю над окружением. Принятие же решений "на месте" приводит к усиленному стрессу, который снижает креативность.
=== Музыка ===
Многие утверждают, что планирование и строгии правила вредят креативности. Хорошим контрпримером является музыка. Музыка полна измерений, правил и абсолютно согласованна. Невозможно представить себе оркестр, на ходу решающий, что сыграть далее. Вся структура музыки нацеленна на то, чтобы четко передать "указания" композитора музыканту. 
=== Библиотечное дело ===
Не только Agile, но и вся индустрия разработки ПО с пренебрежением относится к документации. Совершенно другой подход используется в библиотеках и медицинских учреждениях, которые нацелены на то, чтобы максимально быстро и эффективно найти и передать нужные знания. Этого часто не хватает IT. Необходимы стандарты документирования, создания глоссариев и т.д.
=== Зал суда ===
В разработке обычно пренебрегают фиксацией произошедших событий. Представьте себе, если бы события в суде не были задокументированы. Тогда для подтверждения решения пришлось бы согласовать воспоминания основных действующих лиц, что становится невозможным с течением времени.
=== Математическое доказательство ===
Существует математическое обоснование некорректности подхода Agile. Давайте посмотрим на него:
Программное приложение, по сути представляет из себя набор требований. Пусть есть требования А и B, которые зависимы(пересекаются в теории множеств)
Сравним размеры множеств
{{:mdd:screenshot_from_2016-12-25_19-42-45.png?200|}}

Очевидно, что в случае последовательного внедрения работы будет больше.
Пусть теперь есть 3 зависимых множества А, В, С
{{:mdd:screenshot_from_2016-12-25_19-42-39.png?450|}}

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

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


==== Ссылки ====
[[http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf]]