stanford-oval/wikipedia huggingface dataset:
توسعه نرم‌افزاری چابک
بیانیه‌ی چابک > نرم‌افزار کارکننده بالاتر از مستندات جامع

نرم‌افزار بدون مستندات فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم برای مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آن‌ها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نمایید. البته آن‌ها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نمایند.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آن‌ها است. ما دانش خود را با نشستن در کنار آن‌ها و کمک کردن به آن‌ها انتقال می‌دهیم. ما آن‌ها را بخشی از تیم می‌کنیم و با تعامل نزدیک و رو در رو به آن‌ها آموزش می‌دهیم.
بیانیه‌ی چابک > مشارکت مشتری بالاتر از قرارداد کاری

نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آن‌ها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آن‌ها را برآورده می‌کند بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به‌طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می‌کند.
قراردادی که مشخص‌کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم‌افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به‌طور تنگاتنگ با تیم توسعه تعامل داشته باشد.
بیانیه‌ی چابک > پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه

توانایی پاسخ به تغییرات اغلب تعیین‌کنندهٔ موفقیت یا شکست یک پروژهٔ نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازهٔ کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح تجاری و تکنولوژی را دارد.
مسیر یک پروژهٔ نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه‌ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندی‌ها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می‌دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه‌ریزی این است که یک برنامه‌ریزی دقیق برای یک هفتهٔ بعد داشته باشیم و یک برنامه‌ریزی کلی برای سه ماه بعد.
بیانیه‌ی چابک > اصول چابک

بر اساس نظرات Kent Beck، بیانیهٔ چابک، بر ۱۲ اصل استوار است:
رضایت مشتری از طریق تحویل زود و مداومِ نرم‌افزار مفید؛
استقبال از تغییر نیازمندی‌ها، حتی در اواخر توسعه؛
تحویل زود به زود نرم‌افزار قابل استفاده (هفتگی به جای ماهانه)؛
نرم‌افزار قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است ؛
توسعهٔ پایدار که قادر به حفظ سرعت ثابت است؛
همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
گفتگوی رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
پروژه‌ها در اطراف افراد باانگیزه، که باید به آن‌ها اعتماد کرد، شکل می‌گیرند؛
توجه مستمر به برتری فنی و طراحی خوب؛
سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
بهترین معماری‌ها، نیازمندی‌ها و طراحی‌ها از تیم‌های خودسازمانده پدیدار می‌شوند ؛
در فواصل منظم تیم بر چگونگی مؤثرتر شدن تامل وتفکر می نماید و سپس رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم‌سو می‌کند.
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول مدیریت پروژه نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعهٔ نرم‌افزار پیش ببرد..
مقایسه با متدهای دیگر

