تفکر ناب

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

اصول و تجربه هایی که بر تولید ناب، توسعه محصول ناب، خدمات ناب و تفکر ناب اعمال می شوند معمولا عمیق و گسترده هستند. اگرچه بدنه عمومی کار بزرگ است، اما لارمن و وود چارچوبی را برای تفکر نرم افزار ناب توصیف کرده اند که به موجب آن بسیاری از اصول و تجربه های اصلی را به متن نرم افزار قابل مدیریت ترجمه می کند. آن ها برای انجام این کار، تصویر «خانه تفکر ناب» را مجددا ارائه می کنند، به طوری که از خانه های ناب قبلی همانند تویوتا و ... الهام گرفته شده است. خانه نرم افزار ناب در شکل ذیل قابل مشاهده است.

خانه نرم افزار ناب شامل پنج جزء ذیل است:

• سقف، هدف: پایداری به تحویل ارزش سرعت می بخشد 
• ستون اول: به افراد احترام بگذارید 
• ستون دوم: بهبود مداوم 
• شالوده: حمایتِ مدیریت 
• محتویات: جریان توسعه محصول

(خانه نرم افزار ناب) 

سقف خانه ناب: پایداری به تحویل ارزش سرعت می بخشد

هدف ناب قابل مذاکره نیست: در کوتاه ترین زمان ممکن باید بتوانیم ارزش تحویلی به مشتری را حداکثر کنیم.

در ادامه، نحوی نگرش دیگران در این مورد بیان می‌شود:

 تایچی اوهنو: از زمانی که مشتری سفارشی را به ما می دهد تا زمانی که هزینه آن را دریافت کنیم، آنچه که انجام می دهیم این است که به محور زمان نگاه می‌کنیم تا آن را با کنار گذاشتن کارهای بدون ارزش افزوده کاهش دهیم.

 پوپن دیک: روشی برای تحویل بسیار سریع نرم افزار نیاز داریم تا مشتریان زمان کافی برای تغییر طرز فکر خود نداشته باشند.

لارمن و وود: بر روی چوب دستی متمرکز شوید نه بر روی دونده ها. «به جای اینکه به مشغول بودن افراد یا بهینه محلی فکر کنید بر روی جریان ارزش و نرخ ارزش/ اتلاف متمرکز شوید»

بنابراین، به نکات ذیل در مورد نیازمندی ها توجه می کنیم:

• بجای تمرکز بر روی افراد یا سازمان هایی که نیازمندی ها را مدیریت می کنند، بر روی نیازمندی های مشتری متمرکز می شویم.
•  فعالیت های بدون ارزش افزوده را کشف می‌ کنیم و آن‌ها را فعالانه به حداقل می‌رسانیم.

 از دیدگاه نیازمندی های نرم افزار می توانیم «زنجیره ارزش» تحویل نرم فزار سازمان را همانند شکل ذیل نمایش دهیم.

برای بهینه کردن زمان تحویل و بازگشت سرمایه باید گام های موجود در زنجیره ارزش را بهینه کنیم. همچنین برای افزایش واقعی سرعت باید تمام تاخیرهای موجود در زنجیره ارزش را به حداقل برسانیم.

ستون اول خانه ناب: به افراد احترام بگذارید

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

ستون دوم خانه ناب: بهبود مداوم

بهبود مداوم یا «کایزن» ستون دوم ناب است. با کایزن، از طریق بازبینی و بهبود مداوم به سوی یک سازمان یادگیرنده هدایت می شویم. 

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

شالوده خانه ناب: حمایتِ مدیریت

حمایتِ مدیریت شالوده تفکر ناب است. در حقیقت، «حمایت» واژه مناسبی نیست تا به وسیله آن نقش اصلی و فعال مدیریت در پیاده سازی و هدایت ناب توصیف گردد. واژه «رهبری» ممکن است انتخاب بهتری باشد. در ناب، مدیریت با به کارگیری تجربه ها و ابزارهای تفکر ناب و بهبود مداوم، اعمال همیشگی آن ها و تعلیم به کارمندان، آموزش می بیند.

