Управление проектом JustHost.ru
Начали мы со Scrum и это больше было похоже на культ карго, как часто и бывает - кто не хочет следовать ритуалам, тот лентяй и не хочет работать, вон из секты. Но мы быстро осознали что нужно не команду подстраивать под процесс, а процесс под команду. И мы уверены в том что постоянными могут быть только изменения и наш процесс это учитывает.
Сбор данных
Мы собираем "хотелки". Ими могут быть предложения пользователей, предложения команды, данные анализа конкурентов, просто мысли, статьи, письма, картинки. Собираем это в исходном виде, без первичного форматирования в Google Docs. Каждый может открыть документ и сбросить туда свои мысли.
Требования
Когда все текущие требования выполнены, мы распаковываем хотелки и устраиваем мозговой штурм. В результате появляется набор требований с приоритетом и оценка сроков их выполнения, основанная на КУЧЕ предположений. Предположение может быть таким: "Сделаем за 5 дней, тк я видел библиотечку, где всё уже реализовано", хотя на самом деле всё может быть не так радужно и потребуется много дней работы.
Оценку сроков разработки требования мы делаем хитро. Берем требование, каждый скрыто пишет на бумажке сколько может занять разработка. После этого мы "вскрываемся". Если оценки примерно схожи - берем среднее, если есть большие расхождения, внимательно слушаем обладателей очень высоких и низких оценок. Записываем все предположения, на основе которых сделаны эти оценки. Эти предположения нужно устранить!
При выработке требований мы применяем правило - не более 15 дней на разработку. Если требование занимает больше, нужно его раздробить.
Основная задача - избавиться от предположений и уточнить оценки сроков.
Итерации
Мы применяем итерации длиной в месяц (это 20 рабочих дней!). Устраиваем обсуждение перед каждой итерацией, что войдет в нее. При этом могут меняться оценки требований, могут меняться приоритеты требований, могут появляться новые требования.
Сколько требований войдет в итерацию? Мы применяем такую формулу:
реальное время работ = сумма оценок сроков выполнения требований / количество членов команды / скорость команды
Скорость команды - это такой хитрый коэффициент, который учитывает потери на коммуникацию, эффективность совместной работы, точность оценки требований, профессионализм, количество изменений требований. Считается он в конце каждой итерации:
Скорость команды = сколько выполнено / сколько запланировано
Скажем, у вас 3 человека в команде, вы запланировали требований на 60 человеко-дней, а по ходу выяснилось что часть требований заняли больше времени (по каким-то внешним причинам) суммарно на 10 дней и перешли на следующую итерацию. Получим скорость 50/60 = 0.8. Этот коэффициент теперь будет учитывать возможные внешние причины и следующие оценки сроков будут более точны.
Для начала можно взять скорость равной 0.7. Так довольно точно можем ответить на вопрос "Когда?".
Разработка
Когда становится понятно какие требования будем реализовывать в текущей итерации, назначаем ответственных за них. Кто именно это будет, должно быть понятно интуитивно, иначе у вас проблема ;)
У нас необязательно заводить список задач для каждого требования. Достаточно видеть лишь что требование в работе и кто за него отвечает. Каждый организует свою работу как хочет. Но есть негласное правило, что разбивать требование нужно минимум на 4 шага реализации, т.е. не более 5 дней на задачу (итерация 20 дней).
Scrum предписывает проводить 5-15 минутные брифы каждый день. Но мы постоянно на связи и решаем все вопросы по ходу, в течение дня.
Заключение
Приведем кратко основные принципы, которые мы выработали за годы совместной работы:
- Накапливать "хотелки", НЕ структурировать их. Процесс должен быть простым - открыл, записал мысль, закрыл.
- Чтобы не было предвзятости в оценках при обсуждении требований, пишем оценки сроков скрыто и все вместе вскрываемся. Нужно устранить все предположения и уточнить оценку сроков.
- Итерация 20 дней.
- Задача не более 5 дней.
- Всегда пересчитывать скорость команды.
Вот, как-то так )
