Я пробовал добавить в резюме в качестве требований к вакансии комплект практик гибкой разработки. Полторы тысячи просмотров работодателями, около сотни собеседований, результат нулевой. Даже TDD в классическом смысле никто из пригласивших меня на интервью не практикует, не говоря уже о парном программировании. Я сделал вывод что компаний, практикующих XP, у нас нет.
Спасибо за подробное описание, однако я ориентировался на исходный смысл латинского термина культура (возделывание, воспитание, развитие). И именно в его контексте интересно было бы понять почему вы отказались от той или иной практики.
В случаях, когда исходно "уровень качества просто не требуется" и повторное использование кодовой базы в принципе не подразумевается, я полагаю о культуре можно и не заморачиваться вовсе.
Да, я пожалуй что уверен что все, что предполагает экстремальное программирование (Agile), нужно практиковать одновременно, потому что все это как нельзя лучше соответствует семантике слова культура.
А вы как считаете? Что бы вы лично выкинули? И если вас не затруднит, то почему?
Практики, нацеленные на создание производственной культуры, позволяющей создавать программные продукты в понятные сроки и с гарантированным качеством мне кажется давно описаны старожилами отрасли, такими как Кент Бек, Роберт Мартин, Мартин Фаулер и другими.
Если команда проникнется Agile манифестом и начнет ориентироваться на повторное использование кода, будет всегда сначала писать тесты и настроит автоматическую непрерывную интеграцию и поставку, то рано или поздно будет команде счастье и культура. Вопрос только надо ли это все собственнику софтверной компании, которой принадлежит эта команда?
В общем за 20 лет работы в отрасли я ни разу не встретил команду, которая бы все это практиковала. В такой команде я бы был готов поработать не то что волонтером, но даже доплатил бы за такую возможность.
Просто "эффективный менеджмент" сейчас очень модная, трендовая тема. Многие поверили что скрам-канбан и стендапы-ретро способны мгновенно и в разы увеличить производительность работников умственного труда. Через некоторое время это пройдет… все проходит...
Обалдеть! Вы все еще здесь саблями машете!? Давайте хотя бы не на словах воевать, а код писать? Возможно в момент, когда кодовая база у нас перерастет порог в 10 тысяч строк, мы приблизимся к просветлению.
А мне теперь только такой способ мышления и кажется естественным. У меня пару раз были ситуации, когда просили за вполне неплохие деньги писать сначала код, а потом возможно тесты. Я не смог. Примерно на третий день начинается ломка, а к концу недели ступор. Больше я на такое не подписываюсь.
Парное программирование это очень прикольно. У меня уже три года не было парного программирования. :-)
Вам жалко потратить три часа на работу с человеком, с которым вы потом планируете проводить вместе 40 часов в неделю, 160 часов в месяц и почти 2000 часов в год?
Неужели в проекте нет задач, для решения которых не потребуется разбор архитектуры, инфраструктуры и отрыв руководителя проекта?
И правильно, любой заинтересованный кандидат будет тупить в процессе, и делать что-то не так, как вы привыкли делать, а ваша задача при этом прислушиваться к вашим ощущениям, и если они эмоционально сообщают вам что кандидат вам не нравится, то можете смело с ним прощаться. А если вы таки сомневаетесь, договаривайтесь о еще одной такой рабочей сессии и пробуйте еще раз.
При любом раскладе, рабочий подход, с программированием и геморроем в виде объяснения кандидату проекта, архитектуры и инструментария, единственный подход, который показывает честные результаты. Потому что вы видите что человек делает, а не слушаете что он вам про себя рассказывает.
Нил Рэкхем достаточно давно публиковал результаты исследований, которые как раз подтверждали что то, что рассказывают о своей деятельности люди, в весьма значительной степени отличается от самих практик, используемых им в той самой деятельности. И это не желание ввести собеседника в заблуждение или обмануть, это особенность работы мозга. :-)
Как находить правильных людей? На мой взгляд ничего сложного нет. В принятии решения о приеме на работу я обычно опираюсь всего на две абсолютно ненаучные и на первый взгляд не очень рациональные вещи:
Нравится мне человек или нет?
Нравится ли мне то, что он делает или нет?
С кандидатом в программисты не надо разговаривать, с ним надо программировать. Берите любую актуальную задачку из проекта и программируйте с ним за одной клавиатурой. Если вам нравится как человек работает, комфортно с ним код писать и искать решения проблемы, значит есть шанс что это реальный кандидат. А если не нравится, то зачем мучить себя?
То есть вы полагаете что можно 25 лет заниматься программированием, достигнув в этом некоторых профессиональных высот (научившись по меньшей мере на отлично выполнять тестовые задания) и при этом не любить свою работу? 25 лет? Без последствий? Не любить, колоться, плакать и продолжать?
Соответственно вопрос: Как должен профессионал с солидным стажем работы, продемонстрировать менеджеру по персоналу любовь к своей сфере деятельности чтобы менеджер по персоналу заметил эту любовь?
А я вас как раз json-ом не ограничиваю. Json встречается в "запускателе" тестов. Сами тесты в отдельном классе, который в принципе понятия не имеет о том, чего ему могут "скормить" в качестве затравки. Хотите разбирать XML объявляйте новый "запускатель" тестового набора.
[TestClass]
public class DefaultXmlFormatterTest
{
private Command formatterTestSuit;
[TestInitialize]
public void setUp()
{
string text = "<person><FirstName>"Jack"</FirstName><LastName>"Sparrow"</LastName></person>";
Person model =
new Person{
FirstName = "Jack",
LastName = "Sparrow"
};
FormatterSampleData<Person> sampleData =
new FormatterSampleData<Person>{
Text = text,
Model = model
};
Formatter<Person> formatter = new DefaultXmlFormatter<Person>();
this.formatterTestSuit =
new FormatterTestSuit<Person>(formatter, sampleData);
}
[TestMethod]
public void Execute()
{
this.formatterTestSuit.Execute();
}
}
Где вы увидели ограничение форматов в виде "только лишь с json"?
B что в данном случае выглядит сложно? Особенно если избавиться от комментариев, которые я никогда не пишу, и в данном случае привел только для того, чтобы показать примерный ход моих размышлений в момент кодирования.
:-) А мне ситуация видится с точностью до наоборот. Когда у меня был "стартап", мне нужны были как раз люди, умеющие хорошо обращаться с "молотком". Способные забивать гвозди много и качественно. Потому что количество денег у меня было ограниченное, и надо было заниматься не расширением кругозоров, а как можно скорее выходить на рынок и начинать продавать собранный на гвоздях продукт и зарабатывать деньги, пока они не кончились.
А вот до того, как уйти в свободное плаванье, я работал в среднего размера региональной компании. Компания была немолодая, бизнес прибыльный, и деньги водились. Вот тогда я (и другие руководители) иногда нанимал людей, которые не вполне соответствовали требованиям вакансии, но зато отсвечивали некоей перспективой, в некоей области. Большинство из них приходилось потом увольнять конечно, а некоторые "выстреливали", организуя пусть хоть и не новые виды деятельности, но прибыльные выходы на новые сегменты рынков к примеру.
Бесполезный спор на тему "кому, что кажется правильным". Это не теорема, доказательств нет ни у одной из сторон. Каждый участник подразумевает разные исходные и разные результаты.
Если ты не стремишься к чистоте, красоте, понятности, легкочитаемости и лаконичности исходного кода, то тесты тебе не нужны в принципе. Если твоя задача написать как можно больше кода, то тебе тоже тесты не нужны в принципе. Если ты можешь позволить себе не иметь исчерпывающего набора автоматических инструментов контроля качества кода и готов полагаться на живых тестировщиков, то тебе тесты тоже не нужны. Если ты можешь позволить себе текучку кадров и постоянную ротацию исполнителей в проектах, то развитие навыков написания тестовых сценариев тоже не нужны. Если ты можешь позволить себе каждый следующий проект начинать как с чистого листа, то тебе тесты тоже не нужны.
Если отвлечься от околонаучной риторики, то все нанимают сотрудников, похожих на себя и тех, которые уже работают в компании. Мне доводилось видеть отделы, где сотрудники даже внешне были похожи на руководителя. Мой опыт свидетельствует, что непохожий кандидат, будь он даже семи пядей во лбу с 98% вероятностью будет отвергнут среднестатистическим нанимателем. Никто, из виденных мной руководителей среднего звена, не собирался "выходить из зоны комфорта", чтобы там не писали и не рекомендовали Кови, Питерсы и местного разлива бизнес-тренеры.
"Чужак" может попасть в команду только через собственника, если оный еще занимается управлением, а не сбежал в Италию пить кьянти и ходить на яхте под парусом. Только заинтересованный в развитии бизнеса любыми способами собственник может позволить себе кадровые эксперименты. Это тоже мой личный опыт.
Так оно собственно и происходит. В реальности, никого из нанимателей не интересует "широта взглядов" и "богатство опыта" кандидата, если оные не имеют отношения к собственно программированию и обсуждаемой конкретной вакансии. Никто в первом приближении не ждет от человека никакого роста и движения вперед, не относящегося к конкретно написанию кода.
Я пробовал добавить в резюме в качестве требований к вакансии комплект практик гибкой разработки. Полторы тысячи просмотров работодателями, около сотни собеседований, результат нулевой. Даже TDD в классическом смысле никто из пригласивших меня на интервью не практикует, не говоря уже о парном программировании. Я сделал вывод что компаний, практикующих XP, у нас нет.
Спасибо за подробное описание, однако я ориентировался на исходный смысл латинского термина культура (возделывание, воспитание, развитие). И именно в его контексте интересно было бы понять почему вы отказались от той или иной практики.
В случаях, когда исходно "уровень качества просто не требуется" и повторное использование кодовой базы в принципе не подразумевается, я полагаю о культуре можно и не заморачиваться вовсе.
Да, я пожалуй что уверен что все, что предполагает экстремальное программирование (Agile), нужно практиковать одновременно, потому что все это как нельзя лучше соответствует семантике слова культура.
А вы как считаете? Что бы вы лично выкинули? И если вас не затруднит, то почему?
Практики, нацеленные на создание производственной культуры, позволяющей создавать программные продукты в понятные сроки и с гарантированным качеством мне кажется давно описаны старожилами отрасли, такими как Кент Бек, Роберт Мартин, Мартин Фаулер и другими.
Если команда проникнется Agile манифестом и начнет ориентироваться на повторное использование кода, будет всегда сначала писать тесты и настроит автоматическую непрерывную интеграцию и поставку, то рано или поздно будет команде счастье и культура. Вопрос только надо ли это все собственнику софтверной компании, которой принадлежит эта команда?
В общем за 20 лет работы в отрасли я ни разу не встретил команду, которая бы все это практиковала. В такой команде я бы был готов поработать не то что волонтером, но даже доплатил бы за такую возможность.
Просто "эффективный менеджмент" сейчас очень модная, трендовая тема. Многие поверили что скрам-канбан и стендапы-ретро способны мгновенно и в разы увеличить производительность работников умственного труда. Через некоторое время это пройдет… все проходит...
Обалдеть! Вы все еще здесь саблями машете!? Давайте хотя бы не на словах воевать, а код писать? Возможно в момент, когда кодовая база у нас перерастет порог в 10 тысяч строк, мы приблизимся к просветлению.
А как ваша команда оценивает какой код ты выдаешь? Каковы формальные критерии?
А мне теперь только такой способ мышления и кажется естественным. У меня пару раз были ситуации, когда просили за вполне неплохие деньги писать сначала код, а потом возможно тесты. Я не смог. Примерно на третий день начинается ломка, а к концу недели ступор. Больше я на такое не подписываюсь.
Парное программирование это очень прикольно. У меня уже три года не было парного программирования. :-)
Вам жалко потратить три часа на работу с человеком, с которым вы потом планируете проводить вместе 40 часов в неделю, 160 часов в месяц и почти 2000 часов в год?
Неужели в проекте нет задач, для решения которых не потребуется разбор архитектуры, инфраструктуры и отрыв руководителя проекта?
И правильно, любой заинтересованный кандидат будет тупить в процессе, и делать что-то не так, как вы привыкли делать, а ваша задача при этом прислушиваться к вашим ощущениям, и если они эмоционально сообщают вам что кандидат вам не нравится, то можете смело с ним прощаться. А если вы таки сомневаетесь, договаривайтесь о еще одной такой рабочей сессии и пробуйте еще раз.
При любом раскладе, рабочий подход, с программированием и геморроем в виде объяснения кандидату проекта, архитектуры и инструментария, единственный подход, который показывает честные результаты. Потому что вы видите что человек делает, а не слушаете что он вам про себя рассказывает.
Нил Рэкхем достаточно давно публиковал результаты исследований, которые как раз подтверждали что то, что рассказывают о своей деятельности люди, в весьма значительной степени отличается от самих практик, используемых им в той самой деятельности. И это не желание ввести собеседника в заблуждение или обмануть, это особенность работы мозга. :-)
Как находить правильных людей? На мой взгляд ничего сложного нет. В принятии решения о приеме на работу я обычно опираюсь всего на две абсолютно ненаучные и на первый взгляд не очень рациональные вещи:
С кандидатом в программисты не надо разговаривать, с ним надо программировать. Берите любую актуальную задачку из проекта и программируйте с ним за одной клавиатурой. Если вам нравится как человек работает, комфортно с ним код писать и искать решения проблемы, значит есть шанс что это реальный кандидат. А если не нравится, то зачем мучить себя?
:-) Не буду с вами спорить.
То есть вы полагаете что можно 25 лет заниматься программированием, достигнув в этом некоторых профессиональных высот (научившись по меньшей мере на отлично выполнять тестовые задания) и при этом не любить свою работу? 25 лет? Без последствий? Не любить, колоться, плакать и продолжать?
Соответственно вопрос: Как должен профессионал с солидным стажем работы, продемонстрировать менеджеру по персоналу любовь к своей сфере деятельности чтобы менеджер по персоналу заметил эту любовь?
И?
А я вас как раз json-ом не ограничиваю. Json встречается в "запускателе" тестов. Сами тесты в отдельном классе, который в принципе понятия не имеет о том, чего ему могут "скормить" в качестве затравки. Хотите разбирать XML объявляйте новый "запускатель" тестового набора.
Где вы увидели ограничение форматов в виде "только лишь с json"?
B что в данном случае выглядит сложно? Особенно если избавиться от комментариев, которые я никогда не пишу, и в данном случае привел только для того, чтобы показать примерный ход моих размышлений в момент кодирования.
:-) А мне ситуация видится с точностью до наоборот. Когда у меня был "стартап", мне нужны были как раз люди, умеющие хорошо обращаться с "молотком". Способные забивать гвозди много и качественно. Потому что количество денег у меня было ограниченное, и надо было заниматься не расширением кругозоров, а как можно скорее выходить на рынок и начинать продавать собранный на гвоздях продукт и зарабатывать деньги, пока они не кончились.
А вот до того, как уйти в свободное плаванье, я работал в среднего размера региональной компании. Компания была немолодая, бизнес прибыльный, и деньги водились. Вот тогда я (и другие руководители) иногда нанимал людей, которые не вполне соответствовали требованиям вакансии, но зато отсвечивали некоей перспективой, в некоей области. Большинство из них приходилось потом увольнять конечно, а некоторые "выстреливали", организуя пусть хоть и не новые виды деятельности, но прибыльные выходы на новые сегменты рынков к примеру.
Бесполезный спор на тему "кому, что кажется правильным". Это не теорема, доказательств нет ни у одной из сторон. Каждый участник подразумевает разные исходные и разные результаты.
Если ты не стремишься к чистоте, красоте, понятности, легкочитаемости и лаконичности исходного кода, то тесты тебе не нужны в принципе. Если твоя задача написать как можно больше кода, то тебе тоже тесты не нужны в принципе. Если ты можешь позволить себе не иметь исчерпывающего набора автоматических инструментов контроля качества кода и готов полагаться на живых тестировщиков, то тебе тесты тоже не нужны. Если ты можешь позволить себе текучку кадров и постоянную ротацию исполнителей в проектах, то развитие навыков написания тестовых сценариев тоже не нужны. Если ты можешь позволить себе каждый следующий проект начинать как с чистого листа, то тебе тесты тоже не нужны.
В "решение о рефакторинге без добавления новой функциональности"...
Если отвлечься от околонаучной риторики, то все нанимают сотрудников, похожих на себя и тех, которые уже работают в компании. Мне доводилось видеть отделы, где сотрудники даже внешне были похожи на руководителя. Мой опыт свидетельствует, что непохожий кандидат, будь он даже семи пядей во лбу с 98% вероятностью будет отвергнут среднестатистическим нанимателем. Никто, из виденных мной руководителей среднего звена, не собирался "выходить из зоны комфорта", чтобы там не писали и не рекомендовали Кови, Питерсы и местного разлива бизнес-тренеры.
"Чужак" может попасть в команду только через собственника, если оный еще занимается управлением, а не сбежал в Италию пить кьянти и ходить на яхте под парусом. Только заинтересованный в развитии бизнеса любыми способами собственник может позволить себе кадровые эксперименты. Это тоже мой личный опыт.
Так оно собственно и происходит. В реальности, никого из нанимателей не интересует "широта взглядов" и "богатство опыта" кандидата, если оные не имеют отношения к собственно программированию и обсуждаемой конкретной вакансии. Никто в первом приближении не ждет от человека никакого роста и движения вперед, не относящегося к конкретно написанию кода.