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