۳۰ آذر ۱۴۰۳

Techboy

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

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

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

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

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

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

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

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

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

کاربران

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

مالک محصول

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

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

Ruby کامپایلر خالص Ruby JIT را پیش‌نمایش می‌کند

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

ویدئوی مرتبط: روش شناسی چابک واقعا چگونه کار می کند

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

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

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

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

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

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

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

اسکرام و کانبان

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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