در این مورد، ناب از بیشتر تجربه های ما در توسعه چابک فاصله می گیرد. براساس تجربه‌ای که داریم، چابک اغلب به صورت فرایند تیم محور ترویج پیدا کرده است و در بدترین حالت تمایل به کنار گذاشتن مدیریت از فرایند و تجربه های اصلی را دارد. البته، کنار گذاشتن مدیریت از مشارکت و حل مسئله رویکرد مناسبی نیست. موارد ذیل تفاوت های میان چابک و ناب را بیان میکنند:

• در چابک، انتظار داریم مدیریت ما را حمایت کند و در برطرف کردن موانع کمک نماید. 
• در ناب، انتظار می رود که مدیریت ما را رهبری کند و نقش فعالی را در انجام بهبود مداوم بازی نماید.

این اصل مهم برای ناب هدایت کننده ای با اهمیت در سازمان نرم افزاری است. مدیران و هیئت رئیسه به جای پیگیری، رهبری می کنند و برای پیشبرد مداوم تجربه ها پاسخگو هستند.

محتویات خانه ناب: اصول جریان توسعه محصول

در مرکز خانه نرم افزار ناب اصول و تجربه هایی قرار دارند که توسط تیم برای توسعه و تحویل نرم افزار به کاربران پایانی استفاده می شوند. برای انجام این کار تنها یک روش درست وجود ندارد بلکه کتاب هایی هستند که دیدگاه های مختلفی را فراهم می‌کنند. در کتاب «اصول جریان توسعه محصول» هشت موضوع مهم مطرح شده است که هر کدام توسط تعدادی اصول کمکی پشتیبانی می شوند. این موضوعات به همراه اصول مربوطه راهنمای جامعی برای ناب فراهم می‌کنند. از دیدگاه من، این بهترین و معمول‌ترین رویکر برای توصیف اصول ناب است که بر روی توسعه محصول اعمال می‌شود. همچنین، این اصول راهنمای عالی و با اهمیتی برای تیم توسعه نرم افزار است. این هشت موضوع شامل موارد ذیل هستند: 

• دید اقتصادی داشته باشید 
• به طور فعال صف ها را مدیریت نمایید 
• تغییرپذیری را درک نمایید و از آن بهره‌برداری کنید 
• اندازه  بسته ها را کاهش دهید 
• محدودیت های کار در جریان را اعمال کنید 
• جریان تحت عدم قطعیت را کنترل کنید(ریتم و همگام سازی) 
• بازخورد را تا حد ممکن سریع دریافت کنید 
• کنترل را نامتمرکز کنید

شکستن اپیک ها و ویژگی ها به داستان های کوچک تر

اپیک­ ها و ویژگی­ ها داستان­ های بزرگی هستند که قصد داریم برای کاربر انجام دهیم. اغلب این داستان­ های با ارزش و بزرگ را در طول فرایند استخراج کشف می­ کنیم و در بک ­لاگ قرار می ­دهیم. این داستان­ ها معمولا برای پیاده ­سازی در یک تکرار بزرگ­ اند و تیم آن ­ها را به داستان­ های کوچک ­تری می ­شکند تا پیاده­ سازی آن­ ها ممکن شود. مجموعه­ ای روتین برای شکستن اپیک­ ها و ویژگی ­ها وجود ندارد. اما می­ توانید از «ده الگوی رایج برای شکستن داستان­ های کاربر» استفاده کنید.

1- گام ­های گردش کار

گام­ های خاصی که کاربر برای انجام گردش کار طی می­ کند را شناسایی کنید و سپس گردش کار را به صورت تدریجی پیاده­ سازی کنید.

As a utility, I want to update and publish pricing programs to my customer.

• . . . I can publish pricing programs to the customer’s in-home display.
• . . . I can send a message to the customer’s web portal.
• . . . I can publish the pricing table to a customer’s smart thermostat.

 

2- متنوع بودن قاعده کسب و کار

در نگاه اول برخی داستان ­ها خیلی ساده به نظر می­ رسند. هر چند، گاهی اوقات قواعد کسب و کار نسبت به نگاه اول پیچیده ­تر و گسترده ­تر ظهور می­ کنند. در این مورد، برای کنترل پیچیدگی قاعده کسب و کار شاید تقسیم یک داستان به چندین داستان مفید باشد.

As a utility, I can sort customers by different demographics.

• . . . sort by ZIP code.
• . . . sort by home demographics.
• . . . sort by energy consumption.

3- تلاش عمده

گاهی اوقات داستان می ­تواند به چندین بخش شکسته شود به طوری که در ابتدا بیشترین تلاش باید بر روی یکی از آن بخش ­ها صرف شود. در مثالی که در ادامه آورده می ­شود، زیر ساخت پردازشی باید برای پشتیبانی داستان اول ساخته شود. پس از انجام داستان اول اضافه کردن کارکردهای بیشتر در آینده نسبتا ساده می­­ شود.

As a user, I want to be able to select/change my pricing program with my utility through my web portal.

• . . . I want to use time-of-use pricing.
• . . . I want to prepay for my energy.
• . . . I want to enroll in critical-peak pricing.

4- ساده/پیچیده

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

As a user, I basically want a fixed price, but I also want to be notified of critical-peak pricing events.

• . . . respond to the time and the duration of the criticalpeak pricing event.
• . . . respond to emergency events.

5- تنوع داده­ ها

تنوع داده­ ها و منابع داده­ ها، منبعی دیگر برای محدوده و پیچیدگی هستند. داستان­ هایی را در نظر بگیرید که به موقع پس از ساختن ساده ­ترین نسخه اضافه می­ کنید. مثال محلی ­سازی در اینجا آمده است:

As a utility, I can send messages to customers.

• . . . customers who want their messages:
• . . . in Spanish
• . . . in Arabic, and so on.

6- روش­ های ورود داده­ ها

گاهی اوقات پیچیدگی بجای اینکه در خود کارکرد باشد، در واسط کاربری است. در این مورد، ساده­ترین واسط کاربری ممکن را ایجاد کنید و سپس واسط کاربری غنی­ تری را بسازید.

As a user, I can view my energy consumption in various graphs.

• . . . using bar charts that compare weekly consumption.
• . . . in a comparison chart, so I can compare my usage to those who have the same or similar household demographics.

7- به تعویق انداختن کیفیت ­های سیستم

گاهی اوقات، پیاده ­سازی اولیه خیلی سخت نیست و بخش عمده تلاش برای افزایش سرعت، افزایش قابل اطمینان، دقیق ­تر و قابل مقیاس کردن آن صرف می ­شود. هر چند، تیم می­تواند از پیاده ­سازی ابتدایی چیزهای زیادی یاد بگیرد و آن باید برای کاربر ارزش ایجاد کند. در این مورد، داستان را به کیفیت ­های متوالی تقسیم می­ کنیم.

As a user, I want to see real-time consumption from my meter.

• . . . interpolate data from the last known reading.
• . . . display real-time data from the meter.

8- عملیات­ (به عنوان مثال: ایجاد، خواندن، به روز رسانی و حذف کردن)

کلماتی همانند «مدیریت» و «کنترل» نشان می ­دهند که داستان چندین عملیات را پوشش می ­دهد. در این حالت می­ توانیم یک روش طبیعی برای تقسیم داستان پیشنهاد کنیم.

As a user, I can manage my account.

• . . . I can sign up for an account.
• . . . I can edit my account settings.
• . . . I can cancel my account.
• . . . I can add more devices to my account.

9- سناریوهای مورد کاربرد

اگر موارد کاربرد ایجاد شده­ اند تا تعامل پیچیده­ بین کاربر با سیستم یا سیستم با سیستم را نشان ­دهند، در این حالت می­ توان داستان را براساس سناریوهای منفرد مورد کاربرد به داستان­ های کوچک ­تر شکست.

I want to enroll in the energy savings program through a retail distributor.

• Use case/story #1 (happy path): Notify utility that consumer has equipment.
• Use case/story #2: Utility provisions equipment and data and notifies consumer.
• Use case/story #3 (alternate scenario): Handle data validation errors.

10- انجام اسپایک

در برخی موارد، داستان ممکن است خیلی بزرگ یا خیلی پیچیده باشد و یا شاید درک کمی در مورد پیاده­ سازی آن وجود داشته باشد. در این مورد، از اسپایک فنی یا کارکردی استفاده می ­شود و سپس براساس نتیجه بدست آمده داستان شکسته می ­شود.

مدل نیازمندیهای SAFe

برای این که سازمان های بزرگ تر از مزایای توسعه ناب و چابک بهره مند شوند- یا کسب و کارهای کوچک تر که سیستم های بسیار پیچیده ای می سازند- SAFe مدل نیازمندیهای مقیاس پذیری را ارائه می دهد که روش بیان کردن رفتارهای سیستم را نشان می دهد: اپیک ها، قابلیت ها، ویژگی ها، داستان ها، نیازمندی های غیر کارکردی (NFRs) و موارد بیشتر. همان گونه که شکل ذیل نمایش می دهد، هر یک از این قلم های کاری با روش های متفاوتی بیان می شوند.

برای مثال، ویژگی توسط یک عبارت، فرضیه منفعت (benefit hypothesis) و معیار پذیرش توصیف می شود؛ یک داستان توسط گزاره صدای کاربر و معیار پذیرش تشریح می شود. 

این دستاوردها عمدتا مشخصات سیستم و نیازمندی های سنتی را با الگوهای جدید مبتنی بر توسعه ناب-چابک جایگزین می کنند. این مثال ها همچنان قصد دارند تیم ها را کمک کنند تا از تمرکز زود هنگام بر روی راه حل و انتخاب نیازمندی ها و طراحی دقیق در آغاز فرایند یادگیری اجتناب کنند. 

همچنین، الگوها و رابطه هایی برای خصیصه ها، رهنمودهای پذیرش و آزمون در راستای پشتیبانی از نیازمندی های غیرکارکردی که بر روی سیستم های بسیار مهم دنیا تحمیل می شوند در نظر گرفته شده است. 

در کل، این یک مدل جامعی است، همان گونه که شکل بالا نشان می دهد.

بسیاری از متخصصان فقط به بخشی از این قلم ها نیاز دارند. برای مثال، تیم های چابک عمدتا داستان های کاربر، آزمون های پذیرش داستان و نیازمندی های غیرکارکردی (NFRs) را استفاده می کنند. با این وجود، هر جزء برای تامین کردن مقدار درستی از عبارت رفتار و آزمون در سطوح مختلف SAFe طراحی شده است..

پیچیدگی مدل به این دلیل است که توسعه سیستم ها و نرم افزارهای مدرن در مقیاس دشوار است، حتی با روش های چابک. اگر یک جزء مورد نیاز نیست، پس نیاز نیست استفاده شود. با وجود این، تیم ها و برنامه هایی که در حال ساخت راه حل های سازمانی در سطح جهانی با بالاترین کیفیت ممکن هستند احتمالا می توانند اکثر این اجزاء را استفاده کنند.

آزمون های واحد

برای تضمین بیشتر کیفیت، می توان از «آزمون های واحد» نیز استفاده کرد. همان طوری که در شکل ذیل قابل مشاهده است. آزمون های واحد برای تایید کار پایین ترین سطح ماژول برنامه کاربردی (یک کلاس یا متد در برنامه نویسی شی گرا؛ یک تابع یا رویه در برنامه نویسی ساخت یافته) مطابق با آن چه که موردنظر است، مورد استفاده قرار می گیرند. آزمون های واحد توسط توسعه دهنده برای آزمون کدی نوشته می شوند که منطق ماژول موردنظر را اجرا می کنند. در توسعه آزمون محور (TDD)، آزمون قبل از کد نوشته می شود. در هر صورت، آزمون باید در داخل یک چارچوب آزمون خودکار ساخته شود و تا زمانی که داستان آن را پشت سر نگذاشته است به عنوان «انجام شده» در نظر گرفته نمی شود. تیم های چابک بالغ تجربه های گسترده ای را برای آزمون واحد و آزمون کارکردی (پذیرش داستان) خودکار فراهم می کنند.

آزمون های پذیرش

ادامه پست قبل ...

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

• در ارتباط یک به چند (*..1)، هر داستان یک یا بیش از یک آزمون پذیرش دارد. 
• داستان زمانی «انجام شده» تلقی می گردد که آزمون پذیرش را با موفقیت گذرانده باشد. در غیر این صورت به عنوان «انجام نشده» در نظر گرفته می شود. 

آزمون های پذیرش، آزمون های کارکردی هستند که پیاده سازی داستان براساس معیارهای مورد نظر را بررسی می کنند. برای اجتناب از ایجاد حجم زیاد آزمون های دستی که ممکن است سرعت تیم را کاهش دهد، تا حد ممکن آزمون های پذیرش داستان خودکار می شوند.

