برای ارتقای کیفیت توسعه‌ی نرم‌افزار از کجا شروع کنیم؟

کیفیت، مقصدی برای موفقیت

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

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

یک مدل بلوغ می‌تواند مسیر ما را در رسیدن به این هدف، مدون نماید.

گام نخست: در مورد نظرات و تجربه‌های دیگران تحقیق کنید

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

از دو کتاب How google Tests Software و Continuous Delivery می‌توان به عنوان دو اثر تاثیرگذار در این زمینه نام برد.

کتاب How Google Tests Software اثر James Whittaker، Jason Arbon و Jeff Carollo ، تجربیاتی را در زمینه کیفیت نرم‌افزار بیان می‌کنند. چیزی که این کتاب بیان می‌کند - و همانطور که گفتم، ما نیز به دنبال آن هستیم - این است که کیفیت، هنگام تولید نرم‌افزار به دست می‌آید و امکان افزودن آن به نرم‌افزار تولیدشده، وجود ندارد. پس باید در فرایند توسعه‌ی نرم‌افزار به دنبال تولید کیفی نرم‌افزار باشیم.

در کتاب Continuous Delivery، اثر Jez Humble و David Farley نویسندگان سعی دارند توسعه‌دهنده را از برزخ استقرار و تحویل دور کنند؛ نه بدان معنا که این وظایف را به اشخاص دیگری واگذار کنند، بلکه برعکس، همه‌ی کارها بدون سیلوبندی، در تیم توسعه و با محوریت محصول صورت می‌گیرد. هدف نهایی در این‌جا استقرار محصول فقط با فشار یک دکمه است.

گام دوم: آیتم‌های کیفی را شناسایی کنید

وقتی در مورد کیفیت توسعه‌ی نرم‌افزار صحبت می‌کنیم، آیتم‌های متعددی به ذهنمان می‌رسد که می‌توانیم براساس آن‌ها، خود را از لحاظ حرکت در مسیر صحیح ارزیابی کنیم. برای مثال، چقدر تست برای کدهای خود داشته باشیم، چقدر به خودکارسازی فرآیندها اهمیت دهیم و … ؛ اما نکته‌ای که وجود دارد این است که اکثر این موارد مطلق نبوده و بعضا به تنهایی چیز خاصی را به ما نشان نمی‌دهند. در مورد این آیتم‌ها، اهمیت آن‌ها و آستانه‌هایی (threshold) که برای آن‌ها در نظر می‌گیریم، نظرات متعددی وجود دارد. بنابراین بهتر است نظرات مختلف را جمع‌آوری و بر اساس نیازهای خود در مورد آن‌ها تصمیم بگیریم.

گام سوم: گام‌ها را مشخص کنید

حال که آیتم‌های کیفی مد نظر خود را می‌دانیم، برای دستیابی به آن‌ها باید گام‌هایی را طراحی کنیم. آیتم‌ها معمولا دو شکل دارند: یک دسته، آن‌هایی که با مقادیر دو-دویی ارزیابی می‌شوند، مانند وجود و عدم وجود. دسته‌ی دیگر، آن‌هایی که برای آن‌ها می‌توان بازه‌های مقادیر درنظر گرفت، از قبیل بازه‌هایی از درصدها.

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

مسلما با قانون ۸۰/۲۰ یا اصل پارتو آشنایی دارید؛ اصلی که طبق آن در اکثر رویدادها، تقریبا ۸۰ درصد از اثرات از ۲۰ درصد از علل، ناشی می‌شود. پس بهتر است یکی از گزینه‌هایمان در اولویت‌دهی آیتم‌ها، برداشتمان از میزان تاثیر آن‌‌ها در بهبود کیفیت فرایند باشد. آیتمی که به نسبت هزینه‌ی صرف‌شده، بهبود بیشتری را در پی دارد، شایسته‌ی قرارگیری در گام‌های اول است؛ البته اگر آیتم دیگر در آن گام یا گام‌های بعدی، پیش‌نیاز آن نباشد.

مسیر «کارنگی ملون» الهام بخش ما

