Pull to refresh

Comments 6

"повезло", что проблемы "решились" раздутием штата (добавили ещё фронтендеров) и "предсказуемость важнее сжатых сроков". Жаль, что так получается навсегда.


В какие примерно годы происходили описанные в статье события?

Начало преобразований это 2013 год. Оптимизация и совершенствование идут до сих пор…

Я рассказывал как у нас все устроено. Соглашусь что каждая компания имеет свою специфику и не всем наш путь подойдет.

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


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

Могли бы в двух словах рассказать сталкивались ли с такими проблемами и если да, то как боролись?

  1. Вы правы, аврал никуда не девается. Бороться с ним нужно на уровне менеджеров, команда, к сожалению ничего сделать с этим не может. (вариант не брать задачи в течении спринтов не рассматриваем). Мы постоянно общаемся с продуктовым отделом и по возможности они идут навстречу разработке. Работа по канбану скорее показывает, что команда приняла реактивную работу и не прикрывается тем что есть планирование и спринты.
  2. Я говорил что команда проводит ретроспективы каждые две недели, они позволяют выяснить что хорошо и плохо и как это улучшить (например у однотипных задач договорится что нужно описывать в них чтобы на всех этапах разработки и тестирования понимать суть задачи). Планирование перед спринтом в чистом виде нет. Но груминги проходят, в команде всегда есть плановые задачи и проектные задачи, их можно разбирать.
  3. Вы правы, зачастую задачи влетают с неполным описанием и нужно по ходу реализации уточнять. Хотя все уточнения мы проводим устно (общение с менеджером) результаты мы всегда заносим в задачу, чтобы тестеры и все причастные видели к чему пришли и что в итоге нужно сделать в задаче.

К сожалению работа в режиме аврала свойственна некоторым командам и без нее никак. Но мы всячески стараемся снизить масштабы аврала: общением с менеджерами, типизация задач и стандартизация описания требований для однотипных задач (которых в команде достаточное количество). Мы не обманываем себя что у нас жесткие спринты и планирование… Возможно в будущем как-то улучшим процессы и обязательно поделюсь.
Не совсем понятно, вы работали по Scrum, затем перешли на Kanban из-за особенностей работы маркетингового отдела, а затем обратно вернулись к Scrum и двухнедельным спринтам? А как же маркетинг с лендингами?
Не совсем так. У нас несколько команд, часть команд работает по скраму, а часть по канбану.
Sign up to leave a comment.