متدهایی در زنجیرهٔ بین انطباقی تا پیشگویانه وجود دارند. متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر می‌کند، یک تیم انطباقی نیز تغییر می‌کند. یک تیم انطباقی به سختی توضیح می‌دهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی‌تواند وظایفی را که اعضا در هفتهٔ آینده خواهد داشت گزارش دهد، تنها می‌تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می‌شود، یک تیم انطباقی ممکن است فقط بتواند بیانیهٔ مأموریت (برای آن انتشار) یا بیانیهٔ ارزش موردانتظار در مقابل هزینه را گزارش دهد.
در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه‌ریزی آینده به صورت جزئی و برای ریسک‌های شناخته‌شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می‌تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه‌ریزی شده‌است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیم‌های پیشگویانه اغلب یک هیئت کنترل تغییر ایجاد می‌کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می‌شود.
متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده‌ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می‌کوشد تا نبود خطاها را با درجه‌ای از جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال‌های متضادی برای کدهایی که نمی‌توان ثابت کرد، فراهم می‌کنند. تیم‌های چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند.
متدهای چابک که از دههٔ ۹۰–۱۹۸۰ توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با «توسعهٔ سریع اپلیکیشن‌ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری‌محور و طراحی‌محور (مانند نمونه‌سازی سریع تجسم‌محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعهٔ چابک نرم‌افزار تشویق می‌کنند.
در سال ۲۰۰۸ مؤسسهٔ مهندسی نرم‌افزار (SEI) گزارش فنی «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن ۱٫۳ شامل تیپ‌هایی برای پیاده‌سازی چابک و CMMI است.
یکی از تفاوت‌های بین چابک و آبشاری، این است که تست نرم‌افزار در نقاط مختلفی در چرخهٔ عمر توسعهٔ نرم‌افزار انجام می‌شود. در مدل آبشاری، یک فاز تست به صورت جداگانه بعد از پیاده‌سازی وجود دارد. در چابک XP، به‌طور هم‌زمان با پیاده‌سازی انجام می‌شود. به‌طور کلی اگر بیشتر ناشناخته‌ها شناخته شوند (مانند نیازمندی‌های خوبی که تا آن زمان تحلیل شده‌اند)، رویکرد پیشگویانه ممکن است مناسب‌تر باشد. اما اگر ناشناخته‌های شناخته‌نشدهٔ زیادی وجود داشته باشد (مانند نیازمندی‌هایی که ضعیف شناخته‌شده‌اند و هنوز بهبود نیافته‌اند)، رویکرد چابک اجازهٔ بلوغ تدریجی و پیاده‌سازی را می‌دهد.
متدهای چابک

متدهای معروف توسعهٔ چابک نرم‌افزار عبارتند از:
مدل‌سازی چابک
فرایند یکپارچهٔ چابک (AUP)
Crystal Clear
متدهای Crystal
متدهای توسعهٔ سیستم‌های دینامیک (DSDM)
برنامه‌نویسی اکستریم (XP)
توسعهٔ ویژگی‌محور (FDD)
طراحی گرافیکی سیستم (GSD)
توسعه Kanban
توسعه Lean
Scrum
ردیابی سرعت
متدهای چابک > سازمان‌دهی متد

در، اصطلاحات متفاوتی به مفهوم متد انطباقی برمی‌گردد، شامل «سازمان‌دهی متد»، «تطابق قطعات متد» و «مهندسی موقعیتی متد». مناسب‌سازی متد به صورت زیر تعریف می‌شود:
فرایند یا قابلیتی که در آن عوامل انسانی یک رویکرد توسعهٔ سیستم را برای موقعیت پروژه‌ای خاص از طریق تغییرات پاسخگو در، و اثرات متقابل دینامیک بین زمینه‌ها، مفاهیم و قطعات متد تعریف می‌کنند.
به‌طور بالقوه، تقریباً تمام متدهای چابک برای سازمان‌دهی متد مناسب هستند. حتی متد 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، Rankainen & Warsta، 2002).
اندازه‌گیری میزان چابکی

اگرچه چابکی به عنوان ابزاری برای پایان دیده می‌شود، تعدادی رویکرد پیشنهاد شده‌اند که کیفیت چابکی را تعیین می‌کنند. اندازه‌گیری شاخص‌های چابکی (AIM) پروژه‌ها را برای کسب یک امتیاز کل، در مقابل تعدادی از فاکتورهای چابکی امتیازدهی می‌کنند. نام مشابه «شاخص اندازه‌گیری چابکی»، توسعه‌ها را در برابر ۵ بعد یک پروژهٔ نرم‌افزاری (مدت‌زمان، ریسک، تازگی، تلاش و تعامل) امتیازدهی می‌کند. تکنیک‌های دیگر مبتنی بر اهداف قابل‌اندازه‌گیری هستند.
مطالعهٔ دیگری با استفاده از ریاضیات فازی (fuzzy)، می‌گوید سرعت پروژه می‌تواند یکی از استانداردهای چابکی باشد. خودارزیابی‌هایی در چابکی وجود دارد که تعیین می‌کند آیا یک تیم از روش‌های چابک استفاده می‌کند یا خیر (آزمون Nokia، آزمون Karlskrona، ۴۲ آزمون نکته‌ای).
اگرچه چنین رویکردهایی برای اندازه‌گیری چابکی پیشنهاد شده‌اند، کاربرد عملی چنین معیارهایی هنوز دیده می‌شود.
از لحاظ تاریخی، در پروژه‌های چابکی که نتوانسته‌اند نتایج مطلوبی تولید کنند، کمبود داده وجود دارد. می‌توان مطالعاتی را یافت که پروژه‌ها را با پیاده‌سازی ناکارآمد یک (یا چند) متد چابک، ضعیف گزارش کرده‌اند، اما هیچ‌جا احساس نشد که به درستی اجرا شده‌اند و در تحویل تعهدات خود شکست خورده‌اند.
«این ممکن است یک دلیل بی‌میلی برای انتشار مقالات در مورد پروژه‌های ناموفق باشد، یا ممکن است نشان‌دهندهٔ آن باشد که وقتی متدهای چابک کار می‌کنند که پیاده‌سازی درست انجام شود.». اگرچه، داده‌هایی از ROI توسعهٔ چابک نرم‌افزار از CSIAC ROI Dashboard در دسترس است.).
آزمودگی و پذیرش

یکی از مطالعات اخیر که دستاوردهای کیفیت، بهره‌وری و رضایت کسب‌وکار با استفاده از متدهای چابک را گزارش می‌دهد، یک بررسی بود که توسط Shine Technologies از نوامبر ۲۰۰۲ تا ژانویهٔ ۲۰۰۳ انجام شد.
یک بررسی مشابه در سال ۲۰۰۶ توسط Scott Ambler (رهبر تمرین توسعهٔ چابک با گروه متدهای عقلانی IBM) انجام شد که همین فواید را بیان کرد. در بررسی انجام‌شده توسط VersionOne (یک تهیه‌کنندهٔ نرم‌افزار برای برنامه‌ریزی و پیگیری پروژه‌های توسعهٔ چابک نرم‌افزار) در سال ۲۰۰۸، ۵۵ درصد پاسخ‌دهندگان گفتند متدهای چابک در ۹۰ تا ۱۰۰ درصد موارد موفق بوده‌اند.
برخی دیگر ادعا می‌کنند متدهای توسعهٔ چابک بسیار جوان‌تر از آن هستند که نیاز به اثبات گسترده و علمی موفقیت‌شان داشته باشند.
آزمودگی و پذیرش > سازگاری