«مدلی برای بهینه‌سازی پروسه‌های تولید» شاید تعریف مختصر و مفیدی برای CMMI باشد؛ مدلی که به ادعای دانشگاه کارنگی ملون، می‌تواند برای هدایت بهبود فرایند در یک پروژه، بخش یا کل سازمان استفاده شود. CMMI را شاید بتوان مشهورترین مدل بلوغ فرایندی در جهان دانست. اجرای CMMI برای بسیاری از پروژه‌های دولتی ایالات متحده، به خصوص در حوزه‌ی نرم‌افزار، اجباری است. مدل CMMI، راهنمایی برای توسعه یا بهبود فرایندها برای دستیابی به اهداف کسب‌وکار یک سازمان، فراهم می‌کند.

ارزیابی CMMI به شناسایی نقاط قوت و ضعف فرآیندهای سازمان و بررسی ارتباط نزدیک فرایندها با بهترین روش‌های (‌best practice) CMMI کمک می‌کند.

چرا از همین مدل استفاده نکنیم؟

همان‌طور که می‌بینید CMMI یک مدل بلوغ سازمانی است؛ پروسه‌های سازمانی را مدنظر قرار می‌دهد و بازیگران و تصمیم‌گیران آن در سطح سازمان هستند؛ ولی ما به دنبال یک مدل هستیم که در جنبه‌های فنی، ما را راهنمایی کرده و توسط بازیگران فنی هدایت و در سطح محصول پیاده‌سازی شود. آن‌چه که مورد توجه ما باید قرار بگیرد، روش مدل‌سازی مسیر بلوغ بوده که شامل سطوح و حوزه‌ها و آیتم‌های کیفی است و به صورت مشابه مورد استفاده‌ی ما قرار گرفته‌ است.

نظرات افراد تاثیرگذار به ما کمک می‌کند

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

تعادل آرمان‌گرایی و عمل‌گرایی را حفظ کنید

درست است که در حال ترسیم راه بلوغ کیفیت هستیم؛ اما رسیدن به بهترین راه در اولین تلاش شاید خیلی خوشبینانه باشد؛ پس سعی نکنید همه چیز بدون عیب و نقص باشد. برای رسیدن به بهترین راه شاید لازم باشد قدم در راه گذاشته و در عمل طراحی خود را بیازمایید.

هیئت ژوری را برای اصلاحات حفظ کنید

ارزیابی یک محصول در دستیابی به سطوح کیفی و بررسی اصلاحات پیشنهادی، کاریست که باید به صورت مداوم صورت بگیرد. پس هیئتی که در طراحی مدل دخیل بوده‌اند، بایستی حفظ شوند. مسلما اعضای هیئت تغییر می‌کنند، ولی ساختار باید حفظ شود. من اسم این هیئت را «کمیته‌ی کیفیت» می‌گذارم.

انعطاف را وارد طراحی خود کنید

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

تجربه‌ی ما

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

https://git.qualitic.ir

فاصله‌مان تا مقصد چقدر است

خوب است بدانید چقدر تا هدف یا مقصد فاصله دارید. ابزارهایی که به ما در مسیر ارتقای کیفیت کمک می‌کنند، متعدد هستند. چطور است ابزاری در اختیار بگیریم که داده‌ی سایر ابزارهایمان را به صورت متمرکز، نمایش و وضعیت دستیابی به اهداف را به ما نشان دهد؟ استفاده از این ابزار، به دلیل قابلیت‌هایی از جمله نمایش سیر پیشرفت، می‌تواند انگیزه‌ی بیشتری را در جهت ارتقای کیفیت محصول، در تیم توسعه تزریق کند. در سحاب بعد از طراحی مدل بلوغ، به دنبال توسعه‌ی چنین ابزاری رفتیم. ابتدا راه‌حلی برای نمایش وضعیت آن دسته از آیتم‌ها که ابزار سنجش خودکار برای آن‌ها وجود نداشت، تمرکز کرده و بعد از آن به سراغ تجمیع داده‌ی سایر ابزارها رفتیم. این ابزار که نام آن را «نمو» گذاشتیم، هرچند در حال حاضر یک ابزار خصوصی در سحاب‌ است، ولی شاید در آینده‌ای نزدیک، امکان استفاده از سرویس‌های آن برای علاقه‌مندان فراهم شود.

حرف آخر

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