داستان اجایل، داستان اسکرام

اگر در صنعت نرم‌افزار هستید یا در اکوسیستم استارت آپی نقشی ایفا می‌کنید. اگر به عنوان یک مشتری، با تیم یا تیم‌هایی کار کرده‌اید و توسعه نرم‌افزاری که می‌خواستید را به آن‌ها سپرده‌اید. اگر در صنعت دیگری مشغولید ولی نقشی در ارتباط با مدیریت پروژه دارید، این مطالب می‌تواند برایتان جالب توجه باشد.ظهور تفکر سریع (Agile)در سال۱۳۸۰، ۱۷ دوست و رفیق قدیمی که همگی توسعه دهنده نرم افزار بودند، برای تفریح در یکی از اقامتگاه‌های زمستانی به نام Snowbird در ایالت Utah کشور ایالات متحده دور هم جمع شدند. هدف تفریح بود و زدودن خستگی و همینطور وقت گذراندن برای تبادل تجربه یا افکار، حول محور توسعه نرم‌افزار، پروژه‌ها، چالش‌ها و فرصت‌هایی که در جریان است.محل هتل در نقشهبه جز یک دوست از هلند و دو دوست از انگلستان، مابقی از آمریکا بودند. همه افراد این جمع، یک خصیصه مشترک داشتند. چهره‌های تاثیرگذار جهانی در توسعه نرم‌افزار.جمع ۱۷ نفره دوستان در اولین جلسه شکل‌گیری تفکر Agileبعد از یک دورهمی دوستانه، اسکی در طبیعت زیبای Snowbird و استراحت مناسب، تصمیم گرفتند تا در یکی از سالن‌های هتل دور هم جمع شوند و با هم در مورد صنعت تولید نرم‌افزار صحبت کنند.جمع ۱۷ نفره دوستان در اولین جلسه شکل‌گیری تفکر Agile هرکسی تلاش داشت تا بتواند مسائل و مشکلاتی که با آن‌ها دست به گریبان است را شرح دهد. اینکه به نظرش چه جیزی درست نیست یا چه چیزی جای بهبود دارد. عمده سئوال‌هایی که در جلسه طرح می‌شد چیزی شبیه به این بود:آیا از نحوه تولید نرم‌افزار در پروژه‌ای که به آن مشغولید راضی هستید؟پروژه‌های نرم‌افزاری که تجربه می‌کنید، چقدر از رضایت مشتریان یا کسب‌وکارها رو به دنبال دارد؟درصد موفقیت پروژه‌ها برای رسیدن به اهدافشان چقدر است؟آیا فرآیندهای تبدیل نیاز یک مشتری به نرم‌افزار، نرم و روان تعریف می‌شوند یا همیشه با اصطکاک همراهند؟آیا مدت زمانی که برای انجام یک پروژه نرم‌افزاری اختصاص می‌یابد تا مشتری بتواند از آن ارزش بگیرد با خواسته‌های مشتری تطابق دارد؟چقدر یک مشتری از نتیجه کار راضی است؟ یعنی چند درصد از پروژه‌ها به این علت که مشتری تا پایان از آن اطلاع کافی ندارد بعد از ارائه اولیه، نیاز به تغییر پیدا می‌کنند؟بین بها دادن به تهیه و تنظیم مستندات یک نر‌م‌افزار یا رسیدن سریع به یک نرم‌افزاری که کار می‌کند کدام را انتخاب می‌کنیم؟اگر در مسیر پروژه متوجه نیاز به اعمل تغییرات از هرنوعی بشویم (مثلا تغییر در محیط کسب‌وکار، عوض شدن هدف کسب‌وکار، عوض شدن مسیر نیاز مشتری، یک اتفاق پیش‌بینی نشده و امثالهم) چقدر با روی باز با این تغییر کنار می‌آییم؟بررسی مشکلات روش‌های موجود تولید نرم افزار - سال ۱۳۶۵موضوع داغ شد. هر کدام از افراد به نوعی شروع به مشارکت کردند. تجربه خوبشان در صنایع متنوع و محیط‌های مختلف به کمکشان آمد و قرار شد یک لیست از مشکلاتی که صنعت نرم افزار با آنها سر و کله میزند تهیه کنند تا برای رسید به یک راه حل، چاره‌ای بیاندیشند.پس از کلی صحبت و گفتگو، به لیست مشکلات رسیدند.فرآیندهای سخت‌گیرانهمشکل: روش‌های فعلی توسعه معمولاً به وسیله فرآیندهای سخت‌گیرانه و سنگین مشخص می‌شوند که انجام تغییرات در مسیر را دشوار می‌کنند.درگیر نبودن مشتری در فرآیند تولیدمشکل: مشارکت مشتری اغلب محدود است که منجر به سوءتفاهم و عدم تطابق بین نرم‌افزار ارائه شده و انتظارات مشتری می‌شود.تأکید بر مستندسازی به جای نرم‌افزاری که کار می‌کندمشکل: تمرکز بیش از حد بر مستندسازی جامع، بعضی وقت‌ها باعث می‌شود تا کلا نیازهای مشتریان برای انجام تغییرات پذیرفته نشوند یا حتی تحویل نرم‌فزار با تأخیر انجام شود.عدم قابلیت پاسخ به تغییرمشکل: روش‌های جاری با درخواست تغییر مشکل دارند و برای محیط‌هایی که انعطاف‌پذیری و واکنش‌پذیری حیاتی بود، مناسب نیستند.دوره‌های توسعه پیچیده و طولانیمشکل: دوره‌های توسعه اغلب طولانی و پیچیده هستند که باعث می‌شود ارائه خروجی و ارزش به مشتریان با متد گام به گام شدنی نباشد و همچنین نتوان به فرصت‌ها یا چالش‌های ظاهر شده در مسیر واکنش سریع نشان داد.عدم تعامل بین تیم‌هامشکل: رویکردهای جزیره‌ای و کمبود همکاری بین تیم برنامه‌نویسان، تیم تست و تیم‌های دیگر مانع انجام کار با کیفیت و با کارایی بالا می‌شوند.مشکل در اندازه‌گیری پیشرفتمشکل: اندازه‌گیری پیشرفت بر اساس معیارهای فعلی بسیار خطا دارد و گاهی پیشرفت به جای اینکه براساس میزان تحویل آنچه مشتری نیاز دارد تعریف شود، براساس مستنداتی که تولید می‌شود اندازه‌گیری می‌شود.ارتباط ناکارآمدمشکل: بین اعضای تیم و سایر ذی‌نفعان ارتباط کارآمدی وجود ندارد و در بسیاری از اوقات، سوءتفاهم به وجود می‌آید و همچنین نتایجی را به وجود می‌آورد که با نیازهای کاربر هماهنگ نیست.محدودیت انعطاف‌پذیری در برنامه‌ریزی پروژهمشکل: روش‌های فعلی برنامه‌ریزی پروژه منعطف نیستند و اگر تغییری نیاز باشد، بسیار سخت است تا با روش‌های فعلی، برنامه‌ها را تغییر داد.یک لیست خوب ساخته شد. واقعا باید درک کنیم که این لیست را نماینده مشتریان یا کارآفرینان صاحب کسب‌وکار که تماما با فرآیند تولید نرم‌افزار مشکل داشتند، تهیه نکرده بودند. این را افرادی صاحب نام، که خود به نوعی جزوی از مشکل بودن لیست کرده بودند.حال وقت رسیدن به راه حل بود. هر کسی می‌توانست براساس تجاربش با مشتریان، تیم‌های توسعه، تست، فروش و بازاریابی و امثالهم راه حلی پیشنهاد بدهد. بحث و گفتگو شروع شد. در بین تمام مشکلات لیست شده، یک سرنخ مشترک وجود داشت که اگر آن حل می‌شد، خیلی از مشکلات از بین می‌رفت. سرعت!!!سرعت، سرعت و سرعتسرعت انجام کار، سرعت واکنش به تغییرات، سرعت در برنامه‌ریزی مجدد، سرعت در به روزرسانی، سرعت در ایجاد ارزش از طریق سرعت در تحول نرم‌افزاری که کار می‌کند. سرعت، سرعت و سرعت.سرنخ دیگر، تمرکز کمتر روی مستندسازی و تمرکز و صرف بیشتر انرژی روی بیرون دادن خروجی به جای تهیه مستندات مفصل بود. (که البته یه جورایی به سرعت برمی‌گردد)سرنخ دیگر، دخیل کردن مشتری در کل فرآیند تولید بود. نادیده گرفتن مشتری در فرآیند تولید و بازخورد نگرفتن مرتب از اون، مشکلات جدی در انتها به وجود می‌آورد که باعث می‌شد نتیجه، اساسا مورد نظر مشتری نباشد. پس اجازه دادن به مشتری برای اینکه زودتر خروجی‌ها را ببیند و زودتر مسیر درست شکل بگیرد هم ضروری می‌آمد. (دوباره یک جورایی به سرعت برمی‌گردد)سرنخ دیگر، اهمیت دادن و مبنا قراردادن آدم‌ها و روابطشون به جای روش‌ها، متدها و ابزارها بود. به نظر می‌آمد، هرچقدر افرا بتوانند به طور موثرتری با هم ارتباط برقرار کنند و به ابزارهای سرد و بی‌روح چارچوب‌های توسعه بسنده نکنند، نتیجه بهتر و سریع‌تری می‌گیرند. (جالب اینجاست که این سرنخ هم به سرعت برمی‌گردد)بحث داغ شد و هر ۱۷ نفر فعالانه مشغول شدند. همه پیشنهادات روی میز قرار گرفت. لیست شد و دسته‌بندی شد. برای رسیدن به یک لیست یکدست از راه‌حل‌ها، یک مشکل وجود داشت. مشکل این بود که همه پیشنهادات به عنوان راه حل، در یک سطح نبودند. بعضی از آیتم‌های لیست بسیار کلی بودند و بعضی از آنها بسیار دقیق یا کاربردی. به نظر می‌رسید در کنار هم قرار دادن آن‌ها، شروع خوبی برای یک تغییر بزرگ نباشد. فکر خلاقانه‌ای به ذهنشان خطور کرد.دو لیست درست کردند. یک لیست فقط ۴ آیتم داشت. این چهار آیتم، در سطح کلان، رویکرد جدیدی را تعریف می‌کرد. خیلی کاربردی یا راه حل دقیق نبود. تنها نگاه کلی بنیانگذار یک نگرش جدید را نشان میداد. روح حاکم بر روشی باید خلق می‌شد بود. اسم این لیست را لیست ارزش‌ها گذاشتند.بحث در مورد اینکه نام این روش جدید توسعه نرم‌افزار چه باشد هم مطرح شد. از بین تمام پیشنهادات، کلمه Agile انتخاب شد. بسیار نام با مسمایی بود چون همه مسائل، ریشه در نبود سرعت داشتند. چاره درد، سرعت بود. پس اسم لیست را «ارزشهای روش چابک» یا «Agile Values» گذاشتند و برای اینکه جامعه مخاطب و ذی‌نفعان آن در سراسر دنیا را از وجود یک جنبش جدید مطلع کنند، قرار شد تا یک بیانیه صادر کنند و آن را «بیانیه روش چابک برای توسعه نرم‌افزار» یا «Manifesto for Agile Software Development» بنامند.بیانیه اجایل روی وایت برد هتلما در حال کشف راه های بهتری برای توسعه نرم افزار از راه‌های زیر هستیم.خودمان انجامش دهیم و به دیگران برای انجام دادنش کمک کنیم. از طریق این کار ما توانسته‌ایم به ارزش برسیم:اشخاص و ارتباطات به جای فرآیندها و ابزارهاارزش: برای افراد درگیر با فرآیند توسعه و ارتباطات اعضای تیم با هم ارزش بیشتری نسبت به فرآیندها و ابزارهای خاص قائل شوید. اهمیت تعامل سازنده و همکاری مؤثر را درک کنید.نرم‌افزاری که کار می‌کند به جای مستندسازی جامعارزش: تأکید بر ارائه نرم‌افزاری که کار می‌کند به عنوان اولین معیار پیشرفت. در حالی که مستندسازی اهمیت دارد، تمرکز بر تولید نتایج ملموس و عملی است که برای مشتری ارزش فراهم می‌کند.همکاری با مشتری به جای مذاکره قراردادارزش: ترویج همکاری با مشتریان در طول فرآیند توسعه. اولویت بر قراردادهای سفت و محدود نباشد و به جای آن، همکاری فعال با مشتریان، ارتباط مکرر و بازخورد و تناسب با نیازهای متغیر مشتریان استقبال شود.پاسخ به تغییر به جای پیروی از یک برنامهارزش: به پذیرش تغییر در فرآیند توسعه اذعان کنید. اولویت دادن به توانایی پاسخ به تغییرات و تطابق با الزامات و شرایط متغیر به جای رعایت دقیق یک برنامه پیش‌فرض مهم است. روش‌های چابک برای انعطاف‌پذیری و واکنش‌پذیری نسبت به بازخورد و اولویت‌های در حال تغییر طراحی شده‌اند.این چهار اصل با نام ارزش‌های اصلی اجایل یا همان «Agile Core Values» شناخته می‌شوند و بیانیه‌ای که آن را اعلام نموده است با نام «Manifesto for Agile Software Development» یا همان «بیانیه برای توسعه نرم‌افزار چابک» را نام‌گذاری کردند.اما نوبت به لیست دوم رسید. لیستی که راهنمایی بیشتری در مورد اینکه چطور باید کار کرد به خواننده ارائه میداد. لیست دوم ۱۲ آیتم داشت و نام آن را « قواعد چابک» یا همان «Agile Principles» گذاشتند که به نوعی زیر چتر یا با الهام از ارزش‌ها به وجود آمدند. این لیست بسیار کمک کرد تا افرادی که با این مکتب جدید توسعه نرم‌افزار ارتباط برقرار کرده بودن، بتوانند سرنخ‌های عملی بیشتری بگیرند. لیست زیر، دوازده آیتم قواعد چابک هستند:۱. رضایت مشتری از طریق تحویل زودهنگام و مداوم نرم‌افزار:قاعده: نرم‌افزاری که کار می‌کند را به صورت مداوم تحویل دهید، با ترجیح به فواصل زمانی کوتاه‌تر.۲. استقبال به تغییرات حتی در آخرین مراحل توسعهقاعده: به تغییراتی که حتی در آخرین مراحل توسعه رخ می‌دهند، خوش‌آمد بگوئید. روش‌های چابک تغییر را به عنوان یک مزیت رقابتی به مشتری ارائه می‌کنند.۳. تحویل مداوم نرم‌افزاری که کار می‌کندقاعده: نرم‌افزار کاری را به صورت مداوم تحویل دهید، با ترجیح به فواصل زمانی کوتاه‌تر.۴. همکاری بین افراد کسب‌وکار و توسعه‌دهندگان در طول پروژهقاعده: افارد در لایه کسب‌وکار و توسعه‌دهندگان باید در طول پروژه با یکدیگر همکاری کنند.۵. ایجاد پروژه‌ها بر اساس افراد مشتاققاعده: پروژه‌ها را بر اساس افراد باانگیزه ایجاد کنید. محیط و حمایت لازم را فراهم کنید و به آن‌ها اعتماد کنید تا کار را انجام دهند.۶. کارآیی و اثربخشی انتقال اطلاعات به تیم توسعه از طریق گفتگوی رو به روقاعده: کارآمدترین و مؤثرترین روش انتقال اطلاعات به تیم توسعه و همچنین در درون تیم، گفتگوی رو در رو است.۷. نرم‌افزاری که کار می‌کند، به عنوان اصلی‌ترین سنجه پیشرفتقاعده: مبنای پیشرفت، خروجی است و نرم‌افزاری که کار می‌کند. اصلی‌ترین سنجه پیشرفت، وجود نرم‌افزاری است که واقعا کار می‌کند.۸. توسعه پایدار، قابلیت حفظ یک سرعت ثابتقاعده: روش‌های چابک، توسعه پایدار را ترویج می‌کنند. (یعنی پیوسته باشد و قطع و وصل نشود). طرفداران، توسعه‌دهندگان و کاربران باید قادر باشند تا به طور دائم سرعت ثابتی حفظ کنند.۹. توجه مداوم به وجه فنی با کیفیت و همچنین طراحی خوب، چابکی را ارتقاء می‌دهد.قاعده: توجه مداوم به تمایز فنی و طراحی خوب، چابکی را ارتقاء می‌دهد.۱۰. سادگی - هنر به حداکثر رساندن مقدار کار انجام نشده - بسیار اساسی است.قاعده: سادگی - هنر به حداکثر رساندن مقدار کار انجام نشده - بسیار اساسی است.۱۱. تیم با قابلیت خودسازمانده باعث می‌شوند معماری‌ها، تعریف الزامات و طراحی‌ها ارتقا پیدا کنند.قاعده: بهترین معماری‌ها، الزامات و طراحی‌ها از تیم‌های خودسازمانده به وجود می‌آیند.۱۲. مرتبا با این فکر کردن که چگونه کاراتر باشیم و سپس اینکه چگونه رفتار بهتری داشته باشیم.قاعده: در بازه‌های منظم، تیم بر روی عملکرد خود بازنگری می‌کند و به چگونگی بهبود آن فکر می‌کند و سپس رفتار خود را مطابق با آن تنظیم می‌کند.خروجی بسیار شگفت‌انگیز بود. ۴ ارزش اصلی و ۱۲ قاعده اساسی، شالوده یک تفکر یا یک مکتب جدید بود که در نوع خود یک انقلاب در نگاه به کار تولید نرم‌افزار محسوب می‌شد. اثری که این بیانیه و رویکرد جدید در صنعت توسعه نرم‌افزار گذاشت غیرقابل انکار است. این مکتب فکری جدید، نحوه تعریف، مدیریت و کارآیی و کارآمدی پروژه‌ها را نه تنها در صنعت نرم‌افزار بلکه در بسیاری از صنایع دیگر که با مشکلات مشابهی از مدیریت پروژه درگیر بودن، به کل عوض کرد. نیازهایی که مدت‌‌ها نادیده گرفته شده بودند، مجددا زنده شدند و به نوعی نیازهای کسب‌وکارهای نوین با تکیه بر محصولات نرم‌افزاری جانی دوباره گرفتند. ذی‌نفعان کسب‌وکار اکوسیستم‌های استارت‌آپی توانستند به یک مکتب فکری که باعث می‌شد بتوانند با تکیه برآن، کسب و کارشان را با سرعت بیشتر و ریسک کمتر توسعه بدهند، اعتماد کنند.ظهور اسکرام (SCRUM)سال ۱۳۶۵ شمسی، دو پروفسور بازنشسته ژاپنی، به نام‌های Hirotaka Takeuchi (دانشگاه کسب‌وکار هاروارد و دانشگاه توکیو) و Ikujiro Nonaka (دانشگاه کالیفرنیا، برکلی و هیتوتسوباشی ژاپن) یک مقاله‌ای را «Harvard Business Review» منتشر کردند به نام «بازی جدید جدید توسعه محصول». شالوده چارچوب توسعه نرم‌افزار به نام SCRUM از این مقاله گرفته شد.ایده اصلی اسکرام از مقاله این دو استاد دانشگاه گرفته شد.یک توسعه‌دهنده نرم‌افزار معروف به نام Jeff Sutherland (که در سال ۲۰۰۱ هم جزوات ۱۷ نفر گردهمایی اجایل بود) به همراه دو دوست و همکار دیگرش John Scumniotales و Jeff McKenna متاثر از مقاله منتشر شده، شروع به ایده‌پردازی برای رسیدن به یک روش تولید نرم‌افزار با تفکر تکرارشوندگی(Itterative) و افزایشی (Increamental) کردند. آن‌ها سال‌ها روی این موضوع کار کردند و توانستند به افکار خود شکل بهتری بدهند و در نهایت در سال ۱۳۶۹ به صورت رسمی، اسکرام را معرفی کردند و ۷ سال بعد، در سال ۱۳۷۶، کتاب اسکرام را منتشر کردند. توجه کنیم که سال انتشار اولین نسخه کتاب اسکرام ۴ سال قبل از گردهمایی معروف اجایل بود.اسکرام از سال‌ها قبل به وجود آمده بود و در یک مسیر بلوغ وجود داشت. اما مسیر بلوغش از ریشه، کاربردی بود. مکتب یا دیدگاه کلانی نداشت. یا حتی اگر داشت خیلی جامع یا کامل محسوب نمی‌شد. اما وجود یک ورژن اولیه از نحوه توسعه و مدیریت پروژه‌های توسعه نرم‌افزار بسیار به شکل‌گیری یا جهت دادن و بلوغ اولیه خروجی جلسه یوتاه کمک کرد. به نظرم چند اتفاق مهم در جلسه و در سال‌های پس از آن افتاد:مکتب Agile براساس مشکلات جاری صنعت تولید نرم‌افزار به وجود آمد. اما در شکل گیری، کاملا از اسکرام به عنوان چارچوب عملیاتی که قبل‌تر از خودش شکل گرفته بود تاثیر گرفت.چارچوب SCRUM متاثر از مکتب Agile تغییر کرد و بهبود یافت و مسیر بلوغ بهتر و رشد سریع‌تر و فراگیرتری را تجربه کرد به نحوی که با سایه اجایل، هیچ وقت از ریل خارج نشد.اسکرام از حالت یک چارچوب نه چندان معروف با استفاده‌کنندگان محدود، به یک چارچوب فراگیر با پشتوانه جمع فرهیخته توسعه‌دهنگان و بنیانگذاران مکتب Agile تبدیل شد و همین عامل، باعث فراگیر شد آن در سطح بین‌المللی شد.منتج از تفکر اجایل، تعداد زیادی چارچوب کارکری به وجود آمدند که توانستند به نیازهای متنوع تیم‌ها باسایزهای متفاوت و پروژه‌ها با پیچیدگی متفاوت یا بودجه متفاوت پاسخ دهند.برای درک بهتر تفاوت این دو، شاید این دو جمله کمک کننده باشد:اجایل یک مکتب است. یک تفکر است. یک جهان‌بینی است که اصول خود را در سطح کلان دارد.اسکرام یک چارچوب کارکردی است که به تاثیر از این مکتب به بلوغ رسیده و فراگیر شده است.چرا اسکرام؟اسکرام، نام یک نحوه چیدمان افراد در ورزش راگبی است. اسکرام در راگبی ترکیبی از بازیکنان است که با سرهای پایین و دست‌های در هم قفل شده برای شروع مجدد بازی پس از یک تخلف جزئی گرد هم می‌آیند.جاگیری اسکرام در راگبیبه طور مشابه، در زمینه توسعه نرم افزار و مدیریت پروژه، اسکرام بر کار تیمی، همکاری و سازگاری تأکید دارد. نام اسکرام برای نشان دادن تمرکزش بر روی یک تیم سازگار برای کار با همه عوامل درگیر در کار و همچنین خودسازمانده که با یکدیگر به شیوه‌ای هماهنگ و تکراری کار می‌کنند انتخاب شد.آیا اسکرام، تنها چارچوب کاربردی اجایل است؟تعداد زیادی چارچوب کاربردی برای توسعه نرم‌افزار که مکتب اجایل را به عنوان چتر فکری خود انتخاب کرده‌اند وجود دارد. این لیست، نام آیتم‌های مهم در آن‌هاست.ScrumKanbanExtreme Programming (XP)Lean Software DevelopmentFeature-Driven Development (FDD)CrystalDynamic Systems Development Method (DSDM)Disciplined Agile (DA)Scaled Agile Framework (SAFe)Large-Scale Scrum (LeSS)قطعا میتوان باز هم مواردی را به این لیست اضافه کرد. (مثل ورژن فرعی اسکرام که شرکت اسپاتیفای برای مدیریت تیم‌های بزرگتر ایجاد کرده بود)پی‌نوشت‌ها:این نوشته، درک و تحلیل من از تمامی مطالب و محتوایی بود که در مورد اجایل و اسکرام وجود خوانده بودم یا در تیم‌های مختلف آن را تجربه کرده بودم. برای رسیدن به تصویری درست‌تر از هوش مصنوعی OpenAI فقط و فقط برای تحقیقات کمک گرفتم.نام جمع ۱۷ نفره اجایل هم می‌توانید در زیر ببینید:Kent Beck - USAMike Beedle - USA [در سال ۱۳۹۷ فوت کرده است]Arie van Bennekum - NetherlandsAlistair Cockburn - USAWard Cunningham - USAMartin Fowler - UKJames Grenning - USAJim Highsmith - USAAndrew Hunt - USARon Jeffries - USAJon Kern - USABrian Marick - USARobert C. Martin (Uncle Bob) - USASteve Mellor - UKKen Schwaber - USAJeff Sutherland - USA [SCRUM Co-Founder]Dave Thomas - USA