شما اینجایید
خانه > دفتر مدیریت پروژه > اصول استانداردی برای گذار تیم‌های چابک وجود ندارد

اصول استانداردی برای گذار تیم‌های چابک وجود ندارد

اصول استانداردی برای گذار تیم‌های چابک وجود ندارد

تیم‌ پروژه‌ای که در حال گذار به چابک است، معمولاً درگیر نقش‌های پروژه و ساختار کلی تیمی می‌شود. گذار تیم به چابک مستلزمِ تغییر در طرز فکر، سازمان‌دهی تیمی، و فرهنگ تیمی است.

معمولاً می‌پرسند:

  • جایگاه مدیریت پروژه در تیم چابک چگونه تعریف می‌شود؟
  • آیا اسکرام‌مستر [۱] همان مدیر پروژه است؟
  • چه کسی اولویت‌ها را برای توسعه‌دهندگان نرم‌افزار تعیین می‌کند؟
  • چه کسی نیازمندی‌ها را گردآوری می‌کند؟
  • چابک برای سازمان‌دهی یک سازمان با تیم‌های جهانی [۲] «واقعاً چه‌طور کار می‌کنند؟»

برای فهمیدن تفاوت تیم‌های چابک، خوب است که نحوۀ سازمان‌دهی تیم‌های سنتی را بفهمیم:

سازمان‌دهی تیم‌های سنتی

تیم سنتیِ توسعۀ نرم‌افزار از نقش‌های زیر تشکیل شده است:

نقش مسئولیت
مشتری یا کارآور [۳] تجاری نیازمندی‌ها و دانش فرایند کسب‌وکار را فراهم می‌کند؛ کارشناس موضوع کار.
مدیران پروژه فرایندهای مدیریتی پروژه را – آماده‌سازی، برنامه‌ریزی، اجرا، نظارت، کنترل و بستن- برای تحویل موفقیت‌آمیز پروژه مدیریت می‌کنند.
راهبر فنی راهکار فنی را به‌پیش می‌برد و تیم توسعۀ نرم‌افزار را هدایت می‌کند.
معمار برنامه کاربردی معماریِ برنامۀ کاربردی را بر مبنای استانداردها، زیرساخت رایانه‌ای و محیط شبکۀ شرکت طراحی می‌کند.
تحلیلگر کسب‌وکار نیازمندی‌ها را از مشتری کسب‌وکار گردآوری می‌کند.
تحلیلگر سیستم‌ها برای توسعۀ نرم‌افزار، نیازمندی‌های تجاری را به نیازمندی‌های ویژه سیستم ترجمه می‌کند.
توسعه‌دهندگان به طراحی و کدنویسی و آزمونِ واحد [۴] راهکار نرم‌افزاری می‌پردازد.
راهبر آزمون [۵] و تحلیل‌گر آزمون کار آزمودن را هدایت می‌کند و راهکارهای نرم‌افزاری را برای برآوردِ نیازمندی‌های تجاری بررسی می‌کند.
راهبر زیرساخت قرارگیری سرور را با زیرساخت منطبق می‌کند.
سرپرست پایگاه‌داده‌ پایگاه‌داده‌ را ایجاد و نگهداری می‌کند.

 تمام این منابع عموماً از مخازن منابع [۶] مختلفی نشئت می‌گیرند. وقتی یک منبع، واحد کاری خود را تکمیل می‌کند و برای تکمیل کار اضافی به عضو دیگر تیم درخواست ارسال می‌شود، تأخیرها مشخص می‌شوند. اگر تابه‌حال مجبور شده باشید که معماری جدیدی را ارائه کنید، یک سرور را در مرکز داده‌های سازمانی معرفی کنید و یا روندِ یک توسعه، QA یا تولید پایگاه‌داده‌ را اصلاح کنید، با محدودیت‌های این مدل آشنا هستید.

سازمان‌دهی تیم چابک

اگر کتابی در مورد چابک یا اسکرام بخوانید، معمولاً می‌خوانید که بهترین تیم‌ها تیم‌های خودسازمان‌ده، میان‌کارکردی [۷] و خودراهبر هستند. راهنمای اسکرام فقط سه نقش اصلی در اسکرام را تعریف می‌کند: صاحب محصول، اسکرام‌مستر و تیم توسعه.

نقش مسئولیت
صاحب محصول فقط این شخص مسئول محصول است و باید مطمئن شود که نیازمندی‌ها در بک‌لاگِ [۸] محصول به‌خوبی تعریف شده، اولویت‌بندی شده، و به تیم انتقال داده می‌شوند.
اسکرام‌مستر روش‌های اسکرام را آسان می‌کند، برای مدیریت فعالیت‌های بک‌لاگ محصول از صاحب محصول پشتیبانی می‌کند و تیم توسعه را هدایت می‌کند.
تیم توسعه گروهی که کاری را که برای تحویل پروژه لازم است انجام می‌دهند.

تیم‌هایی که به مدل‌های چابک گذار می‌کنند، از اینکه نمی‌دانند جایگاه تحلیل‌گران، راهبران فنی، مدیریت پروژه و دیگر نقش‌های سنتی چه تغییری می‌کند، احساس سرگردانی می‌کنند. برحسب میزان بلوغ چابک در یک سازمان، این نقش‌ها هنوز درون تیم وجود خواهند داشت.

یادآوری می‌شود که تیم توسعه گروهی است که محصول را تحویل می‌دهد و می‌تواند شامل مدیر پروژه، راهبر آزمون و تحلیلگران تجاری باشد.

سازمان‌های بسیاری به چابک شدن فکر می‌کنند؛ اما همیشه از یک صاحب محصولی که خود را وقف می‌کند و نقش صاحب محصول را تمام‌و‌کمال انجام می‌دهد برخوردار نیستند. در این موارد تیم باید خود را با یک تحلیلگر کسب‌وکار قدرتمند تقویت کند. شاید در این تیم پروژه، خودکارسازیِ آزمون [۹] یا توسعۀ آزمون‌محور [۱۰] اجرا نشود، بنابراین نقش سنتی راهبری آزمون باقی می‌ماند.

یکی از مفاهیمی که در تیم‌های چابکی که به بلوغ رسیده‌اند شاهد هستیم، ویژگی میان‌کارکردی [۱۱] اعضای تیم است. یعنی مهارت‌های تحلیلگریِ کسب‌وکار، تحلیلگریِ سیستم، توسعۀ پایگاه‌داده‌، خودکارسازی آزمون و مدیریت پروژه، به‌جای اینکه به‌صورت نقش‌های مجزا برای افراد تعریف شوند، در حیطۀ عملکرد تیمی موجودند.

آخرین تیمی را که عملکرد بالایی داشت به یاد بیاورید. بعید نیست که در آن تیم به‌جای اینکه برای هر مهارت، تکیه بر فرد مجزایی باشد، تمام افراد تمام مهارت‌ها را داشتند. چه‌بسا تیمی که بهترین عملکرد را دارد، هنوز به مدیر پروژه متکی باشد؛ اما همان‌قدر که در تحلیل‌های سیستمی و تجاری توانمند است، از بهترین روش‌های آزمون شناخت دارد، زمینۀ تجاری را نیز می‌فهمد و از مهارت‌های توسعۀ پایگاه‌های داده‌ها برخوردار است.

در مقابل مهارت‌های تیمی که بدترین عملکرد را دارد، در نقش‌های جدا پراکنده‌اند. برای تغییر پایگاه‌داده‌ در محیط توسعه، باید به تیم پایگاه‌داده، درخواست ارسال شود؛  اما چون تیم به‌موقع پاسخ نمی‌دهد، مسئله شدت می‌یابد. منابعی که به‌طور جدا به آزمون می‌پردازند، در دوره‌های معین زمانی تخصیص داده می‌شوند و غالباً نمی‌توانند به شیوۀ زمانمندی عمل کنند. درنتیجه سرعت، تحت‌الشعاع قرار می‌گیرد و انگیزۀ تیم کاهش می‌یابد.

ظاهراً تیم‌هایی که با اجایل کار نمی‌کنند، چندان چابک نیستند!

پیشرفت با هر اسپرینت

تشکیل تیمی که میان‌کارکردی [۱۲]، خودسازمان‌ده و خودراهبر است نتیجۀ تکامل و بلوغ چابک است. بسیاری از تیم‌ها هنوز درگیر تثبیت در این وضعیت هستند زیرا بسیاری از سازمان‌ها سیلوهایی [۱۳] دارند که مانعِ کارکرد مؤثر تیم‌ها می‌شوند. دیگر تیم‌ها نیز کلاً با تغییر از تیمی که تعریف بالابه‌پایین دارد، به تیمی که رویکرد مرکزگرا دارد مقاومت می‌کنند (نحوۀ آسان کردن گذار تیم را در خط دید بخوانید). خوشبختانه با روش‌های چابک می‌توان با حلقه‌های بازخوردی [۱۴] (فیدبکی) تیم را به پیشرفت واداشت.

فیدبک + Agile
نمونه‌ای از حلقۀ بازخوردی (فیدبکی) در تیم‌های چابک

شاید تیم‌هایی که هنوز گذار را کامل طی نکرده‌اند، در جلسۀ بک‌لاگِ محصول هنوز در ارائۀ نقاط داستان تعلل کنند. چه‌بسا اعضای تیم برای تائید، هنوز به رهبر تیم چشم می‌دوزند؛ زیرا قبلاً رهبر تیم مستقیماً تیم را به‌پیش می‌برد. احتمالاً چند اسپرینت طول می‌کشد که تیم با فرایندهای جدید عادت کنند؛ با به‌کارگیری تکنیک‌های مختلف چابک و با هر اسپرینت پیشرفت می‌کنند.

گذار دستورالعمل کتابی ندارد

اگر در حال اجرای روش چابک در سازمان خود هستید، متوجه می‌شوید که برای گذار به چابک، اصول استانداردی وجود ندارد. تیم‌های خودْراهنما، میان‌کارکردی و خودسازمان‌ده یک‌روزه ظاهر نمی‌شوند. تا زمانی که این مهارت‌ها در یک تیمِ خوداتکا شکل بگیرند، استفادۀ تکمیلی از نقش‌های سنتی کار بجایی است. تیم‌های پروژه باید به تعهدات خود بپردازند و تشکیل تیم به‌طور سنتی یا چابک همچنان از تیم رهبری و مجموعۀ مهارت‌های تیمی موجود تأثیر می پذیرد. رویکردهای مختلف بسیاری برای اجرای پروژه است اما باید ساختار تیمی مناسب خود را بشناسیم.


[۱] Scrum Master

[۲] تیم‌های جهانی که گاهی تیم‌های کاری چندملیتی نامیده می‌شوند، نوع بخصوصی از تیم‌های کاری هستند که اعضای آن اهل دو یا تعداد بیشتری ملیت یا فرهنگ متفاوت هستند. درحالی که معنای تیم‌های جهانی یا global group  الزاماً ایجاب نمی‌کند که اعضای تیم ازلحاظ جغرافیایی پراکنده باشند (مثل کار مجازی) اما در بیشتر تیم‌های جهانی امروز، تیم‌های جهانی غالباً با تیم‌های مجازی جهانی یکسان گرفته می‌شوند. (کتاب‌شناسی آکسفورد)

[۳] Client

[۴] Unit test

[۵] test

[۶] Resource pool  مجموعه‌ای از منابع که به وظایف پروژه تخصیص داده می‌شوند. یک مخزن منابع را می‌توان به یک پروژه یا وظیفه یا چندین پروژه تخصیص داد.

[۷] Cross functional

[۸] backlog

[۹] Test automation

[۱۰] Test-driven development

[۱۱] رجوع شود به زیرنویس بعدی

[۱۲] تیم میان‌کارکردی یا Cross-functional به گروهی از افراد می‌گویند که با کارکردها و تخصص‌های مختلف حول یک هدف مشترک همکاری می‌کنند. تیم میان‌کارکردی می‌تواند شامل بخش‌های مالی، بازاریابی، عملیات و منابع انسانی باشد. معمولاً اعضای تیم از تمام سطوح سازمانی هستند و ممکن است خارج از سازمان نیز باشند (مانند تولیدکنندگان، مشتریان کلیدی یا مشاوران).

[۱۳] سیلو (silo) که در اصل یک کلمۀ فرانسوی و به معنای گودالی است که دانه‌ها، علوفه‌ها، ریشه‌ها  و نظایر آن را نگهداری می‌کنند (دهخدا). زمانی سیلوها در یک سازمان رخ می‌دهد که چندین بخش یا گروهِ درون سازمان، تمایلی به اشتراک اطلاعات و دانش با دیگر افراد در آن سازمان ندارند. نتیجۀ سیلوها ایجاد «ذهنیت سیلویی» در سازمان است.

[۱۴] Feedback loop

پاسخ دهید

بالا