Процедурные стандарты

1. Система контроля версий

1.1. Правила именования

1.1.1. Ветка

Необходимо придерживаться следующего формата именования веток:

<тип задачи>/<номер задачи>-<краткое описание>,

где

  • тип задачи - новый функционал (feature), дефект (bug), предложение (proposal);

  • номер задачи - номер задачи в системе учёта задач (gitlab), например 107, MP-224

    (но в нижнем регистре: mp-224). Отсутствует для предложения (proposal);

  • краткое описание - название задачи (допустим более краткий вариант) или краткое описание

    предложения (proposal) на английском языке (не транслитом).

Все компоненты имени ветки должны быть в kebab-case, включая номер задачи.

// Плохо
issue-241-dictionary-infobar-route-stops
feature/241
bug/301
feature/MP-224-onboarding-screen

// Хорошо
feature/241-dictionary-infobar-route-stops
bug/301-broken-infobar-dropdown
proposal/new-branch-type-for-proposals
feature/mp-224-onboarding-screen

1.1.2. [Автоматизировано: commit-linter] Сообщение к изменению

a. При фиксации изменения обязательно используется сообщение, описывающее изменение.

b. Сообщение должно описывать состав изменений и причину (назначение) изменения.

c. Сообщение должно иметь следующий формат:

<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: 
<состав и семантика изменения 1>[, ..., <состав и семантика изменения M>]
[; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>]

Таким образом, самый простой вид сообщения:

<номер задачи> <модуль>: <состав и семантика изменения>

Разновидность наиболее насыщенного изменения:

<номер задачи> <модуль 1>/<подмолуль>, <модуль 2>/<подмодуль>: <состав и семантика изменения 1>, 
<состав и семантика изменения 2>]; <модуль 3>: <состав и семантика изменения>

где

  • <номер задачи> - корректный путь до задачи, который в идеальном случае обеспечивает

    связь изменения в репозитории и задачи на уровне ссылки. Например, #17, CD-11,

    inni/issues#104;

  • <модуль> - название модуля, внутри которого вносится изменение. Модулем в данном случае

    называется любая директория в корне проекта, если эта директория вне директории src или

    любая директория внутри директории src (или директории, считающейся корнем исходного

    кода приложения). Если изменение касается проекта в общем, т.е. изменени структуры,

    изменение состава зависимостей, npm-скриптов и т.д., то в качестве модуля проставляется

    common. common также может относится к изменению в директории общего для модулей кода.

    Если изменение касается процесса непрерываной интеграции (continuous integration),

    то такое изменение отмечается: ci;

  • <подмодуль> - название подмодуля внутри модуля. Подмодулем считается директория

    внутри директории модуля;

  • <состав и семантика изменения> - описание того, что и зачем было изменено.

Разделители:

  • <номер задачи> отделяется пробелом `` от остальной части сообщения;

  • <модуль> и <подмодуль> разделяются слешем /;

  • Группы <модуль>/<подмодуль> отделяются друг от друга запятой ,;

  • <модуль>/<подмодуль> и <состав и семантика изменения> разделяются двоеточием :;

  • Группы <модуль >: <состав и семантика изменения> отделяются друг

    от друга точкой с запятой ;;

  • Группы <состав и семантика изменения> отделяются друг от друга запятой ,

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

Примеры:

// Структура проекта
data-collectors <root of project>
    /dev
        /db
            /data
            /model
            /queries
    /src
        /common
            /services
                /data
        /instrument
        /report
    package.json

// Плохо

// Отсутствует суть изменений
#287 common: review fixes
// Нет номера задачи, в указании модуля присутствует название проекта 
// и указана излишняя вложенность
data-collectors/report/pasrer/historical: optimized parsing of the dom 
    to get 2x speed of parsing

// Хорошо
inni/issues#104 common: added script to update dependencies to cure integrity check error
inni/issues#105 instrument: changed source of data from source1 to source2 
    to get more stable data stream
inni/issues#106 dev/db: changed type of the field `value` of report to store data 
    from different sources;
report: implemented new service to get data from some new source of data.
inni/issues#107 common/services: added new service `report data service` to get 
    report data from database

d. Не должно быть вложенности больше <модуль>/<подмолуль>, т.е. максимальная точность указания изменения ограничивается вложенностью второго уровня. Если изменение касается двух подмодулей одного модуля, то оба варианта записи сообщения об изменении являются приемлемыми:

// Вариант 1. Сообщение разбито по подмодулям
<номер задачи> <модуль 1>/<подмолуль 1>: <состав и семантика изменения>; 
<модуль 1>/<подмодуль 2>: <состав и семантика изменения>

// Вариант 2. Сообщение сгруппировано по модулю
<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, 
что оно сделано в подмодуле 1>, <состав и семантика изменения с указанием, 
что оно сделано в подмодуле 2>;

e. Не должно быть точки в конце сообщения.

f. Сообщение должно быть на английском языке, не должно быть транслита.

g. Каждая часть изменения, т.е. <состав и семантика изменения>, начинается с глагола в прошедшем времени, т.е. описывает, что было сделано: added ..., fixed ..., ...

h. Исключение формата сообщения составляют автоматические фиксации изменений, выполняющиеся в процессе автоматизированной сборки и развёртывания, а также изменения в результате слияния веток.

i. Формат сообщения при фиксации изменения в процессе автоматизированной сборки:

auto/ci: <текст сообщения>

Примеры:

auto/ci: set version 0.1.24

j. Формат сообщения при слиянии веток:

// Слияние ветки <название ветки> -> master
Merge branch '<название ветки>'

// Слияние ветки <название ветки 1> -> <название ветки 2>
Merge branch '<название ветки 1>' into <название ветки 2>

Примеры:

Merge branch 'dev'
Merge branch 'feature/101-automate-rules-of-object-formatting' into dev

k. Вместо номера задачи в редких случаях, когда требуется внести очень мелкое изменение, под которое не имеет смысла создавать задачу (исправление опечатки, корректировка какой-то случайной проблемы), может указываться слово microfix.

microfix common: added comment to skipped specs

2. Процесс внесения изменений

2.1. Внесение изменений

a. Предпочтительнее фиксировать небольшие и законченные изменения.

b. Вносимому изменению должна соответствовать задача, описывающая требуемые изменения.

c. Изменения по задаче должны выполняться в отдельной ветке, соответствующей задаче и названной в соответствии с правилами именования веток п. 1.1.1.

d. Основной (рабочей) веткой является ветка dev.

e. Релизной веткой, т.е. веткой, в которую подливаются изменения, когда они соответствуют следующей версии приложения, является ветка master.

f. Необходимо изменения сопровождать фиксацией сути изменения в файле CHANGELOG.md в корне проекта. Ведите Changelog

g. Сообщения к изменениям должны соответствовать правилам оформления сообщений, указанным в п. 1.1.2.

h. Небольшие изменения (исправление опечатки, корректировка какой-то случайной проблемы), которые помечаются как microfix, могут вноситься сразу в рабочую ветку dev. Если изменение вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью).

i. Задача должна быть переведена в состояние «‎в работе», когда над ней действительно начата работа.

j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым пройдены все инспекции кода.

k. Перед отправкой изменений в репозиторий должны выполняться автоматизированный статический анализ кода и тесты. Не допускается отправлять изменения в репозиторий с отключенной проверкой кода и запуска тестов (pre-commit / pre-push hooks).

l. Добавленные изменения должны быть покрыты спецификациями (автоматизированными тестами).

2.2. Завершение работы над задачей

a. В файле CHANGELOG.md в корне проекта присутствует запись о сделанных изменениях. Ведите Changelog

b. Задача должна быть перведена в состояние «ревью».

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

d. Должен быть создан запрос на влитие изменений (merge request / pull request) в рабочую ветку dev. Аналогом может выступать создание ревью в инструментах типа Upsource на ветку с изменениями.

e. Должно быть выполенно ревью изменений участниками команды.

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

g. Задача должна быть переведена в состояние следующее состояние задачи (как правило, это состояние «‎готово») после её влития в dev.

2.3. Ведение журнала изменений (changelog)

a. В корне проекта должен быть файл CHANGELOG.md, в котором фиксируется суть вносимых изменений.

b. Правила ведения журнала изменений должны соответствовать, описанным на ресурсе: Ведите Changelog

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

// Пример описанного изменения
- [`DXAPP-571`](https://smekalka.atlassian.net/browse/DXAPP-571) Added 
  [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware 
  to get alternative to react native debugger that slows down app during debug

d. Для записей в журнале изменений применяются те же правила по ограничению на длину строки, что и для других файлов.

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

f. Запись в логе изменений должна быть краткой, но ёмкой. Должно быть понятно, что и зачем было изменено.

g. Изменения, которые относятся к текущей версии, которая ещё не выпущена, должны быть в специальной секции [Unreleased changes] в начале файла. При релизе (выпуске) версии эти изменения помечаются конкретной версией релиза и датой его выпуска. Секция же [Unreleased changes] очищается и начинает принимать следующие изменения.

2.4. Обзор кода (ревью)

2.4.1. Цели обзора кода

a. Распространение информации о новых изменениях в текущем и смежных проектах среди участников команды, чтобы все участники в равной степени понимали код проектов.

b. Повышение качества кода проектов.

с. Наращивание навыков разработки у участников команды.

d. Повышение мотивации писать код лучше.

e. Проверка корректности внесённых изменений в плане соответствия сути задачи.

2.4.2. Смысл каждой цели в деталях

a. Если проектов больше 5 и объём кода в каждом из них растёт, участники команды, переходя на незнакомый проект или модуль, будут тратить время на вопросы к коллегам и попытки разобраться в чужом коде. Код ревью решает эту проблему: изменения будут просматриваться шаг за шагом маленькими порциями информации, которые легко усвоить. В результате каждый участник будет хотя бы понимать, что и как уже реализовано. [?] Также для решения этой проблемы необходимо использовать документацию.

b. Код пишется 1 раз, а читается много. Необходимо, чтобы код был очевидным и простым.

c. Более опытные участники команды, комментируя код, делятся опытом с менее опытными, тем самым повышая их уровень.

d. Когда автор осознаёт, что результат его работы будет кем-то проверяться, он стремится получить больше положительных комментариев и меньше запросов на исправление кода.

2.4.3. Процесс обзора кода

a. Ревью инициируется созданием запроса на влитие кода и уведомлением об этом участников команды, которые должны просмотреть код.

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

c. В запросе на влитие должна содержаться информация о задаче, с которой связан этот запрос. Должна присутствовать ссылка на задачу.

d. Участники, проверяющие код, добавляют комментарии к запросу на влитие изменений.

e. Комментарии отмечает выполненными автор изменений, код которого просматривают.

f. После корректировки замечаний и реализации предложений должен запрашиваться повторный обзор кода.

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

2.4.4. Процесс обзора задач, не связанных с системой управления кодом (Github, Gitlab)

Такие задачи, как документирование в Notion, Confluence и пр.

Мотивация: Сократить количество отвлекающих воздействий на автора изменений до 1 (в позитивном сценарии), меньше отвлекая друг друга от работы.

  1. Рецензент в процессе обзора кода фиксирует свои замечания и пожелания в комментариях под задачей в канале review.

    Формат

    Сообщение:

    [краткое описание задачи] [ссылка на задачу]

    Комментарии:

    1 [Замечание или пожеление 1] 2: [Замечание или пожеление 2] N: [Замечание или пожеление N]

  2. После того, как рецензент завершил фиксирование замечаний, он уведомляет об этом автора задач. А также переводит задачу в статус «открыта» / «переоткрыта», чтобы другие рецензенты делали обзоры только на непросмотренные задачи.

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

  4. Автор задачи отмечает сделанные задачи смайлом: ✔

  5. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как завершённые, он также сообщает об этом рецензенту.

  6. Рецензент отмечает смайлом ✔ те пункты, в которых он уверен, что они исправлены или не нуждаются в исправлении. Если рецензент с чем-то не согласен, он уведомляет автора задачи о необходимости её доработать, и процесс повторяется с шага 2. В другом случае задача переводится в состояние «готово».

2.4.5. Противоречия и споры в процессе обзора кода

a. Споры и затягивание обзора кода не допускаются.

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

c. Не допускается повторных обсуждений по поводу уже принятых правил в рамках ревью. Любые идеи и предложения выносятся отдельно. Обзор кода проходит в рамках уже принятых правил написания кода. Это не исключает возможности договориться о новых при хорошем уровне коммуникаций и взаимопонимания в команде. (см. пункт выше)

2.4.6. Правила для участников, проверяющих код

a. Закрыв файл после проверки, вы тем самым полностью принимаете этот вариант так, как будто это написали вы. А так же вы уже несёте ответственность за уровень качества и работоспособности кода. Таким образом, после того, как вы увидели чей-то код - он стал уже вашим.

b. Если что-то правится быстро (5-10 секунд) и ошибка встречается впервые, проверяющий может поправить это самостоятельно. Это является предпочтительным вариантом. Если это имеет смысл, то можно уведомить автора об этих изменениях, чтобы он получил дополнительный опыт и учитывал его в дальнейшей работе.

2.4.7. Состав участников обзора кода

a. Запрос на влитие изменений должен быть сделан на двух участников команды, которые в состоянии понять смысл изменений и подтвердить их корректностью. Не может считаться выполненным ревью, если проверяющий кристально чисто не может осознать суть внесенных изменений. В этом случае для ревью должны привлекаться другие участники команды, которые в силах это сделать. Не должны заливаться изменения, смысл которых неочевиден.

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

c. [?] После завершения обзора кода обязательным составом проверяющих результаты обзора кода должны быть просмотрены оставшимися участниками команды, чтобы достичь обозначенных целей по обучению и погружению в проект. Ревью для всех, кто пишет код, вне зависимости от того, кому оно адресовано. Если Васе написали замечание или указали на ошибку, то все участники команды должны запомнить этот момент и не повторять его в будущем. Для этой цели может создаваться канал #review в мессенжере (например, slack'е), куда отсылаются все комментарии с ревью или ссылка на ревью.

Тут такие мысли:

  1. Знакомство с добавляемым в проект функционалом преследует демо.

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

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

    по сути такую цель преследовать не стоит.

  3. Участники команды могли бы увидеть какие-то интересные технические решения и подходы.

    Возможно, их также стоит вносить в общие правила как лучшие практики.

d. [?] В качестве варианта ревью, возможно, стоит рассмотреть вариант демонстрации кода автором с пояснениями. Это может сократить время, необходимое участникам команды на осмысление кода каждому в отдельности.

2.4.8. Написание комментариев в процессе обзора кода

a. Критиковать код, а не автора. Помните, раз вы увидели этот код - то он уже тоже ваш.

b. Аргументировать принципами (S.O.L.I.D., CLEAN и т.д.), выдвигать предложения по улучшению, а не просто высказаться, что всё плохо.

c. Искренне высказывать позитивные эмоции, если что-то в коде понравилось. Это повышает мотивацию и продуктивность участников команды. Нужно помнить, что обзор кода направлен на повышение качества. Соответственно в процессе обзора кода важно отмечать и закреплять положительные моменты в коде, поощрять новые и интересные идеи.

d. Не писать в побудительном наклонении:

    // Хорошо
    `Я бы исправил здесь A на Б`, `Давай исправим А на Б?`
    `Нам стоило бы в этом случае сделать так ...`

    // Плохо
    `Исправь А на Б`

2.4.9. Отношение к комментариям в обзоре кода

a. Не оправдываться в комментариях: А, да, точно, я затупил, Я невыспался и т.д.

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

c. Запомнить ситуацию, усвоить полученный опыт.

d. Если не согласны - обсудить. Не использовать агрессивно-защитные высказывания и пассивное игноирование. Держать в голове всегда цели обзора кода и команды в целом.

2.4.10. Проверка стиля кода

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

b. В результате необходимо стремиться к отсутствию комментариев, касающихся стиля кода.

2.4.11. Приоритет обзора кода

a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным как для просматривающего изменения, так и для автора изменений. Задача в состоянии «ревью‎» имеет наивысший приоритет, если по какой-то причине явно не было принято другое решение в виде исключения.

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

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

2.4.12. Учёт при планировании

a. Время на ревью и исправления должно учитываться при планировании задач на итерацию.

b. [?] Должно учитываться время, которое необходимо всем участникам команды для просмотра результатов ревью.

2.5. Выпуск следующей версии приложения

Под выпуском (релизом) следующей версии приложения понимается срез текущего функционала рабочей версии приложения. При этом рабочая ветка dev заливается в релизную ветку master.

Порядок действий при релизе

  1. dev -> master

  2. tag v.x.x.x

  3. dev v.x.x.x + 1

Схема с веткой pre-release, если проект - это библиотека и проставление версии не может быть автоматическим. Хотя можно проставлять версию автоматически на основе changelog: added, changed, removed

3. Итерация

3.1. Основная идея

a. Итерация процесса разработки есть один цикл постановки подцелей, производства продукта, получения результата и обратной связи для корректировки качества получаемого результата (сюда же включена и эффективность, которая влияет на конечный результат).

b. Процесс итерации можно представить списком таких этапов (мероприятий):

  • Планирование итерации

  • Запуск итерации

  • Разработка

    • Решение задач. Не является мероприятием, заполняет

      всё доступное время.

    • Обзор решения (Ревью)

    • Внутрикомандное демо

  • Закрытие итерации

  • Тихий час

  • Мозговстряска

c. Суммарная продолжительность общекомандных мероприятий: 9 ч

3.2. Роли

  • Ответственный за итерацию, выбирается по наиболее старшей позиции

    в команде.

3.3. Планирование итерации

a. Продолжительность: 3 ч

b. Цель: включить в следующую итерацию наиболее приоритетные задачи из бизнес, технических и организационных очередей задач.

c. Задачи:

  • актуализировать состав и приоритет задач

  • распределить задачи между участниками в команде

d. Участники:

  • ответственный за итерацию

e. Примечание:

  • нужно оптимизировать (слишком долго)

  • все задачи должны быть связаны с целями

  • задачи должны постоянно актуализироваться и по сути быть уже

    отсортированными по приоритету, привязанными к целям и готовыми

    к взятию в работу

3.4. Запуск итерации (Установка микроцелей)

a. Продолжительность: 15 мин (подготовка) + 10 мин

b. Цель: сделать фокус на целях итерации.

  • актуализировать следующую итерацию по результатам

    завершения текущей

  • проговорить цели, сделать акцент на целях

  • проговорить непонятные задачи

c. Участники:

  • ответственный за итерацию

  • команда

d. Требования к участникам:

  • ответственный за итерацию должен подготовить план итерации

  • участники команды должны просмотреть предварительный план

    и сформулировать вопросы

3.5. Обзор решения (Ревью)

a. Продолжительность (ежедневно): 1 ч

b. Цель: обратная связь по решению задачи.

d. Участники:

  • команда

e. Примечание:

3.6. Внутрикомандное демо

a. Продолжительность (ежедневно): 15 мин (подготовка) + 10 мин

b. Цель: оценить процент достижения цели.

c. Задачи:

  • текущий срез с фокусом на достигнутый за день результат

  • получение обратной связи

  • знакомство с результатами работы других участников команды

d. Участники:

  • ответственный за итерацию

  • команда

e. Требования к участникам:

  • участники команды должны подготовить к демо выжимку по

    достигнутым результатам за день

f. Выжимка по достигнутым результатам:

  • название и ссылка на задачу

  • процент завершения

  • оценка попадания в срок и в оценку

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

g. Ход встречи:

  • Каждому участнику даётся не более 2 мин на представление результата.

    НЕ нужно рассказывать, КАК к нему пришел и что делал, нужно показать,

    ЧТО сделал и дать оценку результата и приближения к цели.

  • Секция вопросов участнику.

  • Повторить, пока не закончатся участники.

  • Количество участников должно быть не более 4.

3.7. Закрытие итерации (Фиксация результатов)

a. Продолжительность: 30 мин

b. Цель: фиксация результатов итерации.

c. Задачи:

  • сформировать статистику по выполнению задач по каждому

    участнику в отдельности и по команде в целом

  • определить процент достижения целей на итерацию

  • актуализировать карточки сотрудников

d. Участники:

  • ответственный за итерацию

e. Примечание:

  • в идеале должно выполняться автоматически

3.8. Тихий час

a. Продолжительность: 1 ч

b. Цель: личная оценка достижения целей.

c. Задачи:

  • просмотреть результаты итерации

  • обдумать их

  • зафиксировать положительные и отрицательные моменты

  • подготовить предложения по улучшению

d. Участники:

  • команда (каждый участник в отдельности)

3.9. Мозговстряска (Оценка результатов)

a. Продолжительность: 15 мин

b. Цель: оценка достижения целей

c. Задачи:

  • обсудить итоги итерации

  • оценить процент достижения цели

  • сделать выводы

d. Участники:

  • ответственный за итерацию

  • команда

3.10. Отношение к оценке времени выполнения задачи

a. Если исполнитель задачи понимает, что задача не может быть выполнена за время, которым она была оценена, то нужно, как можно раньше донести эту информацию до руководителя группы. Если же о недостаточности времени становится известно либо в момент, когда лимит времени достигнут или превышен, то возможностей для маневра практически не остаётся.

b. Исходное (оценочное) время на задачу не изменяется, изменяется только время, которое осталось на доработку задачи.

3.11. Отношение к сроку выполнения задачи

TODO

3.12. Создание задач

TODO: Процедура добавления задач с меткой unverified.

Категоризировать задачи по важности (признак, определяющий распределение задач при обзоре решения (ревью)).

4. Внесение предложений

4.1. Порядок внесения предложений

a. Чтобы подать предложение, необходимо описать его в ветке с названием proposal/<краткое название предложения> и сделать запрос на вливание в ветку dev.

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

c. По истечении полного рабочего дня должно быть достигнуто конечное решение по предложению: принято (исходное или скорректированное) или отклонено.

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

e. Если кто-то не проявил интереса к предложению, т.е. не участвовал в его просмотре и обсуждении, это не должно мешать предложению быть принятым. Если никто не одобрил предложение в оговоренное время, оно считается принятым и должно быть влито в ветку dev.

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

4.2. Когда правила по стилю кода начинают работать?

a. Каждое новое предложение по стилю кода должно быть автоматизировано. Правило не работает, пока оно не автоматизировано.

b. Правило добавляется с пометкой \[Не автоматизировано\] в заголовке правила. Например: 3.2.2. \[Не автоматизировано\] Правила именования для обработчков.

c. Должна быть создана задача на автоматизацию правила.

4.3. Локализация предложений

a. Предложение должно быть оформлено на двух языках: русский и английский.

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

5. Встречи

5.1. Требования к формату встречи

a. Встреча обязательно должна иметь повестку. Например:

Повестка:

1. Обсуждение проблемы извлечения и контроля требований
в процессе производства.

b. Встреча не должна по продолжительности превышать 30 минут.

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

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

Повестка:

1. Обсуждение проблемы извлечения и контроля требований
в процессе производства.

Требования к участникам:

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

e. Каждому участнику встречи по очереди даётся 2 минут на то, чтобы он представил своё предложение. В это время его никто не перебивает. 3 минуты даётся на вопросы к автору предложения.

f. Представленные предложения обсуждаются в течение 5 минут. Также отводится 5 минут на подведение итогов.

g. Должны быть распределены роли на встрече:

  • ведущий встречи, контролирующий проведение встречи в соответствии с данным

    правилом;

  • контролёр времени, отвечающий за соблюдение регламента встречи по времени;

  • писарь, фиксирует результаты встречи.

h. Количество участников не должно превышать 6, иначе велик риск выйти за рамки установленного времени, т.к. уже при 4-х участниках и полном использовании всего своего времени каждым участником всё время встречи будет распределено.

i. Встреча должна записываться на видео/аудио. Видео является более предпочтительным.

j. Исключением по продолжительности может быть встреча, посвящённая демонстрации. Продолжительность подобной встречи не должна превышать 1 ч. 45 мин - выступление, 15 мин - вопросы. В идеале стараться не выходить за пределы встречи в 30 мин.

5.2. Ход встречи

a. Ведущий встречи проверяет готовность присутствующих ко встрече. Если какой-либо участник не готов, ведущий просит его покинуть встречу.

b. Ведущий встречи озвучивает повестку и передаёт слово одному из участников встречи.

c. Участник встречи высказывается в установленный временной лимит. Ему задаются вопросы.

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

e. Подводятся итоги встречи и фиксируются результаты:

  • принятые решения

  • намеченные действия

  • ответственные лица

  • сроки

Например,

Итоги:

1. Проработать структуру пожелания бизнес-заказчика и 
описать критерии перехода пожелания в требование. 
Отв.: Антон К., 07.09.2019
2. Оформить требования по модулю покупки билетов в
соответствии с принятой структурой пожеланий и требований.
Отв.: Даня С., 10.09.2019

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

5.3. Количество встреч

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

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

5.4. Приглашение на встречу

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

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

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

5.5. Открытые вопросы

a. В каких ситуациях действительно нужны встречи?

b. Не более ли качественный вариант решения вопросов, решать их через предложения вне встреч?

c. Классифицировать встречи. К каждому типу можно было бы прописать общие требования ко встрече, участникам, чтобы не нужно было одно и то же писать во встречах такого типа.

PreviousFrontendNextБаза данных

Last updated