چست طریقہ کار: معنی، فوائد، نقصانات اور بہت کچھ

چست طریقہ کار ایک سافٹ ویئر ڈویلپمنٹ فلسفہ ہے جس کا مقصد مسلسل نظرثانی کے ساتھ ساتھ مختصر ترقیاتی سائیکل استعمال کرکے صارفین کو بہتر قیمت فراہم کرنا ہے۔

سافٹ ویئر کی ترقی ریاضی اور سائنس کے شعبوں سے ہوئی۔ لہذا، اس نے اصل میں ان شعبوں سے سائنسی طریقوں کو شامل کیا.

یہ طریقے 1970 کی دہائی میں آبشار کے نقطہ نظر میں تیار ہوئے تاکہ دن کی ضروریات کو پورا کیا جا سکے۔ ان دنوں کمپیوٹر اور ان کے سافٹ ویئر بڑے، پیچیدہ اور دہائیوں تک چلنے کے لیے ڈیزائن کیے گئے تھے۔ لہذا، آبشار کا طریقہ ایک اچھا فٹ تھا.

لیکن، 1990 کی دہائی کے آخر تک، انٹرنیٹ ڈرامائی طور پر دنیا کو تبدیل کر رہا تھا اور ایک نیا نقطہ نظر ضروری ہو گیا۔ اس طرح فرتیلی طریقہ کار زندگی میں آیا۔

ذیل میں اس سافٹ ویئر ڈویلپمنٹ موومنٹ پر گہری نظر ہے اور یہ آپ اور آپ کی ٹیم کی کس طرح مدد کر سکتی ہے۔

فرتیلی ترقی کے طریقہ کار کی تاریخ

1990 اور 2000 کی دہائی کے عروج کے سالوں کے دوران انٹرنیٹ اور ایپلی کیشنز کے لیے اس کی ناقابل تسخیر ضرورت سے فرتیلی سافٹ ویئر کی ترقی میں اضافہ ہوا۔

یہ وہ دور بھی تھا جب کمپیوٹر سائنس کے پس منظر کے بغیر بہت سے ڈویلپرز نے ویب ڈویلپمنٹ کی طرف رخ کیا کیونکہ مختلف گروپوں اور صنعتوں کو پورا کرنے والی ویب سائٹس کی بہت زیادہ ضرورت تھی۔

قدرتی طور پر، زیادہ تر اسٹارٹ اپ چھوٹے تھے۔ لہذا، زیادہ تر پیشرفت چھوٹی ٹیموں میں ہوئی، جس کا حتمی مقصد اکثر وقت سے مارکیٹ میں تیزی سے ہوتا ہے۔ چونکہ دیر سے ہونے کا مطلب مارکیٹ شیئر کھونا تھا۔

ان پابندیوں کا مقابلہ کرنے کے لیے جو آبشار ماڈل نے مصنوعات کو جلد از جلد مارکیٹ میں لانے کے لیے لاحق ہیں، 1990 کی دہائی کے دوران مختلف ڈویلپرز نے مختلف طریقے وضع کیے تھے۔ ان میں Rapid Application Development (RAD)، سکرم، ایکسٹریم پروگرامنگ (XP)، Kanban، اور دیگر شامل ہیں۔

پھر، 2001 میں کسی وقت، 17 ڈویلپرز جنہوں نے ابتدائی فرتیلی ترقی کی ایک شکل یا دوسری شکل پر عمل کیا، یوٹاہ، USA میں اکٹھے ہوئے۔ پھر انہوں نے 'منشور برائے چست سافٹ ویئر ڈویلپمنٹ' شائع کرکے اپنی میٹنگ ختم کی۔

یہ منشور 4 اقدار اور 12 اصولوں پر مبنی ہے۔

فرتیلی ترقی کے 4 اقدار اور 12 اصول

ان تجربات سے جو انہوں نے اپنی میٹنگ کے دوران اکٹھے کیے، 17 ڈویلپرز نے مزید موثر طریقے سے سافٹ ویئر بنانے کے لیے اقدار کے ایک سیٹ پر معاہدہ کیا۔

یہ چار اقدار درج ذیل ہیں:

1. افراد اور تعاملات زیادہ عمل اور اوزار. اس کا مطلب ہے کہ ایک مخصوص عمل کی پیروی کرتے ہوئے ٹولز کے ساتھ سافٹ ویئر تیار کرنا ضروری ہے۔ لیکن قابل لوگوں کا مل کر زیادہ مؤثر طریقے سے کام کرنا زیادہ ضروری ہے۔
   
   
2. ورکنگ سافٹ ویئر جامع دستاویزات سے زیادہ۔ یہ اصل سافٹ ویئر کی ترقی کے عمل سے پہلے پہلے سافٹ ویئر ڈیزائن کرنے اور اس کے لیے دستاویزات لکھنے کے آبشار کے طریقہ کار پر حملہ کرتا ہے۔
   
   
3. گاہک کا تعاون معاہدے پر بات چیت. صرف گاہک یا صارف کے ساتھ مل کر کام کرنے سے ہی آپ وہی سیکھ سکتے ہیں اور تیار کر سکتے ہیں جو گاہک کو درکار ہے۔ یہ زیادہ قدر پیدا کرتا ہے۔
   
   
4. تبدیلی کا جواب دینا ایک منصوبہ پر عمل کرنے پر. پراجیکٹ پلان پر عمل کرنا ضروری ہے۔ لیکن منصوبہ زیادہ سخت نہیں ہونا چاہیے۔ اسے اسٹیک ہولڈر کی توقعات پر پورا اترنے کے لیے تبدیلیوں کو ایڈجسٹ کرنا چاہیے۔

مندرجہ بالا یہ چست منشور کی اقدار 12 اصولوں پر مبنی ہیں اور وہ درج ذیل ہیں:

1. قیمتی سافٹ ویئر کی ابتدائی اور مسلسل ترسیل سے صارفین کا اطمینان۔
2. دیر سے ترقی میں بھی تبدیلی کی ضروریات کا خیرمقدم کرتے ہیں۔
3. کام کرنے والے سافٹ ویئر کو کثرت سے فراہم کریں (مہینوں کے بجائے ہفتوں)
4. کاروباری لوگوں اور ڈویلپرز کے درمیان قریبی، روزانہ تعاون
5. منصوبے حوصلہ افزا افراد کے ارد گرد بنائے جاتے ہیں، جن پر بھروسہ کیا جانا چاہیے۔
6. آمنے سامنے گفتگو مواصلات کی بہترین شکل ہے (مقام)
7. ورکنگ سافٹ ویئر ترقی کا بنیادی پیمانہ ہے۔
8. پائیدار ترقی، ایک مسلسل رفتار کو برقرار رکھنے کے قابل
9. تکنیکی اتکرجتا اور اچھے ڈیزائن پر مسلسل توجہ
10. سادگی — نہ کیے گئے کام کی مقدار کو زیادہ سے زیادہ کرنے کا فن — ضروری ہے۔
11. بہترین آرکیٹیکچرز، تقاضے اور ڈیزائن خود منظم کرنے والی ٹیموں سے نکلتے ہیں۔
12. باقاعدگی سے، ٹیم اس بات پر غور کرتی ہے کہ کس طرح زیادہ موثر بننا ہے اور اس کے مطابق ایڈجسٹ ہوتا ہے۔

تکرار یا سپرنٹ

فرتیلی سافٹ ویئر ڈویلپمنٹ میں تکرار یا اسپرنٹ عام طور پر 1 سے 4 ہفتوں کے مختصر عرصے کے ہوتے ہیں، جس میں ترقیاتی کام ٹوٹ جاتے ہیں۔ یہ چیزوں کو منظم کرنے میں آسان بناتا ہے، کیونکہ اس کے لیے کم منصوبہ بندی کی ضرورت ہوتی ہے۔

ہر ٹیم عام طور پر مختلف افعال کے حامل اراکین پر مشتمل ہوتی ہے، اور ان میں منصوبہ بندی، تجزیہ، ڈیزائن، کوڈنگ اور جانچ شامل ہو سکتی ہے۔

ٹیم سافٹ ویئر پر ہر تکرار یا سپرنٹ پر ایک ساتھ کام کرتی ہے۔ اور وہ آخر میں کام کرنے والی مصنوعات تیار کرتے ہیں۔ ایگیل مینی فیسٹو کے مطابق، سافٹ ویئر کا یہ کام کرنے والا ٹکڑا حقیقی ترقی کا ایک پیمانہ ہے۔

مصنوعات اور گاہک کی ضروریات پر منحصر ہے، ایک تکرار کی مصنوعات مارکیٹ میں جاری ہوسکتی ہے یا نہیں. لہذا، یہ اکثر ایک ہی ریلیز کے لئے بہت سے تکرار لیتا ہے.

فرتیلی ترقی کے فوائد

جیسا کہ آپ تصور کر سکتے ہیں، چست طریقہ کار بہت سے فوائد لاتا ہے۔ وہ درج ذیل ہیں:

1. خیالات کا تیز تر نفاذ
2. آبشار کے نقطہ نظر سے زیادہ لچک
3. منظم تکرار کے ساتھ بہتر پیداوری
4. صارف کی بات چیت کے ذریعے بہتر مصنوعات
5. غلطیوں کی جلد شناخت کر کے انہیں ختم کر دیا جاتا ہے۔

فرتیلی طریقہ کار کے نقصانات

فرتیلی ترقی کے طریقہ کار کے ساتھ کام کرنے کے کچھ نقصانات بھی ہیں۔ اور ان میں شامل ہو سکتے ہیں:

1. شروع میں مکمل اخراجات کا اندازہ لگانا مشکل ہو سکتا ہے۔
2. اسے بہت سارے کسٹمر ان پٹ کی ضرورت ہے۔
3. بہت سے غیر منصوبہ بند کام شامل ہیں۔
4. کوئی واضح طور پر بیان کردہ منصوبے کا اختتام نہیں ہے۔

فرتیلی طریقے کب استعمال کریں۔

1. جب آپ اندازہ نہیں لگا سکتے کہ سافٹ ویئر کی کیا ضرورت ہے۔
2. آپ کے پاس صارفین تک کافی رسائی ہے۔
3. آپ ایک ویب ایپ یا اپ ڈیٹ کرنے میں آسان سسٹم تیار کر رہے ہیں۔
4. آپ کو جلد از جلد ریلیز کے ساتھ مارکیٹ شیئر پر قبضہ کرنے کی ضرورت ہے۔

مقبول فرتیلی ترقیاتی فریم ورک

بہت سے مقبول فرتیلی ترقیاتی فریم ورک ہیں۔ کچھ نے 2001 کے فرتیلی منشور سے پہلے شروع کیا، جبکہ کچھ بعد میں آئے۔

ایک فریم ورک کا مقصد صرف ایک طریقہ کار کے قواعد کی وضاحت کرنا ہے۔ لہذا، جب کہ سب سے زیادہ مقبول فریم ورک آپ کے حوالہ کے لیے ذیل میں درج ہیں، وہاں اور بھی بہت سے ہیں۔ اور آپ اپنی ٹیم کو فٹ کرنے کے لیے اپنا بنانے یا موجودہ فریم ورک میں ترمیم کرنے کے لیے بھی آزاد ہیں۔

1. Scrum: یہ فریم ورک 10 یا اس سے کم اراکین والی ٹیموں کے لیے ڈیزائن کیا گیا ہے۔ روزانہ 2 منٹ کی میٹنگوں کے ساتھ کام کو 4-15 ہفتوں کے سپرنٹ میں تقسیم کیا جاتا ہے۔
   
   
2. Kanban: Toyota سے شروع ہونے والا، Kanban ایک جاپانی لفظ ہے جس کا مطلب بل بورڈ ہے اور یہ ان ٹیموں کے لیے بہت مددگار ہے جو بصری امداد کی تعریف کرتی ہیں۔ ٹاسکس کو ایک اسٹیج سے دوسرے اسٹیج پر منتقل کیا جاتا ہے جیسے کہ اسٹکی نوٹس یا ایپس کا استعمال کرتے ہوئے بصری نمائندگی۔
   
   
3. ریپڈ ایپلیکیشن ڈویلپمنٹ RAD: یہ جملہ عام طور پر فرتیلی سافٹ ویئر ڈویلپمنٹ یا جیمز مارٹن طریقہ دونوں کا حوالہ دے سکتا ہے۔ RAD صارف کے انٹرفیس کی ضروریات پر توجہ مرکوز کرتا ہے اور پروٹو ٹائپنگ پر بہت زیادہ انحصار کرتا ہے۔
   
   
4. دبلی پتلی شروعات: یہ فریم ورک ان لوگوں کے لیے ہے جنہیں کسی پروڈکٹ یا سروس کو تیار کرنے کی ضرورت ہے، لیکن سب سے پہلے اس کی مارکیٹ کے قابل عمل ہونے کا تعین کرنا ہوگا۔ اس میں یہ دیکھنے کے لیے تجربات کا استعمال شامل ہے کہ کیا کام کرتا ہے اور کیا نہیں۔

دیگر قابل ذکر فریم ورک میں ایکسٹریم پروگرامنگ (XP)، اڈاپٹیو سافٹ ویئر ڈویلپمنٹ، ایگیل ماڈلنگ، ڈائنامک سسٹمز ڈیولپمنٹ میتھڈ، اور اسکیلڈ ایجائل فریم ورک شامل ہیں۔

فرتیلی بمقابلہ آبشار کے طریقے

یہاں سافٹ ویئر تیار کرنے کے چست اور آبشار کے طریقوں پر ایک ساتھ نظر ہے۔ اس سے یہ جاننے میں مدد مل سکتی ہے کہ ہر طریقہ دوسرے کے خلاف کیسے کھڑا ہے۔ لہذا، آپ آسانی سے اپنے کام کے لیے بہترین ٹولز کا انتخاب کر سکتے ہیں۔

فرتیلا	آبشار
اضافہ اور تکراری نقطہ نظر	لکیری اور ترتیب وار لائف سائیکل ماڈل
تبدیل کرنے کے لئے لچکدار	سخت نفاذ
ٹیسٹ اور جائزے جاری ہیں۔	تکمیل کے بعد صرف ایک ٹیسٹنگ مرحلہ ہے۔
تقاضے بدل سکتے ہیں۔	تقاضے منصوبہ بندی کے بعد طے ہوتے ہیں۔
بہت سے چھوٹے منصوبوں کا مجموعہ	ایک واحد پروجیکٹ
مزید گاہک کی شمولیت	کم گاہک کی شمولیت

انکولی بمقابلہ پیشن گوئی ترقی

چست سافٹ ویئر ڈویلپمنٹ کا مقصد حقیقی دنیا میں ہونے والی تبدیلیوں کو اپنانا ہے۔ اور یہ اکثر گاہک یا صارف کی ضروریات کا نتیجہ ہوتے ہیں۔ موافقت آبشار کے ماڈل کی پیش گوئی کرنے والی نوعیت کے بالکل برعکس ہے۔

سسٹم تیار کرتے وقت فرتیلی طریقوں کا استعمال کرنا سمجھ میں آتا ہے کہ آپ کو اتنا یقین نہیں ہے کہ چیزیں کیسے نکلیں گی۔ یا جب کسی صنعت میں مسلسل تبدیلیاں اور ارتقاء ہو رہا ہو۔ انٹرنیٹ ایک بڑی مثال ہے۔

بصورت دیگر، اگر آپ کسی ایسے نظام یا مارکیٹ کے لیے تیار کر رہے ہیں جس کے بارے میں آپ کو سب کچھ معلوم ہے، اور جس میں شاید ہی کوئی تبدیلی آتی ہو یا تبدیلی کے لیے مدافعت ہو۔ پھر، آبشار کے فلسفے کی پیشین گوئی کی نوعیت مددگار ثابت ہو سکتی ہے۔

سافٹ ویئر کاریگری

سافٹ ویئر کرافٹسمین شپ ایک اور فلسفہ ہے جو فرتیلی ترقی کے اصولوں پر استوار ہے اور یہ کسی پروجیکٹ میں شامل سافٹ ویئر ڈویلپرز کی مہارتوں پر زور دینے پر توجہ مرکوز کرتا ہے۔

سافٹ ویئر دستکاری کی تحریک کا ایک منشور بھی ہے اور اس میں کہا گیا ہے:

سافٹ ویئر کاریگروں کے خواہشمند ہونے کے ناطے ہم اس کی مشق کرکے اور دوسروں کو دستکاری سیکھنے میں مدد کرکے پیشہ ورانہ سافٹ ویئر کی نشوونما کے بار کو بڑھا رہے ہیں۔ اس کام کے ذریعے ہم قدر میں آئے ہیں: · نہ صرف کام کرنے والے سافٹ ویئر، بلکہ اچھی طرح سے تیار کردہ سافٹ ویئر بھی · نہ صرف تبدیلی کا جواب دینا، بلکہ قیمت میں مسلسل اضافہ کرنا · نہ صرف افراد اور تعاملات، بلکہ پیشہ ور افراد کی کمیونٹی · نہ صرف گاہک تعاون، بلکہ نتیجہ خیز شراکت داری، یعنی بائیں طرف کی اشیاء کے تعاقب میں ہم نے دائیں طرف کی اشیاء کو ناگزیر پایا ہے۔  © 2009، زیر دستخط۔ یہ بیان آزادانہ طور پر کسی بھی شکل میں نقل کیا جا سکتا ہے، لیکن صرف اس نوٹس کے ذریعے مکمل طور پر

نتیجہ

فرتیلی طریقہ کار اور سافٹ ویئر کی ترقی پر ہماری نظر کے اختتام پر، آپ دیکھ سکتے ہیں کہ وہاں بہت سارے اختیارات موجود ہیں۔

ہر ٹیم مختلف ہے۔ اور جس طرح مختلف ٹیموں نے بدلتے وقت کے مطابق اپنے مختلف طریقے تیار کیے ہیں۔ آپ کو بھی یا تو پہلے سے قائم کردہ فریم ورک کے ساتھ جا کر یا اسے اپنی ٹیم کے مطابق ڈھال کر ڈھالنا پڑے گا۔