آنچه در این آموزش قصد داریم مورد بررسی قرار دهیم، این است که به چه شکل می‌توان یک پروژه را به سبک اجایل پیش برد. به عبارت دیگر، خواهیم دید که به چه شکل می بایست نیازهای ذی نفع پروژه را دریافت کرده، آن‌ها را فازبندی کنیم و پس از تکمیل هر فاز، پروژه را جمع کرده و محصول نهایی که تحت عنوان Release (ریلیس) شناخته می‌شود را به بازار عرضه کنیم.
تیم هایی که برای توسعه ی نرم‌افزار از مدل اجایل استفاده می کنند، برنامه ی زمانبندی تحویل نرم‌افزار را به یکسری بازه های زمانی دو تا چهار هفته‌ای تقسیم‌بندی می‌کنند که تحت عنوان Iteration (ایتریشن) به معنی «تکرار» شناخته می شوند که در هر یک از این بازه ها، بخشی از پروژه که تکمیل شده و قابل استفاده است در اختیار مشتری قرار می‌گیرد (ایتریشن در مدل اسکرام تحت عنوان Sprint شناخته می شود.)
| نکته |
توجه داشته باشیم که هر چه این بازه های زمانی کوتاه‌تر باشند، بهتر بوده و در نهایت منجر به رضایتمندی بیشتر مشتری خواهد شد. |
این برنامه ی کاری می بایست به صورت کاملاً شفاف تنظیم شده و در اختیار تک تک اعضای تیم قرار گیرد و هر کجا که نیاز بود تا دستخوش تغییر شود، این تغییرات می بایست با آغوش باز پذیرفته شوند چرا که در نهایت منجر به بهبود نرم‌افزار نهایی خواهند شد. برنامه‌ریزی یک پروژه ی اجایل، معمولاً در سه مرحله صورت می‌گیرد که عبارتند از:
- برنامه‌ریزی ریلیس: برنامه‌ریزی ریلیس دربرگیرنده ی زمانبدنی عرضه ی نهایی محصول در هر ریلیس -یا نسخه- از نرم‌افزار است که می بایست در بدو شروع پروژه مشخص گردد.
- برنامه‌ریزی ایتریشن: تک تک اعضای تیم در ابتدای هر ایتریشن یا اسپرینت دور هم جمع می‌شوند تا در مورد کارهایی که در آن فاز می بایست تکمیل شوند صحبت کنند.
- برنامه‌ریزی روزانه: تیم های توسعه ی نرم افزاری هر روز کاری خود را با جلسات سرپایی شروع می کنند. در این جلسات که در آن نشستن مجاز نیست، اعضای تیم ظرف مدت 5 الی 15 دقیقه اهداف کاری آن روز و همچنین نیازمندی هایش را مشخص کرده و در مورد کارهایی که روز پیش به انجام رسانده اند صحبت می کنند.
یوزر استوری
وقتی که نیاز به توسعه ی یک نرم‌افزار احساس شود، در مدل اجایل -برخلاف روش‌های سنتی- توصیفی کوتاه از کل پروژه نوشته شده که تحت عنوان User Story شناخته می شود. به عبارت دیگر، یوزر استوری توصیفی کوتاه از نیازمندی های پروژه است که حداقل می بایست دربرگیرنده ی عنوان، نوع کاربر، نیازهای کاربر و در نهایت ارزش افزوده ای که برای کاربر ایجاد می‌گردد باشد.
علاوه بر این، یوزر استوری می بایست حاوی یکسری گام های اعتبارسنجی نیز باشد که در این گام ها سنجیده می‌شود که آیا واقعاً پس از استفاده ی نرم‌افزار توسط کاربر، ارزش افزوده ای برایش ایجاد می‌گردد و آیا مشکل وی حل خواهد شد یا خیر! یوزر استوری ها می‌توانند حاوی یکسری اطلاعات دیگر نیز باشند. مثلاً می‌توان از یک شناسه برای متمایز سازی یوزر استوری های مختلف استفاده کرد و یا تألیف کننده ی یوزر استوری را هم در آن مشخص کرد.
| نکته |
برای یوزر استوری هایی که خیلی بزرگ و پیچیده هستند که نمی‌توان آن‌ها را در قالب یک ایتریشن یا اسپرینت عملی ساخت، برخی تیم های اجایل از مفهومی تحت عنوان Epics استفاده می‌کنند که یک یورز استوری جامع است که دربرگیرنده ی چندین یوزر استوری زیرشاخه ی مرتبط با یکدیگر است. |
| به خاطر داشته باشید |
| تیم های توسعه ی نرم افزاری به سبک اجایل ملزم به استفاده از یوزر استوری نیستند اما از آنجا که این تکه کاغذها، بسیاری خلاصه اما در عین حال مفید هستند، بسیاری از تیم های توسعه ی اجایل تمایل به استفاده از آن‌ها نشان داده اند. به هر حال، یوزر استوری تنها راه مشخص سازی یک پروژه ی نرم افزاری نیست و شما می‌توانید در قالب هر ساختاری که تمایل داشته باشید، اقدام به مشخص سازی نیازهای یک پروژه نمایید. |
برآورد پروژه
مدیر پروژه این وظیفه را دارا است تا ببیند که آیا کارهایی که قرار است در هر فاز یا ایتریشن انجام شود با زمان در نظر گرفته شده همخوانی دارد یا خیر که این کار از طریق مفهومی تحت عنوان Point (پوینت) به معنی «نقطه» صورت می گیرد. به عبارت دیگر، پوینت رویکردی برای برآورد پروژه از بعد زمان، پیچیدگی و اندازه است. کارهای ساده‌ای که در زمان کوتاهی به انجام می‌رسند پوینتی معادل با 1 می‌گیرند اما هرچه کارها پیچیده‌تر و زمانبرتر می شوند، می بایست پوینت های بزرگ‌تری -مثلا ۳ یا ۴- به آن‌ها اختصاص داد.
برای مشخص شدن بیشتر و بهتر مفهوم پوینت ها در مدل اجایل، می‌توان سایز تی شرت هایی که می پوشیم را در نظر بگیریم. برای تی شرت ها اندازه هایی همچون Small, Medium, Large و Extra-large در نظر گرفته می‌شود و می‌بینیم که این واحد اندازه‌گیری اگرچه که خیلی دقیق نیست، اما به عنوان یک واحد اندازه‌گیری مرسوم برای تی شرت ها درآمده و هم از طرف شرکت های سازنده و هم از طرف مصرف کنندگان مورد تأیید قرار گرفته است. در مدل اجایل هم دقیقاً قضیه ی پوینت ها به همین صورت است. اصلاً نیازی نیست تا دقیقاً مشخص کنیم که پوینت 1 معادل با چقدر حجم کار، سادگی و پیچیدگی است بلکه پوینت ها را می‌توان کاملاً توافقی با مد نظر قرار دادن نظرات تک تک اعضای تیم مشخص کرد.
سرعت اجرای پروژه
در پایان هر ایتریشن، اعضای تیم می بایست کارهای انجام شده را مشخص کنند و ببینند که کارهای انجام شده چند پوینتی بوده اند. پوینت های کارهای انجام شده را جمع کرده و نتیجه ی نهایی معادل است با سرعت انجام پروژه توسط آن تیم. به عبارت دیگر، اگر تیمی در ایتریشن اول اقدام به تکمیل یورز استوری هایی با 15 امتیاز و در ایتریشن دوم اقدام به تکمیل یورز استوری هایی با 25 امتیاز کرده است، سرعت انجام پروژه معادل است با جمع امتیازها (40) تقسیم بر تعداد ایتریشن ها (2) که می‌شود 20. با مشخص شدن سرعت انجام پروژه توسط اعضای تیم، به مراتب راحت‌تر می‌توان سیاست گذاری ادامه ی پروژه را انجام داد و فازهای پروژه را به گونه‌ای تنظیم کرد که اعضای تیم از ضرب العجل های مشخص شده عقب نمانند.
تست پروژه
در مدل اجایل، تست در تک تک فازهای پروژه صورت می گیرد. این تست گاهی توسط یک فرد خارجی و گاهی هم توسط خود تیم توسعه صورت می پذیرد. خیلی از برنامه نویسان علاقه‌ای به تست کردن کدهای خود ندارند اما این در حالی است که در مدل اجایل، مجبور به انجام این کار هستند. به طور خلاصه، تیم های اجایل از دو روش مختلف برای تست پروژه های خود استفاده می‌کنند که عبارتند از:
- توسعه ی نرم‌افزار تست-محور یا TDD
- ابزارهای تست پروژه یا Unit Test
جالب است بدانید که وقتی که این دو روش تست پروژه در کنار یکدیگر مورد استفاده قرار گیرند، بهترین نتیجه ی ممکن به دست خواهد آمد که متضمن Bug-free بودن پروژه خواهد بود یا حداقل احتمال وجود باگ را به مراتب کاهش می دهد. در روش TDD که مخفف واژگان Test-Driven Development است، توسعه دهنده پیش از آن که شروع به کدنویسی پروژه ی خود کند، ابتدا می بایست یک برنامه ی کوچک تست کننده بنویسد که وظیفه ی این برنامه آن است که برنامه‌ای که توسعه دهنده قرار است در آینده بنویسد را تست کند. پس از نوشتن تست، توسعه دهنده شروع به نوشتن سورس کد اصلی برنامه می‌کند که می بایست حتماً از سد آن تست عبور کند تا بتوان مهر تایید روی آن زد.
| به خاطر داشته باشید |
| در بسیاری از شرکت های برنامه نویسی ایران، مدل TDD به هیچ وجه مورد استفاده قرار نمی‌گیرد چرا که این مدل توسعه ی نرم‌افزار، مدلی هزینه بر تلقی می‌گردد که می‌شود گفت این مدیران شرکت های برنامه نویسی تا حدودی هم باتوجه به فرهنگ و شرایط کاری کشورمان ایران حق دارند که چنین دیدگاهی داشته باشند. |
زمانی که یک توسعه‌دهنده تست کوچکی روی کدهایی که نوشته است اعمال می کند، این فرایند اصطلاحاً Unit Test گفته می شود. تیم های اجایل یونیت تست های زیادی می‌نویسند و آن‌ها را بارها و بارها اجرا می‌کنند تا از صحت اجرای کدهای اطمینان حاصل کنند. این روش دیباگ کردن به توسعه دهندگان کمک می‌کند تا پیش از آن که باگ های کوچک به معضلات بزرگی مبدل شوند، آن‌ها را یافته و دیباگ کنند.
دیپلویمت نرم‌افزار
پیش از Deployment (دیپلویمت) به معنی «استقرار» یا بهتر بگوییم انتشار نرم افزار، می بایست تغییرات مورد نیاز در سورس کد، فایل‌های کانفیگ، تغییر اسکمای دیتابیس (منظور از Schema ساختار جداول دیتابیس است) و … اعمال شده و مجدد پروژه را تست کرد و پس از آن که اطمینان حاصل کردیم که همه چیز به خوبی کار می کند، می بایست اقدام به دیپلویمت نرم‌افزار کنیم.
ارائه دستاوردهای انجام شده
Iteration Review به فرایندی گفته می‌شود که بر آن اساس جلسه‌ای برگزار شده و در آن یوزر استوری هایی که تیم توسعه ی نرم افزاری تکمیل کرده است مرور شده و دستاوردها ارائه خواهند شد. در این جلسه کلیه ی اعضای تیم می‌توانند حضور داشته باشد و هر کسی که در ارتباط با پروژه صحبتی داشت، می‌تواند در حضور جمع نقطه نظراتش را بیان کند.
در این جلسه، می بایست تا حد ممکن بازخوردها را یادداشت کرده و در صورت نیاز، این احتمال وجود دارد تا یوزر استوری های جدید ایجاد شوند تا کمی و کاستی های پروژه را پوشش دهند. این یوزر استوری های جدید می‌توانند قابلیت‌های جدیدی باشند و یا در ارتباط با اعمال تغییراتی در قابلیت‌های قبلی باشند. سپس این یوزر استوری های جدید می بایست اولویت بندی شده و بر اساس درجه ی اهمیت، در دستور کار قرار گیرند.