تجربه‌های به‌کارگیری مفاهیم سرآمدی فنی

  • یوسف مهرداد

گردآوری: یاسر کازرونی

پیش‌گفتار:

متن زیر خلاصه‌ی بخش‌هایی از گفتگوی اعضای گروه تلگرامی «متدهای چابک» (Agile Methods) است.

گفتگو:

در گروه پیشنهاد شد که دوستان از تجربه‌های به‌کارگیری مفاهیم سرآمدی فنی (Technical Excellence) در تیم‌های خود بگویند و کتاب‌ها و مطالب مفید در این خصوص را برای آشنایی سایر عزیزان معرفی نمایند. آن چه می‌خوانید خلاصه‌ای است از این گفتگوها.

———————–
محمد حسین:

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

درگیری در فوریت‌های روزمره از قبیل رسیدگی به درخواست‌های مشتریان و رفع باگ‌ها باعث می‌شود تا به‌کارگیری تجربه‌های فنی چابک به تعویق بیفند.

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

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

او دلیل موفقیت این تیم را عوامل زیر می‌داند:

  1. تمرکز و همبستگی
  2. انگیزه‌ی بالای تیم برای اثبات توانمندی خود به سازمان
  3. داشتن دانش و تجربه‌ی قبلی در کسب‌و‌کار

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

———————–

روح‌الله:

معتقد است که بدون توجه به اصولی مانند SOLID‌ یا Design Patterns و به‌روش‌های TDD ادعای چابکی کردن ‌ادعای بی‌اساسی است. او به همه‌ی توسعه‌دهندگان و تیم‌های چابک پیشنهاد می‌دهد یک‌بار کتابClean Code را مطالعه کنند.

True flexibility (agility) can only happen when you are able to make changes to the product in a easy, fast, and flexible way. In that sense Organizational Agility is constrained by Technical Agility

او همچنین مثال قبلی (تیم محمد حسین) را یک نمونه خوب از تاثیر مثبت ارزش Courage و اثربخشی در موفقیت یک تیم چابک می‌داند.

———————–

سهیل:

به نقل جمله‌ای از ناپلئون می‌پردازد و تسلط نداشتن و استفاده نکردن از تجربه‌های خوب مهندسی را دلیل نرسیدن به چابکی می‌داند:
چابکی یعنی وقتی برای یک مساله چندین راه حل داشتی، اونی رو انتخاب کنی که تغییر در آینده رو بتونه مهار (ساده) کنه [نه حتی بهترین یا سریعترین راه رو!]

———————–

فرید:

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

———————–

مهرداد:

مشکلات فنی را در تیم فعلی خود مطرح می‌کند و استفاده از مفاهیم سرآمدی فنی را لازم می‌داند. برخی از این مشکلات عبارتند از:

  1. پاسخ‌گویی نامناسب به نیاز‌های مشتری در پروژه‌های قدیمی
  2. تمایل نداشتن توسعه‌دهندگان تیم برای بازنویسی کدهای این پروژه‌ها
  3. نداشتن قابلیت نگهداری کدها و استفاده مجدد از آنها
  4. عدم امکان استفاده از معماری و چارچوب‌های جدید
  5. نداشتن مرجع کاملی از مستندات کدها
  6. تکراری و طولانی بودن کدها

منابع پیشنهادی:

  1. Working Effectively with Legacy Code, Michael-Feathers
  2. Refactoring: Improving the Design of Existing Code, Martin Fowler
  3. Clean Code: A Handbook of Agile Software Craftsmanship, Robert C.Martin

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

https://bibalan.com/?p=1624
یوسف مهرداد

یوسف مهرداد


کانال تلگرام

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

برای خروج از جستجو کلید ESC را بفشارید