۵ علامتی که نشان می‌دهند تیم شما فاقد تفکر چابک است!

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

مطلب پیشنهادی

کدام عادت‌ها را کنار بگذاریم تا پولدار شویم؟

۸ عادتی که پول‌هایتان‌ را می‌بلعند و شما را فقیر می‌کنند!

در مورد اول، که تیم با متد اسکرام آشنا نیست، اکثر وقت رهبر اسکرام و همچنین تمرکزش، صرف آموزش و هدایت تیم  در چارچوب اسکرام می‌گردد. اغلب یک روش استاندارد وجود دارد که بر اساس آن تفکر چابک (Agile) و بعد اسکرام به تیم معرفی می‌گردد.از سوی دیگر، وقتی فرد به تیمی می‌پیوندد که اندکی تجربه کار کردن با اسکرام را دارند، باید متفاوت عمل کند. برای مثال، لازم است نظارت بیشتری روی نحوه عملکرد تیم و نحوه تعامل اعضای تیم با یکدیگر داشته باشد تا ببیند که آیا تفکر چابک یا اجایل وجود دارد؟

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

1-  سیلوهای دانش

برخی تیم‌ها، توسعه ‌دهندگان را مجبور می‌کنند تا روی بخش خاصی از محصول کار کنند که راجع به آن اطلاع و آگاهی دارند. وقتی مشکلی رخ می‌دهد، باید منتظر بمانند تا توسعه‌دهنده مورد نظر بیاید و مشکل را برطرف کند. در تولید یک محصول، تعدادی تکرار در نظر گرفته می‌شود که در پایان دوره زمانی هر تکرار، یک محصول قابل ارائه وجود دارد. به این دوره‌های تکرار شونده در اسکرام، اسپرینت(Sprint)  می‌گویند. این مشکل زمانی نمود پیدا می‌کند که در برنامه‌ریزی‌اسپرینت (sprint planning)، از قبل اشخاص مشخصی  برای انجام وظایف یا داستان‌های کاربر (یا  user story: همان نیازمندی‌های سامانه نرم‌افزاری است که در صدد تولید آن هستید) تعیین می‌شوند. این رفتار مانع از آن می‌شود که تیم روی اولویت‌ها کار کند، و در عوض هر شخص روی بخشی کار می‌کند که در مورد آن اطلاع دارد بدون آن که در پایان اسپرینت، محصول قابلیت تحویلی در نظر گرفته شود. ایراد دیگر این رفتار، عدم وجود روحیه و کار گروهی در تیم است چون هر کسی در حوزه خودش کار می‌کند و برایش مهم نیست که در قسمت‌های دیگر چه اتفاقی می‌افتد.

2- روی داستان‌های کاربر که در اولویت قرار دارند، کار نمی‌کنند

مجموعه نیازمندی‌های که در هر اسپرینت باید تمام شوند را سبد اسپرینت (Sprint Backlog) و به نیازمندی‌های جدیدی که صاحب پروژه بعد از انتشار محصول ممکن است به پروژه اضافه کند را سبد محصول (Product Backlog) می‌گویند. تیم‌هایی که روی داستان کاربر در پایین یا وسط سبد اسپرینت کار می‌کنند، مفهوم اولویت را از دست می‌دهند، و همچنین ممکن است به درگیری با صاحب پروژه یا صاحب محصولی که وظایفش را انجام نداده بیانجامد.

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

3- مجزا کردن داستان‌های کاربر برای آزمایش

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

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

4- هیچ دیدی نسبت به نموار burndown ندارند

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

5- آن‌ها فقط اسپرینت بعدی را تخمین می‌زنند

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

این‌ها برخی از نشانه‌هایی بودند که بنا به تجربه، بر اساس آن‌ها می‌توانید بفهمید که آیا تیم دارای طرز تفکر چابک هست یا این که باید روی آموزش بیشتر تاکید داشت.

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