Перед передачей задачи в разработку мы ее оцениваем вместе с разработчиками. В Gitlab для этого в комментарии к задаче пишем /estimate 5h — значит оценка задачи 5 часов. Потом по завершении работы над задачами проводим сверку, и при проведении ретроспективы спринта обсуждаем случаи, когда фактическое время значительно превысило расчетное.
Причины бывают разные. Бывает и так, что и объективно ошибаемся с изначальной оценкой, что-то не учитываем. Тогда особых вопросов не возникает. Но об этом в процессе работы прошу сообщать коллег, чтобы не было сюрпризов под конец спринта.
Да, ретроспективы проводить надо. Мы, например, проводим. С иллюзией не согласен, проверено на практике. Накладные расходы есть, но они не так велики, и отдача от этого — вовремя сданные проекты с хорошим качеством.
Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать, особенно если решение задачи растянулось на пару дней. Если считать от создания ветки до мерджа, то получится времени больше чем ушло на задачу в реальности.
Списывать время не обязательно постоянно в течении дня. Можно и один раз в конце дня, если это будут адекватные данные.
Да, любой инструмент можно использовать с пользой для дела, либо вовред. Забыл, кстати, добавить, что мы его используем для удаленной разработки взамен, на мой взгляд, довольно диких инструментов типа слежки за монитором.
Мне не важно в какое время человек работает и насколько интенсивно нажимает на клавиши. Некоторые задачи предполагают мыслительную активность, при которой вообще лучше отойти от компа. Благодаря этому инструменту, как я считаю, нам удается соблюсти баланс между доверием и контролем.
Разработчик отмечает время, которое он провел над каждой задачей. Это встроенный механизм в Gitlab. Можно написать комментарий /spend 3h — отметится, что человек работал над задачей 3 часа.
Сам Gitlab пока не имеет механизма для подсчета затраченного времени за период каждым сотрудником.
Для этой цели Gitpab работает с API Gitlab — получает все комментарии к задачам и извлекает из них информацию о затраченном времени каждым участником.
Результат складывает в локальную базу. Далее по этим данным строит необходмые отчеты — суммирует время, попутно решает и другие задачи.
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.
А как же post rock. Для себя долго подбирал разное, остановился на пост роке. Без слов, достаточно энергии, чтобы не закисать в процессе работы. При этом достаточно монотонно, чтобы не отвлекаться от работы.
Идея с листенерами мне нравится. Получается более универсальный вариант. Нужно ли их использовать — опять же по ситуации. В коде появляется подписка на события, При добавлении нового таска надо не забывать на него подписаться там где необходимо.
Например, взвесив за и против, для нынешнего проекта я предпочту вариант с pipeline. Для другого проекта с еще более витиеватой логикой возможно лучше подойдет вариант с листенерами.
Да, можно и так. Но у меня жесткого связывания нет, логику управления задачами я как раз вынес за пределы задач. С листенерами получится примерно так же — надо передавать данные и информацию о том, в рамках какого процесса сейчас идет обработка данных, если нужно, чтобы одну и ту же задачу можно было использовать в разных процессах.
Вот пример. Из внешнего сервиса прилетает новый документ на обработку. Нужно найти в нем ключевые слова, определить их тональность, сделать еще ряд манипуляций. Это делается через очереди. Каждая задача — в своей очереди. И эта цепочка как раз описана в отдельном потомке PipelineAbstract.
Помимо этого иногда надо повторно обработать старые документы. В этом случае происходит почти то же самое, но немножко по другому. Чтобы не плодить условия внутри джобов или сами джобы, оказалось очень удобно сделать второй наследник PipelineAbstract и там описать процесс повторной обработки материала.
Я в статье объяснил, почему это оказалось не удобно.
Насчет карты, можно. Это будет чуть ближе к варианту со штатным withChain(). Это уже дело техники и предпочтений, и зависит от ситуации. В моем случае, как я упоминал выше, есть элементы бизнес логики, иногда надо создавать 1 джоб, иногда сразу группу джобов, с разными входными данными, тут практичнее использовать условия.
Вы про метод next()? Не думал как тут можно обойтись без условий. Он вызывается из каждого джоба одинаковым способом. Внутри этого метода надо как-то понять, что делать дальше исходя из того, на какой стадии сейчас находимся. От этого и возникают условия. Тут получается этакая фабрика джобов. На мой взгляд наличие условий в этом методе — не страшно. Но если есть идеи как избавиться тут от if-ов, буду рад.
Перед передачей задачи в разработку мы ее оцениваем вместе с разработчиками. В Gitlab для этого в комментарии к задаче пишем
/estimate 5h— значит оценка задачи 5 часов. Потом по завершении работы над задачами проводим сверку, и при проведении ретроспективы спринта обсуждаем случаи, когда фактическое время значительно превысило расчетное.Причины бывают разные. Бывает и так, что и объективно ошибаемся с изначальной оценкой, что-то не учитываем. Тогда особых вопросов не возникает. Но об этом в процессе работы прошу сообщать коллег, чтобы не было сюрпризов под конец спринта.
Предложите более удачное решение для удаленной разработки.
Да, ретроспективы проводить надо. Мы, например, проводим. С иллюзией не согласен, проверено на практике. Накладные расходы есть, но они не так велики, и отдача от этого — вовремя сданные проекты с хорошим качеством.
Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать, особенно если решение задачи растянулось на пару дней. Если считать от создания ветки до мерджа, то получится времени больше чем ушло на задачу в реальности.
Списывать время не обязательно постоянно в течении дня. Можно и один раз в конце дня, если это будут адекватные данные.
Да, любой инструмент можно использовать с пользой для дела, либо вовред. Забыл, кстати, добавить, что мы его используем для удаленной разработки взамен, на мой взгляд, довольно диких инструментов типа слежки за монитором.
Мне не важно в какое время человек работает и насколько интенсивно нажимает на клавиши. Некоторые задачи предполагают мыслительную активность, при которой вообще лучше отойти от компа. Благодаря этому инструменту, как я считаю, нам удается соблюсти баланс между доверием и контролем.
Разработчик отмечает время, которое он провел над каждой задачей. Это встроенный механизм в Gitlab. Можно написать комментарий
/spend 3h— отметится, что человек работал над задачей 3 часа.Сам Gitlab пока не имеет механизма для подсчета затраченного времени за период каждым сотрудником.
Для этой цели Gitpab работает с API Gitlab — получает все комментарии к задачам и извлекает из них информацию о затраченном времени каждым участником.
Результат складывает в локальную базу. Далее по этим данным строит необходмые отчеты — суммирует время, попутно решает и другие задачи.
Да, внутренние проекты на Gitlab, а опенсурсное привычнее выложить на Github. Про SaaS посмотрю по активности, если будет спрос — сделаю.
Большущее спасибо. Не знал про T и Y. Это то, чего мне частенько не хватало. И, что интересно, проверил — в Gitlab тоже работают эти клавиши!
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.
Тут большая часть списка:
https://music.yandex.ru/users/mnvx/artists
Буду рад, если тоже поделитесь
А как же post rock. Для себя долго подбирал разное, остановился на пост роке. Без слов, достаточно энергии, чтобы не закисать в процессе работы. При этом достаточно монотонно, чтобы не отвлекаться от работы.
Ответ в последнем абзаце.
Идея с листенерами мне нравится. Получается более универсальный вариант. Нужно ли их использовать — опять же по ситуации. В коде появляется подписка на события, При добавлении нового таска надо не забывать на него подписаться там где необходимо.
Например, взвесив за и против, для нынешнего проекта я предпочту вариант с pipeline. Для другого проекта с еще более витиеватой логикой возможно лучше подойдет вариант с листенерами.
Да, можно и так. Но у меня жесткого связывания нет, логику управления задачами я как раз вынес за пределы задач. С листенерами получится примерно так же — надо передавать данные и информацию о том, в рамках какого процесса сейчас идет обработка данных, если нужно, чтобы одну и ту же задачу можно было использовать в разных процессах.
Вот пример. Из внешнего сервиса прилетает новый документ на обработку. Нужно найти в нем ключевые слова, определить их тональность, сделать еще ряд манипуляций. Это делается через очереди. Каждая задача — в своей очереди. И эта цепочка как раз описана в отдельном потомке
PipelineAbstract.Помимо этого иногда надо повторно обработать старые документы. В этом случае происходит почти то же самое, но немножко по другому. Чтобы не плодить условия внутри джобов или сами джобы, оказалось очень удобно сделать второй наследник
PipelineAbstractи там описать процесс повторной обработки материала.Я в статье объяснил, почему это оказалось не удобно.
Насчет карты, можно. Это будет чуть ближе к варианту со штатным
withChain(). Это уже дело техники и предпочтений, и зависит от ситуации. В моем случае, как я упоминал выше, есть элементы бизнес логики, иногда надо создавать 1 джоб, иногда сразу группу джобов, с разными входными данными, тут практичнее использовать условия.Вы про метод
next()? Не думал как тут можно обойтись без условий. Он вызывается из каждого джоба одинаковым способом. Внутри этого метода надо как-то понять, что делать дальше исходя из того, на какой стадии сейчас находимся. От этого и возникают условия. Тут получается этакая фабрика джобов. На мой взгляд наличие условий в этом методе — не страшно. Но если есть идеи как избавиться тут от if-ов, буду рад.Вот так:
На графиках суммы после вычета налогов (на руки) или до?
Вряд ли