مشکلات چابک – آسیب‌شناسی واژگان

در خصوص مفهوم و معنی چابک در زبان فارسی باید بگویم که نزدیک‌ترین و بهترین انتخاب برای Agile همان چابک است. اصولاً آوردن کلمه سریع در کنار چابک آن‌طور که در خیلی از مواقع سهواً و گاهی عمداً آورده می‌شود نادرست است.

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

Agile: Characterized by quickness, lightness, and ease of movement; nimble. Mentally quick or alert: an agile mind.

www.thefreedictionary.com

Agile: Marked by an ability to think quickly; mentally acute or aware: She’s 95 and still very agile.

www.dictionary.com

معنای چابک

باکمی دقت متوجه می‌شویم که چابکی فقط سریع بودن نیست، به واژه Alert (به معنی: گوش‌به‌زنگ، هوشیار، مواظب‌، زیرک‌، اعلام‌خطر،آژیر هوایی‌، به حالت‌ آماده‌باش‌ درآمدن‌ یا درآوردن‌)، Nimble (به معنی: تردست‌) و Lightness (به معنی: سبکی، شرایطی که باعث روشن و شفاف شدن می‌شود) دقت کنید!

موافقم که اصولاً چابک کاری در ایران درست شناخته‌نشده است. ولی هنوز متقاعد نشده‌ام قابل شناخت و پیاده‌سازی نیست. قطعاً می‌تواند، به شرطی که به این مفاهیم پایه و فرهنگ واژگان آن دقت شایسته‌ای داشته باشیم. واژۀ چابک (Agile) هنوز در سطح یک صفت در واژگان فارسی باقی‌مانده و هنوز یک «اسم خاص» نشده است. متأسفانه صنعت نرم‌افزاری کشور تقاضای زیادی از محققین در این‌گونه مقولات نداشته و ندارند!

در زبان انگلیسی تفاوت زیادی بین Agile و agile و agility وجود دارد؛ واژه اول یک اسم شاخص و ویژه و معرفه است که به یک نهضت یا تفکر اشاره می‌کند درحالی‌که دو واژه بعد عموماً توصیفی و عام هستند! این خلأهای واژه‌شناسی همه کاستی‌هایی است که بااینکه کوچک و بی‌اهمیت به نظر می‌رسند ولی در عمل، جایی گریبان چابک کار را گرفته و گلویش را خواهد فشرد. فشاری که خود چابک کار هم گاهی از علت و منبع آن بی‌اطلاع است.

روشن است که دانش بومی از دانش غیربومی مؤثرتر است! بومی کردن یک دانش یا فنّاوری تغییر آن دانش نیست، حتی مفهوم رام کردن آن دانش را هم نمی‌دهد، بیشتر پذیرش (Adoption) و سپس انطباق (Adaption) است.

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

متأسفانه  گروه‌ها و سازمان‌هایی بوده‌اند که قبل از آنکه یک‌بار فرآیندهای چابک یا هر متدلوژی دیگر را تا انتها – آن‌هم بدون کم‌وکاست و دخل و تصرف و پاره‌پاره کردنش، طی کنند، زبان به‌نقد و شکایت گشوده‌اند که، «من میدانم که فلان مورد را پوشش نمی‌دهد» و «چرا پس از شش ماه خبری از معجزه نیست» یا «اصلاً فرآیندی تاکنون با این روش‌ها به محصول نهایی ختم شده است؟ بعید میدانم!» و «من از این بخشش خوشم نمی‌آید، به نظر منطقی نمی‌رسد!» و صدها واژه و جمله دیگر که احتمال به گوش شما هم آشناست.

در هیچ صنعت دیگری در کشور به‌اندازه صنعت نرم‌افزار به الگو‌ها و راه و روش‌های فنّاورانه و مخصوصاً متدلوژی‌های فرایند محور بی‌مهری نشده است. مثلاً در صنعت راه و ساختمان، فنّاوری تولید آسفالت از کشور آلمان وارد می‌شود، ده یا پانزده سال بدون تغییر باقی می‌ماند، «الف» تا «یای» آن موبه‌مو اجرا می‌شود و کسی هم جرئت دست‌کاری آن را ندارد! پس از یک دهه تجربه موفق و چشیدن شکست‌ها و پیروزی‌های متعدد، متخصصین دست به تغییر و بهینه‌سازی آن می‌زنند. چرا؟! چون دانش آن‌ها در طی استفاده از روش قبل، ارتقاءیافته، تجربیات خوب و بدشان پشتیبانشان خواهد بود!

ولی در نرم‌افزار چه؟! آیا مثال‌های معکوس ازاین‌دست بی‌شمار نیستند؟ شما هرکدام حتماً چند موردی در خاطرتان هست! می‌توانید آن‌ها را مطرح کنید 🙂

اگر ما به صنعتی که در آن مشغولیم کمک نکنیم، چه کسی کمک خواهد کرد؟

👋

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

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