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

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

ибо сколько раз приходилось видеть комманды которые бьют себя пяткой в грудь что вот у нас ХР у нас же есть UT, Refactoring, KISS, YAGNI, значит XP а на деле
UT -написание кучи кода который не используется пишется после модуля половину не тестирует. но так надо ибо без этого же не ХР
Refactoring такой что после него код понятен только рефакторивешему, дай Бог что функционал сохранил нужный
KISS, YAGNI и заказчик в комманде превращается в зомбирование заказчика на то что ему не нужно то что он хочет и изменение требований под написанный уже код.
итп. тут о ХР никакой речи быть не может


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

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

XDiaBLo,
В паре кстати весьма продуктивно работать если у обоих есть к этому предрасположенность. к тому же как-то неприлично в ПТ торчать когда товарищ рядом

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

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

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

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

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

А СКГ.Синдром компьютерного гения результат неточного перевода из какой-то книги. Может у Йордона может у ДеМарко. оригнал фраы не помню, так как этот вариант мне больше понравился как более отражающий суть и как-то у меня прижилось в лексиконе ибо симптомы наблюдать в большей или меньшей мере приходится постоянно. :)

k e k s
Вопрос: вот если взять вашу хорошую команду и использовать классичискую методологию - насколько хуже будет результат? Много слышал различных высказываний по поводу замечательности агила, но никто толком не может назвать конкретные преимущества

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

хотя у нас и так не каноничное ХР, у нас даже архитектурное проектирование есть вначале не такое масштабное как в том же RUP но есть ибо мы один раз столкнулись с граблями того, что не было четкого архитектурного представления просто зашли в тупик когда в процессе все казалось так красиво. в книгах ПО ХР этот момент как-то обходят и пишут, что если так получилось самдурак, плохо планировали итерации где-то взяли слишком много итп. да и есть ценность храбрость - под которой подразумевается то, что не надо боятся переделать пол-проекта. :) но с тех пор сначала большой брэйнсторм по архитектруре, потом проектная группа совещается ругается рисуют кучу схемок в итоге получаю набросок архитектуры настолько детальный, чтобы с него не наитерировать не в ту сторону. но не настолько, чтобы тратить на него много времени и сил. помимо этого на вайтборде появляется увесистый список "умных мыслей" которые возникают в момент глобальных виденений проекта и остаются незамеченными при планировании краткосрочных итераций. true-XPшники на этом месте будут орать что за это время половину проекта можно сделать. но на самом деле время которое уходит на это потом окупается на мой взгляд тем что меньше приходится деражать в голове глобальных идей для того что бы что-то не забыть важного.

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

что больше всего понравилось:
top3
3) это меньшее число артефактов и при этом множество разных моделей одного и того же в единицу времени, очень трудно кстати переломить себя было и внедрить обязательно избавление от ненужных артефактов. в итоге опять отступили от каноничного "все что не нужно - в топку". вместо топки ящик туда последовательно все укладывается маркируется по времени и ключевыми словами. для всех этот ящик потусторонний мир обратится к нему можно через "медиума" у которого ключ от кладовки, просто банально,лишние действия? но такое воззрение помогает когда начинаются душевные метания как что делать? нужна модель! не помню! там вроде было!. лишний повод пообщаться на тему проекта с коллегами бумажек меньше. но пару раз за проект кто-то вспоминает о чем-то действительно важном и приходится туда лезть. да и просто на душе спокойнее что ничего важного не выкинул.

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

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

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

к тому же опять же система ценностей. для ХР главная ценность это люди общение и все что с этим связанно, одна из таких абстрактных ценностей это так называемая храбрость. да что нам стоит переделать пол проекта гауно-вопрос ну и вопрос времени. команда живет с этой мыслью внезапные проблемы не напрягают.
в том же RUP первая ценность - процесс несмотря на то что RUP сам по природе итеративный и готовый ко всему, изменение требований входит в управление рисками, все документировано учтено, но не учтенный риск с серьезными последствиями достаточно сильно бьет по процессу и соответственно по всему проекту.
в Классической модели насколько понимаю главная ценность - это как раз отсутствие рисков и изменений требований. ибо это как дом строить какой-нибудь прораб забыл выдать люлей джамшутам они фундамент сделали на 10 этажей а не на 30. нашли это когда построили 20. что делать? разбирать переделывать, провести замеры в надежде что фундамент выдержит в два раза больше того, на что он рассчитан и делать крышу. или с боку костыли пристраивать. с боле гибкими такого не возникает
гле-то так