Экстрим-программирование Agile

Опубликовал cross в Разработка сайтов      4 comments

Март
31

Полтора года работаю тим-лидом по разработке сайтов, в задачи входит общение с клиентом, расстановка задач и приоритетов, технические задания и планирование работы, разруливание багов, трекинг issues`ов и тд и тп.

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

Как выяснилось, методика моей(нашей) работы называется экстремальное программирование. Один из самым популярных подходов в разработке программного обеспечения и любого другого софта на западе, да и судя из моего опыта в Европе, России и Востоке тоже.

Основные принципы экстрим-программирования очень просты и сводят разработку любых проектов к совершенно простым понятиям:

• Постоянная обратная связь с клиентом
• Прозрачность и простота разработки
• Анализ и предоставление клиенту готовых частей кода(релизов)
• Постоянное обсуждение и тестирование

Моделей(методик), а лучше сказать практик, такого подохода несколько: Cleanroom, RAD, RUP, Scrum, Спираль. На инфографике ниже расписана модель экстремального программирования Agile:

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

Интересно, что TDD в данной структуре выделено как обычный пункт ежедневной работы. У меня на это два взгляда, которые зависят от опытности работающей команды и каждого ее члена в частности.

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

Исходя из всего этого, становятся понятными некоторые вещи, которыми можно подитожить статью:

• Для усовершенствования процесса разработки, нужно четко его понимать, от самого его названия, до основных его понятий. Изучать на примере других компаний или по опыту сторонних разработчиков.
• Программисты должны развиваться быстрее, чем повяляются новые в их карьере задачи, для того чтобы TDD процесс был гладким.

Постовой:
Уникальное предложение от CheapTop.ru - БЕСПЛАТНАЯ раскрутка - получи вожделенные ТИЦ и PR плюс продвижение по запросам без затрат. Спешите, число участников ограничено!