Payamvdn/NorthPersian_fa_wiki huggingface dataset:
متفقین در جنگ جهانی دوم بمباران های استراتژیک بسیاری انجام دادند. هامبورگ به عنوان بندری بزرگ و مرکزی صنعتی و محل پالایش نفت در سرتاسر جنگ هدف حمله قرار گرفت. پایگاه قدیمی ترین کارخانه دینامیت جهان، ساخته آلفرد نوبل هم در نزدیکی هامبورگ بود. نیروی هوایی سلطنتی بریتانیا و آمریکا در ژوئیه ۱۹۴۳ در یکی از بزرگ ترین طوفان های آتشین خود در جنگ جهانی دوم حدود ۳۷٬۰۰۰ تن را کشته و ۱۸۰٬۰۰۰ تن را زخمی کرده و ۶۰ درصد از خانه های شهر را نابود کردند.
بدعت دینی به هر نوع باور یا نظریه ای گفته می شود که در مغایرت با برخی باورها یا آداب و رسوم بنیادی یک دین باشد. بدعت با ارتداد تفاوت دارد که ترک صریح دین یا باور است و همچنین با کفرگویی که توهین به مقدسات است تفاوت دارد. بدعت دینی معمولاً به معنی تخطی از قوانین مذهبی یا سنتی و قانون های آن است، هر چند برخی افراط گرایان سیاسی از آن برای خطاب کردن مخالفان خود استفاده می کنند. این واژه حامل بار معنایی رفتار یا عقیده هایی است که به احتمال زیاد اخلاقیات پذیرفته شده را تضعیف کرده یا باعث شر ملموس، لعنت یا مجازات های دیگر می شوند. در برخی ادیان، فرد بدعت گذار حامی نمادهای شر مثل شیطان و هرج و مرج در نظر گرفته می شود. در فرهنگ های تاریخی مسیحی و یهودی و برخی دیگر فرهنگ ها ایده هایی که بدعت تلقی می شدند قانوناً قابل مجازات بودند.
سرمایه داری ستیزی، ضد-سرمایه داری، کاپیتالیسم ستیزی یا آنتی کاپیتالیسم (یا ضد-سرمایه گرایی)، نوعی جنبش و ایدئولوژی سیاسی است که دربرگیرندهٔ انواع متنوعی از نگرش ها و ایده های مخالف با تفکر سرمایه داری می باشد. از این جهت، ضد-سرمایه داران کسانی اند که آرزومند جایگزینی سرمایه داری با نوع دیگری از نظام اقتصادی، اغلب نوعی سوسیالیسم، می باشند. سوسیالیسم. سوسیالیسم، از مالکیت عمومی یا مستقیم کارگران دفاع کرده و طرفدار مدیریت ابزار تولید و تخصیص منابع بوده، و همچنین جامعه ای را خواهانند که در آن برای تمام افراد، دسترسی برابر به منابع، با روش مساوات خواهی وجود داشته باشد. سوسیالیست ها می گویند که تجمع سرمایه از طریق اثرات جانبی موجب اتلاف منابع شده که نیازمند اقدامات تنظیم کننده و اصلاح گر هزینه برداری می باشد. همچنین اشاره می کنند که این فرایند موجب ایجاد صنایع و اعمال زائدی است که وجودشان تنها جهت ایجاد تقاضای کافی برای محصولاتی است که فروششان سودآور باشند (همچون تبلیغات پر-فشار)؛ ازین رو به جای ارضاء نیازهای اقتصادی، صرفاً حجم تولیدات بالا می رود. سنت گرایی. طیف های سنت گرا و محافظه کار جامعه ممکن است نسبت به کاپی
تالیسم لیبرال نظر مساعدی نداشته باشند. خصوصاً در قاره اروپا بسیاری از افراد محافظه کار و سنت گرا از تأثیرات سرمایه داری بر فرهنگ و آداب و سنن ناراضی می باشند. اکوفمینیسم. اکوفمینیست ها در مورد رابطه سرمایه داری و جهان طبیعت انتقاد دارند و لذا با تغییر و تحول در طبیعت برای خدمت به اهداف و منافع انسان مخالف هستند. آن ها ذات سرمایه داری را باعث کاهش رابطه دوستانه انسان ها با یکدیگر و با جهان طبیعت می دانند. آن ها سرمایه داری را به عنوان یک ساخت و ساز پدرسالارانه می دانند که بر اساس استثمار زنان، استثمار طبیعت و استعمار مردم دیگر شکل گرفته است. فاشیسم. فاشیسم در مورد سرمایه داری مواضع مختلط دارد. در عین حال که از حقوق مالکیت خصوصی و حکومت محوری و کورپوراتیسم حمایت می کند، ولی موضعی خصمانه نسبت به مفاهیم لسه فر سرمایه داری ، سیستم بازار آزاد، تجارت آزاد، فردگرایی اقتصادی، فرهنگ مصرف گرایی، و فرهنگ بورژوایی دارد. فاشیسم نیز همانند مارکسیسم، معتقد است که تضاد طبقاتی، حفظ یک ویژگی ذاتی در جوامع سرمایه داری است. به همین دلیل به دنبال آن است که فاصله طبقاتی را توسط دولت جبران کند. مذهب. کلیسای کاتولیک، ربا را منع نموده
است؛ ولی با شورش رفرم های پروتستانی علیه تعصبات پاپی و با فرارسیدن عصر روشنگری و رد آموزش های اخلاقی پاپی، «مسیحیت اروپا» برخی از انواع شارژ و بهره را پذیرفت. این امر موجب برخی تغییرات اجتماعی گردید که اجازه می داد فئودالیسم با کاپیتالیسم یا سایر روش های حکومت جایگزین شود. مسیحیت منبع انتقادات بسیاری از سرمایه داری به خصوص آن جنبه های مادی آن بوده است. جنبش های ضد جهانی سازی. جنبش ضد جهانی سازی جنبشی فعال در سراسر جهان است. این جنبش منتقد جهانی شدن سرمایه داری می باشد. فعالان ضد جهانی سازی از ماهیت غیر دموکراتیک نهادینه شدن سرمایه داری در جهان انتقاد دارند. آن ها مخالف با ترویج جهانی نئولیبرالیسم هستند و معتقدند که نهادهای بین المللی مانند صندوق بین المللی پول (IMF) و بانک جهانی که از مروجین جهانی نئولیبرالیسم هستند به اثرات غالباً ویرانگر سرمایه داری جهانی در شرایط محلی کشورها بی توجه هستند. جلسات این نهادها اغلب با اعتراضهای شدید فعالان جنبش ضد جهانی سازی مواجه شده اند.
علی صمدی احدی (زاده ۱۳۵۱ در تبریز، ایران) فیلم ساز و کارگردان ایرانی-آلمانی و برنده چندین جایزه سینمایی از جمله جایزه فیلم سال آلمان است. از مهم ترین فیلم های او می توان به "سالامی علیکم" و "بچه های گم شده" اشاره کرد.همچنین فیلم انمیشین (( 2021 ، "بچه های گم شده" (۲۰۰۵) فیلمی مستند دربارهٔ زندگی سخت کودکان سرباز شمال اوگاندا است و جایزه فیلم سال آلمان را دریافت کرده است. "سالامی علیکم" از فیلم های پرفروش در آلمان، فیلمی کمدی است که به زبان طنز به ایرانیان مهاجر آلمان و روابط آلمانیان و مهاجران می پردازد. فیلم "موج سبز" او ترکیبی از پویانمایی و فیلم مستند بی واسطه است. زندگی. علی صمدی احدی در سال ۱۳۵۱ در تبریز زاده شده و تا ۱۳ سالگی در ایران زندگی می کرد. در زمان جنگ ایران و عراق هنگامی که ۱۳ ساله بود به تنهایی از ایران گریخت و به آلمان مهاجرت کرد. او در آلمان تحصیل را ادمه داد در رشته های جامعه شناسی و سینما و تلویزیون (ارتباطات بصری) تحصیل کرد. سپس به عنوان فیلمساز و فیلمنامه نویس مستقل کار خود را آغاز کرد که تا امروز ادامه دارد. علی صمدی تا سال ۲۰۰۴ که "بچه های گم شده" را ساخت همواره فیلم کوتاه و مستند می س
اخت. مستند "بچه های گم شده" دربارهٔ زندگی سخت کودکان سرباز شمال اوگاندا، مستند تلخ بسیار موفقی بود و جایزه هایی مانند جایزه فیلم سال آلمان را دریافت کرد. او پس از وقفه ای سه ساله فیلم کمدی "سالامی علیکم" را دربارهٔ مهاجران ایرانی در آلمان ساخت که به گفتهٔ خودش برگرفته از تجربیات و زندگی شخصی اش در آلمان بود. صمدی احدی می گوید «تم فیلم بیشتر در مورد جستجوی وطن است. یک وطن جدید که در مورد خیلی از ایرانی های مقیم خارج از کشور، صادق است. دوره و زمانه گاهی آدم را مجبور می کند قبول کند جایی که زندگی می کند، وطن او شده است.» پرداخت شخصیت و فضا سازی آلمان شرقی نیز از جنبه های بسیار موفق این فیلم است.
حالت به روی افتاده و پیشانی بر زمین نهاده را اصطلاحاً دَمَر یا دَمَرو می گویند. اصل این واژه «دیم به رو» است که دیم در فارسی به معنای صورت است. در جراحی. قرارگیری دمرو متداول ترین وضعیت در اعمال جراحی ستون مهره و نخاع می باشد.نخست بیمار در وضعیت طاق باز بیهوش گردیده و سپس توسط تیم جراحی به حالت صاف بر روی شکم برگردانده می شود. نقاط تحت فشار. گونه، قسمت جلویی دنده ها، خارایلیاک پیشین، کشکک و انگشتان پا که می توان با قرار دادن یک بالش در زیر پا از انگشتان محافظت نمود. در چه عمل هایی به کار می رود؟. لامینکتومی، رگ های واریسی، عمل های جراحی پشت قفسهٔ سینه و سینوس پایلونیدال.
توسعه چابک نرم افزار یا توسعه نرم افزاری چابک گروهی از متدهای توسعهٔ نرم افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه حل ها از طریق خودسازمان دهی و همکاری بین تیم های مختلف کاری، انجام می شوند. این روش برنامه ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته بندیِ تکرارشونده را ارتقا می بخشد و پاسخ های سریع و انعطاف پذیر برای انجام تغییرات را تقویت می کند. در واقع چابک سازی یک چارچوب مفهومی است که پیش بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می بخشد. بیانیهٔ چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد. تاریخچه. سوابق. متدهای توسعهٔ افزایشی نرم افزار به سال ۱۹۵۷ برمی گردند. در سال ۱۹۷۴، E.A. Edmonds در مقاله ای فرایند توسعهٔ تطبیقی نرم افزار را معرفی کرد. هم زمان و به طور مستقل متدهای مشابه توسعه یافت و توسط مرکز توسعهٔ سیستم های شرکت تلفن نیویورک زیر نظر Dan Gielan گسترش یافت. اوایل دههٔ ۱۹۷۰، Tom Gilb شروع به انتشار مفاهیمی در مورد کنترل تحولی پروژه (EVO) کرد، که به مهندسی رقابتی توسعه یافت. در طول نیمه تا انتهای دههٔ 1970 Gielan به طور گسترده در ایالات متحده در مورد این متدولوژی، تجارب و فواید
آن سخنرانی هایی ارائه داد. متدهای توسعهٔ به اصطلاح چالاک و چابک نرم افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته بندی شده، میکرو مدیریتی و آبشاری توصیف شده است. استدلال کنندگان متدهای چالاک و چابک ادعا می کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم افزار در اوایل تاریخ هستند. پیاده سازی های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum (1995)، Crystal Clear، برنامه نویسیExtreme (1996)، توسعهٔ تطبیقی نرم افزار، توسعهٔ ویژگی محور و متد توسعهٔ سیستم های دینامیک (DSDM، ۱۹۹۵) می شود. بعد از انتشار بیانیهٔ چابک در سال ۲۰۰۱، اکنون این ها به طور معمول به متدولوژی های چابک برمی گردند. بیانیه ی چابک. در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه دهندهٔ نرم افزار، در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعهٔ چالاک گفتگو کنند. آن ها برای توصیف رویکردی که اکنون به عنوان «توسعهٔ چابک نرم افزار» شناخته می شود، بیانیه ای برای توسعهٔ چابک نرم افزار منتشر کردند. بعضی از نویسندگان این بیانیه، اتحاد Agile را ای
جاد کردند؛ یک سازمان غیرانتفاعی که توسعهٔ نرم افزار را بر اساس اصول این بیانیه ترویج می دهد. بیانیهٔ چابک به شرح زیر است: ما با توسعه نرم افزار و کمک به دیگران در انجام آن، در حال کشف راه های بهتری برای توسعهٔ نرم افزار هستیم. از این کار به ارزش های زیر می رسیم: ۱- افراد و تعاملات بالاتر از فرایندها و ابزارها ۲- نرم افزار کارکننده بالاتر از مستندات جامع ۳- مشارکت مشتری بالاتر از قرارداد کاری ۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم. معنی موارد سمت راست این بیانیه در مفهوم توسعهٔ چابک نرم افزار در زیر توضیح داده شده است: افراد و تعاملات بالاتر از فرایندها و ابزارها. افراد مهم ترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست می گردد و بر عکس افراد قوی تحت فرایند وضعیت ناکارآمد خواهند بود. یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران و تعامل درست و سازنده با سایر اعضای تیم خیلی
مهم تر از این است که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفق تر هستند از تعدادی برنامه نویس عالی که قدرت تعامل مناسب با یکدیگر را ندارند. در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گران قیمت از برنامه رایگان کدباز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آن ها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید. نرم افزار کارکننده بالاتر از مستندات جامع. نرم افزار بدون مستندات فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم افزاری نیست. تیم باید مستندات قابل فهم برای مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید. با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می گیرد تا آن را با کد برنامه به روز نمایید. اگر آن ها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می شوند. بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه
داشته باشید و آن را به روز نمایید. البته آن ها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نمایند. اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آن ها است. ما دانش خود را با نشستن در کنار آن ها و کمک کردن به آن ها انتقال می دهیم. ما آن ها را بخشی از تیم می کنیم و با تعامل نزدیک و رو در رو به آن ها آموزش می دهیم. مشارکت مشتری بالاتر از قرارداد کاری. نرم افزار نمی تواند مثل یک جنس سفارش داده شود. شما نمی توانید یک توصیف از نرم افزاری که می خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است. این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آن ها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آن ها را برآورده می کند بسازند. اما این تعامل به کیفیت پایین نرم افزار و در نهایت شکست آن می انجامد. پروژه های موفق بر ا
ساس دریافت بازخورد مشتری در بازه های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می کند. قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به طور تنگاتنگ با تیم توسعه تعامل داشته باشد. پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه. توانایی پاسخ به تغییرات اغلب تعیین کنندهٔ موفقیت یا شکست یک پروژهٔ نرم افزاری است. وقتی که طرحی را می ریزیم باید مطمئن شویم که به اندازهٔ کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح تجاری و تکنولوژی را دارد. مسیر یک پروژهٔ نرم افزاری نمی تواند برای بازه زمانی طولانی برنامه ریزی شود. اولاً احتمالاً محیط تغییر می کند و باعث تغییر در نیازمندی ها می شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی های خود را تغییر می دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است. یک
استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفتهٔ بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد. اصول چابک. بر اساس نظرات Kent Beck، بیانیهٔ چابک، بر ۱۲ اصل استوار است: در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول مدیریت پروژه نوشتند، که مدیریت پروژه های نرم افزاری را بر اساس متدهای توسعهٔ نرم افزار پیش ببرد.. مشخصات. متدهای توسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخهٔ حیات پروژه را ترفیع می دهند. متدهای چابک وظایف را به گام های کوچک با کمترین میزان برنامه ریزی می شکنند که به طور مستقیم با برنامه ریزی های طولانی مدت درگیر نیستند. تکرارها فریم های (بسته های زمانی) کوتاه مدتی هستند که معمولاً بین یک تا چهار هفته طول می کشند. هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت ها است: تحلیل نیازمندی ها، طراحی، کدنویسی، واحد تست، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذی نفعان نشان داده می شود. این، ریسک کلی را به حداقل رسانده و اجازه می دهد پروژه خیلی
سریع با تغییرات منطبق شود. ممکن است یک تکرار قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار در دسترس (با حداقل شکاف) در پایان هر تکرار است. شاید تکرارهای چندگانه نیاز به انتشار یک محصول یا ویژگی های جدید داشته باشند. ترکیب تیم در یک پروژهٔ چابک معمولاً عملکردی متقابل و خودسازمان دهی است، بدون توجه به هرگونه سلسله مراتب شرکتی یا نقش های شرکتی اعضای تیم. اعضای تیم به طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه می دهد، بر عهده می گیرند. آن ها به صورت جداگانه تصمیم می گیرند که چگونه با نیازمندی های یک تکرار مواجه شوند. متدهای چابک، وقتی تیم ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته شده تأکید دارد. بیشتر تیم های چابک در یک دفتر تک واحدی (به نام bullpen) کار می کنند، که چنین ارتباطاتی را تسهیل می کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه های بزرگ توسعه می توانند توسط تیم های کاری چندگانه در راستای یک هدف رایج یا در بخش های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت های تمام ت
یم ها داشته باشد. وقتی تیمی در مکان های مختلفی کار می کند، افراد ارتباط روزانه شان را از طریق ویدئو کنفرانس، صدا، ایمیل و... حفظ می کنند. مهم نیست چه دیسیپلین های توسعه ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی نفعان به نمایندگی انتخاب می شود و یک تعهد فردی ایجاد می کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه دهندگان باشد. در انتهای هر تکرار، ذی نفعان و نمایندهٔ مشتریان پیشرفت را بررسی می کنند، اولویت ها را با دید بهینه سازی بازگشت سرمایه (ROI) مجدداً می سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می کنند. بیشتر پیاده سازی های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می گیرند. این به طور خاص شامل نمایندهٔ مشتری و هر کدام از ذی نفعان علاقه مند به عنوان ناظر می شود. در یک جلسهٔ مختصر، هر کدام از اعضای تیم گزارش می دهند که در روز گذشته چه کرده اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست های اسکرام
هر روز در یک زمان و مکان ثابت برگزار می شوند و نباید بیش از ۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.» توسعهٔ چابک بر کار نرم افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می شود. متد چابک ذی نفعان را به اولویت بندی «خواسته ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب وکار مشاهده شده در ابتدای تکرار (که با عنوان ارزش محور شناخته می شود) ترغیب می کند. ابزارها و تکنیک های خاص، مانند یکپارچه سازی مستمر، تست اتوماتیک یا xUnit، برنامه نویسی دوجزئی، توسعهٔ آزمون محور، الگوهای طراحی، طراحی دامنه محور، code refactoring و دیگر تکنیک ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می روند. توسعهٔ کمی چابک (LAD) چاشنی متدولوژی چابک است که تکنیک های دست چین را (از طیف وسیع تری از پروژه های چابک) برای شرکت های مناسب مختلف، تیم ها، موقعیت ها و محیط های توسعه به کار می بندد. یکی دیگر از جنبه های کلیدی LAD متمایل به کاربرمحور بودن است، در درجهٔ اول بر تجارب کاربر و واسط های نرم افزاری قابل استفاده تمرکز
می کند و برای تحویل آن ها متدولوژی های چابک را به کار می بندد. بیشتر پیاده سازی های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است. در توسعهٔ چابک نرم افزار، یک رادیاتور اطلاعات، صفحه نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه نمایش خلاصه ای از آخرین وضعیت محصول (های) نرم افزاری را نمایش می دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعهٔ چابک نرم افزار» در سال ۲۰۰۲ توصیف شد. ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه شان به کار رود. مقایسه با متدهای دیگر. متدهایی در زنجیرهٔ بین انطباقی تا پیشگویانه وجود دارند. متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر می کند، یک تیم انطباقی نیز تغییر می کند. یک تیم انطباقی به سختی توضیح می دهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آ
ن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی تواند وظایفی را که اعضا در هفتهٔ آینده خواهد داشت گزارش دهد، تنها می تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می شود، یک تیم انطباقی ممکن است فقط بتواند بیانیهٔ مأموریت (برای آن انتشار) یا بیانیهٔ ارزش موردانتظار در مقابل هزینه را گزارش دهد. در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه ریزی آینده به صورت جزئی و برای ریسک های شناخته شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه ریزی شده است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیم های پیشگویانه اغلب یک هیئت کنترل تغییر ایجاد می کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می شود. متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می کوشد تا نبود خطاها را با درجه ای ا
ز جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال های متضادی برای کدهایی که نمی توان ثابت کرد، فراهم می کنند. تیم های چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند. متدهای چابک که از دههٔ ۹۰–۱۹۸۰ توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با «توسعهٔ سریع اپلیکیشن ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری محور و طراحی محور (مانند نمونه سازی سریع تجسم محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعهٔ چابک نرم افزار تشویق می کنند. در سال ۲۰۰۸ مؤسسهٔ مهندسی نرم افزار (SEI) گزارش فنی «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می توانند وجود داشته باشند، منتشر کرد. CMMI ورژن ۱٫۳ شامل تیپ هایی برای پیاده سازی چابک و CMMI است. یکی از تفاوت های بین چابک و آبشاری، این است که تست نرم افزار در نقاط مختلفی در چرخهٔ عمر توسعهٔ نرم افزار انجام می شود. در مدل آبشاری، یک فاز تست به صورت جداگانه بعد از پیاده سازی وجود دارد. در چابک XP، به طور هم زمان با پیاده سازی انجام می شود. به ط
ور کلی اگر بیشتر ناشناخته ها شناخته شوند (مانند نیازمندی های خوبی که تا آن زمان تحلیل شده اند)، رویکرد پیشگویانه ممکن است مناسب تر باشد. اما اگر ناشناخته های شناخته نشدهٔ زیادی وجود داشته باشد (مانند نیازمندی هایی که ضعیف شناخته شده اند و هنوز بهبود نیافته اند)، رویکرد چابک اجازهٔ بلوغ تدریجی و پیاده سازی را می دهد. متدهای چابک. متدهای معروف توسعهٔ چابک نرم افزار عبارتند از: سازمان دهی متد. در، اصطلاحات متفاوتی به مفهوم متد انطباقی برمی گردد، شامل «سازمان دهی متد»، «تطابق قطعات متد» و «مهندسی موقعیتی متد». مناسب سازی متد به صورت زیر تعریف می شود: فرایند یا قابلیتی که در آن عوامل انسانی یک رویکرد توسعهٔ سیستم را برای موقعیت پروژه ای خاص از طریق تغییرات پاسخگو در، و اثرات متقابل دینامیک بین زمینه ها، مفاهیم و قطعات متد تعریف می کنند. به طور بالقوه، تقریباً تمام متدهای چابک برای سازمان دهی متد مناسب هستند. حتی متد DSDM نیز با این هدف به کار گرفته شده و با موفقیت در یک زمینهٔ CMM سازمان دهی می شود. اقتضای وضعیت، به عنوان یک مشخصهٔ متمایز بین متدهای چابک و متدهای توسعهٔ سنتی نرم افزار مطرح است، دومی نسبتاً جدی تر
و تجویزی است. پیاده سازی کاربردی این است که متدهای چابک به تیم های پروژه اجازهٔ تطبیق روش های کاری را با نیازهای پروژه های منحصربه فرد بدهند. روش ها فعالیت ها و محصولات به هم پیوسته ای هستند که بخشی از یک چارچوب متد را تشکیل می دهند. در یک سطح خیلی بالاتر، فلسفهٔ پشت متد، شامل تعدادی اصول است که می توانند منطبق باشند (Aydin، 2004). برنامه نویسی Extreme (XP) نیاز به انطباق متد را شفاف می کند. یکی از ایده های بنیادین XP این است که هیچ فرایندی برای تمام پروژه ها مناسب نیست، اما ترجیحاً روش ها باید برای هر پروژهٔ منحصربه فرد سازمان دهی [مناسب سازی] شوند. انطباق جزئی روش های XP، که توسط Beck طرح شد، در موارد مختلفی گزارش شده است. یک روش سازمان دهی پیشنهاد می کند که یک نقشهٔ راه و راهنماهای مناسب برای انطباق با تمام روش ها ارائه می دهد. روش RDP برای سفارشی سازی XP طراحی شده است. این روش، برای اولین بار در کارگاه APSO در کنفرانس ICSE 2008، به عنوان یک مقالهٔ تحقیقاتی طولانی طرح شد، و اکنون نیز تنها متد طراحی شده و قابل اجرا برای سفارشی سازی XP است. اگرچه این روش به طور خاص راه حلی برای XP است، اما قابلیت توسعه برای
سایر متدولوژی ها را دارد. در نگاه اول، این روش در گروه متدهای استاتیک انطباق به نظر می رسد، اما آزمایش ها با روش RDP می گوید این روش می تواند مانند یک متد دینامیک انطباق عمل کند. تفاوت ظریفی بین متدهای استاتیک انطباق و متدهای دینامیک انطباق وجود دارد. فرض کلیدی در مورد متد استاتیک انطباق این است که زمینهٔ پروژه در ابتدای یک پروژه داده می شود و در طول اجرای پروژه نیز ثابت می ماند. نتیجه یک تعریف استاتیک از زمینهٔ پروژه است. با دادن چنین تعریفی و با استفاده از مسیر نقشه ها می توان تعیین کرد کدام قسمت متد ساخت یافته، بر اساس مجموعه ای از معیارهای از پیش تعیین شده، باید برای آن پروژهٔ خاص به کار رود. در مقابل، متد دینامیک انطباق، فرض می کند پروژه در یک زمینهٔ نوظهور واقع شده است. یک زمینهٔ نوظهور به این موضوع اشاره می کند که یک پروژه با فاکتورهای نوظهوری سر و کار خواهد داشت که بر شرایط مربوطه اثر می گذارند، اما قابل پیش بینی نیستند. همچنین به این معناست که زمینهٔ پروژه ثابت نیست و در طول اجرا تغییر می کند. در چنین موردی نقشه های مسیر تجویزی مناسب نیستند. مفهوم کاربردی متد دینامیک انطباق این است که مدیران پروژه اغ
لب ناچارند در طول اجرای یک پروژه، قسمت های ساخت یافته را تغییر دهند یا حتی قسمت های جدیدی ابداع کنند (Aydin و همکاران، 2005). چرخهٔ عمر توسعهٔ نرم افزار. متدهای چابک بر جنبه های متفاوتی از چرخهٔ عمر توسعهٔ نرم افزار تمرکز دارند. بعضی از آن ها بر روش ها (برنامه نویسی extreme، برنامه نویسی فعال مدل سازی چابک) تمرکز دارند، در حالی که بعضی دیگر بر مدیریت پروژه های نرم افزاری تأکید دارند (مانند رویکرد Scrum ). هنوز، رویکردهایی وجود دارند که تمام چرخهٔ عمر توسعه را پوشش می دهند (متدهای توسعهٔ سیستم دینامیک (DSDM) و Rational Unified Process (RUP))، در حالی که بیشتر آن ها از فاز تعیین نیازمندی ها مناسب هستند (مثلاً ویژگی محور در توسعه یا FDD). بنابراین، یک تفاوت آشکار بین متدهای گوناگون توسعهٔ چابک نرم افزار در این مورد است. اگرچه DSDM و RUP نیازی به رویکردهای مکمل برای پشتیبانی از توسعهٔ نرم افزار ندارند، بقیهٔ آن ها با درجات متفاوت این نیاز را دارند. DSDM می تواند توسط هر کسی به کار رود (علیرغم اینکه فقط اعضای DSDM می توانند محصولات یا خدمات DSDM را عرضه کنند). RUP یک محیط توسعه تجاری فروشی است (Abrahamsson، Salo،