آموزش اسکرام؛ قسمت اول: مروری بر رویکرد چابک

اسکرام (Scrum) چهارچوبی برای مدیریت پروژه است که با تمرکز بر کار تیمی، مسئولیت‌پذیری و تکرار و پیشروی به سمت یک هدف مشخص اجرا می‌شود. این چهارچوب با یک فرضیه‌ی ساده آغاز می‌شود: کار را با آنچه می‌بینید یا می‌شناسید شروع کنید. پس‌ازآن، پیشرفت پروژه را پیگیری و بررسی کنید و در صورت نیاز، اصلاحات و تغییرات لازم را به وجود آورید.

اسکرام چهارچوبی مبتنی بر تیم، برای توسعه‌ی سیستم‌ها یا محصولات پیچیده است که پروژه را طی یک فرایند تدریجی و پیش‌رونده، مدیریت می‌کند. به عبارتی شما همیشه در اسکرام، تحت پوشش یک تیم کار می‌کنید. این تیم باید عملکرد متقابل داشته باشد، یعنی از تمام توانایی‌های لازم برای تکمیل وظایف برخوردار باشد. به‌عنوان‌مثال در حوزه‌ی توسعه‌ی نرم‌افزار، تیم شما متشکل از توسعه‌دهندگان بک‌اند (Backend)، توسعه‌دهندگان فرانت‌اند (Frontend) و همچنین طراحان و آزمایش‌کنندگان خواهد بود.

در حالت ایده‌آل، اسکرام از مرحله‌ی خلق یا ایجاد مفاهیم آغاز می‌شود و در تمامی فازهای توسعه و آزمون محصول، معرفی، بازاریابی و فروش مورداستفاده قرار می‌گیرد. اما امروزه بیشتر شرکت‌ها فقط بخش «توسعه» را در تیم خود اعمال می‌کنند. اعضای این تیم‌ها باید تلاش کنند که به T-shaped برسند. این بدان معنی است که تخصص اعضای تیم اسکرام فقط به یک حوزه محدود نمی‌شود. آن‌ها باید از توانایی‌ها و مهارت‌های گسترده‌ای بهره ببرند تا بتوانند در حوزه‌های دیگر نیز به تیم و سایر هم‌تیمی‌ها خدمت کنند. البته، مسلماً منظور این نیست که اعضای تیم باید همه‌چیز را بدانند. بلکه همه آن‌ها متمایل‌اند فراتر از مسئولیت‌های خود پیش بروند و کارهای بیشتری انجام دهند.

توسعه‌ی چابک یا اجایل (Agile) روش یا تکنیکی است که فرایند توسعه و آزمون چرخه حیات توسعه سیستم (SDLC) را با یک رویکرد تکرار متوالی پیش می‌برد. درواقع اجایل، محصول را به بخش‌های کوچک‌تر تقسیم می‌کند. اسکرام، تنها یکی از فرآیندهای تکرار و تکامل فرایند تدریجی توسعه‌ی نرم‌افزار چابک است که به ما اجازه می‌دهد در کوتاه‌ترین زمان ممکن، روی ارائه‌ی ارزش کسب‌وکار تمرکز کنیم. توجه داشته باشید که چهارچوب اسکرام، معمولاً با این مسئله سروکار دارد که الزامات و نیازهای پروژه، از ابتدای کار شناخته‌شده نیستند یا در طول مسیر تغییر می‌کنند. به همین دلیل پیش از اینکه به توضیح مزایا، اصول و عناصر اسکرام بپردازیم، خلاصه‌ای از مفاهیم رویکرد چابک را برای شما شرح می‌دهیم.

تحقیقات مؤسسه‌ی مدیریت پروژه آمریکا نشان می‌دهد سازمان‌های چابک در ۶۵ درصد از موارد پروژه‌های خود را به‌موقع به پایان می‌رسانند (در مقایسه با ۴۰ درصد برای شرکت‌های غیر چابک). به‌علاوه آن‌ها به ۷۵ درصد از اهداف خود دست پیدا می‌کنند (در مقایسه با نرخ ۵۶ درصدی شرکت‌های غیر چابک) و حتی درآمد خود را حدود ۳۷ درصد سریع‌تر ارتقا می‌دهند.

