اگر در صنعت نرمافزار هستید یا در اکوسیستم استارت آپی نقشی ایفا می‌کنید. اگر به عنوان یک مشتری، با تیم یا تیم‌هایی کار کرده‌اید و توسعه نرم‌افزاری که می‌خواستید را به آنها سپرده‌اید. اگر در صنعت دیگری مشغولید ولی نقشی در ارتباط با مدیریت پروژه دارید، این مطالب می‌تواند برایتان جالب توجه باشد.
در سال۱۳۸۰، ۱۷ دوست و رفیق قدیمی که همگی توسعه دهنده نرم افزار بودند، برای تفریح در یکی از اقامتگاه‌های زمستانی به نام Snowbird در ایالت Utah کشور ایالات متحده دور هم جمع شدند. هدف تفریح بود و زدودن خستگی و همینطور وقت گذراندن برای تبادل تجربه یا افکار، حول محور توسعه نرمافزار، پروژه‌ها، چالش‌ها و فرصت‌هایی که در جریان است.
به جز یک دوست از هلند و دو دوست از انگلستان، مابقی از آمریکا بودند. همه افراد این جمع، یک خصیصه مشترک داشتند. چهره‌های تاثیرگذار جهانی در توسعه نرمافزار.
بعد از یک دورهمی دوستانه، اسکی در طبیعت زیبای Snowbird و استراحت مناسب، تصمیم گرفتند تا در یکی از سالن‌های هتل دور هم جمع شوند و با هم در مورد صنعت تولید نرمافزار صحبت کنند.
هرکسی تلاش داشت تا بتواند مسائل و مشکلاتی که با آنها دست به گریبان است را شرح دهد. اینکه به نظرش چه جیزی درست نیست یا چه چیزی جای بهبود دارد. عمده سئوال‌هایی که در جلسه طرح می‌شد چیزی شبیه به این بود:
موضوع داغ شد. هر کدام از افراد به نوعی شروع به مشارکت کردند. تجربه خوبشان در صنایع متنوع و محیط‌های مختلف به کمکشان آمد و قرار شد یک لیست از مشکلاتی که صنعت نرم افزار با آنها سر و کله میزند تهیه کنند تا برای رسید به یک راه حل، چاره‌ای بیاندیشند.
پس از کلی صحبت و گفتگو، به لیست مشکلات رسیدند.
یک لیست خوب ساخته شد. واقعا باید درک کنیم که این لیست را نماینده مشتریان یا کارآفرینان صاحب کسب‌وکار که تماما با فرآیند تولید نرمافزار مشکل داشتند، تهیه نکرده بودند. این را افرادی صاحب نام، که خود به نوعی جزوی از مشکل بودن لیست کرده بودند.
حال وقت رسیدن به راه حل بود. هر کسی می‌توانست براساس تجاربش با مشتریان، تیم‌های توسعه، تست، فروش و بازاریابی و امثالهم راه حلی پیشنهاد بدهد. بحث و گفتگو شروع شد. در بین تمام مشکلات لیست شده، یک سرنخ مشترک وجود داشت که اگر آن حل می‌شد، خیلی از مشکلات از بین می‌رفت. سرعت!!!
سرعت انجام کار، سرعت واکنش به تغییرات، سرعت در برنامه‌ریزی مجدد، سرعت در به روزرسانی، سرعت در ایجاد ارزش از طریق سرعت در تحول نرم‌افزاری که کار می‌کند. سرعت، سرعت و سرعت.
سرنخ دیگر، تمرکز کمتر روی مستندسازی و تمرکز و صرف بیشتر انرژی روی بیرون دادن خروجی به جای تهیه مستندات مفصل بود. (که البته یه جورایی به سرعت برمی‌گردد)
سرنخ دیگر، دخیل کردن مشتری در کل فرآیند تولید بود. نادیده گرفتن مشتری در فرآیند تولید و بازخورد نگرفتن مرتب از اون، مشکلات جدی در انتها به وجود می‌آورد که باعث می‌شد نتیجه، اساسا مورد نظر مشتری نباشد. پس اجازه دادن به مشتری برای اینکه زودتر خروجی‌ها را ببیند و زودتر مسیر درست شکل بگیرد هم ضروری می‌آمد. (دوباره یک جورایی به سرعت برمی‌گردد)
سرنخ دیگر، اهمیت دادن و مبنا قراردادن آدم‌ها و روابطشون به جای روش‌ها، متدها و ابزارها بود. به نظر می‌آمد، هرچقدر افرا بتوانند به طور موثرتری با هم ارتباط برقرار کنند و به ابزارهای سرد و بی‌روح چارچوب‌های توسعه بسنده نکنند، نتیجه بهتر و سریع‌تری می‌گیرند. (جالب اینجاست که این سرنخ هم به سرعت برمی‌گردد)
بحث داغ شد و هر ۱۷ نفر فعالانه مشغول شدند. همه پیشنهادات روی میز قرار گرفت. لیست شد و دسته‌بندی شد. برای رسیدن به یک لیست یکدست از راه‌حل‌ها، یک مشکل وجود داشت. مشکل این بود که همه پیشنهادات به عنوان راه حل، در یک سطح نبودند. بعضی از آیتم‌های لیست بسیار کلی بودند و بعضی از آنها بسیار دقیق یا کاربردی. به نظر می‌رسید در کنار هم قرار دادن آنها، شروع خوبی برای یک تغییر بزرگ نباشد. فکر خلاقانه‌ای به ذهنشان خطور کرد.
دو لیست درست کردند. یک لیست فقط ۴ آیتم داشت. این چهار آیتم، در سطح کلان، رویکرد جدیدی را تعریف می‌کرد. خیلی کاربردی یا راه حل دقیق نبود. تنها نگاه کلی بنیانگذار یک نگرش جدید را نشان میداد. روح حاکم بر روشی باید خلق می‌شد بود. اسم این لیست را لیست ارزش‌ها گذاشتند.
بحث در مورد اینکه نام این روش جدید توسعه نرمافزار چه باشد هم مطرح شد. از بین تمام پیشنهادات، کلمه Agile انتخاب شد. بسیار نام با مسمایی بود چون همه مسائل، ریشه در نبود سرعت داشتند. چاره درد، سرعت بود. پس اسم لیست را «ارزشهای روش چابک» یا «Agile Values» گذاشتند و برای اینکه جامعه مخاطب و ذی‌نفعان آن در سراسر دنیا را از وجود یک جنبش جدید مطلع کنند، قرار شد تا یک بیانیه صادر کنند و آن را «بیانیه روش چابک برای توسعه نرمافزار» یا «Manifesto for Agile Software Development» بنامند.
ما در حال کشف راه های بهتری برای توسعه نرم افزار از راه‌های زیر هستیم.
خودمان انجامش دهیم و به دیگران برای انجام دادنش کمک کنیم. از طریق این کار ما توانسته‌ایم به ارزش برسیم:
اشخاص و ارتباطات به جای فرآیندها و ابزارها
ارزش: برای افراد درگیر با فرآیند توسعه و ارتباطات اعضای تیم با هم ارزش بیشتری نسبت به فرآیندها و ابزارهای خاص قائل شوید. اهمیت تعامل سازنده و همکاری مؤثر را درک کنید.
نرم‌افزاری که کار می‌کند به جای مستندسازی جامع
ارزش: تأکید بر ارائه نرم‌افزاری که کار می‌کند به عنوان اولین معیار پیشرفت. در حالی که مستندسازی اهمیت دارد، تمرکز بر تولید نتایج ملموس و عملی است که برای مشتری ارزش فراهم می‌کند.
همکاری با مشتری به جای مذاکره قرارداد
ارزش: ترویج همکاری با مشتریان در طول فرآیند توسعه. اولویت بر قراردادهای سفت و محدود نباشد و به جای آن، همکاری فعال با مشتریان، ارتباط مکرر و بازخورد و تناسب با نیازهای متغیر مشتریان استقبال شود.
پاسخ به تغییر به جای پیروی از یک برنامه
ارزش: به پذیرش تغییر در فرآیند توسعه اذعان کنید. اولویت دادن به توانایی پاسخ به تغییرات و تطابق با الزامات و شرایط متغیر به جای رعایت دقیق یک برنامه پیش‌فرض مهم است. روش‌های چابک برای انعطاف‌پذیری و واکنش‌پذیری نسبت به بازخورد و اولویت‌های در حال تغییر طراحی شده‌اند.
این چهار اصل با نام ارزشهای اصلی اجایل یا همان «Agile Core Values» شناخته می‌شوند و بیانیه‌ای که آن را اعلام نموده است با نام «Manifesto for Agile Software Development» یا همان «بیانیه برای توسعه نرمافزار چابک» را نام‌گذاری کردند.
اما نوبت به لیست دوم رسید. لیستی که راهنمایی بیشتری در مورد اینکه چطور باید کار کرد به خواننده ارائه میداد. لیست دوم ۱۲ آیتم داشت و نام آن را « قواعد چابک» یا همان «Agile Principles» گذاشتند که به نوعی زیر چتر یا با الهام از ارزش‌ها به وجود آمدند. این لیست بسیار کمک کرد تا افرادی که با این مکتب جدید توسعه نرمافزار ارتباط برقرار کرده بودن، بتوانند سرنخ‌های عملی بیشتری بگیرند. لیست زیر، دوازده آیتم قواعد چابک هستند:
۱. رضایت مشتری از طریق تحویل زودهنگام و مداوم نرمافزار:
قاعده: نرم‌افزاری که کار می‌کند را به صورت مداوم تحویل دهید، با ترجیح به فواصل زمانی کوتاه‌تر.
۲. استقبال به تغییرات حتی در آخرین مراحل توسعه
قاعده: به تغییراتی که حتی در آخرین مراحل توسعه رخ می‌دهند، خوش‌آمد بگوئید. روش‌های چابک تغییر را به عنوان یک مزیت رقابتی به مشتری ارائه می‌کنند.
۳. تحویل مداوم نرم‌افزاری که کار می‌کند
قاعده: نرمافزار کاری را به صورت مداوم تحویل دهید، با ترجیح به فواصل زمانی کوتاه‌تر.
۴. همکاری بین افراد کسب‌وکار و توسعه‌دهندگان در طول پروژه
قاعده: افارد در لایه کسب‌وکار و توسعه‌دهندگان باید در طول پروژه با یکدیگر همکاری کنند.
۵. ایجاد پروژه‌ها بر اساس افراد مشتاق
قاعده: پروژه‌ها را بر اساس افراد باانگیزه ایجاد کنید. محیط و حمایت لازم را فراهم کنید و به آنها اعتماد کنید تا کار را انجام دهند.
۶. کارآیی و اثربخشی انتقال اطلاعات به تیم توسعه از طریق گفتگوی رو به رو
قاعده: کارآمدترین و مؤثرترین روش انتقال اطلاعات به تیم توسعه و همچنین در درون تیم، گفتگوی رو در رو است.
۷. نرم‌افزاری که کار می‌کند، به عنوان اصلی‌ترین سنجه پیشرفت
قاعده: مبنای پیشرفت، خروجی است و نرم‌افزاری که کار می‌کند. اصلی‌ترین سنجه پیشرفت، وجود نرم‌افزاری است که واقعا کار می‌کند.
۸. توسعه پایدار، قابلیت حفظ یک سرعت ثابت
قاعده: روش‌های چابک، توسعه پایدار را ترویج می‌کنند. (یعنی پیوسته باشد و قطع و وصل نشود). طرفداران، توسعه‌دهندگان و کاربران باید قادر باشند تا به طور دائم سرعت ثابتی حفظ کنند.
۹. توجه مداوم به وجه فنی با کیفیت و همچنین طراحی خوب، چابکی را ارتقاء می‌دهد.
قاعده: توجه مداوم به تمایز فنی و طراحی خوب، چابکی را ارتقاء می‌دهد.
۱۰. سادگی - هنر به حداکثر رساندن مقدار کار انجام نشده - بسیار اساسی است.
قاعده: سادگی - هنر به حداکثر رساندن مقدار کار انجام نشده - بسیار اساسی است.
۱۱. تیم با قابلیت خودسازمانده باعث می‌شوند معماری‌ها، تعریف الزامات و طراحی‌ها ارتقا پیدا کنند.
قاعده: بهترین معماری‌ها، الزامات و طراحی‌ها از تیم‌های خودسازمانده به وجود می‌آیند.
۱۲. مرتبا با این فکر کردن که چگونه کاراتر باشیم و سپس اینکه چگونه رفتار بهتری داشته باشیم.
قاعده: در بازه‌های منظم، تیم بر روی عملکرد خود بازنگری می‌کند و به چگونگی بهبود آن فکر می‌کند و سپس رفتار خود را مطابق با آن تنظیم می‌کند.
خروجی بسیار شگفت‌انگیز بود. ۴ ارزش اصلی و ۱۲ قاعده اساسی، شالوده یک تفکر یا یک مکتب جدید بود که در نوع خود یک انقلاب در نگاه به کار تولید نرمافزار محسوب می‌شد. اثری که این بیانیه و رویکرد جدید در صنعت توسعه نرمافزار گذاشت غیرقابل انکار است. این مکتب فکری جدید، نحوه تعریف، مدیریت و کارآیی و کارآمدی پروژه‌ها را نه تنها در صنعت نرمافزار بلکه در بسیاری از صنایع دیگر که با مشکلات مشابهی از مدیریت پروژه درگیر بودن، به کل عوض کرد. نیازهایی که مدت‌‌ها نادیده گرفته شده بودند، مجددا زنده شدند و به نوعی نیازهای کسب‌وکارهای نوین با تکیه بر محصولات نرم‌افزاری جانی دوباره گرفتند. ذی‌نفعان کسب‌وکار اکوسیستم‌های استارت‌آپی توانستند به یک مکتب فکری که باعث می‌شد بتوانند با تکیه برآن، کسب و کارشان را با سرعت بیشتر و ریسک کمتر توسعه بدهند، اعتماد کنند.
سال ۱۳۶۵ شمسی، دو پروفسور بازنشسته ژاپنی، به نام‌های Hirotaka Takeuchi (دانشگاه کسب‌وکار هاروارد و دانشگاه توکیو) و Ikujiro Nonaka (دانشگاه کالیفرنیا، برکلی و هیتوتسوباشی ژاپن) یک مقاله‌ای را «Harvard Business Review» منتشر کردند به نام «بازی جدید جدید توسعه محصول». شالوده چارچوب توسعه نرمافزار به نام SCRUM از این مقاله گرفته شد.
یک توسعه‌دهنده نرمافزار معروف به نام Jeff Sutherland (که در سال ۲۰۰۱ هم جزوات ۱۷ نفر گردهمایی اجایل بود) به همراه دو دوست و همکار دیگرش John Scumniotales و Jeff McKenna متاثر از مقاله منتشر شده، شروع به ایده‌پردازی برای رسیدن به یک روش تولید نرمافزار با تفکر تکرارشوندگی(Itterative) و افزایشی (Increamental) کردند. آنها سال‌ها روی این موضوع کار کردند و توانستند به افکار خود شکل بهتری بدهند و در نهایت در سال ۱۳۶۹ به صورت رسمی، اسکرام را معرفی کردند و ۷ سال بعد، در سال ۱۳۷۶، کتاب اسکرام را منتشر کردند. توجه کنیم که سال انتشار اولین نسخه کتاب اسکرام ۴ سال قبل از گردهمایی معروف اجایل بود.
اسکرام از سال‌ها قبل به وجود آمده بود و در یک مسیر بلوغ وجود داشت. اما مسیر بلوغش از ریشه، کاربردی بود. مکتب یا دیدگاه کلانی نداشت. یا حتی اگر داشت خیلی جامع یا کامل محسوب نمی‌شد. اما وجود یک ورژن اولیه از نحوه توسعه و مدیریت پروژه‌های توسعه نرمافزار بسیار به شکل‌گیری یا جهت دادن و بلوغ اولیه خروجی جلسه یوتاه کمک کرد. به نظرم چند اتفاق مهم در جلسه و در سال‌های پس از آن افتاد:
برای درک بهتر تفاوت این دو، شاید این دو جمله کمک کننده باشد:
اسکرام، نام یک نحوه چیدمان افراد در ورزش راگبی است. اسکرام در راگبی ترکیبی از بازیکنان است که با سرهای پایین و دست‌های در هم قفل شده برای شروع مجدد بازی پس از یک تخلف جزئی گرد هم می‌آیند.
به طور مشابه، در زمینه توسعه نرم افزار و مدیریت پروژه، اسکرام بر کار تیمی، همکاری و سازگاری تأکید دارد. نام اسکرام برای نشان دادن تمرکزش بر روی یک تیم سازگار برای کار با همه عوامل درگیر در کار و همچنین خودسازمانده که با یکدیگر به شیوه‌ای هماهنگ و تکراری کار می‌کنند انتخاب شد.
تعداد زیادی چارچوب کاربردی برای توسعه نرمافزار که مکتب اجایل را به عنوان چتر فکری خود انتخاب کرده‌اند وجود دارد. این لیست، نام آیتم‌های مهم در آن‌هاست.
قطعا میتوان باز هم مواردی را به این لیست اضافه کرد. (مثل ورژن فرعی اسکرام که شرکت اسپاتیفای برای مدیریت تیم‌های بزرگتر ایجاد کرده بود)
پی‌نوشت‌ها:
