Есть ли команды в Узбекистане, которые применяют в практике XP?

[Akrom Obidov]

Очень интересно есть ли в Узбекистане команды которые применяют методологию Экстремального программирования в разработке реальных проектов?

Если есть то думаю очень было бы полезно обмениватся информацией с людми которые видили эффекты и недостатки ХР на практике!

[Fayzulla Agzamov]

Хороший программист должен сам знать если они или нет !

[Fayzulla Agzamov]

если их нет то надо их создавать их также программы которые они разработали размещат и грузить Интернет ! и потом и объемы пойдут

[Atham Mirazizov]

Сообщение от Akrom Obidov

Очень интересно есть ли в Узбекистане команды которые применяют методологию Экстремального программирования в разработке реальных проектов?

Если есть то думаю очень было бы полезно обмениватся информацией с людми которые видили эффекты и недостатки ХР на практике!

Любая софтверная компания в том или ином виде имеет методики командной разработки. Без этого она просто не выживет. Мы в прошлом имели встречу с компанией проповедующей идеи паттернов проектирования М.Фаулера. Встреча была интересна и познавательна. Думаю "в тени" существуют команды высококласных специалистов. Особого желания делиться наработками я среди них ве вижу. Поэтому эволюционный путь развития проходит каждая компания сама. Конечно мы изучаем методики и набираемся опыта самостоятельно, с другой стороны мы открыты для взаимовыгодного обмена этим опытом. В этом деле наши внутренние еженедельные тематические доклады являются крупным достижением.

[Akrom Obidov]

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

Причиной такого отношения является то что у нас в стране до сегодняшних дней во всех крупных компаниях системы (обычно крупные системы разрабатываются командами) разрабатывали в основном одиночки программисты (лично сталкивался с этим не однакратно) которые работали и решали все (бизнес логика, алгоритм, платформа и т.д.) на лету без каких либо методологий надеясь на свой "нюх". Пришел час когда начились организововатся команды из тех же одиночек которые привыкли надеется на свой нюх без каких либо предварительных исследований и проектирования и в общем правил. Начинают проекты, в итоге как обычно проект который был запланирован за 6 месяцев длится полтора года.
Я постараюсь обяснить как работают обычно команды которые состоят из бывших одиночек программистов (был сам когда то таким), у них в команде обычно определяется самый умный и самый опытный Вася Пупкин который пишет самую сложную часть системы и решает абсолютно все что связано с этим проектом и все выполняют то что говорит он, далее распределяет всем задачи без организации проектирования не информируя программера о миссии, в итоге программист который выполняет ту или иную задачу не имеет общую картину проекта и сталкивается с проблемами как "Ты почему написал этот код, изза твоего кода не работает мой код". Кроме того возникают такие проблемы как Вася Пупкин заболел или уволился и появляется вопрос а кто знает какая у системы была архитектура, или кто писал вот этот модуль? Писал и знает Вася Пупкин, а он же уволился (или заболел), чё будем делать теперь? В итоге провал или покрайней мере бедные прогреы теряют пол года на изучение модуля которую Вася Пупкин писал 3 месяца. Далее к этим командам присоеденяется молодеж (новые разработчики) и тот же молодеж получает в наследство азы одиночного программирования... В итоге зараженные привычкой "Нюхать" программисты продолжают работать в таком духе . Эти же одиночки программисты считают что Исследование, Проектирование, тестирование это лишнее и отнимает много времени, но на самом деле это экономит время разработки, позволяет определить дальнейшую жизнь проекта, взглянуть на будущее, предугадать ловушки которые ожидают его и если надо во время отказатся от проекта.
Методологии разработки софта очень похожа на дисциплину которая применяется в армии, это как руководство разработки, как обобщенная блок-схема или даже можно сказать как формула решения той или иной задачи.

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

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

[Djalolatdin Rakhimov]

Акром, а можно подробнее?

[Akrom Obidov]

Что именно вы хотели бы узнать по подробнее?, в прошлом посту я указывал несколько факторов.

[Djalolatdin Rakhimov]

да в целом. так как болезненная тема - определение ресурсов при разработке ПО. может есть ссылки по формализации процессов, контроля - буду благодарен

[Rustam Asimov]

Сообщение от Djalolatdin Rakhimov

да в целом. так как болезненная тема - определение ресурсов при разработке ПО. может есть ссылки по формализации процессов, контроля - буду благодарен

Если Вы готовы рассматривать и другие методологии, кроме XP, то у меня есть книга по RUP ("Управление проектами с помощью IBM Rational Unified Process. Практические советы", Р. Деннис Гиббс, Кудиц-Пресс).

[Ruslan Aliev]

Сообщение от Akrom Obidov

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

Может вы можете рассказать как надо пограммировать команде? Или хотя бы дадите ссылку на источник?