ساجد

خلاصه

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

کلمات کلیدی: روش های چابک، پروژه های بزرگ و توزیع شده؛ پوسته پوسته شدن چابک


1.پس زمینه
به منظور حفظ کنترل بر روی پروژه های بزرگ و توزیع شده، تمایل طبیعی به معرفی لایه های اضافی مدیریتی ، سیاستی است که تقویت شده و فرآیندهای جدید و بازرسی (سکاها و همکاران، 2014) ساختار در صلاحیت مدیران پروژه میباشد (Trivellas و Drimoussis، 2013 جدید؛ Trivellas و Reklitis، 2014). به همین دلیل، بسیاری از شیوه ها و ابزارهای شناسایی شده برای پروژه های توزیع چابک با ابزارها و شیوه های مورد استفاده در پروژه های روش سنتی مدیریت پروژه یکسان میباشند. به عنوان مثال، نیاز به یک تیم معماری که تاثیر مثبت بر هر دو روش های سنتی و همچنین چابک دارد و تیم های ادغام و تضمین کیفیت زمانی که با تیم های توزیع بزرگ مقایسه میشوند نقش های مشابه دارند.
با این حال، چارچوب چابک خواستار دخالت در هر باز تکرار بر اساس درگیری در تمام تیم هاست در حالی که مدل سنتی مراحل خاص فعالیت های تیم را در محل دیکته میکند. در تلاش برای رعایت این رویکرد روش چابک، در پروژه های بزرگ و توزیع شده، تمرکز اصلی باید برای حفظ ساختار سازمانی کوچک باشد. سلسله مراتب باید تا حد امکان تخت باشد، تیم بیشتر و سطح مدیریت کمتری داشته باشد. تیم می تواند واقعی یا مجازی باشد اما تفاوت اصلی با تیم های مشابه که از روش های مدیریت پروژه سنتی پیروی میکنند، این است که تیم ها باید دارای شبکه ارتباطی بین خود باشند. یکی از اعضای هر تیم باید در جلسات مهمی از تیم های دیگر شرکت کند. داشتن تیم خود سازمان یافته، ارتباط متقابل و یک ساختار سازمانی مسطح اجازه می دهد تا تیم های چابک به خوبی بدون عوارض همکاری کنند. در مقابل در شیوه های سنتی عمیقا به اسناد و مدارک و ساختارهای سازمانی سلسله مراتبی وابسته است، هدف از چارچوب چابک افزایش همکاری و هماهنگی تیم و اعضا برای رسیدن به اجرای موفق پروژه توزیع شده است.
علاوه بر این، همچنین در پروژه های بزرگ و توزیع شده، این واقعیت که استفاده از روش چابک، ترجمه شده به تحویل مکرر، در دسترس بودن در برابر تمام ذینفعان، فراهم آوردن کنترل بهتر پروژه و اینکه اجازه می دهد تا اصلاحات و درخواست تغییر در هر زمان انجام گیرد. سبک تکرار شونده و افزایشی روش های چابک علاوه براین اجازه می دهند تا تحویل برنامه ریزی شده بر اساس بازخورد مشتری منطبق باشد. روش های سنتی شواهدی از کار را تنها در اواخر پروژه فراهم می کند و جهت تغییر درخواست که بر طراحی محصول اثر میگذارد باید صبر کرد تا در نسخه های بعدی در نظر گرفته شود.

2. تیمهای توزیع شده از لحاظ جغرافیایی و فرآیندهای توسعه.
امروزه سازمان های بزرگ چند ملیتی، گروه های توسعه نرم افزاری متعدد واقع در قاره های مختلف در سراسر جهان دارند. کاهش هزینه های ارتباطات که تکنولوژی مدرن فراهم میکند، در ترکیب با مزایای بودجه حاصل از جابجایی منابع  محرک اصلی است که تشکیل تیم توزیع شده به لحاظ جغرافیایی را راه حلی موثر هزینه برای شرکت های توزیع شده میکند.
استفاده از گروه های توسعه متعدد برای تشکیل تیم های توزیع شده که برای ارائه یک محصول و یا یک سرویس با هم کار کنند یک چالش است که باید از فرآیندهای توسعه نرم افزار پیروی کرد(Trivellas، 2011؛ ​​Trivellas و Drimoussis، 2013؛ Trivellas و Reklitis، 2014؛ Trivellas و Santouridis، 2009). درس های آموخته شده را می توان از طرح های مدل سازی در بخش های دیگردنبال کرد (Nasiopoulos و همکاران، 2014a؛ 2014b)، اما هنوز هم چالش ها قابل توجه است.

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

