مدیریت پروژه با رویکرد چابک ( اجایل Agile )

مدیریت پروژه با رویکرد اجایل (چابک)

مدیریت به روش اجایل (Agile) یک رویکرد در مدیریت پروژه است که از پاسخگویی دائم به تغییرات به جای پیروی از یک برنامه ­ریزی دقیق و از پیش­ تعیین­ شده حمایت می ­ کند. مدیریت چابک (اجایل) یک روش  ­شناسی نیست. بلکه مجموعه ­ای از اصول است (که به اسم بیانیه مدیریت چابک شناخته می-شود) و حاکی از آن است که ما باید با چه رویکردی به مدیریت پروژه بپردازیم.

اساسا دو روش کلی برای مدیریت پروژه­ های توسعه نرم­ افزار وجود دارد:

  • آبشاری (waterfall): در این روش همه چیز از پیش برنامه ­ریزی شده است و تولید و ساخت در طی یک سال آینده طبق این برنامه ­ریزی از پیش تعیین شده انجام می­ گیرد.
  • چابک(agile): در این روش شما چیزی را برنامه ریزی می کنید که طی چند هفته آینده قصد تولید یا ساخت آن را دارید و بعد از این چند هفته راجع به چگونگی ادامه روند کار تصمیم می گیرید.

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

بیانیه مدیریت اجایل (Agile)

در سال ۲۰۰۱، ۱۷ توسعه دهنده نرم ­افزار در ایالت یوتا گردهم آمدند تا در مورد روند و رویه ­های کاری خود که با مدیریت پروژه به شیوه ­ی آبشاری متفاوت بود بحث و گفت­ وگو کنند. آنها با همدیگر مفهوم توسعه چابک نرم­ افزار را در بیانیه مدیریت چابک تعریف کردند. امروزه وقتی می گوییم یک روش ­شناسی خاص اجایل به حساب می­ آید، به این معناست که از اصول و ارزش ­های بیاینه چابک پیروی می­ کند.

مهم­ترین بخش بیانیه مدیریت اجایل ۴ ارزش آن است. این ۴ ارزش به مانند قلب چیزی است که مدیریت چابک نامیده می ­شود.

ارزش ­های مدیریت چابک به شما کمک می ­کند روی چیزی که مهم است تمرکز کنید. برای مثال، یکی از ارزش ­ها ” نرم­ افزار در حال کار به جای مستندسازی جامع” است. اما این به این معنا نیست که مستندسازی فعالیت­ ها کار بدی است، بلکه به این معناست که اگر شما بین صرف کردن زمانتان برای نوشتن جزئیات یک مسئله و اشکال یا رفع آن اشکال نرم­ افزار باید یکی را انتخاب کنید، انتخاب شما باید رفع اشکال باشد.

افراد و تعاملات آنها به جای ابزار و فرآیندها

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

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

شاید علاقه مند باشید  راهنمای جامع مدیریت پروژه از صفر تا صد - بخش اول

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

پی نوشت: فرآیندهای کاری خوب در خدمت شما هستند و در نتیجه شما هم به مشتریان خدمات ارائه می­ دهید. اما اگر مراقب نباشید خود این فرآیندها تبدیل به مسئله می شوند برای شما. دراین وضعیت، رویه­ های کاری جای نتیجه و خروجی­ ها مد نظر شما را می­ گیرند و شما به جای اینکه به دنبال خروجی­ ها و نتایج مورد انتظارتان باشید، دائما در حال کسب اطمینان از این موضوع هستید که آیا رویه های کاری به درستی انجام می شوند یا خیر. بسیار شنیده شده است که رهبران تازه­ کار تیم­ ها برای توجیه نتیجه بد کسب شده تیمشان گفته ­اند که ” ما دقیقا از روند کاری تعیین شده پیروی کردیم.”.  یک رهبر با تجربه­ تر از فرصت مناسب برای بررسی و بهبود رویه­ های کاری استفاده می کند. رویه های کاری اصل مطلب نیستند. همیشه این سوال را در ذهن خود داشته باشید که آیا رویه های کاری در خدمت ما هستند یا ما در خدمت رویه ­ها کاری؟” جف بزوس“.  اگر انجام موفقیت ­آمیز یک پروژه در نظر شما به معنی به انجام رساندن تک ­تک وظایف در نظر گرفته شده برای یک شخص در آن پروژه باشد  و شکست یک پروژه به معنای این باشد که پروژه اهداف مد نظر تجارت را بدون انجام همه ی رویه ها به دست آورده تعریفتان از مفهوم “پروژه کامل شده ” کاملا اشتباه است. (منبع: the phoenix project: a novel about IT, DevOps, and helping your buissiness win)

نرم­ افزار در حال کار به جای مستندات جامع

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

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

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

شاید علاقه مند باشید  مدیریت ذینفعان پروژه

هنگام نوشتن مستندات بایداز خودتان بپرسید که اگر شما فردا به این تیم بپیوندید می­خواهید چه چیزی از وضعیت کارها و روند تیم بدانید.

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

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

پیش ­فرض مدیریت اجایل (Agile) بر این است که شما محدودیتی برای دسترسی به مشتریان خود ندارید و همیشه می­توانید جلسه­ ای برای صحبت راجع به روند کار با آنها داشته باشید. توسعه­ دهندگان یک حلال مشکل ذاتی هستند اما نیاز دارند به مشتریان خود دسترسی داشته باشند تا بهتر متوجه بشوند که مشکل واقعی کجای کار است.

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

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

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

پاسخ به تغییر به جای پیروی از یک برنامه مشخص

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

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

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

شاید علاقه مند باشید  مزایا و معایب مدیریت پروژه چابک

مدیریت پروژه اجایل یا چابک

 عناصر مدیریت پروژه چابک (اجایل)

فرهنگی که تغییر در آن انتظار می­رود

مدیریت چابک به معنای استفاده از تخته کن­بن، داشتن جلسات ایستاده روزانه یا چیز­های از این دست نیست (این­ها عناصر یک روش خاص از مدیریت چابک است). مدیریت اجایل در هسته­ ی خود یک ذهنیت است که همه­ ی افراد از کارکنان گرفته تا مشتریان انتظار تغییر را دارند. شما نمی­توانید در ابتدا به مشتریان خود قول۱۰۰% همه چیز و یک تاریخ سررسید مشخص بدهید چرا که هر دوی شما می­ دانید که غیرواقعی است. اما می ­توانید به به آنها قول بدهید که در نهایت محصولی را خواهند داشت استفاده می ­کنند.

توسعه فزاینده

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

انتشارهای مکرر

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

حلقه­ های بازخورد کوتاه

چون انتشار به دفعات مکرر اتفاق می ­افتد شما سریعتر می­توانید به بازخورد دست پیدا کنید. و چون شما سریعتر به بازخورد دست پیدا می­کنید با سرعت بیشتری می­توانید تغییرات لازم را رو محصول اعمال کرده و به ارزش دست یابید.

میزان درگیری و تعامل زیاد با مشتری

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

گاهی مشتری  برای ارائه بازخورد به شما در دسترس نیست. بعضی از روش­ های مدیریت اجایل (Agile) مانند اسکرام این مشکل را با در نظر گرفتن یک نقش در تیم به نام مالک محصول حل کرده است. این شخص به مانند نماینده مشتری عمل می­ کند و به نیابت از او رفتار می­کند. اگر تیم توسعه دهنده سوالی داشته باشد از او می ­پرسد. مالک محصول پیشرفت تیم را بررسی کرده و در انتهای چرخه های تکرار الویت های مشتری را دوباره ارزیابی می­ کند.



تیم کمپ سیستم آنلاین مدیریت پروژه و مدیریت تیم است. ما به تیم ها کمک می کنیم تا با سرعت و به سادگی وظایف، گفتگوها، فایل ها و فعالیت های تیمی و کسب و کار خود را به صورت آنلاین مدیریت کنند و ریسک های پروژه و کار تیمی خود را کاهش دهند.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *