Собственно по просьбе тех, кто трудится, и тех, кто следит за процессом, создан данный пост. О положительных/отрицательных сторонах сабжа отписываем в комментах

google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

61 Комментариев на “Парное программирование (делимся опытом)”

  1. bobi сказал:

    практика просто супер, новый человек быстро вьезжает в проект, вливается в команду. Без тестов никуда - это закон (очень хороший :) ). У нас когдато висели три бумажки соответсвующих цветов (RED - GREEN - REFACTORING). Кто прошел эту практику никогда не забудет. Код получается реально качественнее. Есть только одно но оба человека должны быть заинтересоованы в решении задачи, иначе получается что один кодит а второй плюет в потолок, такое поведение не приемлимо!!!

  2. GLad сказал:

    помню, мы с Доком писали парсер. Да, медленно - но уверенно написали, да и архитектуру не слабую придумали. Заметил, что удачно использовать в таске, для которого нет готового решения

  3. jam сказал:

    Поддерживаю.
    ПП - отличная вещь. Сейчас использую в своей команде. Очень помогает. Правда практикуем нерегулярно :)
    Правда продуктивность меньше чем по-отдельности, но зато код чище и лучше, алгоритмы оптимальнее, результат качественнее

  4. Vacuum сказал:

    Наслышан о парном программировании достаточно (в полном смысле слова "достаточно) и твердно решил для себя что это не моё.

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

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

    В-третьих - как говорят: "даже заядлые дрызья могут стать врагами, стоит им начать жить вместе"... Почти тоже и здесь.

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

    Итог: Имхо - технология не жилец.

  5. Roman Movchan сказал:

    Согласен с Вовой, хорошо он отписался выше, +1

    Думаю что проблему текучести кадров можно решать другими способами.
    Да и подмечено очень в точку. Один человек - одна машина.

  6. Interceptor сказал:

    Работал в паре. Удовольствие ниже среднего. Вернее его нет вообще. Один человек - один комп, это основа. Я вообще не терплю когда кто-то висит/сидит за плечом и смотрим в мой экран. Это нервирует... А когда этот человек начинает еще и, извините за выражение, жрать... в то время когда ты кодишь... Хочется нежно сомкнуть пальцы на его шее :)))))
    Возможно просто
    Планерка, регулярные совместные посещения rest room, с доской на стене - вот это да. Когда мне нужна будет помощь я ее попрошу. Когда меня о ней попросят я ее предоставлю.

  7. fenix сказал:

    боби ты прав в том что "...вьезжает в проект, вливается в команду."
    но насчёт "Без тестов никуда - это закон" это не закон это чуш )) если проект на 2-3 чела и скором скажем на полгода или меньше там нах не нужны тесты и это почти все менеджеры говорят но у вас в интерлинке считают по другому
    Садить в пару людей абсолютно разного уровня тоже ничего хорошего из этого не получитса
    TDT не приносит ни какого прироста ни к производительности ни в чистоте кода )) эт моё личное мнение

  8. zeroreturn сказал:

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

  9. jam сказал:

    Vacuum, я наслышан о полетах на марс и что теперь? Написано "делимся опытом". Зачем лить воду и говорить ни о чем? Про аську и линки "для работы" я вообще молчу. Парное ПРОГРАММИРОВАНИЕ это когда 2 человека пишут код, а не отвлекаются на всякое говно.

    Roman Movchan, ПП это не для решения проблем с кадрами, а для получения более качественного кода.

    Interceptor, ПП это инструмент, который нужно уметь использовать

    fenix, конечно, нужно забить на юнит-тестинг тоже, подумаешь умные люди придумали ... нафиг надо? правильно?

    zeroreturn, спасибо, что ты вменяемый

    такое чувство что собрались не проффесионалы, а стадо детей.

  10. Semmy сказал:

    jam сумасшедший? по-твоему, если кто-то не разделяет твою точку зрения, значит это дети, ибо ты пуп земли? ану сейчас-же извинись!

    лично я сам не пробовал так работать, но очень сомневаюсь, чтобы мне понравилось...

  11. Interceptor сказал:

    jam, меня в принципе раздражает когда мне смотрят в монитор... Уметь, не уметь... Меня это меньше раздражать не будет ;-) А если при этом еще задают тупые вопросы, или пытаются вести разговор на отвлеченную тему... или просто занимаются своими делами... или пытаются предложить вариант реализации, заведомо неверный, что я понимаю с первых слов, но вынужден полчаса доказывать, что так не получится...

    Не спорю, возможно попадались такие напарники... Не спорю, что от парного программирования есть толк, для быстрого включения нового человека в проект. Но я предпочитаю программировать сам. Сидя в своем домашнем удобном кресле за своим удобным и заточенным под меня компом... Я думаю, что таких людей много. И что бы им не рассказывали про ПП, их туда не затащишь.

  12. jam сказал:

    Semmy, для того чтоб говорить надо попробовать, не попробовал держи свое "очень сомневаюсь" при себе

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

  13. Interceptor сказал:

    jam, team managment и ПП две разные вещи ;) Одно включает в себя другое. Знак тождества между ними ставить не нужно. ИМХО. Я не против team managment. Я только за. Я не против планерок, я не против работать с rest room, куда можно выйти и побеседовать с другими участниками... Но я против работать в большой комнате. Кстати, посмотри на обстановку в офисах Гугля... Там явно не используется ПП. И по мнению большинства программистов эта обстановка наиболее способствует работе ;-) Там работают по два человека в комнате. за СВОИМИ собственными компами. Спиной друг к другу. В таких условиях я согласен работать. Для меня это вполне комфортно.

    А при чем тут методология к ПП я вообще не понял. ПП всего лишь один из многочисленных составляющих ХР. ХР в данном случае как раз является методологией. ПП - нет.

    Адаптивное программирование юзал? SCRUM? другие методологии? Составил мнение? Плюсы/минусы? Или ты видел только ХР и считаешь это верхом творения?

  14. jam сказал:

    Interceptor, ну что-ж, пофлеймим :))

    1.
    "тим-менеджмент и методология разработки" - 2 разные вещи
    "team managment и ПП две разные вещи" - несравнимые вещи
    "Знак тождества между ними ставить не нужно" - покажи мне предложение в котором я их отождествил

    2.
    да, у нас все знают об офисах гугля и ставят в пример. Ты знаешь как там работают? нет? ну так зачем вода ... и ненужно мне парить о том что ты читал. Никто незнает как там работают. А нащет 2х человек в комнате - как думаешь, почему 2, а не 1? Чтоб нескучно было :)

    3.
    Видимо не все понимают что такое ПП. Еще раз и по русски - ПП применяется не постоянно, часто, но не постоянно. Никто у тебя твой тазик не забирает. Сиди работай. А как пришло время ПП - будь добр, подвигайся к товарищу.

    4.
    English - http://martinfowler.com/articles/newMethodology.html
    Russian - http://www.maxkir.com/sd/newmethRUS.html
    Абсолютно согласен по всем пунктам.

    На адаптивное программирование тратится больше ресурсов.
    SCRUM - слишком длинные спринты.

    Считаю ХР верхом творения для конкретных задач своей команды.

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

    Всем спасибо

  15. jam сказал:

    Ну чтож пофлеймим.

    1. покажи мне место где я отождествляю ПП и тим менеджмент

    2. ты небыл в гугле и незнаешь как там работают. писать можно все что угодно, так что этот аргумент пуст.
    2.1 задайся вопросом почему в комнате 2 человека, недумаю что от скуки

    3. ПП не заставляет проводить 100% времени за 1й машиной. Свой тазик есть и будет.

    4. "при чем тут методология к ПП"? :) да вот как раз потому-что "ПП всего лишь один из многочисленных составляющих ХР" и "соответсвенно ХР в данном случае как раз является методологией". Сам ответил на свой глупый и безсмысленный вопрос.

    5. да, да, да, да, да
    5.1 АП забирает больше ресурсов чем ХР
    5.2 SCRUM - слишком длинные спринты
    5.3 Считаю ХР верхом творения для реализации задач своей команды

    *. продолжать тред вижу смысл только о ПП, ХР

  16. . лить воду и говорить ни о чем смысла невижу, дабы не тратить время
  17. jam сказал:

    P.S. http://martinfowler.com/articles/newMethodology.html
    absolutely agree

  18. fenix сказал:

    jam я не говорил что нужно забить на юнит тестирование вообще ... просто в интерлинке я наблюдал такую глупость что на месячный проект для одной пары пишут юнит тесты а и ещё довольно таки дофига. только для большый проектов есть смысл их писать

    jam вот ты скажы сколько по времени нужно проводить в паре а сколько порознь? (я понимаю что бывают разные задачи но всё же)

  19. GLad сказал:

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

  20. Vacuum сказал:

    jam, дружище-професионал

    я высказался по существу: мне нравится работать комфортно

    если тебе нравится ПП - ради бога

  21. jam сказал:

    fenix, в среднем 50 на 50, зависит от задач
    GLad, быстрее - не факт что лучше
    Vacuum, ок

  22. GLad сказал:

    jam, я не говорю про спешку. Я говорю про задачи чисто технического плана, те которые пишутся на автомате

  23. Interceptor сказал:

    jam, ну значит я неверно тебя понял. Спорить не собираюсь касательно отождествления.
    Касательно гугла - зайди на любой коммьюнити блог ребят, которые работают в гугле. Я отослал этот вопрос своим друзьям, которые там работают, правда не рядовыми программерами, но думаю они должны быть в курсе, посмотрим вечером что ответят :)

    Касательно Фаулера, то я его читал ;-) Мало того, составил собственное мнение о нем и этой книге... Естественно читал и об адаптивном программировании о FDD, SCRUM более детально ;-) Естественно читал основные характеристики и манифест гибких процессов.

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

    Касательно SCRUM длинный спринт. ЛОЛ. Да, если ты разрабатываешь продукты, в которых длительность всего процесса разработки неделя - две, то длительность одной итерации в SCRUM действительно много :)))) Ну, а если это серъезные продукты, в которых нужно не хлопать каждый день новую версию с незначительными улучшениями, а вносить новый значительный функционал, который значительно расширял бы возможности продукта, то SCRUM вполне подходит. Хотя опять же повторяюсь SCRUM тоже не мой выбор.

  24. jam сказал:

    Interceptor, товариСЧ, читать можно много и долго. Нужно применять. Из того что я пробовал - ХР лучшее.

    А вообще - сопоставив пару твоих коментов из разных статей могу сказать, что ты не отвечаешь за свои слова.

    В одном коменте ты говоришь что работать тебе удобнее самому, в следующем говоришь о команде и методологии, а в 3м о том что ты эту самую команду собираешь. Как после этого можно к тебе серьезно относиться?

  25. fenix сказал:

    jam я так понимаю ты работаеш в интерлинке ... ибо парное програмирование врядле где то ещё используетса )) не встречал ни одной конторы в киеве которая ПП использует ... а 50х50 это до хрена ... но всёже почему никто больше не использует ХР ?!!! не одна большая контора в киеве такого не делает!!!

  26. Interceptor сказал:

    jam, ни одно ни другое ни третье мне не мешает. Я пробовал работать в командах, я пробовал управлять командой, я работал сам, я собираю команду чтобы работать вместе.

    Насчет читать - юзать... Ты знаешь, можно очень много попробовать разных способов сажания картошки... потратить сотни лет на опробацию всех возможных видов... А можно один раз прочитать о опыте других и выбрать наиболее оптимальный вариант.

    Я так понял, что ты выбор ХР основываешь исключительно на Фаулере. И исключительно из-за того, что ХР у вас работает ты отвергаешь возможность того, что другие методологии могут работать лучше.

  27. Interceptor сказал:

    Если я прав, на этом спор заканчивается :) Я не собираюсь спорить с человеком, который не может посмотреть на ситуацию сверху, который полностью доверяется чужому мнению и никогда не пытается поставить его под сомнение. Это фанатики. С ними спорить бесполезно ;-)

  28. jam сказал:

    Interceptor, ЛОЛ

    Видимо ты мои коменты читал невнимательно
    Я юзал АП и СКРАМ, а подошла ХР

    Для начаоа команду собери и поработай, потом будешь доказывать какой у тебя большой ХУЙ

  29. bobi сказал:

    2jam полностью тебя поддерживаю.
    2fenix я могу запостить код который ты писал, он сразу скажет многое о твоих коментах об TDD, XP и интерлинке.

  30. doc сказал:

    Опыт: TDD - "попробовал раз, ем и сейчас". ПП - рулит, только сложно объяснить верховному руководству как оно работает. ХР могу сравнить только с PSP и с "формальным" CMMI 5-го уровня. Субъективно ХР явно выигрывает. Для ХР необходимо желание всей команды соблюдать правила, иначе оно не работает. Наверное, это важно и в других Agile методологиях.

    метафора: Тут проскочило сравнение компа с автомобилем. Хочу зацепиться за эту метафору. Задумайтесь. Формулы: 1 человек - 1 машина. (механики не в счет) едем по кругу и не долго. Ралли (аля Париж-Дакар) едем вдвоем и долго. Один прокладывает маршрут, второй рулит. В ХР так же. В формуле второй действительно лишний. Вы когда-нибуть пробавали ехать по незнакому городу пусть даже с картой на автомобиле один. Приходить останавливаться каждые минут 5-10. Зачем? Что бы посмотреть в карту. Вдвоем можно было бы не останавливаться. Тоже и в ХР. Но если второй не умеет читать катру, или первый водить. Мало что из этого получиться.

    Спасибо за внимание. ВСе вопросы на dohque at gmail dot com.

  31. GLad сказал:

    Стоп стоп
    в формуле тоже есть штурман, и не один, который как раз и говорит что куда да почему. Хотя в принципе сравнение верно - то же что я говорил - где осноное уделяется технике и навыкам - там одному, где надо думать, и "прокладывать маршрут" - вдвоём

    Док, вспоминаю математический парсер... :) А проект то ещё жив, http://impression.sf.net

  32. Interceptor сказал:

    doc, неверное сравнение с автомобилем. Ты забыл про техников, забыл про тех кто дает деньги, и т.д. и т.п. Ты забыл про всех. ПП и управлением автомобилем вдвоем это не верное сравние.

    jam, во-первых не хами. Во-вторых учись дискутировать. В-третьих... Про гугл и их методологию.

    Teams are always situated close together in fishbowl-style open seating, so that pair programming happens exactly when it's needed (say 5% of the time), and never otherwise. (http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html)

    Прошу обратить на слова "and never otherwise".

    Еще раз повторяю свою позицию: я против постоянного применения ПП. Против. Да, можно решать локальную проблему позвав другого человека и показав ему проблемное место. Мы этим пользуемся. Редко (просто редко возикают проблемы, которые нельзя решить самостоятельно), но пользуемся. Я не против такого подхода.
    Но постоянное применение ПП повышает угрессию в командах. И я такое наблюдал. В хороших командах. Где каждый является гением. Если же рассматриваем обычную команду (читай программистов с средним уровнем подготовки), которые просто тянут лямку от проекта к проекту, в которых нет никаких своих идей, желаний, которые работают ради бабок, а не ради творчества, то им навяжи любую методологию и она будет работать. Да люди будут убегать, да многих она не строит, но для работодателя как раз ХР самая удачная. И как раз ПП единственная фишка во всем ХР, которую обычно работодатели с мозгами берут в оборот и используют на полную катушку...

    Ведь это так удобно, программы кодируются, программеры обучаются, так как в этих фирмах сумашедшая текучка кадров, то ясно что лучше пусть в ПП вникают в проект, чем потом сами пытаются понять суть... Кроме того фирмы могут себе позволить ПП платя программерам смешные деньги. Еще бы, какая фирма будет платить программисту 800 баксов, если он будет работать в паре и по сути себистоимость общей работы двух программистов в месяц будет 1600. Конечно лучше платить меньше... 200 на человека... Тогда общая себистоимость 400.

    Поэтому подсуммируя вышесказанное. Ребята, те кто отстаивают ПП. Вы часом не технические директора, менеджеры, проджект лидеры, а??? ;-) Вы лапшу на уши своим работникам вешайте...

  33. Interceptor сказал:

    насчет формулы. Ребята, вы путаете грешное с праведным. Есть SP, TL, SA, PL, чья роль заключается в прокладывании маршрутов. Только они и никто другой вам скажут куда ехать и зачем вы туда едите. На любом из уровней, кем бы вы не были проблема стоит перед вами. Если вы не можете ее решить - есть meeting room, есть доска, есть brainstorm, вся команда в вашем распоряжении. Если в течении всего процесса полагаться на одного человека рядом, то возникает ложное убеждение, чот все идет верно. Что вы оба правы, а весь мир против вас. Кроме того у вас обеих теряется возможность получить какие-то новые знания. Еще бы, вы ведь сидите за одним компом (мы тут говорим о черкасских фирмах ;-)) и если вам нужна инфа, то лезете на одни и те же сайты, читаете одну и ту же инфу. У вас нет возможности полезть на разные сайты, один ухватиться за одну интересную идею, другой за другую... Может вашему напарнику было бы интересно в данную минуту почитать о разработке драйверов файловой системы в Vista, и тем самым он расширил бы свой кругозор. А у вас есть задача - реализовать определенный функционал. И вы одергиваете напраника. Нет, нужно читать про то и то...
    Ребята, вы еще не поняли? Лучший ПП это ж лучший способ контроллировать сотрудников на работе. Ведь 2 человека не будут заниматься одной и той же фигней. Хоть одному из них, но будет неинтересно и он скажет напарнику, чтобы тот занялся делом... ПО-моему наиболее эффективный... По сути каждому работнику повесили надзирателя. + платят ровно в два раза меньше чем могли бы платить. (я уже объяснял почему).

    ПП рулит и педалит... Для директоров. А вы будете еще долго сидеть там, где вы сейчас видите и с этой зарплатой и с этими знаниями и с этой организацией работы и рабочего места...

  34. doc сказал:

    Метафора была о тех, кто сидит в машине и под кого машина заточена. И она абстрагировалась от тех кто не сидит в машине. И там и там есть еще много народу как говориться behind the scenes.

    Самое интересное то, что о ПП плохо отзываються те, кто его не пробовал, либо у кого оно не получалось.

    2 Перехватчик: Чего вы хотите добиться в этой дискуссии? Повсеместной отмены ПП и признание практики не работающей? Или может быть хотите показать какой вы крутой?

    Мое личное имхо я высказал. Спорить на эту тему не намерен.

    ЗЫ: Директора как раз свою выгоду от ПП не понимают, в отличии от практикующих его разработчиков. Директора не понимают почему и за что они должны платить в 2 раза больше денег.

    2 Глэд: Не работае авторизация под ФФ 1.5.0.7

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

  35. fenix сказал:

    bobi ты не можеш показать мой код с интерлинка потому что мы в паре не работали а еси ты и возмёш кусок кода то ты не будеш знать какой мой - так что не надо пиздеть ))

  36. seagull сказал:

    2 Interceptor: по комментам я сначала подумал что говорит матерый чувак с 15-летним опытом разработки и опытом участия во многих коммандах. А теперь вот понял что опыта у тебя нет ВООБЩЕ. Я не говорю о том, что ты не писал ПО. Скорей всего пишешь его хорошо, может даже лучше всех собравшихся. Но хорошего опыта работы в команде у тебя точно нет. Никогда не думай, что "команда гениев" может что-то написать - никогда такого не будет. Творческому человеку очень сложно делать рутинную работу. Творческому человеку интересно пока что-то неизвестно, что-то надо придумать. Как только архитектура вылизана и все ясно, творческому человеку становиться очень плохо - не хочеться работать, хочеться чего-то свежего. Если вся команда будет такими, то проект не будет дописан с гарантией 100%. В команде обязаны быть рабочие лошадки, которым легче получить задание с четко ограниченными рамками и реализовать его. Надеюсь, тебе когда-нибудь удастся поработать с действительно творческими людьми и увидеть разницу.

    Теперь про ПП. Нельзя воспринимать техники как "слово божие" :) Только так и никак иначе; или же противоположность - никогда не использовать, ни при каких обстоятельствах. Надо использовать весь арсенал. Я считаю, что ПП нужно использовать и часто, но не всегда. Про то когда целесообразно использовать ПП достаточно коректно написал Glad - повторяться не буду.

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

    И перестаньте делать войны на пустом месте :)

  37. Interceptor сказал:

    Угу, особенно хорошо в этом плане выглядит команда Гугля. Или кто-то хочет сказать, что там 90% обычные программисты? И у них у всех не выходит продукты... ЛОЛ.

    Собственно получил подтверждения от моих друзей, оставшихся там. "Парное тоже вроде где-то используется, но я лично его не видел. Любят Agile в целом и Scrum."

    Вы считаете, что в гугле сидят глупые люди? Что они не просчитали насколько эффективно та или другая методология? Или тот или иной метод в методологии?
    Я пытаюсь учиться на чужих ошибках. У команды Google есть чему поучиться. Вообще почитайте ту ссылочку, которую я выше давал, возможно поймете насколько их процес разработки отличается от вашего и от общепринятого.
    Я пытаюсь взять лучшее. Пока лучшим является то, как работает Google Team. ничего более совершенного пока не придумали.

    Если кто-то по-прежднему считает ХР и ПП верхом творения - на здоровье. :)

  38. doc сказал:

    Давайте тогда возьмем процесс MicroSoft, который выглядит явно успешнее гугла (по объективны показателям, таким как прибыль и т.п.).

    Или будем придерживаться того же PSP.

    Как говориться на вкус и цвет... Agile-методологии настолько популярны лишь потому, что они более естественны для программистов. И кто сказал, что гугль или майкрософт 21-го века не будет следовать Agile.

    Выводы: MicroSoft и Google - это "машины для печатания денег", четко отлаженый механизм. Не обязательно то, что работает для гугль будет работать для всех.

    ЗЫ: Гугль не применяет Agile лишь потому, что их процесс разработки сформировался до того, как Agile стали популярными.

  39. seagull сказал:

    Хор самохвалов.
    Солирует... Interceptor.

    Успокойтесь вы наконец.
    Хоть почитайте что пишет противоположная сторона.

    И не стоит равнятся на гигантов. Ведь при старте и Гугл и Майкрософт явно пользовались другими методиками. Нужно искать решение конкретно для вашей команды, а не панацеи на все случаи жизни.

  40. Interceptor сказал:

    doc, "Директора как раз свою выгоду от ПП не понимают, в отличии от практикующих его разработчиков. Директора не понимают почему и за что они должны платить в 2 раза больше денег."
    Вы это в Фаулере вычитали? Или вы врете или вам попдаались идиоты. Ни в одной компании, с которой я сталикивался не было ситуации когда руководитель против ХР. Если ему доходчиво объяснили какая с этого будет прибыль.
    Насчет двойной оплаты. Так никто и не оплачивает! Если сейчас на рынке труда нужно платить в Черкассах программистам от 800 баксов, то фирмы платят от 200-т. Какая двойная оплата о чем вы?
    Программистов используют как лохов. а они продолжают клепать проги ниже себестоимости и восхвалять ПП.

    "Повсеместной отмены ПП и признание практики не работающей?"
    Я хочу чтобы была еще одна точка зрения, отличная от вашей.
    "Или может быть хотите показать какой вы крутой?"
    Кому? Зачем? Боже упаси.

    "Гугль не применяет Agile"
    Я немного не понял. Где я говорил, что он не применяет Agile? Он его применяет.
    Но практически не применяет ПП. Разницу чувствуете?

    seagull "Творческому человеку интересно пока что-то неизвестно, что-то надо придумать."
    Еще раз прочитай блог, на который я давал ссылку. Поймешь как решается эта проблема.
    "Если вся команда будет такими, то проект не будет дописан с гарантией 100%.№
    Никогда не говори никогда. В Google Team я не видел ни одного человека, который бы
    не был гением в своей области.
    "Надеюсь, тебе когда-нибудь удастся поработать с действительно творческими людьми и увидеть разницу."
    Мне удавалось работать и с творческими людьми и с рабочими лошадками.
    Я выбираю общность. И те и другие должны присутствовать.

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

  41. doc сказал:

    Извините за оффтоп.

    Где в черкассах платят 800 у.е. и кому?
    В киеве не везде и не всем 800 платят. Даже более того в Москве есть программерские должности на которых платят меньше.

    Если бы черкасские программеры действительно стоили 800 у.е. за 200 они бы не работали. Но это уже тема другой статьи. Потому что платят обычно столько, сколько ты хочешь. Конечно, если есть за что платить.

  42. GLad сказал:

    ну насчёт используют как лохов - допустим контора платит программеру 3 бакса в час (450 в месяц)
    берёт контора допустим проект 8 баксов в час, 3 бакса прогеру, 5 конторе - нормально.
    Допустим мы такие самостоятельные ниибаца программеры, работаем за 7 баксов в час - в месяц как раз около 1К. Заметье, платит обычно забугорный дядя, который при этом на проекте рубит от 50 у.е. в час. Где справедливость. Продаёмся, нах, как проститутки, и кто дороже продасться, тот круче.

    Хотя может у кого-то есть решение данной проблемы?

  43. doc сказал:

    seagull прав, Agile вообще и ПП в частности имеет свои недостатки и приимущества. Предлагаю четко сформулировать + и - ПП в частности и Agile вообще. Таким образом получим менее субъективную точку зрения. Поскольку одни учасники сообщества имели только положительный опыт, другие только отрицательный. Насколько я помню у К.Бека в книжке раскрыты обе стороны как ХР, так и отдельных методик. К.Бек утверждает, что каждая из методик ХР поддерживает другую.

    ЗЫ: Попрошу участников которые не имели никакого опыта ПП и ХР помолчать. Потому что когда говоришь, то не слушаешь.

  44. doc сказал:

    2 Глед сформулируй эту проблему в отдельный топик. Мне определенно есть, что сказать по этому поводу. Только нет времени писать статью. Потом на основе дискусси кто-то напишет объективную статью.

  45. GLad сказал:

    Нет Док, тему бабок и З/п создавать не хочу. Каждый зарабатывает где и как считает нужным. Представь ситуацию, что найдётся умник, который скажет что на ренте реально штуку рубить (в принципе этого я не отрицаю, думаю реально :)) Но последствия такого коммента могут быть разрушительными для черкасского ИТ-бизнеса, который и без того слабый.

  46. Interceptor сказал:

    GLad, на ренте реально рубить намного больше штуки в месяц. Вопрос только в том, как эти бабки оттуда забрать в таком количестве и сразу, но он тоже решаем ;-)

  47. GLad сказал:

    ну вот :) не удивлюсь, если завтра с креатива и линка половина программеров уволится и пойдёт искать счастья на ренте. Как джем писал - сайты делать что 2 пальца

  48. jam сказал:

    заранее извиняюсь, но после этого шедевра
    (http://ckdev.org.ua/2006/10/24/parnoe-programmirovanie-delimsya-opyitom/#comment-256)
    больше не читал, что бы не повышать "угрессию в командах"

    Interceptor, а вот теперь перейдем таки на грубости.
    Ну ты и тугой! Ни опыта, ни проектов, зато пиздежа ...
    Да, если ты считаешь что расходы вычисляются программер+программер, то советую поступить в любой ПТУ или школу, где учат экономику и делопроизводство :)

    seagull, где работаешь и чем занимаешься? не хочешь пообщаться в начале ноября, я буду в ЧК
    спасибо за содержательные коменты

    bobi, тебе тоже спасибо и предложение встертиться

    doc, рад тебя видеть :) спасибо за коменты

    GLad, тебя прорвало как раз когда я уже отошел от темы :) ну да ладно, все= мы с тобой это все уже обсуждали в течении 3х последних лет ;)

  49. Interceptor сказал:

    jam :-))))))) не можешь конструктивно понимать и отвечать, прееходишь на хамство. Да, знаком такой психотип людей. Удачи ;-)

  50. Interceptor сказал:

    jam, а мериться пиписьками можешь среди своих подчиненных. Я не собираюсь публиковать ни свой CV, ни что-то кому-то доказывать.
    Я высказал свое мнение, я нашел доказательства его. Имеющие глаза - увидят. Всем остальным - просьба не беспокоится.
    Если еще есть вопросы могу повторить основные тезисы негативов ПП. Позитивы тоже могу привести, но на позитивы думаю все могут расщедриться. А негативы это наиболее интересная тематика.

  51. bobi сказал:

    2all так... кажется тут все сильно разошлись, предлагаю прекратить перепалку, выпить холодного пива и остыть.

    2fenix:
    1. мне не прийдется искать тот код который ты писал, ты со своим напарником был на одинаково низком уровне по написанию кода (к сегдняшнему дню надеюсь ты уже понял как применять ООП), не говоря уже о разработке архитектуры проекта.
    2. Как ты помнишь в то время использовалась XP и вас только двое писало тот проект, вывод напрашивается сам собой.
    (сори за офтоп.)

    2jam буду рад встретися.

  52. bobi сказал:

    2jam в черкассах буду тоже в начале ноября.

  53. fenix сказал:

    bobi ты блин вумник бля нашолся >:-) это был первый мой проект на шарпе и 2 года назад ... я про свой тогдашний уровень не буду спорить и вы будте любезны не пиздеть ... сам ламака ...
    а про то скоко человек писала ППЦ уж будь любезен спросить у серёгаса или глянь в проджект план а потом будеш расказывать

  54. seregas сказал:

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

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

  55. seregas сказал:

    Мда.. не в тему немного запостился, но не смог сдержаться.

    По поводу ПП - я за. Если бы спросили меня года два-три назад, я бы перегрыз горло любому, кто со мной не согласился бы :). Сейчас же я понимаю, что не для всех задач ПП подходит, а самое главное - его трудно продавать :(. Если бы я смог продать проект с использованием классического икспи, я был бы счастлив! Я бы настаивал на ПП (и других практик). И я уверен, что после этого проекта большинство его участников навсегда полюбили бы юнит тесты (тест-инфектед пипл :)) и работу в паре. Кто работал в нормальной (да - НОРМАЛЬНОЙ!) паре, тот меня превосходно поймет.

    Много проблем в илинке было из-за неправильного понимания принципов парной работы и я не мог стоять над душой постоянно и корректировать работу (хотя наверное должен был... но это уже все в прошлом).

    Кста, сейчас у нас в головах зреет идея организации учебного центра для новых девелоперов (не сглазить бы. тьху, тьху, тьху :)). Так вот там уже будет постоянный наставник, результатом работы которого станет (должно стать!!!) появление пары (двоих) разработчиков, которых можно смело сажать на проект.

    К сожалению, без такого центра не обойтись, ибо уровень знаний, которыми снабжают в университетах до обидного низок :(. Сразу работать могут только единицы, которые много занимались самостоятельно и уж точно не по программе ВУЗа :(

  56. fenix сказал:

    seregas
    >> ... реально просырали сроки и качество вашей работы >>было ниже плинтусного ..
    с этим я согласен
    >> сроки просырались
    конечно согласен но вот токо функционал который был в первых планах и что в конце эт ты шот позабыл ))
    а ЦСМ полный мудак хотя я должен быть ему благодарен ибо если б не он я не был бы в киеве а сидел в черкасах ))

  57. fenix сказал:

    seregas так скажы у вас щас всё время работают в парах или иногда порознь?
    просто для многих задач ХП не нужно например когда в html чёто правят или исследуют какуюто проблему - один хочет в гугле поискать другой в МСДН почитать ...
    и самое главное ты считаеш что нужны юнит тесты для сравнительно малеких проектов? (например для пары на месяц) ???

  58. 21csm сказал:

    >>fenix сказал: а ЦСМ полный мудак
    Во-первых, поливать человека грязью за глаза - это удел труса.
    Во-вторых, я тоже не испытываю к тебе ни капли уважения. И считаю тебя довольно-таки тупым.

    >>хотя я должен быть ему благодарен ибо если б не он я >>не был бы в киеве а сидел в черкасах ))
    Тогда радуйся, и молчи в тряпочку.

  59. Rayan сказал:

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

  60. doc сказал:

    Нечто из статьи http://www.maxkir.com/sd/people_as_nonlinearRUS.htm .

    * Практически любую методологию можно с успехом применять в каком-нибудь проекте.
    * Любая методология может привести к провалу проекта.
    * Тяжеловесные методологии тоже могут успешно применяться в работе.
    * Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией.

    Из чего можно сделать вывод: методология не важна в принципе.

  61. Fritz сказал:

    А это разве не универсальный принцип?

    Помоему у Йордана черным по белому - если методология вызывает неприятие команды - не использовать.

    Не утрируя естественно в стиле - а я все хочу писать через goto - это хорошо и правильно.

  62. doc сказал:

    Инструмент, для парного программирования.)

    http://www.cenqua.com/pairon/





Оставте свое мнение