جایگاه چهارچوب های مدیریت و توسعه پروژه در پروژه های نرم افزاری

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

حالت اول: برنامه نویس و یا تیمی از برنامه نویسان تازه کار، به تدریج و به مرور زمان با انجام پروژه‌های متفاوت که هرکدام چالش‌های خاص خودشان را دارند، به یک ریتم کاری نسبتاً ثابتی رسیده و به مرور زمان این ریتم کاری را تکمیل‌تر می‌کنند. شاید در مورد برنامه نویسی که به تنهایی کار می‌کند، دستیابی به یک ریتم کاری ثابت می‌تواند برای مدت زمان طولانی‌تر و در بلندمدت کارساز باشد. ولی در مورد تیم‌ها این امکان وجود دارد که بعد از رسیدن به این ریتم کاری ثابت باز دچار مشکل شوند. مثلاً با آمدن و از دست دادن عضو یا عضوهای جدید.

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

اصولاً تمامی برنامه نویسان باید با فریمورک های مدیریت و توسعه پروژه‌های نرم افزاری حداقل آشنایی را داشته باشند (تسلط لازم نیست). در هر حال تسلط بر این فریمورک ها خود یک تخصص است که ارتباطی به برنامه نویسی ندارد.

آموزش کامل و جزء به جزء این فریمورک ها خارج از موضوع این بحث است و عملاً امکان بررسی آن در قالب چند صفحه کوتاه وجود ندارد. ولی بنظر مناسب می‌رسد که مسیر کلی و roadmap این تخصص بررسی شود تا بتوان با انواع متدها آشنا شد و درک کرد که برای هر نوع پروژه باید از چه متدهایی استفاده شود.

این مسئله را همواره در نظر داشته باشید که پروژه‌های نرم افزاری در مقایسه با انواع پروژه‌های دیگر، متفاوت و پیچیده‌تر هستند. گستردگی، به روز بودن و پیشرفت دائمی تکنولوژی‌های دخیل در پروژه‌های نرم افزاری، همواره این نوع پروژه‌ها را از همان نقطه شروع پیچیده می‌کند و موجب می‌گردد که طبق دستور، قوانین، اصول اولیه و پیش فرض، امکان تصمیم گیری وجود نداشته باشد و لذا در هر پروژه بسته به شرایط و نیاز آن پروژه باید تصمیم گیری انجام شود.

تمامی فریمورک ها به یکی از دو دسته Structured Highly و Flexible Highly و یا خانواده Agile تعلق دارند. به احتمال زیاد با نام Agile آشنا باشید. این مفهوم در دانشگاه برای دانشجویان رشته علوم کامپیوتر، مهندسی کامپیوتر و آی تی تدریس می‌شود. کیفیت مطالبی که ارائه می‌گردد، معمولاً به اندازه‌ای نیست که دانشجویان بتوانند اهمیت موضوع و کاربردی بودن آن را رو درک کنند. به خصوص به علت این که در قالب دروس تئوری در دانشگاه ارائه می‌شود، دانشجویان کامپیوتر و آی تی به صورت پیش فرض اهمیت کمی به این دروس می‌دهند. لذا از تسلط کمتری در این موضوع برخوردار هستند. یکی از سوءتفاهم‌هایی که بعد از تدریس این مفهوم در دانشگاه برای دانشجویان پیش می‌آید این است که متد یا فریمورک خانواده Agile، کل داستان مدیریت پروژه نرم افزاری است. درحالیکه فریمورک های خانواده Agile فقط یکی از انواع فریمورک های مدیریت پروژه هستند.

متدهای Structured Highly تاکید بر این موضوع دارند که قبل از استارت کار، پروژه باید به فازهای کوچکی تقسیم شده و تمامی فازهای آن از قبل مشخص باشند. عملاً فازهایی که بعداً به پروژه اضافه می‌شوند، می‌توانند زمان بندی و برنامه توسعه پروژه رو تحت تأثیر قرار دهند. برای همین این متدها قابلیت انعطاف پذیری ندارند و لذا دلیل نمی‌شود که از این متدها دیگر استفاده نشود. بلکه می‌توانند کاربرد خاص خودشان را در پروژه‌ها داشته باشند. به این متدها گاهاً متدهای سنتی هم گفته می‌شود.

متدهای Flexible Highly و یا خانواده Agile متدهایی هستند که نقطه متقابل متدهای Structured Highly تلقی می‌شوند و در هر مرحله از توسعه هر تغییری را قبول می‌کنند. درنتیجه انعطاف پذیری از اهداف مهم این دسته از متدهاست که یکی از دلایل شهرت و محبوبیت این متدهاست.

متدهای خیلی زیادی در این دو دسته از متدهای مطرح شده قرار می‌گیرند نظیر Scrum، Kanban، Waterfall و PRINCE2. متدهای Scrum و Kanban جزء متدهای خانواده Flexible Highly (Agile)، Waterfall بوده و PRINCE2 به دسته متدهای Structured Highly تعلق دارند.

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

کلیدواژه‌ها:

Agile - Scrum - Kanban - Waterfall - Project Management Frameworks - Project Management Institute (PMI) - Commercial Off-the-Shelf (COTS) - Software Enhancement Projects - Scratch Development (New Build Software Projects) - COTS Implémentation Checklist - RFP Template - Stakeholder Grid