Uncategorized

آیا در جلسه برنامه ریزی اسپرینت، بدهی فنی ایجاد می کنید؟

آیا در جلسه برنامه ریزی اسپرینت، بدهی فنی ایجاد می کنید؟

بدهی فنی

 

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

تیم توسعه به معنای تیمی متشکل از نفرات چندین عملکردی و خود سازمان دهی (cross-functional and self-organizing) از توسعه دهندگان است. اما توسعه دهنده کیست؟ آیا هر کسی را که به توسعه نرم افزار کمک می کند نمی تواند شامل شود؟ برنامه نویس ، آنالیزور، dba، طراح UI، نویسنده محتوا و تحلیلگر تجارت؟ حالا به تیم خود نگاه کنید. آیا چندین عملکردی است؟ بله، به دلیل این که شما تکنسین هایی برای همه مهارت ها دارید، اما آیا این تکنسین ها توسعه دهنده هستند؟ شاید نه. آنها فقط برنامه نویس، تستر، dba و طراحان UI هستند و منتظر کارهای مربوط به مهارت خود هستند. آنها به عنوان توسعه دهنده هایی که قصد توسعه نرم افزار را دارند کار نمی کنند، اما آنها بر اساس مهارت های خود وظایف خود را انجام می دهند.

 

موارد کلیدی که به شما در درک ویژگی های تیم توسعه کمک خواهد کرد.

فرض کنید L&D (گروه یادگیری و توسعه) در حال برگزاری چند آموزش مانند موارد زیر است.

اعلامیه اول “ما قصد داریم یک کارگاه آموزشی برای دولوپر اسکرام داشته باشیم ، بنابراین تمایل خود را برای شرکت در آن به ما اعلام کنید.” خواهید فهمید که فقط برنامه نویسان در این کارگاه شرکت کرده اند.

اطلاعیه دیگر “ما در حال برگزاری کارگاه تست اجایل هستیم، بنابراین تمایل خود را برای شرکت در آن به ما ارسال کنید.” این بار فقط تسترها مشارکت می کنند. همین اتفاق در مورد تجزیه و تحلیل تجارت Agile و آموزش UI / UX نیز رخ می دهد.

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

“در واقعیت، آزمایش کنندگان برای تست کدهای مرحله تولید کد می نویسند و کدنویس ها برای انجام تست های واحدی و ادغامی کد (unit and integration tests)، تست می نویسند.”

 

بیایید نگاه دیگری داشته باشیم

در طول جلسه برنامه ریزی اسپرینت، تیم، اسپرینت بک لاگ زیر را آماده کرده است.

 

بدهی فنی

 

چه چیزی برداشت می شود؟ وظایفی وجود دارد، اما آن وظایف مبتنی بر مهارت است و مبتنی بر جزء (component)  نیست. آیا این روشی اشتباه برای ایجاد کارهای فرعی نیست؟ اگر موافق نیستید پس شرایط زیر را بخوانید.

فرض کنید الکس (کدنویس) و مارتا (تستر) که روی این سه استوری (آیتم های اسپرینت بک لاگ) کار می کنند.

الکس قسمت برنامه نویسی استوری اول را در ۲ روز به پایان رساند، و مارتا آزمایش را شروع کرده است، پس الکس بعد از آن چه خواهد کرد؟

به احتمال زیاد الکس کار خود را روی قسمت کدنویسی استوری ۲ شروع خواهد کرد. اما آیا این روش درست است؟ چرا الکس نمی تواند کار دیگری را از همان استوری انتخاب کند؟ یا چرا مارتا منتظر بود تا الکس کدگذاری را برای تکمیل تست انجام دهد؟ چرا او نمی تواند با الکس هماهنگ شود تا به صورت موازی تست انجام شده یا حداقل تست API ها را شروع کند؟

بسیاری از مردم از من پرسیدند که اگر الکس کار بر روی قسمت برنامه نویسی استوری ۲ شروع بکند چه اشتباهی روی داده است؟ بیایید وضعیت زیر را ببینید.

الکس کدنویسی استوری ۱ را به پایان رساند و برنامه نویسی استوری ۲ را شروع کرد. مارتا در استوری ۱ اشکالی پیدا کرده است، پس او باید چه کند؟ او پیش الکس رفت و می خواست درباره آن بحث کند، اما الکس بسیار شلوغ است و از او خواست که بعداً بیاید.

 

برای ورود به دنیای اسکرام می توانید از دوره غیرحضوری “آشنایی مقدماتی با اسکرام” شروع کنید

دوره غیرحضوری آشنایی مقدماتی با اسکرام

 

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

الکس کدنویسی استوری ۲ را به پایان می رساند و سپس شروع به بررسی اشکالاتی می کند که توسط مارتا ثبت شده است.  او پی می برد که ریشه اصلی پروژه (root) علت بروز برخی مشکلات شده است و برای برطرف کرن آن تغییرات کد فریمورک نیاز است. اما این روی کدی که او تازه برای استوری ۲ تکمیل کرده است نیز تأثیر می گذارد؟

الکس چه خواهد کرد؟ اگر او هر آنچه را که برای رفع مشکلات ریشه لازم است تغییر دهد، باعث تولید مجدد و تأخیر در تحویل محصول خواهد شد. گزینه دیگر میانبر برای رفع اشکال است  (patchwork) ، بنابراین نباید روی کد استوری دوم تأثیر بگذارد.

اکثر برنامه نویسان امروزی گزینه ۲ را انتخاب می کنند زیرا کدگذارها نسبت به کد خود بسیار احساساتی هستند (صرفا جنبه شوخی). دلایل مختلفی برای انتخاب گزینه ۲ وجود دارد، اما نتیجه آن “بدهی فنی” خواهد بود.

 

چه چیز دیگری وجود دارد؟

برای جلوگیری از چنین سناریویی چه کاری می توانیم انجام دهیم؟

در مرحله ۱ کارهای فرعی مانند موارد بالا ایجاد نکنید اما سعی کنید به اجزاء مشخص (component-based) تقسیم شوید. بهترین کار، ایجاد کارهای فرعی و کوچک نگه داشتن استوری نیست. با همکاری هم روی یک استوری کار کنید به جای اینکه مدام از یک استوری به استوری دیگر بروید. تیم باید روی اتمام کارها تمرکز کند و نه صرفاً شروع کار جدید.

 

لینک مقاله اصلی:

https://www.scrum.org/resources/blog/are-you-planning-technical-debt-sprint-planning

 

مدرسه اسکرام ، مرجع حرفه ای آموزش اسکرام

image_pdfدانلودimage_printپرینت
۰ votes, average: ۰.۰۰ out of ۵۰ votes, average: ۰.۰۰ out of ۵۰ votes, average: ۰.۰۰ out of ۵۰ votes, average: ۰.۰۰ out of ۵۰ votes, average: ۰.۰۰ out of ۵ (۰ votes, average: ۰.۰۰ out of ۵)
You need to be a registered member to rate this.
Loading...

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *