Много лет назад я стал жертвой всеобщего помешательства и подсел на эту диету Эткинса. Как и большинство диет, она не помогла. Сначала я потерял вес, а потом все равно медленно набрал его за несколько последующих лет. Причина, по которой Эткинс, да и все остальные чудодейственные диеты не работают, заключается в том, что они пытаются скрыть от нас простую, но горькую истину: чтобы похудеть надо поменьше жрать и почаще делать зарядку, а не пытаться изменить физиологию тела.
За последнее десятилетие или около того мы стали свидетелями расцвета различных «чудодейственных методик разработки программного обеспечения». Вместо обычной статьи про чей-то мучительный провал, я хочу обсудить последний (ну, нескольких последних лет) пример помешательства: Скоростная разработка и сопутствующие методики. Все они обещают одно и то же: дешевое и высококачественное ПО в сжатые сроки. Впрочем, мало кому из последователей удается представить это ПО на суд потребителей. Как и чудодейственные диеты, эти методики тоже пытаются скрыть от нас простую, но горькую истину: прежде чем начинать что-то создавать, надо знать, что же ты собираешься создавать.
Вокруг Скоростной разработки развернулась целая мини-отрасль: книги, семинары, консультации, все что угодно. Не существует способа вкратце обсудить все специфические моменты. Вместо этого я представлю один пример – Дилемма Строителя Пирамид.
Я встречался с этой аналогией на нескольких семинарах, в статьях и книгах. Насколько я могу судить, она принадлежит гению Джона Майо-Смита, который изложил ее в статье "Два способа построить пирамиду" на сайте Information Week.
Два строителя пирамид Растяпхотеп и Изящхотеп собрались соорудить пирамиду для своего фараона. Растяпхотеп придерживался традиционных взглядов, поэтому решил строить пирамиду обычным способом снизу вверх, рискуя не успеть до смерти фараона. Изящхотеп, приверженец Скоростного строительства, построил сначала маленькую пирамидку, а потом достроил ее по бокам. Таким образом, он свел к минимуму риск того, что к смерти фараона пирамида останется недостроенной.
Слева: Пирамида Растяпхотепа (Goofushotep) Справа: Пирамида Изящхотепа (Gallanthotep)
Иллюстрация: Представление этапов процесса разработки на Конференции по Скоростной разработке 2006 года
Эта аналогия призвана показать, как скоростные методики способствуют предугадыванию внезапных изменений (преждевременную смерть фараона) и адаптации к ним. Но я считаю, что это более чем нелепая аналогия, особенно в отношении создания ПО.
- Перво-наперво, невозможно достраивать египетскую пирамиду по сторонам. Пирамида это трехмерный объект (диаграмма/аналогия подразумевает, что это треугольник), и достраивание с одной стороны исказит ее совершенное квадратное основание.
- Во-вторых, фундамент закладывается до строительства. Догадываюсь, что постоянно изменять и достраивать фундамент прямо посреди остального строительства не самая лучшая идея. Сомневаюсь, что такое здание простоит хотя бы несколько сезонов, не говоря уже о тысячелетиях.
- В-третьих, замысловатые сети из туннелей, комнат и коридоров будет довольно трудно планировать, если размер здания будет постоянно изменяться. И скорее всего к концу строительства выглядеть все это будет довольно глупо.
Наверно я не совсем честен, перебирая по косточкам эту скоростную аналогию. В конце концов, сторонники этого подхода божатся, что это все отлично работает, и у них наготове куча показательных примеров доказывающих это. А если речь заходит о провалах, их ответ бескомпромиссен: «Разумеется, тут это не сработало. В проекте было недостаточно хороших специалистов».
Вот тут и таится собственно корень зла – большинство разработчиков недостаточно хороши. Само определение слова «хороший» подразумевает, что большинство людей средние, ниже средних или откровенно бездарные. Массовые продукты, заставить работать которые удается единицам, достойны лишь одного эпитета - дефективные.
Хорошие специалисты могут разработать хорошее ПО при помощи любой методики. Худым людям не нужны тайские таблетки, мы должны решать насущные проблемы, которые стоят за провалами в нашей отрасли. Планка «приемлемости» лежит слишком низко. Мы должны сфокусироваться на совершенствовании навыков не самых способных специалистов в отрасли.
Хотя улучшение чего бы то ни было довольно заманчивая цель, подобные методики на самом деле вводят в заблуждение и препятствуют достижению этой цели. Как и чудодейственные пилюли, скоростная разработка дает людям иллюзию, что проблемы качества можно решить простым изменением в процессе разработки. Действительно, зачем пускаться во все тяжкие, пытаясь изменить людей, когда можно просто изменить процесс?
Я осознаю, что многие разработчики (многие из которых являются моими близкими друзьями и коллегами) могут побиться об заклад, что достигли впечатляющих успехов, конструируя ПО тем же способом, которым Изящхотеп строил пирамиды. Но для подавляющего большинства ПО (т.е. для сложных информационных систем с жизненным периодом в пятнадцать и более лет) и подавляющего большинства разработчиков ПО (т.е. не самых способных ребят) Скоростные методики могут просто не работать.
Давайте вспомним, что если система пошла в промышленную эксплуатацию, это еще не значит, что она успешна. Мы должны создавать наши системы таким образом, чтобы наши последователи, разработчики с меньшими познаниями о бизнес-процессах и слабым пониманием архитектуры системы, тоже могли ее дополнять и поддерживать. Мы должны обучать и тренировать не самых способных и поднимать планку «приемлемости». Да, это нелегко, но это простая и горькая истина.
Оригинал:http://worsethanfailure.com/Articles/The-Great-Pyramid-of-Agile.aspx
