Comments 8
В компании много продуктовых команд и почти все работают по Agile.
«Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?
Agile можно следовать, так как это манифест+набор принципов. А Scrum — это уже конкретный подход к работе, фреймворк. Интерфейс и его реализация, если позволите так выразиться.
Демонстрировать новый функционал стало проще, но только внутри компании, потому что решение не выглядит презентабельным.
А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.
А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию?
Ну так рефакторинг закладывается на оценке задачи. Все, кроме вас на покере выдают оценку 3, а вы — 6. Вас спрашивают почему. Вы говорите «ну вот тут надо переписать». Начинается обсуждение, в котором вопрос всесторонне рассматривается. Проводят следующий раунд, и или вы с командой соглашаетесь и показываете оценку 3. Или команда с вами и выдает оценку 6. Или все сойдутся на оценке 4.
Как мне показалось, эта статья больше про то, как продавать бэкенд его клиентам, в числе которых явно не только люди, участвующие в покере. Таким образом, может получиться ситуация, что и оценку 4 тоже надо продать, так как клиенты спросят «А чего так долго?».
Статья-то да. А вопрос, на который я отвечал — нет.
Ну, вы же все предыдущие итерации укладывались в оценки. И с чего бы в этой они вам не будут доверять?
А чего так долго?
Ну, вы же все предыдущие итерации укладывались в оценки. И с чего бы в этой они вам не будут доверять?
Хорошо, в такой ситуации — ОК. Но предположим, что этот процесс внедряется в команде, где пока оценка ставится под сомнение. И мой вопрос касается как раз такого расклада.
Ну и обоснуете тогда.
Вы просто сами себя в заблуждение ввели вопросом. Задачи оцениваются в стори-поинтах. Долго/не долго — это уже станет понятно после нескольких итераций. И там уже к ответу на вопрос «чего так долго?» у вас будет шанс подготовиться на ретроспективе. Вы там обсудите, «чего так долго?» и договоритесь о конкретных мерах, чтобы стало быстрее.
Вы просто сами себя в заблуждение ввели вопросом. Задачи оцениваются в стори-поинтах. Долго/не долго — это уже станет понятно после нескольких итераций. И там уже к ответу на вопрос «чего так долго?» у вас будет шанс подготовиться на ретроспективе. Вы там обсудите, «чего так долго?» и договоритесь о конкретных мерах, чтобы стало быстрее.
«Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?
Да, действительно. Спасибо!
А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.
Если говорить про вариант «Не так давно», то он делался на коленке и команда не рассматривала рефакторинг этого кода, как нечто необходимое
Если же говорить про текущий вариант, то да, как выше отметили, мы либо закладываем это в оценку задачи, либо убеждаем продуктовый офис вынести это отдельной задачей, обычно они идут нам навстречу.
Sign up to leave a comment.
Как продавать backend продукт внутри компании