مدیریت، برنامه ریزی، سازماندهی، نظارت و کنترل پروژه های نرم افزاری 2 - تیم نرم افزاری

مدیریت، برنامه ریزی، سازماندهی، نظارت و کنترل پروژه های نرم افزاری 2 - تیم نرم افزاری

تقریبا می توان گفت به تعداد سازمان های توسعه دهنده نرم افزار، تعداد سازماندهی تیمی موجود است. چه خوب چه بد، سازماندهی و ساختار سازمان به این راحتی ها تغییر پذیر نیست. با مدنظر داشتن عواقب عملی و سیاسی تغییر در سازماندهی یک شرکت، این تغییرات در محدوده مدیریت پروژه نرم افزاری نیستند. اگرچه سازماندهی افرادی که مستقیما درگیر پروژه نرم افزاری جدید هستند در محدوده مدیریت پروژه است.
گزینه های زیر برای اعمال برنامه منابع انسانی برای پروژه ای که به تعداد n نفر به مدت k سال نیاز دارد وجود دارد:
1- N نفر به تعداد m وظیفه متفاوت انتساب داده می شوند و به نسبت کار ترکیبی کمی رخ خواهد داد. هماهنگی وظیفه مدیر پروژه ای خواهد بود که ممکن است تعداد 6 پروژه دیگر تحت مدیریت داشته باشد.
2- N نفر به تعداد m وظیفه متفاوت انتساب داده می شوند (mبنابراین تیمهای غیر رسمی شکل می گیرند. یک رهبری تیمی ad-hoc یا اقتضایی مورد نیاز است. هماهنگی میان تیمها وظیفه مدیر پروژه خواهد بود.
3- N نفر به t تیم تقسیم شده و هر تیم یک یا چند وظیفه را انجام میدهد. هر تیم ساختاری دارد که برای کلیه تیمهای یک پروژه تعریف شده است. هماهنگی باید توسط هم تیم و هم مدیر پروژه صورت گیرد.
اگرچه ممکن است بتوان هر کدام روشهای گفته شده را زیر سوال برد، ولی شواهد نشان می دهند گزینه سوم بهتر نتیجه را بهمراه خواهد داشت.
بهترین ساختار تیم بستگی به استیل مدیریتی سازمان شما، تعداد افراد موجود در تیم، توانایی های آنها و پیچیدگی کل مسئله دارد. ماتی [MAN81] سه روش کلی برای سازماندهی تیم پیشنهاد می کند:

غیرمتمرکز دموکراتیک (DD):

 این تیم مهندسی نرم افزار رهبر تیمی دائمی ندارد. همچنین هماهنگی وظایف برای مدت زمان کوتاهی برنامه ریزی شده و بعد از مدتی با ظهور وظایف جدید ممکن است تغییر یابند. تصمیم گیری بر حل مسائل و راه حلها و روشها با رضایت گروه صورت می گیرد. ارتباط اعضای تیم نیز افقی است.

غیرمتمرکز کنترل شده (CD):

این تیم مهندسی نرم افزار رهبری برای هماهنگی وظایف داشته و همچنین دارای رهبران ثانویه برای زیر وظایف دارد. حل مسئله همچنان به صورت گروهی صورت گرفته ولی پیاده سازی راه حلها میان زیر گروه های مختلف توسط رهبر تیم تقسیم می شود. ارتباط زیرگروه ها و افراد افقی بوده ولی ارتباط عمودی در راستای سلسله مراتب کنترلی نیز شکل می گیرد.

متمرکز کنترل شده (CD):

حل مسئله در سطوح بالا و هماهنگی داخلی تیم توسط رهبر تیم صورت میگیرد. ارتباط میان رهبر تیم و اعضای آن عمودی است.
مانتی [MAN81] هفت فاکتور پروژه که باید در زمان بندی پروژه مهندسی نرم افزار مدنظر قرار بگیرند را بیان کرده است:
1- دشواری مسئله.
2- سایز محصول نهایی (تعداد خط کد یا نقاط عملکرد)
3- مدت زمانی که تیم در کنار هم می مانند (طول عمر تیم)
4- درجه ای که می توان محصول را ماژولار کرد.
5- کیفیت و قابل اطمینان بودن مورد نیاز برای محصول
6- استحکام و مهم بودن در سروقت بودن ارائه محصول
7- درجه اجتماعی بودن یا نیاز به ارتباط (جلسات گوناگون و ...)
از آنجایی که روشهای متمرکز سرعت بالای دارند، برای پروژه های ساده مناسب هستند. تیمهای غیرمتمرکز راه حلهای بهتر و بیشتری تولید خواهند نمود و از این رو احتمال موفقیتشان برای مسائل پیچیده بیشتر است. از آنجا که یک تیم CD متمرکز می باشد، چه تیم CD و چه CC برای مسائل ساده بهترند. ساختار DD برای مسائل دشوار بهترین گزینه است.
از آنجا که کارایی تیم به صورت وارونه با تعداد افراد تیم تناسب دارد، باید بخوبی هدایت شده و پروژه های بزرگ باید دارای ساختارهای CD و CC باشند تا بتوان زیرگروه در آنها تعریف نمود. مدت زمانی که یک تیم با هم میمانند بر روحیه تیم تاثیر دارد. تحقیقات نشان داده ساختارهای DD بر روحیه و رضایت افراد و تیم تاثیر مثبتی دارد و برای تیمهایی که مدت زمان طولانی با هم خواهند بود مناسب است.
ساختار DD از طرفی برای پروژه های با ماژولاریته پایین باید استفاده شود زیرا تعداد ارتباطات در این ساختار بالا است. ولی وقتی که ماژولاریته مورد نیاز است باید ساختارهای CD یا CC را پیش گرفت.
تحقیقات نشان داده تیمهای CC و CD خطا و عیب کمتری نسبت به تیم های DD تولید می نمایند، البته بستگی به فرایندهای تضمین کیفیتی که تیم انجام میدهد نیز دارد. تیم های غیرمتمرکز زمان بیشتری برای انجام پروژه ها نسبت به تیم های متمرکز نیاز دارند و برای مسائلی که نیاز به تعامل بالا دارند بهترین هستند.
کنستانتین [CON93] چهار نمونه برای تیمهای مهندسی نرم افزار ارائه داده است:
1- نمونه بسته، تیم را در راستای یک سلسله مراتب اختیار و قدرت ساختار دهی می کند (مانند ساختار CC).
2- نمونه تصادفی، ساختار تیم را آزاد بسته و بیشتر به ابتکار اعضای تیم وابسته است. وقتی که به یک پیشرفت غیرمنتظره نیاز است تیمهای با ساختار آزاد بهترند. ولی این ساختار زمانی که تیم نیاز به پیشرفت منظم داشته باشد ممکن است به مشکل برخورد.
3- نمونه باز، تلاش میشود تیم به گونه ای چیده شود که مقداری از کنترل موجود در تیمهای بسته را به همراه ابتکار موجود در تیمهای تصادفی داشته باشد. کار به صورت همکاری با ضریب تعامل بالای افراد انجام شده و تصمیمات به صورت گروهی اتخاذ میشوند. این تیمها برای مسائل دشوار بسیار کارامد بوده ولی ممکن است به اندازه سایر تیمها تاثیرگذار نباشند.
4- نمونه همگام، مسئله مربوطه تقسیم شده و اعضای تیم به گونه ای تقسیم بندی می شودند که بر تکه های کوچک مسئله با حداقل تعامل میان اعضا کار کنند.
در گذشته اولین ساختارهای تیمها متمرکز کنترل شده (CD) بوده است و به آن تیم برنامه نویسی رئیس (chief programmer team) گفته میشد. این ساختار اولین بار توسط هارلان میلز مطرح شد و توسط بیکر [BAK72] توضیح داده شد. هسته تیم توسط یک مهندس ارشد شکل گرفته (برنامه نویس رئیس) که کلیه فعالیت های تیم را برنامه ریزی، زمانبندی و هماهنگی میکند، افراد فنی در این تیم (بین 2 تا 5 نفر) تحلیل و فعالیت های تیم را هدایت می نمایند و مهندس پشتیبان که به عنوان نماینده مدیر او را پشتیبانی و یاری کرده و در زمان نبود وی اختیارات او را به عهده می گیرد. برای برنامه نویس رئیس معمولا تعدادی متخصص (مثلا متخصص مخابرات یا بانک اطلاعاتی)، نیروهای پشتیبان، و مهندسین کتابدار (که مسئول تهیه مستندات پروژه، راهنما، پیکره بندی سیستم و ... هستند) خدمت می کنند؛ همچنین به تیم در تحقیقات ارزیابی و آماده سازی اسناد کمک می کنند. وظیفه یک مهندس کتابدار بسیار حیاطی است، وی در عین حال به عنوان هماهنگ کننده، و یا ارزیاب پیکربندی سیستم میتواند عمل کند.
کنستانتین یک نمونه دیگری از یک تیم غیر متمرکز دموکراتیک (DD) ارائه داده است که از تیم های خلاق غیرمستقل طرفداری می کند و می توان آنرا بی نظمی و نوآوری نامید. در حقیقت در این تمیها که فعال و باز است باید خلاقیت، همبستگی و انرژی بالا منجر به کارایی بالا گردد.
برای دسترسی به کارایی بالا:
اعضای تیم باید به یکدیگر اعتماد داشته باشند.
توزیع مهارتها باید متناسب با مسئله باشد.
افراد تکرو از تیم باید خارج شوند (اگر قرار است همبستگی تیم حفظ شود).
بدون درنظر گرفتن ساختار تیم، هدف برای هر مدیر پروژه ای باید تشکیل تیمی است که دارای همبستگی و چسبندگی بالا باشد. دمارکو و لیستر درباره این موضوع بحث کرده اند:
ما از کلمه تیم در جهان کسب و کار استفاده میکنیم، هر تعداد افرادی که در کنار یکدیگر کار میکنند. ولی خیلی از این تیمها واقعا تیم به معنای واقعی نیستند. آنها هیج تعریفی از موفقیت و روح تیمی ندارند. آنچه موجود نیست، پدیده ای به معنای ژل است. یک تیم ژل گروهی از افراد است که محکم بهم گره خورده اند و کل آن بهتر و قوی تر از مجموع تک تک اعضا عمل میکند.
وقتی که یک تیم ژل می شود، احتمال موفقیت بسیار افزایش می یابد. تیم غیرقابل توقف بوده و کسی جلودار موفقیت آن نخواهد بود... آنها نیاز نیست به روش سنتی مدیریت شوند و یا تحریک شوند، بلکه محرک درونی قوی دارند.
دمارکو و لیستر اذعان داشتند افراد یک تیم ژل شده در تیم کارایی بسیار بیشتری نسبت به میانگین دارند. آنها به یک هدف مشترک، فرهنگ مشترک و همچنین حس نخبگی مشترکی دست می یابند و همین است که آنها را متمایز می کند. ولی همه تیمها ژل نمیشوند. در حقیقت بسیاری از تیم ها از چیزی به نام مسمومیت تیمی رنج میبرند. او پنج مورد را که احتمال دارد تیم مسموم شود ذکر نمود [JAC98]:
1- محل کاری آشفته که در آن اعضای تیم تمرکزشان را از دست داده و انرژی آنها هدر می رود.
2- ناامیدی شدید که بدلایل فنی، شخصی و یا تجاری رخ میدهد و منجر به اختلاف میان اعضا می گردد.
3- فرایندهای تکه تکه یا غیر هماهنگ یا مدل فرایند اشتباه که همانند بن بستی جهت دستیابی به هدف میباشد.
4- نبود تعریف دقیقی از نقشها که منجر به مسئولیت پذیری پایین شده.
5- همواره و مدام در معرض شکست قرار گرفتن که منجر به کاهش اعتمادبنفس و روحیه می شود.
جکمن یکسری پادزهر نیز برای حل این مشکلات ارائه کرده است.
برای دوری از تشکیل یک تیم آشفته، مدیر پروژه باید مطمئن باشد تیمش به کلیه منابع مورد نیاز برای انجام کار دسترسی دارد و اهداف مگر در صورت لزوم نباید تغییر یابند. علاوه براین اخبار بد نباید مخفی باقی بمانند و باید هرچه زودتر تیم را از آنها آگاه نمود (در صورتی که همچنان برای عکس العمل نشان دادن تیم زمان باقی باشد).
اگرچه ناامیدی دلایل بسیاری دارد ولی برای افراد در نرم افزار بیشتر زمانی رخ میدهد که حس کنند نمیتوانند اوضاع را کنترل کنند. یک تیم نرم افزار با داشتن مسئولیت کافی برای تصمیم گیری می تواند از آن جلوگیری کند. هرچه بیشتر به تیم مسئولیت و قدرت کنترل داده شود، ناامیدی و سردرگمی کمتر خواهد شد.
از یک فرایند نرم افزاری که اشتباه انتخاب شده باشد (برای مثال وظایف کاری بیمورد یا سنگین یا محصولات کاری اشتباه)، می توان به دو صورت اجتناب کرد. 1) مطمئن باشیم سختی مسئله و محصولی که دارد ساخته می شود متناسب با سختی فرایندی است که اتخاذ شده است. 2) اجازه دهیم تا تیم بتواند فرایند را انتخاب کند (با شناخت کامل، که وقتی انجام شد تیم در قبال تحویل محصول باکیفیت مسئول باشد).
مدیر پروژه با همکاری تیم، وظایف را پالایش نموده و قبل از آغاز پروژه آنها را تعریف کرده باشد. خود تیم باید مکانیزمهایی را برای مسئولیت پذیری تعریف کند (بررسی های فنی رسمی formal technical reviews بهترین روش است) و یکسری روشهای اصلاحی برای زمانی که عضوی از تیم نتوانست به خوبی عمل کند تعریف نماید.
هر تیم نرم افزاری یکسری کاستی ها و خطاهایی را تجربه کرده است. برای جلوگیری از ایجاد فضایی با خطاهای بسیار باید از تکنیک های تیمی، بازخورد و روش حل مسئله استفاده نمود. علاوه براین خطا توسط یکی از اعضای تیم باید به عنوان خطایی از تیم شناخته شود. این باعث تشکیل تیمی میشود که تلاش دارد اعضای تیم را کمک کند و برخلاف تیمهای سمی یک نفر را مقصر ندانسته و اطمینان اعضا به یکدیگر کاهش نمی یابد. 
علاوه بر 5 سمی که گفته شد، یک تیم ممکن است با خصیصه های انسانی متفاوت اعضا مبارزه کند. برخی از اعضا برونگرا و بعضی درونگرا هستند. بعضی تنها زمانی که مسئله منطقی روی میز است تصمیم گیری میکنند ولی برخی دیگر بر اساس احساسشان تصمیم می گیرند. برخی به یک برنامه زمانی و وظایف کاری دقیق و مشخص برای انجام نیاز دارند بلکه برخی از محیطهای باز که میتوانند خلاقیت به خرج دهند استقبال می کنند. بعضی کارها را بسیار زودتر از ضرب العجل به اتمام می رسانند تا فشار دقایق آخر را بکاهند، برخی در دقایق آخر انرژی گرفته و کار را انجام می دهند. توضیح جزئیات روانشناسی مربوط به افراد تیم خارج از محدوده این کتاب است. ولی باید بدانید فهمیدن خصوصیات افراد اولین قدم برای تشکیل یک تیم ژل شده است.

بازدید: 1252

نظرات

ارسال پاسخ