در مرور ابتدایی، متوجه می‌شویم که رویکرد چابک با توسعه‌ی سریع‌تر، ارائه یا عرضه‌ی بیشتر و همچنین درآمد بیشتر همراه است. پس چرا باید در استفاده از مدیریت چابک پروژه‌ها تردید داشته باشیم؟ واقعیت این است که رویکرد چابک نیز مانند هر ابزار یا روش دیگری، از ویژگی‌های خاصی برخوردار است و شما پیش از آنکه تصمیم نهایی را در خصوص پیاده‌سازی این رویکرد اتخاذ کنید، باید ارزش‌ها و اصول آن را بشناسید.

اجایل یا چابک؛ در اصل نه یک فلسفه است و نه یک روش‌شناسی (متدولوژی). چابک، اصطلاحی برای توصیف یکی از رویکردهای مدیریت پروژه است که تغییرات تدریجی و مبتنی بر بازخورد توسعه‌ی نر افزار را اولویت‌بندی می‌کند. تا چند دهه‌ی گذشته، روش آبشاری (Waterfall) به‌عنوان رایج‌ترین رویکرد توسعه‌ی نرم‌افزار (و عموم محصولات) شناخته می‌شد. به همین دلیل هم‌ زمان و تلاش زیادی به جمع‌آوری منابع و فرایندهای برنامه‌ریزی اختصاص می‌یافت. ضمن آنکه برنامه‌ریزی‌ها، معمولاً مستلزم انبوهی از تصمیم‌هایی بودند که صرفاً براساس فرضیات اتخاذ می‌شدند.

در دهه‌ی ۷۰ میلادی، کاملاً مشخص‌شده بود که رویکرد آبشاری، فرایند کارآمد و مؤثری نیست. توسعه‌دهندگان مدرن حس می‌کردند که روش آبشاری بسیار محدودکننده و نظارت‌شده است و خیلی آهسته پیش می‌رود. در اواخر دهه‌ی ۹۰، هنگامی‌که نسل هکرها راه خود را به نیروی کار باز کردند، این زمزمه‌ها تقویت شد. درحالی‌که روش آبشاری، متکی بر پیش‌بینی و تسلسل است، توسعه‌دهندگان به یک رویکرد مدیریتی انعطاف‌پذیر نیاز داشتند که ظرفیت خطا، باگ، عقب‌گرد و دریافت بازخورد از کاربران واقعی را داشته باشد.

به همین دلیل در سال ۲۰۰۱، یک گروه ۱۷ نفره دوره هم جمع شدند تا یک راه جایگزین برای فرایندهای سنگین فعلی توسعه‌ی نرم‌افزار، که تأکید زیادی بر مستندسازی و ثبت مدارک داشت، ایجاد کنند. آن‌ها پس از مدتی کوتاه، طی بیانیه‌ای اعتقاد خود را درباره‌ی اینکه پروژه‌های نرم‌افزاری چگونه باید اجرا شود، منتشر کردند. این بیانیه Agile Manifesto یا مانیفست توسعه‌ی چابک نام دارد.

بیانیه یا مانیفست توسعه‌ی نرم‌افزاری چابک، حاوی چهار قاعده است:

• افراد و تعاملات، نسبت به فرایندها و ابزارها ارجحیت دارند.
• یک نرم‌افزار قابل‌استفاده و کارا، مهم‌تر از مستندات پیچیده و مشروح است.
• مشارکت مشتری در فرایند کار، نسبت به مذاکرات و بندهای قرارداد، در اولویت قرار دارد.
• پاسخ به تغییرات، مهم‌تر از اجرای  یک برنامه و طرح ثابت است.

قواعد بالا، به این معنی نیست که شما باید همین امروز، ابزار، مستندات و برنامه‌های زمان‌بندی‌شده‌ی پروژه را دور بریزید. همه‌ی این عناصر برای تلاش‌های توسعه‌ی پروژه ارزشمند هستند، اما ابتدا باید روی گزینه‌هایی متمرکز شوید که مانیفست چابک آن‌ها را در اولویت قرار داده،  یعنی افراد، پروتوتایپ‌ها، مشارکت و تکرار.  البته گروه ۱۷ نفره‌ای که از آن‌ها یادکردیم، فهرستی از ۱۲ اصل راهنما را نیز منتشر کردند که درک مدیریت پروژه با رویکرد چابک، کمک می‌کند:

