Pull to refresh
0

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

Reading time 4 min
Views 15K
Именно столько мы уже делаем геосоциальную сеть Альтергео. Я расскажу, как нам удаётся быть и оставаться достаточно эффективными в разработке, сохраняя бодрый темп всё время.

Основное:
  • Численность команды разработчиков — 7 человек;
  • Длительность спринта — примерно две недели;
  • Стендапы каждый день;
  • Организацонные вещи хранятся в Acunote, google docs и MindMap;
  • Код хранится в SVN, новая фича — новая ветка, над одной фичей трудятся несколько разработчиков;
  • Тестирование — через unit-tests.

Два года — это очень длинный марафон, поэтому каждому важно правильно получать задачи и видеть конкретные результаты их выполнения. Для этого мы ввели систему коротких периодов, различения целей и задач плюс предельной конкретизации последних. Самая короткая ставящаяся задача — 2 минуты, самая длинная — 3 часа.

Планирование


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

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

Цель — это некое изменение в работе сервиса, которое мы хотим сделать. Например — «добавить механизм рекомендации друзей». Задача — это часть цели, которую может выполнить один человек в команде. Например «нарисовать дизайн для рекомендаций друзей на мобильном сайте».

Задач без вышестоящих целей в идеале быть не должно. Практика от идеала сильно отличается, так что у нас в каждом спринте есть две мета-задачи — «разные мелочи» и «тестирование», которые, похоже, неискоренимы.

В нашем случае планирование достаточно четко бьется на три части:
  • Выполненные задачи;
  • Постановка целей;
  • Конкретизация и обсуждение задач.

1. Что не выполнено?


Часть задач всегда остается невыполненной. Если всё выполнено — то, вероятно, задач на команду попросту не хватает. Я верю в то, что существуют люди, которые способны планировать спринты со 100% точностью, но мы так ещё не умеем.

Причины не выполнения обычно следующие:
  • Обнаружились объективные трудности (документация по API Facebook устарела, партнеры не прислали вовремя XML, дизайн три раза ходил на утверждение) и задачу не успели сделать;
  • В процессе спринта были добавлены задачи с более высоким приоритетом и задача была отложена;
  • Задача сама была добавлена в процессе спринта и за неё ещё никто не взялся;
  • Кто-то из команды заболел или взял отгул — такое тоже случается.

Невыполненная задача — это не страшно. Намного важнее понимать, почему она была не сделана и смотреть на общий процент провала по спринту. Если сделано только 70-80%, мы ищем ответ на вопрос, что случилось и почему. Второй раз такой косяк не нужен. Важно: мы ищем не виноватых, а корень проблемы.

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

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

2. Что мы хотим сделать в этом спринте?


На этом этапе речь идет о постановке целей (не задач!) на спринт. Цели ставит отдельный человек — Product Owner или PO (замполит продукта). От него требуется, в общем-то, одно — понимать как проект должен развиваться дальше. Он собирает требования и пожелания третьих лиц (отдела маркетинга, отдела связи с клиентами, программистов), тщательно просеивает их, добавляет свои идеи и, в результате, выдает список вещей, которые мы хотим осуществить.

На спринт у нас планируется 4-5 крупных целей. Примеры — «редизайн мобильного сайта под концепцию Q», «внедрение алгоритма N выборки мест для отметок на сайте», «добавление оплаты через Я.Деньги без посредников».

Цель должна быть сформулирована понятно, рекомендуется использовать правило "{глагол} {существительное} {дополнения}" — на двухнедельном спринте забыть, что именно имелось в виду при формулировке пары целей достаточно просто.

Кроме этого, на этом этапе мы решаем, какие именно несделанные задачи из прошлого спринта мы переносим в текущий, а какие — в бэклог.



3. Расписывание и обсуждение


Расписывание ведется всем коллективом — то есть PO и командой разработчиков. Цели надо превратить в задачи, проставить по каждой задаче предположительное время и, в ряде случаев, исполнителя. В нашем случае отдельно выделяются дизайн и верстка — ими всегда занимаются конкретные люди. Исполнителя на задачи программистов, напротив, стараемся сразу не назначать — они выполняются по приоритетам в режиме «кто задачу доделал, тот берет себе следующую».

Время выполнения задачи оценивается всей командой вместе — в том числе и теми, кто к этому участку кода отношения никогда не имел. По загруженности мы исходим уровня шесть часов задач в день на человека. С учетом стендапов и переговоров с коллегами это вполне разумно. Главное — это не мотивирует специалистов пытаться завысить время выполнения задачи, чтобы уложиться в «план».

Если какая-то задача занимает больше 2-3 часов — значит её надо разбивать на несколько мелких подзадач. Это не только улучшает точность оценивания времени и вносит ясность в процесс, но и облегчает работу программистам — психологически проще выполнить четыре мелких и четко поставленных задачи, ведущих к цели, чем одну крупную и аморфную.

На этом этапе часть целей может уйти в бэклог или вообще отсеяться — так бывает, если выясняется, что на выполнение цели уйдет сильно больше времени, нежели рассчитывал PO.

Итоги


Полный цикл планирования занимает около двух дней. Большая часть времени уходит на то, чтобы PO понял, какие именно цели он поставит перед командой. Расписывание задач у нас обычно проходит во вторник около двенадцати часов — понедельник отводится команде для исправления найденных недочетов и доделки мелких задач из текущего спринта. Идею проводить расписывание (равно как и стендапы) с самого утра мы сочли неудачной — на утро всегда находится какая-то срочная работа.

P.S. Если интересно, могу рассказать про конкретные механики работы с Acunote и построение процесса с точки зрения разработчика, а не тимлида.
Tags:
Hubs:
+36
Comments 36
Comments Comments 36

Articles

Information

Website
altergeo.ru
Registered
Founded
2008
Employees
Unknown
Location
Россия