کتاب راهنمای عملی چابکی Agile Practice Guide

مدیریت پروژه چابک چیست؟

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

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

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

 

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

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

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

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

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

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

متدولوژی Agile

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

تعریف مدیریت پروژه سنتی:

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

معروفترین متدولوژی مدیریت پروژه سنتی و فازهای آن:

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

چالش های مدیریت پروژه سنتی:

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

انتشار بیانیه چابک:

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

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

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

تعریف Hass از مدیریت پروژه چابک: یک فرآیند افزایشی و تکراری می‌باشد که در آن توسعه‌دهنده و ذینفعان پروژه باهم کار می‌کنند تا بتوانند دامنه‌ی کاری را درک کنند، نیازهایی که باید ساخته شوند را تعریف کنند و اولویت‌بندی عملکردها را مشخص کنند.

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

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

Larsonو Gray پنج اصل را در نظر گرفته‌اند: تمرکز بر روی ارزش مشتری، تحویل افزایشی و مکرر، استفاده از تجربیات و سازگاری، تیم‌های خود سازمانده و بهبود مداوم

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

فازهای چارچوب مدیریت پروژه چابک:

در کنار چارچوبی که در کتاب پرسمن ذکرشده است، یک چارچوب مدیریت پروژه چابک که توسط Highsmith معرفی‌شده است ۵ فاز زیر را شامل می‌شود:

• رؤیایی بودن:

  • چشم‌انداز محصول و حوزه‌های پروژه تعریف می‌گردد. ارتباطات پروژه و اینکه چگونه اعضای تیم باهم کار می‌کنند مشخص می‌شود. مانند روشن شدن لامپ در ذهن افراد می‌باشد

• اندیشیدن:

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

• اکتشاف کردن:

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

• وفق دادن:

  • در این فاز نتایج از دید مشتری، تکنیکی و کارایی فرآیندها بازبینی می‌گردد. نتایج این فاز شروع تکرار بعد تأثیر می‌گذارد

• خاتمه:

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

 

 

 

 

 

 

 

 

 

 

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

 

اسکرام چیست؟

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

نقش ها در اسکرام:

به‌طورکلی نقش‌ها در اسکرام عبارت‌اند از: رئیس اسکرام، صاحب محصول، تیم توسعه

• رئیس اسکرام:

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

• مالک محصول:

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

• تیم توسعه:

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

در اکثر گروه‌ها یک رهبر وجود دارد- باتجربه‌ترین شخص- که تیم را هدایت می‌کند، راه‌حل‌های پیشنهادشده را بازبینی می‌کند و تصمیم‌گیری می‌کند. رئیس اسکرام تیم را پشتیبانی می‌کند و ورودی را مهیا می‌کند و در صورت نیاز پشتیبانی می‌کند. علی‌الخصوص در تیم‌های توسعه‌ی نرم‌افزار ، تفاوت قائل شدن بین اسکرام مستر و رهبر توسعه دهنده مشکل است. معمولاً یک تیم یک رهبر توسعه‌ای که مهارت و تجربه‌ی بالایی دارد و قادر است تیم را مدیریت کند و تصمیم‌گیری را انجام دهد. که این نقش اسکرام مستر نیست بلکه یک شخص از تیم توسعه می‌باشد.

 مدیریت ریسک در پروژه‌های چابک

ریسک چیست؟

ریسک چیزی است که اتفاق می‌افتد و موجب می‌شود خروجی غیرقابل‌پیش‌بینی و غیرمنتظره به وجود آید. با در نظر داشتن این نکته که این خروجی ممکن است تأثیر مثبت یا منفی داشته باشد. تأثیر مثبت یک فرصت و تأثیر منفی یک تهدید می‌باشد.

ریسک در پروژه:

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

ریسک:

توصیفی از ریسک در یک خط

 احتمال:

احتمال وقوع ریسک

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

زمانی که در صورت بروز ریسک ازدست‌داده می‌شود که معمولاً به‌صورت روز بیان می‌گردد

در معرض قرار گرفتن:

از حاصل‌ضرب احتمال و اندازه از دست دادن محاسبه می‌گردد.

در پایان جمع تمام در معرض ریسک قرار گرفتن‌ها را محاسبه می‌کنیم و در طول هر اسپرینت این معیار محاسبه می‌شود و در نمودار Burn dowm علامت زده می‌شود.

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

نتیجه‌گیری و پیشنهادات یک پروژه چابک

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

نتیجه بررسی نقاط قوت و ضعف:

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

در تولید چابک که یک تغییر اجتماعی محسوب می‌شود، سازمان‌ها از منبع سازمانی بیرونی استفاده می‌کنند. با توجه به عناصر کلیدی ارتقای بهره‌وری، مدیریت چابک جهت دستیابی به تولید پیشرفته کاملاً” مطلوب است.

چرا باید Agile شد ؟

رضایت مشتری

 

