Интересный доклад. Но люди настолько в своём вакууме живут. Вот представьте продуктовую разработку какого-нибудь маршрутизатора, на котором нужно поддержать IPv6. И реальные трудозатраты на это ретроспективно - полгода человеко-команды. Вернёмся назад. Бизнес спрашивает: когда у Вас будет поддержан IPv6? А мы говорим - не знаем, мы можем только на пару недель вперёд максимум микрозадач нарезать и оценить. Бред полнейший. Нужно упоминать явно, для какой разработки возможен подход
интересно в какой момент задачи пилятся на микротаски. Это тоже от отдельная таска и требует времени. Или есть отдельные люди с мировосприятием правильной пилы.
22:05 Прямо сейчас открыто 300 задач. Как обеспечить прозрачность при таком объеме задач? (Кажется, за деревьями леса не видно.) Подозреваю, что накладные расходы на управление задачами будут заметно больше, чем в случае задач на 8 или 4 часа.
как можно поделить таску на часовые "микротаски" или еще меньше? самое быстрое что я делал в своей работе это был просто багфикс, который я решал по логу из эластика. я знал где и что делать (так как сам писал уод до этого), но у меня заняло это около часа, потому что помимо написания кода, его нужно потестировать, перепроверить чтобы ничто не отлетело и потом еще PR оформить... пусть даже это в сумме займет 30 минут, но это же единичные случаи
15:54 мне интересно на какие задачи они делят все? 1 метод - 1 таска? ну, тогда да - конечно я могу поделить задачу на на подзадачи по 15 минут, но у меня га планирование уйдет столько же сколько и на выполнение, еще и бегать каждые 15 минут в джиру отмечаться, что у все сделано и офромлять коммиты... а модет просто нанять менеджера и не заниматься херней?
Огненный доклад! Спасибо! Я сейчас смотрю в сторону разбиения работы на функционально законченные куски, до пары дней работы команды. А вот теперь вижу, что это полумера. :-)
Очень хотелось бы связаться с докладчиком напрямую, но не нашел ни одного способа подобной коммуникации... ;( Доклад конечно интересный, сейчас пойду изучать ссылки, но некоторые вещи мне принципиально непонятны! Например, автор доклада активно пропагандирует покрытие любой новой части кода необходимым и достаточным количеством автотестов... Я с ним в этом согласен, но пока у нас получается, что время на создание качественных автотестов (я сейчас говорю только о модульных и возможно простейших интеграционных тестах, которые пишет сам разработчик) минимум равняется времени на написание исходного кода фичи. Я надеюсь, что это отношение трудозатрат со временем будет уменьшаться, но все равно в разумных пределах. Получается, что бывают такие микротаски на 15 минут, которые требуют 5-7 минут на написание кода (вместе с поиском и обдумыванием решения) и примерно столько же на автотесты. Если честно, то не могу себе представить таких задач в реальности. Это получается просто написать несколько строчек кода, который заранее уже известен! Если нужно что-то дополнительно проанализировать, погуглись, выбрать одно решение из нескольких или уточнить условие задачи, то времени на это уже не останется...
Интересный доклад. Но люди настолько в своём вакууме живут.
Вот представьте продуктовую разработку какого-нибудь маршрутизатора, на котором нужно поддержать IPv6. И реальные трудозатраты на это ретроспективно - полгода человеко-команды.
Вернёмся назад. Бизнес спрашивает: когда у Вас будет поддержан IPv6? А мы говорим - не знаем, мы можем только на пару недель вперёд максимум микрозадач нарезать и оценить. Бред полнейший. Нужно упоминать явно, для какой разработки возможен подход
интересно в какой момент задачи пилятся на микротаски. Это тоже от отдельная таска и требует времени. Или есть отдельные люди с мировосприятием правильной пилы.
пилишь задачу, понимаешь, что задача долгая - пилишь ее на части, сообщаешь об этом
Интересный доклад. Хорошо бы попробовать микротаски на себе :)
22:05 Прямо сейчас открыто 300 задач. Как обеспечить прозрачность при таком объеме задач? (Кажется, за деревьями леса не видно.)
Подозреваю, что накладные расходы на управление задачами будут заметно больше, чем в случае задач на 8 или 4 часа.
В ту же тему - Puzzle Driven Development, www.yegor256.com/2010/03/04/pdd.html
Человек на протяжении 51 минуты пытается продать всем отвратительный микроменеджмент под видом микротасок. Ну что же, удачи.
как можно поделить таску на часовые "микротаски" или еще меньше? самое быстрое что я делал в своей работе это был просто багфикс, который я решал по логу из эластика. я знал где и что делать (так как сам писал уод до этого), но у меня заняло это около часа, потому что помимо написания кода, его нужно потестировать, перепроверить чтобы ничто не отлетело и потом еще PR оформить... пусть даже это в сумме займет 30 минут, но это же единичные случаи
15:54 мне интересно на какие задачи они делят все?
1 метод - 1 таска? ну, тогда да - конечно я могу поделить задачу на на подзадачи по 15 минут, но у меня га планирование уйдет столько же сколько и на выполнение, еще и бегать каждые 15 минут в джиру отмечаться, что у все сделано и офромлять коммиты... а модет просто нанять менеджера и не заниматься херней?
Практических примеров разбиения так и не увидел
так ссылки на репозитории были. Взять тот же гитхаб - маленькие пр
Огненный доклад! Спасибо! Я сейчас смотрю в сторону разбиения работы на функционально законченные куски, до пары дней работы команды. А вот теперь вижу, что это полумера. :-)
Разбивайте на двухминутные задачи, вообще огонь будет.
Очень хотелось бы связаться с докладчиком напрямую, но не нашел ни одного способа подобной коммуникации... ;( Доклад конечно интересный, сейчас пойду изучать ссылки, но некоторые вещи мне принципиально непонятны! Например, автор доклада активно пропагандирует покрытие любой новой части кода необходимым и достаточным количеством автотестов... Я с ним в этом согласен, но пока у нас получается, что время на создание качественных автотестов (я сейчас говорю только о модульных и возможно простейших интеграционных тестах, которые пишет сам разработчик) минимум равняется времени на написание исходного кода фичи. Я надеюсь, что это отношение трудозатрат со временем будет уменьшаться, но все равно в разумных пределах. Получается, что бывают такие микротаски на 15 минут, которые требуют 5-7 минут на написание кода (вместе с поиском и обдумыванием решения) и примерно столько же на автотесты. Если честно, то не могу себе представить таких задач в реальности. Это получается просто написать несколько строчек кода, который заранее уже известен! Если нужно что-то дополнительно проанализировать, погуглись, выбрать одно решение из нескольких или уточнить условие задачи, то времени на это уже не останется...
Очень крутой доклад, оказалось что я так всегда работал даже не подозревая что это микротасковый подход.
Спасибо! Весьма интересно!