انباشت کنترل نشده بدهی های فنی ناخواسته در صنعت نرم افزار رایج است. علت اصلی این تمایل این است که الگوهای ارتباطی ما ناکافی هستند. این منجر به مدل‌های ذهنی توسعه‌نیافته می‌شود و توسعه‌دهندگان راه‌حل‌هایی را برای مشکلاتی که بیان و درک ضعیفی ندارند با انبوه کردن پرچم‌های بولی و جریان‌های کنترل انشعاب تقریبی می‌کنند.
“بدهی فنی” غیرعمدی محصول فرعی یک فرآیند توسعه نرم افزار ناکارآمد است که با ارتباطات ضعیف آغاز می شود. ارتباطات ضعیف باعث می شود که مسائل سازمانی مانند تضاد منافع کنترل نشود و منجر به شفاف سازی ناکافی مشکل برای حل شود. این مانع از توانایی ما برای ایجاد یک مدل ذهنی مناسب از مشکل می شود، که در نهایت خود را در کد پیچیده ای نشان می دهد که ما آن را “بدهی فنی” می نامیم.
تمرکز بر علائم (“بدهی فنی”) یک فرآیند توسعه ناکارآمد به جای دلایل زمینه ای، ناکارآمد است، زیرا روند شکسته سریعتر از آن چیزی که تیم توسعه بتواند به مشکلات قدیمی رسیدگی کند، مشکلات جدیدی ایجاد می کند. این مشکل به عنوان “فنی” قاب بندی می شود زیرا پیامدهای آن در کد آشکار می شود و به این دلیل که اگر به کد محدود شود برای همه راحت تر است. با این حال، چارچوب بندی آن به عنوان چیزی که «توسعه دهندگان» می توانند آن را «پاکسازی» کنند، با عمیق تر کردن شکاف بین «کسب و کار» و «توسعه دهندگان» به فرآیند شکسته توسعه کمک می کند، شکافی که امیدواریم بتوانیم با پل زدن بر این روند و در نهایت مشکل جدی “بدهی فنی” آن را برطرف کنیم.
وارد کانینگهام استعاره فنی بدهی را اختراع کرد تا توسعه دهندگان را قادر سازد تا تجار بتوانند با چیزی که برای اولی قابل مشاهده است، اما از دومی پنهان است، ارتباط برقرار کنند. به طور تئوری رفع این مشکل آسان است: سخاوتمندانه هر از چند گاهی به توسعه دهندگان زمان بدهید تا خانه خود را تمیز کنند. تنها لازم است تاجران کمی صبر کنند تا توسعه دهندگان به اهداف تعیین شده به درستی دست یابند. اما در حقیقت، این مشکلی نیست که توسعه دهندگان بتوانند به تنهایی آن را حل کنند. در واقع، تصور اینکه توسعه دهندگان می توانند و باید بدهی فنی را به تنهایی مدیریت کنند، نشانه ای از نوع تفکری است که منجر به بدهی فنی می شود.
با گذشت زمان، بهترین رویکرد برای کاهش آنچه که ما آن را «بدهی فنی» می‌نامیم، پرداختن به علت اصلی است، یعنی نحوه همکاری ما. تغییر فرهنگ یک سازمان نرم افزاری می تواند دشوار باشد. ابتکارات از بالا به پایین اغلب با مشکل مواجه می شوند، زیرا آنها در رسیدگی به مشکلاتی که در میدان مشاهده می شوند شکست می خورند. شاید بهترین ابتکار از بالا به پایین اعطای آزادی عمل و استقلال به افرادی که در پایین هستند، باشد، زیرا امکان ایجاد تغییرات مثبت از پایین به بالا وجود دارد.
تمرکز بر علائم (“بدهی فنی”) یک فرآیند توسعه ناکارآمد به جای دلایل زمینه ای، ناکارآمد است، زیرا روند شکسته سریعتر از آن چیزی که تیم توسعه بتواند به مشکلات قدیمی رسیدگی کند، مشکلات جدیدی ایجاد می کند. این مشکل به عنوان “فنی” قاب بندی می شود زیرا پیامدهای آن در کد آشکار می شود و به این دلیل که اگر به کد محدود شود برای همه راحت تر است. با این حال، چارچوب بندی آن به عنوان چیزی که «توسعه دهندگان» می توانند آن را «پاکسازی» کنند، با عمیق تر کردن شکاف بین «کسب و کار» و «توسعه دهندگان» به فرآیند شکسته توسعه کمک می کند، شکافی که امیدواریم بتوانیم با پل زدن بر این روند و در نهایت مشکل جدی “بدهی فنی” آن را برطرف کنیم.
وارد کانینگهام استعاره فنی بدهی را اختراع کرد تا توسعه دهندگان را قادر سازد تا تجار بتوانند با چیزی که برای اولی قابل مشاهده است، اما از دومی پنهان است، ارتباط برقرار کنند. به طور تئوری رفع این مشکل آسان است: سخاوتمندانه هر از چند گاهی به توسعه دهندگان زمان بدهید تا خانه خود را تمیز کنند. تنها لازم است تاجران کمی صبر کنند تا توسعه دهندگان به اهداف تعیین شده به درستی دست یابند. اما در حقیقت، این مشکلی نیست که توسعه دهندگان بتوانند به تنهایی آن را حل کنند. در واقع، تصور اینکه توسعه دهندگان می توانند و باید بدهی فنی را به تنهایی مدیریت کنند، نشانه ای از نوع تفکری است که منجر به بدهی فنی می شود.
با گذشت زمان، بهترین رویکرد برای کاهش آنچه که ما آن را «بدهی فنی» می‌نامیم، پرداختن به علت اصلی است، یعنی نحوه همکاری ما. تغییر فرهنگ یک سازمان نرم افزاری می تواند دشوار باشد. ابتکارات از بالا به پایین اغلب با مشکل مواجه می شوند، زیرا آنها در رسیدگی به مشکلاتی که در میدان مشاهده می شوند شکست می خورند. شاید بهترین ابتکار از بالا به پایین اعطای آزادی عمل و استقلال به افرادی که در پایین هستند، باشد، زیرا امکان ایجاد تغییرات مثبت از پایین به بالا وجود دارد.
بیشتر بدانید: https://lnkd.in/ey_4CuWS
