بررسی Agile بصورت جزئی تر (قسمت دوم)

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

3638

3) User stories یعنی کارهایی که می بایست تا مرحله ی بعد انجام داد ، ابتدا می بایست همه ی کارهایی که باید انجام شود پشت سر هم نوشته شود ، سپس برای زمان انجام دادن آن تخمین زده شود و بعد اولویت بندی شود . این وظایف باید تا حدی خرد شده باشند که بتوان در مدت زمان یک مرحله آنها را انجام داد . در نوشتن عنوان کارها می بایست از کلمات مربوط به کسب و کار صحبت کرد ، کلماتی که امکانات و قابلیت های ریز سیستم هستند ، نه از کلمات تخصصی و آی تی (توجه کنید تمام وظایف برای هر شخص غیر متخصصی مانند رئیسان شرکت باید کاملا گویا باشد)
4) بعد از نوشتن لیست کارها باید درست بودن و بجا بودن آنها را بیازمایید ، آیا این کارها به اندازه کافی خوب هستند؟ آیا اهداف کاملا در آنها آمده است ؟ آیا اسمی که برای آن گذاشتیم به خوبی معنا دار هست؟ آیا کارها از هم مستقل هستند؟ (مستقل بودن به این معنی که بتوان آنها را بدون نیاز به هم انجام داد نه اینکه به هم مربوط نباشند) آیا کارها بعد از انجام قابل تست هستند؟
5) سپس می بایست زمان و هزینه ی انجام کارها تخمین زده شود ، این کار توسط خود اعضای تیم انجام می شود ، از تیم می بایست پرسیده شود چرا زمان این کار اینقدر کم یا زیاد است .
6) اولویت بندی کارها گام بعدی است ، 4 حالت برای اولویت کارها داریم 1)حتما باید انجام شود 2) خوبه که باشه 3) اختیاری 4)فراموشش کن!
7) هنگام اولولیت بندی می بایست به ریسکها توجه کرد ، هر کدام که ریسک پرخطرتری داشت و ضروری تر بود اولویت بیشتری دارد . همچنین باید توجه کرد چه چیزهای دیگری به این User stories مربوط است ، شاید آنها مهم باشند و این کار هم مهم شود .
8) قابلیت های سیستم از ترکیب چند User stories با هم تشکیل می شوند ، مثلا سیستم سفارش مشتری یک قابلیت نرم افزار است که از چندین User stories کوچکتر مثل دریافت اطلاعات و پرداخت آنلاین و ایمیل کردن اطلاعات تشکیل شده است .
9) مدت زمان هر مرحله Iteration بین 1 تا 4 هفته است . 1 هفته بسیار مدیریت پذیرتر ، راحتتر و دقیق تر است اما کارهای زیادی را نمیتوان در مدت کم انجام داد . بعد از اتمام مدت زمان، Iteration تمام می شود و به خاطر انجام نشدن بعضی کارها ، زمان جلسه به عقب نمی افتد .
10) هر مرحله باید 100% کامل انجام شود ، اگر کاری قابل انجام نیست یا باید با اضافه کاری آن را انجام داد ، یا چند روز قبل از اتمام مرحله آن را از لیست حذف کنید .
11) هر مرحله یک قابلیت از نرم افزار نیست ، در هر مرحله ، می بایست آن بخش طراحی شده کاملا قابل اجرا و تست باشد .
12) پس از پایان هر مرحله لزوما تست توسط مشتری انجام نمی شود . ممکن است بعد از چند مرحله برای تست به مشتری فرستاده شود ، تعداد این مراحل را کسب و کار مشخص می کند .
13) کسب و کار مشخص می کند : هر مرحله چه کارهایی بر اساس اولولیت قرار است انجام شود . چه کارهایی باید حذف و اضافه بشوند و چه زمانی اجرا و تست می بایست انجام شود .
14) هیج وقت وسط یک مرحله Iteration نمی توان به کل برنامه را عوض کرد و فهمید برنامه ریزی غلط بوده ، برنامه ریزی باید اینقدر قوی و حساب شده باشد که هیچ خللی در اجرای آن بوجود نیاید ، هر تغییری باید بعد از اتمام Iteration و برای مرحله ی بعد صورت بگیرد . (به نظر خودم اگر هر روز بتوان جهت و برنامه را تغییر داد جلسات و مراحل سبک و بی ارزش شمرده خواهد شد و تصمیمات دائما عوض شده و اعضای تیم اعتماد خود را به سرانجام پروژه از دست خواهند داد )
15) از دید مدیر هر مرحله متعلق به خود اعضای تیم است که زمانهای انجام پروژه را چگونه تنظیم کند و مدیر نباید وارد جزئیات چگونگی اجرای هر کار بشود . مسئولیت تحویل کارهایی که خود اعضای تیم در جلسه متقبل شده اند با خودشان است .
16) اگر تیم زمان اضافه آورد آن زمان متعلق به خودش نیست و باید مدیر در مورد استفاده از آن تصمیم بگیرد .
17) در هنگام تخمین زمان کارها ، از سرعت انجام کارها در مرحله قبل بهتر است استفاده شود ، چون موثق ترین و واقعی ترین تخمین زمان ، سرعت مرحله ی قبل است .

 


پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *