خانه > Agile, Project Management, Scrum > چابک نخواهید بود اگر

چابک نخواهید بود اگر


https://sirasad.files.wordpress.com/2010/04/mr-bean-arrested.png?w=500همیشه در تغییر یک سری موارد از گذشته به جا می ماند  یعنی ما دوست داریم که به جا بماند . بدین صورت که ما می خواهیم فقط یک بخش کوچک متحول شود و نه کل اجزا . مثلا در همین چابک سازی خودمان ,  بسیاری از کسانی که تازه به این مقوله سوییچ می کنند دوست دارند فرض کنند که Agile یعنی Waterfall + تکرار .

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

برای اینکه ایرادات Waterfall پوشش داده شود RUP و Agile معرفی شده اند . ولی باز در هر دو روش ردپای Waterfall قابل مشاهده بود . همانطور که می دانید تکرار اساس Rup و Agile می باشد ولی تکراری که با قواعد اینها باشد و نه Waterfall . بدین صورت که ما تکرار را از Agile به ارث می بریم ولی روش کار درون تکرار باز همان Waterfall است . به شکل زیر توجه کنید :

https://sirasad.files.wordpress.com/2010/04/iterative-waterfall-model.png?w=400

اسم کاری که در بالا انجام می شود Agile نیست بلکه Waterfall + تکرار است . یعنی ما نیاز شناسی می کنیم بعد Design  و بعد کد نویسی  و آخر سر هم تست و این رویه ادامه خواهد داشت . در روش بالا عقب گردی وجود ندارد در حالی که Agile  کلا براساس تکرار و عقب گرد ها بنا نهاده شده است . Agile واقعی مانند شکل زیر می باشد :

https://sirasad.files.wordpress.com/2010/04/agile-model.png?w=383

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

پس ما با تعامل لازم با Product Owner خواهیم توانست یک پروژه کاملا چابک برپا نماییم و با رعایت اصول چابک خواهیم توانست محصولات موفق توسعه و ارائه دهیم .

به امید روزهای چابک در سازمان های چابک با افراد چابک

عکس ها از وبلاگ Agile consulting

یاشیاسیز

  1. هنوز دیدگاهی داده نشده است.
  1. No trackbacks yet.

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

%d وب‌نوشت‌نویس این را دوست دارند: