final-task

Курсовой проект

Подготовка со стороны школы к выполнению курсового проекта

1. Перед выполнением курсового проекта все студенты, у которых не выполнены три последних задания подряд, отчисляются как неактивные.

2. Процесс распределения по командам полностью автоматизирован и будет проходить через https://rss-teams.web.app

3. По желанию студенты самостоятельно могут объединяться в группы. В каждой группе 3 студента.

4. Чтобы позиция в скоре более объективно отображала уровень подготовки студентов, нужно попросить менторов перед распределением студентов по группам выставить баллы за все таски, кроме последнего. Баллы за последний перед курсовым проектом таск до момента распределения студентов по группам в скор не добавляются.

Организация командной работы

Распределение студентов по группам

1. Студенты курса регистрируются в https://rss-teams.web.app , тем самым подтверждая своё желание и готовность участвовать в выполнении курсового проекта.

2. Формирование групп происходит либо по желанию студентов, либо рандомно.

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

Задачи ментора

1. Выступает куратором команды – организует и проводит первый митинг с командой.

2. Помогает распределить обязанности, разбить каждую функциональность на подзадачи для каждого члена команды.

3. Помогает студентам решать возникающие проблемы, даёт рекомендации, замечания, советы.

4. Проводит code review.

5. Выступает как координатор, стратег, организатор. Передаёт студентам свой опыт разработки, принятые в продакшене best practices.

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

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

Тим лид команды

1. По умолчанию тим лидом команды является участник с самым высоким скором. По взаимной договорённости он может передать свои обязанности другому участнику команды.

2. Тим лид координирует деятельность команды, занимается распределением задач, планированием, а также разрешает спорные ситуации между участниками команды.

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

Каналы связи

1. Тим лид команды создаёт сервер в Discord, оставляет ссылку на него в таблице рядом со списком своей группы, приглашает на созданный сервер участников своей группы или они сами к нему присоединяются.

В Discord создаются каналы

• all (для всех общий)
• materials (полезные ссылки)
• git (вопросы по гиту)
• work-status (раздел для ежедневного отчета каждого участника команды)

2. Сервер в Discord является основным каналом связи группы. Для видео- или аудио-конференций могут использоваться голосовой канал в Discord, Skype, Telegram и т.д.

Первый митинг

1. Проводится на следующий день после распределения по командам. Время и форма проведения митинга оговариваются заранее. Итоги митинга желательно зафиксировать в письменном виде.

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

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

4. Тим лид создаёт приватный репозиторий, в который приглашает всех участников своей команды. Также тим лид создаёт базовую конфигурацию проекта: устанавливает и настраивает webpack, eslint, eslint-config-airbnb-base, babel, gitignore и другие необходимые зависимости.

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

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

Работа с репозиторием

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

2. Ветка master – это основная production ветка: в ней находятся только финальные релизы проекта – то, что можно предложить пользователям (в нашем случае – то, что подлежит проверке). До самого окончания разработки ветка master пустая, содержит только файл README.md. В конце разработки или при наступлении дедлайна в ветку master мержим ветку develop.

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

4. Каждый участник команды, и тим лид команды в том числе, ведут разработку в своих собственных ветках. Название ветки даётся в соответствии с реализуемой частью функциональности. Данные ветки создаются при начале разработки каждой фичи от develop (актуальной на тот момент). Все мержи в ветку develop происходят только через Pull Request. Для того, чтобы разрешить merge conflicts, нужно смержить ветку develop в свою feature ветку.

5. Ветка считается готовой к мержу в develop, если все комментарии помечены как resolved и как минимум два члена команды поставили approve. Resolve комментария может делать только тот человек, который его оставил.

6. После разрешения на мерж, каждый сам мержит свой Pull request. Если требуется – разрешает конфликты. Это очень важный опыт.

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

8. От каждого участника команды ожидается минимум пять коммитов и минимум два собственных Pull Request, замерженых в ветку develop. Если требования к минимальному количеству коммитов и Pull Request от каждого участника не выполняется, команде начисляются штрафные баллы за недостатки в организации командной работы.

Координация совместной работы

1. Для распределения задач, установки промежуточных дедлайнов, понимания каждым хода разработки (кто, где и на какой стадии находится) используются таск-трекеры: Projects текущего GitHub репозитория, Trello или любой другой инструмент по согласованию с куратором группы / тим лида.

2. В канале work-status (еще лучше - в формате ежедневного митинга) каждый участник команды (в том числе тим лид) каждый день составляют мини-отчёты по схеме:

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

3. Таск-трекеры и ежедневные мини-отчёты позволяют исключить дублирование и параллелизм в работе команды, когда два участника работают над одной задачей. Необходимость каждый день отчитаться о своём вкладе в командную работу стимулирует активность участников команды, позволяет сравнить свой результат с результатом других, быть в курсе процесса разработки.

4. На основе таск-трекера и мини-отчётов составляется worklog – отчёт о проделанной командной работе с указанием вклада каждого участника команды. В worklog вносятся конкретные реализованные фичи или элементы приложения. Образно, то, за что вам будет готов платить работодатель. Варианты "учился писать код" или "читал книгу", "много думал" не годятся.

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

1. Презентация курсового проекта происходит в форме конференции в скайпе, присоединиться к которой могут все желающие.

2. Каждая команда готовит презентацию созданного приложения продолжительностью не больше 5-7 минут, в которой демонстрирует особенности его работы и преимущества, рассказывает об особенностях разработки, трудностях и путях их преодоления.

3. В ходе презентации полученные командой баллы не озвучиваются и не комментируются.

Выставление оценок за курсовой проект

1. Курсовые проекты оцениваются в ходе кросс-чека и в ходе презентации проекта.

2. Кросс-чек проводится не отдельными студентами, а группами. То есть каждая группа должна проверить и оценить проекты 4 других групп.