روش های چابک

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

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

روش های چابک

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

  • نمودارهای فعالیت
  • گزارش های نمونه
  • شبه کد
  • جداول تصمیم گیری و درختان تصمیم
  • نمودارهای وضعیت
  • نمودارهای توالی
  • نمودارهای موجودیت-ارتباط
  • مواردکاربرد
۰ نظر ۲۶ آبان ۹۸ ، ۲۲:۲۷
علیرضا قاقالو

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

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

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

۰ نظر ۲۵ آبان ۹۸ ، ۲۳:۱۵
علیرضا قاقالو

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

«تحلیل» واژه گسترده ای است. بهترین کاربرد آن می تواند عبارت هایی از قبیل «تحلیل نیازمندی ها» (بررسی نیازمندی ها) یا «تحلیل شی گرا» (بررسی اشیا دامنه) باشند.

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

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

منبع: Applying UML and Patterns

نویسنده: Craig Larman

۰ نظر ۱۵ مهر ۹۸ ، ۱۸:۵۱
علیرضا قاقالو

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

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

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

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

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

۰ نظر ۳۰ شهریور ۹۸ ، ۲۱:۳۰
علیرضا قاقالو

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

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

بک لاگ

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


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

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

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

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

۰ نظر ۲۳ مرداد ۹۸ ، ۲۰:۱۱
علیرضا قاقالو

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

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

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

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

به علاوه، توسعه دهنده به طور فعال در بهبود محیط توسعه مشارکت می نماید.

۰ نظر ۱۸ مرداد ۹۸ ، ۱۷:۱۳
علیرضا قاقالو

اسکرام در مورد این نقش کاملا خاص است و برای افرادی که این نقش را برعهده می گیرند آموزش تخصصی و عنوان خاصی(استاد اسکرام) را

در نظر می گیرد. به طور خلاصه استاد اسکرام مسئول انجام کارهای ذیل می باشد:

  • پیشروی تیم به سوی هدف را تسهیل می کند
  • تیم را به سوی بهبود مداوم رهبری می کند
  • قواعد فرایند چابک را اجرایی می کند 
  • موانع را از بین می برد
۰ نظر ۱۸ مرداد ۹۸ ، ۱۶:۴۹
علیرضا قاقالو

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

  • برای تعیین نیازمندی ها با مدیران محصول، تحلیلگران کسب و کار، مشتریان و دیگر ذینفعان همکاری می کند. 
  • بگ لاگ محصول را نگهداری و اولویت ها را براساس ارزش نسبی کاربر مشخص می کند. 
  • اهداف تکرار را مشخص می نماید. 
  • داستان ها را تشریح می کند، در بررسی های پیشرفت مشارکت می نماید و داستان های جدید را می پذیرد.
۰ نظر ۰۳ مرداد ۹۸ ، ۱۱:۱۷
علیرضا قاقالو

سیلوهای کارکردی

(سازماندهی تیم ها به صورت سیلوهای کارکردی)

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

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

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

سازمندهی مجدد سیلوهای کارکردی به تیم های چابک

(سازماندهی مجدد سیلوهای کارکردی به تیم های چابک)

۰ نظر ۲۱ تیر ۹۸ ، ۱۵:۳۶
علیرضا قاقالو