Управление проектом JustHost.ru

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

Сбор данных

Мы собираем "хотелки". Ими могут быть предложения пользователей, предложения команды, данные анализа конкурентов, просто мысли, статьи, письма, картинки. Собираем это в исходном виде, без первичного форматирования в Google Docs. Каждый может открыть документ и сбросить туда свои мысли.

Требования

Когда все текущие требования выполнены, мы распаковываем хотелки и устраиваем мозговой штурм. В результате появляется набор требований с приоритетом и оценка сроков их выполнения, основанная на КУЧЕ предположений. Предположение может быть таким: "Сделаем за 5 дней, тк я видел библиотечку, где всё уже реализовано", хотя на самом деле всё может быть не так радужно и потребуется много дней работы.

Оценку сроков разработки требования мы делаем хитро. Берем требование, каждый скрыто пишет на бумажке сколько может занять разработка. После этого мы "вскрываемся". Если оценки примерно схожи - берем среднее, если есть большие расхождения, внимательно слушаем обладателей очень высоких и низких оценок. Записываем все предположения, на основе которых сделаны эти оценки. Эти предположения нужно устранить!

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

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

Итерации

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

Сколько требований войдет в итерацию? Мы применяем такую формулу:

реальное время работ = сумма оценок сроков выполнения требований / количество членов команды / скорость команды

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

Скорость команды = сколько выполнено / сколько запланировано

Скажем, у вас 3 человека в команде, вы запланировали требований на 60 человеко-дней, а по ходу выяснилось что часть требований заняли больше времени (по каким-то внешним причинам) суммарно на 10 дней и перешли на следующую итерацию. Получим скорость 50/60 = 0.8. Этот коэффициент теперь будет учитывать возможные внешние причины и следующие оценки сроков будут более точны.

Для начала можно взять скорость равной 0.7. Так довольно точно можем ответить на вопрос "Когда?".

Разработка

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

У нас необязательно заводить список задач для каждого требования. Достаточно видеть лишь что требование в работе и кто за него отвечает. Каждый организует свою работу как хочет. Но есть негласное правило, что разбивать требование нужно минимум на 4 шага реализации, т.е. не более 5 дней на задачу (итерация 20 дней).

Scrum предписывает проводить 5-15 минутные брифы каждый день. Но мы постоянно на связи и решаем все вопросы по ходу, в течение дня.

Заключение

Приведем кратко основные принципы, которые мы выработали за годы совместной работы:

1. Накапливать "хотелки", НЕ структурировать их. Процесс должен быть простым - открыл, записал мысль, закрыл.
2. Чтобы не было предвзятости в оценках при обсуждении требований, пишем оценки сроков скрыто и все вместе вскрываемся. Нужно устранить все предположения и уточнить оценку сроков.
3. Итерация 20 дней.
4. Задача не более 5 дней.
5. Всегда пересчитывать скорость команды.

Вот, как-то так )