Может ли Agile / Scrum использоваться одним или двумя разработчиками?

Все, что я читал и исследовал до этого момента, описывает, как Agile / Scrum отлично работает с командами от 4 до 6 человек, может даже больше.

В моем текущем магазине у нас около 8 разработчиков или около того, но, учитывая природу объема проектов и количество отделов, которые мы поддерживаем, у нас никогда не было более 1 или 2 человек, назначенных для данного проекта.

Могу ли я по-прежнему использовать Agile / Scrum с командой из 1 или 2 разработчиков? Я работаю над тем, чтобы заставить моего менеджера начать работать с этой методологией, но я должен быть в состоянии объяснить, как масштабировать вещи для небольшой команды разработчиков, или убедить их, чтобы убедиться, что мы получим больше участников по данной теме. проект.

Вы уверены, что можете использовать определенные гибкие принципы в своих проектах, вам не нужно использовать scrum, используйте то, что будет работать лучше для вас . Вы можете определенно извлечь выгоду из некоторых методов XP и некоторых методов схватки. Но, вероятно, не «по книге», команда из 1-2 человек слишком мала даже для того, что приносит небольшая перебор, начните с того, что написано в книге, а затем отбросьте все, что вы чувствуете неуместным через некоторое время. Только не отбрасывайте ретроспективы, это, безусловно, стоит потраченного времени на обсуждение ваших проблем и поиск решений для них.

Да, вы можете использовать принципы Scrum / Agile для 1 человека. Если вы хотите личной производительности, посмотрите на технику Pomodoro или GTD .

Гибкие методы подходят для небольших команд, так как с большими командами становится сложнее управлять коммуникацией. Когда один или два человека разрабатывают проект (и клиент), вы сможете легко и быстро работать. Я предлагаю вам прочитать Agile манифест как хорошее начало Agile. Для Scrum , я бы посоветовал вам взглянуть на Scrum из окопов . Канбан, кажется, сейчас в моде, и есть личный Канбан !

Будь я на вашем месте, я бы управлял и визуализировал свои задачи и приоритеты, используя Kanban, и применил бы некоторые из практик XP: разработка на основе тестов, ретроспективы и временные рамки, вероятно, хороши для начала. Позже, во время ретроспективы, вы можете определить больше практик, которые вам нужны.

Канбан очень непредсказуем. Все, что на самом деле требуется, это:

1. Вы визуализируете свой рабочий процесс
2. Вы ограничиваете свою работу в процессе (особенно полезно в вашем случае)

Идея состоит в том, что вы используете другие практики, которые вы найдете полезными, и XP является отличным источником для этих практик.

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

Абсолютно и без вопросов. Ознакомьтесь с книгой Pragmatic Programmer для получения дополнительной информации о том, как отдельные разработчики могут работать Agile. Скрам-ресурсы для отдельной работы труднее найти, однако основное понятие итеративной разработки может быть применено к рабочей группе любого размера.

http://www.pragprog.com/the-pragmatic-programmer

Я бы сказал, что вы можете использовать техники из различных гибких методов, но вы не должны использовать Scrum, как это описано в Scrum Guide, поскольку вы не можете выполнять роли. Скрам рассчитан на команды из 4-11 человек. Но многие из гибких методологий, включая Scrum, могут предоставить вам отправную точку.

Я недавно прочитал эту книгу о Scrum : Agile Управление проектами с Scrum

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

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

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

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

Я думаю, что 2 разработчика инстинктивно по умолчанию используют такую ​​систему, как Agile, даже если они не собираются явно делать это. Естественно, они будут разговаривать друг с другом и повторяться со своим ПО.

Глядя на это по-другому:

Почему вы не считаете всех 8 разработчиков членами одной команды Scrum? Таким образом, вы получаете эффект перекрестных помех между проектами. Может быть, вам даже не нужно связывать людей с конкретными проектами?

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