mnv 29 янв 2019 в 08:33

Gitpab. Приятно познакомиться

7 мин

6.6K

Open source*PHP*Laravel*Управление разработкой*Управление проектами*

Комментарии 24

slaFFik 29 янв 2019 в 10:13

Инструмент для Gitlab, который хостится на GitHub.

Напрашивается hosted-решение, SaaS. Планируется?

mnv 29 янв 2019 в 10:35

Да, внутренние проекты на Gitlab, а опенсурсное привычнее выложить на Github. Про SaaS посмотрю по активности, если будет спрос — сделаю.

fishca 29 янв 2019 в 13:36

Не очень понятен принцип расчета времени разработчика, можно как-то более подробно изложить? Но на первый беглый взгляд очень даже полезный инструмент.

mnv 29 янв 2019 в 13:45

Разработчик отмечает время, которое он провел над каждой задачей. Это встроенный механизм в Gitlab. Можно написать комментарий /spend 3h — отметится, что человек работал над задачей 3 часа.

Сам Gitlab пока не имеет механизма для подсчета затраченного времени за период каждым сотрудником.

Для этой цели Gitpab работает с API Gitlab — получает все комментарии к задачам и извлекает из них информацию о затраченном времени каждым участником.

Результат складывает в локальную базу. Далее по этим данным строит необходмые отчеты — суммирует время, попутно решает и другие задачи.

i360u 29 янв 2019 в 13:51

Отмечать время — это как-то уныло и напряжно, особенно при большой загрузке разработчика. Почему-бы не привязаться к git flow: считать время от создания feature-ветки до ее мерджа?

mnv 29 янв 2019 в 14:00

Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать, особенно если решение задачи растянулось на пару дней. Если считать от создания ветки до мерджа, то получится времени больше чем ушло на задачу в реальности.

Списывать время не обязательно постоянно в течении дня. Можно и один раз в конце дня, если это будут адекватные данные.

i360u 29 янв 2019 в 14:18

Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать

А большая детализация тут и не нужна совсем. Хотя, если у вас к этому привязана почасовая оплата — то тоска-печаль: при такой атомизации процесса он (процесс) начинает нести дополнительные накладные издержки а менеджмент получает лишь иллюзию контроля. В любом случае, анализ затраченного времени без хорошего ретроспективного анализа — пустая трата времени и нервов.

mnv 29 янв 2019 в 15:05

Да, ретроспективы проводить надо. Мы, например, проводим. С иллюзией не согласен, проверено на практике. Накладные расходы есть, но они не так велики, и отдача от этого — вовремя сданные проекты с хорошим качеством.

i360u 29 янв 2019 в 15:25

А обычно никто, у кого иллюзии, с этим не согласен. На то они и иллюзии )

mnv 29 янв 2019 в 15:37

Предложите более удачное решение для удаленной разработки.

i360u 30 янв 2019 в 11:18

Очень зависит от уровня задач, размера и компетенций команды. И от лидерских качеств лидеров. Иногда достаточно смотреть на содержание коммитов, и обсуждать с командой цели и задачи. Иногда — строить графики и прогнозы на основе автоматически собранных данных (не приставая к разрабам с формальными требованиями не относящимися напрямую к написанию кода). Данных — полно: это и гит и чаты и таск-трекеры. А вот заниматься крохоборством, подсчитывать часы и минуты, тратить кучу времени на детализированные эстимейты — это дно.

mnv 30 янв 2019 в 12:17

Вот у вас сотрудник, по сути внештатный. Что-то делал в течении месяца. Работал за этот период часов 50. Может быть и 150. Как вы будете считать сколько ему заплатить исходя из истории гита, чатов и таск трекера?

i360u 30 янв 2019 в 11:20

И да, удаленная разработка ничем особо не отличается по процессу от «приближенной» если этот процесс правильно выстроен, т.е. участники не сидят по отдельным «черным ящикам».

cudu 10 дек 2019 в 08:32

то есть никаких решений вы не предлагаете?

SirEdvin 30 янв 2019 в 22:23

Позадачная оплата, например.

i360u 29 янв 2019 в 13:41

Эта штука может как оказаться очень полезной, так и полностью убить процесс а то и команду при "умелом использовании" в рамках "эффективного менеджмента". Потому, что может перевести фокус команды с самих задач непосредственно, на формальные показатели. ИМХО, нужна плашка — "Использовать с осторожностью!"

mnv 29 янв 2019 в 13:53

Да, любой инструмент можно использовать с пользой для дела, либо вовред. Забыл, кстати, добавить, что мы его используем для удаленной разработки взамен, на мой взгляд, довольно диких инструментов типа слежки за монитором.

Мне не важно в какое время человек работает и насколько интенсивно нажимает на клавиши. Некоторые задачи предполагают мыслительную активность, при которой вообще лучше отойти от компа. Благодаря этому инструменту, как я считаю, нам удается соблюсти баланс между доверием и контролем.

SbWereWolf 29 янв 2019 в 17:49

Вся система держиться на доверии тем числам которые разрабы впишут в графу «затраченное время»?
Есть где то контроль что в сутки по всем задачам было затрачено не более 24 часов?

Шикарный инструмент конечно. Просто пользовательскому вводу сложно верить, хочется его как то валидировать.

mnv 29 янв 2019 в 18:12

Перед передачей задачи в разработку мы ее оцениваем вместе с разработчиками. В Gitlab для этого в комментарии к задаче пишем /estimate 5h — значит оценка задачи 5 часов. Потом по завершении работы над задачами проводим сверку, и при проведении ретроспективы спринта обсуждаем случаи, когда фактическое время значительно превысило расчетное.

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

SbWereWolf 30 янв 2019 в 09:39

тогда ок.

Valsha 29 янв 2019 в 21:30

Да, все на чесном слове.
А не лучше использовать что то типа wakatime.com/intellij-idea-time-tracking
В данном случае есть плагины на все современные IDE и они ведут учет времени.
Хотя конечно же спасибо вам за вашу разработку, полезная вещь. Хотя конечно же хотелсь бы больше контроля над «кол-вом реально потреченого времени».
Спасибо, звёздочку на Github поставил :)

mnv 29 янв 2019 в 22:08

Я не пробовал. С виду хороший вариант. По описаниям правда не понял как учитываются случаи, когда надо отойти от IDE и подумать над решением, время, потраченное на созвоны, обсуждения. В моем случае еще важно считать балансы и делать выгрузки по спринтам, мне это экономит прилично времени.