Що таке "крос-функціональна команда" насправді? [зачинено]

Загальне значення "крос-функціональної команди" - це команда, яка об'єднує фахівців у різних галузях, необхідних для досягнення мети.

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

Але де проведена лінія? Чи нормально просити розробників стати тестерами на ітерацію, якщо вона потрібна?

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

У великих компаніях ці "функції" розміщуються в бункери (напрямки управління), але для того, щоб виконати справи, вам, як правило, потрібен час когось із них.

Якщо ви робите TDD або щось подібне, так, це абсолютно нормально.

Однак загалом відповідальність за підписання на роботу розробників не повинна покладатися на тих самих розробників.

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

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

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

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

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

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

Слава Богу за те, що мені не потрібно бути розробником / адміністратором мережі .. це не весело. Ці малі справи в моєму районі .. божевільні. Хто довіряє свою мережу програмістам, Sheesh. Останнє, що вам потрібно - це побачити, як я намагаюся "налагодити" вашу таблицю маршрутизації: P

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

Так, це нормально, щоб розробники ставали тестерами, якщо це потрібно, щоб зробити роботу для ітерації.

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

Багатофункціональна команда - це не лише сфери експертизи, а ставлення до виконання справ. Члени піднімаються і беруть на себе завдання. Ви не чуєте: "Це не моя робота".

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

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