اگر تمام وقت دنیا را داشتید، چگونه نرم افزار می نوشتید؟ آیا با چیزی که اکنون انجام میدهید متفاوت است؟ این سؤالی است که در برنامه نویسی افراطی ( extreme programming ) مطرح می‌شود.
حتماً درباره مثلث مدیریت پروژه شنیده‌اید، درست است؟
یک مثلث بسازید و در هر نقطه این موارد را قرار دهید :هزینه، زمان و محدوده یا گستره پروژه (در حوزه مدیریت پروژه، مدیریت محدوده فهرست وظایفی است که باید به میزان مورد نیاز، با حفظ کیفیت، تنوع تعیین شده و در زمان مشخص با منابع موجود و توافق شده در پروژه، انجام گیرد)؛ البته شما فقط میتوانید دو مورد از این سه مورد را کنترل کنید.
در مرکز مثلث، یک نقطه وجود دارد. هرچه به سمت یکی از این موارد حرکت کنید، مشخصا از موارد دیگر دورتر می‌شوید؛ این مفهوم مفید است اما اینجا چیزی وجود دارد که فراموش شده!
نظرتان درمورد کیفیت چیست؟!
بیایید مثلث‌ها را رها کنیم و در عوض ،شاخص‌هایی مشخص کنیم که هر وجه را کنترل می‌کند. به عنوان مشتری و شخصی که پول پرداخت می‌کند، محدوده را به 10 تغییر دهید، به این معنی که دریافت همه‌ی ویژگیها، بسیار مهم در نظر گرفته می‌شود.
اما با این کار، شاخص‌های هزینه و زمان 0 می‌شود؛ در واقع آن‌ها را برای شاخص محدوده قربانی می‌کنید. بنابراین شما زمان کمی را دارید چراکه شما به همه‌ی ویژگیها نیاز دارید.
انجام این کار،شاخص کیفیت را خاموش می‌کند؛ زیرا تنها راه تحویل ویژگی‌های خواسته شده، قبول بدهی فنی و صرف نظر از مواردی مثل تست، ریفکتور کردن و اصطلاح و بهبود پروژه است.
این بسیار معمول است؛ کیفیت معمولاً انعطاف پذیرترین عنصر در نظر توسعه‌دهندگان و ذینفعان است، حتی اگر آن را نپذیرند!
بسیار شنیده‌ام که تیم‌های متعددی مواردی این چنین را می‌گویند:“ می‌خواهم تست بنویسم اما وقت ندارم“ یا “ بعد از انتشار نسخه بعدی، ریفکتور را انجام می‌دهیم“ .
بعضی‌اوقات، این امر مهمی‌ست، که یک فرصت از دست رفته برای تحویل پروژه وجود دارد، صرف نظر از این که معماری شما چقدر زیباست. شما نمی‌توانید ۳۰ متخصص و توسعه‌دهنده استخدام کنید؛ بنابراین مجبورید با آنچه که دارید کار کنید. من یک بار شانس کار کردن در یک شرکت بسیار خوب را داشته‌ام، به حدی که علی‌رغم تیم ۴۰ نفره توسعه‌دهندگان و حدود پنج‌سال سابقه تولید نرم افزار آن‌ها، دونفر به عنوان پشتیبان کار می‌کردند و هر هفته، این دونفر تغییر می‌کردند.
گرچه وقتی نوبت به من رسید، به کار روزانه خودم ادامه می‌دادم و در کل هفته فقط با دو تیکت پشتیبانی ساده برخورد کردم. من در شرکت هایی با تیم‌های به مراتب کوچک‌تر هم کار کرده‌ام که نیروهای پشتیبانی آن‌ها با طوفانی از تیکت‌ها مواجه بودند.
کیفیت این تیم ناشی از پایبندی جدی به برنامه نویسی مفرط(extreme programming ) و چیزی بود که آن‌ها آن را قانون طلایی می‌نامیدند:
تیم توسعه مجاز به اطلاع داشتن از مهلت پروژه نیست.
- برنامه نویسی مفرط یا extreme programming که به اختصار XP هم خوانده می‌شود، یک متدولوژی توسعه نرم افزار است، که در آن هدف افزایش کیفیت نرم افزار و پاسخ‌گویی به نیازمندی‌های در حال تغییر کاربر است.
آن‌ها این مفهوم را اختراع نکرده بودند، اما این اولین جایی بود که دیدم این مفهوم کار می‌کند. چراکه همه به آن اعتقاد داشتند. تنها کسی که مهلت پروژه را می‌دانست صاحب و مسئول پروژه بود؛ و آن‌ها برای پایبندی به این قانون طلایی، اتحاد، اعتقاد و اقتدار داشتند.
بنابراین چرا فکر می‌کنم این مسأله مهم است؟ خب به این گفتگو توجه کنید:
رئیس : تحویل این ویژگی چقدر طول می‌کشد؟
شما : یک هفته.
رئیس : به اندازه کافی خوب نیست!
شما : خب، یک روز.
چه تغییری!!! دفعه اول دروغ گفتی؟ یا رئیس شما برای شما الهام‌بخش است که در مدت زمان کم کد بیشتری می‌نویسید؟ شما احتمالاً این تخمین را آماده کرده‌اید تا آن را خوشحال کنید، گرچه همه‌ی ما این کار را کرده‌ایم و بعداً پشیمان شده‌ایم!
من شاهد اتفاقات مشابهی در تیم‌های نه چندان حرفه‌ای بوده‌ام. شما این مهلت‌های غیر واقعی را به خود تحمیل می‌کنید که به طور مثال باید هر دوهفته یک بار کارتان را تمام کنید و به سرعت آن را انجام دهید. شما هم دقیقاً کاری را که لازم است، تا فقط سیستم شما کار کند را انجام میدهید، بدون تست کردن و بدون انتخاب روش مناسبی برای توسعه؛ خب این بد است! زیرا شما بدون اینکه کار قبلی را تمام کنید، قدم بعدی را شروع می‌کنید.
شما فقط به کارفرما گفته‌اید که مرحله A را تمام کرده‌اید و طبیعتاً او از شما نمی‌پرسد چگونه و چطور به پایان رسیده؟ و وقتی او فکر می‌کند شما درحال انجام مرحله B هستید، هنوز دارید با مشکلاتی که در مرحله‌ی قبلی برایتان رخ داده، دست و پنجه نرم می‌کنید :)
یا بدتر اینکه نواقص خود را در نظر نمی‌گیرید و همین‌طور پیش می‌روید، و همچنین می‌پذیرید که بدهی فنی توسط افراد دیگر پرداخت می‌شود. بنابراین فرض کنید می‌خواهیم پروژه را دیر تحویل بدهیم و آن را تست و ریفکتور کنیم، مواردی که فکر می‌کنید باید کنترل کنیم چیست؟
۱. محدوده یا گستره پروژه
اولین مورد محدوده پروژه است. منظور از محدوده‌ی پروژه، اهداف پروژه و بودجه مالی و زمانی است برای دستیابی به اهداف پیش‌بینی شده. محدوده پروژه مشخص می‌کند که چه فعالیت‌هایی باید در چه زمان و با چه هزینه‌ای به انجام برسد، همچنین حدود پروژه را تعیین کرده و وظایف هر عضو از تیم را تعیین می کند و روش هایی را برای تکمیل و تایید نهایی کار، تعیین می نماید. در‌واقع محدوده پروژه نمایانگر زمان، هزینه و کیفیت کار شماست؛ پس مطلقاً اولین چیزی که باید درنظر بگیرید این مورد است. (مستندسازی)
۲.هزینه
مورد بعدی هزینه است، که معمولاً به معنای منبع است(من از اصلاح منابع متنفرم چون برنامه‌نویس لباس نیست که راحت عوضش کنیم! اما با این حال می‌خواهم مقداری درباره آن بگوییم)
یکی از راه‌حل‌های پیشنهادی، اضافه کاری است. یکی از اصول XP این است که اگر تیم شما مجبور باشد که دوهفته پشت سرهم اضافه کاری داشته باشد، حتما مشکل جدی پیش آمده، که باید برطرف باشد.
سعی کنید از اضافه کاری به جز در مواقع اضطراری استفاده نکنید، چرا با این کار تیم خود را آتش می‌زنید. راه‌حل پیشنهادی دیگر، استخدام توسعه‌دهندگان بیشتر است.این کار ممکن است در دراز مدت کار کند، اما حتی باتجربه‌ترین برنامه‌نویس هم‌زمان می‌برد تا با روند یک پروژه آشنا شود.
استخدام توسعه‌دهندگان بیشتر یک راه‌حل بلند مدت برای یک مشکل کوتاه مدت است؛ و شاید درحال حاضر به شما در تحویل سریع‌تر کمکی نکند، حتی بعضی‌اوقات در دراز مدت هم به شما کمکی نمی‌کند. به یاد داشته باشید ۹ زن نمی‌‌توانند در مدت یک ماه بچه‌دار شوند! :)))))
۳.کیفیت
و اما آخرین چیزی که می‌توانیم فدا کنیم، کیفیت است؛ به عبارت دیگر از کنار کار بزنید!
ممکن است در حال حاضر از بررسی دوباره یا تست بگذرید، چون نیاز به بازنویسی دارد. شما بدهی فنی ایجاد می‌کنید و از فردا برای پراختن به مشکلات امروز هزینه می‌کنید.
در شرکتی که من کار می‌کردم، قربانی کردن کیفیت تقریباً در هیچ موردی وجود نداشت و در جایی هم که قرار بود این اتفاق بیفتد، موقتی بود؛ یعنی با تعهدی محکم به پرداخت آن در آینده.
گرچه من نمی‌توانم فکرکنم که اصلاً آن‌ها به این کار متوسل شده باشند. بنابراین با حذف محدوده پروژه، هزینه و کیفیت، به عنوان مقادیر قابل تغییر، تنها نتیجه‌گیری این است که زمان نمی‌تواند از اهمیت ویژه‌ای برخوردار باشد، البته نه خیلی هم کم اهمیت!
در نتیجه، توسعه‌دهندگان را وسوسه نکنید که از کنار کار بزنند. مهلت پروژه را از جلوی چشم آن‌ها دور کنید و اجازه دهید نرم افزاری با کیفیت بنویسند. این امر در دراز مدت باعث کاهش هزینه‌های تیم پشتیبانی اختصاصی، می‌شود. وغالبا با کدی که کار با آن راحت‌تر است و اصولی نوشته شده، امکان تحویل سریع‌تر هم فراهم می‌شود.
من می‌خواهم برای دوستانی که می‌گویند این اتفاق در تیم ما نمی‌افتد، چالشی ایجاد کنم. این مفهوم را برای ذینفعان خود توضیح دهید و از آن‌ها بخواهید چهار متغییر را به ترتیب اهمیت آن‌ها، رتبه‌بندی کنند.
امیدوارم چیزی شبیه به این را به شما بدهند:
- کیفیت بالا
- تحویل سریع
- کم هزینه
- محدوه پروژه‌ی گسترده
آن‌ها را سرحساب کنید و مطمئن شوید که صاحب محصول نیز چنین کاری را انجام می‌دهد.البته شاید تعجب کنید که این طرز فکر، چقدر برای افرادی که صورت حساب را پرداخت می‌کنند، لذت بخش است!
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید