Как ускорить разработку проекта

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

Типы задач

Практика показывает, что в проекте есть задачи разного типа:

  1. новый функционал
  2. улучшение функционала
  3. ошибка
  4. технические задачи

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

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

количество задач на следующий месяц / 3

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

Распределяя функционал

Проект всегда имеет распределение:

  1. компоненты
  2. модули
  3. библиотеки

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

Заметка: задачи лучше распределять ориентируясь на способности и потребности разработчика.

Принципы распределения

Практичная команда: каждый член команды должен знать основной функционал + 1 дополнительный сложный или несколько среднесложных дополнительных функционалов.

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

Автор и исполнитель

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

ШагИсполнительАвтор
1При необходимости пишет план реализации в комментарии к задаче или REAME.md 
2 Проводит ревью шага 1
3Создает файлы/классы/методы без реализации 
4 Проводит ревью шага 3
5Пишет код реализации и отправляет код на ревью 
6 Проводит ревью шага 5
7Пишет тесты 
8 Проводит ревью шага 7

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

Допущения:

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

Совет: можно немного освободить Автора (Тимлида) от ряда замечани, если между шагом 7 и 8 один из членов команды проведет предварительное ревью.

Мини-команда

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

В книге "Фредерик Брукс. Мифический человеко-месяц" описывается хороший рецепт, реализация которого для двух человек мне видится в создании мини-команды с ролями Исполнитель и Ассистент, которые почти параллельно занимаются следующими видами деятельности в рамках одной задачи: 

ИсполнительАссистент
Пишет план реализации в самой задаче или REAME.mdПроводит ревью
Создает файлы/классы/методы без реализацииПроводит ревью
Пишет код реализацииПишет тесты
Отправляет код на ревью, проводит ревью тестов написанных АссистентомПроводит ревью

Любой член команды может быть свободен какое-то время, это время он может потратить с пользой на:

  • обсуждение деталей с бизнесом
  • обсуждение деталей с руководителем
  • выполнение другой задачи (см. выше типы задач)

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

Кроме того, такой подход позволяет исключить Bus-фактор.

Теперь добавим Автора задачи в мини-команду. Первым делом Автор обязан провести устную беседу с Исполнителем и Ассистентом (чтобы все участники правильно поняли задачу) и инициирует процесс реализации:

ШагИсполнительАссистентАвтор
1Пишет план реализации в самой задаче или REAME.md  
2 Проводит ревью шага 1 
3  Проводит ревью шага 1
4Создает файлы/классы/методы без реализацииРезолвит шаг 3 
5 Проводит ревью шага 4 
6  Проводит ревью шага 4
7Пишет код реализации и отправляет код на ревьюРезолвит шаг 6 и пишет тесты 
8Проводит ревью тестов написанных АссистентомПроводит ревью шага 7Ожидает кросс-резолва между Исполнителем и Ассистентом
9  Проводит ревью шага 8

Как видно Ассистент должен резолвить ревью Автора, это нужно чтобы следующий раз учитывать особенности ревью, которое проводит Автор + для более глубокого погружения в задачу.

Стоит добавить, что у задачи с типом "ошибка", процесс другой (более простой).

Проблемы

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

Заместители

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

Проектировщик

Задача руководителя:

  1. Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.
  2. Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.
  3. Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.
  4. Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.

09.01.2011 10:18

Комментарии

Комментариев пока нет.


Copyrights © 2007 - 2026 YaPro.Ru