مصاحبه با اعضای فنی استارت‌آپ‌های تکنولوژیک در مورد کارکرد درس مهندسی نرم افزار

متدولوژی اولیه

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

مصاحبه اول
مصاحبه‌ی اول با مدیر محصول فنی ارشد و دانشجوی دکترای مهندسی نرم‌افزار
وی به صورت کلی وظایف مدیر محصول فنی را در دو بخش کشف (Discovery) و ارائه (Delivery) می‌بیند.

کشف

خروجی این بخش که از طریق پرس‌و جو از کاربر، جست و جو در بازار (Market research)، بررسی رقبا (Bechmarking)، جلسه با سهام‌داران محصول (Product Stakeholders) و… حاصل می‌گردد، تعدادی فرضیات خواهد بود. فرایند ذکر شده تا حد بسیاری در قالب مهندسی نیازمندی می‌گنجد. این فرضیات پس از تست اولیه مبدا به وجود آمدن تعدادی تسک(Task) می‌باشد. پس از تعریف تسک‌ها با کمک روش‌هایی مانندuser story، لازم است که به اولویت‌بندی آنان بپردازیم چرا که معمولا در نیازمندی‌ها شناسایی شده و در راستای این مورد، تسک‌های استخراج شده باید در قالب زمانی محدودی به ثمر برسند. عملا می‌توان گفت که در صنعت مهم‌ترین دلیل اولویت‌بندی رقابت ما با زمان است. در این پروسه می‌توان از چهارچوب‌هایی (Frameworks) چون MoSCoW، RICE و … استفاده کرد. لازم به ذکر است در انتخاب این چهارچوب‌ها، بایستی که به دو عامل ارزش کاربران (User values) و ارزش کسب‌وکار (Business values) توجه کرد. فرضا علیرضا در تدوین نقشه‌ راه (Roadmap) تیم خود، از دو چهارچوب تاثیر-تلاش (Impact Effort) استفاده کرد. وی بخش Impact را از طریق امتیازدهی توسط ذی‌النعان (Scoring by stakeholders) کسب و کاری و بخش Effort را از طریق امتیازدهی توسط ذی‌النفهان فنی به دست آورده و سپس با تشکیل ماتریس مربوطه، به اولویت‌بندی تسک‌های نقشه راه پرداخت. در گام بعد و به جهت یافتن دیدی شفاف‌تر بر حجم نسبی تسک‌ها وی با تعامل با تیم فنی، به هر تسک یک Story point اختصاص داد. یکای این Story pointها از روش t-shirt size به دست آمد. در انتها نیز به باز بررسی و تعریف مواردی چون سناریو‌ها، جرنی‌ها و… می‌پردازیم تا تسک به شفاف‌ترین حالت خود برسد و با تعامل ذی‌النفعان، علاوه بر از بین بردن تمامی ابهام‌ها، از انطباق تسک‌های تعریف شده با نیازمندی دی‌النفعان اطمینان حاصل کرد. در این مرحله اصطلاحا گفته می‌شود که باید نسبت به تسک تعریف شده مطمئن (Confident) بود. پس می‌توان پروسه کشف نیازمندی را در سه گام تعریف کرد:

• بررسی نیازمندی‌ها از ذی‌النعان مختلف
• شفاف‌سازی تسک با کمک روش‌هایی چون User Story
• اولویت‌بندی با کمک چهارچوب‌های انتخاب شده در راستای ارزش‌های کسب و کاری و کاربران
• باز بررسی تسک تا رسیدن به مرحله اطمینان (Confident)

ارائه

هدف از این گام ساختن (Build)، سنجش (Test) و پخش (Release) محصول و یا بخشی از آن می‌باشد. در این بخش روشگان‌هایی چون چابک (Agile)، چارچوب‌هایی چون اسکرام (Scrum) و همچنین مباحث تست نرم‌افزار به میان می‌آیند. لازم است که برای تسک‌ها تعریف پایان (Definition of Done یا DoD) و ملاک پذیرش (Acceptance Criteria) تعریف نماییم تا همه افراد دخیل به تعریفی یکتا و شفاف از به پایان رسیدن تسک برسند. از مصداق‌های این دو می‌توان به انجام عملی خاص توسط کاربر، رسیدن مقادیر کمی یک متریک به حدی خاص و… اشاره کرد.

فلسفه کافی (Lean) از مفاهیم جامع در تمامی پروسه‌های تولید می‌باشد و محدود به مهندسی نرم‌افزار و به طور کلی حوزه IT نمی‌باشد. یکی از اصول این فلسفه بیان می‌دارد که برای پیاده‌سازی کاری بزرگ، ابتدا بخش کوچکی از آن را انجام دهید و سپس در صورت رسید به اهداف دل‌خواه، به انجام بخش‌های بزرگ‌ آن بپردازید. روش چابک بازنمایی این فلسفه در پروسه توسعه نرم‌افزار می باشد. مزیت این پروسه ساخت و سنجش سریع محصول می‌باشد که خود باعث کاهش چشم‌گیر ریسک حاصل از تغییر می‌باشد. نشست‌ها (جلسات روزانه، بازبینی، برنامه‌ریزی و…) و همچنین اسناد (بک‌لاگ و…) همه و همه ابزارهای برای راه‌اندازی چرخه‌ای به‌جهت تولید و سنجش سریع محصول، تیم و رویه‌ها می‌باشند.

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

مصاحبه دوم
مصاحبه دوم با مهندس داده ارشد و مشاور مهندسی و مهندس داده
در این بخش عمدتا به بررسی کاربرد مفاهیم مهندسی نرم‌افزار در حوزه داده (Data) می‌پردازیم.

در بسیاری از حوزه‌های کاری فنی من جمله نرم‌افزار، داده، شبکه مباحث اجایل به شکل‌های مختلفی چون اسکرام و کنبان (Kanban) به جهت مدیریت زمان و تسک‌ها استفاده می‌شوند. مهندسی نیازمندی نیز از دیگر مباحثیست که در حوزه مهندسی داده و بالاخص در بخش پایگاه‌بندی داده (Data warehousing) جایگاه مهمی دارد و شفاف‌سازی نیازمندی‌های تمامی ذی‌النفعان پیش از آغاز فرایند تولید و پی بردن به اهداف جامع صورت دادن تسک‌ها کمک شایانی به تصمیم‌گیری‌های فنی در تمامی ابعاد بالاخص در بخش برنامه‌ریزی می‌کند. این برنامه‌ریزی می‌تواند در سطح زیرساخت باشد. (فرضا نوع ورود داده، هم‌زمانی، دسته‌بندی‌ها و…) مثلا در صورت وجود نیازمندی به موقع (Real Time) به زیر ساخت داده‌ای، لازم است از ابزاری چون Kafka و Spark استفاده شود. این در حالیست که در صورت نیازمندی دسته‌ای (Batch)، می‌توان به صورت مستقیم از منبع داده (Data Source) از داده‌ها استفاده نمود. پس می‌توان گفت تشخص نیازمندی‌ها بخش تاثیرگذاری از پروسه مهندسی داده می‌باشد. در زمینه تست نیز می‌توان برای خط لوله‌های (Pipelines) مختلف به نوشتن تست پرداخت. فرضا معمولا در صورت استفاده از ابزاری چون Apache Airflow برای توسعه پایپ‌لاین‌های داده در توسعه نرم‌افزار سازمانی (Enterprise) معمولا سه محیط تعریف می‌شود:

• محیط توسعه (Develop)
• محیط تست (Test)
• محیط محصول (Production)

در همین راستا تست‌های نوشته شده، پیش از ورود به محیط پروداکشن، به بررسی و یا اصطلاحا چک و تیک (Check and Tick) پایپ‌لاین‌ها، از ابعادی چون نوشتار (Syntax)، اعتبار داده (Data validation) و… می‌پردازند. همچنین شناخت صحیح نیازمندی‌ها و به دست آوردن درکی جامع از معیار‌ها، عنصری مهم در بخش مصورسازی داده‌ها می‌باشد.

معماری پروژه‌های داده‌ای دارای مفاهیم مشابه زیادی با معماری‌های مورد استفاده در توسعه نرم‌افزار دارد. مشابها در پایپ‌لاین‌های داده‌ای نیز قوانینی چون ماژولار بودن (Modularity)، مجزا بودن و… رعایت می‌گردد. این قوانین در هنگام بالا آوردن ابزار‌های پایپلاین‌های داده‌ای بر بستر Kubernetes نیز مورد استفاده قرار می‌گیرند. فرضا در هنگام بالا آوردن Apache Airflow بر بستر Kubernetes به ازای هر پایپلاین داده‌ای، یک Pod تعریف می‌کنیم که به صورت مستقل از دیگر Pod ها به ارائه عملکرد می‌پردازد و در انتها نیز به جهت صرفه‌جویی در منابع به پایین آوردن (Down) آن Pod می‌پردازیم.

قوانین نانوشته (Best Practise) مهندسی نرم‌افزار در حوزه دیتا را می‌توان در به سه بخش تقسیم کرد.

• زیرساخت داده
• پایپ‌لاین‌های داده
• مصورسازی و ارائه داده

از جمله قوانین نانوشته می‌توان به نحوه کانفیگ زیرساخت‌های مختلف داده‌ای (Ram, CPU و…) و بر اساس کوئری‌های ارسالی و کاربران اشاره کرد.

فرضاً در توسعه ابزار Click house در حالت Cluster، در نظر گرفتن مباحثی چون Distributed و Sharding از موارد بسیار مهم می‌باشد. در نظر گرفتن ۶ گره (Node) متشکل از سه Distribution و دو Shard برای Clustering نوعی بست‌پرکتیس می‌باشد. تنظیمات(Config) بهینه Spark برای Clustering آن، به جهت اجرای هم‌زمان چند Worker نیز نیازمند استفاده از چنین بست‌پرکتیس‌هایی می‌باشد.