۱- بالاترین اولویت، جلب رضایت مشتریان ازطریق تحویل سریع و ادامه‌دار نتایج عاری از خطای هر یک از بخش‌های کوچک‌تر پروژه، در فواصل زمانی کوتاه است.

۲- تغییر الزامات و نیازمندی‌های پروژه حتی در اواخر فرایند توسعه نیز مورد استقبال قرار می‌گیرد. چراکه تغییراتی که به بهبود محصول (نرم‌افزار) منجر شوند، مسلماً رضایت مشتریان را در پی خواهند داشت.

۳- ارائه‌ی زودهنگام نرم‌افزار یا محصول کاربردی در فواصل زمانی کوتاه (از چند هفته تا چند ماه)

۴- توسعه‌دهندگان و ذینفعان / مالکان نرم‌افزار باید به‌صورت روزانه با یکدیگر مشارکت داشته باشند.

۵- تیم پروژه را از افراد باانگیزه تشکیل دهید، محیط و فضای لازم برای پیشرفت را در اختیار آن‌ها قرار دهید، از آن‌ها حمایت کنید و اطمینان داشته باشید که کار را به‌خوبی تکمیل می‌کنند.

۶- جلسات و مباحثات رودررو، کارآمدترین و مؤثرترین راه برای موفقیت پروژه است.

۷- یک محصول نهایی قابل‌استفاده و کاربردی، آخرین مقیاس سنجش پیشرفت پروژه خواهد بود.

۸- فرایندهای چابک، توسعه‌ی پایدار را ارتقا می‌دهند. اسپانسرها، توسعه‌دهندگان و کاربران باید بتوانند سرعت پیشرفت ثابتی را در طول زمان (بلندمدت) حفظ کنند.

۹- توجه مداوم به مزایای فنی و طراحی خوب، رویکرد چابک را تقویت می‌کند. به عبارتی تیم چابک، همیشه از بهترین فناوری‌ها و دستاوردهای حوزه‌ی توسعه‌ی نرم‌افزار استفاده می‌کند.

۱۰- سادگی، به معنای هنر به حداکثر رساندن میزان کار انجام‌نشده، یکی از عناصر ضروری رویکرد چابک محسوب می‌شود.

۱۱- بهترین معماری‌ها، الزامات و طرح‌ها، از تیم‌هایی حاصل می‌شوند که خود-سازمان هستند، یعنی تیم‌های مستقلی که خودشان را سازمان‌دهی می‌کنند.

۱۲- در فواصل زمانی مشخص، اعضای تیم درباره‌ی این موضوع که چگونه می‌توان کارایی بیشتری داشت، تأمل و همفکری می‌کنند. سپس تیم رفتار خود را براساس نتایج گفتگوها، اصلاح می‌کند یا تغییر می‌دهد.

اگر به صنعت توسعه‌ی نرم‌افزار امروزی نگاه کنید، متوجه می‌شوید که این اصول و حتی کل رویکرد چابک، پاسخی به انتظارات سطح بالای کاربران هستند.

واقعیت این است که کاربران، اهمیتی به مستندات پروژه نمی‌دهند. آن‌ها می‌خواهند نرم‌افزاری در دست داشته باشند که خوب کار کند. طرح و برنامه‌های بلندمدت شما برای آن‌ها در اولویت نیست، بلکه آن‌ها می‌خواهند محصول خود را سریع‌تر تحویل بگیرند. آن‌ها می‌خواهند که یک باگ، «دیروز» رفع شده باشد نه طی هفته‌ی آینده یا نسخه‌ی بعدی نتایج.

چیزی که تا این بخش مشاهده کردیم، صرفاً لایه‌ی بیرونی یا ظاهر رویکرد چابک است که طبیعتاً فوق‌العاده به نظر می‌رسد. اما همان‌طور که قبلاً گفتیم، رویکرد مدیریتی چابک برای همه‌ی پروژه‌ها سودمند نیست. چرا؟ رویکرد چابک، ممکن است به معنای جدایی از همه‌ی فرایندهایی باشد که تیم یا سازمان شما، به آن‌ها خو گرفته است. اجایل یعنی حرکت سریع. بنابراین در این رویکرد همه‌چیز از قبل تنظیم و برنامه‌ریزی نمی‌شود. آیا محیط فعلی تیم شما می‌تواند چنین تغییراتی را تاب بیاورد؟ پنج سؤال زیر به شما کمک می‌کنند پاسخ درست را بیابید.

احتمالاً تابه‌حال اصطلاح «سریع شکست خوردن» را شنیده‌اید. این اصطلاح به رویکرد چابک اشاره دارد. شما در این روش، سریع حرکت می‌کنید و نتایج را به‌طور مداوم، با کاربران واقعی آزمایش می‌کنید. اگر عادت دارید که همیشه همه‌چیز را تحت کنترل داشته باشید، رویکرد چابک استرس زیادی به شما وارد می‌کند. قبل از اینکه رویکرد چابک را بپذیرید، از خودتان بپرسید که آیا حاضرید نسخه‌ی پایین‌تر از نسخه‌ی نهایی محصول را با کاربران واقعی تست کنید؟ آیا راه‌اندازی یک MVP (حداقل محصول پذیرفتنی) به شما احساس خوبی می‌دهد؟ یا فکر می‌کنید پیش از آنکه محصول خود را معرفی کنید، باید پروژه را کاملاً تکمیل کرده و محک زده باشید؟

همان‌طور که اشاره شد، رویکرد چابک براساس «اجرا و پیاده‌سازی مداوم و یادگیری از اشتباهات» پیش می‌رود. پس شما نسبت به رویکردهای سنتی، با سطوح بالاتر خطرپذیری مواجه هستید.

در رویکرد چابک، شما مرتباً با مشتریان خود همفکری می‌کنید تا محصول را بهبود دهید. مسئله اینجا است که همه‌ی توسعه‌دهندگان، طراحان و سازندگان، از خودبینی کم یا زیادی برخوردار هستند. آیا بازیگران کلیدی تیم شما می‌توانند احساس شخصی خود را کنار بگذارند و تلاش و ایده‌های خود را با نیازهای مشتری سازگار کنند؟

تعاملات مداوم روش چابک، صرفاً به ارتباط با کاربران و مشتریان محدود نمی‌شود. توسعه‌دهندگان محصول نیز باید هرروز با ذینفعان و مالکان پروژه در ارتباط باشند. این روند در صورتی امکان‌پذیر است که در فرهنگ‌سازمانی شما، سلسله‌مراتب غیرقابل‌دسترس و سختی وجود نداشته باشد.

درنهایت همان‌طور که دیدیم، مدیریت پروژه‌ی چابک دائماً تلاش می‌کند تا فرایندهای خود را بهبود دهد و محصول را بهتر کند. بنابراین اگر تیم یا رهبر پروژه، از ایده‌های هیجان‌انگیز جدید استقبال نمی‌کند، باید کمی دست نگه‌دارید. از خودتان بپرسید که فرهنگ‌سازمانی شما، موفقیت و پیشرفت را چگونه تعریف می‌کند؟ آیا می‌توانید قدم‌های کوچک و پایداری که شما را به هدف نهایی نزدیک‌تر می‌کند، ببینید؟

رویکرد چابک، ترکیبی از برنامه‌ریزی و اجرای مداوم، یادگیری دائمی و تکرار است. بااین‌حال یک پروژه‌ی پایه‌ی چابک را می‌توان به هفت مرحله تقسیم کرد:

درواقع شما باید علت کار خود را توضیح دهید، زیرا در طول مسیر پروژه، بارها به این عقیده‌ی اصلی مراجعه می‌کنید. به‌علاوه اعضای تیم باید هدف نهایی و علت تلاش‌های خود را بدانند. برای شرکت‌های تولیدی، سخنرانی آسانسوری یا Elevator Pitch یکی از بهترین راه‌های تعریف چشم‌انداز است:

مشخص کنید که چه افرادی، چه محصولی (نام محصول، دسته‌بندی محصول) را برای چه کسی (مشتری هدف) توسعه می‌دهند. چه جایگزین‌هایی (رقبا) برای محصول شما وجود دارد، محصول شما چه مشکلاتی را حل می‌کند و مزایای آن چیست.

