Pull to refresh

Comments 7

Смущают затраты времени на звонки.
Мы понимали, что нам нужно созваниваться, поскольку вся команда должна быть вовлечена в процесс разработки и знать, что мы вместе стараемся создать.
… т.е. без регулярных созвонов команда не знает, что она пытается создать? Нет багтрекера, не ведётся документация?

Закончив фичу, разработчик сообщает, что готов показать демо. Тогда на звонок собирается все, кто участвовал в разработке фичи.
Закончив фичу, я пишу один e-mail (текстом которого можно потом пользоваться при написании документации, при ответе заказчику и т.п.), который видят все, кому это нужно. Каким образом созвон с (например) пятью людьми может быть эффективнее?
Если бы у автора реально был Agile, то как раз плотные коммуникации — это, фактически, обязательное требование. Т.к. там команда должна работать на определённый результат, а не просто на выполнение задач. Но у автора не Agile совсем.
уберите теги и слова «agile» и «scrum» из статьи и заголовка
Если вы закрываете 10-15 проблем в неделю (1-2 в день). Получается каждый раз вы созваниваетесь и обсуждаете, а потом ещё раз созваниваетесь после необходимых изменений (на основе обсуждений). Итого 2-3 раза в день. Скажите, каково разработчикам каждый раз отвлекаться, вникать в реализацию фичи своего коллеги 3 раза в день? Это ведь не просто бла бла бла, а конкретные рекомендации над которыми надо размышлять. Получается два часа поработал, созвон, два часа поработал, созвон… Со стороны выглядит, что у Вас достаточно опасная ситуация.
1. Agile не подходит для релизов раз в квартал. Это само по себе противоречит почти всем принципам Agile.
2. PO не должен следить за написанием требований, он сам их должен писать, технические специалисты должны описывать технические подходы. PO фактически занимается тем, что формирует стратегию достижения поставленных бизнесом целей. Поэтому в разрезе употребления термина «product owner» фраза «следит за соответствие требований пожеланиям заказчика» неуместна. У вас, скорее, менеджер проекта.
3. PO не должен оценивать задачи, PO должен брать оценку от технических специалистов и на базе оценки принимать тактические решения, которые позволят остаться в рамках road map (например, выкинуть второстепенные требования или принять решение о реализации грязного MVP вместо полноценно рабочей функциональности).
4. Выделение фиксированного времени на фикс багов не имеет смысла — фикс конкретного бага должен приоритизироваться так же, как и разработка фич. Достаточно странно тратить 50% времени разработчиков на фиксы чего-то некритического при наличии критических бизнес-требований, например.

Если коротко — у вас не Agile процесс и не Agile команда.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Website
www.dataart.com
Employees
1,001–5,000 employees
Registered