@bondle
Дробить задачу еще на более мелкие совсем не охота, да и руководство будет кричать когда уже начнем писать код (разработчики то выделены и сидят без дела).
Собственно вопрос основной вопрос в заголовке. Расскажите ваш опыт. Что вы делаете первым делом и как решаете проблемы с параллельными задачами?
Особенно буду признателен за рекомендации курсов/книг/статей по этой теме.
Решения вопроса 0
Ответы на вопрос 5
@Adamos
Дробить задачу еще на более мелкие совсем не охота
Ну и зря. Вообще-то технологиям планирования совместной работы уже не первый век, и важнейший этап — как раз выделение тех участков работы, которые критичны для начала работы на других участках, и подтягивание их на диаграмме Ганта как можно раньше, чтобы уменьшить простой. Потом уже менее критичные задачи ложатся на свободные участки и параллелятся относительно друг друга.
Так, например, нас учили делать генплан строительства еще 30 лет назад. До популяризации в РФ всяких там Скрамов и Канбанов.
@mayton2019
Переодически может появиться очень крупная задача вида «нужно то не знай что». Мне приходится с ней разбираться и если с первым этапом — конкретизация требований все более-менее понятно, то с дальнейшими действиями все совсем плохо.
Ситуация — знакомая. Во первых это — не задача. Это issue типа investigation. Его результатом должен быть не финальный продукт а просто новый сет issues. Оценивать время можно как угодно. Можно писать 1 день для начала. Все равно никто не сможет оспорить вашу оценку.
А совсем попа когда во время разработки понимаешь, что все должно быть не совсем так как ты запроектировал и приходится переделывать.
Это — риски и их просто надо заранее проговорить на митингах. Просто сообщайте заказчику что задача — рисковая и если что-то не так пойдет — то время надо будет сдвинуть.
@DevMan
любую задачу можно разделить на множество этапов, которые занимают не больше дня.
а если вдруг заняли – сигнал о проблеме.
связанные задачи, либо вообще не должны распределяться между разными людьми, либо должен быть приоритет и следование ему.
@hint000
приходится говорить что-то типа: ну вот у тебя зависит от него, ты посмотри как у него сделано, поставь заглушки, потом объедините.
Сначала пишутся все необходимые интерфейсы между кусками задачи. С обсуждением. На это много времени не требуется. Когда интерфейсы зафиксированы (ну как «зафисиксированы», в рабочем порядке никто не запрещает слегка корректировать), то куски можно спокойно разрабатывать независимо. Вроде же это классика. Я бы не сказал «ну вот у тебя зависит от него…», я бы сказал «ваши куски взаимодействуют — значит сразу договаривайтесь, как в точности они взаимодействуют».
А так это надо на конкретной задаче разбирать, в чём затруднения. «По фотографии» такие проблемы не решить.
@dimonchik2013