test:test - Genraim/wiki-test GitHub Wiki

Мы используем трекер задач и Slack. Здесь пойдет речь про трекер задач/issue tracker и процесс разработки.

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

На текущий момент менеджером проекта является Алексей Егармин @genraim

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

Чеклист оформления задач

Спринт

Спринт -- итерация в разработке проекта, жестко фиксированная по времени. Длительность наших спринтов -- 2 недели. Спринт успешно завершен, если все задачи из него выполнены.Нужно внимательно и аккуратно выбирать и формулировать задачи, а также критерии их выполненности. Кроме того, по окончанию спринта должна быть реализована новая самоценная функциональность. Ценная задача, это когда что-то едет, двигается, мониторится. Выполняет конкретную задачу, лишает вас конкретной проблемы.

“Написать еще 3 класса в супер ооп-стиле, чтобы можно было потом переиспользовать” -- это пример антиценной задачи. “Код некрасивый” -- это не конкретная проблема, а вот 3 часа, уже потраченные на “чтобы было красиво” -- проблема. “Я потом потрачу много времени на изменение этого кода” -- это вообще не проблема, ибо это лишь ваш домысел. Не решайте во время спринтов вымышленные проблемы.

Каждый спринт начинается в 00:00 YEKT и завершается через 2 недели в 23:59 YEKT, потом двое суток перерыва -- и снова в спринт. В ходе спринта не менее одного раза происходит общение с руководителем проекта о ходе выполнения взятых задач. По окончании спринта происходит анализ и публичное обсуждение результатов.

Самое важное. Не участвовать в спринте -- это НОРМАЛЬНО! Если вы знаете, что за в эти 2 недели будет важный экзамен, или что-то, что помешает вам потратить 10 часов на работу в лаборатории -- пропустите спринт.

Самый страшный грех -- это если вы берёте спринт и не выполняете его. Это адский дизреспект от команды(многие планируют пользоваться результатами вашего спринта). Не делайте так. Гораздо лучше сделать маленькую задачу, чем “я почти закончил, осталось отдебажить” огромную крутую задачу. Длинный путь начинается с шага; человек, передвинувший гору, делал это по камешку и всё такое.

Ишью

Бэклог

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

Излагайте свои мысли в бэклог, даже если это не ваша задача, так вы поможете себе и вашим коллегам узнать об актуальных проблемах в проекте.

Оформление задач

Общий ишью-трекер находится здесь: трекер

В специальный двухдневный период продумайте задачи, над которыми вы будете работать в спринте. Задачи должны быть самодостаточными (Пример: Сделать proof-of-concept навигации по ИК-маякам, которая может …. !). Разделите задачу на несколько тикетов. Хороший тикет четко формализован (понятен его смысл, понятно как его выполнить, понятны критерии выполненности задачи) и должен выполнятся за 1-2 часа непрерывной работы над ним.

Старайтесь писать тикеты, так чтобы они были короткими и понятными. Не пытайтесь объединить десять задач в одну.

Так как тикет подразумевает некоторое действие для его выполнения, заголовок скорее всего должен содержать глагол или отглагольное существительное (Например: Выпилить шестеренку для колеса. Изготовление ракеты. Написать на вики про сборку опенсиви). Проставьте теги (лейблы), соответствующие тикету. Если вы считаете, что нужного тега не хватает -- добавьте тег, нам не жалко ;)

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

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

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

Выполнение задач

Назначайте себе задачи в проекте, так вся команда знает, что это задание выполняете вы.

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

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

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

Если вам нужно писать код

Общее правило: одна ишью - одна ветка от master в репозитории. После того, как вы считаете задачу сделанной, код проходит ревью хотя бы у одного члена команды для увеличения bus-factor. Ревьювер оставляет комментарии по коду прямо в коде, в виде коммитов с префиксом CR @ ваш ник. После исправлений код вливается в master (если вам не хватает прав, следует использовать механизм Merge Request). После этой процедуры ветка удаляется, а ишью закрывается.

Маилстоун

Milestone -- важная, крупная задача, которая не укладывается в спринты и может выполняться не одним человеком. Имеет важное значение для всего проекта, поэтому создавать milestone могут люди с уровнем доступа не ниже Master. Маилстоун включает в себя множество других задач, выполнение которых приведет к выполнению маилстоуна. Для маилстоуна можно установить дедлайн, в этом случае дедлайн ишью не может превышать дедлайна маилстоуна. Если вы считаете, что для вашей задачи нужен маилстоун, обратитесь к человеку, имеющему соответствующий уровень доступа и убедите его в том что это необходимо.