:: مجموعه مقالات کاربردی : ارزیابی سریع یک تیم نرم افزاری ::

با عرض سلام و خسته نباشید خدمت همه دوستان سایت ، یک سلسله مقاله جمع آوری کردم که فکر میکنم خیلی مفید واقع بشه ! این مقالات بیشتر در زمینه مهندسی نرم افزار هست. که ان شالله به تدریج در سایت قرار میدهم :
هدف : از همه دوستان خواهش میکنم این مقالات رو به بحث بکشیم .اگر نظری تجربه و یا نکته ای به ذهنتان میرسه لطفا بیان کنید انشاالله بعد از بررسی هر مقاله خود مقاله و نظرات دوستان رو در قالب یک فایل PDF منتشر خواهیم کرد و این کار تنها با نظر مدیر سایت – مدیر بخش امکان پذیر است.
سعی کردم مقالاتی رو تهیه کنم که کاربردی باشند ( خودم شدیدا با مقالات صرف تئوری مخالفم ! باید عمل کرد ! نه اینکه فقط خواند) – مقالات بدون هیچ تحریفی ارائه میشود ( در صورت تغییر مشخص میشود)
مقاله اول را با موضوع ارزیابی تیم های نرم افزاری آغاز میکنم این مقاله رو یکی از دوستان زحمت کشیده و ترجمه کرده ، میتونید با یک Search ساده در گوگل منبعش رو پیدا کنید : "The Joel Test"
موضوع مقاله : ارزیابی سریع یک تیم نرم افزاری
کاربرد : مدیریت پروژه ، ارزیابی و رتبه بندی تیم های برنامه نویسی و نرم افزاری بدون نیاز به پشتوانه تئوری قوی
توضیح : این مقاله در دو قسمت ارائه میشود
قسمت اول :
ارزیابی سریع یک تیم نرم افزاری

برنامه نویسها بدقولترین انسانها هستند . اینو من نمیگم , همه میگن . حالا چکار کنیم بهموون نگن بدقول؟
آقای Joel Spolsky تعداد 12 سوال طرح کردند تا به این وسیله شما بتونین یک برآورد کلی از وضعیت پروژه های نرم افزاریتون داشته باشین . شما باید سعی کنید کاری کنید تا جواباتون به این سوالات مثبت باشه . در اینصورت پروژتوون هم موفقه و هم به احتمال زیاد سر وقت آماده میشه . این اطلاعات برای نوشتن برنامه ها بصورت انفرادی هم مفیده . در اینصورت شما این سوالات رو از خودتوون میپرسید .
تست یوئل
The Joel Test
آیا تاکنون چیزی در مورد SEMA شنیده اید ؟
یک سیستم الکترونیکی نسبتا پیچیده برای سنجش یک تیم نرم افزاری است . برای فراگیری کار با این سیستم به حدود 6 سال وقت نیاز دارید .در حالی که با انجام تست زیر میتوانید کارایی تیم نرم افزاری خودتان را محک بزنید .
(The Joel Test) تست یوئل :
1- آیا از ناظر منبع استفاده میکنید ؟
2- آیا میتوانید کد اجراییتان را در هر مرحله بسازید ؟
3- آیا ساختارهای روزانه میسازید؟
4- آیا دیتابیس اشکال دارید ؟
5- آیا اشکالات کد قبلی را قبل از نوشتن کد جدید برطرف میکنید ؟
6- آیا برنامه زمانبندی به روز دارید ؟
7- آیا شرحی از ویژگیهای پیشنهادی در مورد برنامه دارید ؟
8- آیا برنامه نویسهایتان محیط کاری آرام و ساکت دارند ؟
9- آیا از بهترین ابزاری که میتوانید بخرید استفاده میکنید ؟
10- آیا تستر دارید ؟
11- آیا از نفرات جدید در خلال مصاحبه میخواهید کد بنویسند ؟
12- آیا در پایان کار یک تست مفید و گسترده انجام میدهید ؟



بهترین ویژگی این تست سادگی در گرفتن پاسخ "" بله "" یا "" خیر "" است . اگر برای هر پاسخ مثبت یک امتیاز به تیم خود بدهید , میتوانید یک برآورد کلی از تیمتان داشته باشید . اگر تیم شما حائز امتیاز 12 شود یعنی تمام قواعد فوق را اجرا کرده باشد , یک تیم عالی دارید , امتیازهای 10 و 11 نیز خوبند .
ولی اگر مجموع امتیازات شما کمتر از 10 باشد به یک بازنگری در تیمتان نیاز دارید . شرکتهایی مثل میکروسافت همواره در امتیاز 12 هستند ولی شرکتهای کوچک اغلب امتیازی کمتر از حد عالی وخوب دارند( اغلب اوونا حتی امتیازی بین 2 و 3 دارن !! که به یک کمک جدی احتیاج دارند ) اما با بکارگیری این قواعد میتوان کارایی آنها را افزایش داد .
حال به تشریح 12 سوال فوق میپردازیم .
1- آیا از ناظر منبع استفاده میکنید ؟
بااستفاده از ناظر منبع های تجاری و CVS رایگان میتوان برنامه را کنترل کرد . بدون ناظر منبع شما مجبورید برای هر مشکلی برنامه نویسها را دور هم جمع کنید . مهمترین خصیصه سیستمهای کنترل منبع اینست که کد برنامه خودش را روی درایو سخت هر برنامه نویسی چک میکند .
2- آیا میتوانید کد اجراییتان را در هر مرحله بسازید ؟
با اینکار شما میتوانید از چگونگی اجرای کد با هر تغییری در آن اطمینان حاصل کنید و تغییرات لازمه را در آن انجام دهید . این مساله در خطایابی کمک زیادی میکند . همچنین با ساختن بسته نصبی در پایان میتوانید آنرا برای اجرا بروی CD , درایو سخت ویا وب سایت آماده کنید .3- آیا ساختارهای روزانه میسازید؟
با ساختن ساختارها و گزارشهای روزانه میتوانید از کم وکیف انجام پروژه در روزهای قبل اطمینان حاصل کنید . در این مرحله برنامه نویس در پایان کار روزمره گزارشی از کارهای انجام شده و کارهای مرتبط که باید انجام شوند تهیه میکند و روز بعد هنگام آغاز کار ابتدا گزارش روز قبل را مطالعه میکند تا ادامه کار روز قبل مختل نشود .
4- آیا دیتابیس اشکال ( بانک اشکالات ) دارید ؟
بطور عادی هیچ کسی قادر نیست در یک لحظه بیشتر از 2 یا 3 خطا را به خاطر آورد . در صورتیکه چیزی هم باعث بشود تمرکز فرد به هم بخورد , آن 2 , 3 خطا هم فراموش میشود و کدی که باقی میماند کدی است با خطاهای متعدد . ما میتوانیم با تهیه فرمهای مخصوص درج خطاها , آنها را ثبت کنیم تا در موقع تصحیح کارمان ساده شود و از تصحیح تمام خطاهایی که متوجه آنها شده ایم مطمئن شویم .
5- آیا اشکالات کد قبلی را قبل از نوشتن کد جدید برطرف میکنید ؟
خطاها را در اسرع وقت تصحیح کنید چرا که تصحیح اغلب خطاها هنگامیکه آنها را میشناسید چون خطا در ذهن شما تازه است کاری ساده است و زمان زیادی نمیگیرد اما در غیر اینصورت ممکن است تصحیح خطا آنقدر مشکل شود که شما مجبور شوید کدتان را از نو بنویسید تا هم هزینه و هم زمان را بیهوده تلف کنید .
6- آیا برنامه ریزی به روز دارید ؟
شعار برنامه نویسها اینه : آماده میشه هر وقت آماده شد !!!!! ما باید آماده شدن پروژه را تحت کنترل خودموون در بیاریم برای اینکار کار ما به برنامه ریزی احتیاج داریم . اما چه چیزی باعث میشود ما در امر کدنویسی هم برنامه ریزی کنیم ؟ اگر یک کد تجاری مینویسید مجبورید برنامه ریزی داشته باشید چرا که باید زمان اتمام و اجرای کد را بدانید . اما در سایر زمینه ها هم با برنامه ریزی میتوانید نسبت به انجام بهتر پروژه اطمینان پیدا کنید .

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

قسمت دوم : در این بخش در ادامه به بررسی پرسش های باقیمانده مبپردازیم :
7- آیا شرحی از ویژگیهای پیشنهادی در مورد برنامه دارید ؟
در صورت داشتن شرحی از آنچه مشتری میخواهد میتوانید نرم افزار بهتر وبدون اشکالتری به او ارائه دهید . اما برنامه نویسها از نوشتن مستندات بیزارند و بنابراین فقط به نوشتن کد میپردازند و از ثبت ویژگیهای پیشنهادی مشتری سر باز میزنند . شما میتوانید با فرستادن برنامه نویسهایتان به دوره های فشرده نویسندگی بی میلی آنها را نسبت به نوشتن مستندات کاهش دهیم .
8- آیا برنامه نویسهایتان محیط کاری آرام و ساکت دارند ؟
دانسته کارکنان با وارد شدن به محل کار جمع آوری میشود و ما باید با فراهم کردن محیطی آرام برای آنها کاری کنیم که تمرکز آنهافقط متوجه کارشان باشد . این یک اصل کلی است و مختص برنامه نویسها نیست .
انتخاب موقعیت مناسب کار چندان ساده ای نیست برای اینکار توجه داشته باشید در بهترین حالت بطور متوسط 15 دقیقه وقت تلف میشود تا شخص تمرکز کامل برای انجام کار بدست آورد .
9- آیا از بهترین ابزاری که میتوانید بخرید استفاده میکنید ؟
بطور مثال فرض کنید یک برنامه نویس برای کامپایل کدش مجبور باشد برای چند ثانیه معطل شود , بنابراین سعی میکند کمتر کد اجرایی بسازد و برنامه را امتحان کند تا زیاد معطل نشود , بنابراین کد نوشته شده در هنگام کامپایل بزرگتر میشود و به این ترتیب گرفتن باگهای آن هم مشکلتر میشود .
اگر فرآیند کامپایل بیش از 15 ثانیه طول بکشد علاوه بر مشکل فوق باعث میشود تا برنامه نویس در طول کامپایل به کار دیگری مشغول شود , که این امر سبب به هم خوردن تمرکز و اتلاف وقت میشود . بنابراین با تهیه یک کامپیوتر سریعتر میتوانیم از بروز این مساله جلوگیری کنیم .
10- آیا تستر دارید ؟
اگر شما به ازای هر یک یا در برنامه نویس یک تستر نداشته باشید , محصولاتتان همواره باگدار هستند . شما میتوانید با استخدام یک تستر با هزینه فرضاً30 دلار جلوی یک هزینه صد دلاری برای تصحیح باگهای احتمالی را بگیرید .
11- آیا از نفرات جدید در خلال مصاحبه میخواهید کد بنویسند ؟
متاسفانه امروزه مصاحبه رو در رو برای تعیین صلاحیت یک فرد مناسب نیست چرا که نتیجه آن منوط به اینست که شخص مصاحبه کننده از مصاحبه شونده خوشش بیاید یا از قبل با او آشنا باشد . بنابراین مصاحبه حضوری به تنهایی راه مناسبی برای تعیین صلاحیت یک فرد نیست .ما میتوانیم بصورت عملی از او بخواهیم کاری انجام دهد . همانگونه که یک آشپز را بدون چشیدن غذایش برای پختن غذای عروسیتان استخدام نمیکنید یک برنامه نویس را هم نباید بدون دیدن نمونه کارش استخدام کنید .اگر شخص جدید تمام جزئیات برنامه نویسی را بلد باشد خوبست اما اگر کاربرد آنها در برنامه نویسی را بلد نباشد مسلما بدرد شما نمیخورد . اما اگر از او بخواهید تا کد بنویسد به قابلیتهای او نیز پی خواهید برد
.12- آیا در پایان کار یک تست مفید و گسترده انجام میدهید ؟
یک تست مفید و گسترده آنست که برنامه خود را به چند نفر نشان بدهید تا با آن کار کنند . تجربه نشان میدهد اگر برنامه تان را به 5 نفر بدهید تا با آن کار کنند 95 درصد در مورد معایب , باگها و مزایای برنامه تان مطمئن میشوید .
با طراحی یک رابط کاربر زیبا و مناسب که مورد پسند مشتری باشد میتوانید برای محصولتان مشتری های بیشتری پیدا کنید . برای اینکار رابط کاربرتان را به چند نفر نشان بدهید تا یک نمای کلی از علایق مردم را بدست بیاورید . به توصیه آقای Joel Spolsky بهتر است در پایان کار خودتان هم یکبار نرو افزار را تست کنید . چرا که هم مجانی است و هم خودتان یک مرور کلی روی آن انجام داده اید و اینکار میتواند در کیفیت بهتر نرم افزار موثر باشد .