اکثر ما با این موضوع درگیر بوده ایم که هر شنبه دور هم جمع شده ایم و معمولا برنامه ی روشنی نداریم و تلاش می کنیم تا یک اسپرینت را برنامه ریزی کنیم. معمولا از جای خوبی شروع می کنیم، در مورد اینکه کدام استوری به اندازه ی کافی واضح نیست و کدام استوری نیاز به جزییات فنی بیشتری دارد، با هم مجادله می کنیم اما دوباره به همان جای قبلی باز می گردیم. بدین ترتیب تیم فنی، “برنامه ریزی” را به عنوان بخشی از جلسه اسپرینت در نظر می گیرند. مالک محصول (Product Owner) نگران و سردرگم می شود و متاسفانه گاهی راه حل های خوبی که در جلسه مطرح می شود به دلیل شلوغی، سر و صدا و یا مشکلات ترجمه از زبانی به زبان دیگر گم می شود. در این وضعیت اسکرام مستر و یا رهبر تیم باید اوضاع را تحت کنترل خود دربیاورد اما یک مقدار زمان در چنین وضعیتی از بین می رود.
اغلب مشکل اصلی این است که اعضای تیم فنی تا زمانی که از نظر “تکنیکال” در مورد یک استوری صحبت نکرده باشند و آن را مورد بحث و بررسی قرار نداده باشند در مورد آن مطمئن نخواهند بود. برخی از برنامه نویسان ترجیح می دهند این کار را در حالی که در قلعه ی خود نشسته اند انجام دهند اما برخی دیگر می خواهند در مورد آن بحث کنند چرا که ترجیح می دهند به یک توافق تیمی برسند.
در نهایت بهره وری از دست رفته مایه ی تاسف و پرهزینه است. اما مشکلی که در اینجا با آن مواجه هستیم بسیار پیچیده نیست و با کمی تدبیر قابل حل است. اما چگونه باید برای رسیدن به موفقیت در این مرحله آماده شد؟ اگر جلسه ی برنامه ریزی تنها در مورد برنامه ریزی و نه مشخص کردن جزییات فنی باشد چه؟ بیاید فرض کنیم که استوری ها آماده اند، وظایف مشخص شده اند، استوری پوینت ها تخمین زده شده اند و تمام آنچه که ما باید انجام دهیم نهایی کردن کارها با قرار دادن آنها به عنوان هدف است. انجام این کار در هر اسپرینت به طور موثر به نظم و تمرکز بالایی نیاز دارد. این امر زمانی که اندازه ی تیم اجایل بزرگ باشد، چالش برانگیزتر می شود.
معرفی روش هایی برای داشتن جلسه برنامه ریزی اسپرینت موثر
برای داشتن یک جلسه برنامه ریزی اسپرینت موثر آنچه که به عنوان تجربه می توانیم کنیم “مراقبت از جلسه” است. اسکرام مستر باید پیش از جلسه از تیم فنی بخواهد که برآورد های خود از استوری های اسپرینت را آماده کنند و در جلسه با مالک محصول چک کنند و در نهایت اسکرام مستر باید اطمینان داشته باشد تا موارد زیر به صورت کامل در جلسه مورد توافق قرار خواهند گرفت:
- استوری کاربر
- مشخصات و مدل ها
- عمدتا سوالاتی که در چهار سطوح زیر قرار می گیرند:
- کارهای فرانت اند
- کارهای بک اند
- وابستگی ها
- ناشناخته ها/تحقیقات
معمولا زمانی که در مورد کارهایی که باید انجام شود صحبت می کنید با وابستگی ها و موارد ناشناخته روبرو می شوید. به طور مثال فرانت اند و بک اند. این موضوع که به مواردی ناشناخته و یک سری وابستگی ها بربخورید بسیار طبیعی است و ایرادی ندارد. معمولا افراد در هنگام برخورد با این موارد عصبی می شوند چرا که برخوردن به این موارد نشان دهنده ی آن است که به اندازه کافی کار کرده اید اما نه کامل و درست.
حال این جلسه به یک جلسه قابل قبول برای توسعه دهندگان تبدیل شده است. بدین ترتیب توسعه دهندگان خود را در جلسه شریک می بینند و بهتر در آن مشارکت می کنند و خروجی جلسه از نقطه نظری سطح بالا است که مهندسان با آن راحتتر هستند. اما از طرفی بحث در مورد مسایل فنی وارد جزییات نشده و این موضوع باعث می شود تا رضایت همه حاضران در جلسه تامین شود. اجازه بدهید یک مثال برای شما بزنیم. شما صفحه وبی دارید که دارای دو بخش است. هر بخش استوری مختص به خود را دارد اما هر وظیفه در هر استوری در مجموع در سطوح بالاتر اینگونه دنبال می شود:
- پیاده سازی REST API برای بخش الف
- پیاده سازی یک صفحه HTML و CSS برای بخش الف
- پیاده سازی ماژول های انگیولار، کنترلها و سرویس ها
هنگامی که در حال برنامه ریزی جلسات هستید همواره به این امر توجه داشته باشید که این استوری ها نباید به صورت یک علامت سوال بزرگ باشند چرا که باعث می شود توسعه دهندگان عصبی شده و مساله برایشان مبهم جلوه کند.
زمانی که شما فکر می کنید این کارها ساده هستند یک توسعه دهنده با ذکر این نکته که طراحی صفحه باید طبق اصول UX و UI باشد تا انسانها بتوانند تعامل خوبی با سیستم داشته باشند این مساله دیگر ساده به نظر نمی رسد و پیچیده می شود.در نتیجه در اینجا شما با اولین مورد ناشناخته و وابستگی ها روبرو می شوید که قابل تخمین زدن و پیش بینی است اما به عنوان یک تیم باید قادر به مقابله با این مسائل باشیم. زمانی که این جلسات به همراه توسعه دهندگان برگزار شود آنگاه می توان با این مسائل ناشناخته روبرو شد و آنها را مورد محاسبه و تخمین قرار داد. گفته شدن جملاتی مثل “من می توانم در این امر به شما کمک کنم” و یا ” اجازه دهید در این مورد از تیم دیگری کمک بگیریم” و … نشان می دهد که در این جلسات می توان خطرات این موارد ناشناخته و وابستگی ها را به حداقل رساند و از آنها عبور کرد.
بنابراین هنگامی که در حال برنامه ریزی جلسات هستید همواره به این امر توجه داشته باشید که این استوری ها نباید به صورت یک علامت سوال بزرگ باشند چرا که باعث می شود توسعه دهندگان عصبی شده و مساله برایشان مبهم جلوه کند. در هنگام شروع می توانید برآورد های ساعتی داشته باشید و به تدریج آن را به برآوردهای روزانه برسانید. تمامی آنچه که باید انجام دهید این است که یک اسپرینت بسازید،استوری های هدف را به همراه یک ویژگی معنادار مشخص کنید. بدین ترتیب برنامه ریزی برای یک اسپرینت تنها ۳۰ دقیقه از شما زمان می گیرد.
