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

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

مسئله:

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

برای یافتن راه حل ، جلسات بازاندیشی (رترو) اسپرینت را تسهیل گری کنید:

در جلسه بازاندیشی تیم، این مسئله به عنوان مشکل اصلی مطرح شد و ما سعی کردیم راه حل هایی برای این چالش پیدا کنیم:

راه حل ۱:

“تسک های بک‌اند و طراحی را یک اسپرینت قبل شروع کنیم” این یکی از راه حل های پیشنهادی بود. این مثال را در نظر بگیرید، ما می خواهیم یک صفحه لاگین ایجاد کنیم، بنابراین بگذارید آن را به ۳ تسک تقسیم کنیم: ۱- طراحی صفحه ورود به سیستم ۲- پیاده سازی API ورود به سیستم ۳- اجرای فرانت‌اند ورود به سیستم.

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

براساس راهنمای اسکرام:

“اسکرام از رویکرد چرخشی و افزایشی برای بهینه سازی پیش بینی پذیری و کنترل ریسک استفاده می کند.”

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

سارا: “ما هیچ گزینه دیگری نداریم ، …”

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

“اگر می خواهید طرز تفکر جدیدی به مردم بیاموزید، سعی نکنید آنها را آموزش دهید. درعوض، ابزاری در اختیار آنها قرار دهید که استفاده از آنها موجب تفکر جدید شود. ” باکمینستر فولر

راه حل ۲: هجوم سه تفنگ دار

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

۱- به جای وایرفریم یا پروتوتایپ با کیفیت بالا، با وایرفریم های با کیفیت پایین شروع کنید

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

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

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

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

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

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

۲- در مورد قرارداد API توافق کنید

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

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

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

MockAPI.io یکی از ابزارهای عالی است که با استفاده از آن به راحتی یک API ماک ایجاد کنید.

یا Mock.io یکی دیگر از ابزارهای عالی است که می توانید نوع دیگری از Mock API ها را ایجاد کنید (Mock API برای میکروسرویس ها ، Mock JSON API ، Fake JSON API)

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

چابک و موفق باشید

اسد صفری

نسخه انگلیسی این نوشته در سایت FactfulAgility.com