Gitlab для лидов

Что такое Gitlab?

Это платформа для управления RnD проектами, где вы так же можете создавать, редактировать, наблюдать за сроками реализации задач, необходимых для автоматизации и совершенствования производственных процессов вашего отдела.

Например: автоматизация рутинных процессов передачи и хранения данных, исправление сложных багов в конвейере производства, создание новых и расширение функционала старых инструментов для вашего отдела.

Регламент работы с Gitlab и взаимодействия с RnD отделом.

Инициатором создания и формализации (описание ТЗ) задачи в первую очередь является лид отдела.
Создание задачи и ТЗ к нему непосредственно в среде Gitlab, может осуществляться как лидом отдела, так и менеджером RnD разработки с обязательным уведомлением супервайзера проекта об этой задаче. Ответственность за актуализацию ТЗ лежит на лиде отдела, весь период, до завершения всех этапов (разработка, тестирование, внедрение) решения задачи. Так же в ответственности лида регулярное (минимум раз в неделю) посещение ресурсов Gitlab, для актуализации состояния задач его отдела. Для удобства актуализации и понимания сроков выполнения задач, RnD делают интерактивный гант, пока бета, не судите строго. Сроки реализации задачи устанавливаются супервайзером проекта исходя из производственной целесообразности, потребностей всех отделов, ресурсов RnD отдела.

Порядок создания, ведения и завершения типовой задачи для RnD.

1. Формулировка, краткое описание ТЗ, производственные материалы для тестирования (если есть), желаемый срок реализации передаются лидом менеджеру RnD
2. Менеджер RnD, обязан в срок не более 2-х рабочих дней разместить задачу на платформе Gitlab с последующей передачей ссылки на задачу лиду отдела и супервайзеру проекта. (для ускорения этого этапа, лид может разместить задачу самостоятельно, но тогда ссылку супервайзеру и менеджеру RnD передает он). 
3. Лид приглашается на собрание RnD для уточнения деталей задачи (опционально).
4. Супервайзер определяет приоритет и срок реализации задачи, он может отличаться от желаемого, супервайзер исходит из производственной целесообразности и потребностей всех отделов проекта.
5. Лид регулярно (минимум раз в неделю) проверяет статусы задач своего отдела в Gitlab или Gant. В случае изменения производственной обстановки, лид оперативно вносит правки в ТЗ с уведомлением менеджера RnD и супервайзера или сообщает о неактуальности задачи и необходимости ее досрочного закрытия.
6. После завершения итерации разработки, результат передается на тестирование.
7. Менеджер RnD заводит в ftrack задачу на тестирование, определяет сроки (по умолчанию 3 рабочих дня) и назначает исполнителем лида отдела.
8. Лид может самостоятельно провести тестирование, либо переназначить исполнителем сотрудника своего отдела.
9. Результатом тестирования должна быть видеозапись экрана произведенная во время тестирования, а так же ссылка на материалы (проект графического софта например) в которых проводилось тестирование, чтобы разработчики RnD могли воспроизвести условия тестирования повторно на своей стороне, в случае неудачи. Если тестирование неуспешно - возвращаемся в п. 6
10. Если тестирование прошло успешно, лид используя dev версию приложения Ярко, передает задачу на тестирование максимально возможному числу сотрудников отдела для поиска ошибок у разных пользователей.
    
11.  Если все прошло успешно, задача закрывается в ftrack и Gitlab менеджером RnD

Порядок создания, ведения и завершения экстренной/блокирующей задачи RnD (если что-то сломалось).

1. В случае чрезвычайной ситуации на пайплайне (что-то из рабочих процессов работает неадекватно вашему ожиданию, например публикация работы происходит не с первого раза или вообще перестала работать все факты важно фиксировать) в первую очередь сообщите в HelpDesk, потом супервайзеру проекта, потом в чат RnD проекта, потом коллегам на кухне во время обеда.  Именно в таком порядке, не наоборот!   
2. RnD регистрирует заявку в структуре Zammad. У них есть 4 рабочих часа на исправление проблемы.
3. Если в чате HelpDesk вам задают уточняющие вопросы, просят проверить различные способы решения проблемы, у вас есть 1 час, чтобы оперативно ответить и провести тесты. Если вы по каким-то причинам не можете оперативно отвечать - подключите в коммуникацию вашего заместителя или сотрудника отдела (пусть напишет в HelpDesk от своего имени).
4. Если по истечении 4 часов проблема не была решена, она формируется в задачу вашего отдела в Gitlab. В чате HelpDesk вам должны скинуть ссылку на задачу в гите. Если не скинут - сообщите супервайзеру проекта.
5. Далее задача решается тем же путем, что и типовая, начиная с п.4

Как посмотреть задачи своего отдела

1. Рядом с лисичкой на стартовой странице через выпадающие меню переходим в группу RnD

2. Далее снова через выпадающее меню идем в раздел доски с карточками

3. Вы попадете на доску, где видны карточки по всем отделам и проектам

4. Нужно в поисковой строке фильтром выбрать свой проект и отдел

Label важно прописывать как он указан в гитлабе, он чувствителен к регистру или можно просто щелкнуть на один из лейблов, которые уже есть на доске

5. Теперь мы видим карточки задач только своего проекта и отдела

Что означают колонки

Open - наши черновики задач, где мы накидываем идеи по задачам прежде, чем взять в работу

To Do - задачи запланироанные для выполнения

In Progress - задачи уже в работе

Done - задачу закончил выполнять разработчик, но требуется ее проверить/донастроить

Testing - задачи в тестировании

Closed - закрытые/выполненные задачи

Что видно в карточке задачи

В карточке видно название, описание, исполнитель, дата выполнения и лейблы задачи, а также комментарии по задач

Какие бывают лейблы

Лейблы показывают принадлежность задачи к проекту, статус ее разработки (колонку), отдел от которого пришла задача (может быть несколько) и приоритетность

Как ставится приоритетность

Есть три лейбла приоритетности: High, Medium, Low, Blocker
Их определяет лид исходя из важности для своего отдела, а затем мы обсуждаем и утверждаем на РнД собрании
От приоритета зависит очередность, в которой мы будем брать задачи по отелу. Важно не ставить везде High, и подходить к приоритизации рационально. Blocker - означает, что мы полностью встали на производстве без этой задачи. Такую приоритетность может поставить только супервайзер.

Что должно быть в задаче

1. Цель: для чего мы делаем задачу
2. Описание: что нам нужно сделать для достижения цели задачи, что нам важно учесть, какие есть пожелания и ограничения. Можно уточнить детали технической реализации, если они известны
3. Тестовый сценарий: описание корректного поведения наработки по задаче (в идеале пошаговый с описанием результата после каждого шага)

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

Проставление и актуализация приоритета

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

Схема взаимодвействия Helpdesk - Gitlab

Если вы столкнулись с багами в существующих разработках. Первое место, куда следуем о них сообщить - наш бот помощи: @yarko_helpdesk_bot. Мы постараемся в течение 24 часов решить вашу проблему, если у нас не получится решить ее в течение суток, мы перенесем задачу в гитлаб. 

Схема тестирования

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

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

Сроки по задачам

Когда вы передаете задачу в отдел РнД, важно также указать срок, в который задачу нужно вам отдать. Мы оценим этот срок по необходимости совместно с супервайзером и поставим на карточке задачи срок, которого будем придерживаться. Если срок вам не подходит, то можно обсудить его с супервайзером и при возхможности мы поднимием задачи приоритетность, и постараемся сократить срок. (Обычно для этого необходимо приостановить работу над другими задачами)