متد چابک در مدیریت پروژه طراحی محصول | Agile

مدیریتاستارت‌آپمسیردیزاینر

مدیریت پروژه چابک یا همان Management Project Agile که آن را با نام اختصاري (APM )نیز می شناسند یک رویکرد براي مدیریت پروژه (معمولا براي ارائه پروژه هاي پیچیده) است که پروژه هاي بزرگ را به پروژه هاي کوچکتر و قابل کنترل تر تجزیه می کند و این پروژه هاي کوچکتر در بازه هاي زمانی کوتاه و تکرار شونده (که اسپرینت نام دارند)در طول زمان تکمیل پروژه انجام می شوند.اسپرینت ها معمولا کوتاه هستند و طول آنها بین دو تا چهار هفته است. درواقع روش مدیریت پروژه چابک ، پروژه را به بخش هاي کوچک بین اعضاي تیم تقسیم می کند و در فاصله هاي زمانی معین بخش هایی از پروژه را که قابل ارائه باشند اجرا و تست می کند و تحویل می دهد و از بازخورد هاي مشتریان براي طراحی و ایجاد تغییر در محصول موردنظر در دوره تکرار بعدي استفاده می کند.

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

راهبردهاي فلسفی ، توسعه دهندگان را به موارد زیر تشویق می کند :

• رضایت مشتري
• تحویل افزایشی زود
• تیم هاي پروژه کوچک با انگیزة بالا
• روش هاي غیر رسمی
• حداقل محصولات کاري مهندسی نرم افزار
• سادگی توسعه

راهبردهاي توسعه، نیز بر موارد زیر تاکید دارند :

• تحویل در مدت تحلیل و طراحی
• ارتباطات فعال و ادامه دار بین توسعه دهندگان و مشتریان

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

تاریخچه از رویکرد چابک یا (Agile)

[um_loggedin] در دهه 1990 همزمان باگسترش شرکت هاي رایانه اي توسعه نرم افزار با بحران روبرو شد که در آن زمان با عنوان “بحران توسعه برنامه” یا “تأخیر تحویل برنامه ” شناخته می شد و طبق تخمین کارشناسان، زمان بین نیاز مشتري و تولید برنامه و نرم افزار سه سال بوده است و قادر به پاسخگویی سریع به نیاز مشتریان وجود نداشت. مشکلی که ممکن بود در این سه سال به وجود بیاید این بود که برخی ازسیستم ها، مشاغل و در نتیجه نیاز ها تغییر می کرد و بسیاري از پروژه ها لغو می شدند و بسیاري از پروژه هایی هم که به اتمام رسیده بودند تمام نیاز هاي فعلی را برآورده نمی کردند.

همچنین در بسیاري از صنایع دیگر این مدت به بیشتر از سه سال نیز می رسید. براي مثال در صنعت هوافضا 20 سال یا بیشتر طول می کشد تا یک سیستم پیچیده ارائه و به کار گرفته شود. مثل برنامه شاتل فضایی که درسال 1982 عملی شد ولی از فناوري هاي اطلاعات و پردازش دهه1960 استفاده کرد.

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

این رهبران به دنبال راه هایی براي ساخت سریع نرم افزارهاي کاربردي و ارائه زودهنگام آن به دست کاربران و مشتریان بودند. این روش تحویل سریع ، مزایاي مهمی را به همراه داشت از جمله اینکه این امکان را به کاربران می دهد که سریعتر برخی از مزایاي نرم افزار جدید را کسب کنند . همچنین تیم طراحی نرم افزار را قادر به دریافت بازخورد سریع در مورد کار می کرد کرد که بهبود کیفیت نرم افزار را به دنبال داشت.

در نهایت در سال 2001 ،اصطلاح و تفکر جدیدي به نام Agile در مدیریت پروژه هاي نرم افراري توسط این تیم 17نفره به وجود آمد و به عنوان “Manifesto Agile”(بیانه چابک) بطور رسمی در بیانیه اي معرفی شد.

این بیانیه عبارت بود از:

ما روش هاي بهتري براي ایجاد نرم افزارها یافته ایم که در آنها چهار اصل اساسی باید رعایت شود.

• افراد و تعاملات را بر فرآیندها ترجیح می دهیم.

بیانیه چابک پیشنهاد می کند افرادي که پشت این روند و فرآیندها هستند اهمیت و تاثیر بیشتري دارند.

 

• نرم افزاري که کار می کند را بر مستندات زیاد ترجیح می دهیم.

در گذشته توسعه دهندگان نرم افزار سالها براي تهیه مستندات دقیق وقت صرف می کردند. و همه این اتفاقات قبل از اینکه حتی یک خط از برنامه نویسی خود را بنویسند اتفاق می افتاد. اگرچه اسناد و مدارك ضرر ي ندارد ، اما در نهایت تیم ها باید بر روند کار تمرکز کنند و نرم افزارهاي با کیفیت و عملکرد ي را در اختیار مشتریان قرار دهند. بیانیه چابک بر اهمیت مشتري مداري در این اصل تأکید می کند. تیم چابک باید بعد از تحویل محصول نهایی به مشتري ، انتظار برخی تغییرات و بازبینی ها را داشته باشد و از آنها براي بهبود کیفیت استفاده کند .

 

