Some-Thoughts-On-Failure
مدیریت پروژه نرم افزاری, مقاله

چک لیست شکست در RUP

۰ 119

این مقاله در وبلاگ Jeff Sutherland در سال ۲۰۰۲ به نقل از  کریج لارمن نوشته شده که خوندنش خالی از لطف نیست. این پست در تکمیل پست قبلیم هست تا بعضی از دوستان بدونن که تا چه حد RUP رو اشتباه فهمیدن و اشتباه اجرا میکنن.

اگر شما هم مثل ۱۱ مورد زیر در مورد RUP فکر می کنید حتماً باید آگاهیتون رو درباره RUP بیشتر کنید:

  • وقتی فکر می کنیم  inception=requirements و elaboration=design و construction=implementation
  • وقتی فکر می کنیم هدف از elaboration اینه که مدل ها باید بصورت کامل و با دقت تعریف بشن و لزوماً فقط همین مدل ها هستن که در فاز construction تبدیل به کد خواهند شد.
  • وقتی فکر می کنیم در فاز elaboration فقط پروتوتایپ ها باید ساخته بشن. در واقع هسته کیفی المان های مهم معماری باید در این فاز تبیین بشن.
  • وقتی سعی می کنیم اغلب نیازمندی ها قبل از شروع مرحله طراحی یا پیاده سازی تعریف بشن.
  • وقتی سعی می کنیم اغلب امور مربوط به طراحی رو قبل از شروع پیاده سازی تمام کنیم.
  • وقتی قبل از شروع کدنویسی زمان زیادی رو صرف تکمیل نیازمندی ها و امور طراحی می کنیم.
  • وقتی فکر می کنیم مدت مناسب هر iteration یا تکرار باید بر حسب ماه باشه نه بر حسب هفته.
  • وقتی فکر می کنیم در مرحله رسم نمودارهای UML و انجام فعالیت های مربوط به طراحی، زمان زیادی باید صرف شه تا حتماً پیش نویس کدها به درستی و بصورت کامل آماده شه تا در مرحله کدنویسی این خروجی ها به سادگی به کدهای اصلی تبدیل شن.
  • وقتی سعی می کنیم در ابتدای کار، کل پروژه رو از آغاز تا پایان برنامه ریزی کنیم بطوریکه جزئیات و رویدادهای هر تکرار از همون ابتدا پیش بینی بشه.
  • وقتی سازمان از شما میخواد قبل از ورود به فاز elaboration، برنامه قابل قبول و پیش بینی های اصلی پروژه رو آماده کنید.
  • وقتی سازمان شما فکر میکنه پذیرفتن RUP به این معنی هست که خیلی از فعالیت های اختیاری رو باید بطور کامل انجام بدیم و در هر مرحله باید داکیومنت کاملی رو تولید کنیم و همچنین فکر میکنه تجربه موفق در RUP مثل یک فرآیند معمولی میمونه که لزوماً با گذروندن خیلی از مراحل از پیش تعیین شده محقق میشه.

موفق باشید.

Share

در باره نویسنده / 

حمیدرضا متقیان

مدیر محصول نرم افزار. علاقه مند به دنیای وب و ارزش آفرینی در کسب و کار.

ارسال پاسخ

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

نوشته های تصادفی

  • یوزر اینترفیس به سبک اجایل

    یوزر اینترفیس(رابط کاربری) به سبک اجایل #۳

    و اما قسمت آخر؛ در دو پست قبلی کلیاتی درباره UI Development مطرح شد. در این قسمت بصورت کاربردی تر به این موضوع خواهم پرداخت.  همونطور که می دونید Iterative(تکرارشونده) و Incremental(تدریجی)  بودن توسعه، دو اصل حیاتی در بطن Agile هستن. بعضی ها فکر می کنن که این دو مورد فقط باید در توسعه Back-End…

  • 24 تله ی رایج در اسکرام

    ۲۴ تله ی رایج در اسکرام (بخش دوم – آخر)

    با فرضیات پیش رفتن. اغلب اعضای تیم موفق به سوال از Product Owner در مورد جزئیاتی که در حال انجامش هستند نمی شوند و یکی از اعضای تیم مشکلات رو حل می کند در حالیکه که این فرد درباره محدودیت های محصول اطلاعات کاملی نداره و با فرضیات خودش تصمیم گیری می کنه. ارتباط و…

پربازدید ترین ها

  • بندهای حیاتی یک قرارداد تولید نرم افزار

    بندهای حیاتی یک قرارداد تولید نرم افزار

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

  • بایدها و نبایدها در ارائه پروپوزال

    بایدها و نبایدها در ارائه پروپوزال

    در اسفند ۸۸ در وب سایت بزرگ برنامه نویس به موجب سوال یکی از دوستان در مورد “شیوه ارائه طرح پیشنهادی نرم افزار”  توضیحاتی هر چند مجمل دادم که خوندنش خالی از لطف نیست: Proposal رو باید بر اساس RFP یا Request For Proposal ای که از مشتری میگیرین تهیه کنید. RFP از اهمیت زیادی…

  • the-internet-of-things

    آینده در دستان اینترنت اشیاء (IoT)

    Internet Of Things تحولی در آینده اینترنت است که مسلماً کسب و کار نرم افزار رو بسیار پر رونق تر و در عین حال فراگیرتر می کنه.  فرض کنید به خرید رفتید و خیلی راحت از یخچال خونتون استعلام میکنید که چه چیزهایی رو باید خریداری کنید؛ نیم ساعت قبل از اومدنتون میتونید سیستم تهویه…

عضویت در خبرنامه

بایگانی