بیشک اسکرام را میتوان محبوبترین روش پیادهسازی الگوی چابک در بین شرکتهای کوچک و تیمهای نرمافزاری و بهویژه استارتاپها دانست. دلیل روشن است، این روش مجموعهای از دستورالعملهای اجرایی برای انجام کار و پیادهسازی پروژهها به تیمها میدهد که قرار است به آنها برای مدیریت تیم و توسعه مناسب و بهینه نرمافزار کمک کند. این روش بهویژه مطلوب مدیران پروژه و مدیران فنی شرکتها است؛ اما در عمل، این روش چقدر به بهبود عملکرد تیمی و افزایش چابکی شرکتها کمک میکند؟
مقدمه
چابکی در توسعه نرمافزار به مجموعهای از روشها و الگوهای گفته میشود که هدفشان توسعه نرمافزار در دورههای چرخشی و ایجاد تعامل بین تیم توسعه نرمافزار و بخش کسب و کار، برای توسعه نرمافزار کاربردیتر گفته میشود. روشهای استفاده شده در این مجموعه حاصل تجربیات برتری است که قرار است به توسعه سریعتر نرمافزار، با انعطافپذیری بالاتر و سرعت پاسخگویی بیشتر به تغییرات کمک کند. اصول چابکی در توسعه نرمافزار توسط 14 نفر از افراد پیش رو در زمینه توسعه نرمافزار، در قالب بیانیه چابکی[1]، و اصول پشت آن[2]، در سال 2001 بیان شدند. هرچند مفهوم چابکی در سازمان پیش از آن نیز مطرح بود. بحث ما در این مقاله حول چابکی در توسعه نرمافزار قرار دارد.
اسکرام در بیان عمومی یک فرآیند کنترل و مدیریت پروژه است که پروژههای بزرگ را در قالب بخشهای کوچکتر و در دورههای تکراری انجام میدهد. روش اسکرام در توسعه پروژههای نرمافزاری (که مورد نظر این نوشته است)، یک روش پیادهسازی چابکی در تیم است که با استفاده از مجموعهای از فرآیندها و ابزار و نقشها، قرار است به تیم توسعه نرمافزار در بهبود سرعت و عملکرد کارشان کمک کند.
روش اسکرام به روشی بسیار محبوب برای توسعه نرمافزار، چه در شرکتهای کوچک، و چه در شرکتهای بزرگی که کار خود را در قالب تیمهای مختلف انجام میدهند، بدل شده است. افراد، بهویژه مدیران پروژه، که در بسیاری از اوقات روش اسکرام را معادل چابکی میدانند، تمایل زیادی به استفاده از این روش دارند، که در نظرشان قرار است سرعت و بهینگی و انعطافپذیری کار تیمشان را بالا ببرد. اما آیا در عمل این اتفاق میافتد؟
اسکرام چگونه کار میکند؟
هرچند انتظار میرود که پیش از مطالعه این مقاله با روش اسکرام آشنایی داشته باشید، در ادامه نگاهی کلی و گذرا به اسکرام انجام میشود.
در روش اسکرام، کار به صورت مجموعهای از دورههای تکرار شونده، یا اسپرینت، انجام میشود. اسپرینتها غالبا یک یا دو هفتهای هستند (بسته به تیم و نوع کار). در ابتدای هر اسپرینت، با حضور افراد تیم، اسکرام مستر، مدیر پروژه که گاهی نقش اسکرام مستر را نیز بر عهده دارد، و مالک محصول (یا نماینده مالک محصول)، جلسه برنامهریزی اسپرینت برگزار میشود. در طول این جلسه بخشی از نرمافزار که قرار است در اسپرینت پیش رو انجام شود در قالب مجموعهای از استوریها (بکلاگ اسپرینت) مشخص میشود. سپس این استوریها بین افراد تیم تقسیم میشوند و برای هرکدام تخمین زمانی انجام میشود. این استوریها در قالب کارتهایی در یک تخته واقعی یا مجازی، موسوم به تسکبورد، ثبت میشوند تا بتوان پیشرفت کار را با جابجایی این استوریها در این تخته، بین وضعیتهای مختلف (انجام نشده، در حال انجام، انجام شده، پایان یافته و …) بررسی کرد.
با شروع اسپرینت، افراد تیم شروع به انجام وظایف خود میکنند. در پایان یا آغاز هر روز، در طول جلسات روزانه، افراد در مورد روند انجام کار خود، به باقی تیم توضیح میدهند. (معمولا با پاسخ به سه سوال 1.امروز چه کردید؟ 2.فردا چه میکنید؟ 3.در طول کار چه مشکلاتی دارید؟). در طول این جلسات، تسکبورد بهروزرسانی میشود و استوریها در ستونهای مربوطه جابجا میشوند.
در پایان هر اسپرینت نیز جلسه ارائه دمو برگزار میشود که در آن کار انجام شده برای بررسی و گرفتن بازخور به مشتری یا نماینده او ارائه میشود، و در پایان نیز عملکرد تیم و افراد بررسی میشود.
آیا اسکرام یک روش چابک است؟
به نظر یافتن یک تعریف مورد توافق از چابکی کار آسانی نیست. بعضی چابکی را درگرو پایبندی به برخی اصول میدانند و برخی آن را افزایش انعطافپذیری و سرعت پاسخگویی و بهینگی تیم/سازمان میدانند؛ اما برای اینکه بتوانیم پایهای برای بررسی چابکی داشته باشیم، میتوانیم به بیانیه چابکی که ویژه توسعه نرمافزار است رجوع کنیم:
بیانیهٔ توسعه نرمافزار چابک
ما با توسعه نرمافزار و کمک به دیگران در انجام آن،
در حال کشف راههای بهتری برای توسعه نرمافزار هستیم.
از این طریق باید دست یابیم به ارزش:
افراد و تعاملات بالاتر از فرآیندها و ابزارها
نرمافزار کارکننده بالاتر از مستندات جامع
مشارکت مشتری در انجام کار بالاتر از قرارداد کار
پاسخگویی به تغییرات بالاتر از پیروی یک طرح
با وجود اینکه موارد سمت چپ نیز ارزشمند هستند ولی
ما برای موارد سمت راست ارزش بیشتری قائل هستیم[3]
بیانیه چابکی چهار بند برای ما بیان میکند که اصول پشتشان تعامل با مشتری، سرعت بالای پاسخگویی به تغییرات، تعامل درون تیمی، تکیه بر خلاقیت مشتریان، سادگی و … میباشد.[4]
اسکرام، یکی از معروفترین روشهای پیادهسازی چابکی است که دارای امکان شخصیسازی بالا است. با این حال این روش غالباً دارای بخشهای زیر است که کم و بیش اجرا میشوند: برگزاری جلسات اسپرینت در هر هفته یا دو هفته یک بار،ایجاد یک تسکبورد برای تخصیص و بهروزرسانی وظایف، برگزاری جلسات روزانه برای آگاهی افراد از وضعیت پیشرفت کار و ارائه دمو در هر اسپرینت میباشد.
در نظر اول، این مراحل و اقدامات روشهای خوبی برای تعامل بین تیمی، تعامل با مشتری و مدیریت پروژه فراهم میکنند؛ اما آیا در عمل همچنین است؟ اجازه دهید که بخشهای مختلف اسکرام را بررسی کنیم تا ببینیم که چطور میتوانند مانعی برای بازدهی کار تیمی باشند:
استفاده از اسکرام
کلیت استفاده از اسکرام در تیم/شرکت با چالشهای بزرگی همراه است. یکی از مهمترینها، هزینه سربار زیاد آن است. برگزاری جلسات طولانی برای آغاز و پایان اسپرینت، جلسات روزانه و به روز نگه داشتن تسکبورد، مهمترین هزینههای پیادهسازی هستند. از طرف دیگر پیادهسازی اولیه این روش در سازمان نیاز به یادگیری و آموزش آن در تیم، گاها کمک گرفتن از افراد خارجی، همگام کردن افراد جدید تیم با الگوی کار فعلی و … همگی مواردی هستند که پیادهسازی اسکرام را دشوار و هزینهبر میکنند. مسئول پیادهسازی اسکرام در سازمان باید نخست از خود بپرسد که آیا پیادهسازی اسکرام، ارزش این هزینهها را خواهد داشت؟
از دیگر مشکلات پیادهسازی اسکرام، همراهی تیم است. افراد تیم غالباً به اسکرام به چشم مجموعهای از دستورالعملهای وقتگیر و پر دردسر نگاه میکنند که برای آنها تنها مانع انجام کار به شکل دلخواهشان است و صرفاً روشی مورد علاقه مدیران پروژه است تا بتواند کار خود را آسانتر انجام دهد و نظارت بیشتری به تیم داشته باشد.
جلسات اسپرینت
در این جلسات قرار است که اعضای تیم با مشارکت یکدیگر و نقش فعال مدیر پروژه و یا اسکرام مستر، کارهایی که قرار است در اسپرینت پیش رو انجام شود را تعریف کنند و وظایف یا استوریها را به افراد تخصیص دهند. هدف این جلسات پیادهسازی دو مورد از مهمترین اصول چابکی است: تولید نرمافزار در دورههای چرخشی و ایجاد تعامل تیمی.
جلسات اسپرینت چند مشکل اساسی دارند. اول اینکه آنها وقتگیر هستند و میتوانند تا چند ساعت وقت کل تیم را بگیرند. مخصوصاً اگر اسپرینتهای کوتاه داشته باشیم، مثلاً یک هفتهای. از طرف دیگر اگر طول اسپرینتها طولانی شود، انعطافپذیری و قدرت پاسخگویی تیم به تغییرات کاهش مییابد.
مشکل دیگر درباره جلسات اسپرینت این است که این جلسات ممکن است به جای اینکه شکلی تیمی داشته باشند، با مرکزیت مدیر پروژه/اسکرام مستر اجرا شوند. در این صورت در طول این جلسات تنها این مدیر یا اسکرام مستر است که وظایف را تعریف میکند و به افراد تخصیص میدهد. این مساله نه تنها روحیه تعامل تیمی را افزایش نمیدهد، بلکه قاتل آن است.
از دیگر مسائلی که در مورد جلسات اسپرینت مشکلزا است، وجود شرایط عدم اطمینان میباشد. همانطور که پیشتر اشاره شد، اسپرینتهای طولانی میتوانند انعطافپذیری و سرعت پاسخگویی تیم را کاهش دهند. اگر سرعت تغییرات شرایط پروژه زیاد باشد و یا میزان ابهام در آن بالا باشد، تعریف دقیق استوریها برای آنها بسیار وقتگیر، دشوار و غیر دقیق خواهد بود. این مساله میتواند هم در طول جلسه اسپرینت و هم در طول انجام کار، مانعی بزرگی در راه تیم باشد.
جلسات روزانه
یکی دیگر از موارد اصلی اسکرام، برگزاری جلسات روزانه با حضور اعضای تیم، برای آگاهی از وضعیت پیشرفت کار است. هدف، برگزاری جلسات کوتاه (حداکثر 15 دقیقهای) است که تکتک اعضای تیم آن به این سه سؤال پاسخ میدهند:
- امروز چه کردید؟
- فردا چه کاری انجام خواهید داد؟
- در طول انجام کار به چه مشکلاتی برخوردید؟
هدف این جلسات این است که وضعیت پیشرفت کار بررسی شود (معمولاً در حین یا پس از پایان این جلسه تسکبورد به روز میشود)، افراد در جریان کار یکدیگر قرار بگیرند و مشکلات احتمالی شناسایی و رفع شود.
اما جلسات روزانه در عمل چه دستاوردهایی دارند؟ مهم نیست که اسکرام مستر چقدر تلاش کند که طول این جلسات را کنترل کند، این جلسات در عمل بسیار بیشتر از 15 دقیقه وقت تیم را میگیرند. افراد باید کار خود را متوقف کنند، همگی جمع شوند و پس از پایان جلسه سراغ کار خود برگردند. این جلسات به راحتی میتوانند نیم ساعت از کار تیم را متوقف کنند و این جدا از به هم ریختن تمرکز افراد است. این مساله بهویژه در مورد تیمهایی که همگی یکجا جمع نیستند (مثلاً تمام یا بخشی از افراد دورکاری میکنند) یا ساعت کاری افراد تیم باهم هماهنگ نیست (که این دو مورد مخصوصاً در مورد تیمهای استارتاپی بسیار متداول است)، میتواند بسیار دردسر آفرین تر باشد.
مشکل دیگر جلسات روزانه این است که این جلسات به راحتی میتوانند قاتل روحیه افراد باشند. فرض کنید که یک برنامهنویس تمام روز را مشغول بررسی و رفع یک باگ پر دردسر بوده است (اگر با برنامهنویسهای تیمتان صحبت کنید، میدانید که چنین موردی ابداً نادر نیست!). حال در پایان روز این فرد باید مقابل تمام افراد تیم و مهمتر از همه، اسکرام مستر بگوید که در روز جاری دستاورد خاصی نداشته و در مورد برنامه فردا هم نمیتواند حرف مشخصی بزند. از سوی دیگر بیان مشکل مذکور میتواند به راحتی آغازگر یک بحث تخصصی طولانی بین افراد فنی تیم شود که جلسه را از دست خارج میکند. حال روحیه فرد مذکور را تصور کنید، او باید بین سایر افراد بیان کند که دستاوردی نداشته است. این ابداً برای افراد خوشایند نیست. مخصوصاً اگر اسکرام مستر تأکید زیادی روی پیشرفت کار از روی برنامه داشته باشد. این مساله به راحتی میتواند باعث شود که افراد به جای بیان واقعیت، شروع به توصیفهای طولانی و نادقیق از کارشان کنند تا از توبیخ رسمی یا غیررسمی فرار کنند.
یکی دیگر از مشکلات جلسات روزانه این است که حتی برای افرادی که در یک تیم کار میکنند، خیلی اوقات جزییات برهی کارها میتواند نامربوط باشد. فرض کنید طراح گرافیک تیم، باید به صحبتهای فنی دو برنامهنویس در مورد یک مشکل تخصصی گوش کند. این مساله چقدر برای تیم مفید است؟
مشکل دیگر درباره این جلسات، وجود حس نظارت است. افراد تیم به خاطر این جلسات حس میکنند که زیر ذرهبین اسکرام مستر و سایر اعضای تیم هستند. این مساله میتواند به راحتی خلاقیت افراد را از بین ببرد، زیرا افراد وقتی تحت نظر باشند نمیتوانند با آرامش و راحتی خلاقیت و نوآوری به خرج دهند.
تسکبورد
ایجاد یک لیست از وظایف یا استوریها که قرار است در طول اسپرینت انجام شود و به روز شود، میتواند معیار خوبی از پیشرفت کار به مدیر پروژه دهد. برای مدیران پروژه، چه چیز جذابتر از این؟! اما آیا واقعاً این اتفاق میافتد؟
استوریها در واقعیت نمیتوانند معیار کاملی برای بررسی روند کار باشند. زمان لازم برای انجام استوریهای بسیار متفاوت است. از کمتر از نیم ساعت تا چندین ساعت. پس چیزی که شما روی تسکبورد به صورت بصری میبینید میتواند بسیار گمراهکننده باشد. از سوی دیگر تخمین دقیق زمان لازم برای استوریها میتواند بسیار دشوار باشد. از سوی دیگر معمولاً تعداد یا جزییات استوریها هم در طول اسپرینت تغییرات زیادی دارد. این مساله باعث میشود که تسکبورد در طول انجام کار تغییرات بسیار زیادی داشته باشد و عملاً قابل تکیه نباشد.
تأکید زیاد مدیر پروژه بر وفادار ماندن به تسکبورد و بهروزرسانی رسانی مداوم آن، باعث خواهد شد که فشار زیادی به افراد تیم وارد شود، زمان و تمرکز آنها برای انجام این کار تلف شود و درنهایت تخمینهای نادقیق بیشتر شود. کسی دوست ندارد که کارش بیشتر از میزان تخمین زده شده طول بکشد، پس چه بهتر است که تخمینها با دامنه بسیار بالا زده شوند که این اتفاق نیفتد!
ارائه دمو
این مورد خاص خیلی مرتبط به اسکرام نیست و به صورت عمومیتر به چابکی برمیگردد. همانطور که در ابتدا گفته شد، یکی از اصول چابکی ارائه دمو در بازههای کوتاه به مشتری است. این کار باعث میشود که ابهام کار کاهش یابد و درنهایت کار به چیزی که واقعاً مورد نیاز مشتری است نزدیکتر شود. این مساله بسیار خوب است، اما میتواند مشکلاتی داشته باشد. در واقع دموهای ارائه شده به مشتری میتوانند تیم را در یک دام بزرگ بیاندازند: انتظارات خارج از برنامه.
هدف اصلی ارائه دمو به مشتری در واقعاین است که برنامه اولیهای که برای پروژه در نظر گرفتهشده است، در طول انجام کار و با رفع ابهامات، اصلاح شود. این مساله باعث میشود که انتظارات قدیمی که در مورد پروژه زده شده بود تغییر کند و مواردی به آن اضافه یا حذف شود. معمولاً تمایل مشتریان به اضافه کردن موارد جدید بیشتر است، زیرا با تحویل گرفتن کار، تازه موارد زیادی که قبلاً فکرش را نکرده بودند برایشان روشن میشود.
خوب، این مورد در عمل بسیار عالی است. مشتری ما محصولی کامل و مناسب تحویل میگیرد. این یکی از اهداف اصلی چابکی است؛ امااین مساله چطور میتواند برای ما مشکلساز باشد؟ یک مساله بسیار مهم که به پیش از شروع پروژه بازمیگردد: قرارداد کاری.
تیمهایی که کارشان را بر اساس روشهای چابک انجام میدهند، اغلب، قراردادهای خود را بر اساس روش سنتی تنظیم میکنند. به این شکل که مجموعهای از نیازمندیها و انتظارات برای پروژه تعریف میشود که انجام پروژه منوط به انجام آنها است. در پایان کار، مشتری با تطبیق موارد تحویل داده شده با موارد موجود در پروژه، تکمیل یا عدم تکمیل پروژه را تعیین میکند. حال اگر در طول انجام کار، موارد جدید دیگری به پروژه اضافه شود، چه اتفاقی میافتد؟ متأسفانه غالباً در قراردادها این مورد به خوبی پیشبینی نشده است و کارهای اضافهای که توسط تیم انجام شده است، هرچند به درخواست مشتری، جزو قرارداد دیده نمیشود. نتیجه: پروژه به خاطر خزش از حیطه، با زمان و هزینه بیشتر انجام میشود و از طرف شرکت، یک پروژه شکست خورده محسوب میشود، حتی اگر مطلوب مشتری باشد.
برای حل این مشکل، در هنگام بستر قرارداد حتماً باید مکانیزمیبرای تغییرات و موارد اضافه در نظر گرفته شود و در طول انجام کار نیز تیم کسب و کار در کنار تیم فنی، در جریان تغییرات مورد انتظار مشتری باشند و در صورت نیاز حتی قرارداد را به روز کنند.
بازگشت به سؤال اول
خوب، حال با توجه به موارد مطرح شده، باید ببینیم آیا اسکرام یک روش چابک هست یا نه. بیایید بررسی را با توجه به چهار بند بیانیه چابکی انجام دهیم و ببینیم که اسکرام، چقدر به این اصول پایبند است:
- افراد و تعاملات بالاتر از فرآیندها و ابزارها: اسکرام برای ایجاد تعامل بالا بین افراد، مجموعهای از فرآیندها (مانند جلسات اسپرینت و روزانه) یا ابزار (مانند تسکبورد)ایجاد کرده است؛ اما در عمل چه اتفاقی میافتد؟ تمرکز تیمها روی پایبندی به این ابزار آنقدر زیاد میشود که هدف آنها را فراموش میکنند. در واقع نقض بند اول!
- نرمافزار کارکننده بالاتر از مستندات جامع: چیزی که به نظر میرسد این است که مستندات، توانستهاند با زیرکی خود را در قالب استوریهای ها و کارتهای تسکبورد وارد اسکرام کنند! تأکید بسیار بالای برخی مدیران پروژه یا اسکرام مسترها به ثبت دقیق و مداوم کارتها و بهروزرسانی بورد، در واقع شکل دیگر از مستند نویسی مشکلساز را وارد کار تیم میکند.
- مشارکت مشتری در انجام کار بالاتر از قرارداد کار: به نظر میرسد که در این مورد اسکرام به خوبی میتواند به چابکی وفادار باشد.
- پاسخگویی به تغییرات بالاتر از پیروی یک طرح:این مورد هم بسیار به روش کار مدیر پروژه بستگی دارد. آیا مدیر پروژه اعتقاد دارد که اسپرینتها باید حتماً به آن شکل که در جلسه آغازین آن پیشبینی شدهاند پیش بروند و انجام شوند؟ اگر این چنین باشد، در واقع مشکل عدم انعطافپذیری، هرچند با روش اسکرام تا حد خوبی حلشده است، اما همچنان در مقیاس کوچکتری وجود دارد.
آیا باید اسکرام را کنار بگذاریم؟
با توجه به این موارد مطرح شده، به نظر میرسد که اسکرام، میتواند در تضاد با چابکی بوده و روحیه افراد، تعاملات، خلاقیت، انعطافپذیری و … را در تیم ما نابود کند. خوب، آیا این به این معنی است که باید اسکرام را کنار بگذاریم؟
موارد و ایراداتی که در مورد اسکرام مطرح شد، در واقع مربوط به روشهای متداول استفاده از آن است و در عمل قابل کنترل است. جلسات اسپرینت اگر به درستی انجام شوند، به خوبی میتوانند الگوی تکرارشونده موردنظر در چابکی را اجرا کنند و آغازگر خوبی برای مشارکت افراد تیم در کار و افزایش همدلی آنها باشند. جلسات روزانه میتوانند باعث شوند که افراد بهتر در جریان کار باشند و مدیر پروژه بهتر بتواند برنامه کار را کنترل کند. تسکبورد میتواند به افراد حس بهتری از انجام کار بدهد و …
اسکرام برای بیشتر تیمها همچنان میتواند یک روش کاری بسیار مناسب باشد، اما اجرای آن باید با درک مناسب باشد تا مشکلات مطرح شده در بالا حذف شود یا دستکم به حداقل برسد. در نظر داشتن موارد زیر برای اجرای اسکرام میتواند بسیار مفید باشد:
اسکرام باید یک روش چابک باشد! در واقعاین مساله ریشه بیشتر مشکلات است. بیشتر افراد به درستی نمیدانند که اسکرام تنها روشی برای پیادهسازی چابکی است و پیش از استفاده از آن، خود چابکی باید توسط افراد تیم درک شده باشد. افراد تیم، بهویژه مدیر پروژه و اسکرام مستر باید بدانند که هدف استفاده از اسکرام، بالا بردن سرعت پاسخگویی، کاهش هزینههای نا لازم، بالا بردن انعطافپذیری، افزایش تعاملات تیمی و … است. وقتی این درک به خوبی جا بیفتد، در اجرای اسکرام، بسیاری از ایرادات میتواند رفع شود.
اسکرام یک بسته آماده نیست! یکی از ویژگیهای مهم اسکرام، انعطافپذیری بالای آن در اجرا است. هر تیم میتواند بسته به نیاز خود، شکلی برای پیادهسازی آن پیدا کند. روش پیشنهادی من برای اجرای اسکرام در تیم شما، اجرای مرحلهای آن است. اجازه دهید تیمتان کارش را به شکل طبیعی انجام دهد و سپس با تعامل با افراد تیم، اسکرام را به شکل مناسب تیمتان و بهمرور پیادهسازی و اصلاح کنید. به این شکل، جدا از اینکه شما میتوانید بخشهای زائد اسکرام را از تیم خود حذف کنید و به ترکیبی مناسب و کارا برسید، همدلی تیم برای پیادهسازی آن هم بالا میرود.
تعاملات تیم را بهتر کنید جلسات روزانه را از حالت خشک و سه سؤالی خارج کنید. در صورت نیاز میتوانید حتی آن را به یک روز در میان کاهش دهید (واقعاً چقدر نیاز به برگزاری جلسه در هر روز دارید؟). شاید اینکه افراد تنها به حالا کلی و طبیعی از وضعیت کارشان صحبت کنند بهتر باشد. ضمناً مرکزیت جلسه نباید روی شخص خاصی مانند اسکرام مستر باشد. افراد باید رو به تمام تیم صحبت کنند، نه فقط یک شخص خاص.
تعامل افراد تیم باید در حالت طبیعی و بیرون از جلسات بیشتر باشد. به عنوان مثال سعی کنید افراد درگیر در وظایف مرتبط با یکدیگر را در یک محیط و کنار هم قرار دهید تا بتوانند وظایفشان را با همکاری بالاتر در طول روز انجام دهند.
حساسیت روی تسکبورد را کاهش دهید باور کنید یا نه تعداد کارتهای جابجا شده روی تسکبورد، در عمل معیار کاملی برای بررسی پیشرفت کار و افراد نخواهد بود. تأکید بسیار زیاد روی آن شما را به ارزیابیهای اشتباه میرساند. از شروع کار با یک تسکبورد کامل میتواند ناممکن باشد. کار را با استوریهای کلیتر شروع کنید و از افراد بخواهید استوریهای خود را کاملتر کنند. ضمنان نیازی به وارد کردن تمام وظایف در تسکبورد نیست. این کار مزاحم عملکرد افراد است. از آنها بخواهید که مثلاً تنها وظایفی که بیشتر از دو ساعت زمان میخواهد.
ضمناً این نکته را هم در نظر داشته باشید که خلاقیت، با تمام خوبیهایش، هزینه هم دارد. هرچند روشهای خلاقانه میتوانند مشکلات بسیاری را حل کنند و هزینه زمانی و اجرایی کارها را در بسیاری از زمانها کاهش دهند، اما از سوی دیگر در برخی موارد ممکن است به خوبی جواب ندهند و در واقع شکست بخوردن. اگر طرفدار خلاقیت در تیم هستید، باید بدانید که چنین مواردی هم رخ خواهند داد. افراد نباید در این موارد بازخورد منفی زیادی دریافت کنند، به شکلی که تصمیم بگیرند از خلاقیت فاصله بگیرند.
با تیم خود صحبت کنید از تیم خود بخواهید در مورد روش انجام کار نظر بدهند. اگر فکر میکنند که بخشی از روش اسکرام برای آنها آزار دهنده است از آنها بخواهید که به شما برای بهبود آن کمک کنند. حتی اگر درنهایت نتوانید به روشی برای بهبود آن برسید، افراد تیم تلاش شما را درک خواهند کرد و با روحیه بهتر به کار ادامه خواهند داد.
همیشه بپرسید که آیا ارزشش را دارد؟ این یک قاعده کلی در چابکی است. اگر قرار است کاری را انجام دهید، باید ابتدا از خود بپرسید که ارزش خروجی مورد انتظار آن، در برابر هزینه آن چقدر است؟ نباید کارها را صرفاً چون جزو قواعد از پیش تعیین شده هستند انجام دهید.
جمعبندی
اسکرام یا سایر روشهای چابک، یک فرمول جادویی نیستند که به صورت خودکار مشکلات شما را حل کنند و باعث شوند که کار شما به شکل شگفتانگیزی خوب پیش برود. اسکرام صرفاً یک ابزار است برای بهبود کار؛ مانند هر ابزار دیگری، پیش از استفاده از آن، باید آن را به درستی بشناسید، بدانید که چرا میخواهید آن را به کار بگیرید، درنهایت آن را به درستی به کار ببندید.
اگر اسکرام را بدون شناخت کافی و با روش نادرست به کار ببندید، به نتیجهای کاملاً عکس انتظارتان میرسید: بهرهوری تیم شما کاهش مییابد، افراد روحیه و انگیزه کاریشان را از دست میدهند، تعاملات تیمی دچار مشکل میشود و …
برای استفاده صحیح از اسکرام بهتر است ابتدا روح چابکی را در شرکت/تیم خود جا بیاندازید، از افراد تیمتان کمک بگیرید و اسکرام را به صورت تدریجی و به شکل مناسب خود پیادهسازی کنید. همچنین همیشه در نظر داشته باشید که هیچگاه یک دستورالعمل مناسب تمام تیمها وجود ندارد. برای رسیدن به راه حل مناسب، باید تیم خود، انتظارات و اهدافتان را به خوبی بشناسید و بعد عمل کنید.
[1] http://agilemanifesto.org/
[2] http://agilemanifesto.org/principles.html
