پاورپوینت پیاده سازی روش چابک یا Agile در توسعه نرم افزار

بسمه‌تعالي ارائه دهنده : مهندس مصطفی مستعلی روش‌های سريع االنتقال (چابک) توسعه نرم افزار اهداف جلسه ‏ نرمافزار تقسيمبندی متدولوژي‌های توسعه ‌ ‌ ‏ متدولوژيها با يکديگر ‌ معيارهای مقايسه ‏ مقايسه متدولوژي‌ها بر اساس معيارهای مطرح شده ‏ متدولوژيهای چابک ‌ اصول بنيادی ‏ معرفی چند روش چابك 2 متدولوژي توسعه نرم‌افزار ‏ فرآيند توليد و توسعه نرم‌افزار ذات ًا يك فرآيند بي‌نظم و پر هرج و مرج است .براي نظم دادن به اين فرآيند ،متدولوژي‌هاي توسعه نرم‌افزار مطرح شدند ‏ متدولوژي توسعه نرم‌افزار مشخص مي‌کند ،چه فرآورده‌اي ( )Whatتوسط چه کسي ( )Whoو در چه زماني ( )Whenتوليد شود. 3 متدولوژيهای توسعه نرم‌افزار ‌ تقسيم بندی ‏ متدولوژيهای سنگين وزن ()Heavyweight ‌ ‏ ‏ فازها بطور کامل اجرا شده و مستندات کامل ايجاد مي‌شود متدولوژيهای سبک وزن ()Lightweight ‌ ‏ فازها به صورت کوتاه و مستندات به اندازه ايجاد مي‌شوند ‏ متدولوژيهای چابک در دسته دوم قرار دارند 4 متدولوژي سنگين وزن ‏ در 25سال اخير روش‌هاي بسيار زيادي براي توسعه نرم‌افزار معرفي شدند اما امروزه تعداد بسيار اندكي از آنها مورد استفاده قرار مي‌گيرد! ‏ متدولوژي‌هاي فعلي بيش از اندازه ماشين‌گرا و مكانيزه هستند و بصورت فرآيندي وارد جزئيات غيرضروري مي‌شوند ،به همين مينامند دليل اين نوع متدولوژها را سنگين وزن ‌ 5 Bنگين وزن مشکالت متدولوژي‌هاي س ‏ مشتريان نرم‌افزارها حاضر نيستند كه براي دست يافتن به نرم‌افزارهاي مورد نياز خود مدت زيادي منتظر بمانند ‏ رقابت بسيار شديد شركت‌هاي توليد نرم‌افزار براي ارائه خدمات نرم‌افزاري به كاربران ‏ تغييرپذيري بسيار زياد نرم‌افزارهاي امروزي انكارناپذير است 6 لزوم تغييرات در توسعه نرم‌افزار No Change! We are already running late. • I need to meet my date. •We worked hard to prevent change at the start. Co st o f ch ang e • Customer big cheese Promised date 7 لزوم تغييرات در توسعه نرم‌افزار No Change! We are already running late. • I need to meet my date. •We worked hard to prevent change at the start. ch ang Co st o f Change & Rework happens at the most expensive time e • Customer big cheese 8 Spec signed off here Promised date لزوم تغييرات در توسعه نرم‌افزار Successful Project Meet Schedule big cheese 9 No Change! Best Product Change! Conflict* Customer متدولوژيها با يکديگر ‌ معيارهای مقايسه ‏ روش ‏ معيار موفقيت ‏ اندازه پروژه ‏ سبک مديريت ‏ نحوه مستندسازی ‏ چرخهها ‌ ‏ اندازه تيم ‏ برگشت سرمايه 10 روش ‏ روشهای چابک بصورت Adaptiveيا سازگار عمل می‌کنند ‌ میشوند يعنی با شرايط منطبق ‌ ‏ روشهای سنگين وزن بصورت پيشگو يا Predictiveعمل ‌ است؟ ‌بينی ش قابلپيپي ابتدا چيز ازاز همه آيا است؟ ‌بينی ش قابل ابتدا چيز همه میکنند آيايعنی در آغاز همه چيز را پيش‌بينی ‌ میکنند ‌ ‏Rigid, ‏Highly Structured ‏Ad hoc, ‏Chaotic ‏Process Discipline ‏Agile Processes ‏RUP ‏CMM - SW 11 معيار موفقيت ‏ روشهای چابک دستيابی به ارزش کاری ‌ معيار موفقيت در ‏ پذيری وزن های روش‌ روش ندارند پذيری معيارانعطاف‌ سنگين وزن سنگين هایهای روش ‌ ندارندراستای رفتن در انعطاف‌ پيش موفقيت وزن سنگين ‌ در ( )Business Valueاست طرح اوليه است 12 اندازه پروژه ‏ ‏ روشهای چابک کوچک است ‌ اندازه پروژه در روشهای سنگين وزن می‌تواند بسيار بزرگ ‌ اندازه پروژه در کاهد!!!!!! نمی‌ نمیکاهد چابک ‌ هایچابک روش‌های محبوبيتروش‌ مسألهازازمحبوبيت اينمسأله باشداين است) بيشتراست) بسياربيشتر کوچکبسيار هایکوچک پروژه‌های تعدادپروژه‌ کهتعداد دهدکه می‌دهد نشانمی‌ (آمارنشان (آمار 13  Bمديريت سبک ‏ روشهای چابک بصورت غيرمتمرکز و آزاد است ‌ مديريت در روشهای سنگين وزن مديريت بصورت مطلق و استبدادی ‌ در کند تصميم‌ امکان است می‌کند فراهممی‌ بهتررارافراهم گيریبهتر تصميمگيری ‌ غيرمتمرکزامکان مديريتغيرمتمرکز مديريت 14 نحوه مستندسازی ‏ ‏ روشهای چابک بصورت بسيار محدود انجام ‌ مستندسازی در میشود ‌ بسيار کار سنگين, های سازي سازي‌ مستند موارد بسياریازاز در بسيار کار سنگين, های ‌ مستند موارد بسياری روشهای سنگين وزن مستندسازی بصورت کامل و جامع دردر ‌ است زمانبریاست دشوارووزمانبری دشوار میشود انجام ‌ 15 چرخهها ‌ ‏ روشهای چابک بسيار زياد است ‌ تعداد چرخه‌ها ( )Cyclesدر اما زمان آنها کوتاست انتظار زمانانتظار شدنزمان طوالنیشدن موجبطوالنی توليد,موجب هایتوليد, چرخه‌های بودنچرخه‌ زمانبربودن ‏زمانبر روشهای سنگين وزن تعداد چرخه‌ها کم است ولی زمان آنها ‌ در شود می‌شود نشرهامی‌ رسيدنبهبهنشرها برایرسيدن برای بسيار زياد است 16 اندازه تيم ‏ روشهای چابک اندازه تيم کوچک است (بين 20تا 30نفر) ‌ در ‏ روشهای سنگين وزن اندازه تيم توسعه بزرگ است ‌ در بود خواهدبود بيشترخواهد بسياربيشتر کوچکبسيار تيمکوچک درتيم همکاریدر خالقيتووهمکاری خالقيت 17 برگشت سرمايه ‏ ‏ روشهای چابک سرمايه خيلی زود در طول پروژه بر می‌گردد ‌ در روشهای سنگين وزن برای برگشت سرمايه بايد تا انتهای ‌ در اند روش روش‌ بصرفه‌اند اقتصادیبصرفه‌ لحاظاقتصادی چابکازازلحاظ هایچابک کردهای پروژه صبر ‌ 18 مقايسه متدولوژي‌هاي سبک و سنگين Agile Methods Heavy Methods Adaptive Predictive Business Value Conformation to plan Small Large Decentralized Autocratic Low Heavy People-Oriented Process-Oriented Numerous Limited Domain Unpredictable/ Exploratory Predictable Team Size Small/Creative Large Approach Success Measurement Project Size Management Style Documentation Emphasis Cycles 19 B بيانيه روش‌هاي چابک ‏ در سال 2001متخصصان روش‌هاي چابک بيانيه‌اي را منتشر كردند و اين روش‌ها را در چهار اصل كلي به دنياي نرم‌افزار معرفي نمودند كه عبارتند از: ‏ فردگرايي و تعامل برتر از فرآيندها و ابزارها ‏ نرم‌افزار قابل اجرا بهتر از مستندات مفهومي ‏ همکاري با مشتريان بهتر از مذاکرات قراردادگرا ‏ دنبالهروي از طرح ‌ پاسخ به تغيير بهتر از 20 معروف‌ترين روش‌هاي چابک  XP (Extreme Programming)     21 Crystal Family FDD (Feature Driven Development)   Scrum Dynamic System Development Adaptive Software Development Open Source Software Development متدولوژی XP (Extreme )Programming ‏ بر مبنای اصول سادگی ،همکاری و بازخورد سريع استوار است ‏ ايده اين روش توسط Kent Beckدر سال 2000ارائه شده است ‏ مبتنی بر آزمايش ()Test-Driven ‏ نقش مشتريان بسيار پررنگ است ‏ فرآيند آن شامل 12فعاليت و 5فاز است 22 متدولوژی – XPچرخه حيات 23  – فازهاXP متدولوژی شامل پنج فاز است XP چرخه حيات  Exploration   24 Planning Iterations To Release    Product Tionizing Maintenance and Dead متدولوژی – XPنقش‌ها و مسئوليت‌ها ‏ برنامه‌نويس ‏ مشتري ‏ آزمايش‌کننده ‏ پي‌گيري کننده ()Tracker ‏ مربي ‏ مشاور ‏ مدير (رئيس ارشد) 25 متدولوژی – XPفرآورده‌ها ‏ ‏ ‏User Stories ‏ میشوند معمول ًا بشکل متنی بوده و توسط مشتريان نوشته ‌ ‏ از طريق آنها نيازمندي‌های سيستم مشخص می‌شود ‏Iteration Plan ‏ میشوند مجموعه‌ای از User Storyهاست که توسط مشتری انتخاب ‌ ‏ میشود میکشد ،توليد ‌ در يک تکرار که معمول ًا دو هفته طول ‌ ‏ ‏ طرح‌های تکرار با توجه به اولويت مشخص شده توسط مشتری اجرا میشوند ‌ تعيينشده توسط توسعه‌دهندگان خواهد بود ‌ انتخاب براساس بودجه 26 متدولوژی – XPفرآورده‌ها ‏ ‏Release Plan ‏ ‏ (ادامه) مجموعه‌ای از طرح‌های تکرار را در قالب يک نقشه کلی برای رسيدن میدهد به نشرها نمايش ‌ ‏Task ‏ ‏ ‏ زيرمجموعه‌ای از User Storyها هستند ‏mیوmلويmتبmmيشتریدارmند و بmmايد سmريmع ‏Taskها از نmmظر تmmکنيکیو کmmار ا اmنmجام شmوند ‏mرحرmيزیتmکرارها()Iteration Planningm ‏Taskها در مmرحmله ط ‌ ‏mیشmوند مmشخصم ‌ 27 متدولوژی – XPفرآورده‌ها ‏ ‏Metaphore ‏ نشان‌دهنده يک تصوير کلی از سيستم اسmت ‏ برای هر عنصر در سيستم يک نام در نظر گرفته می‌شود ‏ ‏ (ادامه) ارتباط بين عناصر درگير در سيستم از طريق Metaphoreمشخص می‌شود ‏Spike ‏ ‏ يک راه‌حل ضربتی ( ،)Spike Solutionبرنامه ساده‌ايست که بوسيله آن می‌توان راه‌حل‌های بالقوه را کشف کرد در مواردی که User Storyها حساس و مهمند از آن استفاده می‌شود 28 متدولوژی – XPعمليات ‏ ‏Planning Game ‏ يک تعامل محصور ( )Close Interactionبين مشتری و ‏ پيادهسازی گزارش‌های مشتری را تخمين ‌ برنامه‌نويس کار الزم برای برنامه‌نويس بدست می‌آيد می‌زند و مشتری در مورد حوزه و زمان نشرها تصميم‌گيری می‌کند ‏ ‏Simple Design ‏ تأکيد اصلی در اين روش بر روی طراحی ساده‌ترين راه‌حل ممکن است و پيچيدگي‌های غيرضروری و کدهای اضافی به سرعت حذف می‌شوند 29 متدولوژی – XPعمليات ‏ ‏Testing ‏ توسعه نرم‌افزار يک فرآيند آزمايش‌گراست ()Test-Driven ‏ ‏ قبل از اينکه برنامه‌نويس يک خاصيت را اضافه کند ،برای آن يک تست طراحی می‌کند که بصورت پيوسته اجرا می‌گردد ‏Refactoring ‏ ‏ (ادامه) بازسازی سيستم با حذف موارد تکراری ،بهبود ارتباطات ،ساده‌‍سازی و افزايش انعطاف‌پذيری سيستم ‏Pair Programming ‏ دو نفر کد را روی يک کامپيوتر می‌نويسند (يک کدنويس و يک متخصص استراتژی) 30 متدولوژی – XPعمليات ‏ ‏Collective Ownership ‏ ‏ (ادامه) هر فردی می‌تواند کد را در هر زمانی تغيير دهد ‏Continuous Integration ‏ کد جديد در حداقل زمان ممکن به کد اوليه می‌پيوندد ،بنابراين سيستم دفعات زيادی در روز يکپارچه شده و ساخته می‌شود ‏ ‏Hour Week 40 ‏ حداکثر چهل ساعت کار در هفته کافی است ‏ اين مورد اجباری است و بيشتر از اين ساعات کار مجاز نمی‌باشد 31 متدولوژی – XPعمليات ‏ ‏On- Site Customer ‏ ‏ (ادامه) مشتری بايد بصورت تمام وقت برای تيم توسعه در دسترس باشد ‏Coding Standards ‏ قواعد کدنويسی بايد توسط برنامه‌نويسان رعايت شود و ارتباط بين کدها مورد توجه قرار گيرد 32 متدولوژی FDD (Feature Driven )Development ‏ نمیدهد و بيشتر روی دو تمام فرآيند توسعه نرم افزار را پوشش ‌ ‏ برای استفاده بهمراه ساير فعاليت‌های يک پروژه توسعه نرم‌افزار ‏ مبتنی بر توسعه تکراری با انتخاب بهترين و موثرترين ‏ روی جنبه‌های کيفتی تأکيد دارد و شامل نشرهای محسوس و پيادهسازی متمرکز می‌شود ‌ فاز طراحی و طراحی شده است و هيچ مدل فرآيند خاصی الزم ندارد فعاليتهاست ‌ پيگيری دقيق پيشرفت پروژه است 33 فرآيندهایFDD ‏ ‏ ‏ شامل پنج فرآيند ترتيبی است که از طريق آنها فعاليت‌های طراحی و پياده‌سازی انجام می‌شود قسمت تکراری فرآيند ( FDDطراحی و ساخت) از توسعه چابک حمايت می‌کند هر تکرار از يک خاصيت ،معمول ًا 2تا 3هفته زمان می‌برد 34 متدولوژی – FDDنقش‌ها ‏ ‏mیکmmند ‏mقشهایخmود را بmmه سmه دmسmته کmmلیتmmقسيمم ‌ FDDن‌ m ‏ نقشهای کليدی ‌ ‏ نقشهای حمايتی ‌ ‏ نقشهای اضافی ‌ 35 متدولوژی – FDDنقش‌هاي کليدي ‏ مدير پروژه ‏ معمار ارشد ‏ مدير توسعه ‏ برنامهنويس ارشد ‌ ‏ مالك كالس ()Class Owner ‏ متخصص دامنه ()Domain Manager 36  – نقش‌هايFDD متدولوژی حمايتي 37 )Release Manager( مدير نشر  )Language Guru( مشاور زبان  )Build Engineer( مهندس ساخت  )Toolsmith( مسئول ابزار  )System Administrator( مدير سيستم  متدولوژی – FDDنقش‌هاي اضافي ‏ ‏ سه نقش اضافی که در همه پروژه‌ها وجود دارند ‏ آزمايشکننده ()Tester ‌ ‏ مستقرکننده ()Deployer ‏ نويسنده فني ()Technical Writer میتواند چندين نقش بازی کند و هر نقش ممکن است هر عضو ‌ به چند عضو نسبت داده شود 38 Bين تجربيات متدولوژی – FDDبهتر ‏ ‏Domain Object Modeling ‏ ‏ شامل استخراج و توضيح دامنه مسأله می‌باشد ‏Developing By Feature ‏ توسعه و بررسی ميزان پيشرفت پروژه از طريق دنبال کردن پيادهسازی ليست وظايف و خواص مشخص شده ‌ ‏ ‏Individual Class Ownership ‏ برای هر کالس شخصي وجود داشته باشد که مسئول سازگاری ،کارايی و صحت آن باشد 39 Bين تجربيات متدولوژی – FDDبهتر ‏ ‏Feature Teams ‏ ‏ ‏Inspection ‏ ‏ استفاده از معروفترين و بهترين مكانيزهاي شناسايي خطاها ‏Regular Builds ‏ ‏ تيم كوچكي كه به‌صورت پويا شكل گرفته‌اند تضمين اينكه هميشه يك سيستم قابل اجرا و قابل نمايش دادن ( )Demoوجود دارد ‏Configuration Management ‏ داشتن تاريخچه تغييرات و نسخه‌هاي مختلف (بهمراه كد منبع) Bين تجربيات متدولوژی – FDDبهتر ‏ ‏Progress Reporting ‏ روند اجراي فعاليت‌ها به صورت كامل و در سطوح مختلف سازماني گزارش شود متدولوژيScrum ‏ از يک استراتژی در بازی راگبي اقتباس شده است ‏ انعطافپذيری ،سازگاری و سودمندی است ‌ تأکيد روی اصول ‏ تمرکز :چگونه اعضای تيم بايد عمل کنند تا سيستم توليد شده ،در انعطافپذيری کافی داشته باشد ‌ يک محيط کاملاً تغييرپذير، ‏ ايده اصلی :توسعه سيستم‌ها شامل چندين متغير محيطی و تکنيکی است (نيازها ،زمان ،منابع و تکنولوژی)که احتمال ًا در طول فرآيند میکنند توسعه تغيير ‌ ‏ اين موضوع فرآيند توسعه را پيچيده و غيرقابل پيش‌بينی می‌کند 42  فرآورده‌ها- Scrumمتدولوژي میشوند ‌ به سه دسته اصلی تقسيمScrum فرآوردههای ‌ 43 Product Backlog  Sprint Backlog  Sprint BurnDown Chart   متدولوژيScrum - Product ‏Backlog ‏ شامل يک صف اولويت‌بندی شده است که در آن منديهای‌تکنيکی و حرفه نمايش داده شده‌اند که بايد ‌ ‌ وظيفه توسعه داده شوند ‏ برای هر مورد مشخص شده در اين فرآورده ،خواصی مانند وضعيت ،اولويت و تخمين کاری وجود دارد 44 متدولوژيScrum - Sprint ‏Backlog ‏ مجموعهای از موارد حرفه و فني که برای تکرار جاری ‌ ( )Current Iterationزمانبندی شده‌اند در اين فرآورده میشوند نمايش داده ‌ ‏ ‏ نيازها در اين فرآورده به وظايف تبديل می شوند برای هر وظيفه يک شرح کوتاه وجود دارد و مشخص می‌شود که چه کسی مسئول انجام آن است و همچنين وضعيت و تعداد ساعات باقيمانده تا تکميل شدن هر وظيفه در اين فرآروده میشود مشخص ‌ 45 متدولوژيScrum - Sprint BurnDown ‏Chart ‏ ساعات باقيمانده برای تکميل شدن همه وظايف مربوط به يک Sprintرا در قالب يک گراف بصورت برجسته نمايش می‌دهد 46  نقش‌ها- Scrumمتدولوژي  Scrum Master  Product owner  Scrum team  Manager 47 متدولوژي‌هاي خانواده Crystal ‏ متدولوژيهای متفاوت است که مناسبترين ‌ شامل مجموعه‌ای از آنها برای هر پروژه منحصر به فرد انتخاب می‌شود ‏ متدولوژيها را برای شرايط مختلف ‌ دارای اصولی است که موجود در پروژه‌ها سفارشی می‌کند ‏ روش Crystalپيشنهاد می‌کند که يک متدولوژی مناسب بحرانیبودن پروژه انتخاب شود ‌ براساس اندازه و ميزان 48 متدولوژي‌هاي خانواده ( Crystalادامه) ‏ هر عضو از خانواده Crystalبا يک رنگ مشخص می‌شود که میدهد .رنگ تاريکتر نشان ميزان سنگينی متدولوژی را نشان ‌ سنگينتر است ‌ دهنده متدولوژی ‏C: Comfort ‏D: Discretionary ‏Money ‏E: Essential ‏Money ‏L: Life 49 متدولوژي‌هاي خانواده Crystal ‏ (ادامه) تمامی پروژه‌ها از توسعه افزايشی با بازه زمانی حداکثر 4ماه میکنند استفاده ‌ ‏ تأکيد روی ارتباطات و همکاری بين افراد درگير در پروژه است ‏ نمیکند هيچ فعاليت يا ابزاری را برای توسعه محدود ‌ ‏ میتوان از فعاليت‌های XPو Scrumبا هم در اين روش استفاده مثلاً ‌ کرد 50 مزايای روش‌های سريع االنتقال ‏ تأکيد روی شرکت‌دادن مشتری در پروژه‌ها است که در پروژههای کاربردی بسيار مفيد است ‌ ‏ تأکيد روی کارگروهی و ارتباط متقابل که در باال بردن راندمان کاری نقش مهمی دارد ‏ همه افراد درگير در پروژه در قبال کيفيت محصول مسئولند ‏ سنجش مستمر کارهای انجام شده از مزايای بسيار مفيد اين روشها است ‌ 51 مزايای روش‌های سريع االنتقال ‏ (ادامه) روشهای مدرن توسعه نرم‌افزار سازگار ‌ توسعه افزايشی که با است ‏ طراحی ساده و روشن برای فرآيند توسعه ‏ بازبينیهای مستمر که به باال رفتن کيفيت کار برنامه‌نويسان ‌ میکند کمک ‌ 52 معايب روش‌های سريع االنتقال ‏ روشها ،اگر کد بيش از ‌ بدليل کمبود فعاليت‌های طراحی در اين چند هزار خط باشد ممکن است فرآيند توسعه با موانع خطرناکی برخورد کند ‏ روشها آنها را به ‌ کمبود مستندات مربوط به طراحی در اين میکند و قابليت‌های استفاده مجدد را پروژههای کوچک محدود ‌ ‌ میکند در آنها محدود ‌ ‏ کمبود فرآيندهای بازبينی ساخت‌يافته 53 معايب روش‌های سريع االنتقال ‏ (ادامه) بازبينیهای غير ‌ کمبود فرآيند طراحی منظم و استفاده از ساخت‌يافته باعث اتالف زمان و هزينه می‌شود ‏ روشها هيچ نوع طرح استانداردی ‌ کمبود طرح کيفيت .در اين برای ارزيابی کيفيت وجود ندارد ‏ روشها ‌ کمبود راهنماهای آموزشی برای استفاده از اين 54