Еще лучше спрашивать про гипотетические ситуации и сценарии у человека, тогда сразу можно оценить его критическое и аналитическое мышление, глубину и ширину шагов для решения ситуации
Я, как практик, не согласен. Если человек красиво говорит, это совсем не значит, что он способен это реализовать. Именно поэтому я и спрашиваю, что человек реально делал, а не что он мечтал делать, и "как бы он обустроил Россию".
Embedded - это программирование микроконтроллеров? Да, я там совсем не работал, не моя тема. Можете даже развернуть, когда и почему навык написания кода на листочке нужен и полезен, думаю всем будет интересно.
насколько быстро человек может читать чужой сложный код
Это задача код-ревью, чтобы её делать, нужно быть хоть немного в теме написанного сервиса. И на ревью на рабочем месте можно потратить полчаса-час, на собеседовании - не более 10 минут, причем в состоянии стресса.
быстро писать код
Серьезно? У вас там чемпионаты на скоростное кодирование чтоли проходят?:)))
компаниям нужны сотрудники, которые могут сориентироваться по заданному материалу и принести ценность в работе
И определить, могут ли кандидаты принести ценность, можно только в шестиступенчатом собеседовании, за один час этого сделать никак нельзя. Ну и что, что другие делают?:)))
Прикол в том, что ты не знаешь, на какую сумму тебе сделают предложение в условном Яндексе, а специально обученные люди на каждом этапе будут рассказывать, что они разработчиков не обижают, и кто-то по итогам собеседований получил предложение на 20% ВЫШЕ рынка, просто потому что очень хорош (так в Тинькофф рассказывают, можно посмотреть в их материалах для подготовки).
Не совсем согласен. Соответствие конечно же есть, но как только мы начинаем упоминать знакомые слова, типа "час, день, неделя", мозг начинает к этому привязываться, и вот были неопределенные 80 сторипоинтов, а стали вполне определенные 60 человеко-дней с иллюзией, что 30 человек сделают фичу за 2 дня. И да, это сложно объяснить заказчику, особенно когда он хочет тебя не понять и простить, а утопить.
быстро отходили от story point-ов в пользу оценки по дням
Это внутри команды, или при оценке нового проекта целиком?
waterfall
А как релизите? С заказчиком не бывает проблем, как раз в статье описанных, типа "я не это имел ввиду"? Корректировка требований как происходит? В этом же главная беда waterfall.
Вы просто не для того применяете сторипоинты, я в ответе на первый комментарий пояснил, для чего они нужны. При оценке задач, уже принятых командой к выполнению, они бесполезны.
Со сторипоинтами одна проблема - никто не понимает, зачем они нужны. Поясню.
Когда мы пытаемся оценить большой проект, мы разбиваем его на фичи и истории, и истории оцениваем примерно на основе уже проработанных историй (без всякой привязки к командам и людям). Принимаем примерную скорость команд (опять же на основе опыта), получаем количество итераций, то есть срок проекта. Тут и применяются сторипоинты.
При взятии историй в спринт сторипоинты нужны только для определения скорости команды, чтобы менеджеру понять, сколько примерно итераций осталось для проработки фичи. Внутри же команды при оценке спринта логично пользоваться днями и часами.
То есть сторипоинты - наружу, человеко-часы - внутрь команды. Двойная бухгалтерия, так сказать:)))
в итоге решение все равно принимает лид и архитектор
Для госструктур очень характерно (да, у них тоже есть IT). Команда хочет одно, приходит Большой Начальник и говорит - будет иначе, я так решил. Такой вот ГосСкрам
Спасибо!
Я, как практик, не согласен. Если человек красиво говорит, это совсем не значит, что он способен это реализовать. Именно поэтому я и спрашиваю, что человек реально делал, а не что он мечтал делать, и "как бы он обустроил Россию".
Embedded - это программирование микроконтроллеров? Да, я там совсем не работал, не моя тема. Можете даже развернуть, когда и почему навык написания кода на листочке нужен и полезен, думаю всем будет интересно.
Это задача код-ревью, чтобы её делать, нужно быть хоть немного в теме написанного сервиса. И на ревью на рабочем месте можно потратить полчаса-час, на собеседовании - не более 10 минут, причем в состоянии стресса.
Серьезно? У вас там чемпионаты на скоростное кодирование чтоли проходят?:)))
Довольно редко нанимают в свои команды. Обычно в чужие.
Именно так:)))
И определить, могут ли кандидаты принести ценность, можно только в шестиступенчатом собеседовании, за один час этого сделать никак нельзя. Ну и что, что другие делают?:)))
Действительно, альтернатив никаких, вы правы:)))
У меня на полиграфе как-то спросили, приносил ли я работодателю больничные с венерическими болезнями:)))
Прикол в том, что ты не знаешь, на какую сумму тебе сделают предложение в условном Яндексе, а специально обученные люди на каждом этапе будут рассказывать, что они разработчиков не обижают, и кто-то по итогам собеседований получил предложение на 20% ВЫШЕ рынка, просто потому что очень хорош (так в Тинькофф рассказывают, можно посмотреть в их материалах для подготовки).
Этапы могут быть разными, но их количество и, скажем так, качество одинаково для всех уровней.
Для успокоения заказчика лучше всего подходит ватерфол. Там всё распланировано, точно и понятно. Но не работает:))
А сторипоинты как раз и говорят заказчику, что есть неопределенность, и надо с ней жить. Это реально другое мышление.
Не совсем согласен. Соответствие конечно же есть, но как только мы начинаем упоминать знакомые слова, типа "час, день, неделя", мозг начинает к этому привязываться, и вот были неопределенные 80 сторипоинтов, а стали вполне определенные 60 человеко-дней с иллюзией, что 30 человек сделают фичу за 2 дня. И да, это сложно объяснить заказчику, особенно когда он хочет тебя не понять и простить, а утопить.
Это внутри команды, или при оценке нового проекта целиком?
А как релизите? С заказчиком не бывает проблем, как раз в статье описанных, типа "я не это имел ввиду"? Корректировка требований как происходит? В этом же главная беда waterfall.
Вы просто не для того применяете сторипоинты, я в ответе на первый комментарий пояснил, для чего они нужны. При оценке задач, уже принятых командой к выполнению, они бесполезны.
Вообще переоценку положено делать раз в квартал, но у нас происходит примерно раз в год.
Со сторипоинтами одна проблема - никто не понимает, зачем они нужны. Поясню.
Когда мы пытаемся оценить большой проект, мы разбиваем его на фичи и истории, и истории оцениваем примерно на основе уже проработанных историй (без всякой привязки к командам и людям). Принимаем примерную скорость команд (опять же на основе опыта), получаем количество итераций, то есть срок проекта. Тут и применяются сторипоинты.
При взятии историй в спринт сторипоинты нужны только для определения скорости команды, чтобы менеджеру понять, сколько примерно итераций осталось для проработки фичи. Внутри же команды при оценке спринта логично пользоваться днями и часами.
То есть сторипоинты - наружу, человеко-часы - внутрь команды. Двойная бухгалтерия, так сказать:)))
Вот так всегда - одного кандидата обвиняют в коррупции, значит он виноват, а другого не обвиняют, значит и не виноват:)))
И способ достижения целей, да:)))
Вы похоже из госухи?
Для госструктур очень характерно (да, у них тоже есть IT). Команда хочет одно, приходит Большой Начальник и говорит - будет иначе, я так решил. Такой вот ГосСкрам