• مشارکت مشتریان را بر مذاکرات قراردادي ترجیح می دهیم.

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

به جای استفاده از این روش منسوخ ، تمرکز باید بر روی توسعه مداوم محصول یا برنامه موردنظر باشد. به همین دلیل این رویکرد بهتراست که با همکاری مشتری یا ذینفعان پروژه محصول نهایی مورد نیاز را طراحی کنیم.

 

• پاسخ به تغییرات را بر پیشروي بر اساس طرح و برنامه ترجیح می دهیم

برای توسعه نرم افزار همواره ممکن است تغییرات مفیدی از سوی ذی نفعان و مشتریان مورد نیاز باشد.تیم های نرم افزاری در رویکرد اجایل باید همیشه توانایی تغییر جهت کار خود در هرزمان را داشته باشند.

 

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

دلایل اهمیت روش چابک

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

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

دوازده اصل Agile

• ایجاد رضایت در مشتری از طریق تحویل زودهنگام و مستمر محصولات و نرم افزارهای ارزشمند.

• استقبال از تغییرات حتی تغییراتی که در اواخر کار توسط مشتری درخواست شده است.

• تحویل مکرر محصول و نرم افزار کارامد به مشتری در بازه های زمانی کوتاه (اسپرینت)

• همکاری هر روزه تیم توسعه دهنده و ذینفعان پروژه در طول پروژه بصورت روزانه.

• ایجاد پروژه ها پیرامون افراد با انگیزه که برای انجام کار مورد اطمینان هستند و فراهم کردن محیط مناسب و پشتیبانی از آنها.

• مکالمه حضوری و رو در رو موثرترین روش انتقال اطلاعات به تیم توسعه دهنده پروژه است.

• نرم افزار یا محصولاتی که درحال کار هستند یا ارائه شده اند، شاخص اصلی پیشرفت پروژه هستند.

• فرآیندهای چابک باعث توسعه پایدار می شوند.

حامیان مالی ، توسعه دهندگان و کاربران باید بتوانند یک سرعت و پیشرفت ثابت را برای مدت نامحدودی حفظ کنند.

• توجه مستمر به امور فنی و طراحی خوب محصول یا نرم افزار.

• حفظ سادگی –یعنی به حداقل رساندن انجام کارهای غیر ضروری.

• خودسازماندهی و متخصص بودن در تیم

بهترین معماری ها، الزامات و طرح ها از تیم های دارای سازمان دهی درونی پدیدار می شوند به عبارت دیگر تیم های چابک خود هدایت و سازماندهی می شوند .(خود سامانده و متخصص هستند.)

• تعاملات پیوسته در تیم

در فواصل منظم، تیم پروژه در مورد چگونگی تأثیرگذاری بیشتر تأمل می کند و سپس رفتار خود را متناسب با آن تنظیم و تنظیم می کندو در فواصل منظم آن را محقق می کند این اصل یکی از حیاتی ترین اصول تفکر چابک می باشد.

نمودار Burndown

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

با توجه به دلایل زیر، نمودار Burndownبرای تیم توسعه ضروری است:

• نظارت بر تغییرات محدوده پروژه
• نگه‌داشتن تیم در برنامه زمان‌بندی
• مقایسه کار برنامه‌ریزی شده در برابر پیشرفت تیم
• ارائه تصویر جامعی از پروژه پیش از شروع آن
• تسهیل ارتباطات مشتری با تعیین ساده و واضح انتظارات
• کمک به ارزیابی پیشرفت هنگام ارزیابی موانع یا کارهای جدید

 

بهترین کارکرد مدیریت چابک

بهترین کارکرد مدیریت اجایل زمانی خواهد بود که:

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

هزینه تغییرات در متد اجایل

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

 

عملکرد متد چابک یا (Agile)

مختص مشترکین دیزاین کلاب. شما به این سطح محتوا دسترسی ندارید و یا وارد اکانت خود نشده‌اید.

ورود🔗 | نام‌نویسی‌🔗 | خریداشتراک🔗

[/um_loggedin]

جمع‌بندی

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

روش اجایل (agile) یک تکنیک بسیار خوب برای استفاده در یک کسب و کار است که نیازهایش دائما در حال تغییر می‌باشد. نمونه پروژه‌هایی که چابکی برای آنها مناسب است:

•  پروژه های فن آوری اطلاعات و نرم افزاری
•  جابجایی امکانات سازماندهی دوباره شرک تغییر پروسه کسب و کار
• سازماندهی دوباره شرکت
•  تغییر پروسه کسب و کار
•  پروژه هایی با کیفیت بالا و زمان پیاده سازی کم