ویرگول
ورودثبت نام
سارا رشادی
سارا رشادیروزانه‌های یک اسکرام‌مستر
سارا رشادی
سارا رشادی
خواندن ۲ دقیقه·۶ سال پیش

۵، ۱۰، ۱۵، حرکت...

به عنوان یک برنامه‌نویس که داره همراه با تیم کار می‌کنه، زمانتون رو چطور بین کدنویسی، رفع باگ و بدهی فنی مدیریت می‌کنید؟

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

این اشتباهیه که خیلی از تیم‌های اسکرام انجام می‌دن. اون‌ها در محاسبه ظرفیت تیم، تمام ظرفیت رو به کد زدن اختصاص می‌دن.

همونطور که در ابتدای متن هم اشاره کردم، این موضوع باعث چند تا آسیب جدی می‌شه:

اول اینکه تیم تمام مدت داره می‌دوه که به عدد مورد نظر برسه در نتیجه ممکنه از کیفیت محصول کم بشه. در نتیجه به زودی شما با یه عالمه بدهی فنی و یه عالمه مشتری ناراضی مواجه می‌شید.

دوم اینکه تیم در بلند مدت خسته و دلسرد می‌شه. چون وقتی برای یادگیری و رشد نداره.

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

برنامه‌نویسی دونفره (به انگلیسی: Pair programming) روشی برای برنامه‌نویسی در متد برنامه‌سازی مفرط در پارادایم توسعه نرم‌افزاری چابک است. در این روش دو برنامه‌نویس در کنار هم و روی یک ایستگاه کاری کار می‌کنند.
در هر لحظه یکی از این دو کدنویسی کرده و دیگری کد او را بررسی و نقد می‌کند و به فراخور نیاز راهنمایی‌اش می‌نماید. این دو به صورت دوره‌ای جای خود را عوض کرده و کسی که راهنمای ای نقاد بوده دست به کدنویسی برده و کد‌نویس مرحله قبل کد او را نقد و بررسی می‌کند.
نفر دوم که کار کدنویسی را مشاهده می‌کند، مشاهده‌گر (به انگلیسی observer) یا ناوبر (به انگلیسی navigator) می‌نامند. نفر کناری بررسی و نقد کد به استراتژی کلی برنامه و مشکلاتی که در آینده پیش خواهد آمد نیز می‌اندیشد. به‌طور کلی نفر دوم به تاکتیک‌ها توجه بیشتری دارد تا تکنیک‌ها.

این آسیب‌ها در نهایت به کاهش بهره‌وری تیم منجر می‌شه.

برای حل این چالش می‌شه از تکنیک «پنج-ده-پانزده» استفاده کرد. به این ترتیب که:


۵ درصد از ظرفیت به افزایش دانش فنی افراد
۱۰ درصد از ظرفیت به رفع باگ و مشکل
۱۵ درصد از ظرفیت به رفع بدهی فنی اسپرینت جاری و اسپرینت‌های قبل اختصاص پیدا کنه.

این توزیع باعث می‌شه تیم فرصت و توجه کافی داشته باشه و علاوه بر رضایت تیم، رضایت مشتری رو برای شما به همراه بیاره.

برنامه نویسیباگاسکراماستارتاپکد نویسی
۶
۵
سارا رشادی
سارا رشادی
روزانه‌های یک اسکرام‌مستر
شاید از این پست‌ها خوشتان بیاید