Об опыте экстремального программирования

Википедия определяет термин «экстрема́льное программи́рование» (англ. Extreme Programming, XP) как одну из гибких методологий разработки программного обеспечения. В насыщенной практике Creative есть проекты, работа над которыми по своей сути несет элементы этого метода. Что этот такое и стоит ли внедрять элементы XP в свою работу, расскажем ниже в топ 10 качеств этого явления.

  1. Сделать сайт быстро, технологично и всего за несколько дней. Основные моменты экстремально программирования это «Короткий цикл обратной связи» и «непрерывный, а не пакетный процесс». Но! В скорости не всегда можно учесть все моменты, неизбежно начинает страдать качество воплощения. И конечно редко когда в таких условиях можно продумать все на перспективу. И тут как учили в школе — «два пишем — три в уме», а когда таких запоминалок становится слишком много, наступает коллапс. Любой быстро написанный продукт, нацеленный на использование в дальнейшем — придется полностью перерабатывать, менять, дополнять и расширять. И время, сэкономленное на быструю реализацию проекта, потом уходит на переделки.
  2. Невозможность долгосрочного планирования. В жестких временных условиях любое планирование крайне сложно в реализации — по факту планировать получается только на день. Задачи в экстренном порядке выставляются с утра, в конце дня — дедлайны. Заказчик не понимает чего хочет сам, и не может донести задачи до исполнителя. «Каскадности задач» при таком планировании не предусматривается, поэтому и условия для выполнения задач появляются стихийно и непоследовательно. В итоге это выливается большие технические долги и все прочие неприятности.
  3. Децентрализация. С помощью децентрализации можно добиться максимальной вовлеченности и нацеленности на результат. Процесс рассеивания (а по сути — передача на аутсорс) функций веб — программирования и дизайна — с одной стороны увеличивает скорость и уменьшает издержки, а с другой — требуется максимальное включение всех специалистов.
  4. Глубокое погружение.  Подчас не только ответственному менеджеру, но и всей группе веб-разработчиков приходится быть в круглосуточном коннекте с заказчиком. Не все специалисты, даже самого высокого уровня могут быть на связи  24 часа в условиях сложного технологического процесса. И в какой-то момент профессиональное выгорание у специалистов, работающих на проекте, становится неизбежным. И здесь выручает грамотный менеджмент — заранее выставить временные границы для связи с заказчиком и привлекая на подобные проекты только опытных менеджеров проектов.
  5. Рефакторинг. Если не обращать внимания на качественную переработку кода, то легко можно  наломать дров и крайне быстро испортить всю работу.
  6. Коллективная двусторонняя ответственность за продукт. Атмосфера в рабочей группе по экстремальному программированию должна быть корпоративно — рабочей, чтобы с одной стороны — не допустить уставания от проекта, а с другой — чувствовать локоть соседа в боях за чистый код и технологичный результат!
  7. Стартапы. Экстремальное программирование подходит для любых сфер бизнеса. Но чаще всего и успешно применяется на стартапах и в высококонкурентных сферах бизнеса.
  8. Слишком широкий круг. Трудности могут возникать и из-за большого круга ответственных лиц. Чем шире круг — тем тяжелее привести проект к успешному завершению.
  9. Частые релизы. При быстрой смене плана действий, отсутствии долгосрочного планирования увеличивается и частота релизов. Они, как правило, происходят стихийно и бессистемно.
  10. Детализация. В каждой задаче нужно детализировать все по максимуму. Отговорки после не годятся. Никаких очевидностей и саморазумеющихся фактов быть не должно. Любой блок может оказаться ключевым! Но может неприятно подвезти на этапе релиза.

Комментарий веб-программиста: «Порой заказчик даже не просит, а требует, вопреки логике и здравому смыслу, чтобы всё на сайте было, так как они хотят. Нет слова «нет» (если чего-то не предоставляют битрикс [на чем мы делаем сайт] или используемые сервисы, то нам приходится всё это дорабатывать самим, и не просто дорабатывать, а прорабатывать каждую мелочь).  Зачастую это порождает глобальные переделки сайта. Так однажды на протяжении года мы, по несколько раз переделали одни и те же части сайта, вытачивая каждую мелочь, необходимую заказчику. Страницу курсов одного из таких сайтов я лично дорабатывал и переделывал 70 раз! »

Выводы:  Главное что можно и нужно сделать при экстремальном программировании — это правильно выбрать рабочую группу. Специалисты как части единого и важного механизма должны подбираться очень тщательно. И тогда в процессе не будет проблем. Члены команды должны быть достаточно коммуникабельны и иметь опыт командной игры, иначе на каком — то этапе может быть сделано все на свое усмотрение, а не на усмотрение клиента. А это уже убытки в виде времени и денег, и конечно нужно правильно подбирать проект-менеджера, чтобы бравая команда веб-разработчиков работала как швейцарские часы — красиво, четко и без сбоев.