روش های سريع الانتقال (چابک) توسعه نرم افزار

صفحه 1:
فصل دوازدهم 

صفحه 2:
5 اهداف جلسه تقسیم‌بندی متدولوژي‌های توسعه نرم‌افزار © معیارهای مقایسه متدولوژي‌ها با یکدیگر * مقایسه متدولوژي‌ها بر اساس معیارهای مطرح شده * اصول بنیادی متدولوژي‌های چابک * معرفی چند روش چابك 

صفحه 3:
‎a‏ متدولوژي توسعه نرم‌افزار ‏* فرآیند تولید و توسعه نرم‌افزار ذاتا يك فرآیند بي‌نظم و ير هرج و مرج است. براي نظم دادن به اين فر آیند. متدولوژي‌هاي توسعه نرم‌افزار مطرح شدند ‏* متدولوژي توسعه نرم‌افزار مشخص مي‌کند. چه فر آورده‌اي (۲۷۲۵۲) توسط جه كسي (۲۷۷0) و در چه زماني ‎Ji (When)‏ ‏شود. 

صفحه 4:
|“ تقسیم بندی متدولوژي‌های توسعه نرم‌افزار 5 متدولوژي‌های سنگین وزن ‎(Heavyweight)‏ * فازها بطور کامل اجرا شده و مستندات کامل ایجاد مي‌شود * متدولوژي‌های سبک 534 ‎(Lightweight)‏ * فازها به صورت کوتاه و مستندات به اندازه ایجاد مي شوند * متدولوژیهای چابک در دسته دوم قرار دارند 

صفحه 5:
متدولوژی سنگین وزن © در 25 سال اخیر روش‌هاي بسیار زبادي براي توسعه نرم‌افزار معرفي شدند اما امروزه تعداد بسیار اندكي از آنها مورد استفاده قرار مي‌گیرد! * متدولوژي‌هاي فعلي بیش از اندازه ماشین گرا و مکانیزه هستند و بصورت فرآيندي وارد جزئیات غيرضروري مي‌شوند. به همین دلیل این نوع متدولوژها را سنگین وزن مي‌نامند 

صفحه 6:
‎a‏ مشکلات متدولوژي‌هاي سنگین وزن ‏* مشتریان نرم‌افزارها حاضر نیستند که براي دست یافتن به نرم‌افزارهاي مورد نیاز خود مدث زيادي منتظر بمانند ‏" رقاپت پسهار شدید شركت‌هاي تولید نرم‌افزار براي ارائه خدمات نرم‌افزاري به کاربران ‏" تغييرپذيري بسیار زیاد نرم‌افزارهاي امروزي انکارناپذیر است 

صفحه 7:
1 لزوم تغییرات در توسعه ‎ate‏ ( Op Oko! De are creeds rurcratky hetee. "sid wi Der wa ard 7 3 

صفحه 8:
1 لزوم تغییرات در توسعه ‎ate‏ ( We Oko! (Der are abroad rurcratcny kate. 1 aed cent ony chit. Dee worked bard te preven ‏رجات‎ ‎f= ‎De N A 

صفحه 9:
1 لزوم تغییرات در توسعه نرم‌افزار 

صفحه 10:
5 معیارهای مقایسه متدولوژي‌ها با یکدیگر روش معيار موفقيت اندازه پروژه سبک مدیربت نحوه مستندسازی چرخه‌ها اندازه تیم برگشت سرمایه 

صفحه 11:
روش * روش‌های چابک بصورت ۸02/0676 يا سازكار عمل می‌کنند هه یمن دهد 1 

صفحه 12:
* معیار موفقیت در روش‌های چابک دستیابی به ارزش کاری cow! (Business Value) oe ‏درا‎ ۴ 12 

صفحه 13:
1" اندازه پروژه * اندازه پروژه در روش‌های چابک کوچک است این مسأله از محبوبیت روش‌های چابک نمی کاهد !!! (آمار نشان می‌دهد که تعداد پروژه‌های کوچک بسیار بیشتر است) 18 

صفحه 14:
‎a |‏ سبك مدیر یت ‏* مدیریت در روش‌های چابک بصورت غیرمتمرکز و آزاد است ‎ ‎14 

صفحه 15:
نحوه مستندسازی * مستندسازی در روش‌های چابک بصورت بسیار محدود انجام می‌شود 15 

صفحه 16:
جرخه‌ها « " تعداد جرخدها (076165)) در روشهاى جابك بسيار زياد است اما زمان آنها كوتاست 16 

صفحه 17:
7 اندازه تیم * در روش‌های چابک اندازه تیم کوچک است (بین 20 تا 30 نفر) 17 

صفحه 18:
‎at‏ برگشت سرمایه ‏* در روش‌های چابک سرمایه خیلی زود در طول پروژه بر می‌گردد 

صفحه 19:
مقایسه متدولوژي‌هاي سبک و سنگین ile Method: He: ‘Adaptive Business Value Conformation to plan Small Large Decentralized ‘Autocratic Low Heavy People-Oriented Process-Oriented "Numerous "Limited Unpredictable/ Predictable | Exploratory ‘Small/Creative_ Large 

صفحه 20:
5 بیانیه روش‌های جابک * در سال 2001 متخصصان روش‌هاي چابک بيانيه‌اي را منتشر کردند و این روش‌ها را در چهار اصل كلي به دنياي نرم‌افزار معرفي نمودند که عبارتند از: * فردگرايي و تعامل برتر از فرآیندها و ابزرها *_نرم‌فزارقابل اجرابهتر از مستندات مفهومي * همکاري با مشتریان بهتر از مذاکرات قراردادگرا پاسخ به تغییر بهتر از دنبال‌روي از طرح 

صفحه 21:
‎ai‏ معروف‌ترین روش‌هاي چابک ‎= XP (Extreme Programming) ‎= Scrum ‎= Crystal Family ‎= FDD (Feature Driven Development) = Dynamic System Development ‎= Adaptive Software Development ‎= Open Source Software Development ‎21 

صفحه 22:
AP (Extreme (539) 9 Programming) * بر مبنای اصول سادگی. همگاری و پازخورد سریع استوار است * ایده این روش ‎Beck lugs‏ 16601 در سال 2000 ارائه شده است * مبتنی بر آزمایش ‎(Test-Driven)‏ * نقش مشتریان بسیار پررنگ است * فرآیند آن شامل 12 فعالیت و 5 فاز است 

صفحه 23:
متدولوژی 26۳ - چرخه حیات EXPLORATION | PLANNING ITERATIONS TO PHASE | PHASE RELEASE PHASE PHASE PRODUCTIONZING fa 1 yt 1 ‘CONTINUOUS INTEGRATION — — ! 0 ‎“ro‏ ۵ ۱ سوم ۱ ‎coutccm‏ { ‎Gs)‏ ۳ نت ارس سود = yo! aS 

صفحه 24:
۷" متدولوژی 2۳ - فازها * چرخه حیات 2۳ شامل پنج فاز است 

صفحه 25:
مشو نورق كذ ‎SP we‏ مسئوليتها * برنامه‌نویس ‎a te ۰‏ 5 * آزمایش‌کننده " بى كيري كننده (1726[»6) مربي = * مدیر (رئیس ارشد) & die 

صفحه 26:
+ متدولوژی 2۳ - فر آورده‌ها ‎User Stories *‏ * معمولاً پشکل متنی بوده و توسط مشتریان نوشته می‌شوند " از طریق آنها نيازمندي‌های سیستم مشخص می‌شود ‎Iteration Plan *‏ * مجموعه‌ای از 51015 ۲750۲ هاست که توسط مشتری انتخاب می‌شوند * در یک تکرار که معمولاً دو هفته طول می‌کشد. تولید می‌شود " طرح‌های تنگرار پا نوجه به اولوبت مشخص شده توسط مشتری اجرا می‌شوند " انتخاب پراساس بودچه تعپین‌شده توسط توسحه‌دهندگان خواهد بود ‎26 

صفحه 27:
۷" متدولوژی ‎XP‏ — فر آور ده‌ها «دام) ‎Release Plan "‏ * مجموعه‌ای از طرح‌های تکرار را در قالب یک نقشه کلی برای رسیدن به نشرها نمایش می‌دهد ‎Task *‏ ۴ زیرمجموعه‌ای از 5101۲ 567] ها هستند 7 ا5ههاز سظر تسکنیکیو کایواولویتسیشترودایندو بسایدسریع لنجام شوند * عاك هآهادر ‎(Iteration Planning, \ Sig pat pe ale ya‏ ‏مشخصميشوند ‎27 

صفحه 28:
|“ متدو لو زى ‎-XP‏ فر آور ده‌ها رداس) ‎Metaphore *‏ * نشان‌دهنده یک تصویر کلی از سیستم است © برای هر عنصر در سیستم یک نام در نظر گرفته می‌شود " ارتباط بین عناصر درگیر در سیستم از طریق 7/0/2۳0۲ مشخص می‌شود ‎Spike =‏ " يك رادحل 523 ‎F Complorlee aay (Spike Solution)‏ بوسپله آن می‌توان راه‌حل‌های بالقوه را کشف کرد " در مواردی که 58017 27567 ها حساس و مهمند از آن استفاده می‌شود 

صفحه 29:
‎a‏ متدولوژی ‎XP‏ — عملیات ‎Planning Game *‏ " یک تحامل محصور ‎GPa Qe (Close Interaction)‏ 9 پرنامه‌وپس پدست می‌آید * پرنامه‌نویس کار لازم پرای پیاده‌سازی گزارش‌های مشتری را تخمین می‌زند و مشتری در مورد حوزه و زمان نشرها تصمیم‌گیری می‌کند ‎Simple Design *‏ * تأکید اصلی در اين روش بر روی طراحی ساده‌ترین راهحل ممکن است و پيچيدگي‌های غیرضروری و کدهای اضافی به سرعت حذف می‌شوند ‎29 

صفحه 30:
6 متدو لو زى ۳ - عملیات رد ‎Testing "‏ " توسعه نرم‌افزار یک فرآیند آزمایش‌گراست (9۲-07176ع۲) © قبل از اینکه برنامه‌نویس یک خاصیت را اضافه کند. برای آن یک تست طراحی می‌کند که بصورت پیوسته اجرا می‌گردد ‎Refactoring "‏ * بازسازی سیستم با حذف موارد تکراری. بهبود ارتباطات. ساده‌سازی و افزايش انعطاف پل بری سیستم ‎Pair Programming "‏ " دونفر کد را روی یک کامپیوتر می‌نوبسند (پک کدنوپس و یک متخصص استراتژی) 

صفحه 31:
6 متدو لو زى ۳ - عملیات رد ‎Collective Ownership "‏ * هر فردی می‌تواند کد را در هر زمانی تغییر دهد ‎Continuous Integration "‏ * كد جديد در حداقل زمان ممكن به كد اوليه مى بيوندد. بنابراين سيسانم دفعات زيادى در روز يكبارجه شده و ساخته مى شود * ۷۷۵۵۱40 ۲۲۵0۱۲ " حداکثر چهل ساعت کار در هفنه کافی است * این مورد اجباری است و بیشتر از این ساعات کار مجاز نمی‌باشد ‎31 

صفحه 32:
59 متدو لو زى ۳ - عملیات رد ‎On- Site Customer *‏ * مشتری باید بصورت تمام وقت برای تیم توسحه در دسترس باشد ‎Coding Standards *‏ " قواعد كدنويسى بايد توسط برنامهنويسان رعایت شود و ارتباط بين كدها مورد نوجه قرار كيرد ‎32 

صفحه 33:
FDD (Feature Driven ‏متدولوژی‎ Development 5 * تمام فرآبند توسعه نرم افزار را پوشش نمی‌دهد و بیشتر روی دو فاز طراحی و پیاده‌سازی متمرکز می‌شود * برای استفاده بهمراه سایر فعالیت‌های یک پروژه توسعه نرم‌افزار طراحی شده است و هیچ مدل فرآیند خاصی لازم ندارد * مبتنی بر توسعه تکراری با انتخاب بهترین و موثرترین فعالیت‌هاست * روی جنبه‌های کیفتی تأکید دارد و شامل نشرهای محسوس و پیگیری دقیق پیشرفت پروژه است 

صفحه 34:
1 فر آیندهای ۳۳۳ * شامل پنج فرآبند ترتیبی است که از طربق آنها فعالیت‌های طراحی و پیاده‌سازی انجام می‌شود Develop Butta a an Overall {fm Features [tm Pin PY 1b Design Dy | ye} Bulla BY ‏سا‎ tun Feature Feature Feature * قسمت تکراری فرآیند 1910 (طراحی و ساخت) از توسعه چابک حمایت می‌کند * هر تکرار از یک خاصیت. معمولاً 2 تا 3 هفته زمان می‌برد 

صفحه 35:
۷" متدولوژی (۲1(1 - نقش‌ها ‎FDD "‏ نسقشهای‌خود را بسه سه هسته کسلی‌تسقسیم‌می‌کسند * نقش‌های کلیدی ‏* نقش‌های حمایتی ‏* ای ای © 

صفحه 36:
۷" متدولوژی (۲۲(1 - نقش‌هاي كليدي مدير يروزه معمار ارشد مدير توسعه بجي ۰ مالك كلاس ‎(Class Owner)‏ : al Manager) ‏متخصص دامنه‎ 

صفحه 37:
عمدو نورى ‎TAD‏ سس‌هاي حمایتی (Release Manager) yi ‏مدير‎ " (Language Guru) (43 )9bio (Build Engineer) 23bs ‏مميهندس‎ " (Toolsmith) 4\3\ Jomo ™ em Administrator) pimuw ps0 © 37 

صفحه 38:
5 متدولوژی ( - نقش‌هاي اضافی " سه نقش اضافى كه در همه يروزهها وجود دارند ‎(Tester) 09335, $203) *‏ * مستقر کننده ‎(Deployer)‏ ‏* لویسنده فني ‎(Technical Writer)‏ * هر عضو می‌تواند چندین نقش بازی کند و هر نقش ممکن است به چند عضو نسبت داده شود 

صفحه 39:
1 متدولوژی (۲1(1] - بهتوین تجربیات ‎Domain Object Modeling *‏ * شامل استخراج و توضیح دامنه مسأله می‌باشد ‎Developing By Feature "‏ * توسحه و بررسی میزان پیشرفت پروژه از طریق دنبال کردن پیاده‌سازی لیست وظایف و خواص مشخص شده ‎Individual Class Ownership *‏ ‏" برای هر کلاس شخصي وجود داشته باشد که مسئول سازگاری. کارایی و صحت آن باشد 

صفحه 40:
1 متدولوژی (۲1(1] - بهتوین تجربیات ‎Feature Teams *‏ " تیم كوچکي که به‌صورت پویا شکل گرفته‌اند ‎Inspection *‏ * استفاده از معروفترین و بهترین مكانيزهاي شناسايي خطاها ‎Regular Builds *‏ " تضمین اینکه هميشه يك سیستم قابل اچرا و قابل نمایش دادن (126720) وجود دارد ‎Configuration Management *‏ ‏* داشتن تاریخچه تغییرات و نسخه‌هاي مختتلف (بهمراه کد منبع) 

صفحه 41:
‎a‏ متدولوژی (1(1] - بهتوین تجربیات ‎Progress Reporting * ‏* روند اجراي فعالیت‌ها به صورت کامل و در سطوح مختلف سازماني ‏گزارش شود ‎ 

صفحه 42:
5 متدو لوژی 50۳۰ * از یک استراتژی در بازی راگبي اقتباس شده است * تأکید روی اصول انعطاف‌پذیری. سازگاری و سودمندی است * نمرکز: چگونه اعضای تیم بايد عمل كنند تا سیستم تولید شده. در یک محیط کاملاً تغییرپذیر. انعطاف‌پذیری کافی داشته باشد * ایده اصلی: توسعه سیستم‌ها شامل چندین متغیر محیطی و تکنیکی است (نیازهاء زمان. منابع و تکنولوژی)که احتمالاً در طول فرآیند توسعه تغییر می‌کنند * این موضوع فرآیند توسعه را پیچیده و غیرقابل پیش‌بینی می‌کند 42 

صفحه 43:
1" متدو لوژی 50۲۳0 - فر آورده‌ها * فرآورده‌های 5071270 به سه دسته اصلی تقسیم می‌شوند ‎Product Backlog *‏ ‎Sprint Backlog *‏ ~=_ Sprint BurnDown Chart * لا 6 

صفحه 44:
Scrum - ۳۲۵00 ‏متدولوژی]‎ ‎Backlog * شامل یک صف اولویت‌بندی شده است که در آن وظیفه‌مندي‌های تکنیکی و حرفه نمایش داده شده‌اند که باید توسعه داده شوند * برای هر مورد مشخص شده در این فرآورده. خواصی مانند وضعیت. اولویت و تخمین کاری وجود دارد 

صفحه 45:
متدولوژی] 50۲۱0 - ما5 ‎Backlog‏ * مجموعه‌ای از موارد حرفه و فني که برای تکرار جاری ‎cyl 9 ileus cuinile; (Current Iteration)‏ 0559175 نمایش داده می‌شوند * نیازها در این فرآورده به وظایف تبدیل می شوند * برای هر وظیفه یک شرح کوتاه وجود دارد و مشخص می‌شود که چه کسی مسئول انجام آن است و همچنین وضعیت و تعداد ساعات باقیمانده تا تکمیل شدن هر وظیفه در اين فرآروده مشخص می‌شود 

صفحه 46:
Scrum - Sprint BurnDown ‏متدولوزى‎ ‏هن‎ * ساعات باقیمانده برای تکمیل شدن همه وظایف مربوط به یک ‎Sprint‏ را در قالب یک گراف بصورت برجسته نمایش می‌دهد Work Remaining (hous) o 68 8 8 8 8 8 8 7 2 35 4 5 8 7 8 8 1011121314 15 16 47 18 19.20.24 22 20.24 25 26-27 28 29 30 ‘Serum Day 

صفحه 47:
۷" متدو لوژی 50۱1۳0 - نقش‌ها Scrum Master Product owne: "i Scrum team we 2 ‏ج حا‎ See Manager ‏معو‎ 0 ory 1+41 

صفحه 48:
Crystal oolgil& ‏متدولوژی‌های‎ 4 * شامل مجموعه‌ای از متدولوژي‌های متفاوت است که مناسبترین آنها برای هر پروژه منحصر به فرد انتخاب می‌شود * دارای اصولی است که متدولوژي‌ها را برای شرایط مختلف موجود در پروژه‌ها سفارشی می‌کند * روش ‎oi Crystal‏ م ىكند كه ‎Ky‏ متدولوژی مناسب براساس اندازه و میزان بحرانی‌بودن پروژه انتخاب شود 

صفحه 49:
5 متدولوژي‌هاي خانواده ۲۱5۵1 (ادامه) * هر عضو از خانواده 07511 با یک رنگ مشخص می‌شود که میزان سنگینی متدولوژی را نشان می‌دهد. رنگ تاریکتر نشان دهنده متدولوژی سنگین تر است C: Comfort D: Discretionary Money E: Essential Money L: Life of شالك تالت ‎of the‏ ‎system‏ 49 

صفحه 50:
5 متدولوژي‌هاي خانواده ۲۷5۵1 ‎(tot)‏ * تمامی پروژه‌ها از توسعه افزایشی با بازه زمانی حداکثر 4 ماه استفاده می ‎HES‏ * تأکید روی ارتباطات و همکاری بین افراد درگیر در پروژه است * هیچ فعالیت با ابزاری را برای توسعه محدود نمی‌کند * مثلاً می‌توان از فعالیت‌های 26۳ و 962۳90 با هم در این روش استفاده کرد 

صفحه 51:
‎at‏ مزایای روش‌های سریع الانتقال ‏* تأکید روی شرکت‌دادن مشتری در پروژه‌ها است که در پروژه‌های کاربردی بسیار مفید است ‏* تأکید روی کارگروهی و ارتباط متقابل که در بالا بردن راندمان کاری نقش مهمی دارد ‏۴ همه افراد درگیر در پروژه در قبال کیفیت محصول مسئولند ‏* سنجش مستمر کارهای انجام شده از مزابای بسیار مفید این روش‌ها است ‎51 

صفحه 52:
‎at‏ مزایای روش‌های سریع الانتقال (داس) ‏۴ توسعه افزایشی که با روش‌های مدرن توسعه نرم‌افزار سازگار است ‏* طراحی ساده و روشن برای فرآیند توسعه ‏* بازبینی‌های مستمر که به بالا رفتن کیفیت کار برنامه‌نوبسان کمک می‌کند 

صفحه 53:
5 معایب روش‌های سریع الانتقال * بدلیل کمبود فعالیت‌های طراحی در اين روشهاء اكر كد بيش از جند هزار خط باشد ممكن است فرآيند توسعه با موانع خطرناكى برخورد كند " كمبود مستندات مربوط به طراحى در اين روشها آنها را به پروژه‌های کوچک محدود می‌کند و قابلیت‌های استفاده مجدد را در آنها محدود مى كند * کمبود فرآیندهای بازبینی ساخت‌یافته 

صفحه 54:
5 معایب روش‌های سریع الانتقال «دامه) " كمبود فرآيند طراحى منظم و استفاده از بازبينىهاى غير ساخت بيافته باعث اتلاف زمان و هزينه مى شود " كمبود طرح كيفيت. در اين روشها هيج نوع طرح استانداردى براى ارزيابى كيفيت وجود ندارد " كمبود راهنماهاى آموزشى براى استفاده از اين روشها 

صفحه 55: