مهارت‌های تیمی برای رشد حرفه‌ای توسعه‌دهندگان
توسعه‌دهندگان تازه‌کار و سطح‌متوسط از طریق مطالعه‌ی کتاب‌ها و مقالات گوناگون، و شرکت در دوره‌ها و رویدادهای برنامه‌نویسی، تلاش می‌کنند تا سطح خود را ارتقا داده و به سمت پروژه‌های سنگین‌تر و چالش‌برانگیزتر حرکت کنند. با این حال آن‌ها اغلب فرصت‌های ارزشمندی که در تیم و نقش فعلی خود برای رشد حرفه‌ای در دسترس دارند را نادیده گرفته و زمان گرانبهایی که می‌توانست صرف ارتقای مهارت‌هایشان شود را از دست می‌دهند.
در این مقاله به معرفی چند روش مبتنی بر همکاری و کار تیمی برای انتقال دانش در یک تیم پرداخته‌ایم. توسعه‌دهندگانی که از این روش‌ها استفاده می‌کنند، نسبت به کسانی که فقط به کتاب‌ها، دوره‌ها، مقالات و آموزش‌ها تکیه می‌کنند، رشد حرفه‌ای سریع‌تری دارند.
1. بررسی کد همکاران
هر pull requestای که توسط همکارانتان ارسال می‌شود، فرصتی است برای کشف اینکه دیگران چگونه مسائل را حل می‌کنند و بسته به شرایط از چه الگوهای طراحی و تکنیک‌هایی استفاده می‌کنند. هر کد ناآشنا فرصتی است برای پرسیدن سؤالاتی مانند:
- چرا نویسنده‌ی کد این رویکرد را انتخاب کرد؟
- دلیل انتخاب آن چه بود؟
- چه گزینه‌های دیگری ممکن است در شرایط مشابه در آینده، در نظر گرفته شوند؟
بنابراین توصیه می‌شود در اسرع وقت، PRهای دریافتی را بررسی کنید. توسعه‌دهندگان از بازخوردهای سریع و سازنده برای بهبود و تسریع پیاده‌سازی کد خود استقبال می‌کنند. می‌توانید حتی از این هم فراتر رفته و گاهی PRهای مشارکت‌کنندگان برترِ پروژه‌های متن‌باز را بررسی کنید تا درباره‌ی رویکرد و تصمیم‌گیری‌های فنی آن‌ها اطلاعات کسب کنید.
در مورد درخواست بازبینی برای PRهای خودتان هم، هرچه بتوانید بازخورد بیشتری دریافت کنید، سریع‌تر مهارت‌های کدنویسی و طراحی خود را بهبود می‌بخشید و PRهایتان نیز در آینده مشکلات کمتری خواهند داشت. می‌توانید برای PRهای پیچیده، از همه‌ی اعضای تیم بخواهید که آن‌ها را بررسی کرده و نظرشان را با شما به اشتراک بگذارند.
یکی دیگر از مزایای بررسی کد به‌عنوان یک تکنیک کار گروهی این است که توسعه‌دهندگان مجبور نیستند در لحظه فکر کنند و می‌توانند کدها را با سرعتی که برایشان مناسب‌تر است بررسی کنند. این ویژگی برای توسعه‌دهندگان کم‌تر برون‌گرا که شیوه‌هایی مانند برنامه‌نویسی دونفره برایشان خسته‌کننده یا استرس‌زاست، مناسب‌تر است.
۲. برنامه‌نویسی دونفره
برنامه‌نویسی دونفره روشی عالی برای مشاهده‌ی نحوه‌ی حل مسائل توسط همکاران است. این روش برای انتقال دانشِ ضمنی که قابل‌نوشتن یا بیان به‌صورت شفاهی نیست بسیار ایدئال است. برنامه‌نویسی دونفره همچنین یک تکنیک عالی برای پیاده‌سازی و حل مسائل پیچیده‌ای است که نیاز به همکاری توسعه‌دهندگان با‌تجربه در زمینه‌های مختلف دارند. علاوه بر همه‌ی این‌ها برگزاری جلسات برنامه‌نویسی دونفره، ارتباط بین هم‌تیمی‌ها را در سطح شخصی تقویت می‌کند.
به خاطر داشته باشید که برنامه‌نویسی دونفره می‌تواند خسته‌کننده باشد. به همین دلیل بهتر است به‌جای یک جلسه‌ی طولانی، برگزاری چند جلسه‌ی کوتاهتر مناسب‌تر باشد. برنامه‌نویسی دونفره از نظر زمانی نیز می‌تواند هزینه‌بر باشد. بنابراین استفاده از آن برای کارهای بی‌اهمیت، رویکرد چندان بهینه‌ای برای یادگیری نیست.
توصیه می‌شود هنگام درخواست از همکارانتان برای یک جلسه‌ی برنامه نویسی دونفره، شخصیت آن‌ها را در نظر بگیرید. برخی افراد بسیار درون‌گرا هستند و از این کار لذت نمی‌برند. برخی دیگر نیز آنقدر برون‌گرا هستند که ممکن است نقش شما را بیش از حد منفعل کنند. شکاف دانش بین افراد نیز نباید خیلی زیاد باشد تا جلسه برای هردوی شما مفید باشد.
۳. درخواست و ارائه‌ی بازخورد
قبل از شروع یک کار پیچیده، یک برنامه‌ی مختصر بنویسید و آن را با همکاران خود در میان گذاشته و از آن‌ها بازخورد بگیرید. هدف از این کار اعتبارسنجی ایده‌ها و طرح‌ها قبل از شروع پیاده‌سازی، یافتن گزینه‌های بهتر، و کشف زودهنگام مشکلات بالقوه است.
اعضای تیم اغلب خوشحال می‌شوند که ایده‌های خود را با نویسنده‌ی طرح در میان بگذارند. این بازخوردها بسیار ارزشمند هستند و احتملاً شما را از تلاش برای رفع مشکلات در آینده حفظ می‌کنند. بهتر است بازخوردها را نیز با اعضای تیم در میان بگذارید و نظر سایر اعضای تیم را نیز جویا شوید. به عنوان مثال، وقتی کسی به شما پیشنهاد می‌کند که از یک کتابخانه‌ی شخص ثالث استفاده کنید یا نحوه‌ی عملکرد خود را تغییر دهید، ابتدا نظر تیم را در این مورد بپرسید. این کار نه‌تنها برای شما سودمند است بلکه فرصتی است برای همکاران شما تا به رویکرد حل مسائل توسط دیگر همکارانتان فکر کرده و مواردی را یاد بگیرند.
چیزی که درمورد بازخوردها مهم است این است که بازخوردها ممکن است بر اساس ترجیحات شخصی فرد ارائه شوند. همچنین از بازخوردها نباید رنجیده‌خاطر شد. افراد حتی زمانی که بازخورد بیش‌از‌حد‌منفی و دلسرد‌کننده‌ای را بیان می‌کنند، قصد صدمه‌زدن به احساسات نویسنده را ندارند و صرفاً از طرح ارائه‌شده انتقاد کرده‌اند.
۴. مدیریت جلسات تیم
بسیاری از تیم‌های توسعه‌ی نرم‌افزار مدیریت و برگزاری جلسات روزانه، رترو، دمو و برنامه‌ریزی اسپرینت را به‌صورت دوره‌ای به اعضای تیم واگذار می‌کنند. هر جلسه فرصتی است برای شخصی که آن را اداره می‌کند تا ارتباطات خود با سایر اعضای تیم را تقویت کرده و مهارت‌های نرم را تمرین کند.
اگر در تیم شما امکان مدیریت دوره‌ای جلسات وجود ندارد، از مدیر خود بخواهید که امکان برگزاری چند جلسه را به‌عنوان یک تجربه‌ی یادگیری برای شما فراهم کند. اگر مدیر شما برای مدتی طولانی جلسات تیم را مدیریت کرده باشد، ممکن است از ایده‌ی سپردن این مسئولیت به اعضای تیم استقبال کند. پس از اجرای چند جلسه، از مدیر خود و سایر همکارانتان بخواهید که درمورد نحوه‌ی مدیریت جلسه، موارد مثبت و منفی و جنبه‌هایی که نیاز به بهبود دارند، بازخورد دهند. این کار نقاط ضعف شما را روشن کرده و به شما کمک می‌کند تا آن‌ها را برطرف کنید.
