۲۹ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

روش شناسی چابک چیست؟ توسعه نرم افزار مدرن توضیح داد

همه در مورد توسعه چابک صحبت می کنند، اما واقعا چگونه کار می کند؟ بیاموزید که چگونه تیم ها از اسکرام، کانبان و سایر روش های چابک برای ارائه نرم افزار بهتر استفاده می کنند.

همه در مورد توسعه چابک صحبت می کنند، اما واقعا چگونه کار می کند؟ بیاموزید که چگونه تیم ها از اسکرام، کانبان و سایر روش های چابک برای ارائه نرم افزار بهتر استفاده می کنند.

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

روش توسعه نرم افزار چابک چیست

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

این مقاله آغازگر روش‌های چابک است که با افراد، تیم‌ها، فرآیندها و ابزارها شروع می‌شود. همچنین می آموزید که چگونه چابک به devops متصل می شود و درباره بهترین شیوه هایی که به سازمان ها کمک می کند فرهنگ چابکی را پرورش دهند و نرم افزار بهتری ارائه دهند.

نقش در روش شناسی چابک

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

کاربران

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

مالک محصول

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

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

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

آیا به دنبال یک معرفی سریع برای توسعه چابک هستید؟ این ویدیوی پنج دقیقه‌ای را تماشا کنید و به سرعت بالا بروید.

تیم توسعه نرم افزار

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

Agile تیم‌ها را روی ارائه نرم‌افزارهای کار متمرکز می‌کند، بنابراین آنها باید برنامه‌های کاربردی، ادغام‌ها و سایر موارد قابل تحویلی را که بر کاربران تأثیر می‌گذارند، تکمیل کنند – نه فقط اجزای فنی. اعضای تیم باید بر اساس آنچه می‌سازند، چه کسی چه کاری انجام می‌دهد، و نرم افزار چگونه توسعه می یابد.

تیم‌های چابک اغلب نقش‌های دیگری نیز دارند، از جمله موارد زیر:

  • رهبران فنی یا تیم با مالک محصول در زمینه معماری، معیارهای پذیرش غیرعملکردی، توالی، وابستگی ها و سایر ملاحظات فناوری و امنیتی شریک می شوند. سرنخ های فناوری مسئولیت های گسترده ای دارند که ممکن است شامل تخمین داستان‌ها و جزئیات اجرای برنامه ریزی با تیم.
  • استادهای اسکرام اغلب تیم‌های جدید را در مورد فرآیندها، مسئولیت‌ها و ابزارهای چابک هدایت می‌کنند. مسئولیت‌های استاد اسکرام می‌تواند شامل حل بلوک‌هایی باشد که مانع پیشرفت می‌شوند، بررسی رویکردهای بهبود سرعت تیم چابک< /a>، و نظافت های عقب افتاده.
  • تحلیلگران تجاری با صاحب محصول شریک می شوند. مسئولیت‌های تحلیلگران اغلب شامل ایجاد وایرفریم، مستندسازی کاربر است. داستان ها و بررسی نتایج آزمون زمانی که تیم های توسعه نرم افزار در حال توسعه میکروسرویس ها و سایر محصولات فنی هستند و در جایی که تحلیلگر کسب و کار دانش توسعه نرم افزار بیشتری نسبت به مالک محصول دارد، تحلیلگران کسب و کار بسیار مفید هستند.

این به رهبران سازمانی بستگی دارد که چگونه تیم‌های چابک را استخدام کنند و چقدر بزرگ شوند. بسیاری از بهترین روش جف بزوس برای ایجاد رابطه دو تیم چابک به اندازه پیتزا برای به حداکثر رساندن همکاری بین هم تیمی ها.

اسکرام و کانبان چیست

هنگامی که دیدگاه محصول و تیم (یا تیم‌ها) اصول چابک را اتخاذ کنند، با مواردی که در مانیفست چابک شناسایی شده‌اند شروع شود. ، سازمان باید روش شناسی فرآیندی را انتخاب کند. Scrum و kanban فرآیندهای چابک اولیه هستند.

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

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

اسکرام شامل چندین جلسه استاندارد است (گاهی اوقات مراسم اسکرام یا آیین های اسکرام نامیده می شود) برای کمک به تیم ها برای متعهد شدن به اولویت های اسپرینت، تکمیل کار در طول اسپرینت و پایان دادن به هر دوی سرعت. با موفقیت. این جلسات معمولاً شامل چند عنصر مشترک است:

  • برنامه‌ریزی اسپرینت جایی است که مالک محصول اولویت‌ها را به اشتراک می‌گذارد و تیم تصمیم می‌گیرد که چقدر کار می‌تواند در طول اسپرینت انجام دهد. 
  • جلسات

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

