فرز و چابک به سبک Scrum! (مقدمه)

Scrum که یکی از چارچوب‌ها یا همون framework‌های Agile محسوب میشه در واقع چارچوبی مدیریتی هست برای تولید و توسعه‌ی پروژه‌ها و محصولات خلاقانه! (البته خیلی جاها این خلاقانه رو میگن پروژه‌های پیچیده)

اصلاً اسکرام (Scrum) چیه؟ Agile چیه؟ قضیه چیه؟ چارچوب مدیریتی رو چه به شبکه؟؟؟ 😐

پاراگراف Bold شده‌ی بالا به همراه سوالاتی که مطرح شد، نقشه راه موضوعی هستن که قراره یه چند وقتی زیاد باهاش سر وکار داشته باشیم و به سراغش بریم 🙂

***

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

برای پیدا کردن جواب این چراها بیاین برگردیم به دهه‌ی 1990 میلادی، زمانی که این مشکلات خیلی خیلی بیشتر از حال حاضر بودن و ریشه‌‌‌ی این مشکلات و راهکارهایی که برای حلشون داده شد رو از اونجا رهگیری کنیم.

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

علتش هم واضح بود: زمانی که تأخیر زیادی تا تحویل محصول نهایی رخ بده، مطمئناً نیازهای بازار و مشتریان در طی این مدت تغییر می کنه. در نتیجه محصول نهایی دیگه اون چیزی نیست که مشتری می‌خواد.

برای مثال بیاین بریم سراغ حوزه‌ای در دنیای تکنولوژی که بیشتر باهاش آشنایی داریم یعنی حوزه‌ی نرم افزار و ببینیم در اون زمان اوضاعش چه شکلی بوده.

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

مشکل بزرگ مدل Waterfall تأخیر زمانی زیاد تا تحویل نهایی محصول بود. بنابراین این روش قادر نبود به فرآیند تولید سرعت ببخشه و عملاً نمی‌تونست پاسخگوی نیازهای دنیای صنعت باشه. همین مشکل باعث شد تا یک سری از رهبرای فکری دنیای نرم‌افزار (یه گروه هفده نفره)، در سال 2000 و بعدش 2001 دور هم جمع بشن و با معرفی یه فلسفه‌ی فکری و عملکردی جدید و انتشار یه بیانیه در رابطه با این فلسفه‌ی فکری، سعی کنن به این اوضاع نابه‌سامون اندکی سروسامون بدن.

این فلسفه‌ی فکری جدید Agile نام داشت و بیانیه‌ای که به معرفی ارزش‌های اون پرداخت تحت عنوان Agile Manifesto یا ارزش‌های Agile، منتشر شد.

ارزش‌های Agile یا Agile Manifesto

Agile بر اساس 4 ارزش پدید اومد:

1- برتری انسان‌ها یا همون اشخاص و تعاملات بر ابزارها و فرآیندها (Individuals and Interactions Over Processes and Tools):

در واقع این انسان‌ها هستن که به نیازهای دنیای کسب و کار پاسخ میدن و فرآیند توسعه رو هدایت می کنن. اگر عکس این موضوع اتفاق بیوفته، یعنی فرآیندها و ابزارها هدایت همه چیز رو در اختیار بگیرن، خوب قطعاً تیم انسانی هم کم‌تر پاسخگوی تغییرات و برآوردن نیازهای مشتریان خواهد بود.

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

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

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

تأکید Agile بر این هست که متخصص‌ها/تیم‌های مختلف درگیر در تولید و توسعه‌‌ی یک محصول باید مدام با هم در تعامل باشن و بدون هیچ نگرانی یا درگیری‌ای بتونن پیوسته با هم ارتباط داشته باشن و از نظرات هم استفاده کنن (حذف بروکراسی، حذف تک بعدی بودن افراد/تیم‌ها و متکی بودن تنها بر یک تخصص یا ابزار خاص)

2- اولویت نرم‌افزارها بر مستندات جامع (Working Software Over Comprehensive Documentation):

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

Agile مستندسازی رو حذف نمیکنه اما میگه باید اون رو کوتاه‎تر و بهینه‌ترش کرد. یعنی مستندات فقط شامل چیزایی باشن که نیازه توسعه‌دهنده بدونه تا بفهمه باید چه کاری رو انجام بده و درگیر جزییات نشه. مثل یه قصه‌ی کلی که از کاربر گرفته میشه تا توسعه‌دهنده بدونه کار ساخت یک function یا عملکرد جدید رو باید از کجا شروع کنه.

3- همکاری مداوم مشتری در طول تولید محصول به جای مذاکرات مقطعی (Customer Collaboration Over Contract Negotiation):

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

خب مشکلی که این روش داشت این بود که بعد از این که تیم توسعه اون مرحله رو کامل بر حسب فیدبک خودش از نیازهای مشتری انجام میداد و خروجی رو تحویل مشتری میداد، مشتری میگفت: “این که اون چیزی نبوده که من میخواستم! 😒 ” و اینطوری تیم توسعه و تمام تلاشاشون نابود می شد :))

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

