در چند سال اخیر، تعداد شیوه‌های فنی محبوب به طور تصاعدی افزایش یافته است. یادگیری شیوه‌های رایج توسعه نرم افزار می‌تواند به شما کمک کند تا برنامه نویس بهتری شوید. کتاب Agile Technical Practices Distilled (روشهای فنی چابک تقطیر شده) از اصطلاح Agile به عنوان یک چتر گسترده استفاده می‌کند و اصول و شیوه‌های Agile و همچنین اکثر روش‌های مرتبط با آن را پوشش می‌دهد.

شما با کشف اینکه چگونه راننده-ناوبر، ساعت شطرنج، و سایر تکنیک‌های مورد استفاده در رویکرد برنامه نویسی دو نفره، به کد نویسی نظم می‌دهند، شروع خواهید کرد. سپس یاد خواهید گرفت که با استفاده از refactoring، طراحی کد خود را با خیال راحت تغییر دهید. در حین یادگیری این تکنیک ها، بهترین شیوه‌های مختلف برای نوشتن تست‌های کارآمد را نیز بررسی خواهید کرد. فصول پایانی کتاب عمیقاً به اصول SOLID می‌پردازند؛ پنج اصل طراحی که می‌توانید از آنها استفاده کنید تا نرم افزار خود را قابل درک تر، انعطاف پذیرتر و قابل نگهداری‌تر کنید.

با به پایان رساندن این کتاب، ایده‌های جدیدی برای بهبود مهارت‌های طراحی نرم‌افزار، روابط درون تیم و نحوه کار کسب‌وکارتان کشف خواهید کرد.

در دهه‌ی گذشته، حرکت به سمت روش‌های سبک وزن‌تر و چابک تر، قابل توجه‌ترین تغییر برای تاثیر گذاری بر روی پروژه‌های نرم افزاری از زمان ظهور مدل آبشاری در دهه 1970 بوده است. این روش‌ها که از رهبران فکر و عمل مختلفی نشات گرفته شده اند و در واقعیت ثابت شده و در آزمایش ها  نیزموفق شده اند، ثابت کرده اند که مزایای برجسته ای در معیار‌های «چهار بزرگ» ارائه می‌دهند: بهره وری، کیفیت، روحیه و زمان عرضه به بازار. در پنج سال گذشته، این روش‌ها به صورت ویروسی گسترش یافتند. در سازمان‌های بزرگتر، این ابتکارات معمولا با تیم‌های جداگانه ای آغاز می‌شوند که برخی یا همه‌ی شیوه‌های مورد حمایت توسط روش‌های مختلف، در درجه اول XP، Scrum، Lean، Kanban و ترکیبات و انواع مختلف را اتخاذ می‌کنند. با این حال، با گسترش روش‌ها به سطح سازمانی، تعدادی افزونه برای روش‌های پایه ای چابک به منظور رسیدگی به فرآیند‌های بزرگ تر، سازمانی، حوزه کاربرد و چالش‌های حاکمیت سازمان بزرگ‌تر لازم بود.
کشف و تجزیه و تحلیل نیازمندی‌های موثر، بهترین شیوه حیاتی برای توسعه جدی برنامه است. با این حال تاکنون، نیازمندی‌ها و روش‌های چابک به ندرت با همزیستی مسالمت آمیزی داشته اند. برای بسیاری از سازمان‌ها که رویکرد‌های Agile را در نظر می‌گیرند، عدم وجود روند‌های نیازمندی‌های چابک مقیاس پذیر و موثر، مانع پذیرش چابک بوده اند. در کتاب Agile Software Requirements (نیازمندی‌های نرم افزاری چابک)، Dean Leffingwell دقیقاً نحوه‌ی ایجاد نیازمندی‌های موثر در محیط‌های چابک را نشان می‌دهد.
این کتاب به شما کمک می‌کند تا از مزایای Agile استفاده کنید بدون اینکه ارزش کشف و تجزیه و تحلیل نیازمندی‌های موثر را از بین ببرید. در این کتاب، راه حل‌های اثبات شده ای را پیدا خواهید کرد که می‌توانید همین حالا اعمال کنید - خواه یک توسعه دهنده نرم افزار یا تست کننده، مدیر اجرایی، مدیر پروژه/برنامه، معمار یا رهبر تیم باشید.

