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

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

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

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

ما در پروژه ها یا مسئله های پیچیده به چند چیز یقین داریم:

۱- چیزی که مشتری درخواست داده یا آنچیزی که ما فکر می‌کنیم که مشتری به این قابلیت یا فیچر نیاز خواهد داشت با آنچیزی که واقعا نیاز دارد، معمولا متفاوت هست.

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

۳- موارد ۱ و ۲ باعث می شود که مطمئن شویم، که تغییر در مسئله های پیچیده، امری اجتناب ناپذیر بوده و به جای دوری از آن باید راهی پیدا کنیم که پذیرای آن باشیم.

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

به تفکر “پاسخگویی سریع به تغییرات” چابک یا چابکی گفته می شود.

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

اسکرام با استفاده از یک روش چرخشی افزایشی باعث کاهش ریسک و افزایش میزان پیش بینی پذیری می شود.

آیا ما “محصول درستی” می سازیم؟
آیا ما محصول را به “شیوه درستی” میسازیم؟

PO یا Product Owner یا مالک محصول نماینده گروه ذینفعان محصول است. PO  به عنوان یکی از نقش های اصلی در محیط اسکرام به حساب می آید . مسلما هر نقشی باید یک سری وظیفه داشته باشد که وظایف PO عبارت است از :

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

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

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

اما علاوه بر مالک محصول نقشی به نام تیم توسعه وجود دارد که کار او توسعه محصول مورد نظر خواهد بود. این تیم می تواند شامل تمام نقش های توسعه نرم افزار مانند برنامه نویس , تحلیل گر و طراح  DBA و … باشد. تیم در صورت وجود نفرات زیاد می تواند به چندین تیم مجزا نیز تقسیم شود. تعداد ۳-۹ نفر برای هر تیم ترجیح داده می شوند.

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

• Self-Organize یا خود سازمانده هستند:  از متد مدیریت Micromanagement   یا مدیریت دستور-کنترل برای این تیم ها استفاده نمی شود و این تیم ها خود-سازمانده است. در واقع به این تیم ها فقط گفته می شود که می خواهیم چه کاری انجام دهیم و چگونگی نحوه انجام به خود تیم سپرده شده است.
• Cross-Functional کار می کنند : تمامی تخصص های لازم در تیم وجود دارند که بدون وابستگی به بیرون از خودشان بتوانند یک محصول کارکننده را تولید، تست و ارائه کنند.

از جمله وظایف این نقش می توان به موارد زیر اشاره کرد :

• تعیین مقدار کاری که باید در طی یک اسپرینت (۲-۴ هفته) انجام دهند .
• چگونه باید کارها را انجام دهند .

اسپرینت در اسکرام همان چرخش‌هایی هست که بالاتر گفته شد. طول این چرخش‌ها معمولا در اسکرام بین ۲-۴ هفته است. در شروع هر اسپرینت مقداری درخواست مشتری (که معمولا به اسم User Story شناخته می شوند) با توجه به ظرفیت تیم (سرعت تیم یا  Velocity) انتخاب می شوند و در لیست بک لاگ اسپرینت قرار می گیرند. این لیست شامل تمام درخواست های مشتری می شود که تیم متعهد شده تا در این اسپرینت پیاده سازی کند.

برای اینکه بتوان میزان ظرفیت تیم را سنجید میتوان به هر داستان کاربر یک وزن داده شود . واحد این وزن Story Point است. اما درباره نحوه وزن دادن به هر داستان : ساده ترین درخواست مشتری را انتخاب کنید . به آن   Story Point 3 بدهید.  موارد دیگر باید بر اساس رابطه سختی آن ها با این داستان وزن دهی شوند. مورد بعدی را انتخاب کنید اگر دو برابر سخت تر از این داستان بود به آن ۵ و اگر کمی سخت بود به آن ۳ بدهید.

همانطور که در بالا ذکر شد “در شروع هر اسپرینت مقداری درخواست مشتری (User Story) با توجه به ظرفیت تیم انتخاب می شوند” . ظرفیت تیم همان سرعت تیم خوانده می شود . به عبارت ساده تر تیم در طی اسپرینت ۴ هفته ای چند Story point می تواند انجام بدهد؟ تعیین این میزان برای هر تیم به دو روش امکان دارد :

• تعیین ظرفیت اسپرینت با توجه به عملکرد تیم در اسپرینت های قبلی
• تعیین ظرفیت تیم بر اساس توان نیروی کار موجود و میزان توجه آن ها به کار

به طور خلاصه تیم بر اساس ظرفیت و یا سرعت خود و رعایت اولویت های مالک محصول تعدادی User Story  را از داخل بک لاگ محصول انتخاب و به داخل بک لاگ اسپرینت انتقال می دهد. این فعالیت در طی جلسه برنامه ریزی اسپرینت انجام و جلسه در ابتدای هر اسپرینت برگزار می شود.

در گام بعدی تیم شروع به پیاده سازی هر یک از اقلام موجود در بک لاگ اسپرینت خواهد کرد . برای اینکه اعضای تیم اعلام کنند که چه کاری را انجام داده اند و چه کاری را می خواهند انجام دهند جلسه ای با عنوان جلسه روزانه اسکرام و یا جلسه سرپایی روزانه در هر روز معمولا در شروع روز کاری به مدت حداکثر ۱۵ دقیقه برگزار می شود . در این جلسه هر کس ۳ سوال اصلی مطرح و به آن ها جواب می دهد :

• با توجه به هدف اسپرینت، دیروز چه کاری انجام دادم؟
• امروز چه کاری می خواهم انجام بدهم
• چه موانعی در پیش رو دارم و با چه موارد پیش بینی نشده ای برخورد کرده ام؟

طرح این سوالات برای ایجاد شفافیت و وضوح عملکرد تیم می باشد . این عمل باعث ژل شدن بیشتر تیم می‌شود.

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

آخرین جلسه بعد از اتمام هر اسپرینت , جلسه Scrum Retrospective یا بازبینی عملکرد است. این جلسه فرصتی با ارزش برای بهبود عملکرد تیم می باشد. در این جلسه عملکرد اسپرینت بررسی و برای آینده توافقی از نقاط بهبود استرخاج می شود. در این جلسه معمولا سوال هایی مانند زیر مطرح می شود :

• چه مواردی در اسپرینت قبل خوب بود؟
• کدامیک از عملکردهای ما نیاز به اصلاح دارد؟
• چه بهبودهایی را می توان برای آینده در نظر گرفت؟

بهبود های کشف شده در این جلسه ۲ ساعته به مرور در اسپرینت های بعدی اعمال می شوند.

علاوه بر خود تیم نقشی به نام Scrum master در داخل تیم اسکرام وجود دارد . همانطور که از عنوان این نقش قابل ملاحظه  است کار این نقش مدیریت پروسه اسکرام است. اولا او پروسه اسکرام را در سازمان کلید می زند و ثانیا کنترل می کند که آیا تیم و مالک محصول ,اسکرام را درست انجام می دهند؟ علاوه بر این ها وظیفه حذف موانع از سر تیم در راه فرآیند اسکرام نیز بر عهده اسکرام مستر است .برای هر تیم باید یک SM و یک PO مجزا وجود داشته باشد.

منبع: scrum.ir