نیازمندیهای چابک

شما در این سایت با مفاهیم نیازمندیهای نرم افزار چابک آشنا می شوید

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

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

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

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

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

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

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

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

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

۰ نظر
علیرضا قاقالو

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

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

آزمون واحد

۰ نظر
علیرضا قاقالو

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

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

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

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

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


آزمون پذیرش

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

۰ نظر
علیرضا قاقالو

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

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

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

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

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

۰ نظر
علیرضا قاقالو

وظیفه ها

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

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

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

۰ نظر
علیرضا قاقالو

تشریح داستان

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

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

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

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

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

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

۰ نظر
علیرضا قاقالو

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

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

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

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

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

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

۰ نظر
علیرضا قاقالو

سطح تیم: بک لاگ

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

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

بک لاگ

(داستان ها و بک لاگ تیم)


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

داستان یک قلم کاری است که در بک لاگ تیم قرار می گیرد.

از دیدگاه مدل، «داستان یک نوع قلم بک لاگ» است.


۰ نظر
علیرضا قاقالو

سطح تیم: آزمون گران

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

  • هنگامی که کد نوشته شد، برای آن مورد آزمون پذیرش می نویسد
  • برای درک درست داستان و حصول اطمینان از اینکه آیا آزمون های پذیرش، کارکرد مورد نظر داستان را برآورده می کنند با توسعه دهنده و مالک محصول ارتباط برقرار می کند
  • داستان کاربر را متناسب با آزمون پذیرش نوشته شده، آزمون می کند
  • موارد آزمون را در مخزن مشترک ثبت می کند
۰ نظر
علیرضا قاقالو