Workflow

В цьому розділі описані процеси, котрі повинні дотримуватись всіма учасниками команди відповідно до ролей.

1. 👦 Developer

1.1. Створення задачі:
1.1.1. Задача створюється в колонці Backlog;
1.1.2. Задачі повинні мати наступні вимоги: [05:30 - ]

• Затрати на вирішення задачі мусить бути вирішена не більше ніж за 4 години;
• задача мусить мати label (BUG, REFACTOR, TASK); [06:00 - ]
  • BUG - дефект;
  • REFACTOR - вдосконалення коду (функціональність не змінюється), написання резюме зустрічей, інтеграція Liquibase, ...
  • TASK - необхідно, щоб задача відносилася до фічі;
• якщо необхідного label-y немає - 👨PM повинен його створити створити.
• належним чином прописані вимоги - щоб їх міг зрозуміти кожен, перш за все це потрібно, щоб рев'ювер зміг оцінити результат роботи - задача виконана чи ні;
• якщо задача є продовженням іншої, то в ній повинно бути посилання на попередню [11:10]
• коли задача створюється, не треба ставити відповідального; 👦 девелопер повинен сам взяти верхню задачу з колонки Open

1.2. Початок роботи над задачею:
1.2.1. У девелопера може бути тільки одна задача в статусі In Progress;
1.2.2. Перед початком виконання задачі бере тікет із колонки Open:
1.2.2.1. Перш за все треба брати свої задачі, які були повернуті із рев'ю або були заблоковані
1.2.2.2. Брати задачі, вже назначені на когось, не дозволяється;
1.2.3. Якщо задача повернулась з рев'ю і в неї багато зауважень, треба розбити її на декілька, відповідно до скоупа (4 години);
1.2.4. Призначає себе на цю задачу;
1.2.5. Переносить задачу в колонку In Progress;
1.2.6. Гілку з задачею треба називати так: #123-very-important-feature;
1.2.7 Повний цикл роботи над задачею (від моменту assign до моменту close) мусить вкладатись в один тиждень. В разі порушення цього принципу - проблема буде ескалуватись до рівня 👨PM, проведеться з'ясування ситуації з метою прискорити процес. Бажано уникати ескалації, оскільки це додаткові затрати ресурсів команди, збільшує незадоволення, понижує рейтинг і авторитет винного (розробника, або рев'ювера). Якщо в якийсь момент часу приходить ясність, що задача затягнеться - варто попередити 👨PM

1.3. Робота над задачею:
1.3.1. Повідомлення в коммітах повинні бути такого формату: #123: commit message;
1.3.2. На задачу повинні бути юніт-тести; Без тестів 👴 Reviwer не приймає задачу;
1.3.3. Притримуватись вимог до коду;
1.3.4. Після того, як попрацював над задачею, додає коментар до задачі: @AndriyBaibak time tracking: 1 hours spent;

1.4. Якщо задача заблокована іншою [24:25]:
1.4.1. Додає коментар до своєї задачі blocked with #123 @AndriyBaibak @author-of-blocker pls fix it ASAP, тобто повідомляє PM'а та автора задачі-блокера про проблему;
1.4.2. Переводить заблоковану задачу в Open;

1.5. Якщо не вдається вирішити задачу:
1.5.1. Треба попросити допомоги у партнера;
1.5.2. Звернутисть в загальний чат;
1.5.3. Якщо робота виходить за рамки скоупа задачі - треба додати коментарі додати //TODO або @todo, доробити задачу частково, в ньому повинні бути:

• чіткий опис, що треба доробити;
• номер задачі в рамках якої був створений TODO; якщо такого посилання немає - 👴 Reviwer не приймає задачу;
• з цих TODO 👨PM буде створювати нові задачі (в описі такої задачі треба вказати посилання на задачу, в якій був створений TODO);

1.5.4. Якщо в рамках задачі реалізовані лише тести, час закінчився - варто додати @todo і позначити тести як @Ignore;
1.5.5. Якщо в рамках задачі порушені інші тести - варто їх відновити. Відкладати їх на потім не дозволяється оскільки це сильно ускладнить роботу в майбутньому - багато часу піде на з'ясування причини падіння, що саме призвело т.д.
1.5.6. Якщо вимоги до системи помінялись - певно якийсь набір тестів мусить відреагувати на зміни. Варто спробувати спершу локалізувати тести, які фіксують застарілий функціонал, позначити їх @Ignore. Далі тестами покриваєтсья новий функціонал, реалізовується логіка, перевіряється падіння старих тестів, видаляються старі тести. Якщо падають інші тести, не позначені як застарілі - варто дуже ретельно перевіряти їх, оскільки це можуть бути як пропущені застарілі, так і сигнал до порушення логіки.

1.6. Завершення роботи над задачею:
1.6.1. Змержує мастер до своєї гілки;
1.6.2. Створює пулл-реквест;
1.6.3. Для з'єднання пулл-реквеста з задачею в його опис додає connect to #123 (№ задачі);
1.6.4. Переносить задачу з колонки In Progress в Review;
1.6.5. В канал #reviewme додає лінк review me <link to PR>; Нічого крім запитів в цьому каналі постити не дозволяється!
1.6.6. Переходить до пункту 1.1;
1.6.7. Якщо до прийняття пулл-реквеста мастер змінився, то змержує мастер до своєї гілки знову.

1.7. Після того, як задача змерджилась в мастер (і якщо ця задача вносить новий функціонал), проводить демо (канал #demos);
1.8. Приймає участь у колективному code-review;

2. 👨 Project Manager - Андрій Байбак, @AndriyBaibak [20:40]

Зона відповідальності - щоб задачі швидше проходили від стврення до завершення;

2.1. Якщо пулл-реквест довго не розглядається, нагадує рев'юверам, що треба провести рев'ю; запити на рев'ю знаходяться в каналі #reviewme;
2.2. Нагадує девелоперу, що його задача блокує іншу;
2.3. Превіряє задачі в клонці Backlog і, якщо вони задовольняють вимогам, переносить іх в колонку Open;
2.4. Перевіряє коментарі задач на наявніть "time tracking"-коментарів, переносить дані про витрати часу до загальної таблиці звітності;

3. 👴 Reviewer - Олександр Анакін, Олександр Власов, Роман Черепанов;

3.1. Проводить рев'ю по запиту з каналу #reviewme:
3.1.1. Якщо зауважень до задачі немає, пише PASSED в коментарі на GitHub та ставить 👍 в #reviewme та добавляє label PASSED_reviewer-name;
3.1.2. Для того, щоб задача пройшла рев'ю, необхідно мінімум 2/3 голосів;
3.1.3. Рев'ювер не може голосувати за свою задачу;

3.2. В разі наявності зауважень:
3.2.1. Змінює label REVIEW на нову - FAILED_reviewer-name;

3.3. В разі відсутності зауважень:
3.3.1. Робить мердж;
3.3.2. Закриває задачу;

4. Різне

4.1. Scope задачі повинен бути максимум 4 години. [27:20]
4.2. Якщо задача більше, ніж на 4 години, варто розбити її на дрібніші;
4.3. Мердж між гілками, які не пройшли код-рев'ю не дозволяється; [26:25]
4.4. Спілкуватись на GitHub варто англійською мовою;
4.5. В коментарях на GitHub використовувати персональні повідомлення (@User); [10:00 - 13:30]
4.6. Краще коментувати комміти, щоб з коментаря зразу можна було перейти до коду; [17:40 - 19:30]
4.7. На Waffle.io нові задачі додавати знизу списка;