پروداکت استوری: شکست اجایل Agile

این متن ترجمه نوشته آقای Andy Hunt یکی از بنیانگذاران مانیفست اجایل است. مفتخرم که جزو 17 نفر بنیانگذاران یا نویسندگان مانیفست اجایل در سال 2001 هستم. فکر می‌کنم این مانیفست، تلنگری از انرژی، امید به روشی بهتر برای انجام کارها، ایجاد نرم افزار و بهتر کردن جهان را فراهم کرد. این اتفاقف یک نقطه عطف بود. اما در 14 سال زمانی که از آن تاریخ می‌گذرد، ما راه خود را گم کردیم.کلمه اجایل، سازمان یافته شده. و در بهترین حالت "بی معنی" و در بد ترین حالت دچار جینگوئیسم شده است. تعداد زیادی از افراد، اجایل را به صورت ضعیف انجام می‌دهند. تلاشی نصف و نیمه برای پیروی از چند روش منتخب توسعه نرم افزار، آن هم به شکلی ضعیف. تعداد زیادی متعصب اجایل داریم - به این معنا که متعصب کسی است که با فراموش کردن هدف، تلاش خود را دو چندان می‌کند. و بد تر از همه، متودولوژی های اجایل، خود اجایل نبودند.و قسمت طنز ماجرا اینجاست!چگونه وارد این آشفتگی شدیم؟شادی ناشی از وجود قوانین:اساس رویکرد اجایل، پذیرش تغییر است. آگاهی از:تغییرات محصول در حال توسعهنیازها و خواسته های کاربرانمحیط، رقابت، بازار، تکنولوژیو همه اینها می‌توانند چشمه های تغییر باشند.برای پذیرش جریان تغییر، متند های اجایل به ما توصیه می‌کنند تا "بازرسی و تطبیق" داشته باشیم. به این معنی که بفهمیم چه چیزی تغییر کرده است تا ما به وسیله تغییر متد ها، بازنویسی کدها، همکاری با مشتریان مان و ...، با آن سازگار شویم. اما اکثر کسانی که به اصطلاح اجایل را پذیرفته اند، این کار را انجام نمی‌دهند و دلیل خوبی هم دارند.زمانی که شما برای اولین بار در حال یادگیری یک مهارت جدید هستید - یک زبان برنامه نویسی جدید، یا یک تکنیک جدید، یا یک روش توسعه جدید - هنوز تجربه، مدل‌های ذهنی یا توانایی مدیریت یک مفهوم انتزاعی مانند "بازرسی و تطبیق" را ندارید.این توانایی، تنها در افرادی با تجربه بسیار بالا در به کارگیری این متند ها، در سطوح مهارت بالاتر وجود دارد. تنها راهی که مبتدیان می‌توانند با استفاده از آن، موثر باشند این است که از قوانین ساده و بدون پیش زمینه استفاده کنند. "وقتی این اتفاق افتاد، آن را انجام دهید."و از آنجایی که متدولوژی های اجایل، به راحتی برخی از روش های مشخص را برای شروع ارائه می‌کند، تیم های جدید به همه آنها یا به بخشی از آنها می‌چسبند و همانجا گیر می‌کنند. بنابراین، به جای توجه به اصول اجایل و ایده‌های انتراعی مانیفست اجایل، افراد به قوانین آهنین و مجموعه ای از شیوه های انجام کار خواهند پرداخت و نه بیشتر! متد های اجایل از استفاده کنندگان می‌خواهند تا فکر کنند، و صادقانه بگویم این یک اجبار است. خیلی راحت است که به سادگی از قوانینی که مطرح شده پیروی کنید و ادعا کنید که شما براساس کتاب راهنما جلو می روید. زیرا این روش، آسان است و از تمسخر و سرزنش در امان است. هرگز به خاطر آن اخراج نخواهی شد. در عین حال که ممکن است علنا محدودیت های برخی از قوانین را مطرح و محکوم کنیم. اما نقطه امن و راحتی در شیوه وجود دارد. اما مطمئنا چابک بود و یا موثر بودن به معنای راحتی نیست.اگه فقط تعداد نگشت شماری از قوانینی را انتخاب کنید که دلتان می‌خواهد آنها را دنبال کنید و قوانین سخت را نادیده بگیرید، آنگاه اگر کسی از شما پرسید، می‌توانید بگویید "اجایل عمل می‌کنید". آنگاه می‌توانید انرژی خود را بر اجرا و استفاده مجموعه کوچک از قوانین عمدتا بیفایده صرف کنید. در این صورت، همه احساس بهتری دارند، درست تا وقتی که قرار باشد چیزی را به مشتریان ارائه دهید.گیر کردن در شیار بتنی:پیروی از مجموعه ای از قوانین سختگیرانه، عملکرد شما را به اندازه یک فرد تازه کار پایین می آورد. بنابراین، تیم ها خود را ناآگاهانه و توسط یک راه حل، گیر انداخته اند. پیروی کورکورانه از قوانین مشخص و نه کسب تجربه ای که لازم دارند تا به نقطه ای برسند که بدانند و بتوانند از قوانین فراتر بروند.این روزها، خیلی شایع است که در توییتر یا در mailing listها، جر و بحث هایی دیده می‌شود که در آنها، متعصبان قوانین محدود اجایل استدلال می‌کنند که شما اجایل نیستید زیرا قوانین مورد علاقه آنها را دنبال نمی‌کنید.ایده بازرسی و تطبیق چه شد؟ایده معرفی شیوه‌های جدید و تکامل شیوه‌هایمان متناسب با چالش‌های موجود چه شد؟ شیوه های اجایل متعارف در متودولوژی های رایج، اساساً برای بیش از یک دهه بدون تغییر باقی مانده است. ما در بلاتکلیفی گیر کرده ایم. و همانطور که من دوست دارم بگویم، تنها تفاوت بین شیار و گور در ابعاد است.یک راه رو به جلوتا به حال، افراد زیادی از جنبش اجایل شاکی هستند، برخی بی سر و صدا، برخی با صدای بلند، و هیچ یک از این شکایات بدیع نیستند. (تازگی ندارند) اما در اینجا یک نکته جدید وجود دارد: بیایید آن را درست کنیم. همینجا همین الان. ما با هم می توانیم مشکلات ذاتی در پذیرش و تکامل اجایل را برطرف کنیم و به پیشبرد صنعت کمک کنیم.اول از همه، ما نیاز به یک نام داریم. مجموعه‌ای از ایده‌های خوب معمولاً در دنیا جذابیت چندانی ندارند. باید یک نام، یک برند وجود داشته باشد تا ایده را به آن آویزان کنیم. نامش را بگذاریم:روش GROWS™در این مورد GROWS مخفف Growing-World Oriented Working Systems است. این ایده ای است که من و جرد ریچاردسون روی آن کار کرده ایم.اینها، مفاهیم مهمی هستند:نرم افزار طراحی و ساخته نمی‌شود. این مدلِ خطی و قطعی ای است، که در اینجا کارکرد ندارد. رشد استعاره بهتری است، زیرا رشد با تغییر همراه است. با محوریت دنیای واقعی Real-world-oriented، اشاره به این ایده است که ما باید تمام تصمیمات خود و جهتگیری های خود را مبتنی بر شواهد واقعی بنا کنیم. یعنی دریافت بازخورد از دنیای واقعی و در شرایط واقعی. هر چیزی جز این، فقط ترکیب نامناسبی از خیال پردازی و توهم است.و البته، نرم افزاری که کار کند، محصولی است که ما در نهایت تحویل خواهیم داد. اما نه به قیمت هزینه شدن یک تیم کاری/عملکردی و نه به قیمت هزینه شدن کل سازمان. نرم افزار، تیم، کاربران، حامیان مالی، همه و همه یک سیستم را تشکیل می‌دهند. و ما باید از این مطمئن شویم که کل سیستم برای تمام اجزای تشکیل دهنده اش، کار می کند.بنابراین بیایید روش "جدید" خود را بر چهار ایده اساسی بنا کنیم:مبتنی بر شواهدمدل مهارت Dreyfus سازگاری محلی Local Adaptation (سازگاری براساس شرایط محیطی موجود)فراگیری عمومیمبتنی بر شواهد:یعنی، هر تیمی بتواند براساس شواهد واقعی و براساس بازخورد های دنیای واقعی، بازرسی و تطبیق را انجام دهد.مدل مهارت Dreyfus:اما برای رساندن این تیم ها به آن نقطه، لازم است از آموخته های مدل مهارت Dreyfus برای ارائه پشتیبانی دقیق برای مبتدیان و اراه خدمات برای اجرا کنندگان پیشرفته تر، استفاده کنیم.سازگاری محلی Local Adaptation:با قرارگیری این چارچوب در جایگاه خود، ما میخواتیم هر تیمی را براساس شواهد واقعی، با خیال راحت و با شرایط بومی آن، سازگار کنیم.فراگیری عمومی:و در نهایت، هر تلاشی که در اینجا انجام می‌دهیم، باید برای کل سیستم کار کند. و نه فقط توسعه دهندگان و نه فقط مدیران و تستر ها، و نه فقط کاربران و نه فقط حامیان مالی. در اینجا، "ما" در مقابل "آنها" وجود ندارد. فقط و فقط "ما" وجود دارد.پایانمسیح حیدری زادهلینک مطلب اصلیhttps://toolshed.com/2015/05/the-failure-of-agile.html