سازمان و مدیریت پروژه چابک

دکتر محمد احمدزاده ( PhD,PMP,ACP,ITIL,COBIT)آدرس لینکدین: https://www.linkedin.com/in/mohammad-ahmadzadehمقدمهتا به حال به این موضوع توجه کرده اید که چرا سازمان ها و شرکت های بزرگی مانند گوگل و فیسبوک می توانند به سرعت ویژگی های جدیدی را به محصولاتشان اضافه کنند ولی همین کار برای شرکت های دیگر تا هفته‌ها یا حتی ماه ها طول می کشد؟ راز گوگل و فیسبوک و شرکت های مشابه آن چیست؟استخدام بهترین ها ؟تعداد زیاد کارکنانشان ؟و یا پشتوانه مالی آنها ؟اما هیچکدام از موارد فوق؛ دلیل اصلی نمی باشد. دلیل اصلی این موفقیت، استفاده آن ها از روش های توسعه نرم افزار چابک یا Agile می باشد.دوره آموزشی مرتبط با این مقالهتولد چابکشرکت تحقیقاتی Standish Group در سال 1994 آمارگیری وسیعی بر روی چندین هزار پروژه توسعه نرم افزار انجام داد. در این آمارگیری میزان زیادی از سرمایه گذاری انجام شده تلف شده و بسیاری از پروژه ها شکست خورده بودند. نکته جالب اینجاست که در هیچکدام یک از این پروژه ها از چارچوب و متدولوژی چابک یا Agile استفاده نشده بود. نتیجه آمارگیری بدین صورت بوده استنمودار۱: تحقیق Standish Group درباره آمار شکست و موفقیت پروژه های نرم افزاری (۱۹۹۴)مانیفست ۴ گانه مدیریت پروژه چابکاین آمار باعث شد تا بزرگان توسعه نرم افزار مانند جف ساترلند، روبرت-سی-مارتین، کن شوابر و دیگران، سعی کنند برای بهبود اوضاع با مطالعه دقیق، دلایل موفقیت این 16% پروژه را کشف کنند تا اینکه در سال ۲۰۰۱ طی بیانیه‌ چابک نتایج تحقیقاتشان را منتشر کردند:“ما در تلاشیم تا راه های بهتری در زمینه توسعه نرم افزار پیدا کنیم و به دیگران نیز در رسیدن به این هدف یاری می رسانیم. با انجام این کار مزیت های زیر متصور است”:شکل ۱: ۴ مانیفست کلیدی در مدیریت چابکتمامی این تلاش ها باعث شد که آمار موفقیت پروژه ها، در سال ۲۰۰۴ به عدد ۳۴% برسد، که بیش از دو برابر پیشرفت محسوب می شد. در این بین نمی توان از تاثیر دو اصل تعامل با مشتری و افزایش قدرت انعطاف پذیری در مقابل تغییرات چشم پوشی کرد.اما دلیل این امر در چیست؟الزام به مدیریت پروژه چابکانجام پروژه های نرم افزاری مانند شلیک گلوله به سمت هدف متحرک است و برای این کار، حداکثر یک بار فرصت داریم؛ لذا قبل از شلیک سعی می کنیم با توجه به محل قرارگیری هدف، خوب محاسبه و برنامه ریزی کنیم؛ سپس نفس را حبس و در نهایت شلیک کنیم. اما هیچ وقت موفق به زدن هدف نمی شویم! چرا؟چون درست زمانیکه مشغول تنظیم زاویه توپ بودیم هدف جای خود را تغییر داده است، یعنی همان اتفاقی که در پروژه های مختلف نرم افزاری مشاهده می کنیم؛ در حقیقت نیازهای مشتری تغییر می کند و این یعنی شکست یک پروژه دیگر.این شلیک چشم بسته سه فرض نادرست را در پس خود دارد:مشتری می داند که چه چیزی را می خواهد ؟!توسعه دهنده های نرم افزار می دانند که بهترین راه حل مسئله چیست ؟!نیازهای مشتری ثابت بوده و تغییر نمی کند ؟!اما باید قبول کرد که تغییر نیازمندیهای مشتری غیر قابل اجتناب است و به جای مقابله با این تغییرات، باید راهکاری را پیدا نمائیم تا سریعتر تغییر جهت دهیم.دوره آموزشی مرتبط با این مقالهحل مسئله توپ و هدف به روش Agile، دقیقا مانند این است که به جای توپ، از گلوله کنترل از راه دور استفاده کنیم تا هر چقدر هم که هدف تغییر مکان دهد، سرنوشتی جز انهدام نداشته باشد؛ یعنی ما به عنوان توسعه دهنده نرم افزار، می دانیم که مشتری تازه در حین انجام پروژه نیازمندی های خودش را متوجه می شود؛ بنابراین این نیازها، حتماً تغییر خواهند کرد. در ضمن راه حل درست برای تامین و تکمیل این نیازمندی ها نیز، در حین انجام پروژه و توسط توسعه دهنده گان نرم افزار کشف می شود، پس استفاده از متدولوژی چابک، یک قدم به سمت موفقیت پروژه می باشد.روبرت-سی- مارتین و همکارانش فهمیدند که هر چه حجم کاری که قرار است انجام شود کمتر باشد، پیش بینی‌ها نزدیک تر به واقعیت هستند؛ لذا باید پروژه را به اجزای کوچکتر تقسیم نمود و به جای پیش بینی مدت انجام کل پروژه، مدت انجام اجزا را پیش بینی کرد. یکی دیگر از اصول متدولوژی چابک، به برنامه ریزی چابک و تحویل پی در پی محصول نرم افزاری کارا در بازه‌های زمانی کوتاه تاکید دارد. اگر در هر کدام از این بازه ها، از پیش بینی خود عقب افتادیم؛ حداقل باید بتوانیم تا پایان دوره، مهمترین قسمت های محصول را ارائه دهیم؛ زمان این دوره ها حتماً باید کوتاه باشد. برای مثال اگر ما قطاری را از دست بدهیم که هر ۵ دقیقه یک بار حرکت میکند، مشکل جدی پیش نمی آید؛ در بدترین شرایط فقط ۵ دقیقه معطل می شویم. اما اگر همین قطار ۳۰ دقیقه یک بار حرکت کند، انتظار؛ آزاردهنده است، ولی به هر حال صبر می کنیم. در شرایط بدتر، از دست دادن کشتی که هر دو هفته یک بار از بندر حرکت می کند، یک فاجعه خواهد بود.اگر یک تیم مدیریت پروژه به جای 6 ماه کار مستمر روی یک پروژه، در بازه های زمانی دو هفته ای آن را انجام دهد و در انتهای این بازه ها، بخشی از محصول را به مشتری تحویل دهد، اگرحتی کل راه را اشتباه رفته باشد، فقط دو هفته از زمان پروژه را از دست داده است نه ۶ ماه را!بنابراین دوره های زمانی کوچکتر ریسک شکست پروژه رو پایین می آورد. این همان کاری که در مدیریت پروژه چابک انجام می دهیم!نظرات و سوالات ارزشمند تان را با من و در پایین همین مطلب به اشتراک بگذارید.ارادت- محمد احمدزادهآدرس ایمیل: Info@ahmadzadeh.academyآدرس ایمیل: info@mohammad-ahmadzadeh.comوبسایت شخصی: https://mohammad-ahmadzadeh.com