Комментарии 7
Изменилось ли как то время stand-up meeting?
Мне кажется если проходить по полному списку задач, а не по тем над которыми разработчик работал сегодня — время должно увеличиться.
Мне кажется если проходить по полному списку задач, а не по тем над которыми разработчик работал сегодня — время должно увеличиться.
Время стендапов сначала увеличилось до 40 минут, а потом мы сбили его обратно до 15 минут. Дело было в том, что мы и заказчики привыкали. Много «залежалых» задач начали двигаться и время уходило на их обсуждение. Когда поток задач стал равномерным, обсуждение начали проходить быстро.
> Мне кажется если проходить по полному списку задач
Проходить по полному списку задач не нужно, нужно идти по задачам пока остались свободные ресурсы. Т.е. если все члены команды набрали себе работы на день, то дальше можно ничего не обсуждать.
> Мне кажется если проходить по полному списку задач
Проходить по полному списку задач не нужно, нужно идти по задачам пока остались свободные ресурсы. Т.е. если все члены команды набрали себе работы на день, то дальше можно ничего не обсуждать.
>Проходить по полному списку задач не нужно, нужно идти по задачам пока остались свободные ресурсы. Т.е. если все члены команды набрали себе работы на день, то дальше можно ничего не обсуждать.
Если идти от правого края, то в вашем случае столбцы Ready for Test, Ready for preprod, Ready for live должны разбираться полностью всегда, потому что только так можно выловить висячие задачи. Я правильно понимаю? Хотя Ready for test под вопросом, так как заивисит от организации процесса тестирования (могут или не могут там виснуть задачи).
Если идти от правого края, то в вашем случае столбцы Ready for Test, Ready for preprod, Ready for live должны разбираться полностью всегда, потому что только так можно выловить висячие задачи. Я правильно понимаю? Хотя Ready for test под вопросом, так как заивисит от организации процесса тестирования (могут или не могут там виснуть задачи).
> должны разбираться полностью всегда
Я бы сказал, что они должны обсуждаться и по возможности задачи оттуда должны уходить правее.
Возможен вариант, что задачи из последних колонок не часто обсуждаются, например, если задача готова к заливке, а заливку на боевой можно делать только 1 раз в неделю в определенное время. Мы же не будем ежедневно обсудать эту задачу, проще пометить ее стикером и написать дату ее заливки, а во время стендапа пропускать.
> Хотя Ready for test под вопросом, так как заивисит от организации процесса тестирования (могут или не могут там виснуть задачи)
В Kanban как всегда всё решается принципом «Make Process Policies Explicit». Т.е. всё как вы договоритесь, как команде понятней и удобней.
Я бы сказал, что они должны обсуждаться и по возможности задачи оттуда должны уходить правее.
Возможен вариант, что задачи из последних колонок не часто обсуждаются, например, если задача готова к заливке, а заливку на боевой можно делать только 1 раз в неделю в определенное время. Мы же не будем ежедневно обсудать эту задачу, проще пометить ее стикером и написать дату ее заливки, а во время стендапа пропускать.
> Хотя Ready for test под вопросом, так как заивисит от организации процесса тестирования (могут или не могут там виснуть задачи)
В Kanban как всегда всё решается принципом «Make Process Policies Explicit». Т.е. всё как вы договоритесь, как команде понятней и удобней.
false comment(
Спасибо за статью, интересный подход, логично и похоже должно работать! Хотелось бы уточнить только один момент на следующем примере… Обычно крайние правые колонки — это валидации продактов\тестировщиков. Как разбираются задачи, в случае если в предпоследней колонке, которая, например, отвечает за подтверждение Product Owner'а (PO), задач больше, чем количество команды (разработчики и тестировщики)? Суть в том, что если фактически задачи «подвисли» в статусе, за который обычно отвечает определенная группа людей (например, тестировщики), и задач больше, чем участников этой группы, будут ли другие (разработчики?) брать на себя их решение (например, тестирование)?
Ответ на этот вопрос, как на все остальные вопросы, которые касаются Kanban, лежит в принципе «Make Process Policies Explicit». Это означает, что как команда договорится, так и надо делать.
Если PO является бутылочным горлышком, то это нужно явно обозначить на стендапе и во время ретроспективы. Возможно PO отдаст часть полномочий аналитикам или еще кому-то, возможно PO станет не один человек, а несколько, например, кто-то из соинвесторов присоединится к этой работае.
Если выяснится, что PO просто не успевает разгребать задачи и расшить его полномочия не на кого, то тогда команде нет смысла работать с высокой скоростью. Возможно даже часть команды надо убрать на другой проект, потому что не имеет значение как быстро команда делает карточки, если PO не успевает их принимать.
Из своего опыта могу сказать, что довольно редко одни роли в команде, помогают другим. Кроссфункциональность есть, но с большими ограничениями. Бывает, что программисты помогают DevOps, аналитики помогают тестировщикам, но никогда не видел, например, чтобы программисты помогали тестировщикам или аналитики работали с DevOps.
Если PO является бутылочным горлышком, то это нужно явно обозначить на стендапе и во время ретроспективы. Возможно PO отдаст часть полномочий аналитикам или еще кому-то, возможно PO станет не один человек, а несколько, например, кто-то из соинвесторов присоединится к этой работае.
Если выяснится, что PO просто не успевает разгребать задачи и расшить его полномочия не на кого, то тогда команде нет смысла работать с высокой скоростью. Возможно даже часть команды надо убрать на другой проект, потому что не имеет значение как быстро команда делает карточки, если PO не успевает их принимать.
Из своего опыта могу сказать, что довольно редко одни роли в команде, помогают другим. Кроссфункциональность есть, но с большими ограничениями. Бывает, что программисты помогают DevOps, аналитики помогают тестировщикам, но никогда не видел, например, чтобы программисты помогали тестировщикам или аналитики работали с DevOps.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стендапы в стиле Kanban