اسکرام چارچوبی برای توسعه و حفظ محصولات پیچیده مانند نرم افزار است. 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 به شما نشان می‌دهد که چگونه نگاشت‌های داستانی متغیر، تیم شما را قادر می‌سازد تا در طول مراحل توسعه گفتگوهای بهتری درباره پروژه انجام دهند. تیم شما یاد خواهد گرفت تا به درکی مشترک از آن چه که شما کوشش می‌کنید تا بسازید برسد.

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

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

کتاب 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 برای یک سال، من کاملا تحت تاثیر قرار گرفتم تا در پروژه‌های جدید هم از آن به طور پیش فرض استفاده کنم مگر اینکه دلیل محکمی برای عدم استفاده از آن وجود داشته باشد.

Scrum بر مبنای چندین جز اصلی به نام‌های Values، principles و practices است که در مجموع فریم ورک Scrum را تشکیل می‌دهند.  سازمان هایی که از  Scrum  استفاده می‌کنند باید فریمورک Scrum را در تمامی بخش‌های سازمان خود مورد استفاده قرار دهند؛ اگرچه ممکن است که نتوان این کار را به یک باره در تمام سازمان انجام داد ولی حداقل تیم‌های جدید که از Scrum استفاده می‌کنند باید این کار را انجام دهند. سازمان‌ها وقتی که در حال انتخاب ترکیبی مناسب هستند تا Scrum خود را پیاده سازی کنند باید همیشه با فریمورک Scrum صادق باشند.
Essential Scrum ارزش ها، اصول و روش‌های اسکرام را با یک سری روش‌های آزمون و خطا که با یکدیگر سازگارند ولی در فریمورک اسکرام اجباری نیستند ترکیب کرده است. تعدادی از این روش‌ها برای موقعیت شما مناسب خواهد بود و بعضی دیگر نه. هر روشی احتیاج به بررسی دارد تا برای شرایط خاص شما تغییر پیدا کند.

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