همه‌ی ذینفعان کلیدی ازجمله مدیران و مسئولان اجرایی، مالکین پروژه و اعضای تیم باید در جلسه‌ی معرفی چشم‌انداز حضورداشته باشند.

تفاوت رویکرد چابک را در این مرحله به‌راحتی مشاهده می‌کنید: قرار نیست شما ساعت‌ها وقت بگذارید تا هر گام از مسیر را برنامه‌ریزی کنید. کافی است که تلاش‌های لازم برای تکمیل هر بخش یا قسمت از محصول را شناسایی و اولویت‌بندی کنید، به‌طوری‌که با کنار هم گذاشتن یا ترکیب این بخش‌های کوچک، به یک محصول نهایی قابل‌استفاده برسید.

برای مشخص کردن هر یک از بخش‌های کوچک پروژه، پنج اطلاعات کلیدی را وارد کنید: تاریخ، نام، هدف، ویژگی‌ها (فیچرها) و متریک. مزیت نقشه‌ی راه محصول این است که شما ایده‌ی واضحی از «چه‌کاری، چه زمانی، چگونه» و همچنین راه سنجش پیشرفت به دست می‌آورید.

ازآنجاکه پروژه‌های چابک؛ نتایج متعددی را در مراحل مختلف ارائه می‌دهند و به عبارتی از چندین نسخه برخوردار هستند، ویژگی‌هایی که باید زودتر و در نسخه‌های اولیه ارائه شوند، اولویت‌بندی می‌شوند. به‌عنوان‌مثال اگر پروژه‌ی شما در ماه مهر راه‌اندازی می‌شود، می‌توانید MVP خود را برای اوایل ماه بهمن تنظیم کرده و ویژگی‌های اولویت بالا را در ماه اردیبهشت ارائه کنید. البته این فواصل، به پیچیدگی پروژه‌ی شما و طول اسپرینت‌ها (دوره‌های کار اختصاص داده‌شده به هر هدف) بستگی دارد. انتشار هر محصول معمولاً سه تا پنج اسپرینت را شامل می‌شود. در قسمت آینده‌ی آموزش اسکرام، از مفهوم اسپرینت بیشتر صحبت می‌کنیم.

در این مرحله از نمای ماکرو، به میکرو حرکت می‌کنید. تیم توسعه و مالک محصول، اسپرینت‌ها را برنامه‌ریزی می‌کنند. یک اسپرینت، چرخه‌ی کوتاه‌مدت توسعه است که در آن وظایف و اهداف خاصی دنبال می‌شود و معمولاً بین یک تا چهار هفته طول می‌کشد. طول اسپرینت‌ها باید در تمام مراحل پروژه یکسان بماند. در این صورت تیم می‌تواند باتوجه‌به عملکرد گذشته‌ی خود، کارهای آینده‌ی خود را با دقت بیشتری برنامه‌ریزی کند.

در ابتدای هر اسپرینت، تیم فهرستی از کارهای ناتمام ایجاد می‌کند. این کارها باید در بازه‌ی زمانی تعیین‌شده، قابل‌تکمیل باشند و به شما اجازه دهند یک محصول نرم‌افزاری قابل‌استفاده را توسعه دهید. سپس شما می‌توانید با استفاده از یکی از روش‌های چابک؛ که در ادامه‌ی مطلب معرفی می‌شوند، روی فهرست کارکنید.

در طول هر اسپرینت، شما به فرصت‌هایی نیاز دارید که مطمئن شوید موانع و انحرافاتی در مسیر رسیدن به انحراف وجود ندارد. جلسات روزانه‌ای که اعضای تیم در حالت ایستاده باهم گفت‌وگو می‌کنند، همان فرصتی است که به کمک شما می‌آید. در طول این جلسات ۱۵ دقیقه‌ای، تیم درباره‌ی سه موضوع بحث می‌کند: دیروز چه کردید؟ امروز روی چه چیزی کار می‌کنید؟ آیا مانعی بر سر راه حرکت تیم وجود دارد؟ توجه داشته باشید که جلسات ایستاده، برای تقویت ارتباطات خاصی که مدیریت پروژه چابک را هدایت می‌کند ضروری هستند.