2.2. توزیع با استفاده از روش چابک
برای پروژه هایی که روش چابک را دنبال میکنند، تلاش برای حرکت از تیم محلی به ، تیم های بزرگ توزیع شده به سختی مدل های پی در پی نیست. با این وجود واقعیت این است که تلاش های اولیه برای استقرار روش چابک با استفاده از، تیم های محلی کوچک انجام شد، با توجه به Versionone.com (2010)  که حالت چابک را بررسی کرد، از انتقادات و پیشنهادات چندین هزار پروژه بازخور گرفت که نشان داد که بیش از 50 درصد از پروژه های چابک حداقل یک فرد دور کار دارند، و تیم های توزیع به جای یک استثنا ،هنجار امروزشدند. چنین اعداد بالایی به این دلیل مشاهده شدند چرا که شرکتها تلاش کردند روش چابک را با پروژه های بزرگی که تنها توسط گروه های بزرگتر می تواند پوشش داده شوند، در ترازوی قیاس قرار دادند.  پرداختن به اندازه افزایش یافته، توزیع شده درطبقه های مختلف، ساختمان ها، شهرستانها و یا کشورها اجتناب ناپذیر است.
تمرکز اصلی با استفاده از روش چابک در پروژه های بزرگ و توزیع یافته یکسان باقی می ماند، یعنی دستیابی به رضایت مشتری با ارائه نرم افزاری با ارزش به آنها و این تنها می تواند زمانی به دست آید که از ارزش های اصلی و اصول راهنمای روش ها پیروی شود. چالش اضافی پرداختن به افزایش پیچیدگی به عنوان یک نتیجه توزیع و پوسته پوسته شدن نیاز به یک ارزیابی دقیق از عوامل سازمانی و شیوه های چابک در جهت انعطاف پذیری و پاسخگویی به تغییرات است که میطلبد روش های چابک در کانون توجه باقی بماند.

2.2.1. عوامل سازمانی
افزایش ساختار سازمانی، در حالی که تلاش میشود از دستورالعمل چارچوب چابک در همان زمان پیروی کرد، در چند مورد تناقض وجود دارد. بنابراین پیدا کردن یک تعادل خوب بین آنها کلید موفقیت برای پروژه های توزیع شده است. هنگامی که تلاش میشود پروژه چابک را درجه بندی نمود ، چهار عامل سازمانی به بازی می آیند (هایاسمیت، J.، 2012):

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

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

همکاری و هماهنگی: ارتباط چهره به چهره در پروژه های بزرگ و به خصوص در توزیع شده پیچیده است. برخی از مزایای استفاده از ارتباط چهره به چهره را تنها می توان با استفاده از ابزارهای زیر متوجه شویم: ویدئو کنفرانس، تسهیل جلسه مبتنی بر وب / وایت برد های هوشمند تعاملی، برنامه های کاربردی بررسی، IM و VoIP، حضور برنامه های کاربردی است.
علاوه بر ابزار ذکر شده در بالا، ایجاد یک رابطه خوب بین اعضای تیم است که در صورت توزیع شدن کار، می توان تیمها را با هم، حداقل یک بار در طول پروژه دور هم جمع کرد، و اینکه ترجیحا در آغاز آن انجام شود. در همان زمان، با صحبت کردن اعضای تیم با هم و حل و فصل مسائل در پروژه که ممکن است در اوایل، تضمین کند که بحث و تصمیم گیری هایی جمعی وجود دارد که در جهت اهداف تیم پیش میرود (Trivellas و Santouridis، 2009).

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

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

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

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

3. مطالعه تجربی

3.1. مطالعه موردی: شرکت Telematicum
سلب مسئولیت: این مطالعه  موردی بر اساس داده های واقعی از یک نرم افزار ارتباطات و خدمات شرکت جهانی است. نام شرکت و همچنین نام محصولات در حال توسعه در حال تغییرند.
Telematicum ، یک شرکت نرم افزار ارتباطات و خدمات جهانی است که کار خود را در سال 2013 به منظور توسعه یک محصول جدید به نام TeleWeb با هدف دستیابی به یک مزیت رقابتی که عملکردی بهتر نسبت به رقبا و افزایش سهم بازار اجازه می داد آغاز کرد. در همان زمان، تصمیم به طراحی مجدد واسط کاربر از یک محصول به نام  smart clientگرفت که در مجموعه این شرکت وجود داشته ، به عنوان بخشی از راه حل ارتباطات یکپارچه ساخته شده است.

