پیاده سازی اسکرام در یک پروژه دولتی در آمریکا

معرفی

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

مقدمه

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

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

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

بک گراند

یک فرضیه ای که وجود دارد این است که تخمین زدن کارها معمولا کاری بیهوده است. در پروژه ی EVE-MOD نیز دقیقا همین طرز فکر درباره ی استوری پوینت وجود داشت و جلسات Refinement  صرفا به یکسری محاسبات استوری پوینتی تبدیل شده بود تا یک گفتمان موثر بین تیم ها و PO. به شما پیشنهاد می‌کنم حتما هشتگ NOESTIMATE را در دنیای واقعی جست و جو کنید.

تیم پرواکت

USCIS یک آژانس در سازمان DHS میباشد. پروژه ی E-Verify که در سال ۱۹۹۶ آغاز شد،یک سیستم USCIS میباشد که در آن کارفرما ها میتوانند صلاحیت نیروهای انسانی را تایید کنند.درسال  ۲۰۱۶ USCIS تصمیم گرفت تا با مدرنیزه کردن E-Verifyبتواند محدودیت ها و دردسرهای یک پلتفرم دولتی را از بین ببرد و بتواند بر اساس یک معماری ابریِ درست، پایداری و کیفیت این سیستم را ارتقا دهد و خلاصه این بود که سفر دوساله ی ما با نام EVE-MOD آغاز شد…

EVE-MOD با چارچوب اسکرام اما در یک مقیاس بزرگ و در قالب سه تیم اسکرام پیش می‌رفت. هرکدام از این تیم ها یک ساختار پایدار داشته و به صورت موازی با هم کار می‌کنند و نیز توانایی این را دارند تا فیچر های مشتری را پیاده سازی کنند. هرتیم یک اسکرام مستر، تحلیگر کسب و کار، مهندس DevOps و تعدادی برنامه نویس دارد.  EVE-MODتلاش کرد تا بتواند با ایجاد پایپ لاین CI/CD این امکان را ایجاد کند تا تیم بتواند بیش از ده بار در روز کدهای تعیین شده شده خود را در ۲۰ الی ۳۰ دقیقه به راحتی مستقر کند که این با توانایی های مهندسین DevOps میسر می‌شود.

توضیح اجایل در مقیاس، کار پیچیده ای است. شاید برایتان سوال پیش بیاید که چرا از واژه مقیاس استفاده می‌ کنیم. علت این است که ما درقالب سه تیم و بر روی یک محصول و در راستای رسیدن به یک هدف کار می‌کنیم. ما مارچ ۲۰۱۶ با یک تیم اسکرام شروع کردیم و نزدیک به یکسال با همان یک تیم ادامه دادیم و در می ۲۰۱۷ به دو تیم ارتقا یافتیم و در نهایت در پاییز ۲۰۱۸ تبدیل به سه تیم شدیم. ممکن است مانند پروژه ما تعدادتان زیاد شود و یا ممکن است مانند خیلی از تیم ها تعدادتان کم شود اما نکته ای که باید به آن توجه کنید این است که تا یک تیم به مرحله درستی از کارایی و موفقیت در اهدافش نرسیده، اجازه ندهید که بزرگتر شود. به نظر من اینکه ما ۵۵ هفته با روش بدون مقیاس پیش رفتیم می‌تواند موفقیت بزرگی در ادامه مسیرمان ایجاد کند.

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

شروع مسیر جدید : یکسال بدون تخمین

برنامه این بود که بتوانیم اپلیکیشن مدرنیزه شده را با پلتفرم قدیمی خودش و سیستم های upstream(برای ایجاد دیتا) و سیستم های downstream(حلِ دستی مسائل پیچیده) ادغام کنیم که تعداد این سیستم ها درمجموع ۵ عدد بود و پلتقرم قدیمی و هرکدام از سیستم ها سمت یک تیم پروداکت دیگر مدیریت می‌شد. ما مشاهده کردیم که کارهای خودمان (EVE-MOD) طبق روال پیش می‌رود اما زمانی‌که می‌خواستیم فرآیند آزمایش یکپارچگی را انجام دهیم متوجه شدیم که درخصوص API ها بین تیم ها مشکلاتی ایجاد شده و درنتیجه از برنامه نویس های تیم خواستیم تا برای پیدا کردن مشکل با تیم های دیگر زمان بگذارند.

در ادامه یکی از اسکرام مستر ها برد کانبان درست کرده و سعی کردیم جریان کار بین تیم ها (EVE-MOD، پلتفرم قدیمی، استریم سیستم ها) رو به شکل بصری پیش ببریم. چند نفر از افراد EVE-MOD را به عنوان نقطه ارتباطی بین خودمان و تیم های دیگر انتخاب کردیم که به صورت منظم بایکدیگر جلسه داشته و چالش و کارهای پیش رو را مدیریت کنند. همچنین دو تیم هر روز بعد از جلسه روزانه، یک جلسه روزانه دیگر داشتیم تا بتوانیم به صورت یکپارچه وضعیت فعلی و آینده خود را بررسی کنیم.

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