توسعه چابک، توانایی توسعه سریع نرم افزار در مواجهه با نیازمندی‌های به سرعت در حال تغییر است. برای دستیابی به این چابکی، ما باید شیوه هایی را به خدمت بگیریم که نظم و بازخورد لازم را فراهم کنند. ما نیاز به استفاده از اصول طراحی داریم تا نرم افزارمان را انعطاف پذیر و قابل نگهداری نگه دارند؛ و نیاز داریم تا الگو‌های طراحی که به منظور متوازن نگه داشتن این اصول برای مسائل خاص پدید آمده اند را بدانیم. این کتاب، تلاشی برای گره زدن هر سه این مفاهیم به یکدیگر به منظور تشکیل یک اتحاد کارآمد است. این کتاب، اصول، الگوها و شیوه‌ها را توصیف می‌کند و سپس نحوه‌ی بکارگیری آن‌ها را توسط شرح دقیق ده‌ها مورد مطالعاتی مختلف نشان می‌دهد. از همه مهمتر، موارد مطالعاتی به عنوان کار‌های کاملی ارائه نشده اند؛ بلکه الگو هایی در حال پیشرفت هستند. خواهید دید که طراحان اشتباه می‌کنند و مشاهده خواهید کرد که چگونه اشتباهات را شناسایی کرده و در نهایت تصحیح می‌کنند. خواهید دید که آن‌ها بر سر معما‌ها گیج می‌شوند و نسبت به ابهامات و سبک سنگین کردن‌ها نگران هستند. در حقیقت شما عمل طراحی را مشاهده خواهید کرد.
این کتاب که توسط یک توسعه دهنده نرم افزار برای توسعه دهندگان نرم افزار نوشته شده است، مجموعه ای منحصر به فرد از جدیدترین متدهای توسعه نرم افزار است. کتاب Agile Software Development, Principles, Patterns, and Practices ( توسعه نرم افزار چابک، اصول، الگو‌ها و شیوه ها) که توسط Robert C. Martin تالیف شده است، شامل روش‌های OOD، UML، الگو‌های طراحی، چابک و XP، همراه با شرح مفصلی از طراحی کامل نرم افزار  برای برنامه‌های قابل استفاده مجدد در سی پلاس پلاس و جاوا است. با استفاده از یک رویکرد عملی و حل مسئله، چگونگی توسعه یک برنامه شی گرا از مراحل اولیه تجزیه و تحلیل و از طریق طراحی سطح پایین تا پیاده سازی آن، نشان داده می‌شود. این کتاب، افکار طراح را به خوانندگان نشان می‌دهد – نشان دادن خطاها، کوچه‌های بن بست و بینش‌های خلاقانه ای که در طول مراحل طراحی نرم افزار رخ می‌دهند. این کتاب شامل موارد زیر است: استاتیک‌ها و پویا ها؛ اصول طراحی کلاس؛ مدیریت پیچیدگی؛ اصول طراحی پکیج؛ تحلیل و طراحی الگوها؛ گذرگاههای پارادایمی. این کتاب اصول OOD را یک به یک توضیح می‌دهد و سپس آنها را با مثال‌های متعدد، الگو‌های کاملاً کار شده و موارد مطالعاتی به نمایش می‌گذارد. همچنین در استفاده از ++C و OOD تله ها، دام‌ها و راهکار‌ها را پوشش می‌دهد و سپس نشان می‌دهد که چگونه می‌توان از روش‌های Agile استفاده کرد. در ادامه در مورد روش‌های طراحی و توسعه نرم افزار بزرگ به طور مفصل بحث می‌کند. یک مورد مطالعاتی از ساخت سیستم امنیتی نیز به صورت مفصل و در سه فصل در این کتاب ارائه شده است. برای مهندسین نرم افزار، برنامه نویسان و تحلیلگرانی که می‌خواهند نحوه طراحی نرم افزار شی گرا را با روش‌های پیشرفته درک کنند، این کتاب مناسب است.