(هر داستان دارای یک یا بیش از یک آزمون پذیرش است)

سه اصطلاح «کارت»، «گفتگو» و «تایید» برای توصیف داستان ها

ران جفریز، یکی از ایجاد کننده های ایکس پی، از سه اصطلاح «کارت»، «گفتگو» و «تایید» برای توصیف داستان ها استفاده می کند. این سه جزء در ادامه توضیح داده می شوند:

کارت: نمایش دهنده دو یا سه جمله ای است که برای توصیف هدف داستان استفاده می شود. 

گفتگو: جزئیات هدف کارت که در گفتگوی با مشتری یا مالک محصول کشف می شود را نمایش می دهد. به عبارت دیگر، کارت همچنین «قولی برای گفتگو» درباره هدف را نشان می دهد. 

تایید: این که چگونه تیم، از طریق مشتری یا نماینده مشتری، متوجه می شود که کد نوشته شده هدف کامل داستان را برآورده می کند، توسط این جزء نمایش داده می شود.

وظیفه ها

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

وظیفه واحد کوچکی از کار است که برای تکمیل داستان ضروری است.

وظیفه ها یک مالک دارند (شخصی که مسئولیت انجام وظیفه را برعهده می گیرد) و با واحد ساعت برآورد می شوند (معمولا 4 تا 8 ساعت). میزان ساعت باقی مانده (تکمیل شده) وظیفه به نوعی وضعیت تکرار را نمایش می دهد. هر داستان می تواند یک یا بیش از یک وظیفه داشته باشد و هر وظیفه حداکثر به یک داستان تعلق دارد و همچنین ممکن است به هیچ داستانی تعلق نداشته باشد. در بیشتر موارد، وظیفه ها «بچه های» داستان مربوط به خود هستند (با حذف داستان پدر، وظیفه ها نیز حذف می شوند). همچنین، مدل وظیفه های مستقل و وظیفه هایی که برای سایر اهداف تیم استفاده می شوند را برای افزایش انعطاف پذیری پشتیبانی می کند.

تشریح داستان

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

• نمودارهای فعالیت
• گزارش های نمونه
• شبه کد
• جداول تصمیم گیری و درختان تصمیم
• نمودارهای وضعیت
• نمودارهای توالی
• نمودارهای موجودیت-ارتباط
• مواردکاربرد

مدل سازی چابک چیست؟

تحلیل گران و مدل سازان با تجربه راز مدل سازی را می دانند:

هدف از مدل سازی اساسا برای فهمیدن است نه برای مستند کردن.

یعنی، عمل مدل سازی باید روشی را برای فهم بهتر فضای مساله و راه حل فراهم کند. از این رو، استفاده از زبان مدل سازی UML برای این نیست که طراح نمودارهای UML مفصلی را ایجاد کند و به برنامه نویس تحویل دهد تا آن ها را پیاده سازی کند، بلکه هدف از آن بررسی سریع روش های متفاوت و حرکت در جهت طراحی خوب است. این دیدگاه که با روش های چابک سازگار است در کتاب Agile Modeling: Scott Ambler «مدل سازی چابک» نامیده می شود.

مبانی داستان کاربر

داستان های کاربر جایگزین چابک برای چیزهایی هستند که به طور سنتی به آن ها عبارت های نیازمندهای نرم‌افزار گفته می شود (یا مواردکاربرد در RUP و UML). در ابتدا توسط ایکس پی معرفی شده‌اند و اکنون به طور کلی مختص توسعه چابک هستند و در بسیاری از کلاس های اسکرام آموزش داده می شوند. داستان کاربر به صورت ذیل تعریف می شود:

داستان کاربر عبارت خلاصه ای از هدف است که آن چه سیستم باید برای کاربر انجام دهد را توصیف می کند.

داستان کاربر معمولا در الگوی ذیل بیان می شود:

به عنوان <نقش کاربر>، من می توانم <فعالیت> برای اینکه <ارزش کسب و کار>.

در این الگو، داستان های کاربر به صورت ترکیبی از فضای مسئله (ارزش کسب و کار تحویل شده)، نقش کاربر (یا اشخاص) و فضای راه حل (فعالیتی که کاربر با سیستم انجام می دهد) دیده می شوند.