HR никогда не сможет определить не только профессиональный уровень инженера, но и его пригодность для командной работы, пригодность для работы с данной группой и т.п. Просто потому что он не собеседник для инженера, он «чужой».
я бы не согласился с частью «но и его пригодность для командной работы». В большинстве случаев HR может вполне адекватно оценить вольется или нет новый человек в команду. Конечно сразу отсеивать кандидата по этому признаку HR-у не стоит, но свои рекомендации он дать может, т.к. проводя техническое собеседование, на отвлеченные темы с кандидатом обычно не разговариваешь.
Согласен, там много о себе как о разработчике или менеджере не напишешь. Я просто пример привел. Мне написали, потому что я там указал в виде ключевых слов технологии и кинул ссылку на проект. Лучше всего регистрироваться на linkedIn конечно.
Так хочется не согласиться по поводу того, что «не станете лучше руководить проектами». Уверен есть и обратные примеры. Скорее всего все зависит от возможностей проекта и руководства, если проект гибкий и руководство приветствует и понимает все нововведения, то мне кажется, что полученный от прохождения PMP опыт можно удачно прменить.
недавно прочитал, что менеджер отличается от начальника тем, что занимается управлением, а начальник уверен в том, что управление персоналом сводится к его физическому присутствию на рабочем месте и грубой форме общения с подчиненными.
начальники не умеют (или не хотят) заниматься своими должностными обязанностями по управлению персоналом и пытаются реализовать странную (с точки зрения менеджмента) идею:
Отсутствие системы управления персоналом(свою лень или некомпетентность) компенсировать поиском инициативных сотрудников и системой мотивации (стимулирования) персонала.
Наш переход происходил в несколько этапов. Сначала мы добавили ведение спецификаций. Спецификации приживались у нас месяца 2, потом это вошло в норму. Далее мы начали играться с длиной релизов, выпускали сначала два раза в неделю, раз в неделю, раз в две недели, раз в месяц, раз в два месяца, раз в три месяца… Определили, что раз в 3-4 недели таки оптимальный вариант, где все довольны: клиент с релизом без ошибок, команда в конце релиза бодрячком. Ввели standup митинги два раза в неделю. Потом ввели Product Backlog поигрались с важностью и Story Points… и… убрали их через два релиза. Потом добавили ретроспективу, которая стала проводиться раза два в неделю с фразами «А давайте ка сделаем/улучшим/поменяем/добавим… ». В общем можно сказать, что уложились мы где-то в пол года, когда уже наигрались с длинами спринта. И это был наш первый опыт перехода на Agile. Для перехода мне хватило прочитать эту книгу
Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.
и сходить на парочку конференций, чтобы задать вопросы.
вот про спеку не соглашусь. сколько уже было ситуаций типа "… а помните год назад я заказывал..." или "… я не то совсем имел ввиду, вы сделали не правильно.." И докажи потом, что ты прав. Иногда спасают письма в таких ситуациях, если, конечно, их никто не поудалял. Но лучше всего после обсуждения какой-то функциональности нарисовать пару скринов, хотябы в том же Paint, оформить в презентацию с комментариями и еще раз зааппрувить, а потом выложить на треккер, чтоб не потерялось. Спека — идеальный вариант вообще будет.
И то что не панацея, соглашусь, наверное, но все зависит от специфики проектов. Могу сказать только, что год назад без пары пунктов из теста Джоэла было все таки сложновато. И сидели в разных местах, например, и работали в openspace, где шумно было, и спек небыло и тестеров, и т.д… Пока пришел к выводу, что чем больше пунктов из этого теста есть, тем лучше. Хотя вот есть команды которые работают, например без тестеров вообще, можно послушать Николая Алименкова, например, он рассказывает про один такой случай, и вроде все у них в порядке.
человек спросил о методологии, думаю, чем больше он почитает о скраме, хр, 12-и шагах, тем проще ему будет к чему-то прийти.
Ну треккер все по-разному ведут, и комментарии не все заполняют при коммите — это уже у кого какие правила устоялись при разработке. А с таким подходом сразу все видно. И в режиме нехватки времени удобнее будет на компактную таблицу посмотреть (но это мое мнение, каждый делает как ему удобно). Тут удобвство как раз в лаконичности, а не в автоматизме.
product-owner это у нас Project Manager. Документ просматривается всеми, т.к. нужно учитывать и время на изменение и время на тестирование, но Project Manager вносит здравый смысл в приоритетность функционала, т.к. тестерам в основном все важно, трясутся над каждой вкладкой, а программисты за частую не могут оценить приоритет функционала, т.к. отвечают не за весь проект, а за отдельные его части. Но изменения приоритетов производятся не часто, т.к. мы уже знаем, что для клиентов нужно в первую очередь. Если изменения в приоритете все же нужно сделать, то это правится непосредственно в таблице импакт анализа. Кстати, лучше продумать сразу все возможные приоритеты и стараться сильно не усложнять. Чтоб потом не пришлось вводить новый приоритет и из-за этого делать изменения по всей таблице импакт анализа. Нам с головой хватает 3-х, видел примеры максимум с 5-ю приоритетами.
Так не от разработчика зависит, а от заказчика. Разработчик может быть и «человек-оркестр», а играть должен все равно по правилам заказчика. Заказчику в основном нужны релизы и как можно чаще, и чтоб по-больше новой функциональности было. Выбирая методологию разработки нужно смотреть на то, как вы работаете с заказчиком, если он любит, чтоб все сначала было спланированно, взвешенно, диаграмма нарисована, дизайн продуман, а потом только к коду приступать, то тут лучше водопадную модель использовать. Если заказчику все равно, то я бы за основу взял Scrum, т.к. здесь вы себя страхуете практически со всех сторон. Вы часто выпускаете релизы, заказчик может посмотреть на функциональность и внести изменения, когда еще не так много спроектированно и есть возможность легко что-то поменять. Плюс вы можете, на основании нескольких релизов, просчитать среднюю производительность команды и более точно спланировать следующий релиз. Еще у вас в Product backlog будет куча заданий с приоритетами и со Story Points, так что сможете распланировать на несколько релизов вперед.
Например, в нашем проекте, я не могу сказать, что использую Scrum, т.к. половина из него не прижилась, но за основу мы взяли Product BackLog, и внутренние релизы мы планируем сроком на 1-4 недели, заказчик же получает релиз раз в 2-3 месяца. Т.е. у нас получается такое понятие как спринт в спринте. Пробуйте из разных методологий выбрать то, что подходит для вашего проекта. Ведь все еще зависит от количества человек в команде, соотношения тестеров и программистов, сложности задач и др. факторов.
Если будет 10 или 9, то это уже хорошо. у нас на проекте год назад было 5, сейчас 10, собираемся поднять планку еще выше. Если у вас появятся тестировщики, то это уже +2 пунка, они без БД ошибок не работают, ну а все остальное — дело наживное.
есть примеры команд, их не много, но есть, в которых нет тестировщиков. В таких командах все покрывается TDD, BDD, ATDD, DDD и всякими другими ...DD (и придумали же)
Не стоит выдерживать все практики в скраме, если не получается, значит откажитесь от какой-то из практик. Есть еще понятие ScrumBat(или СкармНо по нашему). Это когда вы говорите, мы используем скрам, но не используем…, потому что… Можно почитать здесь scrumbat
Покажите заказчику Тест Джоэла: 12 шагов к лучшему коду может он проникнется и попытается создать вам все условия. Если заказчик заинтересован в улучшении процесса разработки, то шагов 10 (а может и 11) он вам постарается сделать, это не дорого и не очень сложно.
Про импакт анализ собирался подготовить статью, т.к. не все с ним знакомы. Я и сам узнал о нем недавно, можно сказать, что он у нас в «сыром» виде еще, но определенно работает, и смысл есть.
Спасибо за столь длинный комментарий, статью написал, чтобы отзывы послушать. так что какие уж тут обиды? а вот по поводу знакомства… что-то не припоминаю я…
Согласен, что не надо цепляться за одну методологию. Когда команда работать начинала, вообще методологии небыло, так что-то кто-то слышал — применили… Очень помогли конференции, на которых можно пообщаться со знающими людьми, позадавать вопросы. Стараюсь приветствовать любые полезные нововведения от всех членов команды, ведь один я не могу охватить все новое, что всплывает в мире разработки ПО.
Львиная доля написанного очевидна даже для тех, кто не то, чтобы проектами не управлял, а вообще не тимлидил ни разу. Много воды и статья ни о чем
Может быть очевидна для тех, кто уже читал хоть что-то про методологии, согласен.
Какие-то круги-круги-круги
Извините, вспомнил универ, графики. Был вариант со списком под каждой из методологий, но он показался мне не красивым.
Мы файл с фичами периодически показываем заказчику. Также файл ведется в Excel и на дополнительных страницах я еще виду разбиение фич на подзадачи, + там же и импакт анализ делается на каждую фичу в спринте, а его в JIRA нормально не нарисуешь. Если б не импакт анализ, то в общем-то можно было все делать и в JIRA или поставить, например VersionOne — как раз для работы по Scrum предназначен. Но JIRA и VersionOne — вещи платные, а заказчику просто удобно смотреть все в Excel, а на треккер он вообще не заходит, ему это не интересно.
я бы не согласился с частью «но и его пригодность для командной работы». В большинстве случаев HR может вполне адекватно оценить вольется или нет новый человек в команду. Конечно сразу отсеивать кандидата по этому признаку HR-у не стоит, но свои рекомендации он дать может, т.к. проводя техническое собеседование, на отвлеченные темы с кандидатом обычно не разговариваешь.
начальники не умеют (или не хотят) заниматься своими должностными обязанностями по управлению персоналом и пытаются реализовать странную (с точки зрения менеджмента) идею:
Отсутствие системы управления персоналом(свою лень или некомпетентность) компенсировать поиском инициативных сотрудников и системой мотивации (стимулирования) персонала.
Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.
и сходить на парочку конференций, чтобы задать вопросы.
И то что не панацея, соглашусь, наверное, но все зависит от специфики проектов. Могу сказать только, что год назад без пары пунктов из теста Джоэла было все таки сложновато. И сидели в разных местах, например, и работали в openspace, где шумно было, и спек небыло и тестеров, и т.д… Пока пришел к выводу, что чем больше пунктов из этого теста есть, тем лучше. Хотя вот есть команды которые работают, например без тестеров вообще, можно послушать Николая Алименкова, например, он рассказывает про один такой случай, и вроде все у них в порядке.
человек спросил о методологии, думаю, чем больше он почитает о скраме, хр, 12-и шагах, тем проще ему будет к чему-то прийти.
Например, в нашем проекте, я не могу сказать, что использую Scrum, т.к. половина из него не прижилась, но за основу мы взяли Product BackLog, и внутренние релизы мы планируем сроком на 1-4 недели, заказчик же получает релиз раз в 2-3 месяца. Т.е. у нас получается такое понятие как спринт в спринте. Пробуйте из разных методологий выбрать то, что подходит для вашего проекта. Ведь все еще зависит от количества человек в команде, соотношения тестеров и программистов, сложности задач и др. факторов.
и придумали же)Не стоит выдерживать все практики в скраме, если не получается, значит откажитесь от какой-то из практик. Есть еще понятие ScrumBat(или СкармНо по нашему). Это когда вы говорите, мы используем скрам, но не используем…, потому что… Можно почитать здесь scrumbat
Покажите заказчику Тест Джоэла: 12 шагов к лучшему коду может он проникнется и попытается создать вам все условия. Если заказчик заинтересован в улучшении процесса разработки, то шагов 10 (а может и 11) он вам постарается сделать, это не дорого и не очень сложно.
1. Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.
2. Мартин Фаулер. Экстремальное программирование.
Согласен, что не надо цепляться за одну методологию. Когда команда работать начинала, вообще методологии небыло, так что-то кто-то слышал — применили… Очень помогли конференции, на которых можно пообщаться со знающими людьми, позадавать вопросы. Стараюсь приветствовать любые полезные нововведения от всех членов команды, ведь один я не могу охватить все новое, что всплывает в мире разработки ПО.
Может быть очевидна для тех, кто уже читал хоть что-то про методологии, согласен.
Извините, вспомнил универ, графики. Был вариант со списком под каждой из методологий, но он показался мне не красивым.