قبل از هر چیز باید گفت من معتقدم که تیمهای موروثی در زمینه تضمین کیفیت(تیمهایی که برای مدت طولانی به ضکل روتین در یک شرکت مشغول انجام فعالیتهای تضمین کیفیت هستند) میتوانند برای پشتیبانی از یک تیم مهندسی ترکیبی در زمینه DevOps مجددا کسب مهارت کرده، و البته به صورت بالقوه میتوان این کار را برای دیگر تیمهای موجود در سازمان نیز انجام داد. من در این مقاله قصد دارم تا اولین گام عمومی را برای طرح آموزشی که میتواند بر اساس نیازهای شما اصلاح شود را ارائه دهم. این موضوعیست که تیم خود ما تجربه آنرا دارد.
حوالی سال ۱۳۹۱ یا ۱۳۹۲ بود که در یک رویداد با عنوان “سمپوزیوم مدیریت اطلاعات” شرکت کردم. در یکی از کارگاهها طی یک گفت و گو یکی از شرکتکنندگان از سخنران جلسه پرسید که بزرگترین رقیب او کیست. سخنران جلسه پس از کمی تفکر درباره پاسخ این سوال، جواب داد: “وضع موجود”. این یک پاسخ دقیق بود که رقیب واقعی را نام نبرد اما همین موضوع در مورد بسیاری از کمپانیها و تیمها درست بود.
مقاومت در برابر تغییر میتواند بسیار زیاد و قوی باشد، اما به عنوان یک مدیر، شما باید به تیمهایتان برای تطابق با شرایط جدید و آموزش انگیزه دهید. استخدام و حفظ استعداد بعد از موضوع امنیت و ایمنی تیم، مهمترین کار هر مدیر است. حفظ استعداد صرفا به معنی حفظ افراد نیست، بلکه مقصود حفظ و نگهداشت افرادیست که میتوانند نیازهای امروز و آینده کسب و کار را پشتیبانی کنند.
Command Prompt
این قسمت احتمالا بیشتر توجه علاقمندان لینوکس را جلب میکند چرا که کاربران Windows و Apple خیلی در زمینه استفاده از خط فرمان توانمند نیستند و باز هم احتمالا هیچگاه و یا بسیار کم از Command Prompt بهره گرفتهاند. استفاده از Command Prompt برای کسی که کار با کامپیوتر را در دهههای ١٩٨٠ و ٩٠ شروع کرده یک امر اجباری بوده است. اما امروزه کودکان ٣ ساله هم از ipad استفاده میکنند. بنابراین هیچ جای تعجبی نیست که اعضای جوان تیم هیچ وقت و یا کمتر نیاز به یادگیری استفاده از Command Prompt دارند.
تعداد کمی از غیر برنامهنویسان که هیچ یک از ابزارهای سیستمی یا دستورات Powershell برای ایجاد کاربران در Active Director را به کار نگرفتهاند، امروزه نیاز به ویرایش متغیر محیطی دارند.
من با فرض اینکه همه اعضای تیم(تیمی که من در آنجا را مشغول به کار بودم) استفاده از Command Prompt را میدانند، یک اشتباه مرتکب شدم. اگر شما مسئولیت مدیریت در تیم تضمین کیفیت را دارید، بهترین کار این است که در ابتدا یک آمارگیری گسترده برای یک نتیجه گیری کلی انجام دهید، و سپس برای آنهایی که هنوز مهارتشان این موضوع را شامل نمیشود، یک برنامه آموزشی ایجاد نمایید. یادگیری بهرهگیری از Command Prompt سخت نیست. برخی از دستورات اولیه به همراه تنظمیات اولیه و ساده را آماده نموده و برای آموزش به آنها منتقل نمایید. هر چند ممکن است آنها این دستورات را امروز استفاده نکنند، اما قطعا آگاهی از این اطلاعات میتواند در بکارگیری این افراد در نقشهای آتی ایشان در حوزه IT به کارشان بیاید. به آنها یادآوری کنید که هر چند ممکن است تست دستی به طور کانل منقضی نشود، اما روز به روز نقشهایی که درگیر تست دستی باشند، کمتر و کمتر خواهد شد. زبانهای اسکریپتنویسی، Cloud، لینوکس و دیگر تکنولوژیها، همگی به Command Prompt متکی هستند. به عنوان یک مدیر، تیم و شرکت خود را در یک مسیر درست هدایت نمایید، و سپس اجازه دهید این تیم شما را با موفقیتهای خود غافلگیر کند. آنها زمانی که متوجه شوند به جای حرکت دادن موس با تایپ کردن میتوانند با استفاده از شگردهای فنی کار را خیلی سریع انجام دهند، قطعا به آن علاقمند میشوند.
مهارتهای وب
خیلی از تسترهای دستی در تست وب به صورت تعاملی بسیار عالی عمل میکنند، اما نیاز به توانمندیهای تکنیکی دارند. به جای اینکه آنها مرتب خطای ۴۰۴ را به ما گزارش کنند، و معنای آنرا ندانند، بهتر است به آنها یاد بدهیم که HTTP 404 response چیست.
هر آنچه که در محیط شما مانند Request, Page Caching, HOSTS File, TCP/IP, SSL/TLS, DNS نیاز است را به آنها یاد دهید. سپس به آنها مبانی XML,JSon,Soap و Rest را آموزش دهید. زیرا خیلی از تسترها بدون آنکه متوجه شوند چه اتفاقی در پس UI رخ میدهد، سرویسهای وب را با مرورگر تست میکنند. از یکی از اعضای تیم بخواهید تا آنچه را در شرکت شما نیاز است را در یک پایگاه دانش یا Wiki گردآوری کرده و مستند نماید.
Source control(کنترل نسخه)
سپس این تیمها نیاز به درک سیستمهای کنترل نسخهای دارند که شما از آنها استفاده میکنید. Git یک سیستم متداول است اما ممکن است برای این کار سیستمهای دیگر مانند Mercurial و یا Team Foundation Server بسیار مناسبتر باشند. با توجه به درک اعضای تیم از Command line جدید، بزای آنها یک Test Repository ایجاد کنید. در ابتدای امر احتمالا تیم باید ۳ امتیاز از ۱۰ امتیاز مهارت را برای موفقیت داشته باشد و باقی آنرا طی مواجهه با نیازهای پیشرفته فرا بگیرد، زیرا آموزش مهارت بیش از این مقدار، آنها را دچار انباشتگی اطلاعات و کاهش راندمان خواهد کرد.
در حالیکه تعداد زیادی دوره آموزشی از Git(یا دیگر ابزارها) در یوتوب وجود دارد، ممکن است شما کسی را برای آموزش درون تیمی، انتخاب کنید. همان طور که هر کس علاقمند به دریافت یک رتبه بیش از حد انتظار در گزارشات آخر سال است، به افراد این موضوع را تفهیم کنید که داوطلب شدن به عنوان آموزش دهنده Git(یا دیگر ابزارها) میتواند یک قدم به سوی این هدف باشد. ما این موضوع را امتحان کردیم که بهتر است با دانشپژوهان تعامل کنید و به آنها تکلیف دهید، و از آنها بخواهید این تکالیف را انجام دهند. بسیاری از تازه کارها کد را در همین زمان Pull و Push میکنند، بدون اینکه متوجه باشند که چه کار میکنند و به این ترتیب در جریان کار استاد دوره اختلال ایجاد میکنند.
اعضای تیم سپس در Pull کردن، Push کردن، Branching و Merg کردن کدها راحتر بوده و آمادهنر خواهند شد، تا به این ترتیب تدریجا به استفاده از Source Control Repository واقعی سوییچ کنند. شاید بعضی فقط اصرار به دسترسی به صورت Read-Only داشته باشند اما ما به این نتیجه رسیدهایم که دسترسیهای عمومیِ یکسان بهتر است. تنظیم انتظارات باعث میشود که آنها کد را خارج از محدوده مسئولیت خود تغییر ندهند. یکی از دوستان من که در مایکروسافت و در تیم Office 2010 مشغول به کار بود، میگفت تقریبا این امکان را داشتهاند که هر چیزی را در کد منبع شرکت تغییر دهند، اما این کار را نمیکردند. آنها به این باور رسیده بودند که افرادیکه خود را بخشی از شرکت میدانند، و دارای دانش کافی نیز میباشند، منابع قابل اعتمادی هستند.
تیم QA را تشویق کنید تا آخرین کد را هر روز چک کنند و به دنبال تغییرات باشند. هر یک از اعضای QA را با یک Developer هم گروه کنید و مطمئن شوید که آنها میتوانند ورودیها را در Source Control ببینند و کد را مرور کنند. همانطور که آنها در یادگیری کد به پیش میروند، خواندن کد نیز به آموزش آنها کمک خواهد کرد.