پاول کریل (Paul Krill)
مترجم: شیرین سادات صفوی
تقریبا ده سال از زمانی که اساتید رشته برنامهنویسی «مانیفست تولید چابک نرمافزار» را ارایه دادند میگذرد. هدف این مانیفست بهبود فرآیندها و اعمال تغییرات ضروری برای همگامی با مشتری و ارایه سریعتر نرمافزار نهایی بود.
مانیفست چابکی راهکار تولید نرمافزار در فوریه 2001 و در گردهمآیی برنامهنویسان در دانشگاه یوتا ارایه شد. این مانیفست قرار بود تا راهکاری برای جایگزینی روشهای سنگین و سرشار از سندسازی تولید نرمافزار (مانند شیوه آبشاری که در آن زمان مثل طلا ارزش داشت) بیابد.گر چه روشهای چابک دیگری نیز در همین مکان تاریخی پیش از این ارایه شده بود، اما این گردهمایی در حکم نقطه عطفی بود که مفهوم کلی چابک را به پیش راند. تقریبا ده سال از آن زمان میگذرد و امروزه شاهد استفاده سازمانهای نرمافزاری از متدولوژیهای چابکی چون Scrum و (XP (Extreme Programming هستیم و تولید نرمافزارها به روش چابک رواج بیشتری یافته است. حتی با وجود نقاط ضعف بالقوه راهکار چابک، تحلیلگران بازار اعلام کردهاند که روشهای چابک به طوری کلی موجب سوددهی بیشتر شرکتهای تولیدکننده نرمافزار شده است.
وارد کانینگهام (Ward Cunningham)، یکی از امضاکنندگان مانیفست که در آن زمان برای شرکت Tektronix کار میکرد، معتقد است که راهکار چابک صنعت برنامهنویسی را دچار تحولهای اساسی کرده است. به گفته او، بحث بر سر شکست برنامهنویسی کامپیوتری و بحرانهای برنامهنویسی به لطف برنامهنویسی چابک از میان رفته است.
اسکات امبلر (Scott Ambler)، متدولوژیست ارشد روشهای چابک در IBM Rational، معتقد است مانیفست چابک حتی به چیزی فراتر از اهدافش دست یافته است. وی در این باره میگوید: «این مانیفست اثر بسیار عظیمی بر صنعت داشته است. امروزه دیگر شخصی را پیدا نمیکنید که دلش نخواهد چابک کار کند. در کنار این مساله انتظار موفقیت از برنامهنویسی چابک هم بسیار بالاتر از چند سال گذشته رفته است.»
اما کنت بک (Kent Beck)، یکی دیگر از امضاکنندگان مانیفست و موسس راهکار برنامهنویسی افراطی (XP)، ده سال بعد از ارایه مانیفست، چندان در باره موفقیت این راهکار مطمئن نیست و میگوید که جواب قطعی در این باره ندارد. وی معتقد است: «هر چند برنامهنویسی چابک به برنامهنویسان کمک کرد تا دقیقتر به روش تولید نرمافزارشان بیاندیشند، اما هنوز هم هستند افرادی که در حین انجام پروژه، به دنبال لیستی از وظایف و تعهدات میگردند و راهکار چابک را تضاد با ماهیت چابک آن قرار میدهند.»
چابک بودن به چه معنا است
کانینگهام معتقد است یادگیری راهکار چابک میتواند بسیار سخت باشد: «باید قبل از مجرب شدن در برنامهنویسی چابک فنون بسیاری را فرا بگیرید و در آنها استاد شوید.» او تاکید میکند که مهارتهای ظریف برنامهنویسی در این امر ضروری هستند. «افراد زیادی وارد حوزه چابک میشوند اما بحث برنامهنویسی آن به نظرشان بیش از حد دقیق است و از آن دلزده میشوند. برای رسیدن به موفقیت در این راهکار باید واقعا به فرآیند چابک اعتقاد داشته باشید و روشهای قدیمی را کاملا کنار بگذارید.»
موانع سازمانی هم میتوانند سد راه اجرای معماری چابک شوند. اسکیپ آنجل (Skip Angel)، از مربیان ارشد برنامهنویسی چابک در شرکت BigVisible Solutions در اینباره میگوید: «برنامهنویسی چابک در توسعه سریعتر نرمافزارها و خرد کردن مسایل به جای در نظر گرفتن کل پروژه، خوب عمل میکند. اما فکر میکنم آن چیزی که برای سازمانها مشکلساز شود، این است که آنها آمادگی لازم برای هماهنگی با سرعت بالای راهکار چابک را ندارند.»
بک میگوید با استفاده از برنامهنویسی چابک در 1997، موفق شد ابزارهای تست جاوای JUnit را با موفقیت تولید کند. این امر بر فرآیندهای کوتاهمدت، تستهای بسیار و ارتباط نزدیک با مشتریان متکی بوده است.
البته همراه کردن همه افراد با برنامهنویسی چابک هم کار سختی است. بک میگوید: «یکی از برنامهنویسهایم دایم میگوید ترجیح میدهد خطمشی و نیازمندیهای روشنتری در دست داشته باشد. من هم جواب میدهم سرعت ما تنها به آن دلیل است که نیازمندیهای دقیقی در دست نداریم.» بک معتقد است این خطمشیها تنها وقت تلف کردن هستند.
متدهای برتر برنامهنویسی چابک
برجستهترین متدولوژیهای برنامهنویسی چابک، Scrum و XP هستند. به گفته بک، XP بیشتر به جنبه مهندسی امر تولید نرمافزارها میپردازد: «این متدولوژی در مقابل Scrum که بیشتر به مدیریت پروژه میپردازد، بر روی خود امر برنامهنویسی تمرکز دارد.»
| < قبلی | بعدی > |
|---|