Gitlab для лидов

Что такое Gitlab?

Это платформа для управления проектами и репозиториями, работающая с системой версий Git. Она позволяет команде работать над кодом вместе, объединяя инструменты для управления кодом, проектами и выполнением DevOps-задач.

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

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

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

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

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

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

1. В любой непонятной ситуации (что-то из рабочих процессов работает неадекватно вашему ожиданию) в первую очередь сообщите в HelpDesk, потом супервайзеру проекта, потом в чат RnD проекта, потом коллегам на кухне во время обеда, далее, если позволяет NDA, близким родственникам, соседке по площадке и случайном попутчику в метро. Именно в таком порядке, не наоборот!   
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 часов решить вашу проблему, если у нас не получится решить ее в течение суток, мы перенесем задачу в гитлаб. 

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

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

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

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

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