لازم به ذکر است که این شیوه‌ها با مدل های کاری ترکیبی چابک.

Scrum عملکرد یک تیم را با توانمند ساختن تیم برای متعهد شدن به مقدار قابل دستیابی کار به جای اینکه یک مدیر محصول، برنامه یا پروژه تعیین کننده زمان و محدوده مورد انتظار باشد، بهبود می بخشد. داستان کاربر یک قرارداد خرد را تشکیل می دهد که نیازهای تجاری، معیارهای پذیرش (یا آنچه که تیم های چابک گاهی اوقات تعریف انجام شده می نامند) را از هم جدا می کند، و سپس به تیم ها امکان می دهد بر اساس چگونه خود سازماندهی کنند. > اجرا شود. بررسی‌های Sprint یکی از انواع حلقه بازخورد هستند، و صاحبان محصول تشویق می شوند قبل از هر دوی سرعت، اولویت ها را دوباره تنظیم کنند و الزامات را دوباره تعریف کنند. مرورهای گذشته اسپرینت به تیم کمک می کند تا همکاری را بهبود بخشد و بهبود فرآیند را آغاز کند.

بهترین شیوه های فنی برای سازمان های چابک

Scrum فرآیند اساسی را برای تیم‌هایی تشکیل می‌دهد که با هم همکاری می‌کنند، برنامه‌ریزی می‌کنند و ارائه می‌کنند، اما به بهترین شیوه‌های فنی، استانداردهای سازمانی، یا تعریف و هدایت فرهنگ‌های چابک اشاره نمی‌کند.

امروزه، بسیاری از بهترین شیوه های فنی عبارتند از تعریف چرخه عمر توسعه نرم افزار (SDLC) و پیاده سازی فرآیندهای devops. SDLC دستورالعمل‌هایی را درباره نوشتن کد، مدیریت دارایی‌های نرم‌افزار، و توسعه استانداردهای فنی. اتوماسیون هایی مانند CI/CD را توسعه می دهد. , زیرساخت به عنوان کد (IaC ) و آزمایش مداوم مسیر قابل اطمینان تری را برای تولید فراهم می کند. روش‌های دیگر، از جمله روش‌های امنیتی shift-left< /a>، ریزسرویس های قابل مشاهده، پرچم گذاری ویژگی، آزادسازی قناری و AIOps، یک مدل تحویل انعطاف پذیرتر و قابل اعتمادتر ارائه می دهد.

ترکیب توانمندسازی تیم‌های خودسازمانده، روش‌شناسی چابک، توسعه خودکارسازی و مدرن‌سازی معماری‌های ابری به سازمان‌های فناوری کمک می‌کند تا فرهنگ خود را تکامل دهند. چرخه‌های توسعه طولانی‌تر با مدل‌های تحویل مداوم< جایگزین می‌شوند. /a> که امکان انتشار سریعتر ویژگی ها و بهبودها را فراهم می کند. اتوماسیون ها بسیاری از شکاف ها را بین توسعه دهندگانی که به دنبال استقلال و سرعت هستند با مسئولیت های عملیاتی پیرامون عملکرد، قابلیت اطمینان و امنیت برطرف می کند. ترکیب این شیوه‌ها به تیم‌های چابک کمک می‌کند تا تصمیم‌های هوشمندانه‌تری در زمینه معماری اتخاذ کنند، آزمایش‌ها را انجام دهند، بیشتر داده محور شوند و اشتباهات را به سرعت تصحیح کنند.

روش‌های دیگری مانند ادغام تفکر طراحی با اسکرام، پیاده‌سازی جریان‌های ارزش، توسعه روش های مدیریت محصول، و اجرای برنامه ریزی مستمر به تیم های چابک کمک می کند تا با مشتریان، کاربران نهایی همکاری کنند، و ذینفعان کسب و کار 

تیم‌های چابک معمولاً ابزارهایی مانند نرم‌افزار Jira، Azure DevOps و Digital.ai را برای همکاری در بک‌لاگ‌های چابک و بردهای کانبان به کار می‌برند. این ابزارها به تیم‌های چابک کمک می‌کنند کار را اولویت‌بندی کنند، نیازمندی‌ها را بگیرند، داستان‌های کاربر را کامل کنند، گزارش‌های سوزاندن، و با استفاده از کنترل نسخه، CI/CD و ابزارهای دیگر، گردش کار را خودکار کنید. 

چارچوب‌ها و راهنماهای مفهومی مانند SAFe، Enterprise Scrum، LeSS (Scrum در مقیاس بزرگ)، مدل Spotify، و StarCIO Agile می‌توانند به هدایت اصول، استانداردها و شیوه‌های چابک در بسیاری از تیم‌های همکار کمک کنند.

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