بهترین روش و فرآیند توسعه نرم افزار چیست؟
اگر در روش های توسعه نرم افزار تازه وارد هستید ، می توانید به عنوان یک دستور العمل برای پخت و پز به آنها فکر کنید. یک دستور العمل پخت و پز معمولاً لیستی از مواد اولیه با وزن / حجم آنها را ارائه می دهد ، لیست دستورپخت را در اختیار شما قرار می دهد و در نهایت آن را برای خوردن افراد سرو می کنید. از آنجا که این دستورالعمل نوشته شده است ، افراد دیگر می توانند آن را دنبال کنند.
روش توسعه نرم افزار فرآیندی برای نحوه ساختن نرم افزار است. معمولاً چیزی فراتر از یک فرایند است و فلسفه های اساسی پشت سر آن وجود دارد. روشهای بسیار متنوعی وجود دارد ،وظیفه شما این است که بهترین روش را برای خود پیدا کنید . ایده های بسیار جالب وجود دارد که ارزش آزمایش کردن را دارند.
به عنوان مثال ، چند روش شناخته شده کمتر ، Mob Programming و Anarchy Programming هستند. برنامه نویسی Mob توسط وودی زویل و تیمش با این ایده شروع شد که همه اعضای تیم در یک چیز ، در یک زمان ، در یک فضا و در یک کامپیوتر با هم کار کنند. این ممکن است کمی عجیب به نظر برسد ، اما اگر بپرسید که چرا این موفقیت حاصل شده است ،میتواند چیز های جالبی یاد بگیرید.
برنامه Anarchy Programming نمونه دیگری است و توسط فرد جورج با ایده حذف ساختارهای معمول مدیریت آغاز شد تا تیم های خود سازمان یافته تر با مسئولیت پذیری بیشتری تشکیل شوند.
هر دوی این روش ها بسیار جالب هستند و بسیار خوب است که می بینید افرادی به فکر بهبود روش ساخت نرم افزار هستند. من شخصاً معتقدم که داشتن ذهن آزاد نسبت به ایده های جدید و احترام و گذاشتن احترامی که شایسته آن هستند بسیار مهم است. مانند همه روش ها ، آنها توسط یک فلسفه اساسی متصل می شوند که مربوط به وضعیتی ست که مردم در آن برهه از زمان با آن روبرو هستند.
در این مقاله ، ما می خواهیم برخی از روش های شناخته شده را بررسی کنیم و راهی برای دسته بندی آنها ارائه می دهیم تا به درک شما کمک کند. به طور خلاصه ، ما برخی از توصیه ها را در مورد بهبود روش کار شما ارائه داده ایم.
دسته بندی های مختلف روش های توسعه نرم افزار کدامند؟
در جدول زیر ، سه دسته بر اساس توانایی تحویل آنها ارائه شده است. به نظر من این یک روش خوب برای فکر کردن در مورد روشهای مختلف موجود است. آبشار یک فرآیند خطی است. رویکردهای تکراری از چرخه یا سرعت استفاده می کنند و مداوم عبارت است از قرار داشتن در یک جریان ثابت یا یک حالت زایمان مداوم و بدون تکرار یا دو سرعت.
دسته بندی |
ریشه |
خلاصه |
waterfall |
ساخت و ساز |
از اوایل سال 1970 ، رویکردهای آبشار مورد انتقاد قرار گرفتند زیرا در زمینه ساخت نرم افزار کار نمی کرد. احتمالاً این رویکرد براساس دستاوردهای تاریخی بشر در ساخت و سازچیزی سخت (فیزیکی) که ساخته شده ، اتخاذ شده است. |
تکراری (Iterative) |
|
در سال 2001 ،Agile Manifesto توسط نمایندگان Extreme Programming ، SCRUM ، DSDM ، توسعه نرم افزار تطبیقی ، Crystal ، Feature-Driven Development ، برنامه نویسی عملی و سایر افرادی که نیاز به جایگزینی برای مستندات و فرایندهای توسعه نرم افزارهای سنگین را دوست داشتند ، توافق شد. . |
مداوم (Continuous) |
صنعت تولید کم سود |
در سال 1938 ، كیچیرو تویودا (بنیانگذار شركت موتور تویوتا) این فلسفه را مطرح كرد كه وقتی ماشین آلات ، تاسیسات و افراد بدون تولید هرگونه زباله با هم كار می كنند ، شرایط ایده آل برای ساختن چیزها ایجاد می شود. توسعه نرم افزار کم سود (LSD) نوادگان تویودا به شدت تحت تأثیر این هستند. |
توسعه نرم افزار waterfall(آبشار)
آبشار یک رویکرد خطی برای توسعه نرم افزار است که نیاز به تلاش دارد تا پروژه را کنترل کند. نمونه ای از روش آبشار ، مدل COCOMO است که در سالهای اولیه مهندسی نرم افزار محبوب بود. در آن دوره میزان قابل توجهی از شکست پروژه های نرم افزاری وجود داشت. در این چند وقت اخیر اوضاع بهتر شده است.
چیزی که مردم در مورد رویکرد آبشار به سمت آن جلب شده بودند ، یقین ظاهری آنها بود. مردم می توانند با زمان مشخصی از زمان طولانی شدن پروژه و برآوردی با دامنه ثابت آنچه قرار است تحویل داده شود ، تخمین بزنند. داشتن یک زمان مشخص و یک محدوده ثابت به افراد تصویب کننده پروژه ها اطمینان می دهد.
جنبشی از این دوره بوجود آمد و agilemanifesto در اوایل سال 2000 متولد شد
Agile مجموعه ای از ارزشها و اصول در مورد راههای بهتر تولید نرم افزار است و این روش موارد خاصی برای اجرا تجویز نمی کند.
توصیه من این است که از آبشار استفاده نکنید بلکه به دنبال یک روش تکراری یا مداوم باشید.
توسعه نرم افزارIterative (تکراری)
توسعه نرم افزارتکراری از چرخه ها یا سرعتهای سریع استفاده می کند تا با انتشار مداوم زود هنگام ارزش ، به کاربران برسد. طول تکرار می تواند ثابت یا متغیر باشد. استفاده از تکرار معمولاً با Agile مترادف است حتی اگر agilemanifesto استفاده از آنها را موظف نکند. دو مورد از شناخته شده ترین روش های تکراری در زیر پوشش داده می شوند. (Scrum و Extreme Programming XP).
اسکرام در دسته iterative یا تکراری برای متدولوژی های توسعه نرم افزار قرار می گیرد. اسکرام از اسپرینت های با طول ثابت (با جعبه زمان) استفاده می کند و هر دو سرعت هدفی دارد که تیم برای رسیدن به آن تلاش می کند. راهنمایاسکرام می گوید: "چارچوبی که در آن افراد می توانند مشکلات پیچیده انطباقی را برطرف کنند ، در حالی که محصولاتی را با بالاترین ارزش ممکن ارائه می دهند."
اسکرام دارای سه رکن شفافیت ، بازرسی و سازگاری است. همچنین دارای پنج ارزش تعهد ، شجاعت ، تمرکز ، گشودگی و احترام است. سرنوشت این است که استفاده موفقیت آمیز از اسکرام زمانی اتفاق می افتد که تیم در زندگی پنج ارزش تبحر پیدا کند و سه ستون از هر عملی را پشتیبانی کند.
تصویر زیر نحوه کار دو سرعت را نشان می دهد. در ابتدای هر دو سرعت یک جلسه برنامه ریزی برگزار می شود که در آن تیم داستان هایی را از محصول به عقب مانده اضافه می کند. تیم اسکرام پس از آن برای مدت زمان ثابت کار می کند. در پایان اسپرینت ، نرم افزار باید منتشر شود و تیم یک بررسی با سرعت و یک گذشته نگر انجام می دهد.
Extreme Programming (XP)
پیدایش XP از کار کنت بک در پروژه حقوق و دستمزد سیستم جامع جبران کرایسلر (C3) در دهه 90 حاصل می شود. بعداً او با رون جفریس و وارد كونینگام همکاری كرد که هر سه بنیانگذار XP محسوب می شوند. XP از تکرارهای طول ثابت مانند Scrum استفاده می کند.
پنج ارزش XP عبارتند از: ارتباط ، سادگی ، بازخورد ، شجاعت و احترام. سیزده عمل اصلی وجود دارد (گلوله ای که در زیر نشان داده شده است) و جفری آنها را درExtreme Programming (برنامه نویسی افراطی) توضیح می دهد.
- Whole Team(کل تیم)
- Planning Game(بازی برنامه ریزی)
- Small Releases(نسخه های کوچک)
- Customer Tests(تست مشتری)
- Simple Design(طراحی ساده)
- Pair Programming(برنامه نویسی جفت)
- Test-Driven Development(توسعه آزمون محور)
- Design Improvement(بهبود طراحی)
- Continuous Integration(ادغام مداوم)
- Collective Code Ownership*(مالکیت کد جمعی *)
- Coding Standard(استاندارد برنامه نویسی)
- Metaphor(استعاره)
- Sustainable Pace(سرعت پایدار)
به عنوان مثال ، هر مشارکت کننده در این پروژه ، بخشی جدایی ناپذیر از کل تیم است (در بالای دایره یافت می شود). تأکید بر تیم ، مشتری ، برنامه ریزی بسیار دوست داشتنی ست.
XP (مانند Scrum) به عنوان یک روش توسعه نرم افزار Agile در نظر گرفته می شود.
توسعه Continuousنرم افزار(مداوم )
در توسعه مداوم نرم افزار از تکرار یا اسپرینت استفاده نمی شود بلکه مربوط به جریان کار است. این دسته از توسعه نرم افزار با الهام از سیستم تولید تویوتا با هدف دستیابی به حذف کامل تمام زباله ها در پی کارآمدترین روش ها ، الهام گرفته شده است.
سیستم تولید تویوتا (TPS) بر اساس دو مفهوم تاسیس شد: "jidoka" (که می توان آن را به راحتی به عنوان "اتوماسیون با لمس انسان" ترجمه کرد) ، زیرا در صورت بروز مشکل ، تجهیزات بلافاصله متوقف می شوند ، و از تولید محصولات معیوب جلوگیری می کنند ؛ و مفهوم "فقط در زمان" ، که در آن هر فرآیند فقط یک جریان پیوسته را برای فرآیند بعدی تولید می کند.
دو مورد از شناخته شده ترین روش های مداوم در ادامه آورده می شود. Kanban و DevOps.
روشKanban
روش Kanban توسط دیوید اندرسون توسعه یافته و او كتابی را در سال 2010 منتشر كرد. نام این روش كلمه Kanban را شامل می شود كه بخشی از اصول استفاده شده در سیستم تولید تویوتا (TPS) است.
روش Kanban بر تجسم کار در حال انجام (WIP) و به حداکثر رساندن بازده در سیستم تأکید دارد. برای کمک به روند از یک تخته Kanban (به زیر مراجعه کنید) استفاده می شود. 4 رکن اصلی وجود دارد:
- با کاری که اکنون انجام می دهید شروع کنید
- موافقت می کنیم که تغییرات فزاینده و تکاملی را دنبال کنیم
- به روند فعلی ، نقشها و مسئولیتها احترام بگذارید
- اقدامات رهبری را در همه سطوح تشویق کنید
برای از بین بردن زباله ها (به حداکثر رساندن کارایی) از مخفف DOWNTIME برای برجسته کردن جایی که می توان رهبری را به دست آورد استفاده می شود.
- Defects(عیوب)
- Overproduction(تولید بیش از حد)
- Waiting(در انتظار)
- Not using talent(استفاده نکردن از استعداد)
- Transportation(حمل و نقل)
- Inventory excess(بیش از حد موجودی)
- Motion waste(ضایعات حرکت)
- Excess processing(پردازش بیش از حد)
آخرین نکته در مورد روش کانبان بحث در مورد اسکروبان است (من فهمیدم که اینها می توانند با هم مخلوط شوند). Scrumban ترکیبی از Scrum و Kanban است.اسکرامبان از برخی تیم های ناامید کننده در اجرای یک رویکرد خالص اسکرام ناشی می شود. آنها دریافتند که ترکیب صفحه Kanban در فرآیندهای scrum به آنها کمک قابل توجهی می کند.
DevOps
DevOps به نظر می رسد از حدود 2007-2008 آغاز شده است اما اخیراً مورد توجه قرار گرفته است.
DevOps مجموعه عملکردهایی است که توسعه نرم افزار ، آزمایش و عملیات را با هم جمع می کند. با گردآوری این موارد در DevOps ، امکان انتشار سریعتر نرم افزارو از جمله موارد دیگر وجود دارد.
با بالغ شدن تیم ها ، آنها از ادغام مداوم (continuous integration)، به حمل مداوم(continuous delivery) و در نهایت به استقرار مداوم(continuous deployment) می روند. ابزارهای مختلف وجود دارد که می تواند برای کمک به بلوغ تیم های DevOps استفاده شود. از دسته های زیر برای توصیف روش کمک هر ابزار به DevOps استفاده می شود:
- Plan(طرح)
- Code(کد)
- Build(ساختن)
- Test(تست)
- Release(انتشار)
- Deploy(استقرار)
- Operate(عمل کردن)
- Monitor(مانیتور)
خلاصه
حتی بیشتر از اینها متدولوژی های توسعه نرم افزار وجود دارد. بهترین روش توسعه نرم افزار چیست؟
اولاً ، هرگز از آبشار استفاده نکنید..
اگر شما یک شرکت تازه تاسیس یا واحد تجاری جدید هستید، توصیه این است که از روش توسعه نرم افزار تکراری یا مداوم استفاده کنید. اگر تیم شما نسبتاً جدید باشد ، از یک روش تکراری استفاده می کنیم و ایده هایی از Scrum و XP می گیریم. اگر تیم شما نسبتاً باتجربه است ، از یک روش مداوم استفاده می کنیم و با یک هیئت مدیره Kanban با تأکید بر DevOps کار می کنیم.
اگر شما یک سازمان باشید ، بدون شک برخی از روشهای موجود را در اختیار خواهید داشت و در معرفی هر روش خطرات زیادی وجود دارد. معرفی یک روش کامل مانند Scrum ، XP یا هر یک از آنها بسیار دشوار است. آموزش یک تیم در زمینه مهارت های مختلف ممکن است ماه ها طول بکشد و این تلاش در بسیاری از سازمان ها به شکست انجامیده است. در نهایت درگیری بین روش موجود وروش جدید وجود دارد.
حقیقت این است که در نهایت اکثر سازمان ها با یک روش ترکیبی با برخی از توصیفات روبرو می شوند.
توصیه برای اجرای این راه کار چیست ؟. روش کار چیزی است که ما مدتی است در Codebots از آن استفاده می کنیم وبه سازمانهای زیادی آن را معرفی کرده ایم. به طور خلاصه ، یک روش کار به شما این امکان را می دهد که مسیری را برای کارکنان خود مشخص کنید و سپس با استفاده از آزمایش تیم را قادر می سازید تا بهترین ایده ها را از هر کدام از روش های ارائه دهنده, راه حل برخی از چالش هایی که امروز با آن روبرو هستید ، به کار بگیرید.
در این مقاله ، سعی کرده ایم به شما کمک کنیم تا از روش تحویل برای تشخیص روشهای مختلف استفاده کنید. به شخصه ، آن را راهی مناسب برای تمایز بین روش های آبشار ، تکرار شونده و مداوم مانند این می دانیم. همه این متدولوژی های مختلف با هم رشد کرده و یکدیگر را تحت تأثیر قرار داده اند و بعضی اوقات با هم تداخل دارند.
توضیحات خود را بنویسید