در این مطلب قصد داریم یک مفهوم میان رشتهای را شرح دهیم که نه تنها مورد استفاده متخصصان بازاریابی است، بلکه تیمهای تولیدکننده نرمافزارها نیز از آن استفاده میکنند. فرآیند توسعه چابک که این روزها به وفور توسط تیمهای نرمافزاری مورد استفاده قرار میگیرد، مشتمل بر متدولوژیهای توسعه نرمافزار مبتنی بر تکرار شوندگی و تکامل تدریجی است و این درست همان نقطه مشترکی است که دنیای بازاریابی و دنیای نرمافزاری را به یکدیگر پیوند میدهد.
به دلیل اینکه هر دو حوزه به تدریج محصول خود را آماده کرده و ویژگیهای مورد نیاز مشتری/کاربر را به آن اضافه میکنند. این تکنیک دو مزیت عمده دارد، اول آنکه اجازه نمیدهد خروجی نهایی از بازار کسبوکار عقب بماند و دوم آنکه چابکی خاصی را در اختیار متخصصان بازاریابی دیجیتال و تیمهای نرمافزاری قرار میدهد، بهطوری که آنها ویژگیهای کاربردی محصول را متناسب با نیازهای مشتری و بر مبنای فناوریهای روز طراحی کنند.
پیشنهاد مقاله: چرخش و بوم ناب در بازاریابی دیجیتال ناب چه معنایی دارند؟
توسعه چابک چیست؟
در دهه 90 میلادی تعدادی از متدهای توسعه سبک وزن در واکنش به متدهای توسعه سنگین وزن ارائه شدند. متدولوژیهای سنگین وزن مدلی از توسعه را ارائه میکنند که به شدت منظم، دستهبندی و ریزمدیریتی شده هستند. متدهای سنگین وزن در بیشتر موارد این توانایی را ندارند تا پروژههای نرمافزاری را در کمترین زمان و با کمترین هزینه ممکن به سرانجام برسانند.
به طور کلی میتوانیم اینگونه عنوان کنیم که متدولوژیهای سنگین وزن انعطافپذیری خوبی در دنیای نرمافزار ندارند. به ویژه زمانیکه قرار است تغییری در یک پروژه به وجود آمده یا مولفهای به یک محصول اضافه شود. همین موضوع باعث شد تا به مرور زمان متدهای چابک مختلفی همچون مدلسازی چابک، فرایند یکپارچه چابک (AUP)، Crystal Clear، متدهای توسعه سیستمهای دینامیک (DSDM)، برنامهنویسی مفرط (XP)، اسکرام و…. پدید آیند.
این تعدد متدهای توسعه چابک در نهایت باعث شد تا تعدادی از توسعهدهندگان برتر نرمافزار به فکر ارائه یک چهارچوب مدون برای توسعه چابک باشند. چهارچوبی که به خوبی قادر باشد توسعه چابک نرمافزار را معرفی کند. این هماندیشی در نهایت و در سال 2001 مانیفست چابک را پایهریزی کرد. شکل زیر نمایی از فرآیندهای مورد استفاده در مدلهای مختلف توسعه چابک را نشان میدهد.
مانیفستی که در سال 2001 منتشر شد بر اصول زیر تاکید دارد: فردگرايي و تعامل بهتر فرآيندها و ابزارها، نرمافزار قابل اجرا بهتر از مستندات مفهومي است، همکاري با مشتريان بهتر از مذاکرات قراردادگراست، پاسخدهی به تغييرات بهتر از دنبالهروي بدون تعمل از یک طرح است.
در مجموع مدل توسعه چابک را اینگونه میتوانیم تعریف کنیم:
توسعه نرمافزاری چابک را مجموعهای از متدلوژیهای توسعه نرمافزاری شکل میدهند که بر مبنای تکامل تدریجی و تکرار شونده که در آن راه حلها از طریق خودسازماندهی و همکاری فیمابینی که تیمهای مختلف کاری بر اساس آن کار میکنند شکل میگیرد. این روش برنامهریزی تطبیقی، توسعه تکاملی، زمانبندی دقیق، بهبود مستمر، واکنش سریع و انعطافپذیری در برابر تغییرات را از خود نشان میدهد. در واقع متدولوژی چابک یک چارچوب مفهومی است که پیشبینی تعاملات در سراسر چرخه توسعه را بهبود میبخشد.
اسکرام به یاری کمپینتان میآید
اگر از هر متخصص بازاریابی موفقی در ارتباط با پیشرفت یک کمپین سوال کنید، به شما خواهد گفت، بهکارگیری متدهای چابک به واحد بازاریابی کمک خواهد کرد تا زحماتشان را متمرکز کنند.
در حالی که اسکرام از سوی تیمهای نرمافزاری مورد استفاده قرار میگیرد، اما قوانین آن برای ارائه طرحهای بازاریابی دیجیتال بسیار کارآمد هستند. اسکرام یک مدل تکرارشونده و افزایشی است که برای کنترل و مدیریت پروژه مورد استفاده قرار میگیرد. مایک کان در این ارتباط گفته است: «اسکرام یک چارچوب است. در نتیجه به جای توصیف دقیق و کامل کارها و اینکه هر کاری چگونه در یک پروژه باید به سرانجام برسد، سعی میکند در بیشتر موارد کارها را به تیم واگذار کند. این کار شدنی است، به دلیل اینکه تیم خواهد دانست چگونه باید به بهترین نحو ممکن مشکل خود را حل کند.»
اسکرام چیست؟
اگر به ساختار این متدولوژی و نرمافزارهایی که بر پایه این متدولوژی در گذشته ساخته میشدند، نگاهی داشته باشید مشاهده میکنید که همه چیز کاملا مشابه به آبشار است. نه تنها هیچگونه انعطاف پذیری در کار نیست، بلکه امکان تغییر مسیر نیز میسر نیست.
امروزه شرکتهای تولیدکننده محصولات و حتی مشتریان این شرکتها به خوبی به این حقیقت آگاه شدهاند که تا مادامی که سیستمی به طور کامل پیادهسازی نشده باشد، نمیتواند منعکس کننده عملکرد خود باشد. مشتری ممکن است نیازهای دیگری در ذهن داشته باشد اما سیستم تا زمان استقرار کامل، توانایی تشریح آنها را ندارد.
در نتیجه اگر بتوانیم ساز و کاری در این زمینه پیادهسازی کنیم تا مشتری از همان ابتدای امر در جریان ساخت یک محصول قرار گیرد، آنگاه مشکل برطرف خواهند شد. این تکنیک به مشتریان کمک میکند در مدت زمان ساخت و قبل از آنکه محصول نهایی شود، نظرات خود را اعلام دارند. به طوری که محصول نهایی هماهنگ و متناسب با نیازهای آنها آماده شود.
امروزه اسکرام، راهکار مفیدی است که برای پروژههای مختلف مورد استفاده قرار گرفته و همگان بر مفید بودن آن اذعان دارند. اسکرام بر مبنای یک روش تکرارشونده این توانایی را در اختیار تیمهای تولیدکننده محصول قرار میدهد تا محصولات را با بالاترین کیفیت تولید کنند.
این چهارچوب که جزء روشهای چابک است، یک مدیریت قدرتمند برای تولید محصولات به وجود آورده و به اعضا تیم این توانایی را میدهد که بر مبنای دستورالعملهای پیشنهادی، سرعت تولید محصولات را افزایش دهند. شکل زیر نمایی از چهارچوب اسکرام را به همراه فرآیندهایی که در اسکرام انجام میشود، نشان میدهد.
در اسکرام هر عضو تیم باید در ارتباط با وظیفهای که به او محول شده درک درستی داشته باشد و باید برای رسیدن به هدف مشخصی که در تمامی مراحل عملیاتی یا فازهای اجرایی وجود دارد، تلاش کند.
در چهارچوب اسکرام هر مرحله عملیاتی سیستم، اسپرینت (Sprint) نامیده میشود. شکل زیر نمایی از یک اسپرینت را نشان میدهد. اسکرام دارای مرحله برنامهریزی اولیه است. در این مرحله اعضا گروه باید یک نقشه اولیه و یک معماری سیستم را آماده کنند. این نقشه راه باید به گونهای آماده شود که قابل تغییر باشد.
در مرحله بعد باید تعدادی فاز عملیاتی اسپرینت به طور مرتب و جزء به جزء برای محصول آماده شوند. هر اسپرینت به طور میانگین به یک تا چهار هفته زمان نیاز دارد. اسپرینتهایی که در طول فازهای مختلف آماده میشوند در نهایت باعث به وجود آمدن محصول کاملی میشوند. فهرست کارهایی که در هر اسپرینت آماده میشوند Backlog نامیده میشوند.
به عبارت دیگر مجموعه نیازهای عملیاتی و غیر عملیاتی (Functional and Non Functional Requirements) محصول که مستندسازی شدهاند backlog نامیده میشوند. همچنین مجموعه نیازهایی که در هر اسپرینت تکمیل میشوند sprint Backlog نامیده میشوند. هر چرخه اسپرینت تا زمانی که محصول آماده عرضه نهایی باشد ادامه مییابد. بعد از عرضه نهایی محصول این احتمال وجود دارد که مشتریان به نیازهای جدید احتیاج پیدا میکنند. به این نیازهای جدید Product Backlog گفته میشود.
Backlogها در هر اسپرینت بهروزرسانی میشوند. این فهرست وظایف دارای اولویت هستند. هر یک از اعضاء تیم موظف است یک تکلیف خاص را برعهده گرفته و همچنین تضمین کند که وظیفه محول شده به او پیش از آغاز اسپرینت بعدی به اتمام خواهد رسید.
زمانیکه یک اسپرینت آغاز میشود، دیگر جایی برای اعمال تغییر در یک تکلیف وجود نخواهد داشت. در صورت تخطی از این قوانین تمامی اسپرینتها و Backlogهای اولیه و تلاشهایی که در این زمینه انجام شده بود تبدیل به یک کار بیهوده میشوند.
البته لازم به توضیح است، مشتری میتواند پیشنهاد حذف بخشهایی از محصول در دست ساخت را در هر مرحله از تولید ارائه کند. این سختگیری از دو جهت حائز اهمیت است، اول آنکه باعث به وجود آمدن یک نظم خوب در گروه میشود و دوم آنکه تاریخ تحویل محصول نهایی را به تعویق نخواهد انداخت.
در هر اسپرینت به طور روزانه جلساتی با مشارکت تیم تولیدکننده محصول، مدیریت و مشتری اولیه برگزار میشود، تا میزان پیشرفت و قابلیتهای محصول مورد بررسی قرار گیرد. اینکار باعث افزایش بیش از پیش هماهنگی میان اعضا گروه میشود.
در مدت زمان برگزاری جلسات، مدیر پروژه سوالاتی را از مخاطبان شرکتکننده در جلسه میپرسد. به طور مثال: از زمان برگزاری جلسه قبل تا جلسه امروزه چه مسئولیتی به آنها سپرده شده است و آیا موفق شدهاند وظیفه خود را به سرانجام برسانند؟ در مدت زمان اسپرینت به چه مشکلاتی روبرو شدهاند؟ مطابق با فهرست وظایف، تا زمان برگزاری جلسه بعدی تمایل دارند چه مسئولیتی به آنها سپرده شود؟ و…
مدیر چهارچوب اسکرام مسئولیت بررسی فرآیند تکمیل ساخت محصول، برررسی تواناییهای اعضا تیم، شناسایی مسئولیتها و تکالیف اختصاص یافته به اعضا و کاهش ریسکهایی که پروژه را در معرض خطر قرار میدهد بر عهدهدار دارد
ساختار چهارچوب اسکرام چگونه است؟
شکل زیر نقشهای اسکرام که مشتمل بر کاربران، ذینفعان، مالک محصول، تیم و مدیر اسکرام است را نشان میدهد.
این نقشها که مشتمل بر درخواستکنندگان محصول یا ذینفعان محصول یا استفادهکنندگان نیز میشوند از طریق رابط خود که همان مالک محصول (Product Owner) است با تیم توسعهدهنده محصول به تعامل خواهند پرداخت.
مالک محصول که نماینده گروه ذینفعان محصول است، همان مدیر بازاریابی دیجیتال است که در واقع ایده اولیه را مطرح کرده است. مالک محصول اصلیترین نقش را در اسکرام بر عهده دارد. در اسکرام هر کدام از نقشها وظیفه خاص خود را دارند. مالک محصول دو وظیفه مهم را بر عهده دارد. اول آنکه باید هدف و چیستی هدف را برای تیم مشخص ساخته و آنرا به تیم نشان دهد (مالک محصول در ارتباط با اینکه تیم چگونه باید به این هدف دست پیدا کند، مسئولیتی ندارد. در نتیحه تیم میتواند از سازوکار خاص خود برای رسیدن به هدف استفاده کند.)
دوم آنکه اولویتبندی کارها را مشخص کند. اهداف و نیازهای مالک محصول در فهرستی موسوم به Product Backlog قرار میگیرند. یک Product Backlog تمامی درخواستها و ویژگیهای مدنظر مالک محصول که در محصول وارد خواهند شد را در خود جای میدهد. این فهرست نیازها بر مبنای معیارهای خاصی مرتبسازی میشود. این مرتبسازی اولویتها جزء وظایف مالک محصول است. روال کار به این صورت است که درخواستها بر اساس اولویتهای تجاری کسبوکار مالک یا ذینفعان تنظیم میشود. دقیقا مطابق با همان قاعدهای که در شمارههای آغازین این سری به آن اشاره کردیم. اولویتهای مشتریان شناخته شده یا سرمایهگذاران در ارجحیت قرار دارند.
اولویتبندی درخواستها و نیازها چگونه انجام میشود
در اسکرام نقشی برای تیم در نظر گرفته شده است. اصلیترین وظیفه تیم، تکمیل محصول نهایی است. در پروژههایی که تیم متشکل از طیف گسترده از افراد است، اسکرام این انعطافپذیری را به وجود آورده است تا یک تیم بزرگ را به تیمهای چندگانه و مجزا تقسیم کرد.
اسکرام پیشنهاد میکند هر تیم متشکل از پنج تا نه نفر باشد. تیمهای اسکرام در مقایسه با سایر تیمها از چند ویژگی شاخص برخوردار هستند: اول آنکه قابلیت خود سازماندهی (Self-Organize) دارند، در نتیجه از روش ریزمدیریتی (مدیریت دستور-کنترل) در ساختار این تیمها استفاده نمیشود و تیمها توانایی خودسازماندهی دارند.
ویژگی خودسازماندهی نحوه انجام یک وظیفه را به تیمها ابلاغ نمیکند و اجرای دستورالمعلهای دیکته شده را از آنها انتظار ندارد، بلکه به تیمها اعلام میکند که چه کاری را درنظر داریم انجام دهیم.
دوم آنکه تیمها بر مبنای عملکرد متقابل کار میکنند، اعضا هر تیم به صورت افزایشی در فکر پیادهسازی واحد کوچکی هستند که معروف به Story است. هر داستان توصیف کننده عملیاتی است که برای تکمیل محصول باید انجام شود.
سوم آنکه رفتار تیمهای اسکرام متفاوت با رفتار تیمهای دیگر است. تیمهایی که بر مبنای متدولوژیهای مختلف کار میکنند به طور معمول به صورت مولفهای کار کرده و هدفشان تکمیل جزیی از محصول هست. چهارم آنکه تیم مقدار کاری که در مدت زمان یک اسپرینت دو تا چهار هفتهای باید انجام شود را مشخص میکند. پنجم آنکه تیم مشخص میکند کارها چگونه باید انجام شوند.
پیشنهاد مقاله: بازاریابی دیجیتال چیست و چرا همگان به دنبال یادگیری آن هستند؟
در شروع هر اسپرینت یکسری از درخواستهای مشتری با توجه به ظرفیت تیم که در اصطلاح تخصصی به آن سرعت تیم گفته میشود، انتخاب شده و در فهرست Sprint Backlog وارد میشوند. این فهرست تمامی درخواستهای مدنظر مشتری را در خود جای میدهد.
درخواستهایی که تیم طراحی کننده ضمانت کرده است در این اسپرینت آنها را پیادهسازی کند. درخواستهای مشتری چه آنهایی که در Product Backlog قرار دارند و چه آنهایی که در Sprint Backlog طبقهبندی شدهاند، همگی در قالبی به نام User Story نگهداری میشوند.
جالب آنکه User Story زبان خاص خود را دارد. به عبارت دیگر توصیفات به جای آنکه اختصارات فنی باشند، علایم تجاری هستند که برای بسیاری از مشتریان قابل درک هستند. مالک محصول این توصیفات را با کمک اعضا تیم آماده میکند.
در شروع هر اسپرینت تعدادی از درخواستهای مشتری با توجه به ظرفیت تیم انتخاب میشوند. توانایی تیم بر اساس دو فاکتور تعیین ظرفیت اسپرینت با توجه به کارکرد تیم در اسپرینتهای قبلی و تعیین ظرفیت تیم بر اساس توان نیروی کار موجود و میزان توجه آنها به کار قابل ارزیابی و تشخیص است.
تیم بر مبنای ظرفیت/سرعت خود و همچنین رعایت اولویتهای تعیین شده از سوی مالک محصول تعدادی از درخواستهای مشتری را از داخل Product Backlog انتخاب کرده و به Sprint Backlog وارد میکند. این فعالیتها در مدت زمان برگزاری جلسه برنامهریزی اسپرینت سازماندهی میشود. جلسات در ابتدای هر اسپرینت برگزار میشوند.
در گام بعد تیم فرآیند پیادهسازی درخواستهای مشتری را آغاز میکند. برای آنکه کارها به شکل منظمی انجام شوند و اعضای تیم اعلام دارند در نظر دارند چه کاری را انجام داده و به انجام چه کاری تمایل دارند، جلسهای با عنوان جلسه روزانه اسکرام که به صورت روزانه و در اول وقت کاری و به مدت حداکثر ۱۵ دقیقه برگزار میشود، تشکیل میشود.
در این جلسه هر یک از اعضا تیم سه سوال کلیدی را بیان کرده و به آنها پاسخ خواهد داد. دیروز چه کاری انجام داده است؟ امروز در نظر دارد چه کاری انجام بدهد؟ چه موانعی پیش روی او قرار دارد و در کار انجام شده با چه موارد پیشبینی نشدهای برخورد کرده است.
طرح این سوالات باعث شفافت شدن عملکرد تیم شده و انعطافپذیری خوبی به تیم میدهد. زمانی که اسپرینت به پایان رسید، تیم، پیشنمایشی از موارد کامل شده را آماده میکند. این پیشنمایش در مدت زمان برگزاری جلسهای تحت عنوان Sprint Review در معرض دید آزمایشکنندگان/مشتریان قرار میگیرد. این جلسه به منظور دریافت بازخوردهای مالک محصول و افرادی که در جلسه حضور دارند برگزار میشود.
در این جلسه تیم بازخوردهای ارائه شده را دریافت کرده و آنها را در Product Backlog پیادهسازی میکند. این راهکار به منظور دریافت و کنترل تغییرات مورد استفاده قرار میگیرد. جلسهای که بعد از اتمام هر اسپرینت، برگزار میشود و آخرین جلسه است، جلسه بازبینی عملکرد اسکرام نام دارد.
این جلسه به منظور بهبود کارکرد تیم برگزار شده و تنها اعضا تیم در آن حضور دارند. در این جلسه عملکردهای اسپرینت بررسی و برای آینده راهحلی ارائه میشود. در این جلسه پرسشهایی همچون، کدامیک از عملکردهای ما درست بودهاند، کدامیک از عملکردهای ما به ویرایش نیاز دارند و چه تغییراتی برای بهبود فعالیتها در آینده ضروری هستند بیان میشود.
راهکارها و راهحلهای ارائه شده در این جلسه دو ساعته به مرور زمان در اسپرینتهای بعدی پیادهسازی خواهند شد. در پایان لازم به ذکر است که علاوه بر خود تیم نقشی به نام مدیر اسکرام نیز در داخل تیم وجود دارد. کار این نقش مدیریت پروسه اسکرام است. این نقش در وهله اول پروسه اسکرام را در سازمان کلید زده و در وهله دوم کنترل میکند آیا تیم و مالک محصول، اسکرام را به درستی مورد استفاده قرار دادهاند یا خیر؟
علاوه بر اینها وظیفه حذف موانع از پیش روی تیم در مدت زمان بهکارگیری اسکرام بر عهده مدیر اسکرام است. برای هر تیم باید یک مدیر اسکرام و مالک محصول مجزا وجود داشته باشد. مدیر اسکرام را میتوانید همانند مدیرتولید در برنامههای تلویزیونی در نظر بگیرید.
کلام آخر
همانگونه که مشاهده کردید، توسعه چابک نرمافزاری در چالاکی متخصصان بازاریابی نقش تاثیرگذاری دارد. بهطوری که نه تنها به روند بازاریابی شتاب میبخشد، بلکه قادر است آنرا هدفمند سازد.
همچنین دیدیم چهارچوبهایی نظیر اسکرام تا چه اندازه فرآیند تولید محصولات (چه نرمافزاری و چه سختافزاری) را در قالب یک برنامه زمانبندی دقیق خطدهی کرده و به ظریفترین شکل ممکن تقسیمبندی کارها میان اعضا تیم را مدیریت میکنند.
جلسات مختلفی که میان مدیر پروژه، اعضا پروژه و آزمایشکنندگان محصول برگزار میشود باعث میشود تا کمینه حداقلی یک محصول به درستی آماده شده و به مرور زمان ویژگیهای کلیدی و موردنیاز مشتریان به محصول اضافه شود.
منابع
http://labs.openviewpartners.com/what-is-scrum-infographics/5
https://www.quora.com/Can-you-build-startups-with-scrum-methodology
https://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG
http://tynerblain.com/blog/2010/08/24/inside-a-scrum-sprint/
https://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/
http://blog.crisp.se/2008/02/12/mattiasskarin/1202847600000
http://www.scrumguides.org/scrum-guide.html
https://www.scrumalliance.org/why-scrum
http://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/
http://www.agilenutshell.com/scrum
https://cb.hbsp.harvard.edu/cbmp/product/86116-PDF-ENG