Трелло не так давно стал поддерживать русский язык. При этом мы с ним работаем уже более 2-х лет.
У нас есть 2 типа сопровождения сайтов: поддержка и разработка:

  • Поддержка — важно фиксировать время реакции на инциденты, вопросы и настройку. Быстро закрывать мелкие задачи.
  • Разработка — важно планировать изменения и правки по спринтам.

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

Тут расскажем про наш стиль работы в Трелло 🙂 Стиль Системо 🙂

Базовые правила

  • Мы создаем доску под клиента или продукт (сайт)
  • Иногда под одного клиента может быть несколько продуктов и тогда досок может быть 2 или более
  • К доске подключается команда. Изначально это может быть 2-3 участника (заказчик, разработчик и куратор), но по мере роста задач, к доске могут подключаться другие участники

Организация внутри доски

При создании доски выделяются базовые списки

Суть Канбан — разбиение задачи на списки, слева направо.

Изначально у нас было 5 списков:

  • План и вопросы — то что планируется, идеи и всяческие вопросы, стратегия (беклог)
  • Оценка — сюда тащим то что уже пора делать, то чему нужно назвать цену и срок
  • Работа — тут то что уже оплачено и выполняется
  • Тест — сюда тащим карточку которая готова и нужно принять работы заказчиком (оплатить)
  • Закрыто — тут то что принято и оплачено

Но затем пришлось добавить еще один «Данные». В нем сохраняем карточки с данными. Разные доступы, адреса, конфигурации, правила и т д.

Процесс

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

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

Если задача подготовлена и согласована, то ждем предоплату от заказчика. Предоплата как правило 50% — согласие заказчика с началом работ.

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

По готовности тащим в Тест. Там заказчик проверяет результат и принимает работы. Если работы приняты, заказчик отправляет доплату — как правило еще 50%.

После этого карточка убирается в Закрытые.

Таская карточки слева направо — идет разработка продукта по итерациям. В соответствии с манифестом Agile.

Система следующих шагов

Любой кто имеет опыт в подобных работах, знает как важно иметь систему следующих шагов. В любой момент времени должен быть известен следующий шаг. Часто сложно спрогнозировать ситуацию на 5-10 шагов вперед. Или даже на 3 шага вперед. Но следующий шаг обязательно должен быть.

Минимум в день должен быть выполнен 1 шаг. Лучше 3-4 шага. В идеале 5-10 шагов. Все зависит от способа планирования и наличия проблем по ходу решения задач.

Резюме

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


Поделитесь страницей в социальных сетях: