آیا تا به حال برایتان سوال شده که چطور از متدلوژی اجایل (سیستم مدیریت چابک) در گیت لب استفاده کنید؟ اگر از گیت لب استفاده میکنید ممکن است برایتان واضح نباشد که ویژگیهای آن چطور با مشخصههای اجایل کار خواهند کرد. در این مقاله این موضوع را برای شما توضیح داده ایم.
روش توسعه به صورت اجایل (Agile) یکی از مهم ترین متدولوژیهایی است که در دهه های اخیر به علم مهندسی نرم افزار اضافه شده است. هرچند که همه بر سر جزئیات این روش توافق ندارند اما در هر صورت تاثیر مثبتی که استفاده از آن بر تیمهای نرمافزاری داشته است قابل انکار نیست.
شباهت ویژگیهای گیت لب با سیستم مدیریت اجایل (Agile)
گیت لب نیز با طراحی منعطفی که دارد این قابلیت را داراست که با هر متدلوژی ای که شما در نظر دارید منطبق شود. در این مقاله ما یک نگاشت ساده از مشخصههای روش مدیریت چابک را که با ویژگیهای گیت لب به طور کامل منطبق هستند را توضیح داده و نشان میدهیم که چطور شرکتهای نرمافزاری، تیمهای موفق با عملکرد بسیار خوب را بوسیله گیت لب اداره میکنند.
نگاشت مشخصههای مدیریت نرم افزار اجایل به ویژگیهای گیتلب
مشخصههای روش اجایل | ویژگیهای گیتلب |
داستان مشتری | Issues |
وظایف (Tasks) | لیست تسکها |
اپیک (Epic) | اپیکها |
نقاط و حدسها | وزن |
بکلاگ محصول | لیست ایشوها و برچسبها |
اسپرینت (Sprint) | نقاط milestone |
چارت burndown | چارت burndown |
برد چابک | برد ایشوها |
یک تکرار چابک با استفاده از گیتلب
داستان کاربر – ایشوهای گیتلب
در روش چابک، به طور معمول با استفاده از داستان کاربر یک ویژگی واحد را بیان میکنیم که ارزش کسب و کار را برای کاربران ارائه میدهد. در گیتلب یک ایشو ساده در یک پروژه به این هدف کمک میکند.
تسکها – لیست تسکها در گیتلب
معمولا، داستان کاربر به وظایف مشخص و انفرادی تقسیم میشود. در گیت لب میتوانیم یک لیست وظایف در هر issue ایجاد کنیم تا این وظایف به طور مشخصتری معلوم باشند.
اپیکها – اپیکهای گیتلب
از جهات دیگر، برخی متخصصان روش چابک از یک انتزاع برای داستانهای کاربر (user story) استفاده میکنند که اغلب تحت عنوان epic شناخته میشوند که نشاندهنده جریانی بزرگتر و متشکل از چندین ویژگی است. در گیتلب یک اپیک شامل عنوان و شرحی است که از خیلی جهات شبیه یک issue است. اما به شما این اجازه را میدهد که چندین موضوع را به آن و به عنوان child ضمیمه کنید تا این سلسله مراتب را نشان دهد.
بک لاگ (Backlog) محصولات – لیست ایشوهای گیتلب و برچسبهای اولویت
صاحبان محصولات و یا کسب و کارها مختلف از استوریهای کاربران به عنوان ابزاری برای منعکس کردن نیازهای کسب و کار و مشتریان استفاده میکنند. این داستانها در بکلاگ محصولات ذخیره میشوند تا فوریت و نظم مورد نظر برای توسعه را ثبت کنند. مالک محصولات با ذینفعان ارتباط برقرار کرده و اولویتها از این طریق مشخص میشوند و به طور مداوم بک لاگ آپدیت میشود. در گیتلب لیستی از ایشوهای مختلف به صورت پویا ایجاد میشود که کاربران میتوانند برای بررسی و ردیابی بکلاگ خود آن را مشاهده کنند. برچسبها میتوانند برای ایشوها به صورت مجزا تولید شده و به آنها اختصاص داده شوند. سپس این امکان را به شما میدهد که لیست ایشوها را با برچسبهای متعدد فیلتر کنید. این اقدامات همگی به انعطافپذیری بیشتر نیز کمک میکند. برچسبهای اولویت را میتوان برای نظم بخشیدن به ایشوها نیز استفاده کرد.
اسپرینتها – مایلاستونهای گیتلب
هر اسپرینت یک دوره زمانی محدود را نشان میدهد که در آن کار بایستی تکمیل شود که ممکن است یک هفته، چند هفته و یا یک ماه و بیشتر طول بکشد. در طی این پروسه مالک محصول و تیم توسعه برای تصمیم گیری درباره کارهایی که در اسپرینت بعدی بایستی انجام شود جلسهای تشکیل میدهند.
ویژگی مایل استونهای گیت لب از این مسئله پشتیبانی میکنند: برای هر کدام از نقاط عطف (milestones) یک تاریخ شروع و یک تاریخ پایان اختصاص دهید تا دوره زمانی اسپرینت شما ثبت شود. سپس تیم شما ایشوهای مختلف برای آن اسپرینت را ثبت کرده و آنها را به مایلاستونهای مشخص تخصیص میدهد.
نقاط و تخمینها – وزن ایشوهای گیتلب
در جلسات، داستانهای کاربر مورد بحث قرار گرفته و سطح تلاش فنی لازم برای هر یک از آنها تخمینزده میشود. در گیتلب، ایشوها دارای ویژگی وزنی هستند که میتوانید از آن برای توصیف سطح تلاش فنی لازم استفاده کنید. در این جلسه (یا جلسات بعدی) داستانهای کاربر به نتایج فنی تجزیه میشوند و برنامههای فنی و معماری مستندسازی میشود. در گیتلب این اطلاعات را میتوان داخل هر ایشو مستندسازی کرد یا هنگام درخواست ترکیب (Merge) آنها را به توضیحات مرج اضافه کرد.
در طول هر اسپرینت، اعضای تیم توسعه یک سری استوری را برای کار روی آنها انتخاب میکنند. در گیتلب، ایشوها بین افراد مختلف توزیع میشوند. در نتیجه شما میتوانید خودتان را به هر ایشو تخصیص دهید تا مشخص شود که شما فردی هستید که در حال کار بر روی ایشو مورد نظر هستید. برای ایشوهایی که نیاز به همکاری بین اعضای مختلف را دارند میتوانید قبل از شروع ایشو، یک درخواست ترکیب link-to-issue ایجاد کنید که بیانگر شروع پروسه همکاری فنی است.
برد اجایل – برد ایشوهای گیتلب
در طول هر اسپرینت، ایشوها در مراحل مختلفی جا به جا میشوند. بعضی از این مراحل شامل: آماده برای توسعه (ready for dev)، در حال توسعه (In dev)، In QA، In review و Done نام دارند. معمولا اینها ستونهای برد در روش اجایل هستند. در گیتلب، برد ایشوها به شما این امکان را میدهد که مراحل مختلف یک پروژه را مشخص کنید و ایشوها را بین أنها جابجا کنید. تیم نرم افزار میتواند برد گیتلب را براساس مایلستون () تنظیم کرده و در جلسات روزانهی خود از نظر جریان کار، وضعیت اسپرینت را رصد کنند.
چارت burndown – چارت burndown گیتلب
تیم توسعه بایستی این امکان را داشته باشند که به صورت real-time از میزان پیشروی خود در برنامه با خبر باشند و میزان ریسک خود را همزمان با پیشرفت پروژه اندازه بگیرند. گیت لب از چارتهای burndown پشتیبانی میکند که به تیمها این امکان را میدهد که همزمان با پیشرفت کار آن را به صورت تصویرسازی شده ببینند.
در پایان اسپرینت، تیم توسعه ویژگیهای پروژه را به صورت دمو به سهامداران نشان میدهد. در گیتلب این پروسه با استفاده از یک سری Review apps سادهسازی شده است که حتی کد پروژه ای که هنوز به مرحله تولید نرسیده و در محیط تست قرار دارد بتواند به صورت دمو نشان داده شود. Review apps و ویژگیهای CI/Cd با استفاده از درخواستهای merge یکپارچه میشوند. همچنین از ابزارهای مشابه برای QA استفاده میشود تا کیفیت نرم افزار نیز حفظ شود. برای این اقدام نیز از تست اتومات توسط CI/Cd و یا تست دستی در محیط Review App استفاده میشود.
بازنگری و تجربیات تیم در پایان اسپرینت میتواند در یک wiki مستندسازی شود. تا بتوانیم اقدامات انجام شده و یا مواردی که در طول پروژه یاد گرفتهایم را در طول زمان دنبال کنیم. در طول بازنگری، تیم میتواند به صفحه مایلاستونها مراجعه کرده و چارت burndown و دیگر چارتهای کامل شده و آمارهای مربوط به هر اسپرینت را مرور کند.
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.