اسکرام چارچوبی برای توسعه و حفظ محصولات پیچیده مانند نرم افزار است. Scrum فقط مجموعه ای از قوانین است که در Scrum Guide تعریف شده اند و نقش ها، رویدادها، مصنوعات و همچنین قوانینی را که آنها را به هم پیوند می‌دهند را توصیف می‌کند. این چارچوب در صورت استفاده صحیح، یک تیم را قادر می‌سازد تا مشکلات پیچیده را برطرف کند در حالی که خلاقانه و مولدانه، محصولاتی با بالاترین ارزش ممکن را ارائه می‌دهد. اسکرام یک روش چابک (Agile) است. در حقیقت، این روش محبوب‌ترین روش Agile است که امروزه استفاده می‌شود.
اسکرام از رویکردی تکرار شونده و افزایشی برای بهینه سازی قابل پیش بینی بودن و کنترل ریسک استفاده می‌کند. این ناشی از ماهیت کنترل فرآیند تجربی اسکرام است. از طریق استفاده صحیح از بازرسی، سازگاری و شفافیت، یک تیم اسکرام می‌تواند روش جدیدی را برای انجام کاری (یک آزمایش) امتحان کند و مفید بودن آن را پس از یک تکرار کوتاه اندازه گیری کند. سپس آنها می‌توانند به طور جمعی تصمیم بگیرند که این شیوه را بپذیرند، گسترش دهند یا آن را کنار بگذارند. این، ابزارهایی که یک تیم استفاده می‌کند و نحوه استفاده از آنها را نیز شامل می‌شود.
ترکیب Scrum با ابزارهای موجود در Microsoft Azure DevOps یک اتحاد قدرتمند را تشکیل می‌دهد. هدف کتاب Professional Scrum Development with Azure DevOps (توسعه اسکرام حرفه ای با آژور دِو اُپس) تالیف Richard Hundhausen، ایجاد درک اولیه از اسکرام و چگونگی پشتیبانی از Scrum در Azure DevOps است. من همچنین توضیح خواهم داد که کدام شیوه‌ها وقتی بدون استفاده از ابزار‌ها اجرا شوند ارزش بیشتری ارائه خواهند داد. علاوه بر این، من به ابزارهایی که به اشتباه به عنوان چابک به بازار عرضه شده اند اشاره خواهم کرد و آنها را با شیوه‌های ترجیحی‌تر مقایسه می‌کنم.
در توسعه نرم افزار، هر چیزی و همه چیز می‌توانند در یک لحظه تغییر کنند. تیم‌های سالم این را می‌دانند. آنها همچنین می‌دانند که بازرسی مداوم و انطباق با روش انجام کار ها، یک راه زندگی است. تیم‌های اسکرام با عملکرد بالا، این کار را یک گام فراتر می‌برند. آنها می‌دانند که در هر مانعی یا اختلال در کارکرد، فرصتی برای یادگیری و پیشرفت است. خواندن این کتاب اولین قدم عالی است.
این کتاب برای هر عضوی از تیم توسعه نرم افزار که از Scrum استفاده می‌کند یا قصد استفاده از Scrum را دارد، ارزشمند خواهد بود. من در درجه اول بر مسئولیت‌ها و وظایف توسعه دهنده تمرکز می‌کنم (که در Scrum شامل طراحان، معماران، کد نویسان، تست کنندگان، نویسندگان فنی و غیره است.). صاحبان محصولات و اسکرام مسترها نیز از این کتاب بهره خواهند گرفت، زیرا آنها از بسیاری از ابزارهای Azure DevOps برای برنامه ریزی و مدیریت کار خود و ارزیابی پیشرفت استفاده خواهند کرد. ذینفعان از جمله مشتریان، کاربران، حامیان مالی و مدیران نیز از این کتاب بهره خواهند برد، خصوصاً وقتی یاد بگیرند که طبق قوانین Scrum چه کارهایی را باید انجام دهند و چه کارهایی نباید انجام دهند و کدام ابزارها در Azure DevOps از این قوانین پشتیبانی می‌کنند.
این کتاب در درجه اول بر استفاده از Scrum برای محصولات نرم افزاری تمرکز دارد، بیشتر به این دلیل که حوزه مورد نظر Azure DevOps است. با این حال، بیشتر این کتاب فراتر از توسعه نرم افزار و پروژه‌های IT قابل استفاده است. از آنجا که اسکرام یک چارچوب سبک برای توسعه راهکار‌های تطبیق پذیر با انواع مسائل پیچیده است، راهنمای موجود در این کتاب می‌تواند در مورد توسعه هر نوع کالایی مانند خدمات، کالاهای فیزیکی یا موارد انتزاعی‌تر به کار گرفته شود.

من تصمیم گرفته ام تا در مورد یک روش ساده که به آن story mapping (نگاشت داستان) می‌گویم، بنویسم. من و افراد زیاد دیگری، نگاشت‌های ساده ای می‌سازیم تا به ما کمک کنند که با هم با دیگران کار کنیم و تجربه استفاده از یک محصول را تصور کنیم. ساختن یک نگاشت خیلی ساده است. با همکاری دیگران، من داستان یک محصول را تعریف می‌کنم و هر قدم بزرگی که کاربران در این داستان بر می‌دارند را در یک جریان چپ به راست روی یادداشت‌های چسبان می‌نویسم. سپس، ما بر می‌گردیم و در مورد جزئیات هر مرحله صحبت خواهیم کرد و این جزئیات را روی یادداشت‌های چسبان می‌نویسیم و آنها را به صورت عمودی در زیر هر مرحله قرار می‌دهیم. نتیجه، یک ساختار ساده جدول مانند است که داستانی را از چپ به راست تعریف می‌کند و آن را از بالا به پایین به جزئیات می‌شکند. این سرگرم کننده و سریع است و این جزئیات، backlog بهتری از داستان‌ها را برای پروژه‌های توسعه چابک ما می‌سازند.
نوشتن کتاب در این باره چقدر می‌تواند پیچیده باشد؟ اما معلوم شد که حتی چیز‌های ساده نیز می‌توانند بسیار پیچیده باشند. نوشتن در مورد اینکه چرا می‌خواهید یک نگاشت داستانی بسازید، چه چیزی هنگام ساختن آن اتفاق می‌افتد و همه روش‌های مختلفی که می‌توانید از آن استفاده کنید، احتیاج به صفحات خیلی زیادی داشت. از آنچه فکر می‌کردم چیز‌های بیشتری برای این شیوه ساده وجود داشت.
اگر از یک روند توسعه چابک استفاده می‌کنید، به احتمال زیاد لیست کار‌های انجام نشده (backlogs) را با داستان‌های کاربری پر می‌کنید. از آنجایی که من تصور می‌کردم که داستان‌ها (stories) شیوه رایجی هستند، نوشتن درباره آنها در این کتاب باعث اتلاف وقت من می‌شود. اما من اشتباه می‌کردم. در یک دهه و نیم از زمانی که داستان‌ها توسط Kent Beck برای اولین بار توصیف شده اند، آنها بیشتر از هر زمان دیگری محبوب‌تر هستند و همچنین بیشتر بد فهمیده و بد استفاده شده اند. این مرا ناراحت می‌کند. علاوه بر این، همه مزایایی که ما از نگاشت داستان به دست می‌آوریم را از بین می‌برد. بنابراین، در این کتاب، من مایلم تا آنجا که می‌توانم تصورات غلط بزرگ در مورد داستان‌ها و نحوه استفاده از آنها در توسعه نرم افزار Agile و Lean را اصلاح کنم. به همین دلیل، به گفته Tom Waits، من این «ساندویچ را به یک ضیافت» تبدیل کرده ام.
نگاشت داستان کاربری، ابزاری ارزشمند برای توسعه نرم افزار است؛ اما وقتی که دلیل و نحوه‌ی استفاده از آن را بفهمید. این کتاب آموزنده، بررسی می‌کند که چگونه این تکنیک اغلب بد فهمیده شده، می‌تواند به تیم شما کمک کند تا بر روی کاربران و نیاز هایشان بدون گم شدن در ویژگی‌های منحصر به فرد محصول، متمرکز باقی می‌بماند.
نویسنده این کتاب، Jeff Patton به شما نشان می‌دهد که چگونه نگاشت‌های داستانی متغیر، تیم شما را قادر می‌سازد تا در طول مراحل توسعه گفتگوهای بهتری درباره پروژه انجام دهند. تیم شما یاد خواهد گرفت تا به درکی مشترک از آن چه که شما کوشش می‌کنید تا بسازید برسد.

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

