مشاهده خبر بازگشت به لیست اخبار

چهارمین اصل اجایل: نیازمندی های اجایل به سختی بسنده می کنند.

نوشته شده توسط: فروزان
در تاریخ:


تیم توسعه اجایل به صورت تدریجی به نیازمندی ها می رسد. نیازمندی های اجایل بصری هستند و به سختی بسنده می کنند. با حداقل نیازمندی ها برای توسعه بیشتر و آزمایش را با بازده مناسب ادامه می دهند. منطق برای این موضوع حکم می کند زمان صرف شده برای هر چیزی که بخشی از محصول نهایی نیست را به حداقل برسانیم.


برخی افراد توسعه اجایل را به معنی "هیچ فرآیندی وجود ندارد" اشتباه گرفته اند، آنها فکر می کنند تیم توسعه اجایل فقط همراه با ادامه دادن مسیر، کارها را پیش می برند، به عبارت دیگر JFD ! این رویکرد خیلی شبیه اجایل نیست اما Fragile است!


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


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


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


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


XP (eXtreme Programing) نیازمندی ها را به بخش های کوچکی به نام User Stories می شکند. این ها اساسا مشابه Use Case هستند اما سبک و ساده تر.


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


 یک روش رایج در میان تیم توسعه اجایل این است که نیازمندی ها را با استفاده از قضیه یا داستان کاربر بر روی یک کارت ارائه دهند، و با استفاده از سیستم T-card به داستان ها اجازه می دهند تا به راحتی به عنوان نماینده کسب و کار/کاربر در تنظیم اولویت پروژه حرکت کنند.


نیازمندی ها به منظور دستیابی به این شرایط به قطعات بسیارکوچک شکسته می شوند: مزیت داشتن این کار بر مستندات طولانی این است که بسیار بصری و محسوس است. شما می توانید در کنار سیستم T-card و پیشرفت بحث وایت برد، مسائل و اولویت ها، حضور داشته باشید.


بازه زمانی پروژه توسعه اجایل ثابت است، در حالی که ویژگی ها متغیر هستند. تغییر اولویت ها یا افزودن ویژگی های جدید به پروژه ضروری است. نماینده فیزیکی کسب و کار یا کاربر، باید قبل از افزودن کارت جدید مقدار قابل مقایسه ای از کار را حذف کنند.


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


در مقابل، تیم اجایل تغییرات را می پذیرد: در واقع انتظار آن را دارند. اما آنها با تثبیت بازه زمانی و ویژگی ها، تغییرات را مدیریت می کنند.


کارت ها می تواند بوسیله مستندات به طور مناسب مورد حمایت قرار گیرند اما همیشه اصل توسعه اجایل این است که حداقل میزان اطلاعات را سند سازی کنند و این به ویژگی ها اجازه می دهد تا توسعه یابند و به واحد های بسیار کوچکی شکسته شوند.


استفاد از عمل مدیریت اجایل Scrum ، نیازمندی ها (ویژگی ها یا داستان ها و هر زبانی که ترجیح می دهید استفاده کنید) به وظایف کمتر از 16 ساعت شکسته می شوند (دو روز کاری) و ترجیحا، کمتر از 8 ساعت، بنابراین پیشرفت را می توان به صورت روزانه اندازه گیری کرد.


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



هیچ دیدگاهی تاکنون برای این خبر ثبت نشده است.

اولین نفر باشید!
دیدگاه خود را ثبت کنید: