‫‫ اسکرام چیست؟ با پدرام کشاورزی

فریم‌ورک اسکرام چیست؟ نقش مالک محصول، دولپور و اسکرام مستر در اسکرام چیست؟

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

‫‫من توی این اپیزود سعی کردم یه تصویر کلی از چیزی که از اسکرام انتظار میره در شرکت ها اتفاق بیفته رو بگم. بنابرین عموما از گفتن تئوری پرهیز کرد (لااقل سعی کردم) و فرایند اسکرام را مرحله به مرحله از مواجهه با مالک محصول (Product Owner) تا دولوپرها و اسکرام مستر و از رویدادهای اسکرام (Scrum Event) مثل جلسه برنامه ریزی اسکرام (Sprint Planning) تا جلسات روزانه اسکرام (Daily Scrum) ، بازبینی اسپرینت (Sprint Review) و بازاندیشی اسپرینت (Sprint Retrospective) رو مرور کردم.

‫‫امیدوارم برای علاقه مندانی که این چارچوب براشون تازه است مفید واقع بشه و برای حرفه ای ها مرور نسبتا کوتاه عملی و لذت بخشی باشه.

‫‫مثل همیشه منتظر فیدبکهاتون هستم.

منابعی که برای مطالعه بیشتر میتونید سمتشون برید، یکی سایت راهنمای اسکرامه. برای مطالعه عمیق‫‫ تر ساز و کار اسپرینت و رویکرد Iterative Incremental یه سر به این کتاب (Scrum – A Pocket Guide) بزنید. اگر فکر میکنید همین راهنمای اسکرام لازم دارید که با تفسیر بیشتر اما کماکان مختصر بدونید میتونید به این کتاب (Scrum Insights for Practitioners) سر بزنید.

‫‫اجایل گپ رو میتونید از لینکدین ، تلگرام و اینستاگرام نیز دنبال کنید.

‫‫با خود من هم، پدرام کشاورزی، از طریق لینکدین می‌توانید در ارتباط باشید.

‫‫در انتها از پانته‌آ شهریاری برای تدوین این کار بسیار ممنونم.

مقدمه اپیزود اسکرام چیست

سلام و درود به همه‌ی شما عزیزان.
من پدرام کشاورزی هستم و با یکی دیگه از قسمت‌های پادکست «اجایل گپ» در خدمتتونم.

توی پادکست «اجایل گپ»، ما درباره‌ی گپ‌ها و خلأهای به‌کارگیری تفکر اجایل در سازمان‌ها صحبت می‌کنیم؛ و خب، احتمالاً به این موضوع هم می‌پردازیم که آیا روش‌ها، پرکتیس‌ها و فریم‌ورک‌هایی مثل اسکرام واقعاً درست دارن کار می‌کنن یا نه.

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

اون موضوع چیه؟
اینه که بیایم یک‌بار ساده و شفاف بگیم که اصلاً اسکرام چی هست! حداقل یه معرفی اولیه داشته باشیم.

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

تو اون نظرسنجی، ما سه تا موضوع مطرح کرده بودیم:
۱. مبانی و اصولی مثل خود اسکرام،
۲. پرکتیس‌ها و تکنیک‌ها و روش‌ها،
۳. و مشکلات رایجی که توی پیاده‌سازی به وجود میان.

و خب، بیشترین رأی مربوط به "مشکلات رایج" بود؛ بعد از اون هم موضوع "اصول و مبانی" بیشترین علاقه‌مندی رو داشت. این برام خیلی جالب بود چون نشون داد بخشی از مخاطب‌هامون، نیاز دارن که از پایه با این مفاهیم آشنا بشن، و تا الان ما کمتر به اون بخش پرداختیم.

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

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

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

راستش رو بخواید، خود من هم هر بار که اسکرام گاید (راهنمای اسکرام) رو می‌خونم، یه چیزی برام تازه‌ست. یعنی هنوز هم وقتی می‌خونمش، یه قسمت جدیدی ازش برام معنی پیدا می‌کنه. هر بار که می‌خونم یه "آها" تو ذهنم شکل می‌گیره.
برای همین فکر نمی‌کنم با یه اپیزود ۳۰ دقیقه‌ای یا یک ساعته، بشه به اون درک عمیق رسید. پس اینو با همدیگه روشن کنیم که انتظارمون از این اپیزود چیه.

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

بیشتر تمرکزم هم روی چیزهاییه که شما توی فضای سازمانی می‌تونید ببینید. یعنی نمی‌رم خیلی وارد تئوری‌های عمیق اسکرام بشم، بلکه روی ظواهرش تمرکز می‌کنم—اون چیزی که قابل مشاهده‌ست، اون چیزی که وقتی وارد یه تیم اسکرامی می‌شی، می‌بینی.

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

خب... بریم شروع کنیم!

چرا از اسکرام استفاده می‌کنیم؟ از استفاده از اسکرام چه انتظاری داریم؟

بذارید من اول از همه یه سؤال بپرسم:
اصلاً چرا داریم از اسکرام استفاده می‌کنیم؟ چه کاری قراره برای ما انجام بده؟

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

خب، قراره تیم روی این کار کنه، و هدف اینه که اون مسئله یا محصول، به‌درستی حل بشه یا ساخته بشه. ما یه اپیزود دیگه هم داشتیم در مورد این‌که تو محیط‌های پیچیده یا به‌اصطلاح Complex Environments چی پیش میاد، و گفتیم که اونجا چه اپروچی باید داشته باشیم.
اونجا هم یه اشاره‌ای کردم—اگر اشتباه نکنم—که اسکرام دقیقاً برای همین محیط‌های پیچیده طراحی شده؛ برای پروداکت‌های پیچیده، برای مسائلی که نمی‌شه از قبل همه‌چیز رو براش مشخص کرد.

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

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

در سازمانی که اسکرام را پیاده‌سازی کرده است با چه چیزی مواجه می‌شویم؟

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

مالک محصول (Product Owner) کیست؟ در اسکرام چه وظیفه‌ای دارد؟

اولین کاری که باید انجام بدن اینه که یه نفر رو انتخاب کنن که روی این ایده کار کنه، مسیر رو براش مشخص کنه، و تیم رو به سمت ساخت اون نرم‌افزار هدایت کنه. توی اسکرام، به این شخص می‌گن: Product Owner یا همون «مالک محصول».

هدف محصول (Product Goal) چیست؟

مالک محصول (Product Owner) کسیه که میاد ایده‌ی سازمان رو می‌شنوه، بررسیش می‌کنه و اون رو تبدیل می‌کنه به یک هدف مشخص، قابل‌اندازه‌گیری، و واضح. هدفی که نشه فقط در حد «ما یه نرم‌افزار می‌خوایم» تعریفش کرد. چون خب، چه نرم‌افزاری؟ با چه ویژگی‌هایی؟ قراره برای کی ساخته بشه؟ قراره چه کاری انجام بده؟ همه‌ی این سؤالات رو مالک محصول (Product Owner) می‌پرسه تا به یه تعریف دقیق برسه.

مثلاً می‌گه: ما یه نرم‌افزار مرتبط با رمزارز می‌خوایم که این ویژگی‌ها رو داشته باشه، مخاطبش این گروه از آدم‌ها باشه، و قراره فلان مشکل رو حل بکنه.

وقتی به این نقطه رسیدیم، حالا می‌تونیم بررسی بازار رو انجام بدیم: رقبا کی‌ان؟ مخاطب‌هامون کی‌ان؟ بازار چقدره؟ محیط رقابتی چجوریه؟ و بعد از این بررسی‌ها، یه هدف برای ساخت اون نرم‌افزار تعیین می‌کنیم.

توی اسکرام، به این هدف می‌گن: Product Goal، یعنی هدف محصول.

تفاوت محصول با پروژه در چیست؟

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

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

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

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

به‌همین خاطر نقش مالک محصول (Product Owner) خیلی مهمه؛ چون کسیه که باید دائم گوش به زنگ باشه، هدف رو به‌روز کنه، و اون تعادل بین «انتظارات خود سازمان» و «نیازهای کاربران» رو حفظ کنه.

بکلاگ محصول (Product Backlog) چیست؟

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

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

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

برای اینکه این مسیر رو به بقیه‌ی تیم منتقل کنه، یه چیزی داریم به اسم Product Backlog یا همون «بک‌لاگ محصول».

خب، بکلاگ محصول (Product Backlog) چیه؟ یه لیست از آیتم‌هایی که باید انجام بشن. این آیتم‌ها اولویت‌بندی شدن، مرتب شدن و طبق راهنمای اسکرام اصطلاحاً ordered هستن—یعنی مشخصه که چی قراره اول انجام بشه، چی دوم، چی سوم و همین‌طور تا آخر.

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

پس تا این‌جا دوتا چیز داریم:
۱. مالک محصول (Product Owner)
۲. بکلاگ محصول (Product Backlog)

این دوتا با همدیگه عجینن. مالک محصول (Product Owner) با بکلاگ محصول (Product Backlog) زندگی می‌کنه. مدام چکش می‌زنه، مدام به‌روزش می‌کنه، آیتم‌ها رو جابه‌جا می‌کنه، حذف و اضافه می‌کنه.

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

مالک محصول (Product Owner) باید مدام مسیر رو بررسی کنه، چون فقط «رسیدن به مقصد» مهم نیست؛ رسیدن با کم‌ترین هزینه، بیشترین ارزش و در سریع‌ترین زمان مهمه.

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

بعد از این مرحله، وارد بخش بعدی می‌شیم: تیم توسعه یا همون Developers.

دولوپر (Developers) کیست؟ در اسکرام چه وظیفه‌ای بر عهده دارد؟

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

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

این ساختار شامل یه سری «جلسه» یا رویداده—که ما تو فارسی معمولاً بهشون می‌گیم «جلسه». این جلسات ۵‌تا هستن. هدف از این جلسات اینه که تیم باهم هماهنگ بمونه، وضعیت خودش رو بسنجه و پیشرفتش متوجه بشه، بازخورد بگیره، و بکلاگ محصول (Product Backlog) رو به‌روز نگه داره. حالا بعداً در مورد هر کدومشون مفصل صحبت می‌کنیم.

ولی این وسط یه نقش دیگه‌ای هم هست که تا الان نگفتم؛ چون الان وقتشه که بیاریمش وسط: اسکرام‌مستر (Scrum Master).

اسکرام مستر (Scrum Master) کیست؟ در اسکرام چه وظیفه‌ای دارد؟

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

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

پس فعلاً در همین حد بگم: اسکرام‌مستر قراره شرایط رو طوری فراهم کنه که همهٔ این اتفاق‌ها—از هدف‌گذاری تا توسعه و هماهنگی تیم—بتونه روان و بدون اصطکاک پیش بره.

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

فقط همین‌قدر بدونید که اسکرام‌مستر اصلی‌ترین کاری که باید انجام بده اینه که اسکرام رو همون‌طوری که توی Scrum Guide توضیح داده شده، توی سازمان پیاده‌سازی کنه.

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

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

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

پس حالا که داریم درباره‌ی فرایند صحبت می‌کنیم، بریم ببینیم که اصلاً این فرایند چی هست.

اسکرام مستر با چه فرایندی و چطور از مالک محصول و دولوپرها یک تیم می‌سازد؟

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

اسپرینت چیست؟

خب، اسپرینت (Sprint) یعنی چی؟
اسپرینت یه بازه‌ی زمانیه. یعنی ما قبل از شروع، مثلاً با هم توافق می‌کنیم که این اسپرینت قراره یه هفته طول بکشه.
توی همین یه هفته قراره یه بخش از کارهایی که توی بک‌لاگ هست رو انجام بدیم.

مثلاً مالک محصول (Product Owner) می‌گه: «ببین، این آیتم‌های اول بک‌لاگ خیلی مهمن.»
تیم هم می‌گه: «باشه، ما این پنج شیش‌تا آیتم اول رو توی این هفته تحویلت می‌دیم.»
این میشه اسپرینت اول.

بعدش چی؟ همین‌طوری اسپرینت‌به‌اسپرینت جلو می‌ریم تا اون مسئله‌ی پیچیده یا اون محصول مورد نظر رو، کم‌کم و قدم‌به‌قدم حل یا تولید کنیم. یه اصطلاحی هم اینجا باید به کار ببرم که ممکنه براتون آشنا باشه: این روش، روش Iterative یا همون دوره‌ای هست.

یعنی ما هر دفعه یه تیکه از کار رو انجام می‌دیم، تحویل می‌دیم، فیدبک می‌گیریم، بررسی می‌کنیم و دوباره ادامه می‌دیم.

تکه محصول (Increment) چیست؟

حالا اینجای قصه یه واژه‌ی دیگه هم وارد می‌شه که توی اسکرام خیلی مهمه: تکه محصول (Increment).

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

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

فرض کن شما دو سال یه اپلیکیشن ساختی، بعدش می‌بری تحویل مشتری، اونم می‌گه: «این دیگه به چه درد من می‌خوره؟ الان که نیاز من فرق کرده!» اینجاست که کل انرژی و وقت و هزینه‌ای که صرف کردی، ممکنه به فنا بره.

پس ما چی کار می‌کنیم؟ با استفاده از اسپرینت و تکه محصول (Increment)، سعی می‌کنیم ریسک شکست رو بیاریم پایین.

هر بار یه تیکه از محصول رو می‌سازیم، می‌دیم به کاربر، فیدبک می‌گیریم، و اگر لازم بود مالک محصول (Product Owner) بره و بک‌لاگ رو اصلاح کنه، مسیر رو عوض کنه، یا اولویت‌ها رو جابه‌جا کنه.

همه‌ی این‌ها باعث می‌شه که ما:

• سریع‌تر یاد بگیریم،

• سریع‌تر اصلاح کنیم،

• و در نهایت، یه محصول بهتر تحویل بدیم که واقعاً به درد کاربر بخوره.

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

من منابع لازم رو حتماً توی توضیحات همین اپیزود پادکست می‌ذارم که اگه دوست داشتید، برید سراغشون.

یه نکته‌ی دیگه که خیلی مهمه اینه که اسپرینت یه سقف زمانی داره. این سقف چقدره؟
یک ماه تقویمی.
یعنی نه ۳۰ روز، نه ۴ هفته، بلکه دقیقاً یک ماه تقویمی که توی خود راهنمای اسکرام (Scrum Guide) هم همین‌جوری اومده.

ما تو اسکرام به این مدل زمان‌بندی می‌گیم Timebox.
و اصلاً اسکرام به‌شدت عاشق تایم‌باکسه!
تو همه‌ی ایونت‌هاش هم می‌بینید این تایم‌باکس وجود داره.

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

جلسه برنامه‌ریزی اسپرینت (Sprint Planning) چیست؟

اینجا یه ایونت داریم به اسم Sprint Planning یا همون برنامه‌ریزی اسپرینت.
این ایونت، تایم‌باکسش ۸ ساعته... البته برای اسپرینت‌هایی که یک ماهه‌ست.
اگه اسپرینت کوتاه‌تر باشه، مثلاً یه هفته‌ای یا دو هفته‌ای، طبیعتاً این زمان هم کمتر میشه.

تو اسپریـن پلنینگ، قراره چه اتفاقی بیفته؟

ببینید، وقتی درباره‌ی ایونت‌ها صحبت می‌کنیم، همیشه سه‌تا سؤال مهم وجود داره که باید بدونیم:

1. هدف ایونت چیه؟

2. چه کسانی توی ایونت شرکت می‌کنن؟

3. تایم‌باکس یا زمان‌بندیش چقدره؟

تایم‌باکس رو که گفتیم.
حالا بریم سراغ نفرات شرکت‌کننده:

توی اسپرینت پلنینگ، کل تیم اسکرام حضور دارن. یعنی:

• مالک محصول (Product Owner)

• اسکرام‌مستر

• دولوپرها

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

حالا هدف چیه؟

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

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

در انتهای این جلسه، سه چیز خیلی مهم باید حاصل بشه:

1. هدف اسپرینت: یعنی چی قراره توی این بازه‌ی زمانی بهش برسیم.

2. بکلاگ اسپرینت (Sprint Backlog): یعنی لیستی از آیتم‌هایی که تیم قراره توی همین اسپرینت روشون کار کنه.

3. طرح اجرا یا Implementation Plan: یعنی اینکه تیم دولوپرها دقیقاً چه برنامه‌ای دارن برای اینکه اون آیتم‌ها رو پیاده‌سازی کنن.

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

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

اما خب توی روزهای کاری این اسپرینت، مثلاً اگه اسپرینت‌مون یک هفته‌ای باشه، از شنبه تا چهارشنبه، یه ایونت دیگه هم داریم به اسم Daily Scrum یا همون اسکرام روزانه.

معمولاً اول روز برگزارش می‌کنن (هرچند راهنمای اسکرام نمی‌گه که حتماً باید اول روز باشه، ولی خب تجربه نشون داده که این تایم مناسبه).

تایم‌باکس دیلی اسکرام چقدره؟
۱۵ دقیقه!
فقط ۱۵ دقیقه. جلسه‌ای خیلی کوتاه، ولی خیلی مهم.

چه کسانی توش شرکت می‌کنن؟
فقط دولوپرها.

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

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

هدف دیلی اسکرام چیه؟

یادتونه توی Sprint Planning یه هدف تعیین کردیم؟
همون هدف، هر روز توی دیلی اسکرام میاد روی میز.
تیم بررسی می‌کنه:

