در بحث چابکی و خصوصا چارچوب اسکرام بحث های زیادی در خصوص تخمین و مشکلات آن، یا راهکار های برای استفاده مفید از آن ارائه شده است. ولی امروز میخواهم با نگاهی تازه به یکی از دلایل عدم تحقق تعهدات و تخمین ها بپردازم. همانطور که میدانید یکی از ستون های سه گانه اسکرام بحث شفافیت است. بحث شفافیت در اسکرام و همچین اصل “بهترین راه برقراری ارتباط گفتگوی فیس تو فیس است” در مانیفست چابک، اهمیت بحث شفافیت را از نقطه نظر نویسندگان مانیفست چابک و اسکرام برای ما روشن می نماید. اما چقدر به این موضوع در تیم های کاری خود توجه می‌نمایید؟
تا حالا پیش آمده که یک یوزر استوری که فاقد المان های صحیح نوشتن آن است را وارد اسپرینت نمایید؟ (پیشنهاد می نمایم اگر میخواهید بدانید چگونه یک یوزر استوری خوب بنویسید به لینک از سایت Atlassian رجوع نمایید). تا حالا شده که یا یک تماس تلفنی یا یک تیکت، اقدام به ورود آن به بک لاگ نمایید و در ادامه با نامیدن آن به عنوان یک یوزر استوری آماده، در اسرع وقت آیتم مربوط را به تیم توسعه ارائه دهید تا آن را انجام دهد، بدون اینکه مراحل تکمیل یوزر استوری طی شده باشد ؟ در اینجا به طور خلاصه منظور ما از یک یوزر استوری آماده تهیه آن بر اساس المان های مهندسی نیازمندی های نرم افزار و در نظر گرفتن استاندارد invest برای تکمیل یوزر استوری می باشد.
اگر به هر دلیلی، نظیر فورس پروژه، درخواست مشتری یا ابلاغ مدیران عالی، پاسخ شما به سوال بالا بله می باشد، پیشنهاد می نمایم تا انتهای این تجربه با من همراه باشید.
در تیم ها زیادی مشاهده کردم که با دلایلی نظیر موارد بالا و یا دیگر موارد نظیر شلوغی زیاد مالک محصول یا چند مسئولیتی بودن وی، نیازمندی به درستی شفاف نمی شود و مطابق اصول تبدیل به یوزر استوری استاندارد نمی گردد و در جلسات گرومینگ، برنامه ریزی و حتی حین اسپرینت هم زمان کافی برای شفاف سازی صورت نمی پذیرد. در برخی تیم ها مشاهده نمودم که خود مالک محصول هم نیازمندی را به درستی نمیداند !!! و یا با ذینقعان آیتم درخواستی را شفاف نکرده است و سپس اقدام به ارائه آن در تیم می نماید و با آوردن جملاتی تعهد آور نظیر اینکه این نیازمندی توسط مدیر عامل یا مدیر فروش ارائه شده سعی میکنند دلیلی محکم جهت چرایی اینکه تیم باید روی آن کار کنند ارائه می دهد. ( البته به غلط ) در مواجه با این درخواست ها تیم به دلیل عدم درک صحیح نیازمتدی دست نفرات باتجربه و ریش سفیدان را نگاه میکند و اینجا تنها با توجه به المان هایی نظیر روحیه فرد تجربه و حدسیات او نسبت به پذیرش یا عدم پذیرش آن اقدام می نماید. و یا ممکن است از سر اجباری فقط عددی را به عنوان تخمین بیندازد تا هم اسکرام مستر خوشحال شود و هم زودتر جلسه تمام شود تا تازه در خلوت خود به این فکر کند که چگونه این تعهد جدید را انجام دهم.
اگر چارچوب اسکرام به درستی جا افتاده باشد و روحیه چابکی در تیم و سازمان جایگاهی داشته باشد احتمالا نیازمندی غیر شفاف امکان ورود نخواهد داشت و در غیر اینصورت فاجعه آغاز می شود. بدیهی است که وقتی در دنیای پیچیده توسعه محصولات نرم افزار نیازمندی به درستی شفاف نشده باشد احتمال ارائه خروجی متضاد خواسته واقعی مشتری به طرز معنا داری افزایش پیدا میکند. همچین به جهت مشخص نبودن محدوده کار، و عدم شفاف سازی نیازمندی های عملکردی و غیر عملکرد، تیم توسعه در شروع کار با چالش های فراوانی مواجه می شود. زمانی که در یک محیط پیچیده ابهام زیادی را وارد کار تیم نماییم قطعا درخواست ارائه تخمین زمانی حتی با بهترین پرکتیس ها امری نشدنی و حتی غیر معقول است. متاسفانه در تیم هایی مشاهده می شود که حتی روی موارد با ابهام زیاد هم به شدت درخواست می شود که تیم‌تخمین زمانی بدهند و با عدم تحقق نیازمندی در زمان مورد نظر تیم مورد سرزنش قرار می گیرد. سناریو دیگری نیز که ممکن است مشاهده شود، تحویل نیازمندی در زمان مقرر اما بدون در نظر گرفتن استاندارد های کیفیت می باشد، که بعد از ریلیز نیازمندی، قطعا مشکلات و چالش های زیادی را برای محصول و تیم ایجاد خواهد نمود. نظیر دوباره کاری، نارضایتی مشتری و … همچنین در بیزنس های B2B سبب رد شدن فیچر ارائه شده و تاخیرات قرار دادی خواهد شد. برخی دیگر از مشکلات عدم شفافت سازی نیازمندی به شرح ذیل است:
سوالات متوالی حین توسعه
درگیری ذهنی بیش از حد تیم
ناراحتی استرس از عدم تحقق
فقدان کیفیت کد نوشته شده
درک اشتباه نیازمندی
دوباره کاری
تنش در تیم و …
و این موارد تنها بخشی از معضلات عدم شفافیت خواهد بود.
تمامی این عوامل در شرایطی رخ میدهد که وظیفه شفاف سازی آیتم های بک لاگ با نماینده تیم با ذینقعان است. یعنی همان مالک محصول. اصول مذاکره، مشخص شدن حد و حدود اختیارات، و امکان نه گفتن می تواند به مالک محصول در عدم پذیرش موارد غیر شفاف در اسپرینت های نزدیک یاری رساند، و زمان لازم را به مالک محصول نفرات تحلیل گر بدهد تا نیازمندی را ابتدا شفاف نمایند و مطابق با اصول مهندسی نیازمندی های نرم افزار اقدام به تدوین یوزر استوری نمایند. همچین از دیگر پرکتیس هایی که در مواجه با عدم قطعیت در نیازمندی به تیم ها کمک می‌نماید روش FACTFUL PLANNING می‌باشد. در این روش ضمن اینکه تیم بر اساس روش مذکور اقدام به بررسی و محک زنی نیازمندی می شود، از ارائه تعهدی خارج از واقعیت خود داری می نماید. تمامی این اقدامات کمک می نماید که تیم بتواند نسبت به آیتم هایی از backlog تعهد دهد، که از شفافیت کافی برخوردار باشد. این اطمینان در جلسات Refinment که به Grooming مشهور هستند رخ خواهد داد و اصطلاحا یوزر استوری ready for Develop می شود. برای یادرگیری این مفهوم می توانید مبحث Definition of Ready را فراگیرید و در تیم های خود اجرایی نمایید. همچنین در صورتی که به دلایلی نظیر چند مسئولیتی بودن مالک محصول امکان ارائه نیازمندی با اصول یاد شده نمی باشد در جلسات رتروسپکتیو می بایست این عامل شناسایی شود و راهکارهایی نظیر کمک گرفتن از نفرات تیم و یا تغییراتی در میزان مسئولیت های مالک محصول، به عنوان اقدام اصلاحی در نظر گرفته شود.
اسکرام و چابک به ما وعده کیفیت و رضایت مشتری را داده ولی به شرط درک و پیاده سازی صحیح، ارزش ها، چارچوب ها، قوانین و المان های آن. بدون در نظر گرفتن آن ها و یا پیروی از بخشی از آن، قطعا تحقیق وعده ها امری غیر ممکن خواهد بود.
لذا در‌انتها می بایست به این مهم توجه نماییم که جدای از اینکه تخمین خوب است یا بد، باید به این اصل توجه نماییم که شفافیت ستون اسکرام است و قطعا بدون شفاف سازی کامل و صحیح نیازمندی ها قطعا ارائه خروجی با کیفیت، در زمان منطقی غیر ممکن خواهد بود
چابک باشید
دیدگاهتان را بنویسید