Чи може Agile / Scrum використовувати 1 або 2 розробники?

Все, що я читав і досліджував до цього моменту, описує, як Agile / Scrum чудово працює з командами з приблизно 4 до 6 членів, можливо навіть більше.

У моєму теперішньому магазині у нас близько 8 розробників або близько того, але, враховуючи характер обсягу проектів і кількість відділів, які ми підтримуємо, ми ніколи не маємо більше 1 або 2 людей, присвоєних певному проекту.

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

Ви впевнені, що можете використовувати певні спритні принципи у своїх проектах, вам не потрібно використовувати scrum, використовуйте все, що буде найкраще для вас . Ви, безумовно, можете скористатися деякими методами XP та деякими методами scrum. Але, мабуть, не "за книжкою", команда на 1-2 людини просто занадто мала навіть для тієї маленької накрутки, почніть з того, що йдеться в книзі, а потім киньте все, що ви відчуєте, що через деякий час ви не відчуєте ніякого значення. Просто не кидайте ретроспективи, напевно, варто витратити час, який потрібно витратити на обговорення ваших проблем та пошук їх вирішення.

Так, ви можете використовувати принципи Scrum / Agile для 1 людини. Якщо ви хочете особистої продуктивності, подивіться техніку Pomodoro або GTD .

Швидкі методи підходять для менших команд, оскільки з більшими командами стає важче керувати спілкуванням. З 1 або 2 людьми, що розробляють проект (і замовник), ви повинні мати можливість по-спритному працювати дуже легко. Я пропоную вам прочитати маніфест спритності як хороший початок спритного. Для скрути я б запропонував подивитися на Scrum з окопів . Канбан, здається, зараз у моді, і тут є і особистий Канбан !

Якби я був ти, я керував і візуалізував би мої завдання та пріоритети за допомогою Kanban, і я застосував би деякі з практик XP: Тестова розробка, ретроспективи та таймбокс, ймовірно, добре почати з. Пізніше, під час ретроспектив, ви зможете визначити більше практик, які вважаєте себе потрібними.

Канбан дуже нерецептурний. Все, що потрібно насправді, це:

1. Ви візуалізуєте свій робочий процес
2. Ви обмежуєте свою роботу (особливо корисно у вашому випадку)

Ідея полягає в тому, що ви скористаєтесь іншими методами, які вам здаються корисними, а XP є прекрасним джерелом цих практик.

Відмова: Я ніколи цього не пробував, але це було б у верхній частині мого списку речей, щоб спробувати, якби я був у тому самому становищі.

Абсолютно і без сумнівів. Ознайомтесь з книжковою програмою «Прагматичний програміст», щоб отримати докладнішу інформацію про те, як окремі розробники можуть працювати Agile. Ресурси Scrum для індивідуальної роботи важче знайти, однак первинне поняття ітеративного розвитку може бути застосоване до будь-якої робочої групи за розмірами.

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

Я б сказав, що ви можете використовувати прийоми різних спритних методів, але не слід використовувати Scrum, як це описано в Посібнику з Scrum, оскільки ви не можете заповнити ролі. Scrum розрахований на команди з 4-11 осіб. Але багато спритних методологій, включаючи Scrum, можуть дати вам вихідну точку.

Нещодавно я прочитав цю книгу про scrum: Agile Project Management with Scrum

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

Так, ви можете використовувати спритні методи лише з двома розробниками, але вам завжди потрібен завзятий менеджер із клієнтів / продуктів. З одним розробником я б сказав, що ні, головним чином, тому що мені особисто подобається працювати в командах, а також тому, що ви не можете дійсно парувати програму, і, таким чином, пропускати всі можливості спільного використання коду. Чотири-шість розробників + один менеджер продукту - це ідеальний розмір для спритного проекту. Більше того, і підгрупи, як правило, формують, яка начебто перемагає мету.

Я точно не знаю вашої точної ситуації, але мені здається , що ви одночасно працюєте над багатьма проектами. Моя пропозиція полягає в тому, що ви повинні спробувати викласти ідею зменшення кількості одночасних проектів, а натомість мати, скажімо, дві команди, що працюють над одним проектом кожна. Це був би перший крок для покращення ситуації та полегшення застосування спритного процесу.

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

Я думаю, що 2 розробники інстинктивно замовчують таку систему, як гнучка, навіть якщо вони не ставлять за мету явно це зробити. Вони, природно, будуть розмовляти один з одним і повторювати свою позицію.

Дивлячись на це по-іншому:

Чому ви не вважаєте всіх 8 розробників членами однієї команди Scrum? Таким чином ви отримуєте ефект перехресних переговорів між проектами. Можливо, вам навіть не потрібно привертати людей до конкретних проектів ??

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