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

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

۰ 99

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

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

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

موفق باشید.

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

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

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

ارسال پاسخ

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

*

code

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

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

  • 5 افسانه Agile

    ۵ افسانه Agile

    بی شک برای استفاده از هر روش جدیدی دلایلی وجود دارد.  یکی از این دلایل می تواند برتری نقاط قوت روش جدید نسبت به روش فعلی باشد. اما آیا همیشه اینطور است؟ اگر شما به یکی از دلایل ذیل می خواهید به اجایل مهاجرت کنید باید بدانید که دچار افسانه زدگی Agile شده اید! این…

  • چگونه یک طراح وب خوب شویم؟

    چگونه یک طراح وب خوب شویم؟

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

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

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

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