یکی از مهمترین دستاوردهای چابک سازی سازمان را می توان رضایت مشتریان دانست زیرا که در محیط های چابک رضایت مشتری اصلی ترین معیار اندازه گیری موفقیت سازمان خواهد بود. رضایت مشتری از طریق تعاملات زیاد و تقریبا هر روزه وی با تیم توسعه بدست خواهد آمد . در محیط های چابک ارزش بسیار زیادی برای مشتری قائل می شود به طوری که در بیانیه توسعه نرم افزار چابک چنین می خوانیم : “بالاترین اولویت ما رضایت مشتری از طریق تحویل به موقع و مداوم نرم افزار ارزشمند می باشد ” .

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

• قبول و پذیرایی از نیازهای در حال تغییر مشتری
• تحویل نرم افزار کارکننده غالبا هر چند هفته یک بار
• تعاملات دائمی بین مشتری و تیم توسعه

 

بهبود کیفیت

 

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

در محیط های چابک روش های مختلفی برای بهبود کیفیت محصول ارائه شده است که از جمله آنها می توان به موارد زیر اشاره کرد:

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

افزایش بهره وری

 

در محیط های چابک یکی از معیارهای پیشرفت تیم افزایش بهروری نیروی انسانی می باشد . این افزایش بهروری از 50% تا 90% خواهد بود.  نیروی انسانی پر هزینه ترین و اصلی ترین رکن هر سازمان توسعه نرم افزار می باشد به همین دلیل پایین بودن بهروری این منبع می تواند بسیار به ضرر سازمان مطبوع تمام شود .

در سازمان های چابک برای به حداکثر رساندن بهره وری نیروی انسانی از روش های انگیزه ده به نیروی کار مانند روش های زیر استفاده می شود :

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

نتیجه گیری

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

همانطور که در شکل بالا مشاهده می فرمائید سازمان دارای یک سری استراتژی می باشد و Agile برای هر استراتژی یک برنامه مشخص دارد که با عمل سازمان به این برنامه سازمان خواهد توانست به این استراتژی برسد و دست یابی به هر استراتژی مصادف با نزدیکی و دست یابی به هدف عالی و والای یک سازمان یعنی همان سود و درآمد بیشتر می باشد خواهد شد.

اگر چابک نشویم چه خواهد شد ؟

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

شرکت تحقیقاتی  Standish Group چند سال  قبل آمارگیری وسیع بر روی چندین هزار پروژه توسعه نرم افزار  انجام داده  بود . در این آمارگیری میزان زیادی از سرمایه گذاری انجام شده تلف شده است و بسیاری از پروژه ها شکست خورده اند . نکته جالب اینجاست که در هیچکدام یک از این پروژه ها از Agile استفاده نشده است .نتیجه آمارگیری بدین صورت بوده است :  31% این پروژه های قبل از اتمام شکست خورده  و تعطیل شده است ; هزینه 52% این پروژه ها 189% بیشتر از هزینه برآورده شده بوده است ;فقط 16.2% پروژه ها  به موقع تمام شد ;

علت شکست اکثر این پروژه ها نبود انگیزه در نیروی کار ,  نبود  تعامل با مشتری ,  فهم اشتباه از نیازمندی های مشتری و باگ های متعدد نرم افزار بوده است که اگر این پروژه  ها چابک بودند شاید آمار شکست بسیار پایین تر می بود .  باتوجه به تجربیات کشورهای صنعتی پیشرفته و صنعتی جهان می توان از ضررهای چابک نشدن به موارد زیر اشاره کرد :

• از دست دادن مشتری
• نرم افزار با تعداد باگ نامحدود
• نیروی انسانی بی انگیزه
• تاخیر در ارائه محصول
• ارائه ویژگی های بلااستفاده

برای چابک شدن چه چیزی نیاز است ؟

Agile می تواند در محیط ها و شرایط  زیر راحت ترو بهتر اعمال شود :

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

برای موانع در مورد  اعمال Agile هم می توان به موارد زیر اشاره کرد :

• کمبود دانش Agile
• تیم های بسیار بزرگ
• توسعه به صورت توزیعی و گسترده به صورت فرا محلی
• قراردادهای بسته (از نظر قیمتی و دامنه پروژه)
• نیروی کار نابلد و یا نیروی کار تازه وارد و تازه تیم شده
• حرکت به صورت سریع

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

برنامه یک سازمان برای چابک سازی چه می تواند باشد؟

برنامه و طرح  یک سازمان برای انتقال به Agile شامل موارد زیر می تواند باشد:

• بررسی سازمان و تعیین وضعیت فعلی سازمان
• آموزش و نهادینه سازی ارزش ها و اصول Agile
• آموزش اسکرام
• برگزاری کارگاههای آموزشی در مورد متد اسکرام و XP
• برپایی و استارت Agile در سازمان
• بررسی وضع و نظارت بر عملکرد
• برگزاری جلسات بازبینی عملکرد و تعیین روش های بهبود وضعیت

در حالت کلی برنامه در 4 سطح قابل تعریف خواهد بود :

1- بررسی

2- آموزش

3- اجرا

4- بازبینی