Несколько слов о процессах

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

Он-боардинг - процесс погружения в коллектив, работу и задачи. Знакомство с командой и получение логинов и паролей. Более сложная часть состоит в том чтобы за отведенное время (например месяц или два) разобраться с процессами и научиться оценивать задачи и сроки. Чтение confluence (корпоративной вики) где вероятно будет рассписано все: отвественные, подходы к codestyle, архитектуре, ревью кода и т.д. Знакомимся со всем этим и получаем первые задачи.

Ошибки на первых этапах неизбежны, кривые оценки, косяки с соблюдением стандартов. В нормальных процессах время на эти ошибки на первое время закладывается заранее.

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

Например существует методология waterflow. По ней строят технически сложные инженерные сооружения типа электростанций. Когда очень точно до мельчайшей детали формулируется что мы хотим получить, составили все чертежи и технические параметры. Потом расписали весь процесс изготовления на микроуровне (как схема сборки мебели икея или конструктора лего). затем мы расписали для каждой задачи конкретного ответсвенного и сроки (с выстроенным календарем и диаграммой Ганта). Как итог мы знаем результат, знаем сроки, знаем исполнителей и все-все-все.

В чистом виде waterflow в IT невозможен (однако может быть применим для некоторых критических компонент). Часто исполнители не понимают как решать задачу, а менеджеры исполнителей до конца не понимают саму задачу, поэтому планы приходится менять по несколько раз в день.

Kanban - это инструмент, который позволяет удобно организовать работу с помощью стикеров с описанием задач и доски со статусами для этих задач. Весь процесс ведущий к созданию ценности разбит на мелкие задачи (т.е. декомпозирован), здесь удобно привести пример с ремонтом. Обычно статусы для декомпозированных задач выбираются следующие:

• бэклог (все что еще не оценили)
• в плане (все что уже оценили и взяли в спринт)
• в работе
• заблокирован (когда есть препятствующая задача, блокер)
• готово

У каждой карточки есть оценка по времени. Сам flow (последовательность статусов) задается бизнес процессом и может иметь другой набор статусов, ветвлений и пр.

Agile - это философия, итеративный подход в разработке продуктов, который фиксируется на непрерывных выпусках и учете отзывов клиентов на каждой итерации. Первый шаг - все не стесняются того что никто в компании ничего не понимает в продукте, это не стыдно и по факту правда. Многие продукты в конечном счете получились не тем чем они задумывались изначально. Чаще всего требования заказчика или менеджера не являются ТЗ.

1. мы принимаем то что финальный результат не зафиксирован
2. мы не только разрешаем заказчику вмешиваться, но и делаем этот процесс комфортным
3. всеми силами пытаемся не превратить проект в хаос

Scrum - is an agile project management framework that helps teams structure and manage their work through a set of values, principles, and practices.

Это конкретный рецепт как организовать работу по  Agile и не сойти с ума. Разбивает работу на цели, которые должны быть выполнены в течении ограниченных по времени итераций, называемых спринтами.

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

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

Ритуалы скрама.

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

Как итог (пример):

• Каждый понедельник в 11 утра планирование (какие появились новые задачи, оценка, работа с backlog, что не успели сделать за прошлый спринт, выбор из всей этой кучи тех задач, которые хотим сделать за этот и распределение внутри команды)
• Раз или два в нелелю daily - это короткий созвон, где вы говорите как ваши дела, он нужен для того чтобы поделиться с командой о затыках в решении задач.
• Регулярный или не регулярный груминг. Это чистка бэклога и вычесывание оттуда лишнего и ненужного
• В конце спринта ревью и ретро. На котором обсуждается что успели и не успели, почему, что хорошо, что могло быть лучше и благодарим коллеги за хорошую работу (а за не хорошую не благодарим :))
• далее по кругу...

Сложно бывает эти регламенты соблюдать.

Что такое покер планирование? (идет в комплекте со скрамом, один из ритуалов)

Как быстро и безошибочно дать им сроки и оценку сложности. (спойлер никак, однако можно сделать следующее:...) 

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

Если все задачи оценит "сильный" сотрудник, то "слабый" не успеет их сделать.

Если все задачи оценит "слабый", то "сильный" будет простаивать.

Можно разделить задачи между сотрудниками и пусть каждый оценит свою, но...

Что если "сильный" сотрудник захочет поиграть в WoW и напишет себе много часов (даст завышенную оценку задачам), или он оценит их "честно" но заболеет и "слабый" сотрудник взявший его задачи точно не выдержит сроки.

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

1. команда собирается, обсуждаем задачу #N
2. каждому члену команды дается полторы минуты и листочек на подумать и каждый в закрытую пишет сколько это задача займет часов
3. когда время вышло все вскрывают свои карточки
4. берутся вылеты, сначала обсуждают самую дешевую оценку, как возможно реализовать это за такой короткий срок; потом берется тот кто дал самую высокую оценку и его просят рассказать какие подводные камни он там углядел, они дискутируют раунд повторяется
5. и на 2 или 3 раунд оценки будут почти полностью совпадать
6. далее переходим к обсуждению задачи #N+1

На выходе получаем:

1. усредненную оценку, которая примерно подходит всем разработчикам
2. в такой системе очень сложно обмануть (толко методом коллективного сговора)

Минусы способа:

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

но это лучшее что пока что придумано

Что такое стори поинты?

Абстрактные баллы отражающие сложность задачи. Эталонная задача - выбирается самая простая стоит 1 стори поинт. Далее чем сложнее задача, тем больше стори поинтов она стоит. Стори поинты никак не связаны со временем! Это про сложность, т.к. оценка по времени не универсальная, задачи могут быть как очень простые, но долгие, так и довольно сложные, но разрешимые за относительно короткое время. 

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

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

Таск трекер

Jira, clickup etc.

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

Важная часть процессов это код ревью

Это процесс когда ваш код проверяют. Обычно будет так: вам упала задача, вы сделали под нее ветку в  git, выполнили, создали merge request, чтобы ваше изменение засунули в основную ветку. При одобрении merge request возникает инерционный процесс правки по комментариям от лида.

Правила (критически важны):

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