کل پروژه TeleWeb شامل بیش از 100 عضو، که به چند تیم ویژه توسعه یافته تقسیم شده اند، شامل یک تیم معماری، یک تیم طراحی UI، یک تیم یکپارچه سازی، یک تیم تضمین کیفیت، یک تیم صاحب محصول، و یک تیم رهبری مجازی. پروژه ده ماه به طول انجامید. یکی از تیم های ویژه Web client   TeleWeb بود که شامل پانزده عضو بود، یازده توسعه دهنده و چهار امتحان کننده بود. سه نفر از پانزده نفر شامل دو توسعه دهنده و یک امتحان کننده، به مکان های مختلف توزیع شد. به منظور بررسی فرآیندهای توسعه چابک تیم Web client  در TeleWeb دنبال شد ، پرسشنامه (Corosin.com، 2012) برای مصاحبه scrum استفاده شد. هیچ مسئله مهم و یا عمده شناسایی نشدند و تیم بهترین شیوه چابک را با انحراف ناچیز دنبال کرد. تنها انحراف مهم تعداد اعضای تیم است، که بیشتر از تعداد تاکید شده در روشscrum  بود.
تیم Smart Client ، یک معمار، یک مدیر محصول، یک تیم طراحی UI، یک مدیر پروژه، یک گروه توسعه با 12 عضو و یک گروه تست با سه عضو اختصاص داده بود. طراحی مجدد پروژه Smart Client 6 ماه به طول انجامید. همچنین در این پروژه، توسعه دهندگان در سه کشور مختلف توزیع شد. هدف مدیر تولید بود معرفی یک نگاه و احساس مدرن به مشتری و فعل و انفعالات رابط کاربر، ایجاد یک رابط کاربر دوست داشتنی و آسان برای استفاده مشتری های هوشمند بود.

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

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

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

نتایج حاصل از توسعه سنتی و چابک برای TeleWeb و smart client را در 3 حوزه اصلی میتوان طبقه بندی کرد:

بهبود کیفیت: با روش سنتی و تیم smart client شروع میکنیم، تعدادی نقص باز در طول زمان در شکل a1 نشان داده شده است. مدت زمان محدود به چهار ماه است، از ژانویه تا پایان ماه آوریل، مراحل توسعه و آزمایش آغاز میشود. طبق روش آبشار ساشیمی، فعالیت های آزمون در طول دوره پیاده سازی آغاز شد.  که در شکل تعدادی نقص باز که تا 60بالا میروند ، قبل از اتمام مرحله پیاده سازی که پایان ماه فوریه بود نشان داده شده. بعد از این نقطه عطف، تمام ویژگی ها تحت ارزیابی تیم تست قرار گرفت و تا نقطه 160 نقص مشاهده شد. گروه های توسعه در طول ماه آینده به منظور کاهش تعداد نقص به سطح رضایت بخش کیفیت پروژه تا پایان ماه آوریل، که به عنوان مهلت برای شروع تحویل به مشتریان تنظیم شده بود به سختی کار کردند. در آغاز ماه مه، محصول برای تحویل به مشتری آماده است.
تعداد نقص باز  TeleWeb Web clinet در شکل 1 B نشان داده شده است. در طول مدت زمان هفت ماه، با در نظر گرفتن این واقعیت که ویژگی ها به صورت تدریجی تحویل شد و اکثریت در دوره ماه مارس معرفی شد، نقص ها بطور یکنواخت توزیع شده اند. در ماه مارس و دوره پس از آن، یک نقطه اوج 100 نقص باز مشاهده شد. 

درخواست افزایش و تغییر محتوا:

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

