آیا در جلسه برنامه ریزی اسپرینت، بدهی فنی ایجاد می کنید؟
اسکرام یک چارچوب ساده برای توسعه محصولات نرم افزاری پیچیده در یک محیط پیچیده است ولی عملی کردن آن سخت است. اما چرا؟ من به تشریح دلایل این موضوع نمی پردازم، اما می خواهم مطابق درک خودم یکی از مشکلات تیم توسعه را مطرح کنم که منجر به ایجاد بدهی فنی برای تیم توسعه می شود.
تیم توسعه به معنای تیمی متشکل از دولوپرها و یا توسعه دهنده هاست که خودکفا و خود سازمانده (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