Здравствуйте, bkat, Вы писали:
L>>Эти ребята (С) сидят на своих теплых местах уже давно. Оно им надо, чтобы какой-то smartass с улицы указывал им, как и что делать? B>Это они тебе прямо так и говорят?
Ну, прямо не говорят. Мне ж именно за это деньги и платят B>Указывать, кстати, и в самом деле не стоит.
Случаи разные бывают.
Здравствуйте, saprxm, Вы писали:
S>хотя предлагаю всем сговориться и прессовать всех HR города S>сделать флэш моб: 2 недели будет приходить народ на собеседования и методично втаптывать свинок в грязь
Не, мне не интересно. Тебя обломали, сам и прессуй сколько хочешь — с чего бы за тебя мстить?
Стоит ли оно того? Вот если бы денег предложил...
S>особенно тех из них, что ходят на каблуках, в короткой юбке и обтягивающих колготках, и макияжем, на который видимо уходит все нерабочее время
У тебя, наверное, внерабочее время уходит на что-то более полезное :) Поздравляю.
Хотя, возможно ты просто завидуешь им. Ну, тогда можешь дома так же одеваться.
S>я кстати готов даже их пародировать, сколь бы это не подходило моему облику S>нужно растопырив мизинцы идти виляя задом с блаженной лыбой на мордочке...
Как в воду глядел ^^
S>можно даже организовать гильдию программистов и проплатить такую акцию — вероятно все будут довольны S>пропрофанировать эту пургу к чертям
Ух, уже интереснее. Сколько платишь?
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, bkat:: >> Так что не запорет. Элементарно не дадут Р>Ну и слава богу.
Особенность предметной области в том, что компания может себе позволить тратить годы на разработку модуля, аналогичные которому по сложности во внешнем мире решаются за два месяца. Бо все оба конкурента тормоза еще большие, а молодым и энергичным ребятам из гаражей вход в эту индустрию заказан.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
B>>>А как же получение опыта от общения с реальными пользователями твоего продукта? И получения опыта работы, когда помимо спокойного течения разработки, приходится внезапно отвлекаться на вопросы поддержки? Такого опыта не получишь если будешь задерживаться в компании не более чем на год-два
G>>А как это коррелирует с вопросами разработки? ГВ>Прямо и непосредственно.
Неубедительно.
G>>Или всем нужен программист, который еще и саппортом работает, и внедренцем, и тестером, и прожект-планы рисует? ГВ>Планирование, тестирование, саппорт — это всё разработка. Узкий специалист подобен флюсу, сам знаешь.
Ну тогда вообще получается что каждый разработчик долен уметь все!
Ну а на деле таких "универсальных солдат" исчезающе мало, или они уже давно в совете директоров сидят.
G>>Даже если некоторые фирмы начинают с такого, то рано или поздно всетаки вводят некоторое разделение труда. ГВ>Одно другого не исключает. Разделение труда по персоналиям нужно там, где этого самого труда оказывается достаточно много.
Неверно. Разделение труда ужно там где есть противоположнонаправленные (26 букв) интересы.
Напрмиер ПМ должен уложится в сроки, а прокдакт-менеджер должен дотянуть до релиза ключевых фич.
Программист старается быстрее реализовать функционал, а тестер страрается сломать это все.
Суть в том что не должен один человек сомещать роли с противоположными интересами. Поэтому минимальное разделение труда для успешной разработки просто необходимо.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>На самом деле saprxm кое-в чём прав. 8-часовой рабочий день "от... до..." — это копия расписания из механической индустрии и программистам, в общем, не релевантна. G>>Этого утверждения в его сообщении я не увидел.
ГВ>Учимся читать написанное:
ГВ>
с другой стороны всем нужно раз и навсегда признать и постоянно держать в голове:
ГВ>работа программистом по 8 часов + час обед + 1.5 часа дорога — это для человека не нормальные условия, какой бы интересной работа ни была
ГВ>это не полезно для кровеносной системы, для позвоночника (вообще для опорно-двигательного аппарата) и что немаловажно — для психики
и где тут про то что это программистам не релевантно? тут про то, что это для человека ненормально.
не, ну я в принципе согласен, что 8-часовой рабочий день это не нормально
Здравствуйте, baily, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>>>>>Или всем нужен программист, который еще и саппортом работает, и внедренцем, и тестером, и прожект-планы рисует?
B>>>>>А как вы хотели? Программист должен в той или иной мере тестировать свой код, составлять план на свою работу. А также должен решать и некоторые проблемы саппорта. Это не означает, что в фирме не нужны тестеры и саппорт. G>>>>Называй вещи своими именами. Если разработчик пишет код, то он должен убедится в его корректности хотябы на подмножестве входных значений. Тестированием это назвать сложно. G>>>>А вот когда разработчика нагружают еще обязанностями поиска ошибок, то эффективность работы падает сильно.
B>>>Ну если вопрос только в терминологии G>>Вопрос именно в выполняемых задачах.
B>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода.
Смешно. Зачем же тогда крупные конторы держат штат тестеров?
Попробуй в своем коде найти все ошибки. Это вообще говоря потребует времени большего, чем на кодирование.
Кто за тебя программы писать будет?
B>>>А собирают ли у вас на работе файлы трассировки и дампы падения. А кто занимается их анализом? Обязан ли он это делать? G>>Сначала тестер, а если выявится баг, то разработчики править будут. Сбором саппорт занимается. G>>Далеко не все дампы будут попадать разработчикам.
B>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем.
Ну вот, а ты предлагаешь повесить саппорт на разработчиков.
B>Тем не менее, в случае возникновения нештатных ситаций ( а кто пишет безбажный код? ), помочь сможет только разработчик. А кто же еще?
Но его роль будет сводиться к исправлениб бага.
Выявление бага будет на совести тестера.
Вот тебе и разделение труда.
B>И вот тут можно получить просто неоценимый опыт того, как писать программы так, чтобы быстро суметь понять в чем проблема и как ее решать.
Это к саппорту вообще мало отношения имеет.
B>Можно сказать, прочувствовать на своей шкуре последствия наступания на грабли.
Красивые лозунги. Может сразу как в видеоролике "We share your pain" от МС?
B>>>Как тут правильно писали, цикл разработки обычно длится больше года, и если нигде больше года не работать, то некоторые нюансы останутся за бортом. G>>Ну у кого-то больше года, а у кого-то по 3 стабильных релиза в день B>Это что же за область такая? Все ли релизы одинаковы полезны
А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты.
После этого тестеры находят по одному багу в неделю при ручном тестировании.
B>>>>>Опять же — общение с клиентами. Вы для кого пишите продукт? Неужели вам неинтересно мнение пользователей о нем? G>>>>Одно дело интерес, а другое — обязанности разработчика. B>>>Ну так речь шла о получаемом опыте, а не об обязанностях G>>Ну и как этот опыт поможет программисту при нормальном разделении труда?
B>Как и любой механизм обратной связи. Можно годами делать ошибки и не замечать этого, так как в тот момент, когда проявятся последствия этих ошибок, вы уже будете "приобретать опыт" на новом месте работы.
Обратную связ можно и подругому получить. Иметь для этого мастеров-универсалов (и требоваться такое при приеме на работу) не самая лучшая идея.
Здравствуйте, saprxm, Вы писали:
S>речь хотел завести еще об одном вопросе (или по крайней мере чтобы он был в поле зрения при обсуждении), но видимо он пока остался в тени
S>дело в следующем: S>программисты программируют, автоматизируют, делают полезную работу S>по справедливости эта работа должна быть оплачена очень хорошо S>потому что завтра продукты сегодняшней автоматизации будут сокращать количество рабочих мест (например продавцов — замена торговыми автоматами) S>в итоге это будет усиливать конкуренцию на рынке труда, и всем нам сделает хуже
Программисты будут конкурировать с продавцами?
S>в дальнейшемм регулярную прибыль (в итоге большая) от автоматизации будут получать не программисты, а те кто однажды оплатил их труд
S>это все к томуу, что если мы вообще принимаем такую модель S>(хотя очевидно, что она уже порочна, но она общепринята, а против хмыриной системы в одиночку не попрешь), S>то нам всем как, классу программистов, следует сделать все возможное, чтобы максимум бабла попала в итоге к нам в руки S>для этого нужно избавить нашу прибыть от ненужного, непродуктивного персонала, таких как HR, менеджмент
Вот же ехремист! Сразу видно — из Питера!
S>Потому что эти должности — детали хмыриной системы, которая не доводит до нас всей нашей прибыли S>и вессь этот этикет при трудоустройстве — это интерфейс выстроенный для нас, проходя через который будущий рабоотник показывает свою лояльность к существующему порядку
Всё тебе системы мерещатся, которые надо уничтожать. Угомонись. HR, как и прочий менеджмент — это вспомогательная функция. Их не нужно никуда выкидывать, разгонять, вышвыривать на улицу и творить всякие непотребства. Их нужно просто загружать своим делом. И перестать лебезить, даже если им очень этого хочется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, genre, Вы писали:
G>и где тут про то что это программистам не релевантно? тут про то, что это для человека ненормально.
G>не, ну я в принципе согласен, что 8-часовой рабочий день это не нормально
Это нормально и правильно для другой деятельности. Те же заводы, магазины — они предполагают наличие людей на рабочем месте в определённое время по производственным причинам. Я сделал скидку на то, что, как это стало ясно, топикстартер нередко слишком обобщает подходы IT-индустрии, потому и соотнёс его высказывание с программистами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
B>>>>Ну если вопрос только в терминологии G>>>Вопрос именно в выполняемых задачах.
B>>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода. G>Смешно. Зачем же тогда крупные конторы держат штат тестеров? G>Попробуй в своем коде найти все ошибки. Это вообще говоря потребует времени большего, чем на кодирование. G>Кто за тебя программы писать будет?
Да уж. Нет слов. Вы это серъезно пишите или стебетесь?
То есть по вашему надо после того как что-то скомпилировалось сразу выкладывать "стабильный релиз"? Неудивительно что их у вас получается по 3 в день.
B>>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем. G>Ну вот, а ты предлагаешь повесить саппорт на разработчиков.
Ссылку в студию, где я это предлагал. Я говорил о том, что полностью оградиться от саппорта не удастся.
B>>Тем не менее, в случае возникновения нештатных ситаций ( а кто пишет безбажный код? ), помочь сможет только разработчик. А кто же еще? G>Но его роль будет сводиться к исправлениб бага. G>Выявление бага будет на совести тестера. G>Вот тебе и разделение труда.
Ну найдет тебе тестер баг. Но перед тем как его поправить, кто будет устанавливать причину бага? Или у вас тестеры копаются в дампах, а потом говорят — исправь в файле таком-то строчку такую-то?
B>>И вот тут можно получить просто неоценимый опыт того, как писать программы так, чтобы быстро суметь понять в чем проблема и как ее решать. G>Это к саппорту вообще мало отношения имеет.
А к чему же это имеет отношение? Одно дело багфикс в процессе разработки, до релиза. Совсем другое багфикс для реального продукта, когда проблема у реального пользователя.
B>>Можно сказать, прочувствовать на своей шкуре последствия наступания на грабли. G>Красивые лозунги. Может сразу как в видеоролике "We share your pain" от МС?
Ну можно и так. Только скорее всего долго так делать не получится. Прийдется искать новую работу. Либо потому, что руководство на фирме грамотное и вовремя турнет такого "программиста". Либо, если руководство неграмотное, то грохнется сама фирма.
B>>>>Как тут правильно писали, цикл разработки обычно длится больше года, и если нигде больше года не работать, то некоторые нюансы останутся за бортом. G>>>Ну у кого-то больше года, а у кого-то по 3 стабильных релиза в день B>>Это что же за область такая? Все ли релизы одинаковы полезны G>А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты. G>После этого тестеры находят по одному багу в неделю при ручном тестировании.
Ну если все автотесты проходят — это однозначно релиз!
G>>>Ну и как этот опыт поможет программисту при нормальном разделении труда?
B>>Как и любой механизм обратной связи. Можно годами делать ошибки и не замечать этого, так как в тот момент, когда проявятся последствия этих ошибок, вы уже будете "приобретать опыт" на новом месте работы. G>Обратную связ можно и подругому получить. Иметь для этого мастеров-универсалов (и требоваться такое при приеме на работу) не самая лучшая идея.
Обратная связь — понятие широкое. Здесь идет речь об отзыве пользователей на именно ТВОЮ работу, причем некоторые отзывы ОБЯЗУЮТ тебя исправить твои ошибки ЗДЕСЬ и СЕЙЧАС. По другому получить такую связь невозможно
Этим не надо проникаться. Такие вещи нужно сформулировать в документе, который называется "Configuration Management Policy". Если такой документ есть, то у нормального специалиста освоение среды займёт совсем не много времени.
Я так понимаю, что прочитав кулинарный рецепт, написанный местным гуру, он сможет работать только по кулинарному реепту и в случае любых вопросов будет дергать того же гуру. Такой специалист, ИМХО, менее ценен чем тот кто знает ПОЧЕМУ в "Configuration Management Policy" прописаны те или иные вещи.
Здравствуйте, baily, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>>>Ну если вопрос только в терминологии G>>>>Вопрос именно в выполняемых задачах.
B>>>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода. G>>Смешно. Зачем же тогда крупные конторы держат штат тестеров? G>>Попробуй в своем коде найти все ошибки. Это вообще говоря потребует времени большего, чем на кодирование. G>>Кто за тебя программы писать будет?
B>Да уж. Нет слов. Вы это серъезно пишите или стебетесь?
Серьезно.
B>То есть по вашему надо после того как что-то скомпилировалось сразу выкладывать "стабильный релиз"? Неудивительно что их у вас получается по 3 в день.
Нет, проходится еще дофига автоматических тестов.
B>>>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем. G>>Ну вот, а ты предлагаешь повесить саппорт на разработчиков. B>Ссылку в студию, где я это предлагал. Я говорил о том, что полностью оградиться от саппорта не удастся. http://www.rsdn.ru/forum/job/3565330.aspx
А как же получение опыта от общения с реальными пользователями твоего продукта? И получения опыта работы, когда помимо спокойного течения разработки, приходится внезапно отвлекаться на вопросы поддержки? Такого опыта не получишь если будешь задерживаться в компании не более чем на год-два
Выделенное как раз предполагает вешание функций саппорта на разработчиков.
Если саппорт от разработки отделен, то не будет такого что придтеся "внезапно отвлекаться".
B>>>Тем не менее, в случае возникновения нештатных ситаций ( а кто пишет безбажный код? ), помочь сможет только разработчик. А кто же еще? G>>Но его роль будет сводиться к исправлениб бага. G>>Выявление бага будет на совести тестера. G>>Вот тебе и разделение труда.
B>Ну найдет тебе тестер баг. Но перед тем как его поправить, кто будет устанавливать причину бага? Или у вас тестеры копаются в дампах, а потом говорят — исправь в файле таком-то строчку такую-то?
Нет, тестер восстанавливает последователньность действий, приводящих к багу.
B>>>И вот тут можно получить просто неоценимый опыт того, как писать программы так, чтобы быстро суметь понять в чем проблема и как ее решать. G>>Это к саппорту вообще мало отношения имеет.
B>А к чему же это имеет отношение? Одно дело багфикс в процессе разработки, до релиза. Совсем другое багфикс для реального продукта, когда проблема у реального пользователя.
При нормально поставленном процессе совершенно нет разницы. Добавят баг в трекрер с приоритетом "критический" и он будет исправлен как можно быстрее, а саппорт отправит новую версию как она будет готова.
B>>>>>Как тут правильно писали, цикл разработки обычно длится больше года, и если нигде больше года не работать, то некоторые нюансы останутся за бортом. G>>>>Ну у кого-то больше года, а у кого-то по 3 стабильных релиза в день B>>>Это что же за область такая? Все ли релизы одинаковы полезны G>>А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты. G>>После этого тестеры находят по одному багу в неделю при ручном тестировании.
B> Ну если все автотесты проходят — это однозначно релиз!
Упс, это я напутал. Конечно же стабильные билды, а релизы примерно раз в неделю-две.
B>Обратная связь — понятие широкое. Здесь идет речь об отзыве пользователей на именно ТВОЮ работу, причем некоторые отзывы ОБЯЗУЮТ тебя исправить твои ошибки ЗДЕСЬ и СЕЙЧАС.
И зачем такая обратная связь нужна? Думаешь пользователи лучше разбираются в управлении проектом и знаю когда и кому чего делать надо?
Расскажи это серьезному ПМу, он тебя нафиг пошлет с такой обратной связью.
B>По другому получить такую связь невозможно.
И не нужно её получать.
Здравствуйте, gandjustas, Вы писали:
G>>>Или всем нужен программист, который еще и саппортом работает, и внедренцем, и тестером, и прожект-планы рисует? ГВ>>Планирование, тестирование, саппорт — это всё разработка. Узкий специалист подобен флюсу, сам знаешь. G>Ну тогда вообще получается что каждый разработчик долен уметь все!
В общем — да. Умения лишними не бывают.
G>Ну а на деле таких "универсальных солдат" исчезающе мало, или они уже давно в совете директоров сидят.
Ой, да ладно. Типа, совет директоров — ахти какой ништяк. Невероятно много людей с запудренными мозгами — это да.
G>>>Даже если некоторые фирмы начинают с такого, то рано или поздно всетаки вводят некоторое разделение труда. ГВ>>Одно другого не исключает. Разделение труда по персоналиям нужно там, где этого самого труда оказывается достаточно много. G>Неверно. Разделение труда ужно там где есть противоположнонаправленные (26 букв) интересы.
Что-что? При чём тут интересы. Задача одна — выпустить продукт.
G>Напрмиер ПМ должен уложится в сроки, а прокдакт-менеджер должен дотянуть до релиза ключевых фич.
А кому нужны сроки без ключевых фич? Кому нужны фичи без ключевых сроков?
G>Программист старается быстрее реализовать функционал, а тестер страрается сломать это все.
Кому нужен функционал, о котором не известно — работает он, или нет? И что за глупость про "быстрее"? Тестер тоже старается сломать всё побыстрее.
G>Суть в том что не должен один человек сомещать роли с противоположными интересами. Поэтому минимальное разделение труда для успешной разработки просто необходимо. G>Об этом можно прочитать в MSF Team Model
В RUP тоже много чего написано. Сути это не меняет — разработчик должен разбираться и в методах тестирования, и в управлении, и ещё в куче смежных вещей. ИМХО, чем больше он знает, тем ценнее, как разработчик. Однако это знание вовсе не означает систематическое выполнение работ по определённой роли. Что ему в совете директоров делать? Квалификацию терять?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Этим не надо проникаться. Такие вещи нужно сформулировать в документе, который называется "Configuration Management Policy". Если такой документ есть, то у нормального специалиста освоение среды займёт совсем не много времени.
EOH>Я так понимаю, что прочитав кулинарный рецепт, написанный местным гуру, он сможет работать только по кулинарному реепту и в случае любых вопросов будет дергать того же гуру. Такой специалист, ИМХО, менее ценен чем тот кто знает ПОЧЕМУ в "Configuration Management Policy" прописаны те или иные вещи.
Хм. Если в CMP внести главу с описанием жизненного цикла продукта, то вопросы, в общем, в большинстве отпадут. Это, вроде как, нормально. Для людей же пишется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>>>Или всем нужен программист, который еще и саппортом работает, и внедренцем, и тестером, и прожект-планы рисует? ГВ>>>Планирование, тестирование, саппорт — это всё разработка. Узкий специалист подобен флюсу, сам знаешь. G>>Ну тогда вообще получается что каждый разработчик долен уметь все!
ГВ>В общем — да. Умения лишними не бывают.
G>>Ну а на деле таких "универсальных солдат" исчезающе мало, или они уже давно в совете директоров сидят.
ГВ>Ой, да ладно. Типа, совет директоров — ахти какой ништяк. Невероятно много людей с запудренными мозгами — это да.
G>>>>Даже если некоторые фирмы начинают с такого, то рано или поздно всетаки вводят некоторое разделение труда. ГВ>>>Одно другого не исключает. Разделение труда по персоналиям нужно там, где этого самого труда оказывается достаточно много. G>>Неверно. Разделение труда ужно там где есть противоположнонаправленные (26 букв) интересы.
ГВ>Что-что? При чём тут интересы. Задача одна — выпустить продукт.
А попробуй декомпозировать "выпустить продукт" сразу же получишь "уложиться в сроки" и "сделать все фичи".
G>>Напрмиер ПМ должен уложится в сроки, а прокдакт-менеджер должен дотянуть до релиза ключевых фич. ГВ>А кому нужны сроки без ключевых фич? Кому нужны фичи без ключевых сроков?
Вот и думать надо, причем желательно разным людям. Когда такие вопросы решает один человек, то обычно делается выбор в пользу сроков и урезания фич. А потом с помощью маркетинга пытаются продавать очередной notepad, в надежде насобирать денег на вторую версию.
G>>Программист старается быстрее реализовать функционал, а тестер страрается сломать это все. ГВ>Кому нужен функционал, о котором не известно — работает он, или нет?
Обычно программист удостоверивается что его код работает на каком-то подмножестве входных значений. Но этого недостатточно.
ГВ>И что за глупость про "быстрее"?
Потому что сроки.
ГВ>Тестер тоже старается сломать всё побыстрее.
Тестер в первую очередь старается сломать все, а по скорости — уже как получится.
G>>Суть в том что не должен один человек сомещать роли с противоположными интересами. Поэтому минимальное разделение труда для успешной разработки просто необходимо. G>>Об этом можно прочитать в MSF Team Model
ГВ>Сути это не меняет — разработчик должен разбираться и в методах тестирования, и в управлении, и ещё в куче смежных вещей.
Кому должен?
Следует немного изменить формулировку примерно так: "Хороший разработчик обычно разбирается во всех этих вещах".
ГВ>ИМХО, чем больше он знает, тем ценнее, как разработчик.
Примерно тоже что я написал выше. Обратное неверно вообще говоря.
Поэтому при наборе на должность рядового программиста все эти навыки имеют мало значения.
ГВ>Однако это знание вовсе не означает систематическое выполнение работ по определённой роли. Что ему в совете директоров делать? Квалификацию терять?
Наоборот, я бы такому посоветовал искать работу где все его знания и уменя будут применены в той пропорции как его больше устраивает.
А если занания и умения растут со временем, то человек 10 раз вполне может поменять работу.
Здравствуйте, gandjustas, Вы писали:
B>>>>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода. G>>>Смешно. Зачем же тогда крупные конторы держат штат тестеров? G>>>Попробуй в своем коде найти все ошибки. Это вообще говоря потребует времени большего, чем на кодирование. G>>>Кто за тебя программы писать будет?
B>>Да уж. Нет слов. Вы это серъезно пишите или стебетесь? G>Серьезно.
B>>То есть по вашему надо после того как что-то скомпилировалось сразу выкладывать "стабильный релиз"? Неудивительно что их у вас получается по 3 в день. G>Нет, проходится еще дофига автоматических тестов.
Прекрасно. А кто пишет автотесты? Только тестеры?
B>>>>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем. G>>>Ну вот, а ты предлагаешь повесить саппорт на разработчиков. B>>Ссылку в студию, где я это предлагал. Я говорил о том, что полностью оградиться от саппорта не удастся. G>http://www.rsdn.ru/forum/job/3565330.aspx
G>А как же получение опыта от общения с реальными пользователями твоего продукта? И получения опыта работы, когда помимо спокойного течения разработки, приходится внезапно отвлекаться на вопросы поддержки? Такого опыта не получишь если будешь задерживаться в компании не более чем на год-два
G>Выделенное как раз предполагает вешание функций саппорта на разработчиков. G>Если саппорт от разработки отделен, то не будет такого что придтеся "внезапно отвлекаться".
Назовите это как хотите. Но по сути это означает следующее. Вы планомерно работатете по планам на текущую версию. И тут вам приходится эти работы отложить, чтобы решить проблему, возникшую у пользователя. Будет ли это после обычного письма или звонка от поддержки или вашего начальника, либо когда вам прийдет критический баг через багтрекер. Именно эти обязанности разработчика я называю относящимися к саппорту.
B>>>>Тем не менее, в случае возникновения нештатных ситаций ( а кто пишет безбажный код? ), помочь сможет только разработчик. А кто же еще? G>>>Но его роль будет сводиться к исправлениб бага. G>>>Выявление бага будет на совести тестера. G>>>Вот тебе и разделение труда.
B>>Ну найдет тебе тестер баг. Но перед тем как его поправить, кто будет устанавливать причину бага? Или у вас тестеры копаются в дампах, а потом говорят — исправь в файле таком-то строчку такую-то? G>Нет, тестер восстанавливает последователньность действий, приводящих к багу.
Далеко не всегда это возможно. Бывают, например, нестабильные баги. Бывает программы, которые работают непрерывно сутками. И вот, в процессе работы, программа падает. Получается дамп, который и высылается разработчику.
Много чего еще бывает такого, когда невозможно повторить последователньность действий, приводящих к багу.
B>>>>И вот тут можно получить просто неоценимый опыт того, как писать программы так, чтобы быстро суметь понять в чем проблема и как ее решать. G>>>Это к саппорту вообще мало отношения имеет.
B>>А к чему же это имеет отношение? Одно дело багфикс в процессе разработки, до релиза. Совсем другое багфикс для реального продукта, когда проблема у реального пользователя. G>При нормально поставленном процессе совершенно нет разницы. Добавят баг в трекрер с приоритетом "критический" и он будет исправлен как можно быстрее, а саппорт отправит новую версию как она будет готова.
Разница в том, что в первом случае багфикс ведется в рамках разработки текущего продукта, когда в голове еще свежи все детали, и когда можно все взять и поменять. А вот во втором случае уже гораздо веселее. Не всегда можно пользователю сказать — снеси старую версию с багой и поставь новую без баги, все заново настрой, разверни и т.п
G>>>А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты. G>>>После этого тестеры находят по одному багу в неделю при ручном тестировании.
B>> Ну если все автотесты проходят — это однозначно релиз!
G>Упс, это я напутал. Конечно же стабильные билды, а релизы примерно раз в неделю-две.
У вас специфичная область. Не везде можно выкатывать релизы так часто.
B>>Обратная связь — понятие широкое. Здесь идет речь об отзыве пользователей на именно ТВОЮ работу, причем некоторые отзывы ОБЯЗУЮТ тебя исправить твои ошибки ЗДЕСЬ и СЕЙЧАС. G>И зачем такая обратная связь нужна? Думаешь пользователи лучше разбираются в управлении проектом и знаю когда и кому чего делать надо? G>Расскажи это серьезному ПМу, он тебя нафиг пошлет с такой обратной связью.
Ну если продукт пишется для пользователей, то, представь себе, они лучше знают чего им от продукта надо.
Здравствуйте, Vzhyk, Вы писали:
>> На самом деле все гораздо хуже бывает, когда документации нет, людей или >> уже тоже нет или не помнят. На вопрос как правильно начинают >> рассказывать противоречащие друг другу варианты. Лезешь в исходник, >> чтобы докопаться до сути, потом высняешь, что исходник уж год как >> устарел и не используется в продакшене. А пока ты вовсем этом >> разбираешься, планы, задачи, код меняются. V>Обычный бардак.
Здравствуйте, gandjustas, Вы писали:
G>>>Неверно. Разделение труда ужно там где есть противоположнонаправленные (26 букв) интересы. ГВ>>Что-что? При чём тут интересы. Задача одна — выпустить продукт. G>А попробуй декомпозировать "выпустить продукт" сразу же получишь "уложиться в сроки" и "сделать все фичи".
Да, только противоречия между ними нет, если сроки выставляются обоснованно.
G>>>Напрмиер ПМ должен уложится в сроки, а прокдакт-менеджер должен дотянуть до релиза ключевых фич. ГВ>>А кому нужны сроки без ключевых фич? Кому нужны фичи без ключевых сроков? G>Вот и думать надо, причем желательно разным людям. Когда такие вопросы решает один человек, то обычно делается выбор в пользу сроков и урезания фич. А потом с помощью маркетинга пытаются продавать очередной notepad, в надежде насобирать денег на вторую версию.
Это тебе кто сказал такое, про "обычно"? Обычно люди необычны.
G>>>Программист старается быстрее реализовать функционал, а тестер страрается сломать это все. ГВ>>Кому нужен функционал, о котором не известно — работает он, или нет? G>Обычно программист удостоверивается что его код работает на каком-то подмножестве входных значений. Но этого недостатточно.
если рядом бегает менеджер с "ортогональными интересами", то так и будет, Hundred percents!
ГВ>>И что за глупость про "быстрее"? G>Потому что сроки.
Так "быстрее" или "сроки"?
ГВ>>Тестер тоже старается сломать всё побыстрее. G>Тестер в первую очередь старается сломать все, а по скорости — уже как получится.
Во, как. Значит, тестер может сорвать сроки проекта. Это новость дня. Слушай, ну не пой ты мне эти глупые стереотипы, а? Осточертели уже. Родилось всё это барахло, когда таксисты валом валили в программистов, а закрепилось, чуть ли не как Талмуд. Мне, конечно, начхать, что там на каком заборе написано, и что очередной "гуру" от "современных технологий" взбзднул, но вы ж молодняк портите, засранцы. Это не к тебе персонально, это так, глас вопиющего в пустыне.
G>>>Суть в том что не должен один человек сомещать роли с противоположными интересами. Поэтому минимальное разделение труда для успешной разработки просто необходимо. G>>>Об этом можно прочитать в MSF Team Model
ГВ>>Сути это не меняет — разработчик должен разбираться и в методах тестирования, и в управлении, и ещё в куче смежных вещей. G>Кому должен?
Себе. Поскольку знание x понимание — это аргумент, перевешивающий тысячи процессных бульбуканий и прочих кликушеств.
G>Следует немного изменить формулировку примерно так: "Хороший разработчик обычно разбирается во всех этих вещах".
А... Ну да, верно.
ГВ>>ИМХО, чем больше он знает, тем ценнее, как разработчик. G>Примерно тоже что я написал выше. Обратное неверно вообще говоря.
Обратное — это как? Как выглядит противоположное высказывание? Я что-то модальности вычислить не могу.
G>Поэтому при наборе на должность рядового программиста все эти навыки имеют мало значения.
Хорошие разработчики не пойдут на должность "рядового" программиста. В силу того, что им чужда игра в "ряды", "строи", и всякую прочую "армию" офисных генералов. Ergo, набирая "рядовых программистов" велика вероятность сразу набрать не-хороших разработчиков. СиллогизмЪ!
ГВ>>Однако это знание вовсе не означает систематическое выполнение работ по определённой роли. Что ему в совете директоров делать? Квалификацию терять? G>Наоборот, я бы такому посоветовал искать работу где все его знания и уменя будут применены в той пропорции как его больше устраивает.
О! Что и требовалось доказать. Хороший разработчики в рядовые программисты не пойдут. Ergo, хотите получить хороших разработчиков — забудьте о "построении". Респект.
G>А если занания и умения растут со временем, то человек 10 раз вполне может поменять работу.
О чём и речь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Lloyd пишет: > >> > На самом деле все гораздо хуже бывает, когда документации нет, людей или >> > уже тоже нет или не помнят. На вопрос как правильно начинают >> > рассказывать противоречащие друг другу варианты. Лезешь в исходник, >> > чтобы докопаться до сути, потом высняешь, что исходник уж год как >> > устарел и не используется в продакшене. А пока ты вовсем этом >> > разбираешься, планы, задачи, код меняются. > V>Обычный бардак. > > Ставишь диагноз по фотографии?
Нет. По твоему описанию. То, что ты описал выше — это и есть
обыкновенный бардак.
Здравствуйте, baily, Вы писали:
B>>>То есть по вашему надо после того как что-то скомпилировалось сразу выкладывать "стабильный релиз"? Неудивительно что их у вас получается по 3 в день. G>>Нет, проходится еще дофига автоматических тестов.
B>Прекрасно. А кто пишет автотесты? Только тестеры?
Именно тестеры! При том, они пишут автотесты по искажённым спецификациям, чтобы поломать всё бульдозером! Типа, из расчёта, что вместо int прилетает float... NAN-float.
G>>Нет, тестер восстанавливает последователньность действий, приводящих к багу. B>Далеко не всегда это возможно. Бывают, например, нестабильные баги. Бывает программы, которые работают непрерывно сутками. И вот, в процессе работы, программа падает. Получается дамп, который и высылается разработчику. B>Много чего еще бывает такого, когда невозможно повторить последователньность действий, приводящих к багу.
Больше того, иной раз приходится искать именно такую материнку и именно такую плату. Или — плотно медитировать над потенциальными ошибками, пользуясь обрывочными сведениями из интернета.
B>>>Обратная связь — понятие широкое. Здесь идет речь об отзыве пользователей на именно ТВОЮ работу, причем некоторые отзывы ОБЯЗУЮТ тебя исправить твои ошибки ЗДЕСЬ и СЕЙЧАС. G>>И зачем такая обратная связь нужна? Думаешь пользователи лучше разбираются в управлении проектом и знаю когда и кому чего делать надо? G>>Расскажи это серьезному ПМу, он тебя нафиг пошлет с такой обратной связью. B>Ну если продукт пишется для пользователей, то, представь себе, они лучше знают чего им от продукта надо.
+1. Только пользователи определяют, что в конечном итоге будет включено в продукт. ПМ в данном случае — сошка-передатчик.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Ну если все автотесты проходят — это однозначно релиз!
