как начать карьеру в США?

[Zorkus]

АццкоМото

I don't always test my code, but when I do, I do it in production!

Вооо! Именно так. И 80*80 не помешало

Ну дык, у меня у коллеги-ПМ-а этот плакат на стене висит распечатанный крупно. Чтобы все, так сказать, знали, как идет процесс quality assurance..

[АццкоМото]

АццкоМото, верни обратно старую аватарку, а то мне теперь непроизвольно хочется к тебе на Вы и почтительным голосом обращаться.

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

[Сабина]

Да что ж ха фигня-то! Не знают на Привете классики. 5 лет объяснял всем - безвоздмезно! - что за чурекская морда Аджая Найду и где посмотреть Office Space, а тут уже и The Most Interesting Man In The World не тянет на какого-то мачо-мена
Просто "время течет" и "как бы ни хотелось, а никуда не деться", пора меняться. Как-то так: http://www.belobrovpopov.ru/postcards/06.htm

Так не было меня на Привете те пять лет, так что какие претензии ?
Меняться надо постепенно. Насколько я вас помню по пикнику вы еще на 4/5 - та "чурекская морда" и только на 1/5 этот седовласый уважаемый старец

[Сабина]

АццкоМото, верни обратно старую аватарку, а то мне теперь непроизвольно хочется к тебе на Вы и почтительным голосом обращаться.

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

Понятно. Будем привыкать значит за неимением ребрышек

[АццкоМото]

Насколько я вас помню по пикнику вы еще на 4/5 - та "чурекская морда" и только на 1/5 этот седовласый уважаемый старец

Подчеркивать-то нужно лучшее

[Интеррапт]

АццкоМото, верни обратно старую аватарку, а то мне теперь непроизвольно хочется к тебе на Вы и почтительным голосом обращаться.

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

Ну тебя я кроме ребер готов даже мясом с них угостить.

[АццкоМото]

Ну тебя я кроме ребер готов даже мясом с них угостить.

Прямо в Белом Доме???

[Интеррапт]

Ну тебя я кроме ребер готов даже мясом с них угостить.

Прямо в Белом Доме???

Ну так заманиваю ведь. А там сразу уже и засада - под белы ручки и домой.

[АццкоМото]

Ну тебя я кроме ребер готов даже мясом с них угостить.

Прямо в Белом Доме???

Ну так заманиваю ведь. А там сразу уже и засада - под белы ручки и домой.

Вот и по аватарке так. Глянешь - вроде демократ. Присмотришься - республиканец же.
ЗЫ. из белого дома под белы ручки домой - это пять

[Zorkus]

АццкоМото, верни обратно старую аватарку, а то мне теперь непроизвольно хочется к тебе на Вы и почтительным голосом обращаться.

В рамках флешбома (я знаю тут еще есть вроде любители флешмобов, присоединяйтесь!), предлагаю всем поставить такие аватарки, чтобы Интеррапт был почтителен ко всем нам

[Интеррапт]

Не-а, не нужно. Это приводит к путанице и в прошлом на форуме не приветствовалось дуплицирование аватарок участников.
Да я и так вроде почтителен

[Zorkus]

Ладно.

[Сабина]

Но скока нервов потрачено из-за этой фигни .

Статейку сегодня коллега переслала, ну прямо про нас написано

http://java.dzone.com/articles/build-monkey-antipattern

[mynameiszb]

Статейку сегодня коллега переслала, ну прямо про нас написано
http://java.dzone.com/articles/build-monkey-antipattern

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

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

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

[АццкоМото]

а) собран корректно, б) в срок, в) работал, а не добавлял новые багофичи, ... и еще куча разных букв.

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

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

[mynameiszb]

но валить все это на релиз-манагера мне не кажется правильным

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

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

[АццкоМото]

но валить все это на релиз-манагера мне не кажется правильным

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

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

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

[mynameiszb]

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

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

[АццкоМото]

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

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

