در مورد مدیریت پروژه ی به روش Agile با متدلوژی های مختلف مانند Scrum یا RUP, XP و … مطالب کلی زیادی وجود دارد اما در این نوشته قصد دارم نکات جزئی تر و تخصصی تر که کمتر در مورد آن بحث شده است همچنین تجربیات شخصی ای که داشته ام را بنویسم تا برای کسانی که آشنایی اولیه به این روش اجرای پروژه های نرم افزاری دارند مفیدتر باشد.

بصورت اجمالی agile را بصورت زیر تعریف می کنم:

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

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

‌أ. کدام ویژگی ارزش کسب و کار بیشتری را دارد.

‌ب. کدام ویژگی ریسک بیشتری را کاهش می دهد.

تمام اعضای تیم باید دائما در حال رویاپردازی/نگرانی باشند، رویاپردازی برای کسب و کار بهتر (الف) و نگرانی بابت ریسکها (ب) همچنین هم از اعضای تیم و هم از مشتری می بایست فیدبک گرفته شود.
در مواجه با ریسک ها سه روش موجود است:

‌أ. از بین بردن ریسک.

‌ب. منتقل کردن ریسک به ریسک دیگر.

‌ج. کاهش اثر ریسک.

مراحل مقابله با ریسک ها به این صورت است:

‌أ. آنالیز ریسک

‌ب. ارزیابی ریسک

‌ج. مهیا کردن نحوه ی مقابله با آن

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

Agile برای همه مناسب نیست و برای هر پروژه ای هم مناسب نیست، افرادی میتوانند به روش Agile کار کنند که روحیه ی فردگرا نداشته باشند و روحیه ی تیم گرا داشته باشند، وقتی کدی می نویسند احساس مالکیت شخصی روی آن نکنند، کد را برای تیم بدانند و اگر کسی آن را تغییر داد احساس بدی پیدا نکنند. تمام افراد تیم باید خود مدیر و خود منضبط و خود سازمان یافته باشند، همه باید پروژه را از خود بدانند و به مدیر پروژه به عنوان رهبر نگاه کنند نه رئیس، همچنین پروژه هایی مناسب روش Agile است که نتیجه و نهایت کار معلوم نباشد و با محصولی از پیش طراحی شده و ساخته شده سروکار نداشته باشیم. برای این پروژه هایی که اول و آخر آن 100% معلوم است همان مدیریت پروژه ی معمولی و سنتی کافیست، Agile مخصوصا برای کار نرم افزار مناسبت است که هر روز ممکن است نتیجهو محصول نهایی و حتی استراتژی شرکت تغییر بنیادین کند.
در Agile رهبری و هدایت توسط سرپرست تیم انجام می شود نه مدیریت و سازماندهی سنتی، هر تیم برای خودش تصمیم میگیرد و اطلاعات جزئیات سیستم به مقامهای بالا نخواهد رسید.
برنامه ریزی هر مرحلهIteration در جلسه ی تیمی با حضور همه ی اعضای تیم انجام می شود و با توجه به روند پروژه و مراحل قبل برنامه ریزی برای این مرحله ی پیش رو در جلسه انجام می شود. مراحل برنامه ریزی به این صورت است:

‌أ. وضعیت فعلی چشم انداز کجاست؟

‌ب. نقاط کلیدی پروژه کجاست؟

‌ج. سنگ نشان ها (milestone)برای هر مرحله چیست؟

‌د. محیط اجرای agile چگونه است؟

برای مشخص شدن وضعیت چشم انداز باید به هردفعه این سوالات جواب داد:

‌أ. چه کسی مشکل دارد؟

‌ب. مشکل چیست؟

‌ج. سود منفعت پروژه کجاست و چرا نیاز داریم این پروژه انجام شود؟

‌د. چگونه می فهمیم موفق شدیم؟

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

‌أ. طراحی عملکرد: مثلا سرعت سیستم باید چقدر باشد و از کجا بفهمیم سرعت افزایش پیدا کرده است.

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

دیتابیس