بخش وسیعی از توسعهٔ چابک نرم‌افزار به صورت یک زمینهٔ تحقیقاتی پرکار باقی مانده‌است. به‌طور گسترده توسعهٔ چابک برای انواع مشخصی از محیط‌ها، شامل تیم‌های کوچک متخصصان، مناسب‌تر به نظر می‌رسد. در سال‌های اخیر برخورد مثبت با متدهای چابک در دامنهٔ Embedded در اروپا مشاهده شده‌است.
بعضی مواردی که ممکن است بر موفقیت یک پروژهٔ چابک، تأثیر منفی بگذارد، عبارتند از:
تلاش‌های توسعه در مقیاس وسیع (>۲۰ توسعه‌گر)، اگرچه استراتژی‌های مقیاس‌گذاری و مدارک بعضی پروژه‌های بزرگ توضیح داده شده‌است؛
تلاش‌های توسعهٔ توزیع‌شده (تیم‌های غیرهم‌مکان). استراتژی‌ها در «پل‌بندی و فاصله» و «استفاده از فرایند چابک نرم‌افزار با توسعهٔ دور [دورکاری]» توضیح داده شده‌است؛
تحمیل یک فرایند چابک به یک تیم توسعه؛ سیستم‌های مأموریت بحرانی که در آن‌ها شکست، به هر قیمتی یک گزینه نیست (مثل نرم‌افزار کنترل ترافیک هوایی).
اخیراً موفقیت‌ها، چالش‌ها و محدودیت‌هایی که در انطباق با متدهای چابک در یک سازمان بزرگ مشاهده می‌شوند، مستندسازی شده‌اند.
در شرایط برون‌سپاری توسعهٔ چابک، Michael Hckett، معاون رئیس شرکت LogiGear گفته‌است «یک تیم دورکار... باید این موارد را داشته باشد: تخصص، تجربه، مهارت‌های ارتباطی خوب، تفاهم بین فرهنگ‌ها، اعتماد و تفاهم بین اعضا، گروه‌ها و با یکدیگر.».
متدهای چابک به‌طور گسترده برای توسعهٔ محصولات نرم‌افزاری به کار رفته‌اند، بعضی از آن‌ها نیز از خصوصیات مشخصی از نرم‌افزار، مانند فناوری‌های موضوع استفاده می‌کنند. اگرچه این فناوری‌ها می‌توانند برای محصولات غیر نرم‌افزاری (مانند کامپیوترها، وسایل نقلیهٔ موتوری، وسایل پزشکی، خوراک و پوشاک) نیز به کار گرفته شوند.
همچنین تحلیل ریسک می‌تواند برای انتخاب بین متدهای انطباقی (چابک یا ارزش‌محور) و پیشگویانه (برنامه‌محور) استفاده شود. Barry Boehm و Richard Turner می‌گویند که هر سوی این زنجیره پایهٔ اصلی (home ground) خاص خود را دارد، که به شرح زیر است:
| پایهٔ اصلی چابک | پایهٔ اصلی ارزش‌محور | متدهای رسمی |
| --- | --- | --- |
| حساسیت پایین | حساسیت بالا | حساسیت شدید |
| توسعه‌دهندگان ارشد | توسعه‌دهندگان تازه‌کار | توسعه‌دهندگان ارشد |
| نیازمندی‌ها اغلب تغییر می‌کنند. | نیازمندی‌ها اغلب تغییر نمی‌کنند. | نیازمندی‌های محدود، خصوصیات محدود |
| تعداد کمی از توسعه‌دهندگان | تعداد زیادی از توسعه‌دهندگان | نیازمندی‌ها می‌توانند مدل‌سازی شوند |
| فرهنگ پاسخ به تغییر | فرهنگ نیاز به نظم | کیفیت بسیار زیاد |
نقد

ممکن است متدولوژی‌های چابک در سازمان‌های بزرگ و انواع خاصی از پروژه‌ها ناکارآمد باشند.
متدهای چابک برای پروژه‌های توسعه‌ای و غیردائمی بهتر به نظر می‌رسد. بسیاری از سازمان‌ها باور دارند متدولوژی‌های چابک بسیار قوی هستند و با یک رویکرد مخلوط که ترکیبی از المان‌های رویکردهای چابک و برنامه‌محور است، سازگار می‌شوند.
مارتین فولر، به عنوان یکی از بنیان‌گذاران کلیدی متدهای چابک شناخته می‌شود.
برنامه‌نویسی دونفره ، یکی از تکنیک‌های توسعهٔ چابک از طریق XP است. به رادیاتورهای اطلاعات در پس‌زمینه توجه کنید.
چرخهٔ عمر پشتیبانی از توسعهٔ نرم‌افزار
لوئیجی فورلان

| مشخصات فردی | مشخصات فردی |
| --- | --- |
زاده: ۲۲ ژوئن ۱۹۶۳ ‏(۶۱ سال) ژنو، ایتالیا
اطلاعات تیم: اطلاعات تیم
نقش: Rider
لوئیجی فورلان (ایتالیایی: Luigi Furlan؛ زادهٔ ۲۲ ژوئن ۱۹۶۳) دوچرخه‌سوار اهل ایتالیا است.
جاده ئی۷۵۱ اروپا

