Прошу считать нижеизложенное криком души Как же меня все это за-дол-ба-ло
Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую.. Упс! Его ждал сюрпрайз — страница не работает! Команда девелоперов получает email полный скриншотов и всхлипов. При ближайшем рассмотрении выясняется, что один из классов не помечен атрибутом Serialized. При copy-paste потерялся, знаете ли. Работы на две минуты ровно — поставить атрибут, проранать ограниченную версию билда и дропнуть dll-ку в нужное место на нужном сервере. Так? Ага счаззззз. Далее — примерная хронология событий.
10:50 Фиксаю аттрибут. Делаю check-in
10:55 Запрашиваю билд. Патаму чта билд я сама сделать не могу. Это не порядок когда девелоперы сами делают билды, вы что. Для билдов у нас есть отдельный тим. И когда мне нужен билд — я им шлю емайл.
11:10 Тишина
11:20 Тишина
11:30 Второй запрос билда. Молчание служит мне ответом
11:50 Звонок сотрудникам типа ответственного за билд
12:10 Build started — не прошло и года
12:20 — 1:00 — Мой ланч
1:00 Build failed... Звонок по телефону и выяснение что
1:00 — 2:00 — ланч тима который отвечает за билд
2:00 — Уфффф! Build copmplete!
2:10 — беру с билд-машины dll-ку, пакую ее вместе с инструкциями и отсылаю бизнес аналитику. Ага, а вы как думали. Я сама никак не могу эту dll-ку в нужное место дропнуть. Впрочем аналист который вообще не знает что такое dll-ка тоже не может ее дропнуть. Зато он может, и должен, создать запрос в bug tracking system и отправить его еще другому тиму — те его исполнят. А я такой запрос создать не могу Потому что за демонстрационный сервер отвечают бизнес-аналитики
2:20 Бизнес аналитик ушел на митинг
2:30 Бизнес аналитик пришел с митинга
3:00 Бизнес аналитик создал запрос на хот-фикс
3:30 Бизнес аналитик поинтересовался почему его запрос еще никто не открыл?
4:00 БА сбегал на другой этаж пешком и слезно попросил таки исполнить его запрос
4:30 Hotfix complete!
4:30-5:00 БА тестирует страницу. Страница по прежнему не работает. Команда девелоперов получает емейл полный скриншотов и соплей. После короткого совещания выясняется что эти трагладиты на верхнем этаже не сделали iisreset.
5:30 Для делания iisreset создается отдельный запрос в bug tracking system. Один из девелоперов идет наверх и лично сидит на голове системщиков пока они делают iisreset
6:00 Страница работает. Рабочий день закончен. Демонстрашка клиенту сорвана, но про такие мелочи уже никто не вспоминает.
...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
X>4:30-5:00 После короткого совещания выясняется что эти трагладиты на верхнем этаже не сделали iisreset. X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
А мы в Down Under юзаем Open Source ... рабочего процесса и в помине нет
Хотя.. надвигается внедреж того, что мы налабали. Думаю, скоро будет чего рассказать про рабочие процессы
Здравствуйте, Xenia, Вы писали:
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами.
Зато все при делах
X>А как у вас в конторе обстоят дела с организацией рабочего процесса?
Хорошо.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
(нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много)обстоят дела с организацией рабочего процесса?
Ксюша, а вы откуда? У вас дешовые аналитики по 40К, а у нас дорогие по 24К Давайте меняться
Здравствуйте, Xenia, Вы писали:
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
сделать инсталлер. штоп сут-эн-пасты не терялись. а то так и будете дальше кактусы лопать.
Слушайте, у вас куча всяких отделов, как я погляжу... А тестеров нет что ли? Зачем показывать кастомеру неоттестированное приложение?
У нас фиксы проходят в таком порядке:
1) Запрос саппорту от кастомера, они разбираются действительно ли это наша бага.
2) Саппорт согласует с PM сроки фикса (под фиксом подразумевается сам фикс и тестирование его отделом QA)
3) Выполняется фикс (билды запускаются нами же, нажатием отдной кнопульки — start build
4) Фикс тестируется отделом QA
5) Отправляется саппорту
6) Саппорт отправляет кастомеру.
Но у нас нескольно другой тип продукта — коробочный.
Поверь мне, бывает намного хуже.
Например, когда из-за д%№%;№:ма высшего и среднего руководства рядовые сотрудники регулярно работают сверхурочно и получают за это копейки. Хуже того — руководство считает, что это нормально и по другому вообще нельзя.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Xenia, Вы писали:
S>(нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много)обстоят дела с организацией рабочего процесса? S>Ксюша, а вы откуда? У вас дешовые аналитики по 40К, а у нас дорогие по 24К Давайте меняться
Проблема в том, что баг обнаружился прямо перед демонстрацией.
Т.е. никому (ни девелоперам, ни тестерам, ни самому бизнес аналитику)
эта страничка была не интересна до самого последнего момента.
Такое же отношение, усиленное бумажками и тяжелым процессом, просто на всех других уровнях...
Здравствуйте, seafresh, Вы писали:
S>Здравствуйте, Xenia, Вы писали:
X>>Прошу считать нижеизложенное криком души Как же меня все это за-дол-ба-ло
S>Это бюрократия, а не бедлам. S>Утешу — а ты симпотичная.
Действительно девушка симпатичная и блузка прикольная пиджачок тоже симпатичный и причёска хорошая
[]
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Спасибо! Начало рабочего дня прошло в горячем споре ПМ предположил, что у вас там некое подобие CMM Level 5. Похоже на правду?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Xenia, Вы писали:
X>... Работы на две минуты ровно — поставить атрибут, проранать ограниченную версию билда и дропнуть dll-ку в нужное место на нужном сервере. Так?
На моей предыдущей работе было именно так. При этом следующий день начинался с двух жалоб с разных сторон по поводу того, что где-то что-то перестало работать почему-то как раз ровно с того момента времени, когда "дропнули dll-ку в нужное место на нужном сервере" И что характерно: концов не найти: кто дропнул, какую dll-ку, зачем... ведь ничего не происходило на самом деле
Почему предположил? По его словам, он работал в компании, сертифицированной (терминологию могу неверно использовать) по стандарту CMM Level 5 и что вот этот эпизод дюже сильно похож на то, что он там испытал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Ксения, ответьте, пожалуйста, на нескромный вопрос.
Могу ли я распечатать Вашу фотографию и демонстрировать ее всем, кто заявляет, что женщин-программисток не бывает?
Тот, кто желает, но не делает, распространяет чуму.
Здравствуйте, Xenia, Вы писали:
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Мда... Оказывается, я счастливый человек... Ибо из девелоперов тут один такой. Сам себе тестер, начальник, постановщик, архитектор и администратор по сути. Правда время от времени приходится делать много неинтересной рутины и пожаловаться некому (кто бы понял), кроме как в аську.
Зато хотфикс может быть и правда сделан за пару минут по звонку от парня, которому вдруг надо стало.
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Здравствуйте, Нахлобуч, Вы писали:
Н>Почему предположил? По его словам, он работал в компании, сертифицированной (терминологию могу неверно использовать) по стандарту CMM Level 5 и что вот этот эпизод дюже сильно похож на то, что он там испытал.
А вот Макконел пишет, что CMM 5-го уровня это совсем другое
Здравствуйте, Maxim Matveev, Вы писали:
Н>>Почему предположил? По его словам, он работал в компании, сертифицированной (терминологию могу неверно использовать) по стандарту CMM Level 5 и что вот этот эпизод дюже сильно похож на то, что он там испытал. MM>А вот Макконел пишет, что CMM 5-го уровня это совсем другое
Между сертификацией CMM и реальным соответствием заложенным в CMM идеям дистанция огромного размера.
"Xenia" <6204@users.rsdn.ru> wrote in message news:2165886@news.rsdn.ru... > Прошу считать нижеизложенное криком души Как же меня все это за-дол-ба-ло > > Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую.. Упс! Его ждал сюрпрайз — страница не работает! Команда девелоперов получает email полный скриншотов и всхлипов. При ближайшем рассмотрении выясняется, что один из классов не помечен атрибутом Serialized. При copy-paste потерялся, знаете ли. Работы на две минуты ровно — поставить атрибут, проранать ограниченную версию билда и дропнуть dll-ку в нужное место на нужном сервере. Так? Ага счаззззз. Далее — примерная хронология событий.
> ...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Что характерно, обратную ситуацию — когда девелоперу не только разрешается, но даже категорически приветствуется самостоятельно к паровозу пару деталек привинтить, местное комьюнити тоже считает бардаком И, скажу по секрету — все промежуточные ситуации — тоже бардак. А что, жизнь такая
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали: S>Что характерно, обратную ситуацию — когда девелоперу не только разрешается, но даже категорически приветствуется самостоятельно к паровозу пару деталек привинтить, местное комьюнити тоже считает бардаком И, скажу по секрету — все промежуточные ситуации — тоже бардак. А что, жизнь такая
В данном случае разделение труда по типу одни могут отвертку держать(и только держать), а другие крутить ее могут.
Здравствуйте, Xenia, Вы писали:
X>Прошу считать нижеизложенное криком души Как же меня все это за-дол-ба-ло
X>10:50 Фиксаю аттрибут. Делаю check-in
[] X>6:00 Страница работает. Рабочий день закончен. Демонстрашка клиенту сорвана, но про такие мелочи уже никто не вспоминает.
В компании с "Толстяком" время летит незаметно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Работал в одной конторе где организация работы была прямо противоположная — каждый делал что хочет и как хочет, начальник считал что любые обсуждения проектов — пустая трата времени, типа все кодить должны, а не трепаться без толку.
Бардак был ровно такой же как и в описанном топикстартером случае. Толпа людей бесперерывно мешала друг-другу, по принципу кто первый скомпилирует и билд многострадальный соберет. В обоих случаях проблема — слабоумие начальства, причем в случае описанном топикстартером ИМХО сам процесс разработки правильный, просто кто-то (скорее не автор) не умеет им пользоваться и иногда, только в виде исключения нарушать его.
Налицо некоторое несоответствие...
С одной стороны, процесс весьма бюрократичен, формализован, как следствие — затянут.
С другой стороны — этот ваш аналитик собирается что-то показывать клиенту, что никто, очевидно, не тестировал.
Нужно это несоответствие разрешить, довести до логического завершения в одну из сторон.
Или в сторону формализма и бюрократии — плотнее тестировать, и все такое. Тогда бы не зафиксили не протестированное и не собрались бы показывать не работающее.
Или в сторону свободы и скорости "я ща починю". Тогда бы починили быстро.
Наверное так
Работающего первого варианта я еще нигде не видел ну а второй, понятно, тоже чреват своими проблемами.
Здравствуйте, ora, Вы писали:
ora>Работал в одной конторе где организация работы была прямо противоположная — каждый делал что хочет и как хочет, начальник считал что любые обсуждения проектов — пустая трата времени, типа все кодить должны, а не трепаться без толку. ora>Бардак был ровно такой же как и в описанном топикстартером случае. Толпа людей бесперерывно мешала друг-другу, по принципу кто первый скомпилирует и билд многострадальный соберет. В обоих случаях проблема — слабоумие начальства, причем в случае описанном топикстартером ИМХО сам процесс разработки правильный, просто кто-то (скорее не автор) не умеет им пользоваться и иногда, только в виде исключения нарушать его.
Любые крайности — плохо. Ка грицца: слишком хорошо — это не хорошо.
V>Ксения, ответьте, пожалуйста, на нескромный вопрос. V>Могу ли я распечатать Вашу фотографию и демонстрировать ее всем, кто заявляет, что женщин-программисток не бывает?
Уважаемый волк, вы конечно можете это делать, только учтите что у вас осталось меньше года Очень скоро я перестану быть программисткой
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, Xenia, Вы писали:
Н>[]
X>>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Н>Спасибо! Начало рабочего дня прошло в горячем споре ПМ предположил, что у вас там некое подобие CMM Level 5. Похоже на правду?
За несколько лет здесь я таких "ругательных слов" ни от кого не слышала. Рискну предположить что это рукотворный бардак, не имеющий отношения ни к какой известной методологии по организации оного
Здравствуйте, bkat, Вы писали:
B>Проблема в том, что баг обнаружился прямо перед демонстрацией. B>Т.е. никому (ни девелоперам, ни тестерам, ни самому бизнес аналитику) B>эта страничка была не интересна до самого последнего момента.
B>Такое же отношение, усиленное бумажками и тяжелым процессом, просто на всех других уровнях...
Гы-гы.. а вот это наиболее интересная часть. Дело в том, что у нас тесторов нет, совсем. Их наше руководство "транклютировало" И теперь у нас и происходит весь этот "горький катаклизм" (с) Предполагается что тестирование должны делать девелоперы и бизнес аналитики. И если девелоперы худо-бедно пишут юнит тесты и ловят баги друг-друга, то про БА — даже начинать не хочется.. Повбывав бы.
Здравствуйте, Xenia, Вы писали:
X>Гы-гы.. а вот это наиболее интересная часть. Дело в том, что у нас тесторов нет, совсем. Их наше руководство "транклютировало" И теперь у нас и происходит весь этот "горький катаклизм" (с) Предполагается что тестирование должны делать девелоперы и бизнес аналитики. И если девелоперы худо-бедно пишут юнит тесты и ловят баги друг-друга, то про БА — даже начинать не хочется.. Повбывав бы.
Мне кажется, что проблема ровно в этом Если было бы ТЗ, по которому просто прошли хотя бы один раз, то на эту страничку заглянули -> баг бы поправили (пусть также долго) -> демонстрация состоялась.
Кстати, по первоначальному посту — я так и не понял, почему один день для хот-фикса это плохо? Так это нормально. Например, в онлайновых системах с рестартом один раз в сутки, менять что-то можно только в это время. Соответственно, если обнаружили что-то сегодня, то в боевой версии это сможет появится только завтра. Поэтому проблема именно в аналитике, который за час (утрирую) до клиента решил подготовить контур.
Другое дело, что у конкретного человека это не должно много времени занять, но я понял, что так и было. Правка — 2 минуты, отправка на сборку один раз, отправка на сборку второй раз, разборка с повторной ошибкой. Остальное время можно заниматься своими делами. И это тоже, имхо, нормально.
Здравствуйте, zmaks100, Вы писали:
Z>Здравствуйте, Xenia, Вы писали:
X>>Гы-гы.. а вот это наиболее интересная часть. Дело в том, что у нас тесторов нет, совсем. Их наше руководство "транклютировало" И теперь у нас и происходит весь этот "горький катаклизм" (с) Предполагается что тестирование должны делать девелоперы и бизнес аналитики. И если девелоперы худо-бедно пишут юнит тесты и ловят баги друг-друга, то про БА — даже начинать не хочется.. Повбывав бы.
Z>Мне кажется, что проблема ровно в этом Если было бы ТЗ, по которому просто прошли хотя бы один раз, то на эту страничку заглянули -> баг бы поправили (пусть также долго) -> демонстрация состоялась.
Z>Кстати, по первоначальному посту — я так и не понял, почему один день для хот-фикса это плохо? Так это нормально. Например, в онлайновых системах с рестартом один раз в сутки, менять что-то можно только в это время. Соответственно, если обнаружили что-то сегодня, то в боевой версии это сможет появится только завтра. Поэтому проблема именно в аналитике, который за час (утрирую) до клиента решил подготовить контур.
Z>Другое дело, что у конкретного человека это не должно много времени занять, но я понял, что так и было. Правка — 2 минуты, отправка на сборку один раз, отправка на сборку второй раз, разборка с повторной ошибкой. Остальное время можно заниматься своими делами. И это тоже, имхо, нормально.
Z>С уважением, zmaks100
Ну да, хотфикс в продакшне занимает сутки, но тут речь про demo-environment, ее можно дергать в любое время если только там не происходит демо. Насчет заниматься делами — в том то и дело что у людей голова — не помойка. И когда у тебя свой проект, кусочек помогаешь на другом и еще пара таких хотфиксов, которые нужно постоянно отслеживать чтобы они таки состоялись — то очень сложно сосредоточиться на самой работе. Получается что отвлекся — вернулся к работе, пока вспоминал на чем остановился — уже опять надо отвлекаться. Это приводит к тому что девелоперы просто вынуждены оставаться после 6-ти и работать в выходные. Что естественно не оплачивается как сверхурочные. Я, правда, в последнее время забила. Гребись оно все.. что мне — больше всех надо что ли. Ухожу в 5, вне зависимости от того сколько сделано за день
Здравствуйте, Xenia, Вы писали:
X>Здравствуйте, bkat, Вы писали:
B>>Проблема в том, что баг обнаружился прямо перед демонстрацией. B>>Т.е. никому (ни девелоперам, ни тестерам, ни самому бизнес аналитику) B>>эта страничка была не интересна до самого последнего момента.
B>>Такое же отношение, усиленное бумажками и тяжелым процессом, просто на всех других уровнях...
X>Гы-гы.. а вот это наиболее интересная часть. Дело в том, что у нас тесторов нет, совсем. Их наше руководство "транклютировало" И теперь у нас и происходит весь этот "горький катаклизм" (с) Предполагается что тестирование должны делать девелоперы и бизнес аналитики. И если девелоперы худо-бедно пишут юнит тесты и ловят баги друг-друга, то про БА — даже начинать не хочется.. Повбывав бы.
Ну в общем бизнес аналитик нашел баг, но немного поздновато
Процесс у вас и в самом деле слегка перегруженный для таких случаев,
а в тот день еще сработал закон бутерброда, который никогда не отказывает.
В общем у вас есть повод пересмотреть немного процесс в сторону его облегчения,
если это вообще кому-то нужно...
Здравствуйте, Xenia, Вы писали:
X>Уважаемый волк, вы конечно можете это делать, только учтите что у вас осталось меньше года Очень скоро я перестану быть программисткой
В архиректоры подадитесь что-ли?
Здравствуйте, Блудов Павел, Вы писали:
БП>Здравствуйте, Xenia, Вы писали:
X>>Уважаемый волк, вы конечно можете это делать, только учтите что у вас осталось меньше года Очень скоро я перестану быть программисткой БП>В архиректоры подадитесь что-ли?
Не, я в бизнес-школу поступила (МБА) учиться пойду
Здравствуйте, Xenia, Вы писали:
X>Здравствуйте, Блудов Павел, Вы писали:
БП>>Здравствуйте, Xenia, Вы писали:
X>>>Уважаемый волк, вы конечно можете это делать, только учтите что у вас осталось меньше года Очень скоро я перестану быть программисткой БП>>В архиректоры подадитесь что-ли? X>Не, я в бизнес-школу поступила (МБА) учиться пойду
Ага...
Значит будешь потом гонять аналитиков и разрабатывать подобные процессы?
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Xenia, Вы писали:
AF>Поверь мне, бывает намного хуже. AF>Например, когда из-за д%№%;№:ма высшего и среднего руководства рядовые сотрудники регулярно работают сверхурочно и получают за это копейки. Хуже того — руководство считает, что это нормально и по другому вообще нельзя. :maniac
Именно так, по другому нельзя, да и зачем? Не ужели Вы думаете что руководство должно пытаться экономить Ваше дешёвое время?
А весь этот оверхед всёравно оплатят, причём не кастомеры а их ещё более дешёвые рабочие в Китае. Глобализация рулит....
Здравствуйте, korzhik, Вы писали:
S>>(нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много)обстоят дела с организацией рабочего процесса? S>>Ксюша, а вы откуда? У вас дешовые аналитики по 40К, а у нас дорогие по 24К Давайте меняться
K>New York City
В NYC есть такие зарплаты? Там можно выжить на такие деньги??
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Xenia, Вы писали:
X>>Здравствуйте, Блудов Павел, Вы писали:
БП>>>Здравствуйте, Xenia, Вы писали:
X>>>>Уважаемый волк, вы конечно можете это делать, только учтите что у вас осталось меньше года Очень скоро я перестану быть программисткой БП>>>В архиректоры подадитесь что-ли? X>>Не, я в бизнес-школу поступила (МБА) учиться пойду
B>Ага... B>Значит будешь потом гонять аналитиков и разрабатывать подобные процессы?
Чур меня
Здравствуйте, kograt, Вы писали:
K>Именно так, по другому нельзя, да и зачем? Не ужели Вы думаете что руководство должно пытаться экономить Ваше дешёвое время?
K>А весь этот оверхед всёравно оплатят, причём не кастомеры а их ещё более дешёвые рабочие в Китае. Глобализация рулит....
Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит. Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
Здравствуйте, kograt, Вы писали:
K>Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит. Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
Да, МакДональдс — это хороший пример Никогда не хожу есть в подобные забегаловки. Мало ли что могут сделать с едой ненавидящие начальство сотрудники
Как там в анекдоте... "Вася, позови повара... вы посмотрите, он ест! Он ЭТО ест!!!!"
Здравствуйте, Xenia, Вы писали:
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Как я понял, основная ваша проблема в том, что нет development environment вообще. Контора может быть большой и как угодно забюрократизированной, но вся эта бюрократия должна касаться только production и соответственно deploy 2 production, где ей самое место. Очевидно, что релиз может легко занять один день и это нормально, но применять подобные policy для ежедневной работы — никому не нужный оверхед.
Так что, если нет возможности повлиять на ситуацию (что скорее всего), то только смириться. В качестве абстрактного совета могу рассказать, как было дело организованно у нас в одной немаленькой конторке.
Весь рабочий процесс разбивается на фазы:
1. Development. Происходит в development environment. С ней можно делать все что угодно на усмотрение команды. Билди когда хочешь, деплой на свой сервак, конфиги правь. Полная свобода. Даже нередко демонстрашки юзерам показываются в этом env.
2. QA. Фактически тот же dev env, т.к. баги надо фиксить побыстрее.
3. UAT. Когда QA завершился, то можно уже показывать юзерам. Все деплоится на другой сервак в UAT env и девелоперы с ним не работают. Понятно, что не очень будет здорово, если юзер увидит промежуточный фикс. Здесь тоже нет никакой бюрократии, если готова новая версия, то ее без бумажек деплоят достаточно быстро.
3. Production. Вот тут и всплывают все request, sign off-ы и прочая бумажная деятельность. Но, т.к. это происходит раз в месяц, то в принципе, это не страшно.
То же, что я увидел у вас очень напоминает кодирование прямо в production, что в любом случае не есть хорошо.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Нужно это несоответствие разрешить, довести до логического завершения в одну из сторон. iT>Или в сторону формализма и бюрократии — плотнее тестировать, и все такое. Тогда бы не зафиксили не протестированное и не собрались бы показывать не работающее.
А знаешь как обидно бывает в этом случае — вроде решение есть, оно работает, но одновременно его нет, потому что оно не прошло через все выпускающие руки
Здравствуйте, jhfrek, Вы писали:
X>>Получается что отвлекся — вернулся к работе, пока вспоминал на чем остановился — уже опять надо отвлекаться.
J>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу
Лично я "взрываюсь" на третьем-четвертом "переключении".
Чем совершеннее технически средство, тем более примитивные, никчемные и бесполезные сведения при его помощи передаются.(с)Станислав Лем
iT>>Или в сторону формализма и бюрократии — плотнее тестировать, и все такое. Тогда бы не зафиксили не протестированное и не собрались бы показывать не работающее.
J>А знаешь как обидно бывает в этом случае — вроде решение есть, оно работает, но одновременно его нет, потому что оно не прошло через все выпускающие руки
На обиженных воду возят.
Что хуже — задержать выпуск или поставить с ошибкой? Это очень depends и в разных ситуациях лучше разные крайности.
Где-то лучше подождать
Здравствуйте, L.Long, Вы писали:
LL>Здравствуйте, jhfrek, Вы писали:
X>>>Получается что отвлекся — вернулся к работе, пока вспоминал на чем остановился — уже опять надо отвлекаться.
J>>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу
LL>Лично я "взрываюсь" на третьем-четвертом "переключении".
Я взрываюсь на втором. Однажды прямо на начальство наорал (правда, оно временное было)
Здравствуйте, kograt, Вы писали:
K>Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит. Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
Не согласен.
В древности рабство было эффективно — для простых работ.
Для того чтобы сделать эффективно нетривиальную задачу — нужно мозги напрягать, соответственно умные (и мотивированные) люди.
А бизнес-процессы... Ну поставишь, будут люди друг другу отписывать, в отчетах отмечать что-нибудь, а проект завалится по причине некомпетентности исполнителей. И?
Здравствуйте, Igor Trofimov, Вы писали:
iT>На обиженных воду возят. iT>Что хуже — задержать выпуск или поставить с ошибкой? Это очень depends и в разных ситуациях лучше разные крайности. iT>Где-то лучше подождать
Эта да... Сам знаю что спешка иногда приводит к хужшим последствиям чем задержка Такова жисть
O>В качестве абстрактного совета могу рассказать, как было дело организованно у нас в одной немаленькой конторке.
Если не секрет, в какой стране находится "немаленькая конторка?"
X>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
принципиальные подробности...
и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
X>При ближайшем рассмотрении выясняется, что один из классов не помечен атрибутом Serialized. При copy-paste потерялся, знаете ли.
а это чья вина — ба, bug tracking system ?
X>Рабочий день закончен. Демонстрашка клиенту сорвана, но про такие мелочи уже никто не вспоминает.
все что надо было сделать — после добавления новой страницы посмотреть как она работает
Здравствуйте, Xenia, Вы писали:
X>Прошу считать нижеизложенное криком души Как же меня все это за-дол-ба-ло
X>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую.. Упс! Его ждал сюрпрайз — страница не работает! Команда девелоперов получает email полный скриншотов и всхлипов. При ближайшем рассмотрении выясняется, что один из классов не помечен атрибутом Serialized.
Не кажется ли вам, что винить нужно не "систему", не "дешёвого аналитика", а разработчика, который забыл поставить атрибут в коде?
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, kograt, Вы писали:
K>Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит.
Микрософт давно б загнулся если б у него 70-80% (при том что 10% уже повод бить в набат и возможно разгонять весь HR отдел к едрене фене) сотрудников в год сваливало.
K>Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
не касаясь персоналий, пример неэффективной команды в тексте был взят не со стартапов, естественно. дело в том, что они как правило не выживают от поставленных бизнес-процессов
, уверен, и с образованием и с головой и с опытом и с хорошими зарплатами\самомнением — а видно как все ужасно неэффективно используется, не так ли?
Кстати именно любовь к такого рода "поставленным бизнес-процессам" которые все компании как одна начинают пытаться внедрять (что правильно) лишь немного встав на ноги и получив немного денег (спуская их потом на ветер и не замечая этого, что все таки мне уже не кажется правильным) и сподвигла меня написать текст
Внедрить процесс это как два пальца об асфальт. Внедрить эффективный процесс — вот что достойно уважения! Почему-то мне кажется что менее 7% компаний могут гордиться таким достижением
PS про McDonalds пример не очень корректный — что нового они делают? Они фактически сервис, но никак не разработка — зачем их в IT пихать для сравнения? Конечно, имеет смысл в их условиях пользовать "обезьян" по-максимуму — и то только если говорить о сотрудниках самого низшего звена. Не думаю что в управлении у них такая же текучка и низкие зарплаты — подумайте об этом
PPS Если же искать аналогию McDonalds в IT то это похоже на саппорт какого-то продукта. Да, бывает, имеет смысл сажать студентов с текучкой 70-80% — этого я не отрицал — в определенной ситуации такая стратегия может быть оправдана, кто ж спорит. Просто Вы немного передернули суть топика и уехали в McDonalds, а мы все ж в основной массе не оттуда
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
А с каких пор тебя интересуют проблемы бизнеса и поставки клиентам?
Ты кто — программист или сейлз-менеджер или ПМ? — ты за это получаешь деньги?
Вот меня совершенно не волнует кому и что поставляется и в какие сроки... Это не моя работа и мне за ней денег не платят... Сроки — это проблема ПМа, работа с клиентаом — это проблема — сейлз-менеджера — они за это получают зарплату.
Если в фирме бардак, а это характерно для большенства фирм, то это уже проблемы менеджера по процессам и они волновать должны его, а не тебя...
Я вот вообще с места не сдвинусь — что бы занимтаься чужой работой.
Моя работа — писать софт, качественно и в срок (утвержденный со мной) — все остальное не моя забота, так зак за это я не имею денег.
Здравствуйте, ilya_ny, Вы писали:
_>Здравствуйте, Xenia, Вы писали: X>>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
_>принципиальные подробности... _>и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
... _>все что надо было сделать — после добавления новой страницы посмотреть как она работает
Очень часто бывает что при изменении кода, страничка, что работала раньше, перестает работать.
Пример: изменение code-behind для asp.net не всегда затрагивает страничку. Плюс, изменения бывают глобальными, и не всегда вспоминаешь, что и вот тут надо тоже протестировать.
Здравствуйте, mr_kern, Вы писали:
_>>Здравствуйте, Xenia, Вы писали: X>>>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
_>>принципиальные подробности... _>>и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
_>... _>>все что надо было сделать — после добавления новой страницы посмотреть как она работает
_>Очень часто бывает что при изменении кода, страничка, что работала раньше, перестает работать. _>Пример: изменение code-behind для asp.net не всегда затрагивает страничку. Плюс, изменения бывают глобальными, и не всегда вспоминаешь, что и вот тут надо тоже протестировать.
Баьенька, а на что существуют юнит- и веб-тесты? Как раз для этого.
Здравствуйте, olegkr, Вы писали:
O>Как я понял, основная ваша проблема в том, что нет development environment вообще. Контора может быть большой и как угодно забюрократизированной, но вся эта бюрократия должна касаться только production и соответственно deploy 2 production, где ей самое место. Очевидно, что релиз может легко занять один день и это нормально, но применять подобные policy для ежедневной работы — никому не нужный оверхед.
Может я чего-то не до конца понимаю, но в моем понимании hot fix в продуктивную систему напрямую касается production и, соответственно, deploy 2 production... не так ли?
Здравствуйте, olegkr, Вы писали:
O>Весь рабочий процесс разбивается на фазы: O>1. Development. Происходит в development environment. С ней можно делать все что угодно на усмотрение команды. Билди когда хочешь, деплой на свой сервак, конфиги правь. Полная свобода. Даже нередко демонстрашки юзерам показываются в этом env.
Как при этом согласовывать билды и деплои десятка различных команд, которые работают над разными аспектами одного и того же проекта? Держать десяток серверов для каждой команды? В таком случае, как потом синхронизировать билды и деплои (до production, еще на стадии development, когда для фикса команды номер 3 необходимо установить фиксы команд номер 1, 2 и 8... но об этом никто не догадывается, потому что никто за этим не следит, т.к. полная свобода)?
Здравствуйте, RandomGuid, Вы писали:
<skipped> RG>Не кажется ли вам, что винить нужно не "систему", не "дешёвого аналитика", а разработчика, который забыл поставить атрибут в коде?
Ошибки неизбежны.
[skip]
J>>>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу
LL>>Лично я "взрываюсь" на третьем-четвертом "переключении".
FDS>Я взрываюсь на втором. Однажды прямо на начальство наорал (правда, оно временное было)
Так предсказание надо использовать, и с возникновением таких ситуаций братся за более легкие задачи.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
[skip]
B>>Ага... B>>Значит будешь потом гонять аналитиков и разрабатывать подобные процессы? X>Чур меня
Да это восточная притча про дракона. (точность не гарантирю — copy-past)
Свирепый дракон повадился терроризировать одно царство. Тянул из народа все жилы, отнимал золото, лучших людей забирал в рабство. Раз один богатырь из угнетаемого царства пошел воевать с драконом, но не вернулся. Дракон сделался только еще злее и стал еще жестче притеснять бедный народ. Один за другим по очереди уходили на битву с драконом местные богатыри, но никто из них не возвращался, только дракон становился все свирепей и алчней. Один такой богатырь, в свою очередь вышедший против ящера, дошел до драконьей пещеры и обомлел от уведенного. Все поле вокруг пещеры было усыпано костями поверженных драконов, не было видно ни одного человеческого скелета. Все богатыри, на самом деле, побеждали драконов, но, овладев их сокровищами и властью, незаметно для себя превращались в жадных и злобных ящеров, не желая делиться с соплеменниками трофеями, еще сильнее терзали своей алчностью народ. И нет якобы силы, чтобы противостоять искушению змиевым золотом, и потому дракон бессмертен.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, Олег К., Вы писали:
O>>В качестве абстрактного совета могу рассказать, как было дело организованно у нас в одной немаленькой конторке. ОК>Если не секрет, в какой стране находится "немаленькая конторка?"
Ээээ... USA, Germany, UK, Singapore, Japan... Ну и филиал с отделом разработки в России.
Здравствуйте, Александр Каширин, Вы писали:
АК>Может я чего-то не до конца понимаю, но в моем понимании hot fix в продуктивную систему напрямую касается production и, соответственно, deploy 2 production... не так ли?
Кто же делает сразу хотфикс в production? Выпускается баг-фикс релиз со всеми причиндалами, типа тестирования. Ради одного багфикса никто релизиться не будет.
Здравствуйте, Александр Каширин, Вы писали:
АК>Как при этом согласовывать билды и деплои десятка различных команд, которые работают над разными аспектами одного и того же проекта?
Зависит исключительно от конкретной ситуации. Но я бы сделал так — у каждой команды есть свой development сервер на котором она работает. Как только получилось что-то законченное — тут же делается merge на общий development сервер. Т.е. он содержит последние версии всех завершенных фиксов и фич. Смысл в том, что бы не тянуть с интеграцией до последнего момента, сделали фикс — тут же кидайте на общий сервер.
Потом на этом сервере проводиться QA, и затем он деплоиться в UAT и Production.
Здравствуйте, mr_kern, Вы писали:
RG>>Баьенька, а на что существуют юнит- и веб-тесты? Как раз для этого.
_>Дяденька, не бейте меня сильно
_>А что, у вас к каждой страничке и каждому методу юнит и веб тесты прикручены? Простите, неверю!
Еще не к каждой Но это только вопрос времени. А течении полугода наверное закроем почти всю логику и контролы тестами.
Здравствуйте, mr_kern, Вы писали:
_>А что, у вас к каждой страничке и каждому методу юнит и веб тесты прикручены? Простите, неверю!
Как минимум, каждый имеющий значение аспект функционала должен быть покрыт тестами. Если нет ни юнит-тестов, ни живых тестеров — вот это и есть главная причина бардака.
А обкладывать тестами каждый метод — это конечно лишнее.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Александр Каширин, Вы писали:
АК>>Как при этом согласовывать билды и деплои десятка различных команд, которые работают над разными аспектами одного и того же проекта? O>Зависит исключительно от конкретной ситуации. Но я бы сделал так — у каждой команды есть свой development сервер на котором она работает. Как только получилось что-то законченное — тут же делается merge на общий development сервер. Т.е. он содержит последние версии всех завершенных фиксов и фич. Смысл в том, что бы не тянуть с интеграцией до последнего момента, сделали фикс — тут же кидайте на общий сервер.
О! Вот в этот момент (merge) и появляется весь тот "процесс", который так не нравится автору корневого сообщения... не так ли?
Здравствуйте, Александр Каширин, Вы писали:
АК>О! Вот в этот момент (merge) и появляется весь тот "процесс", который так не нравится автору корневого сообщения... не так ли?
Нет, т.к. merge происходит в development environment. Тот процесс появляется в момент деплоя uat->production, возможно, что так же в момент production (общий)->uat
Здравствуйте, Xenia, Вы писали: X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Хм... У нас организация в которой я работаю, как основная работа (т.е. 1-я) насчитывает более 20.000 человек.
Так вот, такого как у вас... нет!
У нас один человек за все тимы, которые вы перечислели. Капиталисты (С) Красная жара
Так что...
Здравствуйте, Shmakov, Вы писали:
S>А с каких пор тебя интересуют проблемы бизнеса и поставки клиентам? S>Ты кто — программист или сейлз-менеджер или ПМ? — ты за это получаешь деньги?
S>Вот меня совершенно не волнует кому и что поставляется и в какие сроки... Это не моя работа и мне за ней денег не платят... Сроки — это проблема ПМа, работа с клиентаом — это проблема — сейлз-менеджера — они за это получают зарплату.
S>Если в фирме бардак, а это характерно для большенства фирм, то это уже проблемы менеджера по процессам и они волновать должны его, а не тебя...
S>Я вот вообще с места не сдвинусь — что бы занимтаься чужой работой. S>Моя работа — писать софт, качественно и в срок (утвержденный со мной) — все остальное не моя забота, так зак за это я не имею денег.
Меня угнетает то как ,бездарно расходуется мое время и энергия
Здравствуйте, ilya_ny, Вы писали:
_>Здравствуйте, Xenia, Вы писали:
X>>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
_>принципиальные подробности... _>и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
Ну вобщем коммент действительно мимо кассы. Есть business model, набор классов отражающий структуру данных. Есть странички. Один и тот же класс из business model используется на сотнях страниц. У нас очень большое приложение, очень. Юнит тесты естественно были, но они не поймали отсутствие атрибута. А делать регрессивное тестирование приложения после изменения одного класса — ни коим образом не входит в обязанности девелоперов. Это обязанность тестеров, а в случае их отстутсивия — бизнес-аналитиков.
_>--- _>а зачем iisreset нужно было делать ?
Именно за тем что изменения не на самой странице, и не в код-бехайнде а в business layer.
X>>>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
_>>принципиальные подробности... _>>и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
X>Ну вобщем коммент действительно мимо кассы.
коммент о том кто когда и за сколько нанят и соображает этот человек или нет явно не в кассу.
X>Есть business model, набор классов отражающий структуру данных. Есть странички. Один и тот же класс из business model используется на сотнях страниц. У нас очень большое приложение, очень. Юнит тесты естественно были, но они не поймали отсутствие атрибута. А делать регрессивное тестирование приложения после изменения одного класса — ни коим образом не входит в обязанности девелоперов. Это обязанность тестеров, а в случае их отстутсивия — бизнес-аналитиков.
ну так тем более.
если добавить класс, который "на сотнях страниц" (!) (я-то в начале понял что на одной единственной) и его не протестировать — так это еще хуже и тестеры с аналитиками тут не причем.
_>>--- _>>а зачем iisreset нужно было делать ? X>Именно за тем что изменения не на самой странице, и не в код-бехайнде а в business layer.
что у вас называется "business layer" и зачем iisreset делать?
"business layer" хранится в GAC ?
Здравствуйте, ilya_ny, Вы писали:
_>Здравствуйте, Xenia, Вы писали:
X>>Ну вобщем коммент действительно мимо кассы. _>коммент о том кто когда и за сколько нанят и соображает этот человек или нет явно не в кассу.
Вовсе даже и нет.. если политика компании — нанимать толпу молодых и дешевых, которых пол-года учат, а потом они сообразив что к чему тут же увольняются, и на моей памяти ихний тим 100% обновился несколько раз — то уже просто тянет говорить об этом
_>если добавить класс, который "на сотнях страниц" (!) (я-то в начале понял что на одной единственной) и его не протестировать — так это еще хуже и тестеры с аналитиками тут не причем.
_Класс_ сам по себе был протестирован и работал. То есть — данные из базы читались, бизнес методы работали как ожидалось и данные в базу сохранялись. Отсутствие атрибута serializable() на юнит тестах не поймалось.
_>>>--- _>>>а зачем iisreset нужно было делать ? X>>Именно за тем что изменения не на самой странице, и не в код-бехайнде а в business layer. _>что у вас называется "business layer" и зачем iisreset делать? _>"business layer" хранится в GAC ?
Здравствуйте, Xenia, Вы писали:
X>>>Ну вобщем коммент действительно мимо кассы. _>>коммент о том кто когда и за сколько нанят и соображает этот человек или нет явно не в кассу.
X>Вовсе даже и нет.. если политика компании — нанимать толпу молодых и дешевых, которых пол-года учат, а потом они сообразив что к чему тут же увольняются, и на моей памяти ихний тим 100% обновился несколько раз — то уже просто тянет говорить об этом
я тоже так и понял что "просто потянуло поговорить про это".
думаю, что у компании такая политика — т.к это ей выгодно, а иначе бы такого не было
может выгодно иметь аналитиков по 40к, чем аналитиков по 160к
_>>если добавить класс, который "на сотнях страниц" (!) (я-то в начале понял что на одной единственной) и его не протестировать — так это еще хуже и тестеры с аналитиками тут не причем. X>_Класс_ сам по себе был протестирован и работал. То есть — данные из базы читались, бизнес методы работали как ожидалось и данные в базу сохранялись. Отсутствие атрибута serializable() на юнит тестах не поймалось.
естественно я не знаю всех деталей
я просто исхожу из здравого смысла — если вы сделали изменение которое затрагивает сотни страниц и не удосужились посмотреть как работает хотя бы одна их них — это не очень профессионально
ну и тесты, которые не поймали что у класса нету важного аттрибута — это тоже вина тех кто писал тесты, а не тупых и дешевых выпускников
мне именно этот снобизм и не понравился в сообщении.
вины разработчиков которые мало тестируют и при этом знают как сложно сделать релиз ("...и вот так — если не каждый день, то через день.") тут больше чем всех остальных
_>естественно я не знаю всех деталей _>я просто исхожу из здравого смысла — если вы сделали изменение которое затрагивает сотни страниц и не удосужились посмотреть как работает хотя бы одна их них — это не очень профессионально
Может они и смотрели на какой нибудь — не знаю. На этой значит не посмотрели
_>ну и тесты, которые не поймали что у класса нету важного аттрибута — это тоже вина тех кто писал тесты, а не тупых и дешевых выпускников
Никакой это не важный атрибут. На функциональность самого класса, в отрыве от использования на web pages этот аттрибут вообще не влияет, поэтому на такие вещи юнит-тесты не рассчитаны. Я не знаю для чего конкретно менялся этот класс, но вполне может быть что девелопер который это делал вообще не имел ввиду web-pages а работал над каким нибудь безинтерфейсным фидом или еще чем то таким.. И еще раз повторю — делать regression testing это НЕ обязанность девелоперов. Если аналитик знает, что завтра у него демо с клиентом — то это его святая обязанность убедиться что то что он собирается показывать — работает. Потому что девелоперы естественно делают ошибки, тем более идет середина development цикла и release is not even close — половина всего в незаконченном состоянии.
_>мне именно этот снобизм и не понравился в сообщении. _>вины разработчиков которые мало тестируют и при этом знают как сложно сделать релиз ("...и вот так — если не каждый день, то через день.") тут больше чем всех остальных
_>а так — все ок.
Снобизм? Да какой еще снобизм в отношении этих детей которых аналитиками садят может быть. К ним вопросов нет — как только они соображают куда они попали они тут же сваливают, как я уже говорила текучка 100%. А вот к менеджменту который порождает такую стратегию и структуру — да, есть уже серьезная неприязнь, скажем так. Очень скоро от них разбегутся не только аналитики но и девелоперы. За прошлый год ушло 2, в этом году — еще один, один порывался — перебили предложение по зарплате. В следующем году уйдет как минимум один
_>>а так — все ок. X>Снобизм? Да какой еще снобизм в отношении этих детей которых аналитиками садят может быть. К ним вопросов нет — как только они соображают куда они попали они тут же сваливают, как я уже говорила текучка 100%. А вот к менеджменту который порождает такую стратегию и структуру — да, есть уже серьезная неприязнь, скажем так. Очень скоро от них разбегутся не только аналитики но и девелоперы. За прошлый год ушло 2, в этом году — еще один, один порывался — перебили предложение по зарплате. В следующем году уйдет как минимум один
В Америке вообще жопа... Я слышал там одного парня в Нью-Йорке замочили .. это правда ?
Здравствуйте, Kubyshev Andrey, Вы писали:
_>>>а так — все ок. X>>Снобизм? Да какой еще снобизм в отношении этих детей которых аналитиками садят может быть. К ним вопросов нет — как только они соображают куда они попали они тут же сваливают, как я уже говорила текучка 100%. А вот к менеджменту который порождает такую стратегию и структуру — да, есть уже серьезная неприязнь, скажем так. Очень скоро от них разбегутся не только аналитики но и девелоперы. За прошлый год ушло 2, в этом году — еще один, один порывался — перебили предложение по зарплате. В следующем году уйдет как минимум один
KA>В Америке вообще жопа... Я слышал там одного парня в Нью-Йорке замочили .. это правда ?
Да, да! Еще я видел там терминаторы ходють средь бела дня в чем мама ро... ,т е. конвейер произвел. Робокопы всякие и прочая прочая... Ужас, короче.
Здравствуйте, jhfrek, Вы писали:
J>Здравствуйте, Xenia, Вы писали:
X>>Получается что отвлекся — вернулся к работе, пока вспоминал на чем остановился — уже опять надо отвлекаться.
J>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу
Блин, я наоборот в последнее время просто не могу заниматься чем-то одним. Привык уже переключаться: иногда делаю что-то одно, и ловлю себя на постоянном и периодическом желании перекинуться на что-то еще.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали: J>>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу E__>Блин, я наоборот в последнее время просто не могу заниматься чем-то одним. Привык уже переключаться: иногда делаю что-то одно, и ловлю себя на постоянном и периодическом желании перекинуться на что-то еще.
Если период переключений — дней десять, то согласен.
Если переключаться приходится по пять раз в день — это сильно мешает.
Как же меня все это за-дол-ба-ло
Далее — примерная хронология событий.
Если нам не помогут, то мы тоже никого не пощадим.
Тот, кто желает, но не делает, распространяет чуму.
для иллюстрации моего текста
