Здравствуйте, Daenur, Вы писали:
D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?
А я думаю, что отдельные товарищи представляют себя эдакими всемогущими мудрыми старцами архитекторами, по велению перста которых твориться история. А XP выбивает у них почву из под ног
AVM>Да ладно, ничего личного
AVM>По поводу XP — я не отстаиваю эту методологию, не защищаю ее, не молюсь на нее и тд, просто в ней есть много интересных идей, которые мы (ты и я) используем в своей работе каждый день. AVM>Я просто предлагаю посмотреть на XP c различных сторон. Например, как UI-designer может использовать постулаты XP в своей работе.
AVM>По поводу использования мною XP — нет не используем, не по причине того что она очень плоха, или очень хороша для нас, просто у нас на фирме..... ну в общем не используем
Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно). ( Слава богу, у меня одно время был свой прожект , в котором я мог от этого отвалить) Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально. На любые замечания о том что нехило бы документацию составить, очертить круг задач и определить, кто же за что отвечает, следовали ответы что это напрасная трата времени и педалить надо — типа цигель = бабло. Сейчас работаю в конторе, применяющей классичкеский подход к проектированию и разработке, которому меня учили еще в институте. Могу сказать что это небо и земля. Эффективность каждого члена команды при четко очерченых границах и поставленных тербованиях повышается в разы по сравнению с подходами из хр.
Здравствуйте, McSeem2, Вы писали:
MS>На самом деле я тоже кое-что из этого применял на практике и весьма успешно. Самая лучшая идея — активнго включить заказчика в процесс. Надо только сделать это очень ненавязчиво и как-бы естественным путем. Это тоже непросто. Я сумел пару раз это сделать и оба раза было то что надо. Но, большое но! Я работал над проектами в одиночку.
Я прям себя узнаю. Сначала он самозабвенно планы рисует, что надо и что ему не надо просто в журнале прочел и в кино посмотрел, программированию учит, рассказывает что у них все не так как у других. А потом как-то так в русло сотрудничества переходит, он придумывает, я придумываю. Прикольно получается. Тут только такт нужен и не реагировать на наезды. Тогда через какое-то время все устаканивается.
Здравствуйте, Glоbus, Вы писали:
G>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно). ( Слава богу, у меня одно время был свой прожект , в котором я мог от этого отвалить) Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально. На любые замечания о том что нехило бы документацию составить, очертить круг задач и определить, кто же за что отвечает, следовали ответы что это напрасная трата времени и педалить надо — типа цигель = бабло. Сейчас работаю в конторе, применяющей классичкеский подход к проектированию и разработке, которому меня учили еще в институте. Могу сказать что это небо и земля. Эффективность каждого члена команды при четко очерченых границах и поставленных тербованиях повышается в разы по сравнению с подходами из хр.
А вы сейчас Unit-тесты используете ?
Представитель заказчика на ранних этапах участвует в проекте ?
Итерации какую длительность примерно имеют ?
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, AVM, Вы писали:
AVM>>Да ладно, ничего личного
AVM>>По поводу XP — я не отстаиваю эту методологию, не защищаю ее, не молюсь на нее и тд, просто в ней есть много интересных идей, которые мы (ты и я) используем в своей работе каждый день. AVM>>Я просто предлагаю посмотреть на XP c различных сторон. Например, как UI-designer может использовать постулаты XP в своей работе.
AVM>>По поводу использования мною XP — нет не используем, не по причине того что она очень плоха, или очень хороша для нас, просто у нас на фирме..... ну в общем не используем
G>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно). ( Слава богу, у меня одно время был свой прожект , в котором я мог от этого отвалить)
Если вы не использовали хотя бы одну практику XP — вы не использовали XP совсем!
G>Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально.
Потому что вы не использовали парное программирование.
G>На любые замечания о том что нехило бы документацию составить, очертить круг задач и определить, кто же за что отвечает, следовали ответы что это напрасная трата времени и педалить надо — типа цигель = бабло. Сейчас работаю в конторе, применяющей классичкеский подход к проектированию и разработке, которому меня учили еще в институте. Могу сказать что это небо и земля. Эффективность каждого члена команды при четко очерченых границах и поставленных тербованиях повышается в разы по сравнению с подходами из хр.
Здравствуйте, Glоbus, Вы писали:
G>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно).
Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.
Если уж совсем трудно — то можно писать одному, но при занесении кода в CVS кто-то должен посмотреть на код и согласиться в ним. И в CVS пишется, кто проверял это изменение и он также несет за него ответственность. В том числе, получает премиальные за количество добавленных с его участием фич
S>Если вы не использовали хотя бы одну практику XP — вы не использовали XP совсем!
Насколько я знаю, апологеты ХР как раз утверждают, что практики ХР самоценны и в отрыве друг от друга и совсем необязательно использовать их все одновременно. Тем более очевидно, что внедрение всех практик одновременно сродни пожару по способности дезорганизовать рабочий процесс.
G>>Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально.
S>Потому что вы не использовали парное программирование.
Причём тут парное программирование? Речь ведь идёт о разных подходах к планированию и ведению проектной документации.
Здравствуйте, gribunin, Вы писали:
S>>Если вы не использовали хотя бы одну практику XP — вы не использовали XP совсем!
G>Насколько я знаю, апологеты ХР как раз утверждают, что практики ХР самоценны и в отрыве друг от друга и совсем необязательно использовать их все одновременно. Тем более очевидно, что внедрение всех практик одновременно сродни пожару по способности дезорганизовать рабочий процесс.
В том-то и дело что нет. Или все или это жалкое подобие XP с деорганизованностью и бардаком.
G>>>Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально.
S>>Потому что вы не использовали парное программирование.
G>Причём тут парное программирование? Речь ведь идёт о разных подходах к планированию и ведению проектной документации.
К тому, что при парном программировании с частым сменом пар и коллективным владением кодом все участники проекта
успевают по работать со всем кодом. По меньшей мере, с одними участками кода работали как минимум два человека, так
что уход одного к катастрофе приводить не должен. Обе эти практики были нарушены в вышеописанном проекте.
Цитирую "После ухода чела, который вел какой-нибудь кусок..." В XP проекте нет чела, который ведет кусок кода.
Все отвечают за весь код. Цитирую еще раз "руководство которой применяло хр (за исключением программирования в парах" —
парного программирования не было.
G>Нет, это не тестирование в том смысле в котором его понимаю я как программер. Тестирование — это процесс аналица работоспосбности чего-либо и выявления ошибок. А обсуждение иконок с заказчиком это перетиралово и обсуждалово с клиентом. Или ты реально не видешь разницы между тестирвоанием ПО и обсуждением иконок с заказчиком?
Почитай книжку про UI Design http://www.uibook1.ru/ (она тама в пдф). там очень внятно рассказывается про дизайн и тестирование UI. И если ты считаешь что тестирование UI это только "обсуждение иконок с заказчиком" то ты глубоко ошибаешься.
Лучше умереть сидя чем жить стоя
Искусственный интеллект — ничто по сравнению с естественной глупостью http://www.bevip.ru
Здравствуйте, FruT, Вы писали:
FT>Здравствуйте, Glоbus, Вы писали:
G>>Нет, это не тестирование в том смысле в котором его понимаю я как программер. Тестирование — это процесс аналица работоспосбности чего-либо и выявления ошибок. А обсуждение иконок с заказчиком это перетиралово и обсуждалово с клиентом. Или ты реально не видешь разницы между тестирвоанием ПО и обсуждением иконок с заказчиком?
FT>Почитай книжку про UI Design http://www.uibook1.ru/ (она тама в пдф). там очень внятно рассказывается про дизайн и тестирование UI. И если ты считаешь что тестирование UI это только "обсуждение иконок с заказчиком" то ты глубоко ошибаешься.
Юзабилити UI и дизигн UI в смысле иконок ЭТО разные вещи, об этмо я говорю. Или у вас в конторе дизайнеры рисуют интерфейс со всем контролами и тп?
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, Glоbus, Вы писали:
G>>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно).
INT>Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.
Ага, клевый подход. То есть может где-нибудь в индии именно так и пишут, а потом русские товарищи спрашивают "покажите индусский код, мы посмеемся".
INT>Если уж совсем трудно — то можно писать одному, но при занесении кода в CVS кто-то должен посмотреть на код и согласиться в ним. И в CVS пишется, кто проверял это изменение и он также несет за него ответственность. В том числе, получает премиальные за количество добавленных с его участием фич
Кто-то это кто? Какой чин? Статский советник аль колежский асессор? И что значит количество добавленных с его участием фич? Каких фич? откуда взялись? Сам придумал или кто подсказал? И нужны ли они были? И не портят ли архитектуру?
То есть я лично усматриваю в том что ты пишешь старик явное тяготение к бардаку и работе "с наскоку" — подход, применяемый прыщавыми студентами при сдаче лабораторных.
Здравствуйте, Glоbus, Вы писали:
G>Юзабилити UI и дизигн UI в смысле иконок ЭТО разные вещи, об этмо я говорю. Или у вас в конторе дизайнеры рисуют интерфейс со всем контролами и тп?
Да. т.к. у нас руководитель дизайнерсой группы — человек имеющий большой опыт в промышленном дизайне и имеющий степерь по психологии. И я счиьаю что такой подходоправдан — т.к. у нас ни разу не возникало проблемм с заказчиком по поводу интерфейса продукта.
Лучше умереть сидя чем жить стоя
Искусственный интеллект — ничто по сравнению с естественной глупостью http://www.bevip.ru
S>К тому, что при парном программировании с частым сменом пар и коллективным владением кодом все участники проекта S>успевают по работать со всем кодом. По меньшей мере, с одними участками кода работали как минимум два человека, так S>что уход одного к катастрофе приводить не должен. Обе эти практики были нарушены в вышеописанном проекте. S>Цитирую "После ухода чела, который вел какой-нибудь кусок..." В XP проекте нет чела, который ведет кусок кода. S>Все отвечают за весь код. Цитирую еще раз "руководство которой применяло хр (за исключением программирования в парах" — S>парного программирования не было.
Дорогой ты мой человек! Вот давай откинемся на спинку стула и раслаблено проанализируем что нам сулит хр как стиль ведения прожекта, и что нам сулит классический подход
1) отсутсвие внятной документации, все что есть инкапсулируется в тестах. А через 4 года когда нужно будет поднять проект и разобратсья в нем в, дорогой товарищ, сможете по тестам описать мне архитектуру системы?
в тоже самое время классический подход ратует за чательное документирвоание на бумаге или где бы то ни было
2) программирвоание в парах и постоянная их ротация, с целью сделать каждого участника прожекта носителем абсолютного знания о нем. Но это же абсурдно — по своей природе человек не может знать и помнить всего — для того бумага и нужна. Более того — размывается ответсвенность и начинается тыкание пальцем — это он посоветовал, а этот кусок не я делал и тп
Да и ваще — то что парное программирование способствует сохранению информаци о проекте и хорошему понимаю его частей участвниками — это фикция. ничто не заменит бамажки с хорошей документацией. И фразы о том что составление документации слишком длительный и муторный процесс тоже суть полный бред. Если посомтреть внимательно на брукса и его человеко-месяц то явно видно что они там бумажками не брезговали. И системы они писали в сотню раз сложнее, чем каждый из здесь спорящих.
3) активное вовлечение заказчика в процесс разработки. Очень знакомая ситуаха. На моей предыдущей работе наш менеджмент одного вовлек в мой прожект и очень об этом пожалел. Во многих случаях заказчик может быть абсолютно некомпетентен, но на своем видении того или иного момента он будет ой как наставивать. И придется сделать так как он сказал, даже если это глупо — не все заказчиуки вменяемы, а денюжку он платит. Класический же подход предлагает разработку четкого списка требований к системе, включая возможные будущие изменения и дополнения, что позволяет реализовать всю систему максимально гибко. Хр же со своей постоянной готовностью прожекта к сдаче заставляет жить сегодняшним днем, что само по себе херово в любой инженерной деятельности.
Это только первое что в голову приходит. Я уж не говорю о фразах типа "каждый участник проекта чакствует в его тестировании" И чт омне мой дизайнер натестирует?
Так что пусть архитектуру придумывают архитекторы, дизигнеры рисуют иконки и всякую цветастую лабуду, а программеры пишут и тестирую свой — и только свой! — код.
Здравствуйте, FruT, Вы писали:
FT>Здравствуйте, Glоbus, Вы писали:
G>>Юзабилити UI и дизигн UI в смысле иконок ЭТО разные вещи, об этмо я говорю. Или у вас в конторе дизайнеры рисуют интерфейс со всем контролами и тп?
FT>Да. т.к. у нас руководитель дизайнерсой группы — человек имеющий большой опыт в промышленном дизайне и имеющий степерь по психологии. И я счиьаю что такой подходоправдан — т.к. у нас ни разу не возникало проблемм с заказчиком по поводу интерфейса продукта.
О! Руководитель дизигнерсокй группы! а не дизигнер там или тестер. Так это его прямая обязанность — так же как архитектор будучи руководителем над программерами определяет архитектуру системы, так и руководитель вашей групы занимается юзабилити. Опять мы приходим к тому что не должны все участники прожекта заниматься его тотальным тестингом. Каждый отвечает за свой кусок.
ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.
Здравствуйте, Glоbus, Вы писали:
G>ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.
Сорри з небольшой офтоп но все-таки. про пренебрежение к психологии как аналогию могу привести игры переведенные профессиональными программистами
если человек занимаетс зазработкой интерфейса(не только компуретного UI а вообще) то, хлтя-бы основы прикладной психологии знать надо т.к. UI должен дыть функционально удобным и _НРАВИТСЯ ПОЛЬЗОВАТЕЛЯМ_. Причем 2ое обычно важнее(как замеченно из моей практики).Особенно если это mass production.
Лучше умереть сидя чем жить стоя
Искусственный интеллект — ничто по сравнению с естественной глупостью http://www.bevip.ru
Здравствуйте, FruT, Вы писали:
FT>Здравствуйте, Glоbus, Вы писали:
G>>ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.
FT>Сорри з небольшой офтоп но все-таки. про пренебрежение к психологии как аналогию могу привести игры переведенные профессиональными программистами FT>если человек занимаетс зазработкой интерфейса(не только компуретного UI а вообще) то, хлтя-бы основы прикладной психологии знать надо т.к. UI должен дыть функционально удобным и _НРАВИТСЯ ПОЛЬЗОВАТЕЛЯМ_. Причем 2ое обычно важнее(как замеченно из моей практики).Особенно если это mass production.
Нравится/не нравится, красиво/некрасиво — это вопрос вкуса. Тут психология не поможет никак.
Все дизигнеры с которыми я работал были технарями и без знаний психологии затыкали за пояс товарищей из художетсвенных вузов. Просто потмоу что как и в любой художетсвенной деятельности тут главное чутье. А его еще ни психология, ни что другео не формализовало еще. Да и ваще к психологии трудно отностистся как к науке. Там исключений больше чем правил.
Здравствуйте, Glоbus, Вы писали:
INT>>Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.
G>Ага, клевый подход. То есть может где-нибудь в индии именно так и пишут, а потом русские товарищи спрашивают "покажите индусский код, мы посмеемся".
простая логика подсказывает что "индусский" код как раз и пишут в одиночку и подольше стараются никому не показывать, бо в паре засмеют тут-же — после первой же строчки.
Здравствуйте, Glоbus, Вы писали:
G>Да и ваще — то что парное программирование способствует сохранению информаци о проекте и хорошему понимаю его частей участвниками — это фикция. ничто не заменит бамажки с хорошей документацией.
хм, у меня явно другой опыт — никакая "бамажка" в плане пониманию программы и рядом не стоит с собственноручным опытом что-нить в эту программу добавить. Может с "бамажками" не везло
Здравствуйте, Glоbus, Вы писали:
G>а программеры пишут и тестирую свой — и только свой! — код.
опять же мой опыт говорит об обратном — сколько бы человек свой код не тестировал, стоит только за него взяться другому человеку, так плюшки изо всех щелей и полезут.
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, Glоbus, Вы писали:
G>>Да и ваще — то что парное программирование способствует сохранению информаци о проекте и хорошему понимаю его частей участвниками — это фикция. ничто не заменит бамажки с хорошей документацией.
OE>хм, у меня явно другой опыт — никакая "бамажка" в плане пониманию программы и рядом не стоит с собственноручным опытом что-нить в эту программу добавить. Может с "бамажками" не везло