Comments 7
Смущают затраты времени на звонки.
Мы понимали, что нам нужно созваниваться, поскольку вся команда должна быть вовлечена в процесс разработки и знать, что мы вместе стараемся создать.… т.е. без регулярных созвонов команда не знает, что она пытается создать? Нет багтрекера, не ведётся документация?
Закончив фичу, разработчик сообщает, что готов показать демо. Тогда на звонок собирается все, кто участвовал в разработке фичи.Закончив фичу, я пишу один e-mail (текстом которого можно потом пользоваться при написании документации, при ответе заказчику и т.п.), который видят все, кому это нужно. Каким образом созвон с (например) пятью людьми может быть эффективнее?
уберите теги и слова «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 команда.
2. PO не должен следить за написанием требований, он сам их должен писать, технические специалисты должны описывать технические подходы. PO фактически занимается тем, что формирует стратегию достижения поставленных бизнесом целей. Поэтому в разрезе употребления термина «product owner» фраза «следит за соответствие требований пожеланиям заказчика» неуместна. У вас, скорее, менеджер проекта.
3. PO не должен оценивать задачи, PO должен брать оценку от технических специалистов и на базе оценки принимать тактические решения, которые позволят остаться в рамках road map (например, выкинуть второстепенные требования или принять решение о реализации грязного MVP вместо полноценно рабочей функциональности).
4. Выделение фиксированного времени на фикс багов не имеет смысла — фикс конкретного бага должен приоритизироваться так же, как и разработка фич. Достаточно странно тратить 50% времени разработчиков на фиксы чего-то некритического при наличии критических бизнес-требований, например.
Если коротко — у вас не Agile процесс и не Agile команда.
Sign up to leave a comment.
Как не сойти с ума от Scrum? Опыт растущего проекта