بعد از مدتی ناهماهنگی بزرگی را مشاهده کردیم، تیم ما (EVE-MOD) در زمان‌های مشخص شده کارش را تحویل می‌داد اما همکاران ما (پلتفرم قدیمی، استریم سیستم ها) نمی‌توانستند طبق برنامه ریزی پیش بروند و با تاخیرهای پی در پی باعث عقب افتادن نتیجه کار می‌شدند. همین باعث شد که تیم ما زمان زیادی را صرف کمک به همکارانش کند. اواسط مارچ ۲۰۱۸ مشاهده کردیم که تسک های اسپرینت ما پر شده بود از کارهای متفرقه ای که برای این تاخیرها انجام می‌دادیم و مشاهده کردیم که روال کاری اسپرینتی ما (که دوسال با آن پیش می‌رفتیم و مشکلی نداشتیم) دیگر جواب نمیداد!

ما باید یک تغییری را آغاز می‌کردیم، خوشبختانه آزمون یکی از پنج معیار ارزش ما در EVE-MOD بود!

این پنج معیار ارزش در EVE-MOD به شرح زیر بود :

Empathy (همدلی)

Empowerment (توانمند سازی)

Experimentation (آزمون و خطا)

Enthusiasm (اشتیاق)

 Execution(اجرا)

آوریل ۲۰۱۸-کارگاه کانبان

تصمیم بر این شد که از اسکرام به کانبان تغییر جهت دهیم. در حالیکه خیلی ها فکر می‌کردند که پیاده‌سازی کانبان نمی‌تواند تصمیم خوبی باشد اما من و برخی دیگر معتقد بودیم که باید برای بهبود شیوه کارمان تغییرات و تصمیماتی بگیریم. در قدم اول یک روز کاری را  تعطیل کردیم و تمام افراد تیم را که نزدیک به ۳۰ نفر بودند به محوطه بیرون از سازمان بردیم و کارگاه کانبان را برگزار کردیم. پنجم آوریل ۲۰۱۸ کارگاه کانبان را با تیم ها آغاز کردم و در همان ابتدا انتظاراتم را برای انتهای آن پای تخته نوشتم:

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

ساعت ابتدایی کارگاه را صرف این کردیم که کانبان را به تیم آموزش دهیم و یکی از اعضای تیم (برنامه نویس) داوطلب شد تا در فرآیند آموزش به ما کمک کند. دِین وِبر یک اسکرام مستر با تجربه بود که به تازگی کلاس KMP خود را گذرانده بود و شش ماه می‌شد که برنامه نویسی را آغاز کرده بود و در سال ۲۰۱۹ گزارشی به نام “اسکرام مستر مخفی”  درباره تجربیات اخیرش منتشر کرده است. دِین به من کمک کرد تا بتونم یک دوره ۱۶ ساعته کانبان را در یک ساعت جمع‌بندی کنم. من با استفاده از یک برد ترلو ساده، مفهوم کار در حال انجام (WIP) و ایجاد محدودیت برای آن، استراتژی هایمان در کانبان، جریان های کاری و … را آموزش دهم.

در بخش بعدی کلاس را به سه گروه تقسیم کردیم و از آنها خواستیم که برای EVE-MOD برد کانبان طراحی کنند. برنامه ما این بود که این سه تیم مثل همیشه در قالب یک Product Backlog کارها را پیش ببرند و از گروه ها خواستیم که در انجام کارگروهی مشارکت داشته و هرکدام برای اظهار نظر حق داشته باشند. به همه گروه ها زمانی مساوی برای طراحی و انجام کار گروهی داده شد. آنها باید در مرحله بعد به پرسش ما جواب می‌دادند. پس از بحث های انجام شده قرار شد گروه بزرگتر برد محصول برایEVE-MOD  را طراحی کنند.

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

• اگر در حال کار روی وظیفه‌ای هستید، اطمینان حاصل کنید که در Backlog محصول ثبت شده است و نیز اسکرام مستر از آن آگاه است.
• وظیفه در حال انجام را در بخش درستی از نرم افزارتان (جیرا، ترلو، گیت و …) قرار دهید.
• جلسات اولویت بندی و برنامه‌ریزی را هر هفته ساعت ۱۵:۰۰ برگزار می‌کنیم تا مطمئن شویم در مسیر درستی حرکت می‌کنیم.
• اگر قرار است کاری غیر از اولویت های مشخص شده انجام دهید با PO و اسکرام مستر هماهنگ کنید.
• لطفا از پیش درباره جلسه بعدی کانبان فکر کنید.

بلافاصله پس از کارگاه، برخی از اعضای تیم برای ایجاد برد کانبان خود اقدام کردند. آن برد قبلی که پیشتر ایجاد کرده بودیم را پایین آوردیم و جلسات هماهنگی بین تیم ها (Scrum of scrum) را نیز کنسل کردیم.

ما سفر بزرگی را آغاز کردیم و اولین قدم هایمان نیز موفقیت آمیز بود اما این داستان ادامه دارد…

پایان قسمت اول