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

سوالاتی درباره روش agile

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

با ما در ادامه این مطلب همراه باشید تا پاسخ این سوالات را بیابید.

چند نکته درباره روش agile

این روش برای توسعه نرم افزار به صورت رسمی در سال 2001 میلادی و توسط 17 تکنسین تولید شد. آنها 4 اصل را برای پروژه هایی که از این روش استفاده می کردند نوشتند و هدف آنها از این کار نیز بهتر کردن روند توسعه نرم افزار بود. این 4 اصل عبارت بودند از موارد زیر:

-          تعامل با کاربر در طول انجام پردازش ها و کار با ابزارها

-          روکار کردن نرم افزارها بر روی مستندات جامع

-          همکاری بیشتر مشتری های نرم افزارها

-          پاسخ دادن به تغییرات در طول پردازش یک عملیات

قبل از agile: عصر روش waterfall( بخش اول)

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

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

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

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

قبل از agile: عصر روش waterfall( بخش دوم)

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

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

قبل از agile: عصر روش waterfall( بخش سوم)

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

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

محوری برای توسعه نرم افزار با روش agile( بخش اول)

روش waterfall که در سال 1970 ساخته شد یک انقلاب در دنیای توسعه نرم افزار به شمار می آمد چرا که موفق شده بود قوانینی را برای توسعه نرم افزار بیاورد که مطمئن شود مسیر مشخصی برای دنبال کردن وجود دارد. این روش در واقع بر پایه روش waterfall manufacturing بود که توسط Henry Ford در سال 1913 ساخته شده بود. این روش اطمینان حاصل می کند که در هر مرحله از روند تولید نرم افزار محصول نهایی مطابق با آن چه که در ابتدا در نظر گرفته شده بود خواهد بود.

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

محوری برای توسعه نرم افزار با روش agile( بخش دوم)

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

محوری برای توسعه نرم افزار با روش agile( بخش سوم)

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

اهمیت استراتژیک مهارت های ما در روش agile

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

راهکاری برای حل مشکل با مدیر پروژه های waterfall

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

در سال 2001 میلادی گروهی از توسعه دهندگان نرم افزار با تجربه متوجه شدند که آنها موفق شده اند که در عمل روشی را برای توسعه نرم افزار بیابند که با روش کلاسیک waterfall تفاوت هایی دارد. البته باید توجه داشته باشید که تمامی این توسعه دهندگان در استارت آپ ها فعالیت نداشتند. این گروه که شامل برخی از مهم ترین افراد در دنیای تکنولوژی مانند Kent Beck، Martin Fowler، Ron Jeffries، Ken Schwaber و Jeff Sutherland روش مانیفست Agile را ارائه دادند که چگونگی عملکرد پروسه توسعه نرم افزار به صورت مدرن را مستند کرده بود. آنها به شدت بر روی همکاری در مستندها، خودسازماندهی به جای شیوه های مدیریت سفت و سخت و توانایی تغییر برخی از موارد ثابت به جای این که خودشان را به یک مسیر مشخص پروسه توسعه نرم افزار با روش waterfall برسانند،تاکید می کردند.

بر اساس این قوانین بود که روش agile برای توسعه نرم افزار به وجود آمد و امروزه شاهد آن هستیم که بسیاری از افراد از روش agile استفاده می کنند.

قوانینی که در روش agile به کار گرفته می شود

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

کاربران در روش agile

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

صاحب محصول

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

ما این شخص را صاحب محصول می نامیم. در واقع مسئولیت او در روش agile برای توسعه نرم افزار این است که این نما را ایجاد کند و بعد از آن با تیم توسعه دهنده کار کند تا این نما را به واقعیت تبدیل کند.

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

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

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

علاوه بر این برای توسعه دهندگان تیم توسعه دهنده نرم افزار با روش agile بسته به نوع پروژه می تواند شامل مهندسین تضمین کیفیت که به صورت خلاصه QA نامیده می شوند، سایر مهندسین مانند مهندسین پایگاه داده و یا سیستم بک اند، طراحان و تحلیلگرها نیز باشد.

آشنایی Scrum، Kanban و سایر فریم ورک های agile( بخش اول)

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

یکی از محبوب ترین فریم ورک های روش agile فریم ورک scrum نامیده می شود. این فریم ورک بر روی گزارشات تمرکز کرده است که این گزارشات ساختارهای جلساتی نامیده می شوند که شامل موارد زیر می باشند:

-          برنامه ریزی: در این مرحله اولویت های مربوط به ساختارهای جلساتی تعیین می شود.

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

-          جلسات آماده سازی روزانه: اعضای تیم می توانند برای به روزرسانی های مختلف با یکدیگر ارتباط برقرار کنند.

آشنایی Scrum، Kanban و سایر فریم ورک های agile( بخش دوم)

امروزه بسیاری از سازمان ها افراد متخصص در حوزه scrum را استخدام می کنند تا بتوانند به مدیریت تیم های خود در روش agile کمک کنند.

اگرچه امروزه از scrum به صورت گسترده ای استفاده می شود ولی با این حال فریم ورک های دیگری نیز وجود دارد:

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

-          برخی از سازمان ها با نسخه hybrid روش agile سازگار هستند و به همین دلیل از پردازش های مربوط به روش agile  و روش waterfall به صورت ترکیبی برای اپلیکیشن های جدید خود استفاده می کنند.

صحبت پایانی

ما در این مطلب سعی کردیم اطلاعاتی را در خصوص روش agile و کاربردهای آن در اختیار شما قرار دهیم. امیدواریم مطالعه این مطلب درباره روش agile برای شما مفید بوده باشد.