اگر تا این مرحله درست پیش رفته باشید، در پایان سیکل اسپرینت شما یک قطعه‌ی کاربردی از نرم‌افزار را در اختیاردارید. حالا باید آنچه انجام‌شده را با تیم و سایر ذینفعان کلیدی، مرور و بررسی کنید. کلید اصلی این است که برنامه‌ی اولیه‌ی خود را مرور کنید تا مطمئن شوید همه‌ی الزامات برآورده شده است. مالک محصول می‌تواند برخی از عملکردهای محصول را بپذیرد یا رد کند. مهم این است که اگر چیزی اشتباه پیش می‌رود، علت آن را بپرسید. چگونه می‌توانید اسپرینت بعدی را به شیوه‌ای تنظیم کنید که تیم، به اهداف مطلوب دست پیدا کند؟ در رویکرد اجایل، همه‌چیز به یادگیری مداوم و تکرار بستگی دارد و این امر شامل فرایندها و محصول شما نیز هست.

در مدیریت چابک پروژه، شما باید پس از برداشتن هر قدم، قدم بعدی خود را به‌طور روش بدانید. وقتی یک اسپرینت تکمیل‌شده و ویژگی‌های آن معرفی و بررسی‌شده‌اند، باید تصمیمی بگیرید که در مرحله‌ی بعد چه‌کاری انجام می‌دهید. هرچند این تصمیم به‌سرعت اتخاذ می‌شود، ولی باید به‌اندازه‌ای وقت بگذارید که بدانید از اسپرینت قبلی چه درس‌هایی می‌گیرید و در آینده چگونه آن را بهبود می‌دهید.

در سال ۱۹۹۹ کنت بک، یکی از هفده خالق توسعه‌ی نرم‌افزاری چابک، در کتاب برنامه‌نویسی مفرط رویکرد توسعه‌ی نرم‌افزار خود را توضیح داد. روش XP نسبت به اسکرام، تمرکز بیشتری بر نحوه‌ی نوشته شدن کدها و تست‌ها دارد.

هرچند کاربرد XP بسیار کمتر از اسکرام است، اما برخی از روال‌های آن مورد استقبال توسعه‌دهندگان قرارگرفته است، مانند برنامه‌نویسی دونفره، توسعه‌ی آزمون محور و ادغام یکپارچه یا مستمر.

کانبان نیز مانند اسکرام روی تحویل مداوم نتایج متمرکز است و درعین‌حال همه‌ی فرایندها را ساده نگه می‌دارد و حجم کار زیادی را به تیم توسعه تحمیل نمی‌کند. سه اصل روش کانبان عبارت‌اند از:

• تصویرسازی جریان کار روی یک بورد
• محدود نگه‌داشتن حجم کاری که در حال اجرا است.
• وضوح بخشیدن به قدم‌های بعدی

اسکرام شناخته‌شده‌ترین روش توسعه‌ی چابک است و به‌لطف سادگی، کارایی اثبات‌شده و قابلیتی اجرای شیوه‌های مختلف دیگر روش‌های چابک، به‌به‌ویژه در دنیای توسعه نرم‌افزار بسیار محبوب است. در این روش، مالک محصول با تیم خود به‌خوبی کار می‌کند تا اهداف یا ویژگی‌های آن‌ها را شناسایی و اولویت‌بندی کند و این موارد را به چیزی که Backlog محصول نامیده می‌شود،  اضافه کند. بک‌لاگ‌ها می‌توانند ویژگی‌های، رفع باگ یا الزامات غیرکاربردی را شامل شوند، یعنی تقریباً هر چیزی که باید انجام شود تا یک نرم قابل‌استفاده و کاربردی آماده شود.

توسعه‌ی ناب و کریستال، دو تکنیک دیگر رویکرد چابک هستند که در فرصت مناسب به آن‌ها خواهیم پرداخت.

در این مطلب سعی کردیم شما را با اصول و قواعد و کلیات رویکرد چابک آشنا کنیم، زیرا این نکات پیش‌نیاز قسمت‌های آینده‌ی آموزش اسکرام محسوب می‌شوند. هفته‌ی آینده، از مزایا و معایب، اصول و نقش افراد در اسکرام صحبت می‌کنیم.