Практические примеры разбиения больших задач на микротаски / Никита Соболев (wemake.services)
ฝัง
- เผยแพร่เมื่อ 23 ก.ย. 2024
- Приглашаем на конференцию TeamLead Conf++ 2024, которая пройдет 27 и 28 ноября в Москве!
Программа, подробности и билеты по ссылке: clck.ru/3DDSgX
---------
При поддержке AvitoTech мы впервые публикуем все видео с TeamLead Conf 2020 в открытый доступ. Учитесь, вдохновляйтесь и перенимайте лучшие практики у спикеров, не выходя из дома.
--------
Календарь конференций - ontico.ru
--------
TeamLead Conf 2020
Тезисы и презентация:
teamleadconf.r...
Я очень часто слышу, что "оценивать задачи от 15 минут до 2 часов" сложно, ненужно и вообще невозможно.
И как же я устал!
Да, действительно. Поначалу будет сложно.
Да, действительно. Нужно будет поменять свой подход к построению инфраструктуры.
Да, действительно. Нужно будет поменять свой подход к проектированию архитектуры.
Да, действительно. Нужно будет поменять механизм постановки задач.
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Огненный доклад! Спасибо! Я сейчас смотрю в сторону разбиения работы на функционально законченные куски, до пары дней работы команды. А вот теперь вижу, что это полумера. :-)
Разбивайте на двухминутные задачи, вообще огонь будет.
интересно в какой момент задачи пилятся на микротаски. Это тоже от отдельная таска и требует времени. Или есть отдельные люди с мировосприятием правильной пилы.
пилишь задачу, понимаешь, что задача долгая - пилишь ее на части, сообщаешь об этом
как можно поделить таску на часовые "микротаски" или еще меньше? самое быстрое что я делал в своей работе это был просто багфикс, который я решал по логу из эластика. я знал где и что делать (так как сам писал уод до этого), но у меня заняло это около часа, потому что помимо написания кода, его нужно потестировать, перепроверить чтобы ничто не отлетело и потом еще PR оформить... пусть даже это в сумме займет 30 минут, но это же единичные случаи
15:54 мне интересно на какие задачи они делят все?
1 метод - 1 таска? ну, тогда да - конечно я могу поделить задачу на на подзадачи по 15 минут, но у меня га планирование уйдет столько же сколько и на выполнение, еще и бегать каждые 15 минут в джиру отмечаться, что у все сделано и офромлять коммиты... а модет просто нанять менеджера и не заниматься херней?
Интересный доклад. Но люди настолько в своём вакууме живут.
Вот представьте продуктовую разработку какого-нибудь маршрутизатора, на котором нужно поддержать IPv6. И реальные трудозатраты на это ретроспективно - полгода человеко-команды.
Вернёмся назад. Бизнес спрашивает: когда у Вас будет поддержан IPv6? А мы говорим - не знаем, мы можем только на пару недель вперёд максимум микрозадач нарезать и оценить. Бред полнейший. Нужно упоминать явно, для какой разработки возможен подход
Спасибо! Весьма интересно!
Очень крутой доклад, оказалось что я так всегда работал даже не подозревая что это микротасковый подход.
Практических примеров разбиения так и не увидел
так ссылки на репозитории были. Взять тот же гитхаб - маленькие пр
22:05 Прямо сейчас открыто 300 задач. Как обеспечить прозрачность при таком объеме задач? (Кажется, за деревьями леса не видно.)
Подозреваю, что накладные расходы на управление задачами будут заметно больше, чем в случае задач на 8 или 4 часа.
В ту же тему - Puzzle Driven Development, www.yegor256.com/2010/03/04/pdd.html
Интересный доклад. Хорошо бы попробовать микротаски на себе :)
Очень хотелось бы связаться с докладчиком напрямую, но не нашел ни одного способа подобной коммуникации... ;( Доклад конечно интересный, сейчас пойду изучать ссылки, но некоторые вещи мне принципиально непонятны! Например, автор доклада активно пропагандирует покрытие любой новой части кода необходимым и достаточным количеством автотестов... Я с ним в этом согласен, но пока у нас получается, что время на создание качественных автотестов (я сейчас говорю только о модульных и возможно простейших интеграционных тестах, которые пишет сам разработчик) минимум равняется времени на написание исходного кода фичи. Я надеюсь, что это отношение трудозатрат со временем будет уменьшаться, но все равно в разумных пределах. Получается, что бывают такие микротаски на 15 минут, которые требуют 5-7 минут на написание кода (вместе с поиском и обдумыванием решения) и примерно столько же на автотесты. Если честно, то не могу себе представить таких задач в реальности. Это получается просто написать несколько строчек кода, который заранее уже известен! Если нужно что-то дополнительно проанализировать, погуглись, выбрать одно решение из нескольких или уточнить условие задачи, то времени на это уже не останется...
Человек на протяжении 51 минуты пытается продать всем отвратительный микроменеджмент под видом микротасок. Ну что же, удачи.