هوشیاری چابک: 6 اصل برای کمک به موفقیت فرآیند طراحی نرم افزار شما

0 0
Read Time:3 Minute, 6 Second

زنی که روی یادداشت های پس از آن می نویسد

iStock

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

این یک نکته کلیدی است بحث که در کنفرانس اخیر GOTO 2022 بین پیر پورور، نویسنده مشترک معماری پیوسته در عمل، و کرت بیتنر، رئیس راه حل های سازمانی در Scrum.org.

Pureur تاکید کرد که طراحی و حفظ یک معماری نرم‌افزاری با عملکرد خوب، بیش از همه، به صبر نیاز دارد.

او ادامه داد که عجله در راه حل فناوری قبل از پرسیدن سؤالات مناسب به معنای از دست دادن ویژگی ها یا عملکردهایی است که ممکن است برای کسب و کار حیاتی باشند. تیم‌هایی را دیده‌ام که با پایان در ذهن شروع می‌کنند، و می‌دانند که می‌خواهند فناوری‌هایی را وارد کنند. شخصی به آنها گفت: “ما باید در ابر آمازون باشیم.” پاسخ ابر ​​آمازون خواهد بود، و شما حتی این سوال را نمی‌پرسید، درست است؟

برای سال‌ها، طراحی یک معماری نرم‌افزار به معنای طراحی چیزی از قبل و سپس حرکت به مرحله استقرار بود. پورور گفت: تحت مفهوم سنتی معماری، «ما یک خط کد نمی نویسیم تا زمانی که تمام معماری به پایان برسد».

البته مشکل این رویکرد این است که دانستن همه چیز به یکباره بسیار سخت است. طراحی یک معماری زمانی که بیش از نیمی از نیازهای شما نادرست است، نتایج خوبی به شما نخواهد داد. تکامل یابد.”

همچنین: معماران سازمانی مسئولیت انقلاب دیجیتال را بر عهده می گیرند

رویکردهای چابک تری تکامل یافته اند و این فرآیند را تکراری تر می کند. با این حال، این فرض را بر این می گذارد که، “شما کد می نویسید، و به نوعی معماری، مانند نهنگی از آب بیرون می آید.” اما این منجر به نیاز به “بازسازی و تعدیل زیادی” می شود.

توسعه چابک گامی در مسیر درست است، اما برای یک معماری مستمر، طراحان و توسعه دهندگان نرم افزار باید آن را یک قدم جلوتر بردارند.

آنها باید سوالات سخت را بپرسند: کسب و کار به چه چیزی نیاز دارد؟ چه چیزی با کاربران یا مشتریان بهتر کار می کند؟ چه بخش هایی از کسب و کار باید با فرآیند طراحی درگیر شود؟

همچنین: مهارت های کدنویسی مورد تقاضا هستند، اما شرکت ها بیشتر از متخصصان فناوری می خواهند

Pureur توضیح داد که شش اصل زیربنای یک معماری مداوم موفق است. “هیچ یک از اصول جدید یا زمین گیر نیستند، اما در کنار هم، معنای زیادی دارند.” این اصول عبارتند از:

  • به جای پروژه، محصولات بسازید.
  • روی ویژگی های کیفیت تمرکز کنید و زیاد نگران الزامات عملکردی نباشید.
  • تصمیمات را تا زمانی که مطمئن شوید که باید تصمیم بگیرید به تاخیر بیاندازید.
  • برای تغییر برنامه ریزی کنید زیرا همه چیز تغییر خواهد کرد — پس به “طراحی کوچک” فکر کنید.
  • به یاد داشته باشید که آزمایش برای استقرار یک سیستم تقریباً مهمتر از ساختن سیستم است.
  • تیم خود را با افرادی سازماندهی کنید که با تمام جنبه های سیستم سروکار دارند.

پورور می‌گوید: «مردم معماری را به‌عنوان نقشه‌ها، نمودارهای زیبا و غیره تصور می‌کنند. “بله، شما باید آن چیزهایی را داشته باشید که باید به عنوان بخشی از معماری با آنها ارتباط برقرار کنید. همانطور که به طور مداوم تصمیم می گیرید، یاد خواهید گرفت، این حلقه مداوم یادگیری را خواهید داشت، و خواهید رفت. از اشتباهاتت درس بگیری، به عقب برگردی و تصمیماتت را مدام مرور کنی.”


لینک منبع

Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

نوشته های مشابه

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا