Почитал и малость поучаствовал в дескуссии относительно самой спорной практики Agile методологий. Быть или не быть парному программированию. Мой опыт показывает, что быть. Но большинство рассуждений субъективные и не имеют никакого отношения к фактам. И о чем я задумался. Как можно оценить эффективность той или иной методологии? В каком случае мы можем сказать что методология А лучше Б? Ведь отсутствие методологии - тоже методология.
И я решил предложить объективное исследование методологий. Я сам не знаю к чему оно приведет.
Для начала предлагаю перечислить методологии. Мне извесны : XP, PSP (TSP, CMM), RUP, (методология от Microsoft, не помню как называеться)
ЗЫ: Просьба в коментах не обсуждать статью, а постить коротко : методология + ссылка где про нее прочитать. Личный опыт и отношению просьба отложить.
PS: Просьба писать коменты по существу и не создавать флейм. Коменты в которых будет обсуждение будут удалены. В коменте должно быть только название методологии и ссылка где о ней лучше почитать. Заранее приношу извинения за стресс нанесенный удалением коментов. Еще можно постить ссылки на чтиво про методологии.
Продолжение следует...
Loading ...
октября 27, 2006 в 7:57 pm
doc, если ты ставишь вопрос о Как можно оценить эффективность той или иной методологии? то это одно. Если ты хочешь сам исследовать другие методологии, то это другое.
Советую обратить внимание на SCRUM.
Я за Agile. С некоторыми поправками
октября 27, 2006 в 8:13 pm
Interceptor, нет, ты все-таки тугой
"Просьба в коментах не обсуждать статью, а постить коротко : методология + ссылка где про нее прочитать"
ХР постить небуду, все знают где и как найти
октября 30, 2006 в 4:28 pm
Как я заметил, конструктивно тема методолигий никого не интересует. Народ интересует только флейм в этом напраление.
Посему закрываю направление.
октября 30, 2006 в 5:12 pm
Трудно оценивать методологию саму по себе. Гораздо реальней оценить набор экземпляров сущностей организация-процесс-проект-продукт, где методология будет влиять на формирование проекта и процесса его поддерживающего.
Нужно указать:
)
- структору управления, штат (организация)
- класс изготавливаемой информационной системы (продукт)
- структуру ресурсов, их доступность, финансирование и требования по отчетности (в т.ч. предоставление прототипов заказчику) (проект, частично
Далее можно говорить почему та или иная методология была выбрана исходя из вышеперечисленого, как ее адаптировали в существующий процесс, как это помогло оптимизировать используемые ресурсы в проекте.
Исследование слишком масштабное, вряд ли оно будет проведено в полном объеме, поэтому можно остановиться на 2х-3х интересующих тебя структур управления, нескольних классах информационых систем и посмотреть на сколько каждая из методологий применима в конкретном случае. Потом можно с некоторой долей скептицизма все это обобщить и сделать выводы, что рулез и есть серебрянной пулей...
октября 30, 2006 в 6:31 pm
Хоть одна конструктивная мысль. )
Предлаголось для начала нособирать какое-то количество методологий. Потом разработать критерии для анализа. Оценить по ним методологии и т.п.
в результате сделать определенные выводы.
Сейчас похожая тусовка идет в авто сообществе относительно того, когда переходить на зимнюю резину. Половина утверждает, что лучше ездить шипами по асфальту, другая, что первый снег быстро растает и лучше пока ездить на летней. А "чайникам" в этом деле вроде меня абсолютно не понятно когда все-таки эту резину нужно переобувать.
Так же и здесь. Народ читает наши с перехватчиком споры и не может из этого сделать никаких выводов.
октября 30, 2006 в 8:52 pm
doc, очень советую не заниматься чепухой, а юзать уже готовые статьи на тему эффективности тех или иных методик. Наскидку поиском в гугле только что нашел с десяток даже уже переведенных на русский.
Касательно ХР читать лучше всего тут http://www.npj.ru/xpg/xpfaq
Про Agile - http://wiki.agiledev.ru/
Ничего более умного (кроме первоисточников ессно) нету.
Касательно ПП перерыл с десяток обсуждений эффективности применения ПП, оказывается даже научная статья есть на этот счет
Могу подсуммировать:
длительность процесса разработки увеличивается на 15%.
Эффективность (меньшее количество глюков) тоже на 15%.
Процент довольных от юзания ПП у них 85-90%. У нас (к сожалению нет научной статьи, пришлось по форумам собирать свою статистику) - 70%. Но! И тут начинается самое главное эти 70% складываются только потому, что они неверно понимают суть ПП. То есть используют его только для решения конкретных "проблемных" задач. Только 10% на форумах отписались о том, что используют чистое ПП, которое описывает Бек и довольны им (а именно ПОСТОЯННОЕ сидение в ПАРЕ).
Ну а теперь собственно подходим к тому, что я пытаюсь тут доказать: ПП - плохо применимо в постоянном режиме (именно в том, в котором оно описано в ХР). Только для решения краткосрочных проблем в коде 5минут-час. Если проблема более глобальна нужен митинг команды, для ее решения.
Кстати, умник jam, ты мне хотел показать что в МС юзают ПП? ну давай, показывай. Специально интересовался
И для начала почитай что есть Agile и если найдешь там ПП как практику - дашь ссылочку на этот документ и возьми с полки пирожок.
октября 31, 2006 в 3:19 pm
Во-первых огромное спасибо за подкинутые ссылки и интересные факты. Во-вторых Я безусловно уважаю Ваш опыт и интеллект, и полностью с Вами согласен что ПП имеет лишь ограниченное применение. Но мне хотелось бы понять откуда были получины такие цифры. Ведь даже 70% довольных - это не мало. И цена этих 15% глюков тоже может быть очень и очень разной. Особенно учитывая то, что глюки имееют привыку накапливаться, что приводят к повышению энтропии в системе.
Приношу свои извинения, за время потраченное на прочтение моего поста.
октября 31, 2006 в 8:01 pm
doc,
1. Я не являюсь истиной в последней инстанции, поэтому большая просьба обращаться на ты
Касательно экономической обоснованности я бы поррекомендовал почитать Коубера и Лоренса "Парное программирование. Преимущества и недостатки". Там сделана экономическая оценка эффективности, но для западного рынка. (http://www.maxkir.com/sd/pairprog_RUS.htm)
2. Касательно наших программистов (не обязательно работающих в СНГ), просто выходцев из СОЮЗа, то тут дело сложнее. Пришлось самому перелопатить с десяток форумов и блогов, посвященных ХР, Agile и т.п. То есть везде, где может упоминаться парное программирование.
Естественно тем подобных текущей море. Я в них анализировал следующие ответы:
1. Нравится или не нравится парное программирование в принципе.
2. Для тех, кому оно нравится, что они под этим подразумевают.
По первому пункту 70% программистам ПП понравилось.
По второму пункту, только 10% из этих 70% используют ПП постоянно. То есть оставшиеся 90% используют ПП только в случаях, когда оно необходимо (как я и писал и приводил пример с Google Team).
Еще раз для jam - я не против ПП. Я отстаиваю точку зрения, что в чистом виде (постоянная работа в паре) оно неприемлемо.