دیتابیس بصورت عمده ای و یک جا اول پروژه ساخته نمیشه، بلکه بصورت تدریجی و افزایشی طی انجام پروژه ساخته میشه. هنگام انجام User-stories ها با توجه به نیاز دیتابیس طراحی یا ویرایش می شود.
بهینه سازی و نرمالایز کردن دیتابیس هم به تدریج انجام می شود، دلیل تدریجی بودن این کار این است که ابتدای پروژه اطلاعات کافی نداریم.
در صورتی که حین انجام پروژه به این نتیجه رسیدیم که جدولی که طراحی کرده بودیم باید حذف شود آن را نشانه گذاری میکنیم یا اول اسم آن ex می گذاریم، شاید بعدا نیاز شد و یا استراتژی تغییر کرد.
بهتر است در صورت وجود نیروی انسانی کافی، یک مدیر برای دیتابیس قرار دهیم تا تغییرات آن را ثبت و مستند سازی کند.
موقع برنامه ریزی همه ی اعضای تیم باید شرکت داشته باشند و پروژه را از خودشان بدانند
مدت زمان جلسه باید 1/2 روز باشد و تا آنجا که می شود کامل ولی کوتاه باشد و نباید خیلی کشش داد.
همه ی چیزهایی که تیم در مرحله ای که گذشت با آن برخورد کرد و یاد گرفت باید ثبت و بایگانی بشود.
به ترتیب اولویت user-stories ها (کارهایی که می بایست انجام شود) را بر اساس سرعت مرحله قبل لیست میکنیم، تعداد آنها را طوری انتخاب میکنیم که به همه ی آنها کار برسد.
زمان آماده سازی یا sparks time به مدت زمانی گفته می شود که برای انجام یک کاری لازم است تحقیق و آزمایش و جستجو انجام شود، این مدت زمان باید هنگام تخمین مهلت انجام کارها در نظر گرفته شود.
وقتی می خواهیم stories ها را به افراد تیم اختصاص دهیم اول میگذاریم خود افراد داوطلبانه هر کدام که دوست داشتند را با توجه به زمانی که دارند انتخاب کنند بعد هر کاری که موند تقسیم بشود بین همه.
اصلا اجتیاج به برنامه های مدیریت پروژه در روش Agile نیست، هر کاری برنامه زمانی و مسئول مشخص شده ی خودش را دارد و مرحله به مرحله برای آن تصمیم گیری می شود. حتی نمودار گانت هم لازم نیست، فقط در یک جا این اطلاعات ثبت و ذخیره بشود، مثلا یک فایل اکسل
مرحله ی صفر: مرحله ی آماده سازی تیم می باشد که باید قبل از شروع مرحله ی 1 و انجام کارهای پروژه به آنها پرداخت، مقلا آماده سازی اتاق وایت برد، میزها، نرم افزارهای لازم مانند git , SVN و …
باید نرم افزارهای لازم و نخوه ی تست و کانفیگ و کامپایل در این مرحله مشخص شده باشد و بعد به مراحل دیگر رفت. تخته وایت برد و کاغذهای لازم برای یادداشت، نخوه ی ارتباط اعضای تیم و تاریخ های جلسه و هر چیزی که مربوط به گروه باشد باید در اختیار همه قرار گیرد.

برنامه ریزی برای مرحله بعد

