Чи сумісний спритний підхід із тим, щоб мати підрядних працівників?

З одного боку, спритний підхід наголошує на тісному колективі, який несе відповідальність один за одного та приймає колективну власність на проект.

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

Таким чином, моє запитання про те, чи існує принципова суперечність наявності спритного колективу з сумішшю співробітників і підрядників, і надзвичайно різних статусів, що тягнуть за собою?

EDIT: Відповіді вказують на те, що я, можливо, не висловив напруги, з якою стикаюся, тому дозвольте зробити ще один знімок.

Я постійний працівник. Спритний підхід (принаймні, як реалізовано тут) спонукає мене бачити всіх членів команди, як постійних працівників, так і підрядників, як рівних членів згуртованої команди. Корпоративний підхід до підрядників спонукає мене розглядати їх як витратні ресурси, до яких ми не повинні надмірно прив’язуватися.

Мені цікаво, як інші вирішили цю напругу.

Багато команд працюють лише з спритними підрядниками. Деякі компанії, такі як ThoughtWorks, базуються на ідеї «продати» спритних команд. Ми - команда з 10 підрядників, які працюють на великій телекомунікаційній службі, все від тієї ж підрядної компанії.

Де я бачив проблеми, коли в одній команді були 2 компанії з прокату тіл ... через деякий час команда стала проблематичною (все одно нічого не робити з спритним).

Так, це безумовно може спрацювати. Хитрість полягає в тому, щоб:

а) Структуруйте договір підрядних договорів належним чином - якщо ви платите за детальну роботу, то підрядники мають малий інтерес робити набагато більше, ніж плескати речі, щоб покласти менше годин на «шматок»
б) Продайте керівництву, що не кожен цент він платить йде безпосередньо в продукт - триватиме тренування / планування / обговорення, яке буде цілодобово, і в кінцевому підсумку покращиться продукт. Це було найважче для мене.
в) Підберіть правильних підрядників - вся спритна справа починає окупатися, якщо ви можете постійно наймати один і той же екіпаж.

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

У відповідь на вашу редакцію існують різні набори поглядів на ситуацію. Тож, щоб допомогти з’ясувати будь-яку потенційну плутанину, це допомагає зрозуміти, які перспективи застосовуються.

З точки зору команди розробників, немає різниці між підрядником та працівником. Ми всі в одній команді, і всі ми однакові. Додавання та видалення членів команди матиме однакові порушення, незалежно від того, чи є вони працівниками, так і підрядниками. Усі члени команди несуть однакові обов'язки.

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

Agile процеси більше стосуються щоденних розробок та управління способом доставки якісного продукту. Швидкі процеси менше стосуються управлінських обов'язків, таких як рішення про найм / пожежу / контракти, і більше стосуються того, як ми використовуємо ресурси, що є у нас.

Попередня відповідь

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

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

Це зводиться до того, що ви будете брати участь у першій продуктивності, коли наймете нових розробників та підрядників, поки вони не наберуть швидкості. Чим більше ви це робите, тим більше це негативно впливає на результативність вашої команди. Зрештою, стара приказка "Додавання більшої кількості розробників до вже пізнього проекту робить це пізніше". (Я вважаю, що це був Фред Брукс, якщо він не цитував когось іншого).

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

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

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

Ви абсолютно праві, коли сказали, що тимчасові контракти впливають на команду негативно. Насправді швидкість пов'язана з певною конфігурацією команди. Будь-який новий приїзд або виліт визнає недійсним розрахунок швидкості, який ви робили місяцями.

Однак це може працювати, коли підрядники не є тимчасовими. Я працював над проектом, де команда будувалася на 95% підрядників з одним або двома працівниками. Підрядники були там 2 або 3 роки до виходу проекту. Після звільнення працівники роблять технічне обслуговування. Такий спосіб роботи дуже поширений.

Узагальнити:

Спритний, і особливо Scrum, забезпечить усі свої переваги в стабільній команді .