Здравствуй. Я 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 Заглянул в публикацию и обнаружил не мало минусов. Когда ставите минус, не поленитесь прокомментировать, мне интересна обратная связь.