|  E751 |  E751 |
| --- | --- |
اطلاعات مسیر: اطلاعات مسیر
طول: ۲۰۰ کیلومتر (۱۲۰ مایل)
تقاطع‌های بزرگ: تقاطع‌های بزرگ
از: رییکا (کرواسی)
به: کوپر (اسلوونی)
موقعیت: موقعیت
کشورها: کرواسی، اسلوونی
 :  
سامانه بزرگراهی: سامانه بزرگراهی
شبکه بین‌المللی جاده‌ای اروپا: شبکه بین‌المللی جاده‌ای اروپا
جاده ئی۷۵۱ اروپا (به انگلیسی: European route E751) یکی از جاده‌های درجه ۲ قاره اروپا است.
این جاده از شهر رییکا (کرواسی) شروع شده و در شهر کوپر (اسلوونی) به پایان می‌رسد.
سیمون ویتال

| اطلاعات شخصی | اطلاعات شخصی | اطلاعات شخصی | اطلاعات شخصی |
| --- | --- | --- | --- |
زادروز:  ۱ مارس ۱۹۸۶ ‏(۳۸ سال)
زادگاه:  سورا، لاتزیو
قد:  1.82 m
پست:  مدافع
باشگاه‌های جوانان: باشگاه‌های جوانان
:  باشگاه فوتبال دلفینو پسکارا
باشگاه‌های حرفه‌ای*: باشگاه‌های حرفه‌ای*
| سال‌ها |  باشگاه‌ها |  بازی† |  (گل)† |
| ۲۰۰۴–۲۰۱۱ |  باشگاه فوتبال دلفینو پسکارا |  ۸۷ |  (۵) |
| ۲۰۰۵–۲۰۰۷ |  ← Pro Vasto (قرضی) |  ۵۷ |  (۲) |
| ۲۰۱۱–۲۰۱۳ |  باشگاه فوتبال فروزینونه |  ۲۹ |  (۱) |
| ۲۰۱۳–۲۰۱۴ |  Nocerina |  ۶ |  (۰) |
| ۲۰۱۴–۲۰۱۵ |  Renato Curi Angolana |   |   |
| ۲۰۱۵–۲۰۱۶ |  Chieti |  ۱۸ |  (۱) |
| ۲۰۱۶–۲۰۱۸ |  Spoltore |   |   |
| ۲۰۱۸–۲۰۱۹ |  Teramo |  ۲ |  (۰) |
 تعداد بازی‌ها و گل‌ها فقط مربوط به بازی‌های لیگ داخلی است و آمار به روز شده در تاریخ ۱۹ ژانویه ۲۰۱۹. :  تعداد بازی‌ها و گل‌ها فقط مربوط به بازی‌های لیگ داخلی است و آمار به روز شده در تاریخ ۱۹ ژانویه ۲۰۱۹. 
سیمون ویتال (انگلیسی: Simone Vitale؛ زادهٔ ۱ مارس ۱۹۸۶) بازیکن فوتبال اهل ایتالیا است.
از باشگاه‌هایی که در آن بازی کرده‌است می‌توان به باشگاه فوتبال فروزینونه و باشگاه فوتبال دلفینو پسکارا اشاره کرد.
منطقه حفاظت‌شده پروند

| منطقه حفاظت‌شده پروند | منطقه حفاظت‌شده پروند |
| --- | --- |
مکان: استان خراسان رضوی، ایران
مساحت: ۱۶۹۰۰ هکتار
منطقه حفاظت‌شده پروند با وسعت ۱۶۹۰۰ هکتار در شهرستان سبزوار در غرب روستای پروند واقع شده‌است. چهره طبیعی این منطقه به صورت کوهستانی، تپه ماهوری و دارای آب و هوای خشک می‌باشد.
منطقه پروند طی مصوبه شماره ۳۴۰ شورای عالی محیط زیست (کمیسیون زیر بنائی دولت) مورخ ۱۳۸۹/۹/۲۹ به عنوان منطقه حفاظت شده به مناطق تحت مدیریت سازمان حفاظت محیط زیست پیوسته‌است. احتمالاً پیشتر صرفاً به عنوان منطقه شکارممنوع بوده‌است.
حداکثر ارتفاع منطقه از سطح دریا ۱۴۵۵متر در کوه‌های پروند و حداقل آن در حاشیه دشت زرقانی ۹۶۰ متر می‌باشد.
پوشش گیاهی

گونه‌های گیاهی منطقه شامل تاغ، بنه، گون، گز، بادام وحشی، اسکنبیل، آتریپلکس، قیچ، درمنه، بومادران و زالزالک است.
در گردنه دوچاهی بر روی دامنه‌های غربی و سنگلاخی کوه پروند در مجاورت غار آهکی پروند، یک درخت ارس ۴۰۰ ساله نیز روییده‌است.
گونه‌های جانوری

تصاویری از منطقه شکار ممنوع پروند
قوچ
سسک جنبان
پستانداران: پلنگ، گرگ، کفتار، گربه وحشی، آهو، قوچ و میش، کل و بز
خزندگان: افعی شاخدار، مار جعفری، بزمجه و لاک‌پشت
پرندگان: کبک، تیهو، باقرقره، هوبره، کوکر و عقاب
سد ۱۰ثانیه‌ای

کارل لوئیس اولین مردی بود که زیر ده ثانیه در ارتفاع کم دوید.
سد ۱۰ ثانیه ای مانع فیزیکی و روانی برای تکمیل دوی ۱۰۰ متر در کمتر از ده ثانیه است. این دستاورد به‌طور سنتی به عنوان نشانه بارز یک دونده مرد در کلاس جهانی در نظر گرفته می‌شود. گرچه اهمیت آن از اواخر دهه ۱۹۹۰ کمتر شده‌است، زیرا تعداد فزاینده ای از دوندگان از مرز ده ثانیه فراتر رفته‌است. رکورددار کنونی مردان جهان، یوسین بولت است که در مسابقات قهرمانی جهانی IAAF در سال ۲۰۰۹، ۹٫۵۸ دوید.
زمان‌بندی خودکار

پس از تغییر قانون در سال ۱۹۷۷، رکورد ۹٫۰۵ ثانیه‌ای (که او برای ۹ سال در اختیار داشت) جیم هاینز تنها مسابقه زیر ۱۰ ثانیه شناخته شد. در آن سال، هنگامی که سیلویو لئونارد در ۱۱ اوت ۱۹۷۷ ۹٫۹۸ ثانیه دوید، سد دوباره شکسته شد. هر دوی این علائم در ارتفاع بالا ثبت شده‌اند که به دلیل مقاومت کمتر هوا به عملکرد کمک می‌کند.
کارل لوئیس با ۹٫۹۷ اولین دونده سرعتی بود که ده ثانیه در ارتفاع کم تحت زمان‌بندی الکترونیکی شکست داد او در ۱۴ مه ۱۹۸۳ توانست این افتخار را کسب کند.
. کالوین اسمیت در ۳ ژوئیه ۱۹۸۳ در کلرادو اسپرینگز کلرادو رکورد جهانی ۹٫۹۳ ثانیه را در ارتفاع به ثبت رساند و اولین دونده سرعتی بود که در اوت همان سال دو بار زیر ده ثانیه دوید. در مجموع، شش دونده سرعت به‌طور قانونی در طول دهه ۱۹۸۰ سد را شکستند. بن جانسون هم به رکورد زیر ۱۰ ثانیه دست یافت اما پس از مثبت شدن تست دوپینگ او این افتخارات از او پس گرفته شد.
فینال ۱۰۰ متر در مسابقات جهانی ۱۹۹۱ نشان دهنده یک اوج جدید در این رویداد بود: شش ورزشکار در همان مسابقه کمتر از ۱۰ ثانیه دویدند و کارل لوئیس برنده رکورد جهانی را به ۹٫۸۶ ثانیه کاهش داد. در مکان دوم لروی بورل قرار گرفت که رکورد قبلی جهان را که با ۹٫۹۰ ثانیه متعلق به او بود، شکست. در جایگاه سوم با ۰٫۰۱ ثانیه کندتر از رکورد قبلی جهان، دنیس میچل با زمان ۹٫۹۱ ثانیه قرار گرفت. لینفورد کریستی با زمان ۹٫۹۲ ثانیه در مکان چهارم با شکستن رکورد اروپایی خود با ۹٫۹۷ ثانیه قرار گرفت.
موریس گرین اولین ورزشکاری بود که زیر ۹٫۸۰ دوید ثانیه در سال ۱۹۹۹ یوسین بولت در سال ۲۰۰۸ از ۹٫۷۰ ثانیه و در سال ۲۰۰۹ از ۹٫۶۰ گذشت. سد ۱۰ ثانیه ای توسط ورزشکاران پنج انجمن از ۶ انجمن دو و میدانی قاره شکسته شده‌است، به استثنای آمریکای جنوبی که رابسون داسیلوا برزیلی با ده ثانیه ثابت رکورد منطقه را در اختیار دارد.
سیمون ویتلی

سیمون ویتلی (به انگلیسی: Simon Wheatley) (۱۹۷۰-تاکنون) عکاس مستند و سنگاپوری است. وی دوران نوجوانی و دانشجویی‌اش را در بریتانیا گذراند و در سال ۱۹۹۳ با مدرک مطالعات جامعه‌شناسی آمریکا و آمریکای لاتین، از دانشگاه منچستر فارغ‌التحصیل شد.
او سال‌های زیادی را با رویای نویسندگی سپری کرد اما با گذر زمان استعداد بیشتری در رشته عکاسی در خود یافت. سیمون در میانه دهه ۱۹۹۰ با نقل‌مکان به بوداپست، عکاسی را به طور جدی آغاز کرد. او می‌گوید:عکاسی به من کمک می‌کند تا انسان ساده‌تری باشم. در عین حال به من فرصت می‌دهد تا داستان‌هایم را با زبان تصویر روایت کنم. تک عکس‌هایم در مجلات هیچوقت من را راضی نمی‌کند.»
وی یکی از اعضای اصلی مگنوم فوتوز نیز می‌باشد.
چارمینستر

منطقه مسکونی در England
| چارمینستر | چارمینستر |
| --- | --- |
 Parish church of St Mary's:  Parish church of St Mary's
چارمینسترچارمینستر نمایش داده شده در  دورست (انگلستان): چارمینسترچارمینستر نمایش داده شده در  دورست (انگلستان)
جمعیت: ۲٬۹۴۰ 
مرجع شبکه OS: SY680927 
منطقه: West Dorset
Shire county: دورست (انگلستان)
ناحیه: جنوب غربی انگلستان
کشور: England
کشور مستقل: بریتانیا
کدپستی منطقه: DT
پلیس: Dorset
آتشنشانی: Dorset
آمبولانس: South Western
 :  
مجلس انگلستان: West Dorset
 فهرست مکان‌‌ها بریتانیا انگلستان Dorset ۵۰°۴۳′۵۸″شمالی ۲°۲۷′۱۷″غربی﻿ / ﻿۵۰٫۷۳۲۷°شمالی ۲٫۴۵۴۶°غربی﻿ / 50.7327; -2.4546:  فهرست مکان‌‌ها بریتانیا انگلستان Dorset ۵۰°۴۳′۵۸″شمالی ۲°۲۷′۱۷″غربی﻿ / ﻿۵۰٫۷۳۲۷°شمالی ۲٫۴۵۴۶°غربی﻿ / 50.7327; -2.4546
چارمینستر (به انگلیسی: Charminster) یک روستا و محله مدنی در بریتانیا است که در West Dorset واقع شده‌است. چارمینستر ۲٬۹۴۰ نفر جمعیت دارد.
سازمان انقلابی توده‌های جمهوری اسلامی

سازمان انقلابی توده‌های جمهوری اسلامی (ساتجا) سازمانی اسلامی بود به رهبری محمد منتظری.
هدف این سازمان استقرار جمهوری اسلامی در دیگر کشورهای اسلامی بود.
پس از کشته شدن محمد منتظری در انفجار حزب جمهوری اسلامی، ساتجا به گروهی به نام جنبش‌های آزادی‌بخش جهان اسلام به رهبری سید مهدی هاشمی پیوست.
سیارک ۲۶۵۸

| کشف | کشف |
| --- | --- |
تاریخ کشف: فوریه ۱۳, ۱۹۸۰
ویژگی‌های مداری: ویژگی‌های مداری
مبدأ مه ۱۴, ۲۰۰۸: مبدأ مه ۱۴, ۲۰۰۸
اوج: ۳.۹۵۲۵۱۱۶
حضیض: ۲.۲۲۱۱۹۱۶
خروج از مرکز مداری: ۰.۲۸۰۴۳۴۶
تناوب مداری: ۱۹۸۰.۹۴۳۳۲۵۲
آنومالی متوسط: ۷۶.۹۵۳۹۷
انحراف: ۹.۴۲۵۹۹
 :  
سیارک ۲۶۵۸ (به انگلیسی: 2658 Gingerich، نامگذاری:1980CK) دو هزار و ششصد و پنجاه و هشتمین سیارک کشف شده‌است که در ۱۳ فوریه ۱۹۸۰ کشف شد.
قدر مطلق سیارک برابر ۱۲٫۴۰ است.
چالوولی

| چالوولی | چالوولی |
| --- | --- |
چالوولی: چالوولی
مختصات: ۳۹°۵۲′ شمالی ۴۹°۱۸′ شرقی﻿ / ﻿۳۹٫۸۶۷°شمالی ۴۹٫۳۰۰°شرقی﻿ / 39.867; 49.300: مختصات: ۳۹°۵۲′ شمالی ۴۹°۱۸′ شرقی﻿ / ﻿۳۹٫۸۶۷°شمالی ۴۹٫۳۰۰°شرقی﻿ / 39.867; 49.300
کشور:  جمهوری آذربایجان
تقسیمات کشوری جمهوری آذربایجان: شهرستان سالیان
منطقهٔ زمانی: یوتی‌سی +۴ (AZT)
 • تابستانی (DST): یوتی‌سی +۵ (AZT)
چالوولی (به انگلیسی: Chalovly) یک منطقه مسکونی در جمهوری آذربایجان است که در شهرستان سالیان واقع شده است.
جاده ئی۷۳ اروپا

| E۷۳ shield E۷۳ | E۷۳ shield E۷۳ |
| --- | --- |
اطلاعات مسیر: اطلاعات مسیر
طول: ۶۸۴ کیلومتر (۴۲۵ مایل)
تقاطع‌های بزرگ: تقاطع‌های بزرگ
انتهای شمالی: بوداپست (مجارستان)
انتهای جنوبی: متکویچ (کرواسی)
موقعیت: موقعیت
کشورها: مجارستان، کرواسی، بوسنی و هرزگوین
 :  
سامانه بزرگراهی: سامانه بزرگراهی
شبکه بین‌المللی جاده‌ای اروپا: شبکه بین‌المللی جاده‌ای اروپا
جاده ئی۷۳ اروپا در بوسنی و هرزگوین
جاده ئی۷۳ اروپا (به انگلیسی: European route E73) یکی از جاده‌های اصلی قاره اروپا است.
این جاده که از شهر بوداپست (مجارستان) شروع شده، در شهر متکویچ (کرواسی) به پایان می‌رسد و ۶۸۴ کیلومتر مسافت دارد.