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

Информация для справки :

1. Скрам гайд
   
2. Изменения в скрамгайде версии 2020 года (последняя актуальная)
   
3. Почитать для общего развития
   
   

Основные принципы

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

Мы не молчим о проблемах - если есть что-то, что мешает работать, то мы громко об этом говорим. Говорим до тех пор, пока вас не услышат и не помогут устранить проблему.

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

Мы следуем принципу "Нормально делай - нормально будет". Это значит, что мы не терпимы, к плохим, необдуманным и непродуманным решениям.

Мы следуем принципу "Сначала думай, потом делай". Это означает, что перед началом работы над задачей, сначала продумываем возможные решения, уточняем все необходимые моменты и если надо, подтверждаем, что правильно понимаем задачу и только после этого начинаем работу над ней. Обычно если сначала делать, а потом думать часто возникают проблемы, а это значит что мы нарушили сразу 2 наших принципа : 1) Не делать фигни 2) Нормально делай - нормально будет.

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

Все мы люди - мы признаем право на ошибку. Из ошибок мы делаем выводы, становимся лучше и растем.

Основное

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

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

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

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

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


Время доступности

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

Чаты

Набор каналов чатов:

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

Dev - обсуждаем задачи разработки.

Meetings - согласуем тут время звонков, пишем здесь итоги встреч.

QA - чатик для бажиков.

Product - обсуждения связанные с фичами продукта.

Notification - выводятся уведомления от систем сбора ошибок, гитхаба, CI/CD сервисов и тд.

Если в чатике идет обсуждение чего-то больше 10 минут - лучше созвониться и обсудить голосом. А после зафиксировать договоренности.

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



Митинги

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

Пишите минутки по итогам митингов с договоренностями / вопросами / решениями - это сильно облегчит жизнь


База знаний

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

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

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

Стейкхолдер - Лицо заинтересованное в проекте. Болеет за результат и помогает команде идти к намеченной цели.Обладает суперспособностью - задавать вопрос "когда будет готово", на который при этом получает ответ.

Продакт менеджер - Отвечает за продукт и приоритеты, а так же все что с этим связанно.

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

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

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

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

Дизайнер - Помогает Продакт менеджеру работать над продуктом. Осуществляет авторский надзор и сопровождение работ.

QA - Отвечает за качество на сервисе в целом. Участвует на всех этапах от постановки задачи, до реализации, а не только проверяет готовые задачи.

Продуктовый аналитик - Отвечает за продуктовую аналитику и магию цифр.

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


Для фронтэнда за основу можно взять следующие критерии:

1. Верстка соответствует макету.
   
   
2. Интерфейс корректно работает и отображается в Chrome / Safari на стейджинг окружении.
   
   
3. Мобильная версия интерфейса корректно работает в Chrome / Safari на стейджинг окружении.
   
   
4. У задачи есть описанное понимание задачи (опциональный пункт, хорошо работает в задачах с неочевидной логикой).
   
   
5. Реализация логики задачи соответствует постановке задачи.
   
   
6. Аналитика в виде событий и pageview встроена.
   
   
7. Задача перед сообщением менеджеру о том, что сделана, проверена самостоятельно на стейджинг окружении.
   
   

Для бэкенда за основу можно взять следующие критерии:

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

Для задач вида "Проверить что-то" / изучить / и аналогичных. за основу можно взять следующие критерии:

1. У задачи есть описанное понимание задачи (опциональный пункт, хорошо работает в задачах с неочевидной логикой).
   
   
2. По итогам проверки оформлен в каком-то виде результат проверки.
   
   

После формирования базовой постановки задачи, стоит пройти по этому чекисту и дополнить, для более четкого формирования объема задачи(Более актуально для Эпиков и Скорей):

1. В задаче указанно, к каким ролям и их контекстам она относится.
   
   
   1. Роли на текущий момент:
      
      
      1. Родитель:
         
         
         1. Контекст:
            
            
            1. Есть дети
               
               
            2. Нет детей
               
               
      2. Ученик:
         
         
         1. B2T:
            
            
            1. Контекст:
               
               
               1. Создан учителем.
                  
                  
               2. Был импортирован через годзилу.
                  
                  
               3. Бесплатная школа ?
                  
                  
         2. B2C:
            
            
            1. Контекст:
               
               
               1. Пришел по инвайт ссылке.
                  
                  
         3. Нет родителя.
            
            
            1. Контекст:
               
               
               1. 
                  
                  
      3. Учитель:
         
         
         1. Контекст:
            
            
            1. Есть класс.
               
               
            2. Нет класса.
               
               
      4. Администратор
         
         
         1. Контекст:
            
            
2. Если задача про контент, то в ней учтен функционал для учителя (курилка и возможность назначить класс на предмет и статистика по предмету)
   
   
3. В задаче указанно как она влияет на ту или иную роль (Например, что учитель может изменить класс ученика, что в свою роль изменит доступную ему программу)
   
   
4. В задаче описан позитивный сценарий.
   
   
5. В задаче описан негативный сценарий.
   
   
6. В задаче описаны нюансы бизнес логики.
   
   
7. Если задача относится к фремиум/ премиум фичам, то там четко должно быть сформулировано, что покупается / что доступно бесплатно.
   
   
8. В задаче указанно, нужно ли собирать события и pagiview
   
   
   1. Если да, то какие.
      
      
9. В задаче указанно, какие мы делаем допущения или упрощения (Например - не делаем для кабинета учителя, мобильную версию, сделаем позже)
   
   
10. В задаче указанно какой характер она носит (например это проверка гипотезы - значит можно сделать по проще или это временный баннер - значит, можно сделать быстро, а не капитально или - это первая версия, дальше будем развивать) - в зависимости от характера, это будет влиять на потенциальную сложность и трудоемкость задачи.
    
    

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

1. Из постановки задачи ясно, какие роли и какие контексты это затрагивает.
   
   
2. Из постановки задачи ясно, какие микросервисы это затрагивает.
   
   
3. Из постановки задачи ясно, требуется доработка существующего или создание нового функционала.
   
   
4. Из постановки задачи ясно, откуда и каким образом нужно будет получать данные.
   
   
5. Из постановки задачи ясно, требуется только бекенд или фронтэнд разработка.
   
   
6. Из постановки задачи ясно, что дизайн есть и его достаточно.
   
   
7. Из постановки задачи ясно какой положительный сценарий.
   
   
8. Из постановки задачи ясно какие есть негативные сценарии.
   
   
9. Из постановки задачи ясно, какие есть корнер кейсы или нюансы бизнес логики.