نوشته های آرش اصلاح کن

روش CALMS در DEVOPS

آرش اصلاح کن — Sun, 16 Aug 2026 21:49:51 +0330

در سال‌های اخیر، سازمان‌ها بیش از هر زمان دیگری به ارائه سریع، پایدار و باکیفیت نرم‌افزار وابسته شده‌اند. با این حال، در بسیاری از ساختارهای سنتی فناوری اطلاعات، تیم‌های توسعه نرم‌افزار (Development) و عملیات زیرساخت و بهره‌برداری (Operations) به‌صورت جداگانه فعالیت می‌کردند.تیم توسعه معمولاً بر تحویل سریع قابلیت‌های جدید تمرکز دارد، در حالی‌که تیم عملیات مسئول پایداری، امنیت، دسترس‌پذیری و کاهش ریسک سامانه‌هاست. این تفاوت در اولویت‌ها اغلب موجب شکل‌گیری شکاف ارتباطی، تأخیر در انتشار، خطاهای بیشتر و فرهنگ سرزنش میان تیم‌ها می‌شد.رویکرد DevOps برای کاهش این فاصله به وجود آمد. DevOps فقط مجموعه‌ای از ابزارها مانند Docker، Kubernetes، Ansible یا Jenkins نیست؛ بلکه یک فرهنگ، مدل همکاری و روش کاری مشترک میان توسعه، عملیات، امنیت، کیفیت و کسب‌وکار است.یکی از شناخته‌شده‌ترین مدل‌ها برای درک و پیاده‌سازی اصول DevOps، مدل CALMS است. CALMS کمک می‌کند DevOps را نه صرفاً به‌عنوان اتوماسیون، بلکه به‌عنوان یک تحول سازمانی و فرهنگی ببینیم.DevopsDevOps چیست و چرا به وجود آمد؟DevOps ترکیبی از دو واژه زیر است:Dev: توسعه نرم‌افزارOps: عملیات، نگهداری و بهره‌برداری از سامانه‌هاهدف اصلی DevOps ایجاد همکاری مستمر میان افراد، فرایندها و ابزارها برای تحویل سریع‌تر و قابل‌اعتمادتر نرم‌افزار است.در روش‌های سنتی، فرایند تحویل نرم‌افزار معمولاً به شکل زیر بود:تیم توسعه کد را تولید می‌کرد.کد به تیم تست تحویل داده می‌شد.پس از تأیید، تیم عملیات مسئول استقرار در محیط عملیاتی بود.در صورت بروز مشکل، مسئولیت میان تیم‌ها جابه‌جا می‌شد.انتشار نسخه‌های جدید زمان‌بر، پرریسک و اغلب دستی بود.این مدل چند مشکل اساسی ایجاد می‌کرد:زمان زیاد بین توسعه تا انتشار محصولوابستگی شدید به فرایندهای دستیاختلاف میان توسعه‌دهندگان و تیم عملیاتدشواری در تشخیص علت خطاهااستقرارهای پرریسک و با حجم تغییرات زیادنبود بازخورد سریع از محیط عملیاتیکاهش قابلیت اطمینان سرویس‌هاDevOps با تأکید بر همکاری، اتوماسیون، اندازه‌گیری، بهبود مستمر و اشتراک دانش، برای حل این چالش‌ها ایجاد شد.CALMS چیست؟CALMS یک چارچوب مفهومی برای ارزیابی بلوغ DevOps و پیاده‌سازی آن در سازمان است. این واژه از حروف ابتدایی پنج مؤلفه کلیدی تشکیل شده است:C Culture فرهنگA Automation اتوماسیونL Lean تفکر نابM Metrics معیارها و سنجه‌هاS Sharing اشتراک‌گذاریCALMSمدل CALMS بیان می‌کند که موفقیت DevOps فقط به انتخاب ابزار مناسب وابسته نیست. حتی اگر یک سازمان از ابزارهای پیشرفته CI/CD، کانتینر، مانیتورینگ و Infrastructure as Code استفاده کند، بدون فرهنگ همکاری، سنجه‌های درست و اشتراک دانش، DevOps به‌صورت واقعی شکل نخواهد گرفت.1. Culture — فرهنگفرهنگ؛ پایه اصلی DevOpsمهم‌ترین بخش مدل CALMS، Culture یا فرهنگ است. بسیاری از شکست‌های DevOps نه به دلیل ضعف فنی، بلکه به دلیل مقاومت فرهنگی، نبود اعتماد، ساختارهای جزیره‌ای و فرهنگ سرزنش رخ می‌دهند.در فرهنگ سنتی، تیم توسعه ممکن است بگوید:«کد روی سیستم من درست کار می‌کند.»و تیم عملیات پاسخ دهد:«این نرم‌افزار قابل اجرا یا نگهداری نیست.»DevOps تلاش می‌کند این ذهنیت را تغییر دهد. در فرهنگ DevOps، توسعه‌دهنده، تیم عملیات، امنیت، تست و سایر نقش‌ها همگی نسبت به نتیجه نهایی سرویس مسئولیت مشترک دارند.ویژگی‌های فرهنگ DevOpsفرهنگ DevOps معمولاً شامل موارد زیر است:مسئولیت مشترک: موفقیت یا شکست سرویس به یک تیم محدود نمی‌شود.اعتماد بین تیم‌ها: اعضا اطلاعات، تجربه و مشکلات را شفاف بیان می‌کنند.عدم سرزنش افراد: تمرکز بر علت ریشه‌ای مشکل است، نه مقصر یافتن.یادگیری از خطا: رخدادها و شکست‌ها فرصتی برای بهبود فرایندها هستند.همکاری بین‌تیمی: تیم‌ها از ابتدا در طراحی، توسعه، استقرار و نگهداری حضور دارند.شفافیت: وضعیت سامانه، رخدادها، تغییرات و معیارهای عملکرد برای افراد مرتبط قابل مشاهده است.مالکیت سرویس: تیم‌ها فقط کد تولید نمی‌کنند؛ بلکه مسئول کیفیت و رفتار آن در محیط واقعی نیز هستند.نمونه عملیپس از وقوع یک اختلال در سرویس، به جای پرسش:«چه کسی باعث این مشکل شد؟»سازمان DevOps می‌پرسد:«چه عامل سیستمی، فرایندی یا فنی باعث شد این خطا به محیط عملیاتی برسد و چگونه از تکرار آن جلوگیری کنیم؟»این رویکرد معمولاً در قالب جلسات Blameless Postmortem یا تحلیل رخداد بدون سرزنش اجرا می‌شود.2. Automation — اتوماسیوناتوماسیون؛ کاهش کارهای تکراری و خطای انسانیاتوماسیون دومین رکن CALMS است. هدف آن حذف یا کاهش فعالیت‌های دستی، تکراری، زمان‌بر و مستعد خطاست.در محیط‌های سنتی، بسیاری از فعالیت‌ها به‌صورت دستی انجام می‌شوند:نصب و پیکربندی سرورهاایجاد کاربران و سطح دسترسینصب وابستگی‌های نرم‌افزاریانتشار نسخه جدیداجرای تست‌هاتهیه نسخه پشتیبانبررسی وضعیت سرویس‌هاپاسخ به رخدادهای رایجاجرای دستی این فعالیت‌ها معمولاً باعث تفاوت بین محیط‌ها، وابستگی به افراد خاص و افزایش احتمال خطا می‌شود.حوزه‌های مهم اتوماسیون در DevOps1. اتوماسیون ساخت و تست نرم‌افزاربا استفاده از خطوط لوله CI/CD، هر تغییر در کد می‌تواند به‌صورت خودکار:Build شود.تست‌های واحد و یکپارچه روی آن اجرا شود.تحلیل کیفیت و امنیت کد انجام شود.در محیط آزمایشی مستقر شود.پس از تأیید، به محیط عملیاتی منتشر شود.ابزارهای متداول:GitLab CI/CDJenkinsGitHub ActionsAzure DevOps Pipelines2- روش Infrastructure as Codeدر این روش، زیرساخت مانند کد مدیریت می‌شود. به‌جای پیکربندی دستی سرورها، شبکه‌ها یا ماشین‌های مجازی، تنظیمات در فایل‌های نسخه‌بندی‌شده ثبت می‌شوند.ابزارهای رایج:AnsibleTerraformPulumiCloud-initHelmمزایای این رویکرد:تکرارپذیری پیکربندیکاهش خطای انسانیثبت تاریخچه تغییرات در Gitامکان بازبینی و تأیید تغییراتسرعت بیشتر در ایجاد محیط‌های جدید3. اتوماسیون استقراراستقرار نرم‌افزار باید تا حد امکان استاندارد، قابل تکرار و کم‌ریسک باشد. روش‌هایی مانند زیر به این هدف کمک می‌کنند:Rolling DeploymentBlue-Green DeploymentCanary DeploymentFeature FlagsRollback خودکار4. اتوماسیون عملیاتاتوماسیون فقط برای توسعه نیست. در عملیات نیز می‌توان موارد زیر را خودکار کرد:بررسی سلامت سرویس‌هاراه‌اندازی مجدد سرویس‌های دچار خطاتهیه بکاپاعمال Patchهای امنیتیمدیریت لاگ‌هاهشداردهیمقیاس‌پذیری خودکارCulture Automation Lean Measurement Sharing3. Lean — تفکر نابLean چیست؟Lean یا تفکر ناب، رویکردی است که بر حذف اتلاف، کاهش زمان انتظار، بهبود جریان کار و ارائه ارزش سریع‌تر به مشتری تمرکز دارد.در DevOps، تفکر ناب یعنی بررسی کنیم کدام فعالیت‌ها واقعاً برای کاربر یا کسب‌وکار ارزش ایجاد می‌کنند و کدام مراحل فقط باعث تأخیر، دوباره‌کاری یا پیچیدگی می‌شوند.نمونه‌هایی از اتلاف در فرایند تحویل نرم‌افزارموارد زیر معمولاً از مصادیق اتلاف هستند:انتظار طولانی برای تأیید انتشارتحویل دستی بین تیم‌هاتست‌های تکراری یا غیرضروریجلسات بدون خروجی مشخصاصلاح چندباره یک مشکل مشابهمستندسازی ناقص که نیاز به پرس‌وجوی مکرر ایجاد می‌کندمحیط‌های متفاوت توسعه، تست و تولیداستقرارهای بزرگ و کم‌تعدادوابستگی به دانش یک فرد خاصاصول Lean در DevOpsکاهش حجم تغییراتبه‌جای انتشارهای بزرگ و نادر، تغییرات کوچک‌تر و مکرر منتشر شوند. تغییرات کوچک:بررسی ساده‌تری دارند.ریسک پایین‌تری ایجاد می‌کنند.در صورت خطا، بازگردانی آن‌ها آسان‌تر است.علت رخدادها را ساده‌تر مشخص می‌کنند.کوتاه‌کردن حلقه بازخوردهرچه سریع‌تر از کاربران، تست‌ها، مانیتورینگ و محیط عملیاتی بازخورد دریافت شود، اصلاح خطاها نیز سریع‌تر انجام می‌شود.بهبود مستمرDevOps یک پروژه با نقطه پایان مشخص نیست. سازمان باید به شکل دائمی فرایندها را بررسی کند و بهبود دهد.مدلی رایج برای این کار چرخه زیر است:Plan→Do→Check→Actیعنی:برنامه‌ریزیاجرابررسی نتیجهاصلاح و بهبودمحدودسازی کارهای هم‌زماناگر افراد یا تیم‌ها هم‌زمان روی تعداد زیادی کار نیمه‌تمام کار کنند، زمان تحویل افزایش می‌یابد. Lean پیشنهاد می‌کند تعداد کارهای در حال انجام یا Work In Progress محدود شود تا تمرکز افزایش یابد.4. Metrics — معیارها و سنجه‌هاچرا اندازه‌گیری اهمیت دارد؟بدون داده و سنجه، نمی‌توان فهمید آیا DevOps واقعاً باعث بهبود شده است یا خیر. معیارها باید به سازمان کمک کنند تصمیم‌های مبتنی بر شواهد بگیرد، گلوگاه‌ها را شناسایی کند و تأثیر تغییرات را بسنجد.با این حال، هدف معیارها نباید کنترل یا مقایسه ناسالم افراد باشد. استفاده نادرست از سنجه‌ها ممکن است باعث رفتارهای ظاهراً خوب اما غیرواقعی شود؛ برای مثال، تیمی که فقط برای بهبود یک عدد، کیفیت واقعی را نادیده می‌گیرد.معیارهای کلیدی DevOpsمعیارهای معروف DevOps، که اغلب با عنوان DORA Metrics شناخته می‌شوند، عبارت‌اند از:1. Deployment Frequencyتعداد دفعاتی که یک تیم یا سازمان با موفقیت تغییرات را به محیط عملیاتی منتشر می‌کند.این معیار نشان می‌دهد فرایند تحویل تا چه اندازه سریع و قابل‌اعتماد است.2. Lead Time for Changesمدت‌زمان بین ثبت تغییر در کد تا اجرای موفقیت‌آمیز آن در محیط عملیاتی.هرچه این زمان کمتر باشد، سازمان سریع‌تر می‌تواند به نیازهای کسب‌وکار یا کاربران پاسخ دهد.3. Change Failure Rateدرصد تغییراتی که پس از استقرار باعث اختلال، Rollback، Hotfix یا نیاز به اصلاح فوری می‌شوند.این معیار تصویری از کیفیت و ایمنی فرایند انتشار ارائه می‌دهد.4. Time to Restore Serviceمدت‌زمان لازم برای بازیابی سرویس پس از یک رخداد یا اختلال.کاهش این زمان نشان می‌دهد سازمان در تشخیص، پاسخ و بازیابی از خطاها توانمندتر شده است.سنجه‌های عملیاتی دیگرعلاوه بر معیارهای DORA، سازمان‌ها می‌توانند شاخص‌های زیر را نیز اندازه‌گیری کنند:دسترس‌پذیری سرویس یا Availabilityزمان پاسخ‌گویی برنامهنرخ خطامصرف CPU، حافظه، Disk و شبکهتعداد رخدادهای امنیتیدرصد موفقیت Build و Deploymentپوشش تستتعداد Ticketهای باز و زمان حل آن‌هامیزان رضایت کاربران یا مشتریانهزینه زیرساخت و بهره‌وری منابعاصل مهم در استفاده از Metricsسنجه‌ها باید به بهبود سیستم کمک کنند، نه فشار آوردن به افراد. بنابراین بهتر است معیارها در سطح سرویس، فرایند و تیم تحلیل شوند؛ نه به‌عنوان ابزاری برای مقصرشناسی فردی.5. Sharing — اشتراک‌گذاریاشتراک دانش و مسئولیتآخرین مؤلفه CALMS، Sharing است. DevOps زمانی موفق می‌شود که دانش، مسئولیت، تجربه و بازخورد میان تیم‌ها جریان داشته باشد.در بسیاری از سازمان‌ها، دانش فنی در اختیار افراد یا تیم‌های محدود باقی می‌ماند. این وضعیت باعث ایجاد وابستگی، کندی در حل مشکلات و افزایش ریسک می‌شود.اشتراک‌گذاری در DevOps یعنی:توسعه‌دهندگان با مفاهیم عملیات و زیرساخت آشنا شوند.تیم عملیات در تصمیم‌های معماری و طراحی نرم‌افزار مشارکت کند.تیم امنیت از ابتدا در چرخه توسعه حضور داشته باشد.تجربه رخدادها و خطاها مستندسازی شود.مستندات به‌روزرسانی‌شده و قابل دسترسی باشند.موفقیت‌ها، شکست‌ها و درس‌آموخته‌ها میان تیم‌ها منتشر شوند.روش‌های عملی برای Sharingمستندسازی عملیاتیمستندات باید شامل مواردی مانند زیر باشند:معماری سرویسروش استقراروابستگی‌هاروش RollbackRunbook رخدادهاراهنمای عیب‌یابیاطلاعات مانیتورینگ و هشدارهاسیاست‌های Backup و Recoveryجلسات تحلیل رخدادپس از رخدادهای مهم، جلسه‌ای برای تحلیل علت ریشه‌ای برگزار می‌شود. خروجی این جلسه باید شامل موارد زیر باشد:چه اتفاقی افتاد؟چه زمانی رخ داد؟چه اثری بر کاربران داشت؟علت فنی و فرایندی چه بود؟چه اقداماتی برای جلوگیری از تکرار لازم است؟مسئول و زمان‌بندی هر اقدام چیست؟آموزش متقابلبرگزاری جلسات داخلی، ارائه‌های فنی، Pair Programming، Pair Troubleshooting و انتقال دانش بین تیم‌ها، وابستگی به افراد را کاهش می‌دهد.استفاده از مخازن مشترکمواردی مانند کد، فایل‌های Ansible، تنظیمات Kubernetes، Terraform، Runbookها و Pipelineها باید تا حد امکان در مخازن مشترک و نسخه‌بندی‌شده نگهداری شوند.ارتباط میان پنج مؤلفه CALMSپنج جزء CALMS مستقل از هم نیستند؛ بلکه یکدیگر را تقویت می‌کنند.برای مثال:بدون Culture، تیم‌ها ممکن است اتوماسیون را نپذیرند یا مسئولیت مشترک نداشته باشند.بدون Automation، سرعت و تکرارپذیری فرایندها محدود می‌ماند.بدون Lean، ممکن است اتوماسیون فقط یک فرایند ناکارآمد را سریع‌تر اجرا کند.بدون Metrics، سازمان نمی‌داند آیا واقعاً پیشرفت کرده است یا نه.بدون Sharing، دانش در سیلوهای جداگانه باقی می‌ماند و بهبود پایدار شکل نمی‌گیرد.بنابراین، CALMS را می‌توان یک مدل متوازن برای بلوغ DevOps دانست.جمع‌بندیDevOps رویکردی برای نزدیک‌کردن توسعه و عملیات با هدف تحویل سریع‌تر، پایدارتر و باکیفیت‌تر نرم‌افزار است. اما DevOps صرفاً نصب ابزارهای CI/CD، Docker، Kubernetes یا Ansible نیست. موفقیت واقعی آن به تغییر در فرهنگ سازمان، روش همکاری و نحوه تصمیم‌گیری وابسته است.مدل CALMS با پنج مؤلفه فرهنگ، اتوماسیون، تفکر ناب، معیارها و اشتراک‌گذاری، دیدی جامع برای درک و پیاده‌سازی DevOps ارائه می‌دهد.به‌طور خلاصه:Culture همکاری، اعتماد و مسئولیت مشترک ایجاد می‌کند.Automation کارهای دستی و خطاپذیر را کاهش می‌دهد.Lean اتلاف‌ها و گلوگاه‌های فرایند را حذف می‌کند.Metrics امکان تصمیم‌گیری مبتنی بر داده را فراهم می‌سازد.Sharing دانش و تجربه را در سراسر سازمان توزیع می‌کند.سازمانی که این پنج اصل را به‌صورت متوازن اجرا کند، می‌تواند تحویل نرم‌افزار و مدیریت سرویس‌های خود را سریع‌تر، امن‌تر، قابل‌اعتمادتر و پایدارتر انجام دهد.منابع :https://www.atlassian.com/devops/frameworks/calms-frameworkhttps://cloud.google.com/developers/doraKim, G., Humble, J., Debois, P., & Willis, J. The DevOps Handbook.Forsgren, N., Humble, J., & Kim, G. Accelerate.Allspaw, J. Blameless PostMortems and a Just Culture. Etsy Code as Craft.Poppendieck, M., & Poppendieck, T. Lean Software Development.Womack, J. P., & Jones, D. T. Lean Thinking.Humble, J., & Farley, D. Continuous Delivery.Beyer, B., et al. Site Reliability Engineering.