برنامه نویسی گروهی
همانطور که گفته شد هیچ کسی در تیم مالکیت انحصاری کد نوشته شده ی خود را ندارد و هر کسی از تیم می تواند آن را برای بهتر شدن ویرایش کند. در برنامه نویسی گروهی می توان هر کسی یک قسمت از کدنویسی را به عهده بگیرد و با نرم افزارهای مدیریت نرم افزار مانند SVN و Git با هم روی سورس کار کنند، یا دو نفر با یک کامپیوتر کار کنند. هر کدام از این دو نفر می توانند کیبورد را در اختیار بگیرد و کد نویسی کند و دیگری همراه با اون فکر کند که چه راهی بهتر است و کدام متود سریعتر و بهتر جواب می دهد، هرگز فکر نکنید این روش وقت تلف کردن است یا دو نفر موازی یک کار انجام می دهند، بلکه کیفیت و سرعت کد نویسی همچنین درصد خطا بسیار پایین می آیند، در این روش 1+1>2 می باشد. باید توجه داشت که بهتر است بطور مداوم جای کدنویس (راننده) با نفر دیگر عوض شود.
کمک برنامه نویس وظیفه دارد هر خطی که نوشته می شود را در ذهنش چک کند که درست باشد و در مسیر متودهای گذشته باشد. هر دو نفر می بایست اخلاق دسته جمعی و کار گروهی را رعایت کنند، جنسیت دو برنامه نویس نباید خللی در کار وارد کند و تیم به حاشیه برود، هر دو برنامه نویس باید سخت کوش باشند و مسئولیت و وظیفه محول شده را از خودشان بدانند.
به هیچ وجه جَو سرزنش برای وجود باگ در تیم ایجاد نکنید، تا هر کسی که شک در برنامه ای که نوشته بود پیدا کرد آن را به راحتی بیان کند نه این که اصطلاحا آن را به زیر قالی بفرستد.
اگر شک در برنامه ایجاد شده احتیاج به زمان زیادی برای اصلاح داشتIteration تمام شده و آدرس و محل مشکل را برای مرحله ی بعد یادداشت می کنیم. (به هیچ وجه وجود مشکل در کد نباید باعث به تعویق افتادن اتمام مرحله شود).

تست برنامه
تست کد نوشته شده می بایست همزمان با کدنویسی انجام شود، تست صفر و یک می باشد یا 100% درست می باشد که به مرحله بعد می رویم یا مردود می شود که تا درست نشده نباید به سراغ کد دیگر رفت.
در برنامه نویسی چابک ابتدا مشخص می شود که قرار است چه چیزی تست شود و با چه کیفیتی می بایست نتیجه دهد سپس برنامه نویسی بر اساس این اصطلاحا Test case ها صورت میگیرد. این موارد تست از روی user stories هایی که در ابتدای شروع مرحله نوشته بودیم نوشته می شود.
با استفاده از این روش سرعت کار فوق العاده بالا می رود چون از شروع کار برنامه نویس کاملا می داند چه چیزی قرار است در نهایت تست شود و برنامه را بر آن اساس می نویسد و از دوباره کاری و نوشتن برنامه های بی مصرف جلوگیری می شود. اگر Test Case خوبی نوشته نشود وظیفه ی برنامه نویس پیچیده می شود و نباید انتظار برنامه خوبی از او در پایان داشت. بعد از هر اصلاح می بایست کل سیستم تست شود نه فقط آن قسمت، چون ممکن است در حین اصلاح بعضی توابع درست کار نکنند و تغییراتی در آنها ایجاد شود.

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

خروجی دریافتی نباید شبیه و نزدیک به اطلاعات مورد نیاز و مورد انتظار باشد، می بایست دقیقا چیزی باشد که در User stories ها مشخص کردیم.
در صورتی که یک تست چندین بار می بایست انجام شود، بهتر است یک اسکریپت مخصوص اجرای عملیات تست و مهیا کردن ورودی ها بنویسیم به نحوی که در نهایت با فشردن یک کلید بطور اتوماتیک تست انجام شود. بهتر است بصورت شفاف نتایج خطا یا درستی را نشان دهد، هیچ پردازش اطلاعات دوباره ای رو نتایج نباید انجام شود، و برنامه نویس بلافاصله می بایست بفهمد اشکال از کجاست:

کد
شرایط ورودی
نتایج خواسته شده
نوع تست

کد باید قابل تقسیم باشد طوری که هر باز که چیزی تغییر کرد لازم نباشد همه ی سیستم اجرا شود و فقط بخش مربوطه دائما تست شود، و در نهایت بعد از دریافت نتایج دلخواه همه ی سیستم یکبار تست شود.

منبع: وبلاگ احمد نعمتی