به طور سنتی، یک پروژه حولتیم‌های مؤلفه (یعنی UX، توسعه، کسب و کار، تستر و …)، هر نسخه‌ای که نیاز به دامنه‌ای از تخصص‌های مؤلفه داشته باشد، نیاز به درگیر کردن چندین تیم مؤلفه خواهد داشت. به طور معمول، تیم‌های مختلف مجموعه‌های مختلفی از اولویت‌ها را خواهند داشت که به طور اجتناب‌ناپذیری منجر به گلوگاه‌ها در چرخه انتشار محصول می‌شود.
طبق ویکی‌پدیا، یک تیم چندوظیفه‌ای گروهی از افراد با تخصص‌های مختلف است که به سمت یک هدف مشترک کار می‌کنند. یکی از بهترین راه‌ها برای بهبود کیفیت تیم شما این است که آن را چندوظیفه‌ای کنید. یک تیم چندوظیفه‌ای تمام مهارت‌های لازم برای تبدیل یک ایده به یک محصول کارا را دارد.
“یکتیم‌های چندوظیفه‌ایتمام شایستگی‌های لازم برای انجام کار را بدون وابستگی به دیگران که بخشی از تیم نیستند، دارند” — راهنمای اسکرام
در مقابل رویکرد تیم مؤلفه، یکتیم‌های چندوظیفه‌ایگروه‌هایی هستند که از افراد از حوزه‌های مختلف عملکردی شرکت تشکیل شده‌اند. — این تیم باید نه تنها با متخصصان فنی (توسعه‌دهندگان بک‌اند، فرانت‌اند، مهندسان QA و غیره) بلکه همچنین شامل اعضایی مانند تحلیلگران کسب و کار، متخصصان بازاریابی و UX یا هر کس دیگری که در پروژه به طور فعال شرکت می‌کند، تشکیل شود.
یکتیم خودسازمان‌دهندهتیمی است که استقلال انتخاب بهترین روش برای انجام کار خود را دارد، به جای اینکه توسط دیگران خارج از تیم هدایت شود. بر خلاف اصول مدیریت سنتی، تیم‌های خودسازمان‌دهنده و توانمند از بالا هدایت و کنترل نمی‌شوند؛ بلکه از اعضای تیم که به طور فعال و جمعی در تمام شیوه‌ها و رویدادهای اسکرام شرکت می‌کنند، تکامل می‌یابند.
تیم سنتی در مقابل تیم چابک
“یکتیم خودسازمان‌دهیشامل گروهی از کارگران دانش است که باید خود را مدیریت کنند. آنها باید استقلال داشته باشند” — پیتر دراکر.
راهنمای اسکرام نشان می‌دهد “تیم اسکرام شامل یک مالک محصول، تیم توسعه و یک اسکرام مستر است. آنها عبارتند از:
تیم‌های اسکرامهستندخودسازمان‌دهندهوچندوظیفه‌ای” — راهنمای اسکرام:
تیم مؤلفه در مقابل تیم ویژگی
رویکرد سنتی این است که محصول را به طور منطقی و معنادار به مؤلفه‌ها تقسیم کنیم و تیم‌های مؤلفه را به آنها اختصاص دهیم. با این حال، این مؤلفه‌ها از نظر دیدگاه مشتری کاملاً بی‌ربط هستند.
رویکرد تیم ویژگی اکنون تقریباً به عنوان یک روش پذیرفته شده جهانی برای سازماندهی تیم‌های خود است، در مقابل تیم فناوری، به ویژه در رویکرد تحویل مداوم، بر ویژگی‌ها (یعنی یک برش عمودی از سیستم) که نیازهای کاربر را حل می‌کند تأکید می‌کند که معمولاً می‌تواند تحویل ارزش هر ویژگی یا نرم‌افزار کارا را تسریع کند و حلقه بازخورد را از کاربران واقعی کوتاه کند. یک تیم ویژگی تمام مهارت‌های لازم برای انجام کارهای سطح وظیفه‌ای را برای انجام کار دارد. به ویژه، با فرض یک معماری سه‌لایه، اعضای تیم بر روی وظایف مربوط به GUI، لایه میانی و بخش‌های پایگاه داده این داستان کار خواهند کرد.
معایب بزرگ سازماندهی مؤلفه واضح است: این کار جریان ارزش را کند می‌کند. اکثریت ویژگی‌های سیستم وابستگی‌هایی ایجاد می‌کنند که نیاز به همکاری بین تیم‌های مؤلفه برای ساخت، استقرار و در نهایت انتشار دارند. تیم‌ها بخش زیادی از وقت خود را صرف بحث در مورد وابستگی‌ها بین تیم‌ها و آزمایش رفتار در بین مؤلفه‌ها می‌کنند به جای اینکه بتوانند ارزش نهایی کاربر را ارائه دهند.
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.