4- اولویت تغییرات بر دنبال کردن یه نقشه‌ی از پیش تعیین شده (Responding to Change Over Following a Plan):

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

Agile میگه وقتی مشتری رو درگیر روند تولید محصول کنی و مدام باهاش در ارتباط باشی، در هرکدوم از این تکرار مذاکراتی که با مشتری انجام میگیره میشه تغییرات رو متوجه و اون‌ها رو اعمال کرد. در واقع دیدگاه Agile کاملاً متضاد دیدگاه سنتی هست، Agile تغییر رو نه تنها هزینه تلقی نمیکنه بلکه اون رو یه ارزش میدونه که باعث بهبود عملکرد پروژه میشه.

خب تا اینجا پس به صورت کلی فهمیدیم Agile چیه. اما خب اینا چه ارتباطی با Scrum داشت؟

در واقع Agile یک فلسفست که بهترین روش‌ها یا اصول رو برای هدایت به سمت یک انتخاب درست معرفی میکنه اما هیچ چیزی در رابطه با این که چطور باید کارها صورت بگیرن تا به اون انتخاب یا هدف درست رسید رو ارایه نمیده.

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

باز هم تا اینجا درست، ما فهمیدیم تقریباً بخشی از مشکلات چی بودن (تأخیر زمانی در تحویل محصول، عدم برطرف شدن خواسته ی مشتری در هنگام تحویل محصول نهایی، کارهای بیهوده‌ی فراوونی که فقط مهم‌ترین منبع یعنی زمان رو به هدر می دادن و …) و از طرف دیگه فلسفه‌ی Agile با ارزش‌هاش بهمون نشون داد که تونسته این مشکلات رو شناسایی کنه، اما حالا چارچوبایی که در این فلسفه قرار می گیرن چطوری و با چه راهکاری به حل این مشکلات می تونن کمک کنن؟

بررسی کلی عملکرد چارچوب‌های مبتنی بر Agile

در روش‌های مبتنی بر فلسفه‌ی Agile:

1- کار با ساخت یک product backlog شروع میشه.

✅ اصطلاح product backlog:

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

2- کل کار پروژه یا تولید محصول به یکسری iteration یا تکرارهایی کوتاه مدت و زمان‌بندی شده تقسیم میشه که مدت زمان بین هر iteration می‌تونه بین یک هفته تا یک ماه بر حسب نوع پروژه باشه. در ابتدای هر iteration تعدادی از آیتم‌ها از product backlog بر حسب اولیتشون در لیست، انتخاب میشن و تیم متعهد میشه که اون‌ها رو تا iteration بعدی کامل کنه.

✅ اصطلاح iteration:

در Agile منظور از iteration یک بازه زمانی تکراری هست که در طول اون بازه تمام آیتم‌هایی که از product backlog انتخاب شدن باید کاملاً توسعه داده شده و همینطور آزمایش شده باشن. هر پروژه‌ای به تعدادی iteration تا زمانی که کار پروژه به طور کامل انجام بشه، تقسیم میشه.

3- در طول هر iteration، تیمِ Self-Organizating و Cross-Functional، تمام اقداماتی که لازمه تا آیتم‌های انتخاب شده از product backlog کامل بشن رو انجام میدن. این کارها شامل: طراحی، تولید و آزمایش میشه.

✅ اصطلاح Cross-Functional:

منظور از تیم Cross-Functional تیمی هست که تمام مهارت‌های لازم برای انجام یه کار از صفر تا صد رو داشته باشه. یعنی چی؟ یعنی یه تیم هم باید شامل افرادی باشه که کد بزنن، هم شامل افرادی که تست رو انجام بدن، هم افرادی که بحث آنالیز و تجزیه و تحلیل رو انجام بدن، هم افرادی که مستندسازی رو انجام بدن و … باشه. اما این جا دو تا مساله هست:

• این معنیش این نیست که یه آدم باید تمام این مهارتا رو همزمان با هم داشته باشه
• به این معنی هم نیست که در دل یه تیم میشه یه تیم طراحی، یه تیم برنامه نویس، یه تیم تست و … داشت.

به طور کلی منظور از Cross-Functional این هست که هرکدوم از افراد تیم حتی الامکان چند مهارتی باشن. یعنی علاوه بر این که در یک مهارت کاملاً استاد و با تجربه هستن، نسبت به سایر مهارت‌ها هم یه درک و شناختی داشته باشن که بتونن به‌صورت تعاملی با بقیه افراد گروه کار کنن و صحبت‌ها و دیدگاه اون‌ها رو هم متوجه بشن.

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

✅ اصطلاح self-organized:

منظور از self-organized بودن تیم این هست که یک تیم چطور باید کارش رو بر اساس محدودیت‌هایی که بیزینس براش تعیین میکنه انجام بده. هر سازمانی دارای یه سری قوانین، رویه‌ها و استانداردهاست که قطعاً بر کارهایی که قراره در اون سازمان انجام بشه تأثیر میذارن و تیم هم نمی‌تونه این قوانین رو رعایت نکنه. اما با این حال تیم باید آزاد باشه که بتونه هر اقدامی رو که برای روند توسعه‌ی پروژه لازم هست، با در نظر گرفتن محدودیت‌ها، انجام بده.

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

پس در این طرز تفکر، یک تیم، خود سازمانده یا همون self-organized و همینطور خود مدیریت یا self-managing هست و نیازی نداره که مدیر ارشد خارج از تیم وظایفش و چگونگی انجام کارهاش رو مشخص کنه. این تیم خودش تعیین کننده‌ی “چطورها” و “چه کسی‌ها” (هرکس چه وظیفه‌ای داره) هست اما تعیین کننده‌ی “چه چیزها” و “چراها” نیست. هدایت کننده‌ی تیم هم‌چنان مدیر ارشد سازمان که خارج از تیم قرار داره، هست. در واقع چراها و چه چیزها مسایلی هستند که توسط مالک محصول (Product Owner) در کار با مالک تجارت (Business Owner) و ذینفعان (Stakeholders) مشخص می شن.

یک نکته ی خیلی مهم! دو مفهوم self-organized و Cross-Functional کاملاً مکمل هم هستند. تیم زمانی یک تیم موفق خواهد بود که بتونه هردوی این ویژگی‌ها رو همزمان باهم داشته باشه.

4.1- بعد از اتمام هر iteration، تیم، فیچرها یا همون آیتم‌های کامل شده رو با Stakeholder ها بررسی میکنن و فیدبکشون رو در رابطه با آیتم‌های تکمیل شده دریافت میکنن. براساس فیدبکی که از Stakeholderها دریافت میشه، Product Owner و تیم میتونن برنامه ریزی کنن که چه کارهابی و چطور باید انجام بشن و یا حتی تغییر رویه در انجام کارها رو داشته باشن. این یعنی چی؟

مثلاً فرض کنیم stakeholderها فیچرهای تکمیل شده رو دیدن و یهو یادشون میاد که مثلاً فلان فیچر هم باید برای محصول درنظر گرفته می‌شده که اول کار تعیین آیتم‌ها کلاً اون فراموش شده بوده. خب اینطوری Product Owner به راحتی می‌تونه آیتم جدیدی رو که مربوط به اون فیچر جدید هست رو به product backlog اضافه کنه.

4.2- از طرف دیگه، آخر هر iteration تیم باید به یک potentially shippable product increment رسیده باشه و اون رو به product owner تحویلش بده.

✅ اصطلاح potentially shippable product increment:

زمانی که گفته میشه یک محصول potentially shippable هست منظور اینه که تیم تمام کارهایی که در قبال فیچرهای انتخاب شده از product backlog برای اون iteration رو متعهد شده بوده، انجام داده (طراحی، ساخت، تست، مستندسازی) و از لحاظ تکنیکی محصول به حد بالایی از کیفیت و اطمینان رسیده که میشه اون رو به Product Owner تحویل داد. این که حالا این محصول آماده شده میتونه در اختیار مشتری قرار بگیره یا نه، یک تصمیم تجاری و وابسته به نظر Product Owner خواهد بود.

یک مثال ساده از محصولی که potentially shippable هست میشه مثلاً به پروژه‌ی طراحی یک فروشگاه آنلاین اشاره کرد. به عنوان مثال در iteration فعلی، تیم متعهد میشه که ظاهر اصلی این فروشگاه آنلاین با تمام قسمت های مربوط به گالری محصولات، ثبت سفارش، پرداخت آنلاین و … رو آماده کنه. خب تیم در طول این iteration با کیفیت بالا میاد و یک سایت عالی با ظاهری که تمام نیازهای مطرح شده رو داشته باشه آماده میکنه اما مثلاً اگر روی دکمه‌ی پرداخت آنلاین کلیک بشه، هیچ اتفاقی نمیوفته چون هنوز برای اون button طراحی شده، تعریف نشده که باید مثلا‌ً به فلان آدرس درگاه بانکی رجوع کنه.

روش کلی عملکرد اسکرام (Scrum) هم به عنوان یک چارچوب چابک (همون Agile) مشابه مواردی هست که در این بخش گفته شد (اما با جزییاتی بیشتر).

خلاصه:

هرچی تا اینجا مطرح شد فقط مقدمه ای برای ورود به حوزه‌ی اسکرام (Scrum) محسوب میشدن. این که Product Owner کی هست؟ منظور از Stakeholderها چه افرادی هست؟ جزییات عملکرد Scrum چیه؟ اصلاً چرا Scrum رو اینجا، یعنی تو بلاگ شبکه‌ها داریم معرفی می‌کنیم و خیلی سوالای دیگه، مسایلی هستن که سعی می‌کنیم تا در پست‌های بعدی بهشون بپردازیم.