خانه / برنامه نویسی / آشنایی با متدولوژی اسکرام | بلاگ Quera

آشنایی با متدولوژی اسکرام | بلاگ Quera

اسکرام چیست؟

در این مطلب به بررسی چارچوب اسکرام با تکیه بر یادداشت‌های آقای Michael James در سایت scrummethodology می‌پردازیم.

اسکرام یک چارچوب تولید نرم‌افزار از سری روش‌های تفکر چابک (Agile) می‌باشد. چارچوب یا فرآیند؟ مسئله این است، دراین‌باره بین متخصصان اسکرام اختلاف زیادی وجود دارد. اشخاصی مانند
Ken Schwober دائماً از لفظ چارچوب (framework) استفاده می‌کنند و اسکرام را چارچوب می‌دانند ولی بعضی دیگراز لفظ فرآیند یا متدولوژی برای اسکرام استفاده می‌کنند.

تاریخچه اسکرام

این روش در سال ۱۹۸۶ توسط هیروتاکا تاکوچی و ایکوجیرو نوناکا به عنوان یک خط مشی جدید برای تولید نرم‌افزارهای تجاری که باید قابلیت سرعت در تولید و انعطاف‌پذیری را داشته باشند، عرضه گردید. اسم اسکرام از یک نوع بازی در فوتبال راگبی آمده است.

اسکرام (Scrum) یک متدولوژی افزایشی (Incremental) برای مدیریت پروژه‌های نرم‌افزاری است و از رده متدولوژی‌های Agile محسوب می‌شود. این متدولوژی اولین بار در ژاپن اختراع شد و بعدها در سال ۱۹۹۱ توسط Stahl و Degrace توسعه داده شد. در سال ۱۹۹۵ این متدولوژی توسط Ken Schwober و Jeff Stherland به عنوان یک متدولوژی رسمی برای تولید نرم‌افزار بکار گرفته شد.

چارچوبی تجربی برای یادگیری، نه یک متدولوژی!

Agile پاسخی به شکست پارادایم های غالب در مدیریت پروژه های توسعه نرم افزار (شامل روش آبشاری) است و از بسیاری از اصول‌های تولید ناب ( lean manufacturing) بهره می‌برد. در سال ۲۰۰۱، ۱۷ استاد در روش های مشابه در محل پیست اسکی اسنوبورد در یوتا یکدیگر را ملاقات کردند و بیانه‌ی Agile را نوشتند که شرح چهار ارزش و دوازده اصل بود. این اصول و ارزش ها در تضاد شدیدی با پیکره‌ی دانش مدیریت (PMBOK) قرار دارد. بیانه‌ی Agile روی ارتباط و همکاری، عملکرد نرم‌افزار، خودسازماندهی تیمی و انعطاف پذیری برای تطبیق با وقایع نوظهور تجارت، تاکید جدیدی کرده است.

چگونه اسکرام با Agile تناسب پیدا می‌کند؟

Agile مراحل واقعی و قابل لمسی ارائه نمی کند. سازمان‌ها معمولا به دنبال روش‌های مشخص‌تری در قالب تحرک چابک هستند. این روش ها شامل Crystal Clear ، Extreme Programming ، توسعه ی مبتنی بر قابلیت ، توسعه ی پویای سیستم‌ها (DSDM)، اسکرام و دیگر روش ها می‌شود. من تمام روش‌های چابک را دوست دارم با این وجود، برای تیم من اسکرام آن روشی بود که باعث موفقیت‌های ابتدایی شد. تعریف ساده ی اسکرام به تیم ما استقلال لازم را داد تا بهترین کار‌مان را انجام دهیم و به رئیس خود (که تبدیل به صاحب محصول ما شد) کمک کنیم تا به نتیجه‌ای که می‌خواست برسد. از آن موقع ما به کسب و کار ها کمک کرده ایم تا از اسکرام استفاده کنند تا چابک‌تر شوند. یک شرکت چابک اصولی سمت فنی یا تجاری ندارد. تیم‌هایی دارد که مستقیما کار می‌کنند تا ارزش تجاری ارائه دهند. ما وقتی بهترین نتیجه را می‌گیریم که کل کسب و کار را در این کار درگیر کنیم.

فلسفه‌ی پشت اسکرام چیست؟

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

‌نقش‌های اسکرام

نقش‌های عمده در اسکرام عبارتند از:

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

اسکرام مستر (Scrum Master) : اسکرام مستر در نقش یک تسهیل کننده برای صاحب محصول و تیم ظاهر می‌شود. اسکرام مستر تیم را مدیریت نمی‌کند. او کار می‎کند تا هر مانعی که ممکن است جلوی رسیدن تیم به اهداف sprint را بگیرد، برطرف کند. این کار به تیم کمک می‌کند تا خلاق و مولد باقی بماند در حالی که مطمئن است موفقیت‌ها برای صاحب محصول قابل مشاهده است. اسکرام مستر همچنین توصیه‌های لازم برای به حداکثر رساندن بازده سرمایه گذاری (ROI) تیم را به صاحب محصول می‌کند.

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

توسعه‌ی چابک مقیاس پذیر

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

جمع‌بندی از روند کاری اسکرام

در طی یک Sprint که معمولاً یک دوره دو تا چهار هفته است (طول دوره را تیم مشخص می‌کند) اعضاء همگی روی تولید یک محصول کار می‌کنند.

اصطلاح Product Backlog نامی است که به بانک اطلاعاتی نیازمندهای عملیاتی و غیر عملیاتی کل یک پروژه اطلاق می‌شود و در حقیقت مجموعه‌ای اولویت بندی شده از نیازمندی‌های سطح بالای سیستمی است که در نهایت بایستی تحویل داده شود.

مواردی از Product Backlog که در طی یک sprint بایستی انجام شود در طول جلسه طراحی اسپرینت یا Sprint Planning Meeting مشخص می‌شود. در طول این جلسه، Product Owner اعضاء تیم را دربارهٔ مواردی از Product Backlog آگاه می‌کند. سپس اعضاء تیم مشخص می‌کنند که چه مقدار از موارد مشخص شده توسط Product Owner را می‌توانند در این sprint انجام دهند و چه میزان از آن را در sprintهای بعدی.

مواردی از Product Backlog که قرار است در یک Sprint انجام شود را اصطلاحاْ Sprint Backlog می‌نامند. مفاد Sprint Backlog در واقع توافقی است بین اعضاء تیم و Product Owner که بعد از تصویب شدن مفاد یک sprint، هیچکس نمی‌تواند آن را در طول sprint تغییر دهد. در طول دوره، نیازمندی‌های لحاظ شده در Sprint Backlog از Product Backlog حذف می‌شوند. اما امکان دارد به دلایلی که در ادامه می‌آید این نیازمندی‌های دوباره به Product Backlog برگردد.

در اسکرام Time Boxed وجود دارد، به این معنی که sprint بایستی دقیقاً سروقت تمام شود و اگر نیازمندی‌های اشاره شده در Sprint Backlog به هرعلتی تکمیل نشده باشند آن‌ها را کنار گذاشته و دوباره وارد Product Backlog می‌کنند.

بعد از خاتمه یک sprint، اعضاء تیم طی جلسه‌ای به Product Owner و سایر ذینفعان پروژه نشان می‌دهند که چکار کرده‌اند و چطور از نسخه جاری نرم‌افزار می‌شود استفاده کرد.

در ساده‌ترین روش معمولاً از نرم‌افزارهای صفحه گستره (Spread Sheet) همچون LibreOffice Calc یا Microsoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می‌شود، اما می‌توان از طیف وسیعی از ابزارهای نرم‌افزاری که برای استفاده در تیمهای Agile نوشته شده‌اند نیز استفاده کرد.

یادگیری بیشتر

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

منبع


لينک منبع

درباره ی admin

همچنین ببینید

آشنایی با آردوینو (Arduino) و ایجاد پروژه های تعاملی – گیت

هنگامی که Massimo Banzi آردوینو را در سال ۲۰۰۵ طرحی کرد فکرش را نمی کرد که …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *