Здравствуй. Я Gitpab. Рад знакомству. Меня сделали для того, чтобы легче было надзирать за программистами. Я беру часы, которые разработчики отметили в Gitlab, и подсчитываю, кто сколько затратил времени на работы по задачам. И по проекту в целом. Поговаривают, что большие начальники с моей помощью считают зарплату прогеров и рентабельность проектов. И это действительно так. Еще с моей помощью можно повысить маржинальность софтверных проектов. А сейчас я расскажу, чем могу быть полезен твоей команде и тебе лично.
Я работаю без выходных и перерывов на сон и обед. Звучит жутковато, но ты можешь в этом убедиться, развернув меня на своем сервере. Благо в ридми есть инструкции как это сделать.
Не забудь в конфиге прописать проекты, за которыми мне надлежить следить. Я буду раз в час заглядывать в Gitlab и забирать оттуда свежачок — новые спринты, задачи, комменты, списанное время, информацию об участниках.
Забегая вперед скажу, что сам я выгляжу вот так:
Это мой дашборд, тут видны основные показатели. Наиболее интересный из них — Баланс. Он отражает сколько часов разработчику авансировали, либо наоборот должны оплатить на данный момент.
Но теперь давай по порядку. Я неспроста решил рассказать о себе. Дело в том, что я лично повидал довольно много разных проектов и разных проджект менеджеров. Ничего личного, просто давай я сперва расскажу про методику, мать нашу.
Сам я сторонник Scrum. Потому что Scrum — это худшая из методик за исключением всех остальных. Сейчас я сюда скопипащу наш внутренний документ, который в обязательном порядке читают наши новые сотрудники.
Короткая инструкция, но она помогает выстроить Scrum в моих проектах. В ней не сказано кое о чем. Давай я сейчас придумаю даже какой-нибудь модный термин для этого. Во! IED. Круто, правда? IED. Iron Eggs Discipline. Дисциплина Железных Яиц. Без должного внимания к процессу разработки заглохнет любая инструкция с проектом вместе.
Команды, за деятельность которых несет ответственность автор статьи, состоят из нештатных сотрудников — все работают с оплатой за время, уделенное проектам. Надо сказать, что качественно управлять такими командами — дело несколько ювелирное. Чем больше команда, тем сложнее уследить за ней. А моментов, за которыми надо следить, не мало.
Я, Gitpab, отвечаю на все эти тонкие вопросы, попутно решаю и другие задачи.
Один только этот отчет чего стоит. Тут можно отфильтровать списанное время по нужному критерию.
Давай-ка я расскажу одну историю. Однажды мы неумолимо двигались к дедлайну. Проект делали качественно и ответственно, все шло хорошо, и мы уже завершили работу над задачами, как вдруг за неделю до дедлайна нам прислали 63 замечания. Нюансы отношений Бла-ародных Донов директоров были таковы, что надо было закрыть эти задачи обязательно за неделю, чтобы нам не отсрачивали оплату. Нельзя сказать, что эти задачи были жутко сложными, это были замечания на “вылизывание” системы. Но мы делали задач по 20 за спринт. Максимум, на что хватало команды за всю историю проекта — это около 40 задач в неделю. Как выполнить в полтора раза больше-то? По оценке задачи тянули на пару недель.
Но вот родилась мысль. У команды был я, Gitpab. Поэтому владельцу бюджета автор предложил на этой решающей неделе увеличить всем ставку в полтора раза при условии, что эта ставка будет распространяться именно на эти замечания. Всем этим задачам присвоили отдельный лейбл в Gitlab и начали кодить. Думаю можно и похоливарить такое решение, но оно было хорошо преподнесено команде. И все 63 задачи были закрыты за недельный спринт. Серьезно. 63 и качественно.
Для расчета премий просто отфильтровали по каждому участнику списанное время по этому лейблу за период.
Зачем оценивать задачи? Во-первых, как было сказано выше, чтобы не набирать в спринт лишнего. Я сторонник взять задач столько, сколько команда железно успеет выполнить. А если останется время, взять в процессе еще что-то в работу. Так команда выгоднее смотрится перед заказчиком, потому что дает реальные обещания, которые соблюдает, и даже делает чуть больше чем пообещала.
Но есть и другие причины. Еще одна история. В команде был разработчик, который стремился списывать на задачи время больше, чем оно того стоит. Причем иногда в 5, а иногда и в 10 раз больше. Автору это не очень-то нравилось. Но и разработчик этот, надо сказать, устраивал всем кроме этого нюанса. Конфликтовать или устраивать разборки не было никакого желания. В то время мы оценивали не все задачи. В Gitpab не сложно было увидеть, что много времени списывалось только на неоцененные задачи. Стали оценивать все задачи без исключения и это помогло.
А я, Gitpab, предоставляю тебе инструмент для сверки оцененного и реально затраченного времени на задачи.
Я попутно экономлю время на подготовку отчетов о проделанных работах за спринт. Вот смотри, открываешь спринт, а там уже готовый отчет. Просто запушь новый тег в Gitlab и скопируй туда описание из спринта. Оно уже в Markdown.
Скопипастили в Gitlab:
Заказчики признают, что приятно иметь дело с командой, которая пускает в свой Gitlab в процессе выполнения проекта, да еще и дает подробные еженедельные отчеты о проделанных работах.
А некоторые деловитые заказчики, бывает, просят какие-тобезумные бесподобные списки задач со статусами их выполнения. В таких случаях очень удобно завести какой-нибудь отдельный лейбл для такого списка и время от времени выгружать эти задачи, отфильтрованные по лейблу. Просто жми кнопку ”Экспортировать в csv”. Дружище, знал бы ты сколько времени это порой экономит…
Каждому участнику проекта можно указать ставку за час работ:
Пользователь с правами на финансы видит этот раздел вместе с балансами. Балансы тут в часах — сколько часов предоплачено (зеленый). Либо сколько часов надо оплатить (красный). Удобненько, правда?
Но это еще не всё. При проставлении ставки можно задать издержки — сколько надо доплатить, чтобы человек получил свою ставку именно на руки. Для каждого это свой процент.
Подождите, это еще не всё. Есть интерфейс для внесения платежей. Тут видна история платежей, оплаченных часов.
А при внесении оплаты автоматически считаются оплаченные часы с учетом издержек.
Если у тебя сотрудники в штате на фиксе, то резонный вопрос — зачем эта заморочка с ведением оплат? Согласен, тебе это не надо. Но если у тебя люди на почасовой ставке, то такой инструмент очень кстати. Тебе при выплатах не придется строить отчеты о затраченном времени, искать, на чем закончился отчёт в прошлый раз. И уже не возникнет путаницы, ты не захватишь случайно уже оплаченные ранее работы. И не пропустишь не оплаченное время.
Теперь всё, что тебе нужно — посмотреть баланс сотрудника и закинуть человеку достаточно денег для того, чтобы сделать его баланс зелёненьким.
Раз у тебя теперь есть цифры по каждой задачке, то не хитро посчитать их сумму. Благодаря этому ты поймешь, не выходит ли проект за рамки бюджета:
Аналогичная статистика строится и по спринтам.
Декомпозировать задачи, следить за выполнением, координировать команду, да плюс к этому еще и все, что описано выше… можно подумать, отнимает массу времени. Безусловно, это съедает время. Но это куда лучше, чем безконтрольно плывущий проект. Не сделай мой автор меня, он стал бы уже пропащим менеджером, забывшим как выглядит IDE (не путать с IED, см. выше). А благодаря мне он успевает шпарить код ничуть не меньше коллег по цеху.
Выше описана методика и как я могу помочь тебе следовать ей, используя Gitlab в связке с Gitpab. Это хорошо работает в случае с автором. Возможно, ты захочешь что-то поменять под себя. Нет проблем, меняй, подстраивай под себя. В конце концов, наверняка у тебя цель — выполнять проекты качественно и извлекать из них прибыль, а я, Gitpab — всего лишь подмога тебе в этом.
Кстати, меня создал один хороший дядя, автор этой статьи. Он был так добр, что сделал меня опенсурсным. Я буду рад звёздочке на Github.
Чуть не забыл о самом главном. Я — инструмент. А один мой знакомый успешный предприниматель и простой русский миллиардер поговаривает, что инструменты не работают. Работают люди. Надеюсь ты понял о чем я. Пользуйся, я к твоим услугам. Успешных проектов.
ps Заглянул в публикацию и обнаружил не мало минусов. Когда ставите минус, не поленитесь прокомментировать, мне интересна обратная связь.
Как я работаю
Я работаю без выходных и перерывов на сон и обед. Звучит жутковато, но ты можешь в этом убедиться, развернув меня на своем сервере. Благо в ридми есть инструкции как это сделать.
Не забудь в конфиге прописать проекты, за которыми мне надлежить следить. Я буду раз в час заглядывать в Gitlab и забирать оттуда свежачок — новые спринты, задачи, комменты, списанное время, информацию об участниках.
Забегая вперед скажу, что сам я выгляжу вот так:
Это мой дашборд, тут видны основные показатели. Наиболее интересный из них — Баланс. Он отражает сколько часов разработчику авансировали, либо наоборот должны оплатить на данный момент.
Но теперь давай по порядку. Я неспроста решил рассказать о себе. Дело в том, что я лично повидал довольно много разных проектов и разных проджект менеджеров. Ничего личного, просто давай я сперва расскажу про методику, мать нашу.
Проект в Gitlab
Сам я сторонник Scrum. Потому что Scrum — это худшая из методик за исключением всех остальных. Сейчас я сюда скопипащу наш внутренний документ, который в обязательном порядке читают наши новые сотрудники.
Методика
Основной инструмент для ведения спринта — доска (Board).
На доске несколько колонок. В каждой колонке задачи идут в порядке убывания приоритета. У задач, находящихся вверху списка, приоритет выше. Соответственно, брать в работу нужно задачи начиная с верхних.
Каждая задача должна быть оценена перед началом разработки. Для этого в комментарии к задаче необходимо указать, например
Оценки используются для того, чтобы корректно спланировать спринт и не набрать в него слишком много задач.
Чтобы отметить время, затраченное на задачу, например, 1.5 часа, необходимо написать комментарий к задаче в формате
Это сообщение необходимо указывать именно комментарием к задаче (не в теле задаче или где-то еще), в таком случае это время попадет в отчеты о затраченном времени.
Отчеты о затраченном времени находятся в Gitpab.
Спринты планируются в Milestones.
Когда задача переносится в Closed, автоматически увеличивается процент выполнения спринта.
Релизы помечаются тегом формата 0.0.5 в стиле SemVer. К тегу добавляется описание, которое является ченджлогом.
Каждая задача должна решаться в отдельной ветке от master. Название ветки в формате
Каждый коммит должен содержать одно небольшое логически завершенное изменение.
Если задача получается объемной, то она не должна быть оформлена одним коммитом. Вместо этого задача должна оформляться множеством коммитов. Каждый коммит не обязательно должен быть рабочим. Финальный вариант, который будет мержиться в master, должен быть рабочим.
В случае, когда задача простая и решается одним коммитом, в комментарий к коммиту достаточно написать номер задачи через решетку. Пример: #452.
Если задача объемная и делится на множество коммитов, то желательно после номера задачи указывать небольшое пояснение. Пример: #493 cascade delete document files.
Перед мержем ветки с задачей в master необходимо примержить master ветку к ветке с задачей и отправить задачу на код ревью/тестирование.
Доска
Основной инструмент для ведения спринта — доска (Board).
На доске несколько колонок. В каждой колонке задачи идут в порядке убывания приоритета. У задач, находящихся вверху списка, приоритет выше. Соответственно, брать в работу нужно задачи начиная с верхних.
- В Backlog представлены задачи, которые в ближайшее время еще не идут в разработку. Из этих задач мы формируем спринты в Milestones.
- To Do. Задачи текущего спринта переносятся в колонку To Do при старте спринта.
- Doing. Когда разработчик начинает работу над задачей, он ее переносит из To Do в Doing. При этом создает отдельную ветку от свежей ветки master. Название ветки должно совпадать с номером задачи.
- Code review. Когда задача выполнена и разработчик уверен, что все ок, он примерживает в ветку задачи текущую master ветку и переносит задачу в колонку Code review. Тим лид проверяет задачи из колонки Core review и, если все ок, мержит ветку с задачей в master, и переводит задачу в колонку Test.
- Test. Тестировщик проверяет работоспособность по задачам из колонки Test. И если все ок, то закрывает их (переносит в Closed).
- Closed. Это задачи, которые полностью завершены и больше не требуют внимания разработчиков. Они не обязательно находятся в продакшне у заказчика, но уйдут туда с ближайшим релизом.
Время
Каждая задача должна быть оценена перед началом разработки. Для этого в комментарии к задаче необходимо указать, например
/estimate 5hОценки используются для того, чтобы корректно спланировать спринт и не набрать в него слишком много задач.
Чтобы отметить время, затраченное на задачу, например, 1.5 часа, необходимо написать комментарий к задаче в формате
Описание работы
/spend 1h 30mЭто сообщение необходимо указывать именно комментарием к задаче (не в теле задаче или где-то еще), в таком случае это время попадет в отчеты о затраченном времени.
Отчеты о затраченном времени находятся в Gitpab.
Спринты
Спринты планируются в Milestones.
Когда задача переносится в Closed, автоматически увеличивается процент выполнения спринта.
Релизы и релиз ноты
Релизы помечаются тегом формата 0.0.5 в стиле SemVer. К тегу добавляется описание, которое является ченджлогом.
Требования к коммитам
Каждая задача должна решаться в отдельной ветке от master. Название ветки в формате
<Номер задачи>. Пример: 443.Каждый коммит должен содержать одно небольшое логически завершенное изменение.
Если задача получается объемной, то она не должна быть оформлена одним коммитом. Вместо этого задача должна оформляться множеством коммитов. Каждый коммит не обязательно должен быть рабочим. Финальный вариант, который будет мержиться в master, должен быть рабочим.
В случае, когда задача простая и решается одним коммитом, в комментарий к коммиту достаточно написать номер задачи через решетку. Пример: #452.
Если задача объемная и делится на множество коммитов, то желательно после номера задачи указывать небольшое пояснение. Пример: #493 cascade delete document files.
Перед мержем ветки с задачей в master необходимо примержить master ветку к ветке с задачей и отправить задачу на код ревью/тестирование.
Что не хватает
Короткая инструкция, но она помогает выстроить Scrum в моих проектах. В ней не сказано кое о чем. Давай я сейчас придумаю даже какой-нибудь модный термин для этого. Во! IED. Круто, правда? IED. Iron Eggs Discipline. Дисциплина Железных Яиц. Без должного внимания к процессу разработки заглохнет любая инструкция с проектом вместе.
Чем полезен я, Gitpab
Команды, за деятельность которых несет ответственность автор статьи, состоят из нештатных сотрудников — все работают с оплатой за время, уделенное проектам. Надо сказать, что качественно управлять такими командами — дело несколько ювелирное. Чем больше команда, тем сложнее уследить за ней. А моментов, за которыми надо следить, не мало.
- Не подзавис ли кто из разработчиков?
- Не списывают ли на задачи больше чем оно того стоит?
- Выставляются ли счета именно на те работы, которые были выполнены за период?
- Сколько мы прямо сейчас должны разработчику? А всем разработчикам в целом?
- Не выходим ли за рамки бюджета по проекту?
Я, Gitpab, отвечаю на все эти тонкие вопросы, попутно решаю и другие задачи.
Списанное время
Один только этот отчет чего стоит. Тут можно отфильтровать списанное время по нужному критерию.
Давай-ка я расскажу одну историю. Однажды мы неумолимо двигались к дедлайну. Проект делали качественно и ответственно, все шло хорошо, и мы уже завершили работу над задачами, как вдруг за неделю до дедлайна нам прислали 63 замечания. Нюансы отношений Бла-ародных Донов директоров были таковы, что надо было закрыть эти задачи обязательно за неделю, чтобы нам не отсрачивали оплату. Нельзя сказать, что эти задачи были жутко сложными, это были замечания на “вылизывание” системы. Но мы делали задач по 20 за спринт. Максимум, на что хватало команды за всю историю проекта — это около 40 задач в неделю. Как выполнить в полтора раза больше-то? По оценке задачи тянули на пару недель.
Но вот родилась мысль. У команды был я, Gitpab. Поэтому владельцу бюджета автор предложил на этой решающей неделе увеличить всем ставку в полтора раза при условии, что эта ставка будет распространяться именно на эти замечания. Всем этим задачам присвоили отдельный лейбл в Gitlab и начали кодить. Думаю можно и похоливарить такое решение, но оно было хорошо преподнесено команде. И все 63 задачи были закрыты за недельный спринт. Серьезно. 63 и качественно.
Для расчета премий просто отфильтровали по каждому участнику списанное время по этому лейблу за период.
Оценки задач
Зачем оценивать задачи? Во-первых, как было сказано выше, чтобы не набирать в спринт лишнего. Я сторонник взять задач столько, сколько команда железно успеет выполнить. А если останется время, взять в процессе еще что-то в работу. Так команда выгоднее смотрится перед заказчиком, потому что дает реальные обещания, которые соблюдает, и даже делает чуть больше чем пообещала.
Но есть и другие причины. Еще одна история. В команде был разработчик, который стремился списывать на задачи время больше, чем оно того стоит. Причем иногда в 5, а иногда и в 10 раз больше. Автору это не очень-то нравилось. Но и разработчик этот, надо сказать, устраивал всем кроме этого нюанса. Конфликтовать или устраивать разборки не было никакого желания. В то время мы оценивали не все задачи. В Gitpab не сложно было увидеть, что много времени списывалось только на неоцененные задачи. Стали оценивать все задачи без исключения и это помогло.
А я, Gitpab, предоставляю тебе инструмент для сверки оцененного и реально затраченного времени на задачи.
Отчеты для заказчика
Я попутно экономлю время на подготовку отчетов о проделанных работах за спринт. Вот смотри, открываешь спринт, а там уже готовый отчет. Просто запушь новый тег в Gitlab и скопируй туда описание из спринта. Оно уже в Markdown.
Скопипастили в Gitlab:
Заказчики признают, что приятно иметь дело с командой, которая пускает в свой Gitlab в процессе выполнения проекта, да еще и дает подробные еженедельные отчеты о проделанных работах.
А некоторые деловитые заказчики, бывает, просят какие-то
Денежки
Каждому участнику проекта можно указать ставку за час работ:
Пользователь с правами на финансы видит этот раздел вместе с балансами. Балансы тут в часах — сколько часов предоплачено (зеленый). Либо сколько часов надо оплатить (красный). Удобненько, правда?
Но это еще не всё. При проставлении ставки можно задать издержки — сколько надо доплатить, чтобы человек получил свою ставку именно на руки. Для каждого это свой процент.
Подождите, это еще не всё. Есть интерфейс для внесения платежей. Тут видна история платежей, оплаченных часов.
А при внесении оплаты автоматически считаются оплаченные часы с учетом издержек.
Если у тебя сотрудники в штате на фиксе, то резонный вопрос — зачем эта заморочка с ведением оплат? Согласен, тебе это не надо. Но если у тебя люди на почасовой ставке, то такой инструмент очень кстати. Тебе при выплатах не придется строить отчеты о затраченном времени, искать, на чем закончился отчёт в прошлый раз. И уже не возникнет путаницы, ты не захватишь случайно уже оплаченные ранее работы. И не пропустишь не оплаченное время.
Теперь всё, что тебе нужно — посмотреть баланс сотрудника и закинуть человеку достаточно денег для того, чтобы сделать его баланс зелёненьким.
Бюджет проекта
Раз у тебя теперь есть цифры по каждой задачке, то не хитро посчитать их сумму. Благодаря этому ты поймешь, не выходит ли проект за рамки бюджета:
Аналогичная статистика строится и по спринтам.
Эй, Gitpab, а когда твой автор успевает работать?
Декомпозировать задачи, следить за выполнением, координировать команду, да плюс к этому еще и все, что описано выше… можно подумать, отнимает массу времени. Безусловно, это съедает время. Но это куда лучше, чем безконтрольно плывущий проект. Не сделай мой автор меня, он стал бы уже пропащим менеджером, забывшим как выглядит IDE (не путать с IED, см. выше). А благодаря мне он успевает шпарить код ничуть не меньше коллег по цеху.
Подытожу-ка
Выше описана методика и как я могу помочь тебе следовать ей, используя Gitlab в связке с Gitpab. Это хорошо работает в случае с автором. Возможно, ты захочешь что-то поменять под себя. Нет проблем, меняй, подстраивай под себя. В конце концов, наверняка у тебя цель — выполнять проекты качественно и извлекать из них прибыль, а я, Gitpab — всего лишь подмога тебе в этом.
А теперь печеньку в студию
Кстати, меня создал один хороший дядя, автор этой статьи. Он был так добр, что сделал меня опенсурсным. Я буду рад звёздочке на Github.
Чуть не забыл о самом главном. Я — инструмент. А один мой знакомый успешный предприниматель и простой русский миллиардер поговаривает, что инструменты не работают. Работают люди. Надеюсь ты понял о чем я. Пользуйся, я к твоим услугам. Успешных проектов.
ps Заглянул в публикацию и обнаружил не мало минусов. Когда ставите минус, не поленитесь прокомментировать, мне интересна обратная связь.
Комментарии (22)
i360u
29.01.2019 13:41+1Эта штука может как оказаться очень полезной, так и полностью убить процесс а то и команду при "умелом использовании" в рамках "эффективного менеджмента". Потому, что может перевести фокус команды с самих задач непосредственно, на формальные показатели. ИМХО, нужна плашка — "Использовать с осторожностью!"
mnv Автор
29.01.2019 13:53+1Да, любой инструмент можно использовать с пользой для дела, либо вовред. Забыл, кстати, добавить, что мы его используем для удаленной разработки взамен, на мой взгляд, довольно диких инструментов типа слежки за монитором.
Мне не важно в какое время человек работает и насколько интенсивно нажимает на клавиши. Некоторые задачи предполагают мыслительную активность, при которой вообще лучше отойти от компа. Благодаря этому инструменту, как я считаю, нам удается соблюсти баланс между доверием и контролем.
SbWereWolf
29.01.2019 17:49Вся система держиться на доверии тем числам которые разрабы впишут в графу «затраченное время»?
Есть где то контроль что в сутки по всем задачам было затрачено не более 24 часов?
Шикарный инструмент конечно. Просто пользовательскому вводу сложно верить, хочется его как то валидировать.mnv Автор
29.01.2019 18:12+1Перед передачей задачи в разработку мы ее оцениваем вместе с разработчиками. В Gitlab для этого в комментарии к задаче пишем
/estimate 5h— значит оценка задачи 5 часов. Потом по завершении работы над задачами проводим сверку, и при проведении ретроспективы спринта обсуждаем случаи, когда фактическое время значительно превысило расчетное.
Причины бывают разные. Бывает и так, что и объективно ошибаемся с изначальной оценкой, что-то не учитываем. Тогда особых вопросов не возникает. Но об этом в процессе работы прошу сообщать коллег, чтобы не было сюрпризов под конец спринта.
Valsha
29.01.2019 21:30Да, все на чесном слове.
А не лучше использовать что то типа wakatime.com/intellij-idea-time-tracking
В данном случае есть плагины на все современные IDE и они ведут учет времени.
Хотя конечно же спасибо вам за вашу разработку, полезная вещь. Хотя конечно же хотелсь бы больше контроля над «кол-вом реально потреченого времени».
Спасибо, звёздочку на Github поставил :)mnv Автор
29.01.2019 22:08Я не пробовал. С виду хороший вариант. По описаниям правда не понял как учитываются случаи, когда надо отойти от IDE и подумать над решением, время, потраченное на созвоны, обсуждения. В моем случае еще важно считать балансы и делать выгрузки по спринтам, мне это экономит прилично времени.
Bhudh
30.01.2019 01:20<offtopic,sarcasm>
Непонятно только, почему Gitpab, а не Gitpub.
</sarcasm,offtopic>
slaFFik
Инструмент для Gitlab, который хостится на GitHub.
Напрашивается hosted-решение, SaaS. Планируется?
mnv Автор
Да, внутренние проекты на Gitlab, а опенсурсное привычнее выложить на Github. Про SaaS посмотрю по активности, если будет спрос — сделаю.
fishca
Не очень понятен принцип расчета времени разработчика, можно как-то более подробно изложить? Но на первый беглый взгляд очень даже полезный инструмент.
mnv Автор
Разработчик отмечает время, которое он провел над каждой задачей. Это встроенный механизм в Gitlab. Можно написать комментарий
/spend 3h— отметится, что человек работал над задачей 3 часа.Сам Gitlab пока не имеет механизма для подсчета затраченного времени за период каждым сотрудником.
Для этой цели Gitpab работает с API Gitlab — получает все комментарии к задачам и извлекает из них информацию о затраченном времени каждым участником.
Результат складывает в локальную базу. Далее по этим данным строит необходмые отчеты — суммирует время, попутно решает и другие задачи.
i360u
Отмечать время — это как-то уныло и напряжно, особенно при большой загрузке разработчика. Почему-бы не привязаться к git flow: считать время от создания feature-ветки до ее мерджа?
mnv Автор
Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать, особенно если решение задачи растянулось на пару дней. Если считать от создания ветки до мерджа, то получится времени больше чем ушло на задачу в реальности.
Списывать время не обязательно постоянно в течении дня. Можно и один раз в конце дня, если это будут адекватные данные.
i360u
А большая детализация тут и не нужна совсем. Хотя, если у вас к этому привязана почасовая оплата — то тоска-печаль: при такой атомизации процесса он (процесс) начинает нести дополнительные накладные издержки а менеджмент получает лишь иллюзию контроля. В любом случае, анализ затраченного времени без хорошего ретроспективного анализа — пустая трата времени и нервов.
mnv Автор
Да, ретроспективы проводить надо. Мы, например, проводим. С иллюзией не согласен, проверено на практике. Накладные расходы есть, но они не так велики, и отдача от этого — вовремя сданные проекты с хорошим качеством.
i360u
А обычно никто, у кого иллюзии, с этим не согласен. На то они и иллюзии )
mnv Автор
Предложите более удачное решение для удаленной разработки.
i360u
Очень зависит от уровня задач, размера и компетенций команды. И от лидерских качеств лидеров. Иногда достаточно смотреть на содержание коммитов, и обсуждать с командой цели и задачи. Иногда — строить графики и прогнозы на основе автоматически собранных данных (не приставая к разрабам с формальными требованиями не относящимися напрямую к написанию кода). Данных — полно: это и гит и чаты и таск-трекеры. А вот заниматься крохоборством, подсчитывать часы и минуты, тратить кучу времени на детализированные эстимейты — это дно.
mnv Автор
Вот у вас сотрудник, по сути внештатный. Что-то делал в течении месяца. Работал за этот период часов 50. Может быть и 150. Как вы будете считать сколько ему заплатить исходя из истории гита, чатов и таск трекера?
i360u
И да, удаленная разработка ничем особо не отличается по процессу от «приближенной» если этот процесс правильно выстроен, т.е. участники не сидят по отдельным «черным ящикам».
SirEdvin
Позадачная оплата, например.