Что мы можем сделать для фрагментированной команды с короткими проектами?

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

Раз в день/неделю/месяц вам нужно собраться всем вместе и выяснить, когда вы нужны друг другу и как долго, и составить соответствующее расписание.

Набор стикеров на стене — по одной полосе на человека — это все, что вам нужно для отслеживания.

TL;ДР;

Вы мало что можете сделать с недостатком внимания и распределенной работой, которую поощряет ваша текущая модель. Вы можете отслеживать всю работу на канбан-доске и пытаться поддерживать поток, но видимость — это ваш лучший результат.

Межфункциональные команды

Команды гораздо более продуктивны и производят лучшее качество, чем разрозненные люди. Однако Scrum не требует, чтобы каждый член команды мог выполнять любую работу. Только то, что любая команда может справиться со всей работой, которую они берут на себя автономно.

Единственный источник правды

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

Прочтите руководство по Scrum ( http://scrumguides.org ) и попытайтесь применить содержащиеся в нем ценности и принципы.

Scrum предлагает вам ежедневный стендап. Это момент для обсуждения:

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

Разумеется, любой желающий в любое удобное время может пообщаться с коллегой из команды разработчиков. Или в официальном руководстве по Scrum:

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

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

Наконец: если вы смотрите на Scrum и Kanban и испытываете трудности с тем, чтобы Scrum «щелкнул», начните с Kanban. В нем очень мало правил, и он дает вам большую свободу, позволяя команде отслеживать и проверять, как «протекает» ваша работа.

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

Периодическая встреча является частью SCRUM. И это действительно помогает вам работать более эффективно. На этих встречах вы можете обсудить свои проблемы, запланировать помощь по другому проекту и т. д.