Обсуждение

мне лично экстремальное программирование видится гораздо более логичным и обоснованным нежели классическая проектность, которая есть набор традиций а ля наши деды так делали и прадеды, ну и ты типа тоже так делай в XP каждый принцип понятен и обоснован в классической проектности для пращуров каждый принцип тоже был понятен и обоснован, но это кагбэ было очень давно, так что никто и не помнит

вот я вчера как раз читал книжку 60х про критику социалистического планирования, как раз на тему того что оно не фига не agile т.е. уже в 60х тема была настолько осознанна что была не только предметом дискуссий узких специалистов, а уже и в достаточно массовой литературе присутствовала понятно что тогда просто компьютеров не было в массовых количествах и линей связи хотя в 70х уже была частично реализована agile (хотя называлась она конечно же по другому) система управления экономикой в Чили

Я экстремальное программирование практиковал более десяти лет назад. А современных десять лет назад -- это ведь уже очень, очень давно...

Я не хочу даже спорить с вами на экономические темы, но вы традиционно неправы в этих вопросах. К тому же вы очень мало прожили в СССР с централизованным планированием, да и про социалистическую Чили больше только легенды знаете.

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

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

Многочисленные эксперименты показали, что парное программирование будет похуже одиночного. И так со многими другими принципами. Многочисленные новые инициативы показали, что недостатка в новых agile принципах нетути -- а хоть тот же kanban, которому ой сколько лет на производстве, и который в разработке софта только-только начал использоваться. Так что прикипать сердцем к XP я бы не советовал.

>Многочисленные эксперименты показали, что парное программирование будет похуже одиночного. - а можно в этом месте поподробнее? Чьи эксперименты, какие выборки, описание экспериментов, критерии? Первое, что интересует - это описание своего опыта парного программирования, или обобщение на большой выборке? Просто мои личные наблюдения (парное программирование, в котором принимал участие сам + отзывы/ результаты участников воркшопов) дают прямо противоположный результат. Но - личное участие было давно, и условия специфические - освоение нового + научение/ формирование команды/ подтягивание членов команды; + может играть роль что работа была с людьми с низкой/ средней способностью к самоорганизации; + м.б. дело в критериях(?) - т.е. может быть это у меня частный случай (я задаю вопросы в канве гипотезы, что быть может частный случай - у Вас).

У меня был опыт парного программирования и у самого, и когда я руководил программистами. Но я не делал никаких замеров ни по какой методике. И честно считал (по личным ощущениям), что парное программирование -- это хорошо. А потом встретил ряд работ, где оценивались разные методы работы (одиночное программирование, парное программирование, просмотры кода внешними экспертами, использование доказательства программ и т.д.) -- и выяснилось, что по замерам у парного программирования преимуществ перед одиночным нет. Увы, я ссылку не запомнил, а сейчас искать лень. Ну, и в других местах про это встречал. Ибо одно дело "субъективные ощущения", а другое дело -- замеры по каким-то хоть как-то продуманным методикам на многих командах. Мне-то в паре работать нравилось, это менее скучно. Но вот количество ошибок и скорость, скорее всего, были бы выше при одиночной работе, если верить экспериментам. Относительная скука и личные ощущения от работы при этом не замерялись :-)

Это смотря как мерить. ХРшники пишут, что в неделе у них кагбэ два условных "рабочих" дня, потому как половину времени они программируют с кем-то ну и еще всякий оверхед. В этом смысле хуже, ажно в 2.5 раза. Однако, когда работаешь вдвоем есть косвенные бенефиты, а именно в том, что второй человек помогает отсечь больше ошибок на раннем этапе. Кроме того, при таком подходе народ разбирается в чужом коде, так что коммуникация при разработке дизайна проще, а точнее выходит на другой уровень, недостижимый в случае, если каждый в своем куске варится. При этом второй человек вообще говоря может и мешать кодить, понятное дело. Посему в каждом конкретном случае, от парного кодинга может быть как польза так и вред, но последнее скорее характеризует программеров, нежели сам принцип. Ну или к примеру пишу я юнит-тесты часто (хотя и не всегда), это несколько напряжно, но я знаю что потом будет польза, и она есть. У меня фикс некоторых багов занимает несколько минут без всяких душевных терзаний на тему а не обавлится ли сервак с десятком тыщ кастомеров. А кто-то откладывает коммит до следущего дня, типа на "свежую" голову. Ну а с тестами она и вечером свежая. В некоторых случаях время внесения изменений может сократиться и в десяток раз. Хотя исследования это не выявят. Они может наоборот выяснят, то юнит-тесты были в пять раз больше по объему нежели основной код и очень быстро устаревают, так что смысла писать их нет, потому что потом придется заново переписывать. Собственно, так же и с остальными принципами. Они могут не работать по каким-то объективным причинам, а может просто программеры не могут/умеют их реализовать. Посему я и написал, что можно выбрать по вкусу - те которые работают в данной конкретной ситуации.

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

вообще, из ХРшнык практик некоторые сейчас широко распространены (не обязательно заимствованные именно из ХР, но точно из agile методик) - частые короткие релизы, ну и связанное с этим планирование это уже стандарт я бы сказал. хотя в 90х это было не так - постоянная интеграция, специальные билдовые сервера, которые постоянно билдят - то же самое - юнит-тесты тоже обычное дело хотя думаю не так интенсивно как предполагает ХР, например юнит-тесты на баги далеко не всегда пишут - рефакторинг весьма популярен

я немного знаком с тем как проводят эксперименты по социальной психологии, а парное программирование и ХР вообще - это социальная психология однозначно дык вот тут очень много факторов, которые надо учесть и компенсировать соответственно тут надо очень много провести экспериментов, чтобы получить надежные данные вообще особенно, это касается реальных проектов, ибо обычно эксперименты проводят над студентами я немного погуглил обозрел результаты экспериментов, хотя и поверхностно, но в целом: 1 в основном результаты на студентах 2 часто исследуется скорость выполнения какой-то задачи парными и соло программерами 3 конечно есть и индустриальные результаты и на тему кол-ва дефектов, но их относительно мало 4 скорость кодинга варьируется во времени, то бишь поначалу пары могут работать медленее, но потом эффективность возрастает 5 еще есть подразделение на стадии - дизайн, кодинг, багофиксы/сопровождение - по сопровождению достаточно мало данных 6 данные противоречивые - где-то парное программирование лучше, где-то нет Вобщем самые интересные - это как раз индустриальные проекты, в частности сопровождение кода (чаще встречается чем написание новой хрени с нуля). Лично мне интереснее кол-во дефектов, нежели скорость программинга. А вот таких исследований не так много, по понятным причинам. Ибо индустриальные программеры не шибко озабочены замерами. А тесты на студентах на скорость написания с нуля известной задачи проводить сильно легче, но они не очень показательны для промышленных сеттингов. Поясню почему мне лично важнее кол-во дефектов, пусть даже в ущерб скорости. Я лично когда с ХР познакомился, считал что парное программирование будет медленее. Тем не менее это не обязательно плохо. Ибо баг может сильно затянуть релиз проекта. Кодинг на самом деле занимает в районе 5-15% ну может 20% издержек проекта (конечно зависит от того как считать, ибо программер может и кодить и дизайнить и тестить). Так что если ускорить кодинг, то выигрыш от этого не велик. А вот если в результатет будет баг то его найдут на тестировании, ну и вернут на доделку. А поскольку передача ответственности и оформление занимает много времени, прежде всего календарного, то это может ощутимо задержать релиз. Особенно, если при фиксе вылезет еще баги. Ну а если серьезная бага дойдет до кастомера, то может быть еще хуже. Отсюда вывод - в индустриальном сеттинге, общая эффективность зависит не от скорости кодинга, а от кол-ва багов. Ну и исследований именно на эту тему - как парное программирвоание влияет на сроки релиза проекта - я упоминаний о таковом не нашел. Как я и подозревал. А вот исследования на тему кол-ва дефектов в индустриальных сеттингах есть к примеру http://www.google.com/url?sa=t&rct=j&q=pair%20programming%20measurement&source=web&cd=4&ved=0CGAQFjAD&url=http%3A%2F%2Fwww.inf.unibz.it%2F~gsucci%2Fpublications%2Ffull%2520text%2Fc.240.pdf&ei=1LXgT_eyJ42g-waIo_X_DA&usg=AFQjCNFNs6XUZXmLbbUcnuJ_mwmtaB4uTA&cad=rja оно кагбэ подтверждает мою мыслю - парное программирование производит меньше дефектов, не во всех ситуациях значимо, но иногда - сильно меньше в частности, сильно меньше новых багов добавляется во время багофикса - вот это очень существенный результат хотя интуитивно это и так понятно - если я один кодил, то я обнаружил и предотвратил N багов, а если мы вдвоем - то я N, а коллега - M. Так что вдвоем мы обнаружим и предотвратим больше багов. Если конечно не будем друг другу мешать :).

Я забыл ссылку, но была работа именно по качеству кода: рассматривались доказательное программирование, парное программирование, метод главного программиста, независимое ревью кода и ещё штуки три-четыре подобных метододологии. Сравнивались трудозатраты и качество результата. Парное программирование показало огромные трудозатраты при не самом качественном коде. Я уж не помню, что там выиграло, но хорошо запомнил, что парное программирование в части качества результатов даёт отнюдь не лучшие результаты при росте трудозатрат. То бишь неэффективно при том же самом качестве. Вполне возможно, что ещё одна пара глаз вылавливает те ошибки, которые не появились бы при трансовом состоянии, которое проще держать в одиночку.

огромные трудозатраты - это подозрительный пункт поначалу, производительность при парном программировании сильно падает, но потом потери не так велики некоторые исследования не учитывают этого, хотя это известный феномен скажем так если затраты действительно огромны, то парное программирование никто применять не будет - это будет банально некомфортно

В этой книге http://www.amazon.co.uk/Making-Software-Really-Works-Believe/dp/0596808321/ref=sr_1_1?ie=UTF8&qid=1340144218&sr=8-1 есть глава посвященная исследованиям эффективности парного программирования. Можно почитать их выводы и есть ссылки на оригинальные работы на основе которых писалась статья. Обозреваются исследования как на студентах так и в индустрии.

Парное программирование наоборот, очень комфортно: паре ведь не скучно. А затраты больше (хотя и не в разы) при сравнимом с одиночным программированием качеством кода. Насчёт разницы во времени, так у женщин раз в месяц тоже производительность падает, но исследования этого не учитывают...