داستان کاربری (User Story)

آرش اصلاح کن — Wed, 17 Jul 2024 20:46:02 +0330

در توسعه نرم‌افزار چابک، داستان کاربر (User Story) توضیحی مختصر و ساده از یک ویژگی یا عملکرد است که از دیدگاه کاربر نوشته شده است. بسیاری از کارشناسان چابک (Agile) نیز یک داستان کاربر را به عنوان کوچکترین واحد کار توسعه محصول توصیف می کنند .داستان کاربر به شما می گوید که مخاطبان شما چه کسانی هستند، چه چیزی می خواهند و چرا؟داستان کاربر کمک میکند تا یک توصیف ساده از یک نیاز را در اختیار داشته باشیم.در داستان کاربر، تمرکز از روی نیازها برداشته شده و به تجربه کاربران و نظرات آن ها می پردازد.این وسوسه انگیز است که فکر کنیم داستان های کاربر در بیان ساده آن ، نیازمندی های سیستم نرم افزاری هستند. اما اینطور نیست.یکی از مؤلفه‌ های کلیدی توسعه نرم‌افزار چابک، قرار دادن افراد در اولویت است و داستان کاربر، کاربران نهایی را در مرکز گفتگو قرار می‌دهد. این داستان ها از زبان غیر فنی برای ارائه نیاز ها و کمبود های نرم افزار جهت استفاده توسط تیم توسعه به کار می روند. پس از خواندن داستان کاربر، تیم توسعه می‌داند که چرا می‌سازند، چه چیزی می‌سازند و چه ارزشی ایجاد می‌کند.داستان های کاربر یکی از اجزای اصلی یک برنامه چابک است. آنها به ارائه یک چارچوب متمرکز بر کاربر برای کار روزانه کمک می کنند که باعث ایجاد همکاری، خلاقیت و به طور کلی محصول بهتر می شود.با استفاده از روش داستان کاربر، با هزینه و زمان کمتر ، نمونه اولیه پلتفرم تولید می شود . سپس به سراغ تجربه و داستان های کاربران از پلتفرم می رود.نقص های ثبت شده و نیاز کاربران برای توسعه و گسترش پلتفرم شناسایی می شود و مجدد پلتفرم توسعه داده شده و بارگذاری می شود.به این صورت، داستان کاربر، باعث صرفه جویی در زمان تولید شده و سپس طبق نظرات کاربران اصلاح میشود و پیشرفت میکند. به همین شکل، داستان کاربر به تیم ها کمک میکند تا محصول باکیفیتی را سریع تر در دسترس کاربر قرار دهد که البته با سلیقه کاربر هم تناسب دارد.داستان های کاربر چابک چیست؟داستان کاربر روشی ساده برای پاسخگویی به سوالاتی از قبیل " چه کسی " ، چه چیزی ، " چرا " درباره محصول مورد نظر می باشد.این سوالات نیاز ها ، دلایل و سلایق کاربران را در استفاده از محصول و یا ویژگی خاصی از آن را بیان می کنند.این داستان ها کوتاه هستند و می بایست در زمان کمی نیاز کاربران و علت آن را بیان کنند.هدف یک داستان کاربر این است که بستر لازم برای ارزش سازی برای مشتریان را فراهم کند. توجه داشته باشید که «مشتریان» لزوما به معنای سنتی کاربران نهایی و بیرونی تعریف نمی شوند بلکه می توانند مشتریان داخلی یا همکارانی در سازمان شما باشند که به تیم شما وابسته هستند.این دست از داستان ها سازگاری کاملی با فریمورک‌ های مختلف مدیریت چابک مانند Scrum و Kanban دارند. در اسکرام، sprint ها است که تیم توسعه به سراغ داستان های کاربران می‌رود. در کانبان نیز، تیم‌ها داستان های کاربران را در BackLog محصول قرار داده و سپس از workflow خود موارد را پیگیری می کند.همین رسیدگی به داستان های کاربران است که باعث می‌شود تیم‌ های اسکرام قادر به دستیابی به تخمین‌های زمانی دقیق‌ تر، برنامه‌ریزی بهتر برای sprint ‌ها و چابکی هرچه بیشتر باشند. به لطف داستان ها، تیم‌ های کانبان می‌توانند نحوه رسیدگی به کارهای در جریان (Work-in-Progress یا به اختصار WIP) را بیاموزند و جریان کاری خود را بیش از پیش بهبود دهند.داستان های کاربران را ضمنا می‌توان بلوک‌ های سازنده فریمورک‌ های بزرگ‌ تر چابک مانند « اِپیک‌ها » (Epics) و « ابتکارها » (Initiatives) به حساب آورد. اپیک‌ ها وظایفی بزرگ‌ هستند که به مجموعه‌ ای از داستان ها تقسیم می‌شوند و از سوی دیگر، چندین اپیک با قرارگیری کنار یکدیگر، یک ابتکار را شکل می‌دهند. این ساختارهای بزرگ‌تر باعث حصول اطمینان از این می‌شوند که امور روزمره تیم توسعه در مسیر اهداف تعیین شده سازمان می باشد.داستان های کاربر دارای چندین مزیت کلیدی است:حفظ تمرکز بر نیاز کاربر : فهرست کارها (To Do List) ، تمرکز اعضای تیم را صرفا روی وظایفی که باید انجام شود نگه می دارد.اما مجموعه ای از داستان های کاربران تیم را به سمت حل مشکل کاربران واقعی و مسایل پیش آمده متمرکز می کند.داستان ها همکاری را امکان پذیر می کنند: با تعیین هدف نهایی ، تیم ها برای رسیدن به آن می توانند تعامل بهتر و تصمیم گیری جامع تری را با یکدیگر داشته باشند.داستان ها راه حل های خلاقانه را شکل می دهند: داستان ها ، تیم توسعه را مجبور به تفکر انتقادی و خلاقانه نسبت به نحوه رسیدگی به امور می‌کند.داستان ها شتاب ایجاد می کنند: هر داستان که توسط تیم توسعه به سرانجام می رسد پیروزی های کوچکی است که انگیزه و شتاب بیشتری را برای رسیدن به اهداف نهایی ایجاد می کند.چگونه یک داستان کاربر بنویسیم؟داستان‌های کاربر معمولاً از یک الگوی ساده پیروی می کنند:من به عنوان یک < نوع کاربر > ، < نیاز - هدف > را می خواهم تا < چند دلیل >.عموما داستان های کاربر غیر رسمی نوشته می شود تا تمرکز را از نوشتن درباره ویژگی‌ ها به بحث در مورد آن ها تغییر دهد. در واقع این بحث ها مهمتر از هر متنی است که نوشته شود.داستان کاربری تنها نیازهای ضروری را پاسخ می دهد:برای چه کسی طراحی شده؟ (Who)چه انتظاراتی از سیستم می رود؟ (What)چرا مهم است (اختیاری)؟ (Why)چه کسی داستان کاربران را می نویسد؟در ادامه میخواهیم درباره اینکه چه کسی باید داستان کاربران را بنویسد صحبت کنیم. آیا مالک محصول باید داستان کاربر را بنویسد یا هر کسی می تواند داستان های کاربری بنویسد.این مسئولیت مالک محصول است که اطمینان حاصل کند که یک داستان کاربر در BackLog محصول در سیستم چابک وجود داشته باشد تا خوراکی برای بحث وجود داشته باشد، اما این بدان معنا نیست که مالک محصول کسی است که آن ها را می نویسد. در طول یک پروژه چابک خوب، باید انتظار داشته باشید که داستان های کاربری توسط هر یک از اعضای تیم نوشته شود.نمونه هایی از داستان کاربران :به عنوان کاربر اپلیکیشن X ، می خواهم تمامی قبوض خودم را در یک سوپر اپلیکیشن پرداخت کنم تا بتوانم راحت تر امور مالی و بانکی خودم را مدیریت کنم.به عنوان کاربر بازدید کننده سایت ، می خواهم از کالاهای پر فروش و تخفیف دار زودتر باخبر شوم ، زیرا در حراج سفارش دادن برایم به صرفه است.به عنوان مسافر تاکسی اینترنتی ، می خواهم حق انتخاب در مدل خودروی کرایه شده خودم داشته باشم ، زیرا می خواهم به مهمانی مهمی بروم و آسایش ، تمیز بودن خودرو و یا جنسیت سفیر تاکسی برایم اهمیت دارد.منابع :1-https://www.atlassian.com/agile/project-management/user-stories2-https://karokasb.org/user-story