توسعه نرم افزار به روش اسکرام

---

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

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

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

سال‌ها قبل از اینکه اسکرام به عنوان یکی از محبوب‌ترین اعضای خانواده توسعه نرم‌افزارهای چابک مطرح باشد، توسط پرفسور Hirotaka Takeuchi تدوین شده بود. آقای تاکچی، که علاوه بر تدریس در مدرسه کسب و کار هاروارد (HBS) یکی از 10 پروفوسور برتر در حوزه‌ی کسب و کار به انتخاب BusinessWeek است، از  اسکرام به عنوان "یک استراتژی منعطف و جامع برای توسعه محصول که در آن تمامی تیم‌های توسعه به عنوان یک واحد برای رسیدن به هدف مشترک عمل می‌کنند" نام برده بود. این اولین تعریف از مفهوم اسکرام در سال 1986 در حوزه‌ی توسعه محصول است.

در اوایل دهه 90، آقای کن شوئیبر اقدام به پیاده سازی و توسعه آنچه بعدها به نام فرآیند اسکرام شناخته شد، در شرکت خود کرد. Ken Schwaber چند سال بعد، به همراه آقای جف سادرلند برای اولین بار فرآیند توسعه نرم‌افزار اسکرام را در کنفرانس OOPSLA سال 1995 معرفی کردند. کن شوئیبر در سال 20011 یکی از اعضای موثر ایجاد بیانیه چابکی (The Agile Manifesto) بود. جف سادرلند بخش‌های مهمی از این بیانیه را نوشت.

عرصه جدید توسعه محصولات جدید – 1986

در مقاله‌ای که در ژانویه سال 1986 در مجله Harvard Business Review تحت عنوان The New New Product Development Game منتشر شد، Hirotaka Takeuchi و Ikujiro Nonakaاولین قدم‌های معرفی بنیان اسکرام نهاده شد. در این مقاله، شش ویژگی روش توسعه محصول جدید که در آمریکا و ژاپن در حال استفاده بود، ارایه شده است که عبارتند از:

1. بی ثباتی درونی - built-in instability
2. تیم‌های پروژه خود سازمانده - self-organizing project teams
3. فازهای توسعه هم پوشان - overlapping development phases
4. یادگیری متداوم - multilearning
5. کنترل نامحسوس - subtle control
6. انتقال دانش سازمانی

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

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

پس از معرفی رسمی اسکرام از سوی سادرلند و شوئیبر در کارگاره Business Object Design and Implementation که بخشی از رویداد OOPSLA '95 در شهر آستین بود، این دو نفر تلاش کردند تا این فرآیند را به عنوان روشی که امروزه به نام اسکرام می‌شناسیم به صنعت نرم‌افزار معرفی کنند. در سال 2001، شوئیبر به همراه مایک بِدل، در کتاب Agile Software Development with Scrum اسکرام را به  صورت مکتوب به عنوان یکی از روش‌های توسعه چابک معرفی کردند.

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

در سال‌های بعد، Scrum Alliance متولی توسعه اسکرام و همچنین برنامه‌های آموزشی و اعتبار سنجی مانندCertified Scrum Master بود. در سال 2009، Ken به عنوان یکی از اعضای اصلی Scrum Alliance این گروه را ترک کرد و با راه‌اندازی scrum.org تلاش کرد تا اصالت روش اسکرام را حفظ کند و آن‌را توسعه دهد.

نقش اعضای تیم در پروژه چابک اسکرام

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

صاحب محصول

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

مدیر اسکرام

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

تیم توسعه اسکرام

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

روابط متقابل بین سهام داران

3 سهام دار در قالب زیر به هم مرتبط هستند:

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

اسکرام بر پایه هم‌نوایی و نظم نهاده شده است. نظم و هماهنگی در رگ و ریشه انسان نهادینه شده است و آهنگ تپش قلب در عمیق‌ترین بخش‌‎های ذهن شنیده می‌شود. فطرت ما انسان‌ها همیشه به دنبال نظم و هم‌آهنگی در تمامی بخش‌های زندگی است. اما، آهنگ‌ها همیشه برای شادی و خوشی نیستند. ریتم و یکنواختی می‌تواند باعث تشدید عادت‌های بی‌دلیل و یا افسردگی و کرختی شود.

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

اسکرام چه می‌کند؟

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

برای اینکه بیشتر از میزان اسراف در کارها صحبت کرده باشیم، آماری که آقای جف سادرلند در کتاب Scrum: The Art of Doing Twice the Work in Half the Time مطرح کرده است، شاید جالب باشد. طبق اعلام ایشان، در بیشتر سازمان‎هایی که از سوی موسسه اسکرام مورد بررسی قرار گرفته‌اند، در حدود 85% کارها بدون نتیجه بوده‌اند و در بهترین حالت معمولا تنها به 60% از برنامه‌های از پیش تعیین شده رسیده‌اند.

پرهیز از اسراف

آقای تای‌ایچی اونو به عنوان بنیان‌گذار سیستم تولید تویوتا (Toyota Production System) در خصوص به هدر رفتن منابع و سرمایه‌ها می‌گوید: "اسراف بیشتر از آنکه زیان اقتصادی برای کسب و کارها باشد، جرمی است بر ضد جوامع". آنچه آقای Taiichi Ohno از آن به عنوان اسراف یاد می‌کند در فرهنگ ژاپنی شامل سه بخش می شود:

• موری – Muri: اسراف و زیان به دلیل عدم توجه به منطق
• مورا – Mura: اسرف و هدر رفتن به خاطر تناقض‌ها
• مودا – Muda: به هدر رفتن خروجی‌‌ها و دست‌آوردها

مبارزه با این اسراف‌ها و جلوگیری از زیان‌دهی با در نظر داشتن این سه مورد، بسیار شبیه چرخه دمینگ PDCA است. تصور کنید:

• برنامه ریزی (Plan) به معنی جلوگیری از موری
• انجام (Do) به معنی دوری از مورا
• بررسی (Check) به معنی پرهیز از مودا
• اقدام (Act) به معنی هدف گذاری، انگیزه و تشخیص

مهمترین هدف از پیاده سازی و استفاده از اسکرام، ترکیب چرخه‎‌های پیشرفت سودمند PDCA با عادت‌های معمول انسان و جلوگیری از اسراف و زیان‌دهی در منابع است.

در اسکرام هر پروژه به تعدادی اسپرینت معمولاً دو هفته‌ای، هر اسپرینت به تعداد Backlog Item یا PBI و هر PBI به تعداد Task یا SBT تقسیم می‌شود. هر PBII نمایانگر یکی از سناریوهای مشتری مثل «مدیریت کاربران» یا «پرداخت وام» است و معمولاً پیاده‌سازی آن ۲ تا ۳ روز طول می‌کشد. هر SBT هم معمولاً ۴ تا ۶ ساعت زمان می‌برد.

نوشته شده توسط :

وحید صمدیان



پنجشنبه, 30 دی 1395

تعداد بازديد : 1391

برچسب ها : تکنولوژی های طراحی وب