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

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

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

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

http://blog.irscrum.com/wp-content/uploads/2010/04/iterative-waterfall-model.png?w=400

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

http://blog.irscrum.com/wp-content/uploads/2010/04/agile-model.png?w=383

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

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

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

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

یاشیاسیز

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

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

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

پاسخ دهید

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