Я сам убегу если надо будет делить все на задачи по пол часа

Ну и беги раз тебя мировое господство не интересует

А то бесплатную консультацию дай... А поцеловать?

Я когда то полгода в госе работал, так там тот же метод. Только садишься делать и вызывают на «планерку»

Сначала статус задачи спрашивают, а потом почему не успеваем 😂

Вот это идиотизм. Планетки у ведущих специалистов. У пехоты тихий час. Точнее в мегаплане было 2 часа с 15 до 17

так что не надо гнать на эльбрус

Когда у вас будет распределённая компания тыщ на 5000 и 50 проектов по 100 прогнозов тогда надо учиться быстро обмениваться результатами статусами

ну когда будет, приходите, расскажите нам свой опыт управления распределенной командой в 5000 человек

Дилетантская ошибка! Директор компании не может научиться у другого директора просто потому что он сцука такой важный что у других учиться не умеет. Царь должен нанять мудреца, а не другого царя. Директор должен уметь заинтересовать нач РНД если на ит языке.

Примеры в студию

Урл зажали?

:)) если тут хайп до послеавтра продержится с компьютера заброшу.

Я бы хотел подитожить: Пишем us, обсуждаем с командой, описываем тесты, рисуем, а потом добавляем примечания по платформам, оцениваем и вперёд?

Владелец продукта и команда работает с бэклогом декомпозирует истории на более мелкие что в спринт влезали и пишет критерии приемки для каждой. На планировании спринта команда набирает себе историй, декомпозирует на подзадачи и фигачит в принте. На начало спринта у команды уже есть придлизительное понимание, как делать каждую историю. Перед началом работы над историей команда обсуждает детали и истории и синхронизирует понимание. Тогда получается делать дизайн, фронт и бэк параллельно. При этом хорошо бы иметь дизайн систему. Без неё будет тежелее.

Ну и это все возможно если над продуктом работают "мотивированные профессионалы" ))

Урл зажали?

Если пм будет девом и будет истории бить на подзадачи самостоятельно будет следующее: 1. у него будет значительно меньше времени заниматься продуктом 2. его команда не будет чувствовать ответственность за истории по причине того, что дев сам не выбирает себе задачу 3. будет конфликт между командой и пмом на тему "я пм и понимаю в деве, сделайте так как я сказал". 4. из-за всего перечисленного у команды упадет мотивация на дно. У них будет ощущение, что они ресурс для реализации хотелок пма

Если пм будет девом и будет истории бить на подзадачи самостоятельно будет следующее: 1. у него будет значительно меньше времени заниматься продуктом 2. его команда не будет чувствовать ответственность за истории по причине того, что дев сам не выбирает себе задачу 3. будет конфликт между командой и пмом на тему "я пм и понимаю в деве, сделайте так как я сказал". 4. из-за всего перечисленного у команды упадет мотивация на дно. У них будет ощущение, что они ресурс для реализации хотелок пма

1. разбить стори на таски для 10 разработчиков это примерно пол дня с кофеями, обедами и перекурами 2. обычно люди в больших проектах пилят свои модули аля рассылка нотификаций, платежи, маркетинг, просто пропускается не нужной фарс в виде выбора задачи аля финансист возмет задачу из модуля маркетинг и будет неделю вникать как оно работает? нет так не бывает 3. с чего вдруг пма дева девы уважают они в одной лодке, все хотят сделать красиво без напрягов и попить пива вечером 4. хотелки не пма а заказчика, пм-дев и девы обычно прекрасно друг друга понимают НО даже если прямо совсем надо можно делигировать озвучивание решений на тим лида который как бы дев и лид тут на свой вкус

Отлично и кратко про проблемы. Дядя голдрпт сказал что в управлении проектами главное зло что оценки превращаются в обязательства. Интервальная оценка вдруг бац и вместо диапазона превращается в среднее. Казалось бы безобидное допущение. Но когда в проекте 1000-5000 задач не дай бог по дню. Все валится китайские доминошки. Но я пока почитаю проблемы от Дениса.

1. разбить стори на таски для 10 разработчиков это примерно пол дня с кофеями, обедами и перекурами 2. обычно люди в больших проектах пилят свои модули аля рассылка нотификаций, платежи, маркетинг, просто пропускается не нужной фарс в виде выбора задачи аля финансист возмет задачу из модуля маркетинг и будет неделю вникать как оно работает? нет так не бывает 3. с чего вдруг пма дева девы уважают они в одной лодке, все хотят сделать красиво без напрягов и попить пива вечером 4. хотелки не пма а заказчика, пм-дев и девы обычно прекрасно друг друга понимают НО даже если прямо совсем надо можно делигировать озвучивание решений на тим лида который как бы дев и лид тут на свой вкус

мы уже поняли все, спасибо, у нас все скромно в тесном дружеском кругу

Это вы Денис рассказываете про разбиение по подкомандам. Отличный подход если у вас на проекте количество команд не меняется.

1. разбить стори на таски для 10 разработчиков это примерно пол дня с кофеями, обедами и перекурами 2. обычно люди в больших проектах пилят свои модули аля рассылка нотификаций, платежи, маркетинг, просто пропускается не нужной фарс в виде выбора задачи аля финансист возмет задачу из модуля маркетинг и будет неделю вникать как оно работает? нет так не бывает 3. с чего вдруг пма дева девы уважают они в одной лодке, все хотят сделать красиво без напрягов и попить пива вечером 4. хотелки не пма а заказчика, пм-дев и девы обычно прекрасно друг друга понимают НО даже если прямо совсем надо можно делигировать озвучивание решений на тим лида который как бы дев и лид тут на свой вкус

Моя команда декомпозицию историй на подзадачи для двухнедельного спринта делает за 30 мин в среднем ( само планирование часа за 2 где-то). В компании, где я работаю, есть старые комппонентыне команды. Они работают как раз по такому принципу, как вы описываете. Ничего плохого в этом нет, только скорость разработки значительно ниже. Новые скрам-команды подняли скорость разработки на другой уровень по сравнению со старыми командами. Не даром в скраме есть PO, который отвечает за продукт и dev team, которая отвечает за техническую часть. Это позволяет сфокусироваться каждому на главном.

Оценки вообще штука очень субъективная. Как можно полагаться на оценку времени выполнения, когда она может изменяться в процессе работы на десятки процентов?