High maturity processes с этим прекрасно справляются, никакого ремесленничества. Дорого только и долго. За то качественно и прогнозируемо

[mynameiszb]

High maturity processes с этим прекрасно справляются, никакого ремесленничества. Дорого только и долго. За то качественно и прогнозируемо

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

Придет тим-лид и мастер по базам данных, построит кадры и заявит, что лучший способ удалять информацию в таблицах - это "drop table / create table". И апгемахт...

[АццкоМото]

High maturity processes с этим прекрасно справляются, никакого ремесленничества. Дорого только и долго. За то качественно и прогнозируемо

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

Придет тим-лид и мастер по базам данных, построит кадры и заявит, что лучший способ удалять информацию в таблицах - это "drop table / create table". И апгемахт...

Скажите, а вы знаете что-либо о high-maturity processes? Грубо говоря, представьте армию. Вот там никого не интересует, что у Пупкина привычка поспать до обеда. Вот так и тут. Влияние конкретных людей в таких процессах минимально, результат - предсказуем. Минус - цена и минимум возможностей для творчества. Поэтому в мире нет ни одного фейсбука/твитыря/гугла и т.д. сделанных по SEI CMMI Level 5. И нет ни одного самолета/танка/спутника сделанного по аджайлу.
Что до конкретного примера, если в организации до сих пор удаляли информацию в таблицах как-то иначе, то никакой тим-лид не сможет построить народ и сказать "а с сегодняшнего дня мы будем делать по-другому". Любое техническое изменение пройдет через кучу инстанций, прежде, чем будет допущено хотя бы к пилотному проекту. А по окончании пилотки будет проанализировано

[mynameiszb]

Скажите, а вы знаете что-либо о high-maturity processes?

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

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

[АццкоМото]

Скажите, а вы знаете что-либо о high-maturity processes?

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

Да нет никакого "тонкого места". Человек, который решает, пропускать ли код, вообще не имеет никакого отношения к его "анализу на предмет ошибок" и выполняет достаточно четкую инструкцию. Например:
Убедиться, что все багрепорты, назначенные на релиз и с важностью >x в состоянии tested
Убедиться, что все инспекции кода закрыты
Убедиться, что test execution >99%
Убедиться, что test pass rate >95%
Убедиться, что пройден аудит
Убедиться, что нет pending changes in requirements or design assigned to this release
И еще 50 подобных однозначных пунктов. И квалификация человека тут вообще не важна.
А то, что вы нафантазировали про чела, который код пропускает, "проанализировав" его на предмет ошибок - жремучейший аджайл и никакого отношения к mature processes не имеет

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

Это я не могу распарсировать

[mynameiszb]

Да нет никакого "тонкого места". Человек, который решает, пропускать ли код, вообще не имеет никакого отношения к его "анализу на предмет ошибок" и выполняет достаточно четкую инструкцию. Например:
Убедиться, что все багрепорты, назначенные на релиз и с важностью >x в состоянии tested
Убедиться, что все инспекции кода закрыты
Убедиться, что test execution >99%
Убедиться, что test pass rate >95%
Убедиться, что пройден аудит
Убедиться, что нет pending changes in requirements or design assigned to this release
И еще 50 подобных однозначных пунктов. И квалификация человека тут вообще не важна.

Это - то, как видит менеджмент. Который в итоге выпускает продукт, построенный по принципу "по отчетности оно должно работать".

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

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

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

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

Это я не могу распарсировать

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

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

[АццкоМото]

А в реальной жизни

Еще раз. В реальной жизни вы не работали по mature processes. И вы считаете, что тот аджайловский бардак, который вас окружал всю жизнь, это единственно возможная реальность. Но это не так.
Если вам на самом деле интересно, как достигается уверенность, что "тестеры не покрыли что-то там спустя рукава" и так далее, я могу объяснить. Если же вы мне хотите доказать, что в SEI сидят дураки и любая разработка зависит от конкретных людей, то на этом можно закончить