یه مقاله در سال 2012 در مورد مقیاس پذیری متد چابک در اسپاتیفای نوشته شد که میخوام هر چیزی ازش فهمیدم رو باهاتون در میون بزارم.
سعی کردم این مقاله رو خیلی خودمونی تر توضیح بدم و پیشاپیش ازتون ممنونم برای انتقادات و پیشنهادات تون.
تا حالا به این فکر کردید که اصلا چجوری میشه با متد به این سادگی در عین حال استارت اپی، کمپانی بزرگی مثله اسپاتیفای رو سازمان دهی کرد؟؟
یکی از تاثیرگذارترین نمونه هایی که از متد اجایل استفاده میکنه، پلتفرم "Spotify" هست که با وجود بیشتر از 30 تیم تو 3 تا شهر، ذهنیت چابکی(یعنی استفاده از متد اجایل برای مدیریت پروژه) رو حفظ کرده.
این شرکت از حدود سال 2008 فعالیت خودش رو شروع کرده و الان که طبق مقاله میشه سال 2012، بیشتر از 15 میلیون کاربر فعال و بیشتر از 4 میلیون کاربر پرداخت کننده داشته.
خود محصولشون رو می شه گفت " یه نوع پخش کننده موسیقی مثله رادیو جوان که میتونه توی یه چشم بهم زدن همه آهنگ های جهان رو پیدا و پخش کنه.حالا فرقش با بقیه برنامه های مشابهش چیه که این قدر طرفدار داره؟ (این دقیقا همون چیزیه که میخوایم در موردش صحبت کنیم.)
یکی از بنیانگذاران توسعه نرم افزار چابک به اسم "Alistair Cockburn" از Spotify دیدن کرده و گفته: "که از سال 1992 به دنبال کسی بوده که این فرمت ماتریس رو پیاده سازی کنه :) بنابراین از دیدنش واقعاً خوش حاله."
برای مدیریت سازمان های بزرگ با متد اجایل از مقیاس پذیری استفاده میشه که میخوایم یه مقاله درمورد مقیاس پذیری این متد در پلتفرم اسپاتیفای رو با هم مرور کنیم.
اینم بگم که Spotify (مثله هر شرکت چابک خوبه دیگه ای) به سرعت در حال پیشرفته. این مقاله فقط یک تصویر از روش کار این پلتفرمه و ممکنه از سال 2012 تا الان تغییراتی کرده باشه.
مقیاس پذیری متد چابک تو پلتفرم اسپاتیفای(Spotify) با دسته بندی هایی انجام میشه که در ادامه باهاشون آشنا میشیم .
سوال اینجاست که این پلتفرم پیچیده چجوری میدیریت میشه؟
بیاید از قسمت های کوچیک این ساطمان شروع کنیم:
تیم Squad شبیه تیم Scrum هست و طوری طراحی شده که مثله یک استارتاپ کوچیک به نظر برسه.اعضای Squad کنار هم می نشینن و تمام مهارت ها و ابزارهای مورد نیاز برای طراحی ، توسعه ، آزمایش و پیاده سازی به پلتفرم رو در اختیار دارن. درواقع Squad یک تیم خود سازماندهی هستن و روش کار خودشون رو خودشون تعیین میکنن.
حالا یه سری شون از اسپرینت های Scrum و یه سری از Kanban و حتی یه سری از ترکیبی از این روش ها استفاده می کنن و خلاصه یه قانون واحد دست و پا بسته سازمانی ندارن!
هر کدوم از تیم های Squad یه ماموریت بلند مدت داره (مثله ایجاد و بهبود مشتری Android یا ایجاد تجربه رادیویی Spotify یا مقیاس بندی سیستم های پشتیبان یا ارائه راه حل های پرداخت یا ...)
به تصویر زیر توجه کنید لطفا. تصویر نشون می ده که چجوری تیم های Squad مختلف مسئولیت قسمت های مختلف تجربه کاربر رو به عهده می گیرن.
تیم های"Squad" تشویق می شن تا اصول Lean Startup مثله MVP یا همون (حداقل محصول قابل اجرا) رو توی تولید محصول خودشون اعمال کنن. اگه بخوام خیلی خلاصه بگم ام وی پی چیه، میتونم اینجوری بگم که MVP یعنی ارائه محصول به صورت اولیه و استفاده از معیارها و A/B تست برای بررسی کاربردی و مشکل های احتمالی محصول است.
از اونجا که هر تیم با یه ماموریت و یه قسمت از محصول به مدت طولانی در ارتباط هستن، می تونن در یه زمینه متخصص بشن. (مثلا ایجاد یک تجربه رادیویی عالی به چه معناست.)
برای تشویق به یادگیری و نوآوری ، هر "تیم squad" تشویق می شه که تقریباً 10 درصد از وقت خودش رو تو "روزهای هک"(hack days) صرف کنه.
در طول "روزهای هک" اعضای squad هر کاری که می خوان انجام می دن ، معمولاً ایده های جدید رو امتحان می کنن و با دوستای خودشون به اشتراک می گذارن.
این "تیم های squad"یه رهبر مشخص و رسمی ندارن، اما هر کدوم یه "صاحب محصول" دارن."صاحب محصول" مسئول اولویت بندی کارهایی هست که باید توسط تیم انجام بشه، اما درگیر نحوه انجام کار آنها نیستن.
صاحبان محصول تیم های مختلف، با همدیگه همکاری می کنند تا یک سند نقشه راه، درسطح بالا بنویسن که نشون بدن "Spotify" به طور کلی به کجا می ره و چه نیازمندی هایی داره و هر "صاحب محصول" مسئول حفظ و پیاده سازی بخشی از سند محصول متناسب با تیم خودش هست.
یه "تیم squad" یه مربی متد چابک هم داره که به تیم کمک می کنه تا روش کار شون رو بهبود ببخشه.
در حالت ایده آل ، هر"تیم squad" کاملاً مستقله و مستقیماً با ذینفع های خودش در تماسه و وابستگی به سایر "تیم های squad"برای پیشبرد کار خودش رو نداره.پس اساساً یک استارتاپ کوچکه! برای بررسی دقیق تر هر اسکواد به صورت فصلی تیم ها ارزیابی و مصاحبه میشن.
اینجا یه خلاصه بصری از یه نظرسنجی وجود داره که 5 تیم رو در یه خانواده "tribe" نشان می ده:
دایره ها وضعیت فعلی رو نشون می دن و فلش ها "روند (trend)" رو نشون میدن. به عنوان مثال ، ما می تونیم الگویی رو مشاهده کنیم که "تیمsquad " 4 با پشتیبانی مربی چابک وضعیت فوق العاده ای نداره ، اما در حال پیشرفته.
میخوایم یه سری مفهوم های پایه اجایل که داخل جدول قبل بود رو با هم مرور کنیم:
گروه بندی بعدی ترایب "Tribe" هست.
گروه بندی"tribe" مجموعه ای از تیم های "squad" هست که توی زمینه های مرتبط کار می کنن (مثله تیم های پخش موسیقی یا تیم های زیرساخت های پشتیبان)
هر "گروه tribe" یه رهبر "tribe"داره که وظیفه ارائه بهترین بستر ممکن برای تیم های "squad" توی گروه" tribe" رو داره.
تیم های "squad" توی یه گروه "tribe" از نظر فیزیکی توی یه دفتر کار هستن و به طور معمول درست در کنارهم مستقر هستن که باعث تقویت همکاری میشه.
اندازه گروه های "tribe" بر اساس مفهوم“Dunbar number” هست، که می گه اکثر مردم نمی تونن با بیشتر از 100 نفر رابطه اجتماعی برقرار کنن (این تعداد در واقع برای گروه هایی که تحت فشار شدید بقا هستن، بیشتر هست. وقتی گروه ها خیلی بزرگ می شن ، چیزهای بیشتری مثله قوانین محدود کننده ، بوروکراسی ، سیاست رو توی لایه های اضافی مدیریت سازمان شون می بینیم. بنابراین "گروه های tribe" طوری طراحی شده اند که کمتر از 100 نفر باشند.
گروه های"tribe" به طور منظم گردهمایی هایی رو برگزار می کنن و به بقیه گروه های "tribe" (یا هرکسی که حظورداره) نشون می دن که روی چه چیزی کار می کنن، یا چه چیزی رو تحویل دادن و بقیه از چه چیزی می تونن استفاده کنن. این گرده همایی ها شامل نمایشی زنده از ابزارها و تکنیک های جدید هست.
وابستگی توی تیم های Squad همیشه وجود داشت اما این وابستگی ها لزوماً بد نیستن. یه وقت هایی تیم های "squad " باید با هم کار کنن تا چیزی واقعاً عالی بسازن، جدول زیر میزان وابستگی های گروه ها رو در سازمان اسپاتیفای نشون میده.
این جدول داخل یه جلسه دور همی بررسی میشه که راههای از بین بردن وابستگی های مشکل ساز ، به ویژه مسدود کردن و وابستگی های بین تیم ها در اون جلسه مورد بحث قرار می گیره و اغلب منجر به اولویت بندی مجدد، سازماندهی مجدد، تغییرات معماری یا راه حل های فنی میشه. به عنوان مثال به نظر می رسه که تعداد بیشتری از تیم ها توسط تیم انجام عملیات کند میشن. پس تلاش میشه که تیم انجام عملیات رو تقویت کرد.
در نتیجه بررسی ارتباط بین گروه های ترایب سعی میشه ارتباط ها تا جای ممکن سازنده و هدفمند باشه و ارتباط های اضافه حذف بشه.
برای انجام این کار ، تیم ها یک جلسه همگام سازی روزانه دارن که در اون وابستگی های بین "تیم هایsquad " رو شناسایی و برطرف میکنن و از تخته ای با یادداشت های چسبنده برای پیگیری وابستگی های حل نشده استفاده میکنن.
توی Spotify یک تیم عملیاتی جداگانه وجود داره، که وظیفه اونها این هست که به تیم ها حمایت لازم رو برای انتشار رو ارائه بده، اما وظیفه اونها این نیست که برای تیم ها خود اقدام به انتشار رو انجام بدن پس در حد پشتیبانی در قالب زیرساخت ها خدمت ارائه میدن، در واقع تیم عملیاتی یه جورایی راه تولید رو میسازن.
حالا به یه سوال بزرگ میرسیم:
اگر هر تیم"squad" کاملاً خودمختار باشه، و هیچ ارتباطی با تیم "squad" دیگر نداشته باشه، پس داشتن یک شرکت منسجم چجوری امکان داره؟
برای انسجام شرکت و انتقال تجربه ها شعب "Chapter" و بخش "Guild" ایجاد شدن که برخی از مقیاس های اقتصادی رو به وجود میارن، بدون این که استقلال زیادی رو تحت تاثیر قرار بدن!
شعب"Chapter" در واقع گروهایی هستن برای افرادی که توانایی های مشابه و شایستگی های هم سطح دارن و در یک سطح کاری در تیم های مختلف و در یکگروه "tribe" فعالیت میکنن .
هر شعبه "Chapter" به طور منظم ملاقات هایی دارن تا در مورد تخصص و چالش های خاص خودشون بحث کنن.مثلا چند تا از شعب میتونن با این عنوان ها باشن: شعبه "تست و آزمایش" ، شعبه" توسعه دهنده وب" یا شعبه" پشتیبان".
بخشی ازهدایت شعبه"Chapter" مربوط به کارهای روزانه تیم "squad" هست که کمک می کنه تا با فعالیت های جاری در ارتباط باشن. به عنوان مثال، اعضای شعبه "Chapter" به طور مساوی در تیم های "squad" توزیع نشدن؛ مثلا بعضی از تیم های "squad" دارای توسعه دهندگان وب زیادی هستن، بعضی از اونها نه.
بخش"Guild" یک "جامعه مورد علاقه" گسترده است. گروهی از افراد که می خواهند دانش ، ابزار ، کد و شیوه های خود را به اشتراک بگذارند. شعب"Chapter" همیشه محلی واقع در گروه های" Tribe" است ، در حالی که بخش"Guild" معمولاً کل سازمان رو در بر می گیره.اگه بخوام چند تا بخش "Guild" مثال بزنم :بخش فناوری، بخش وب، بخش تستر، بخش مربیان چابک و غیره.
هر بخش"Guild" اغلب شامل همه شعبه "Chapter" هایی هست که در اون منطقه کار می کنن (به عنوان مثال "بخش آزمایش" شامل همه آزمایش کنندگان در همه شعبه "Chapter"های آزمایش هست)اما اعضای اونها ، هر کسی که علاقه مند باشه میتوانه به هر بخش"Guild" بره و عضو بشه.
هر بخش "Guild" یه "هماهنگ کننده بخش" داره که کار های هماهنگی رو انجام میده.
ولی یه خطر کل ساطمان چابک رو تحدید میکنه اونم این هست که اگه نباشه یه بر یکپارگی سیستم تمرکز کنه کل معماری سیستم خراب میشه.
برای کم شدن این خطر یه نقش به اسم "مالک سیستم" وجود داره. برای سیستم های بسیار مهم ، مالک سیستم یک جفت Dev-Ops هستن(یعنی یک نفر با دید توسعه دهنده و یک نفر با دیدگاه عملیات). مالک سیستم برای هرگونه مشکل فنی یا معماری مربوط به اون سیستم، به طور تخصصی فعالیت نمیکنن و یه هماهنگ کننده وجود داره برای هماهنگی ها به اسم اسکرام مستر.
مالک سیستم روی مواردی مثله روند ارتقا کیفیت ، اسناد ، مشکلات فنی ، ثبات ، مقیاس پذیری و انتشار تمرکز می کنن. مالک محصول معمار حلال مشکلات نیست! و شخصاً مجبور نیست همه تصمیمات رو بگیره ، یا همه کدها رو بنویسه!
مالک محصول معمولاً عضو تیم "squad" یا سرپرست بخش "chapter" هست که علاوه بر مالک سیستم، مسئولیت های روزانه دیگه هم داره.
مالک محصول، توسعه سیستم های جدید رو مرور می کنه تا مطمئن بشه که از اشتباهات رایج جلوگیری شده و با دید معماری پلفترم همخوانی لازم وجود داره.نوع بازخورد ها همیشه فقط پیشنهادات و ورودی است و تصمیم برای طراحی نهایی سیستم هنوز با تیمی هست که در خالت فعالیت برای ساخت هست.
ولی این سیستم به صورت کلی چگونه کار میکنه؟ Spotify بسیار سریع رشد کرده است ! طی سال های فعالیتش از 30 تا 250 نفر کارمند در زمینه فناوری داشته!!
این مدل مقیاس بندی - با "Squads" ، "Tribes" ، "Chapters" و "Guilds" - چیزی هست که طی یک سال به تدریج معرفی شد ، در آوریل 2012 این میزان 4.4 از 5 بوده. با این حال ، مثله هر سازمان در حال رشد ، راه حل های امروز مشکلات فردا رو به وجود میاره.پس انتظار تغییرات در این نوع مدیریت وجود داره.
منبع:
Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds Henrik Kniberg & Anders Ivarsson Oct 2012
