- ارسال ها
- 3
- لایک ها
- 2
- امتیاز
- 0
تویوتا سالها پیش نوآوری جالبی در زمینه تولید خودرو به دنیا معرفی کرد ،که به سیستم تولید Just in Time شهرت یافت. بعدها دانشمندان مهندسی نرم افزار آن را توسعه دادند و این متد کنبن نام گرفت.
اگرچه پروسه ی تولید نرم افزار علاوه بر پیچیدگی های خاص خود، نیاز به خلاقیت بیشتری نسبت به تولید خودرو دارد، اما ساختار اصلی این متد، همان است که تویوتا تعریف کرده بود و به کمک آن می توانید پروسه ی تولید نرم افزار را تا حد ممکن بهینه نمایید. در متد کنبن، پروسه ی تولید نرم افزار را به یک تونل استوانه ای تشبیه کرده اند که ورودی آن درخواست های جدید مشتریان برای افزودن ویژگی های جدید و خروجی اش نرم افزار برنامه نویسی شده می باشد. بنابراین در حالت کلی این شیوه از سه مرحله تشکیل گردیده:
1. آنالیز کردن نیازها
2. کدنویسی و توسعه ی نرم افزار
3. تست و خطایابی آن
مشکل مخفی کار تیمی یا The Bottleneck Effect چیست؟
کارشناسان، ایراد مخفی بزرگی به نام تنگنا را در تیم های تولید نرم افزار شناسایی کرده اند که باعث کند شدن پروسه ی تولید نرم افزار می شود ولی متاسفانه اغلب، از دید مدیران پروژه مخفی می ماند. بگذارید مشکل را با یک مثال برایتان توضیح دهم. فرض کنید در شرکتی سه تیم فعالیت می کنند:
· تیم آنالیز
· تیم توسعه
· تیم تست
اگر تیم آنالیز، در هفته، صرفا قدرت تحلیل پنج کلاس یا ویژگی نرم افزار را داشته باشد، در حالی که تیم توسعه، امکان برنامه نویسی 10 کلاس در هفته را دارد، عملا در پایان هر هفته، خروجی تیم، تنها 5 کلاس خواهد بود. در واقع تیم آنالیز یک تنگنا ایجاد کرده و حجم زیادی کار، در بخش آنالیز تجمع پیدا می کنند. مشکل اینجاست که گهگاه، تیم آنالیز برای جبران این نقیصه، تلاش می کند تا سرعت کار خود را با کاهش کیفیت خروجی جبران نماید.
اشکال اصلی این است که شناسایی چنین تنگناهایی در پروسه ی تولید نرم افزار اصلا کار آسانی نیست! هر عضوی از تیم، سرعتی دارد و هر دپارتمانی نیز، توان اجرایی محدودی! در این حالت سایر تیم ها به جای اجرای درخواست های جدید، باید تمرکزشان را روی کمک به تیم آنالیز بگذارند.
متد کنبن یک شیوه بسیار ساده است که به شکلی قدرتمند، اینگونه مشکلات را حل می کند. به ساده ترین بیان، کنبن شامل یک تخته وایتبرد بزرگ روی دیوار است که برگه های یادداشت، یا برچسبهایی - Sticky note روی آن نصب می شوند. روی این برگه ها خلاصه ای از کارهایی که باید انجام شوند نوشته شده. مثلا کلاس هایی که باید توسعه یابند. اما تخته وایتبرد بزرگ ما، به چند بخش کلی تقسیم می شود که معرف فازهای مختلف توسعه ی نرم افزار، مانند آنالیز، توسعه، تست و غیره است.
دقت کنید که قرار نیست یک کپی از آنچه که در اینجا می بینید ایجاد کنید. کافی است بر اساس فرهنگ و شیوه ی کاری تیمتان، چنین تابلویی را استفاده نمایید. در واقع تاثیر ساده این کار، این است که نمایی بصری از آنچه در تیم فنی شما در حال انجام است به شما و مدیر پروژه ارائه می کند و مانع از انباشتگی و کندی کار تیمی می گردد.
اگر دقت کنید متوجه می شوید که برخی از بخش ها به دو قسمت تقسیم شده اند. این نشان دهنده ی کارهایی است که هنوز کارشان تمام نشده و آنهایی که به اتمام رسیده اند.یکی از اعضای تیم تست یکی از واحد های نرم افزار را به اتمام می رساند و این واحد به فاز بعدی منتقل می شود. در این حالت یک فضای خالی در بخش تست ایجاد می شود.
بنابراین یکی از کارهای بخش "توسعه" می تواند به بخش "تست" منتقل شود. با ایجاد یک فضای خالی در بخش "توسعه"، یکی از کارهای بخش "آنالیز" وارد بخش "توسعه" می شود و بالاخره یکی از کارهایی که در حالت انتظار بوده اند، وارد پروسه ی آنالیز و کار خواهد شد و از کندی و معطل ماندن کارها پیشگیری می شود.
اگرچه پروسه ی تولید نرم افزار علاوه بر پیچیدگی های خاص خود، نیاز به خلاقیت بیشتری نسبت به تولید خودرو دارد، اما ساختار اصلی این متد، همان است که تویوتا تعریف کرده بود و به کمک آن می توانید پروسه ی تولید نرم افزار را تا حد ممکن بهینه نمایید. در متد کنبن، پروسه ی تولید نرم افزار را به یک تونل استوانه ای تشبیه کرده اند که ورودی آن درخواست های جدید مشتریان برای افزودن ویژگی های جدید و خروجی اش نرم افزار برنامه نویسی شده می باشد. بنابراین در حالت کلی این شیوه از سه مرحله تشکیل گردیده:
1. آنالیز کردن نیازها
2. کدنویسی و توسعه ی نرم افزار
3. تست و خطایابی آن
مشکل مخفی کار تیمی یا The Bottleneck Effect چیست؟
کارشناسان، ایراد مخفی بزرگی به نام تنگنا را در تیم های تولید نرم افزار شناسایی کرده اند که باعث کند شدن پروسه ی تولید نرم افزار می شود ولی متاسفانه اغلب، از دید مدیران پروژه مخفی می ماند. بگذارید مشکل را با یک مثال برایتان توضیح دهم. فرض کنید در شرکتی سه تیم فعالیت می کنند:
· تیم آنالیز
· تیم توسعه
· تیم تست
اگر تیم آنالیز، در هفته، صرفا قدرت تحلیل پنج کلاس یا ویژگی نرم افزار را داشته باشد، در حالی که تیم توسعه، امکان برنامه نویسی 10 کلاس در هفته را دارد، عملا در پایان هر هفته، خروجی تیم، تنها 5 کلاس خواهد بود. در واقع تیم آنالیز یک تنگنا ایجاد کرده و حجم زیادی کار، در بخش آنالیز تجمع پیدا می کنند. مشکل اینجاست که گهگاه، تیم آنالیز برای جبران این نقیصه، تلاش می کند تا سرعت کار خود را با کاهش کیفیت خروجی جبران نماید.
متد کنبن یک شیوه بسیار ساده است که به شکلی قدرتمند، اینگونه مشکلات را حل می کند. به ساده ترین بیان، کنبن شامل یک تخته وایتبرد بزرگ روی دیوار است که برگه های یادداشت، یا برچسبهایی - Sticky note روی آن نصب می شوند. روی این برگه ها خلاصه ای از کارهایی که باید انجام شوند نوشته شده. مثلا کلاس هایی که باید توسعه یابند. اما تخته وایتبرد بزرگ ما، به چند بخش کلی تقسیم می شود که معرف فازهای مختلف توسعه ی نرم افزار، مانند آنالیز، توسعه، تست و غیره است.
اگر دقت کنید متوجه می شوید که برخی از بخش ها به دو قسمت تقسیم شده اند. این نشان دهنده ی کارهایی است که هنوز کارشان تمام نشده و آنهایی که به اتمام رسیده اند.یکی از اعضای تیم تست یکی از واحد های نرم افزار را به اتمام می رساند و این واحد به فاز بعدی منتقل می شود. در این حالت یک فضای خالی در بخش تست ایجاد می شود.
آخرین ویرایش توسط مدیر