رضایت کارکنان: برای جمع آوری بازخورد اعضای تیم TeleWeb ، یک نظرسنجی ایجاد شد و ازاعضای تیم خواسته شد تا میزان شدتی که آنها با بیانیه های مختلف موافقند در مقیاس 0 (کاملا مخالفم) تا 10 (کاملا موافقم) اندازه گیری شود. این نظر سنجی در آغاز ماه مه  صورت گرفت و همه اعضای تیم وب کلاینت شرکت کردند. نتایج بررسی اظهارات در شکل 2 فراهم آمد. با توجه به اینکه اعضای تیم وب کلاینت TeleWeb قبل از پیوستن به این تیم در پروژه های مختلف از روش های سنتی استفاده میکردند، پاسخ های ارائه شده اجازه می دهد تا یک مقایسه مستقیم از سطح رضایت کارکنان بین روش سنتی و چاک انجام گیرد. آنچه لازم است تا علاوه بر این ذکر شود این واقعیت است که این پروژه نهایی نشده بود که این نظرسنجی اجرا شد.
اولین کشف روشن از پاسخ های ارائه شده از تیم این است که همکاری تیم با استفاده از scrum بهبود یافته است. علاوه بر این، درک تیم در خصوص میزان تاثیری که scrum  در ارزش تجاری کالای نهایی میگذارد بسیار مثبت است. در نهایت، اکثریت قریب به اتفاق اعضای تیم نمیخواهند استفاده از scrum با فرایند توسعه های مختلف را تغییر دهند.
اما بهبود در بهره وری روزانه و همچنین در کیفیت کلی محصول نهایی اعضای تیم با شدت کمتر گزارش شده است.
درک مثبت ما در خصوص تاثیر روش scrum در فعالیت های روزانه و در محصول نهایی تیم، به شدت بر توزیع بهتر نقایص در تمام مدت پروژه بستگی دارد. همانطور که قبلا مورد تجزیه و تحلیل قرار گرفت، این واقعیت اجازه میدهد همه اعضای تیم تلاش های خود را بر این اساس توزیع کنند و از دوره بسیار استرس زای مشاهده شده در فرایندهای توسعه سنتی اجتناب کنند. از سوی دیگر، همکاری نزدیک تر همه اعضای تیم برای رسیدن به یک هدف مشترک روحیه تیم را بهبود بخشیده و اجازه ایجاد روابط بهتر بین آنها را میدهد. ایجاد یک محیط کار که در آن مردم هر روز نگاه به جلو به آینده کار دارند، یک عامل اضافی کمک به درک بهتر از استفاده از scrum بود.
 
 
 
رضایت مشتری: با TeleWeb  محصول به سرعت به مشتریان میرسید، جمع آوری اطلاعات لازم برای حمایت از افزایش رضایت مشتری امکان پذیر نبود. با این وجود، پذیرش محصول و بازخورد اولیه دریافت شده از مشتریان نشان می داد که کالای Teleweb  تبدیل به یک موفقیت بزرگ خواهد شد و تاثیری مثبت بر موقعیت استراتژیک شرکت و سهم بازار آن خواهد داشت.

4. نتیجه گیری
نتایج حاصل از مطالعه نشان داد که اتخاذ چارچوب چابک، در پروژه های بزرگ توزیع شده، کیفیت را بهبود میبخشد، اجازه می دهد تا تغییرات مورد نیاز و اضافی در طول پروژه صورت بگیرد و رضایت کارکنان را که در حال ساخت محصول نهایی هستند بهبود میبخشد. استقبال از چارچوب چابک به منظور توسعه یک محصول جدید و اثرات مثبت شیوه های چابک در مقایسه بین فعالیت های یک تیم توسعه یافته با ویژگی های خاص چابک با فعالیت های یک تیم که فعالیت های مشابه در طول مدت زمان مشابه با استفاده از روش های توسعه سنتی انجام میشود، در حال افزایش است.
با این حال، مورد مطالعه همچنین نشان داد که اتخاذ چارچوب چابک آسان نیست و شرکت ها، به ویژه شرکتهای بزرگ با سابقه ای طولانی در استفاده از فرآیندهای سنتی نیاز به دقت در برنامه این فعالیت دارند ، تلاش دارند از مشکلات معمول مشاهده شده هنگامی که اقدام به اتخاذ روش چابک میکنند جلوگیری کنند. علاوه بر این، ساختن فرهنگ چابک و استقبال از اقداماتی که نیاز به زمان دارند که در طی آن فعالیت به منظور شناسایی مشکلات خاص پروژه های اضافی باید به دقت نظارت شود و اقداماتی را برای رسیدگی به آنها صورت دهند. برای اجرای موفقیت آمیز؛ نتیجه این فعالیت باید اصول راهنمای چابک که مطابق با نیازهای پروژه های واقعی و توسعه مهارت های لازم فردی و شایستگی (Trivellas و Reklitis، 2014 Trivellas و Drimoussis 2013) طراحی شده است، باشد.