• چقدر به اون هدف نزدیک شدیم؟

• امروز قراره چی کار کنیم؟

• چه موانعی سر راهمونه؟

و اینجوری هر روز، یه گام کوچیک برمی‌داریم برای رسیدن به هدف اسپرینت.

این سؤال‌ها برای اینه که ما مدام خودمون رو بسنجیم.
بدونیم الان نسبت به هدف اسپرینت، کجای کاریم؟
آیا داریم طبق پلنی که داشتیم پیش می‌ریم یا نه؟
آیا لازم شده چیزی رو تغییر بدیم؟

و اگه نیاز بود، می‌ریم سراغ تغییر در بکلاگ اسپرینت (Sprint Backlog)؛

• ممکنه آیتمی اضافه کنیم،

• ممکنه آیتمی کم کنیم،

• یا حتی ممکنه آیتمی رو دقیق‌تر و شفاف‌ترش کنیم، یا روش کار رو اصلاح کنیم.

در نهایت، توی دیلی اسکرام، باید بدونیم برای روز بعدی دقیقاً قراره چی کار کنیم.
تمرکز فقط روی روز بعدیه.

حالا بزار یه چیزی رو بگم:
Daily Scrum یکی از چالش‌برانگیزترین ایونت‌هاست.
تیم‌های اسکرام معمولاً با این جلسه دست‌وپنجه نرم می‌کنن،
سازمان‌ها هم اکثراً باهاش آشنان، ولی متأسفانه عموماً اشتباه می‌شناسنش.

احتمالاً بعد از اینکه این قسمت پادکست منتشر بشه، کلی کامنت بیاد در موردش!
می‌دونی چرا؟
چون خیلیا هنوز فکر می‌کنن این جلسه یعنی همون سه‌تا سؤال معروف:

1. دیروز چی کار کردی؟

2. امروز چی کار می‌خوای بکنی؟

3. چیزی هست که مانعت بشه؟

خب این مدل خیلی رایجه، ولی…

واقعیت اینه که چیزی که توی Scrum Guide سال ۲۰۲۰ نوشته شده، متفاوته.
اون سه‌تا سؤال، تا قبل از نسخه ۲۰۱۷ راهنمای اسکرام بود.
بعد دیدن داره سوءبرداشت ایجاد می‌کنه، اصلاً حذفش کردن.

الان فقط هدف رو می‌گن:
"بررسی میزان پیشرفت نسبت به هدف اسپرینت"
هر ساختاری که کمک کنه به این هدف برسیم، درسته.

پس اسکرام مستر باید هدف رو برای دولوپرها شفاف کنه،
ولی اینکه چطوری جلسه رو اجرا کنن، بسپره به خود تیم.
یعنی دولوپرها که Self-Managing هستن، خودشون تصمیم می‌گیرن ساختار جلسه چطور باشه.

مثلاً یکی از تیم‌هایی که من باهاشون کار کردم، ساختاری که استفاده می‌کردیم مدل 1-2-4-All از Liberating Structures بود که در اپیزود زیر میتونید یادش بگیرید.

ساختار ۱-۲-۴-همه چیست؟ با پدرام کشاورزی

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

‫‫‫‫‫‫ ساختارهای رهایی بخش (Liberating Structures) - با داوود آقایی

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

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

اولی چیه؟ Sprint Review یا جلسه نقد اسپرینت.

جلسه‌ی نقد اسپرینت (Sprint Review) چیست؟

این ایونت، چهارساعت تایم‌باکس داره (برای اسپرینت‌های یک‌ماهه).
برای اسپرینت‌های کوتاه‌تر، طبیعتاً زمانش هم کمتره.

چه کسانی توش شرکت می‌کنن؟
کل تیم اسکرام + ذی‌نفعان کلیدی (Stakeholders)
ذی‌نفعان یعنی اونایی که برای نتیجه‌ی کار ما اهمیت قائلن؛ می‌تونن مشتری باشن، مدیر باشن، یا هر کسی که به نحوی به محصول مربوطه.

مالک محصول (Product Owner) معمولاً دعوتشون می‌کنه. اسکرام مستر هم می‌تونه کمک کنه معرفی کنه جلسه چیه، قراره چی بشه، ولی رهبری اصلی جلسه می‌تونه دست تیم باشه.

هدف جلسه چیه؟

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

ما خروجی‌های اسپرینت رو می‌گذاریم وسط میز.
مثلاً نرم‌افزاری که ساخته شده رو نشون می‌دیم.

بعد از Stakeholderها می‌خوایم نظر بدن، باهاش کار کنن، فیدبک بدن.
اگه واقعاً بتونن استفاده‌اش کنن و نظر بدن، خیلی ارزشمنده.

حتی ممکنه راجع به بازار صحبت بشه:

• الان وضعیت چطوره؟

• رقبا چی‌کار کردن؟

• مخاطب‌ها چه نیازی دارن؟

• تحقیقاتی انجام شده؟

همه‌ی اینا شنیده می‌شه.

و یه نکته مهم:
توی همین جلسه ممکنه بحث بشه که تو اسپرینت بعدی چی کار کنیم.
یعنی ورودی‌هایی که از جلسه می‌گیریم، می‌ره توی بکلاگ محصول یا Product Backlog،
بعد مالک محصول (Product Owner) میاد آیتم‌ها رو بررسی می‌کنه، مرتب می‌کنه،
و احتمالاً بعضی از اونا می‌رن تو اسپرینت بعدی.

به‌نظرم Sprint Review یه جلسه‌ی خیلی مهمه.
اگه توی یه سازمان اعتماد بین Stakeholderها و تیم توسعه وجود نداره،
یکی از بهترین ابزارهایی که می‌تونید ازش استفاده کنید همین جلسه‌ست.

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

یادتونه بهتون گفتم که مالک محصول (Product Owner) و بک‌لاگ محصول به همدیگه عجین هستن؟ انگار که به هم چسبیدن! واقعاً هم همین‌طوره. این ارتباط باید مدام ادامه داشته باشه.

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

اگه این گفت‌وگوها اتفاق نمی‌افته، یعنی یه جای کار اسکرام ما می‌لنگه. و این جلسه دیگه اسمش Sprint Review نیست، شده همون ارائه‌ی خشک و خالی مثل دانشگاه که هیچ‌کس گوش نمی‌ده! اما اگه ذی‌نفعان واقعاً میان، مشارکت می‌کنن، حرف می‌زنن، فیدبک می‌دن،
اون موقع می‌تونید بگید جلسه‌تون مسیر درستی داره.

یه نکته‌ی جالب دیگه:
واژه‌ی "Review" همون کلمه‌ایه که توی دنیای فیلم و سینما زیاد می‌شنویم. اگه اهل فیلم باشید، می‌دونید که Review یعنی نقد. یعنی یکی میاد، یه چیزی می‌بینه، بررسیش می‌کنه، نظرش رو می‌گه.نه فقط یه “Nice!” یا “خوب بود”، بلکه دقیق و با جزئیات. Sprint Review هم دقیقاً همینه؛ یعنی بیایم خروجی‌هامون رو بذاریم وسط، مخاطب بیاد بررسی کنه، نظر بده، نقد کنه. تا بدونیم چی خوب بوده، چی نه، و چطوری باید بهتر بشیم.

جلسه‌ی بازنگری اسپرینت (Sprint Retrospective) چیست؟

خب حالا بریم سراغ آخرین ایونت اسکرام: Sprint Retrospective
یا به قول خودمون: بازاندیشی اسپرینت. راستش من خیلی این ترجمه‌ی “بازاندیشی” رو دوست دارم، چون هم بامسماست، هم مفهوم رو قشنگ منتقل می‌کنه.

اول از همه، تایم‌باکس این ایونت چقدره؟ برای اسپرینت‌های یک‌ماهه، سه ساعت. اگه اسپرینت کوتاه‌تر باشه، طبیعتاً کمتر. ولی در کل، بسته به نیاز تیم.

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

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

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

خب… ما دیگه رسیدیم به انتهای اسپرینت. Retrospective، در واقع خاتمه‌ی اسپرینت فعلیه،
و بلافاصله بعدش، دوباره Sprint Planning بعدی شروع میشه. این چرخه‌ی اسکرامیه که مدام تکرار میشه. و با هر بار تکرار، تیم یاد می‌گیره، بهتر میشه، و محصول رشد می‌کنه.

خیلی ممنونم که تا اینجا همراه من بودید.
توی این اپیزود تلاش کردم یه تصویر واقعی و کاربردی از فریم‌ورک اسکرام تو ذهنتون بسازم.

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

دمتون گرم،
خیلی خیلی دوستتون دارم،
فعلاً… خوب و خوش باشید.
خداحافظ.