کتاب User Stories Applied که توسط جامعه چابک به طور کامل مورد بررسی قرار گرفته است، فرآیند‌های مورد نیازی که باعث صرفه جویی در وقت، از بین بردن دوباره کاری‌ها و منجر به تولید نرم افزاری بهتر می‌شوند را ارائه داده است.
بهترین راه برای ساختن نرم افزاری که نیازهای کاربران را برآورده کند، شروع با «داستان‌های کاربر» است: شرح ساده، واضح و مختصر عملکردی که برای کاربران واقعی ارزشمند خواهند بود. Mike Cohn در کتاب User Stories Applied به شما طرحی جامع برای نوشتن این داستان‌های کاربر ارائه می‌دهد و آن‌ها را جزئی از چرخه توسعه شما قرار می‌دهد. شما یاد خواهید گرفت که چه چیزی باعث ایجاد یک داستان کاربر خوب می‌شود و چه چیزی باعث ایجاد یک داستان کاربر بد می‌شود. در این کتاب روش‌های عملی برای جمع آوری داستان‌های کاربر را بررسی خواهید کرد، حتی زمانی که نمی‌توانید با کاربران خود صحبت کنید. سپس، هنگامی که داستان‌های کاربر خودتان را گردآوری کردید، Cohn نحوه سازماندهی، اولویت بندی و استفاده از آنها برای برنامه ریزی، مدیریت و آزمایش را نشان می‌دهد.

این کتاب را می‌توان «برآورد و برنامه ریزی پروژه‌های چابک» نیز نامید. در عوض، این کتاب «برآورد و برنامه ریزی چابک» نامیده شده است. این تفاوت ممکن است خیلی ظریف به نظر برسد، اما اینطور نیست. این عنوان مشخص می‌کند که فرآیندهای تخمین و برنامه ریزی نیز خود باید چابک باشند. بدون برآورد و برنامه ریزی چابک، نمی‌توانیم پروژه‌های چابک داشته باشیم.

این کتاب بیشتر در مورد برنامه ریزی است، که به نظر من پاسخی به سوال «چه چیزی را باید بسازیم و در چه زمانی؟» است، با این حال، برای پاسخ به سوالات مربوط به برنامه ریزی، باید سوالات تخمین («این چقدر بزرگ است؟») و زمانبندی («چه زمانی این کار تمام می‌شود؟» و «تا آن زمان، چقدر زمان می‌توانم داشته باشم؟») را پاسخ دهیم. ابتدا می‌آموزید که چه چیزی باعث می‌شود تا یک برنامه ریزی خوب ایجاد شود و سپس چه چیزی باعث چابکی آن می‌شود.

کتاب Agile Estimating and Planning، راهنمای کامل و عملی برای تخمین و برنامه ریزی پروژه‌های چابک است. در این کتاب، مایک کوهن، بنیانگذار Agile Alliance، فلسفه برآورد و برنامه ریزی چابک را مورد بحث قرار می‌دهد و نحوه انجام کار را دقیقاً با مثال‌های واقعی و موارد مطالعاتی به شما نشان می‌دهد.

این کتاب یک کار پژوهشی نیست. من مروری بر تحقیقات پیشین انجام نداده ام. آنچه که می‌خواهید بخوانید یادآوری خاطره ها، مشاهدات و نظرات شخصی من در طی ۲۰ سال سر و کار داشتن با Agile است – نه بیشتر نه کمتر.

این کتاب برای برنامه نویسان و غیر برنامه نویسان یکسان است. فنی نیست. هیچ کدی وجود ندارد. هدف این است که بدون وارد شدن به عمق جزئیات فنی برنامه نویسی، تست کردن و مدیریت، یک مرور کلی از هدف اصلی توسعه نرم افزار Agile ارائه دهد. این کتاب، کتابی کوچک است. به این دلیل که Agile مبحث خیلی بزرگی نیست. Agile ایده‌ی کوچکی در مورد مشکل کوچک تیم‌های برنامه نویسی کوچک است که کارهای کوچک انجام می‌دهند. Agile در مورد مشکل بزرگ تیم‌های بزرگ برنامه نویسی که کارهای بزرگی انجام می‌دهند، ایده بزرگی نیست. تا حدی عجیب است که این راه حل کوچک برای یک مشکل کوچک نامی دارد. با این همه، تقریباً به محض اختراع نرم افزار، مشکل کوچک مورد بحث، در دهه 50 و 60 حل شد. در آن روزها، تیم‌های نرم افزاری کوچک یاد گرفتند که کارهای کوچک را به خوبی انجام دهند. با این حال، همه اینها در دهه 1970 از بین رفتند، وقتی که تیم‌های نرم افزاری کوچک که کارهای کوچک انجام می‌دادند، همه درگیر یک ایدئولوژی شدند و تصور کردند که باید با تیم‌های بزرگ کارهای بزرگی انجام داد.

آیا قرار نیست با تیم‌های بزرگ کارهای بزرگی انجام دهیم؟ خدایا نه! کارهای بزرگ توسط تیم‌های بزرگ انجام نمی‌شوند؛ کارهای بزرگ با همکاری تیمهای کوچک زیادی که کارهای کوچک بسیاری انجام می‌دهند انجام می‌شوند. این چیزی است که برنامه نویسان در دهه 50 و 60 به طور غریزی می‌دانستند. و این همان چیزی بود که در دهه 1970 فراموش شد. چرا فراموش شد؟ من گمان می‌کنم که دلیلش ناپیوستگی زمان بوده است. در دهه 1970، تعداد برنامه نویسان در جهان شروع به منفجر شدن کردند. پیش از آن، فقط چند هزار برنامه نویس در جهان وجود داشت. پس از آن، صدها هزار نفر بودند. اکنون این تعداد به یکصد میلیون نفر نزدیک شده است.

اولین برنامه نویسان در دهه 50 و 60 میلادی نوجوان نبودند. آنها در دهه‌های 30، 40 و 50 زندگی خود شروع به برنامه نویسی کردند. در دهه 1970، دقیقاً هنگامی که جمعیت برنامه نویسان در حال انفجار بود، آن پیرمردها داشتند بازنشست می‌شدند. بنابراین آموزش‌های لازم هرگز رخ نداد. درحالی که یک گروه جوان 20 و چند ساله وارد کار می‌شدند، افراد با تجربه نیز در حال ترک کار بودند و در نتیجه تجربه آنها به طور مؤثری منتقل نشد.برخی می‌گویند که این واقعه نوعی از دوره‌های تاریک را در برنامه نویسی آغاز کرده است. به مدت 30 سال، ما با این ایده که باید با تیم‌های بزرگ کارهای بزرگی انجام دهیم تلاش می‌کردیم، اما هیچ وقت نمی‌دانستیم که راز این بوده است که کارهای کوچک زیاد باید با تعداد زیادی از تیم‌های کوچک انجام شود.

برای کمک به محبوب کردن این ایده، ما این ایده را نامگذاری کردیم. ما آن را «چابک» نامیدیم. من این مقدمه را در روزهای اول سال 2019 نوشتم. تقریباً دو دهه از زمان راه اندازی مجدد سال 2000 می‌گذرد و به نظر من زمان راه اندازی مجدد دیگری فرا رسیده است. چرا؟ زیرا پیام ساده و کوچک Agile طی این سالها گنگ شده است. Agile با مفاهیمLean ، Kanban، LeSS، SAFe ، مدرن، ماهر و بسیاری موارد دیگر آمیخته شده است. این ایده‌های دیگر لزوما بد نیستند، اما پیام اصلی Agile نیستند. بنابراین وقت آن است که یک بار دیگر آنچه که پیشینیان ما در دهه‌های 50 و 60 و آنچه که ما در سال ۲۰۰۰ یاد گرفتیم به ما یادآوری شود. وقت آن است که به یاد بیاوریم که چابک واقعاً چیست.

در این کتاب، شما چیز جدیدی نخواهید یافت، هیچ چیز قابل توجه یا حیرت انگیزی، هیچ چیز انقلابی که الگو را بشکند. آنچه پیدا خواهید کرد بازگویی Agile به همان شکلی است که در سال ۲۰۰۰ گفته شد. اوه، Agile از دیدگاه دیگری گفته شده است، و ما در طی 20 سال گذشته چیزهایی آموخته ایم که آن‌ها را نیز آورده ام. اما در کل، پیام این کتاب پیام 2001 و پیام 1950 است. این یک پیام قدیمی است. این یک پیام واقعی است. این پیغامی است که راه حل کوچک برای مشکل کوچک تیم‌های نرم افزاری کوچک که کارهای کوچک انجام می‌دهند را در اختیار ما می‌گذارد.

اسکرام کار کرد! حداقل برای ما (منظورم مشتری فعلی من در استکهلم است که اسمش را نمیارم). امیدوارم که برای شما هم کار کند! شاید این کتاب در طول مسیر به شما کمک کند.

این اولین باری است که من یک متدولوژی توسعه (ببخشید، Ken، یک فریمورک) می‌بینم که خارج از کتاب هم درست کار می‌کند. همه‌ی ما از توسعه دهندگان و تست کننده‌ها گرفته تا مدیران با آن شاد و خوشحال هستیم. اسکرام به ما کمک کرد تا از شرایط سختی خارج شویم و ما را قادر ساخت تا به رغم آشفتگی بازار و کاهش کارکنان، تمرکز و حرکتمان را حفظ کنیم.

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

اصول، الگو‌ها و شیوه‌ها مهم هستند، ولی این افراد هستند که آن‌ها را به کار می‌بندند. همان طور Alistair Cockburn گفته است "فرایند و تکنولوژی بر روی خروجی پروژه از اثرات ثانویه هستند. آن چیزی که جزء اثرات اولیه تاثیر گذار بر پروژه است، افراد هستند."
ما نمی‌توانیم تیم‌های برنامه نویسان را مدیریت کنیم، به شرط آن که سیستم‌های ساخته شده از اجزای تشکیل شده توسط فرایند وجود داشته باشند. افراد واحد‌های برنامه نویسی plug-compatible نیستند. اگر می‌خواهیم که پروژه هایمان موفق شوند، ما باید تیم‌های خود سازمانده و  مشارکتی ایجاد کنیم.
شرکت هایی که به تشکیل چنین تیم هایی تشویق می‌کنند، مزیت رقابتی قابل توجهی نسبت به آن هایی که نگرششان این است که شرکت‌های توسعه نرم افزار چیزی بیش از یک شرکت درپیت نیست. یک تیم نرم افزاری خوب، قدرتمندترین نیروی توسعه نرم افزار است.

در این کتاب یک سری موارد مطالعاتی ارائه می‌شود که مبانی توسعه چابک و طراحی چابک را همراه مثال بیان کرده اند و به سرعت از مدل‌های UML به کدهای #C واقعی می‌رسند. فصل‌های ابتدایی اصول توسعه‌ی چابک را مطرح می‌کند، در حالی که در فصل‌های بعدی تکنیک‌های اثبات شده در عمل نشان داده می‌شود.
چه برنامه نویس #C باشید یا ویژوال بیسیک یا حتی برنامه نویس جاوا که در حال یادگیری #C باشید، مدیر توسعه نرم افزار و یا تحلیل گر تجاری باشید، کتاب Agile Principles, Patterns, and Practices in C# اولین کتابی است که شما باید برا ی یادگیری نرم افزار چابک مطالعه کنید و چگونگی به کاربردن آن در برنامه نویسی چارچوب NET. را بیاموزید.

در تئوری که پشت روش‌های چابک، مفاهیم زیادی وجود دارد، اما کتابی در بازار موجود نیست که مفاهیم شیوه‌های چابک را بیان کرده باشه و این شیوه‌های کاربردی را به صورت عملی در یک پروژه‌ی ASP.NET پیاده سازی کرده باشد؛ از جمله برآورد احتیاجات و مدیریت جنبه‌های مختلف پروژه.
Pro Agile .NET Development with SCRUM  از مراحل آغازین شروع پروژه، احتیاجات را جمع آوری می‌کند و محیط را آماده می‌کند. در طول فرآیند توسعه تا انتشار، از رویکرد چابکی تکراری (Agile Iterative) که SCRUM نام دارد، استفاده می‌شود.