معلم
چابک‌سازی فرایند تضمین کیفیت
در این نوشتار، سعی می‌کنم چالش‌های مربوط به کیفیت و چابکی در سازمان‌های بزرگی را مرور کنم که بهره‌بردار نرم‌افزار هستند ولی خودشان توسعه‌دهنده نرم‌افزار نیستند. بخش‌هایی از این نوشتار براساس تجربه‌هایی از تلاش برای توسعه کیفیت نرم‌افزار در برخی سازمان‌های این چنینی نوشته شده است و برای حفظ محرمانگی سازمان‌ها، از اشاره مستقیم به این سازمان‌ها در بیان چالش‌ها و راهکارها خودداری شده است.
جایگاه تخصص و تیم کیفیت نرم‌افزار
در بسیاری از پروژه‌های نرم‌افزاری، یک تیم با هدف ارتقای کیفیت نرم‌افزار تشکیل می‌شود. گاهی هدف این تیم، کنترل کیفیت (Quality Control) است که از روش‌هایی مثل تست نرم‌افزار حاصل می‌شود. البته اگر تیم تست از تیم توسعه نرم‌افزار جدا شود و «مسؤولیت» کنترل کیفیت به عهده تیم تست قرار داده شود، شاهد مخاطراتی خواهیم بود. گاهی نیز یک تیم «تضمین کیفیت» تشکیل می‌شود، که این تیم دارای وظایفی فراتر از تست است و با ارتقای فرایند و ابزارهای مورداستفاده در توسعه نرم‌افزار، سعی در ارتقای کیفیت نرم‌افزار دارد. ولی باز هم اگر «وظیفه» تضمین کیفیت به عهده تیم تضمین کیفیت باشد (بر عهده تیم توسعه نباشد) مخاطراتی به وجود می‌آید، چون هدف تیم توسعه، تولید نرم‌افزار (مثلاً پیاده‌سازی امکانات جدید) است و هدف تیم تضمین کیفیت ارتقای کیفیت محصول یا فرایند موجود نرم‌افزار است و گاهی این اهداف و منافع (به ظاهر) در تضاد قرار می‌گیرند.
از طرف دیگر، کنترل کیفیت و تضمین کیفیت نیازمند تخصص و مهارت‌هایی است که گاهی در تیم توسعه نرم‌افزار وجود ندارد. مثلاً تکنیک‌ها، ابزارها، الگوها و به‌روش‌هایی (best practices) برای تست و تضمین کیفیت وجود دارد که یک فرد یا تیم باتجربه و متخصص بر آن‌ها مسلط است ولی شاید تیم توسعه به درستی از آن‌ها استفاده نکند. بنابراین تیم افراد متخصص در زمینه کیفیت نرم‌افزار می‌توانند برای ارتقای کیفیت نرم‌افزار به تیم توسعه کمک کنند. در این نوشتار، به تیم افراد متخصصی که به توانمندسازی تیم توسعه در زمینه ارتقای کیفیت نرم‌افزار کمک می‌کنند، تیم کیفیت نرم‌افزار گفته می‌شود.
جایگاه تیم کیفیت در ساختارهای مختلف توسعه نرم‌افزار
با توجه به اندازه و ساختار شرکت یا سازمان توسعه نرم‌افزار، شکلهای مختلفی از تیم کیفیت متصور است.
1- بدون تیم کیفیت در شرکت‌های کوچک یا تیم‌های کوچک متخصص
در برخی موارد، مخصوصاً وقتی که تیم توسعه نرم‌افزار کوچک است و یا افراد تیم توسعه از نظر کیفیت نرم‌افزار هم باتجربه و متخصص هستند، تیم مستقلی برای کیفیت برپا نمی‌شود.
2- تیم کیفیت برای توانمندسازی سایر تیم‌های شرکت
در این رویکرد، تیمی از افراد متخصص در زمینه کیفیت نرم‌افزار، به تیم‌های توسعه نرم‌افزار کمک می‌کنند تا از ابزارها و روش‌های توسعه کیفی نرم‌افزار بهتر استفاده کنند. در این مدل، تیم کیفیت بخشی از بدنه همان شرکت توسعه نرم‌افزار است و به توانمندسازی تیم‌ها و پروژه‌های مختلف این شرکت کمک می‌کند. مثلاً این‌جا را ببینید.
3- برون‌سپاری بخش‌هایی از دغدغه‌های کیفیت نرم‌افزار به تیم‌های خارج از شرکت
در این رویکرد، تخصص، ابزارهای مناسب و یا زمان کافی برای نیل به برخی دغدغه‌های کیفیت نرم‌افزار در شرکت وجود ندارد و دانش فنی و یا ابزارهای موردنیاز، به عنوان خدمت (as a service) از خارج از شرکت (از یک مجموعه یا فرد یا شرکت دیگر) دریافت می‌شود. مثلاً زیرساخت ابری، ابزارهای پایش خدمات (Monitoring) و ابزارهای مدیریت و تحلیل لاگ می‌توانند توسط تیمی (شرکتی) غیر از تیم توسعه نرم‌افزار راه‌اندازی شوند.
4- برون‌سپاری توسعه نرم‌افزار و برون‌سپاری دغدغه‌های کیفیت نرم‌افزار به تیم‌های خارج از سازمان
برخی از سازمان‌ها، بهره‌بردار نرم‌افزار هستند ولی خود تولیدکننده آن نیستند. به عبارت دیگر واحد توسعه نرم‌افزار خارج از سازمان بهره‌بردار آن است. دولت و نهادهای حاکمیتی، شهرداری‌ها، وزارت‌خانه‌ها، دولت الکترونیک و برخی سازمان‌های خصوصی این گونه هستند. غالباً در این موارد، تخصص مربوط به دغدغه‌های کیفیت نرم‌افزار هم در سازمان بهره‌بردار وجود ندارد و مدیریت این دغدغه به تیم توسعه و یا نهاد دیگری تنفیذ می‌شود. به خصوص در سازمان‌های بزرگ، تنفیذ کامل مدیریت کیفیت به همان پیمانکاران توسعه نرم‌افزار مخاطره‌آمیز است. تمرکز نوشتار جاری، مرور چالش‌های مدیریت و تضمین کیفیت نرم‌افزار در چنین فضایی به خصوص در سازمان‌های بزرگ است. برخی از این چالش‌ها، در سطحی بالاتر از فرایند توسعه نرم‌افزار شکل می‌گیرند ولی بر فرایند توسعه نیز تأثیر می‌گذارند. در فرایند تضمین کیفیت نرم‌افزار در یک سازمان بزرگ، رعایت چابکی فرایند توسعه و چابکی فرایند تعامل کارفرما-پیمانکار نیز حیاتی است. به خصوص برای سازمان‌هایی که بازار آن‌ها در حال تغییر است و نیازمند عکس‌العمل و تغییر نرم‌افزار برای نیل به نیازهای بازار کسبوکار خود هستند.
چالش‌های افزایش کیفیت و چابکی در سازمان‌های بهره‌بردار غیرتوسعه‌دهنده
سازمان (کارفرما) بزرگی را در نظر بگیرید که شرکت‌های مختلف (پیمانکاران) برای نیازمندی‌های مختلف این سازمان نرم‌افزارهای متنوعی تولید می‌کنند و برای بهره‌برداری به این سازمان تحویل می‌دهند. فضای کسبوکار این سازمان به‌گونه‌ای متغیر است که این سازمان به صورت مستمر نیازمند تغییر، بروزرسانی و بهبود نرم‌افزارهای خود است. مثلاً با توجه به نیازهای کسبوکار، به صورت مستمر امکانات جدیدی به نرم‌افزار اضافه می‌شود. فرض کنید سامانه‌های مختلف نرم‌افزاری در این سازمان، به صورت مستقل و جزیره‌ای کار نمی‌کنند و ارتباطات متنوعی با یکدیگر دارند. سازمان بهره‌بردار (کارفرما) معمولاً بدنه فنی کوچکی دارد و تمرکز آن بر نحوه بهره‌برداری نرم‌افزار است و نه بر فرایند توسعه نرم‌افزار.
در چنین فضایی، که فضای رایجی برای بسیاری از سازمان‌های بزرگ (مثلاً دولت الکترونیک و شهرداری‌ها) است، چالش‌های مختلفی وجود دارد. بسیاری از این چالش‌ها، در فضاهای دیگر توسعه نرم‌افزار (مثلاً در درون یک شرکت توسعه‌دهنده نرم‌افزار) وجود ندارد و یا بسیار ساده‌تر است. بنابراین راهکارهای رایج و مناسب در این فضاها لزوماً برای فضای سازمان‌های بزرگ غیرتوسعه‌دهنده، کارا و مناسب نیست.
برخی از چالش‌های مدیریت چابک کیفیت در سازمان‌های بهره‌بردار غیرتوسعه‌دهنده در ادامه آمده است:
- تعدد ذی‌نفعان و تعارض منافع (Conflict of interest)
منافع هر پیمانکار ممکن است در تعارض با منافع کارفرما یا پیمانکاران دیگر قرار گیرد. آن چه به نفع کارفرما یا برخی پیمانکاران است، شاید در حیطه مسؤولیت‌ها و تعهدات یا منافع پیمانکاری دیگر قرار نگیرد.
- قراردادهای قیمت ثابت (fixed price)
وقتی قرارداد بین کارفرما و پیمانکار شرح خدمات و محدوده مشخصی دارد، اجازه تحرک و بیان نیازمندی جدید از سمت کارفرما به پیمانکار گرفته می‌شود. مثلاً اگر کارفرما نیازمند تغییراتی در نرم‌افزار باشد و یا تمهیداتی را برای ارتقای کیفیت یک سامانه لازم ببیند، لزوماً نمی‌تواند تا موعد تمدید قرارداد منتظر باشد تا تعهدات جدید را در قرارداد جدید پیمانکار بگنجاند.
- دانش فنی منحصر در پیمانکارها
دانش فنی مربوط به هر محصول یا سامانه نرم‌افزاری، عمدتاً در سمت پیمانکار این محصول قرار دارد.
- وابستگی به فروشنده (Vendor lock-in)
کارفرما به پیمانکار وابسته می‌شود و نمی‌تواند پیمانکار را جایگزین کند و خدمت مربوطه را از پیمانکار دیگری دریافت کند.
- تعدد ارتباط بین سامانه‌ها/سرویسهای مختلف
وجود ارتباطات متعدد و پیچیده بین سامانه‌های مختلف
راهکارها
در این بخش به مرور برخی راهکارها در زمینه چالش‌های مطرح شده می‌پردازیم.
- مدیریت دانش
- توجه به فرایند صحیح مدیریت دانش
- استفاده از ابزار مناسب (مثل ویکی) و پرهیز از روش‌های ناکارامد (مستندات ورد و پی‌دی‌اف، تبادل ایمیلی و ...)
- ثبت و انتشار صحیح مستندات و دانش سازمان
- قراردادهای منعطف‌تر
وقتی همه شرح خدمات در قرارداد مشخص شود و مبلغ قرارداد ثابت باشد، انعطاف برای بررسی و اجرای دغدغه‌های مختلف (از جمله دغدغه‌های مربوط به کیفیت) گرفته می‌شود. بخش‌هایی از تعهدات می‌تواند با الگوهای دیگر (مثل پرداخت نفر-ساعتی) تعهد شود. انگیزه لازم در سمت پیمانکار برای این منظور ایجاد شود. مکانیزم مناسب برای نظارت و بهره‌برداری از این پتانسیل باید در سمت کارفرما ایجاد شود.
- توجه به چابکی
- چابکی سازمان، چابکی تعامل با پیمانکاران، چابکی فرایندهای توسعه نرم‌افزار و چابکی فرایندهای تضمین کیفیت باید حفظ شود.
- توجه به راهکارهای «چابکی مدرن» (Modern Agile)
- درس گرفتن از اشتباهها و تجارب
- پذیرش Multi-speed IT
همه پیمانکاران، همه سامانه‌ها و همه پروژه‌ها در یک سطح از بلوغ و سرعت و چابکی نیستند.
- شکستن و تقسیم بیشتر کار و تعدد پیمانکاران قابل جایگزینی
در فضایی که نیازمندی‌ها به سرعت تغییر می‌کنند، نیاز به تغییر سریع بیشتر احساس می‌شود. اما راه‌حل‌های جامع (total solution) با لَختی و کندی بروز می‌شوند. استفاده از راه‌حل‌های جامع در فضای کسبوکار در ایران، که شامل محدودیت‌های جدی از نظر تحریم و هزینه است و معمولاً راه‌حل‌های جامع بالغی هم هنوز در کشور ارائه نشده است، با مشکلاتی همراه است. شاید راه‌اندازی یک راه‌حل جامع ممکن و سهل‌الوصول باشد، ولی نگهداری و تکامل آن در فضای زیست‌بوم کسب و کار سازمان بزرگی که در حال تغییر است، مشکل خواهد بود.
- نیاز به تقویت تیم فنی کارفرما
سازمان چابکی که به شکل فعال در زمینه‌های فنی محصولات نرم‌افزاری مشارکت می‌کند، نیازمند تقویت تیم فنی خود است. بسیاری از سازمان‌ها، تیم فنی نحیفی دارند که توانایی مشارکت در یک فرایند چابک برای تغییر و توسعه و تکامل محصولات نرم‌افزاری را ندارند و بنابراین ترجیح می‌دهند بر نیازمندی‌های نهایی و محیط بهره‌برداری تمرکز کنند. یک راهکار برای رفع این دغدغه، تقویت تیم فنی سازمان از طریق پیمانکار (مثلاً شرکت مشاور) است.
- خودکارسازی گزارش‌های مربوط به کیفیت
همان طور که در سامانه‌های هوش تجاری (BI) گزارشها از خود داده‌ها ساخته می‌شود (کسی محتوای گزارشها را تولید نمی‌کند) گزارش‌های مربوط به کیفیت نرم‌افزار هم به شکل خودکار از داده‌های خام مربوط به کیفیت ساخته شود و کسی محتوای گزارش را تولید نکند. مثلاً بدیهی است که در مدیریت کیفیت سامانه‌های نرم‌افزاری، گزارش‌های مربوط به پایش سامانه‌ها به صورت خودکار (مثلاً از طریق ابزارهایی مثل Zabbix و ELK) ساخته شوند. اما در چارچوب چابکی تضمین کیفیت برای یک سازمان بزرگ، باید فراتر از این موارد رفت. این ابزارها باید در سطح سازمان و برای سامانه‌های مختلف به شکل یکپارچه درآیند. به عنوان یک مثال دیگر، گزارش‌های شفافی درباره کارکرد افراد پروژه پیمانکاران (مثلاً از طریق JIRA Worklogs و نه از طریق تولید گزارش کارکرد) به مدیریت قراردادهای منعطف کمک می‌کند.
- توجه به معماری نرم‌افزار
- دانش صحیح، صریح و متمرکز معماری ثبت شود.
- معماری هر سامانه نرم‌افزاری به خوبی مستند شود. شیوه مستندسازی یکپارچه و منظم باشد. از بروز بودن و صحت مستندات اطمینان حاصل شود. ابزار و فرایند مناسبی برای ثبت و نگهداری مستندات انتخاب شود (مثلاً ویکی و نه pdf).
- معماری نرم‌افزارهای کل سازمان و نحوه تعامل و ارتباطات سامانه‌های مختلف ثبت و نگهداری شود.
- توجه به DevOps و DevSecOps
رویکردها، ابزارها و به‌روش‌های دواپس، هم در محیط توسعه پیمانکاران و هم در محیط عملیاتی بهره‌برداری موردتوجه قرار گیرد.
- بستر تست و تضمین کیفیت
تست تجمیعی سرویسهای مختلف. امکان بدلی کردن (Mock) برخی از سامانه‌ها برای بهبود سرعت و چابکی تست‌ها.
- رویکردهای تست A/B
توجه به امکان تست A/B توسط سامانه‌های مختلف نرم‌افزاری جهت دریافت بازخورد سریع و واقعی از تغییرات.
مطلبی دیگر از این انتشارات
تقاطع زیرساخت و تیم توسعه در کیفیت نرم‌افزار
مطلبی دیگر در همین موضوع
رزومه ساز کاربوم، به راحتی رزومه ای کاملا حرفه ای بسازید
بر اساس علایق شما
این پست تماشایی است!