Небольшая команда разработчиков с большим количеством задач для разных проектов — как быть?

Мы небольшая команда из 4 разработчиков, которые управляют 2 большими веб-сайтами + 4-5 небольшими веб-сайтами + у нас есть канал для настройки / услуга разработки (разовая услуга).

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

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

На поддержке у нас бывают очень разные нагрузки время от времени. В некоторые дни у нас есть только несколько задач, в другие дни они могут добавить 1-2 больших задачи, а также 20-50 маленьких и средних задач.

На данный момент мы создаем такие типы задач:

  1. Быстрая задача - очень маленькие задачи могут быть выполнены без подтверждения от клиента, например <= 1-2 часа
  2. Задача - обычная задача> 1-2 часа
  3. Баг - Мы знаем, как его хотя бы представить. Иногда мы знаем, как это исправить, но иногда мы не можем это оценить (необходимо исследование, исследование занимает, например, 2 часа, а затем 5 минут, чтобы исправить это)
  4. Проблема - то, что мы даже не можем воспроизвести или не знаем, как с этим бороться. Невозможно оценить и спланировать.
  5. Эпический — используется для декомпозиции больших задач, если это возможно. Иногда используется просто для того, чтобы сгруппировать множество задач одним ответственным менеджером со стороны клиента, добавляя новые задачи, связанные с одной большой историей. Например, улучшения UI/UX с помощью AB-тестирования в течение длительного времени.

Мы делаем оценку по всем задачам, где это возможно.

Также у нас всегда есть какие-то задачи, которые долго не могут быть закрыты, даже если они выполнены с нашей стороны. Клиентские разработчики не успели/не доделали код на своей стороне (CRM, готовые продукты и т.д.) - такие задачи надо долго ждать и все эти задачи открыты в списке, чтобы о них не забыть; например, они могут быть в статусе «Тестирование клиентов», но все еще в списке.

На данный момент у нас около 200 открытых тикетов/выпусков.

Очень часто клиент просит что-то как можно скорее и, скорее всего, он спросит об этом одновременно с другим клиентом или попросит несколько задач одновременно :)

Клиенты иногда спрашивают нас, когда будет завершена какая-то будущая задача.

Какое программное обеспечение мы можем использовать, чтобы справиться с этим, и как нам нужно настроить его, чтобы наилучшим образом справиться со всем этим?

Я имею в виду, как мы можем планировать и укладываться в сроки в таком хаосе?

Также нужно сказать - в настоящее время мы используем JIRA, и я пытался создавать короткие спринты, например, 1 неделю, помещать туда работу на 1 неделю, и в этом случае я могу планировать, например, на 2-3 недели вперед. Но это не работает по следующим причинам:

  1. Иногда наша оценка сильно отличается от реальности - мы над этим работаем + планируем спринт всего на 4 дня (1 день на такие ошибки и багфикс)/
  2. Некоторые задачи выполнены на нашей стороне, но не протестированы или не подготовлены клиентом и к концу спринта нам нужно раз за разом переносить эту задачу на следующий спринт.
  3. JIRA позволяет планировать спринт только по Original Estimate, но такие задачи, как в пункте 1, уже почти выполнены, но не закрыты. Если мы их закроем и позже, через 3 недели, когда заказчик будет тестировать, мы создадим другие задачи - тогда общее время по задачам будет разделено, и мы не можем видеть, сколько времени это заняло. Если мы закроем задачу - она ​​еще не слилась с мастером - мы можем ее вообще потерять и нужно тратить время на поиск задачи и ветки для нее (используем названия веток по задачам)
  4. Некоторые задачи даже не оцениваются, как я уже писал
  5. Что делать, если задача уже в продакшене, но через 1-2 недели мы нашли в ней баг? Повторное открытие будет иметь исходную оценку, подзадачи не могут быть включены в спринт.

Я думал о EasyRedmine с их планированием ресурсов, но не уверен, что это поможет справиться со всем этим.

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

Привет, Куджа, добро пожаловать в PMSE! В вашем сценарии рассматривается несколько вопросов, таких как 1) как управлять исправлением ошибок и плановой разработкой 2) как определить приоритеты для разных клиентов 3) как справляться с действиями, которые находятся в невыполненной работе, но имеют внешние зависимости (среди другие). Хотя все вопросы очень актуальны, на них могут быть уже даны ответы на конкретные, отдельные вопросы, и они делают ваш собственный вопрос слишком широким. Не могли бы вы разбить его на разные вопросы (после поиска возможных похожих)?

Ответы (2)

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

Иногда наша оценка сильно отличается от реальности - мы над этим работаем + планируем спринт всего на 4 дня (1 день на такие ошибки и багфикс)/

Без структуры спринта превышение сметы не будет иметь таких же административных последствий.

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

Больше администрирования Sprint, которое вам не нужно делать с Kanban.

JIRA позволяет планировать спринт только по Original Estimate, но такие задачи, как в пункте 1, уже почти выполнены, но не закрыты. Если мы их закроем и позже, через 3 недели, когда заказчик будет тестировать, мы создадим другие задачи - тогда общее время по задачам будет разделено, и мы не можем видеть, сколько времени это заняло. Если мы закроем задачу - она ​​еще не слилась с мастером - мы можем ее вообще потерять и нужно тратить время на поиск задачи и ветки для нее (используем названия веток по задачам)

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

Некоторые задачи даже не оцениваются, как я уже писал

Не имеет значения на доске Канбан.

Что делать, если задача уже в продакшене, но через 1-2 недели мы нашли в ней баг? Повторное открытие будет иметь исходную оценку, подзадачи не могут быть включены в спринт.

Ошибки, указанные в тикетах «сделано», должны быть настроены как новые тикеты. Если это происходит часто, вам следует обратить внимание на надежность ваших процессов тестирования. В целом я избегаю использования подзадач в JIRA из-за ограничений. Ничто не мешает вам связать новую заявку об ошибке с исходной заявкой о функции, чтобы обеспечить отслеживаемость выполняемой вами работы.

Еще пара моментов от меня:

  1. В своих комментариях Даниэлю вы упомянули, что Канбан не позволяет вам отслеживать, «насколько далеко» продвинулись разработчики. Вы не можете надежно измерить, насколько далеко кто-то выполнил задачу — ни одна задача не будет выполнена точно в расчетное время. Отслеживание того, сколько времени теоретически «осталось» для задачи, не повлияет на способность разработчика выполнить ее. Общение является ключевым.

  2. Ограничения WIP не являются обязательными. Тот факт, что вы находитесь в пределах лимита WIP, не означает, что у вас нет проблем. Я упоминал, что общение является ключом?

  3. Цифры, которые вы называете, звучат так, будто у вас слишком много работы. Постарайтесь решить эту проблему либо за счет увеличения ресурсов разработчиков, либо за счет снижения ожиданий ваших клиентов. Изменение программного обеспечения/процесса не удвоит вашу производительность за одну ночь.

  4. Кто отдает приоритет вашей работе? Вы не упоминаете, происходит это или нет. Расстановка приоритетов более эффективна, чем выбор работы в зависимости от того, как давно она была запрошена.

Спасибо за подробный ответ. Попробую снова использовать Канбан. Приоритизация исходит от клиента, но у нас 6 клиентов, поэтому иногда они просят как можно скорее. После того, как я объединяю эти приоритеты вместе и получаю свое между ними.
Я не говорю, что мне нужно точное время для запуска и доставки, но мы должны как-то ответить, когда мы можем выполнить какую-то задачу, это очень важно, и проблема в том, что я не вижу в таком количестве задач, когда мы можем что-то выполнить, только ближайшие плановые работы. Иногда у нас есть точные сроки от клиента — что нам с ними делать? Добавить им более высокий приоритет? Иногда у меня возникает другая проблема - у разработчика есть 20 задач, часть из них в статусе Customer Testing + 10 из них мелкие, в этом месте я не вижу необходимости назначать новые задачи для этого разработчика.
Так что до сих пор я не понимаю, как вы можете управлять всем этим, не зная, сколько работы (в человеко-часах) у вас есть в настоящее время.
Я также думал о разделении задач на разные доски по какому-то свойству, например, расчетные часы <= 2 и > 2, но не уверен, что это сработает. Все это наводит меня на мысль, что мне нужен еще один джуниор или мид-разработчик, который сможет разобраться с этими багами + научить на них, и в таком случае, возможно, я смогу разделять доски )))
Re: Приоритизация - вы не можете относиться ко всем клиентам одинаково. В приоритете должны быть задачи с реальными сроками выполнения (а не сроки, которые клиенты составляют, чтобы заставить вас сделать что-то быстрее).
Re: несколько задач на одного разработчика — вы все равно должны стремиться к многопрофильной команде, что избавит от необходимости заранее загружать разработчиков множеством задач. На самом деле у каждого разработчика должна быть только одна задача, и когда он ее закончит, он должен выбрать следующий приоритет.
Re: сколько у вас работы - я думаю, что это все еще связано с тем, что у вас слишком много работы - у вас есть оценки, и вы должны быть в состоянии «подсчитать», сколько часов работы выше должности, которую вы бы расставили по приоритетам для новой задачи. в канбан-бэклоге. Дайте себе небольшую свободу действий, потому что более высокие приоритеты всегда могут появиться неожиданно. Re: отдельные доски по длительности задачи - не думаю, что это поможет. Команда должна работать с одной доски.

Я не уверен, что вариант программного обеспечения решит вашу проблему.

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

Также будьте осторожны с перегрузкой команды. Многие команды, которые перегружены, на самом деле из-за этого работают медленнее. Хенрик Кнайберг хорошо объясняет проблему в этом видео:

https://www.youtube.com/watch?v=CostXs2p6r0

Опять же, здесь вступают в действие эти строгие ограничения WIP.

Что касается программного обеспечения, Канбан-доски JIRA прекрасно работают, но если вас всего несколько человек, стикеры и белая доска тоже справятся со своей задачей.

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

Спасибо, Дэниел. У нас есть канбан-доска для всех проектов, и у нас нет проблем с ограничениями. На самом деле мы работаем над задачами от начала до конца, поэтому мы не помещаем задачи в некоторые столбцы In Progress на долгое время, и у нас нет такой проблемы. Мы доставляем много кода, но до сих пор не получаем ответа, как сказать, когда мы сможем предоставить какое-то будущее. Поэтому я не вижу здесь, сколько часов нужно разработчику, чтобы закончить свои текущие срочные задачи и спланировать и поставить какую-то новую срочную задачу или сказать клиенту, что ему нужно подождать до какой-то даты.
Более того, Канбан не позволяет увидеть, насколько загружен каждый разработчик, он показывает только количество задач, а не реальную оценку в часах + у него очень длинный список задач в таком случае.
Небольшая команда разработчиков с большим количеством задач для разных проектов — как быть?
СпросиСетьПолитика конфиденциальности1y, 0v