در مشاغل برنامه نویسی، به عنوان یک توسعه دهنده معمولاً باید با دیگران در یک تیم کار کنید و بنابراین لازم است عادت هایی را که هنگام کار فردی روی پروژه ها داشتید کنار بگذارید. در اکثر تیم های برنامه نویسی، توسعه دهندگان قوانین و روش های خاصی برای کار با یکدیگر دارند. برخی از افراد فرآیند انجام این قوانین را Agile و برخی دیگر آن را Scrum می نامند. صرف نظر از اینکه این مجموعه قوانین چه نامیده می شود، این فرآیند به اعضای تیم می گوید که چگونه هنگام کار به عنوان یک تیم کدنویسی کنند و چگونه با یکدیگر و همچنین با مشتریان تعامل داشته باشند.
قبل از اینکه به اصل مطلب بپردازیم، اجازه دهید کمی در مورد روش هایی که بیشتر در هنگام کار با افراد استفاده می شود صحبت کنیم. پس از آشنایی با این روش ها، به ویژگی های تیم های موفق و همچنین ملزومات کار تیمی می پردازیم.
فرهنگ کدنویسی فردی
معمولاً افرادی که هنوز در کدنویسی به بلوغ کامل نرسیده‌اند، به‌تنهایی کد می‌زنند هرچند عکس این قضیه همیشه صادق نیست و همهٔ افرادی که به‌تنهایی کد می‌زنند الزاماً افرادی با سطح مهارت پایین نیستند؛ اما یک نکته همیشه صادق است و آن هم این است که افرادی که به‌تنهایی کد می‌زنند، آغاز تا پایان پروژه را خود به‌تنهایی برعهده می‌گیرند و همهٔ اجزاء و ابعاد پروژه نتیجهٔ مستقیم تصمیمات و کار همان یک برنامه‌نویس است.
از سوی دیگر، برخلاف تصور نادرست موجود، ۲ برنامه‌نویس در یک تیم دونفره، کار را با سرعت ۲ برابر پیش نمی‌برند؛ درواقع یک تیم برنامه‌نویسی دونفره ممکن است به همان اندازه که یک برنامه‌نویس تنها برای تکمیل پروژه به زمان نیاز دارد، زمان لازم داشته باشند. بنابراین به‌تنهایی کد زدن نه‌تنها بد نیست بلکه مزایایی هم دارد که از مزایای کار تک نفره می توان به موارد زیر اشاره نمود:
عدم وجود روابط حاشیه‌ای
وقتی دولوپری خود به‌تنهایی کد می‌زند، فقط مشغول یک کار است: کد زدن. یعنی پیش رفتن یا نرفتن پروژه فقط به کد زدن یا نزدن او بستگی دارد؛ اما دولوپری که در قالب یک تیم با دیگران کار می‌کند، خواه و ناخواه باید با دیگران روابطی برقرار کند زیرا دیگران باید بدانند که او بر روی چه تسکی کار می‌کند تا به محدودهٔ کار او وارد نشوند.
همچنین او باید بداند دیگران بر روی چه موضوعی کار می‌کنند تا به محدودهٔ کار آن‌ها وارد نشود و او و دیگران برای اظهار نظر در مورد کدها و فیدبک گرفتن از یکدیگر نیز باید باهم در ارتباط باشند؛ پس اگر به‌تنهایی کد بزنید، نیازی ندارید تا در ارتباط با کدهای خود به کسی ایمیل بزنید و یا با کسی ملاقاتی داشته باشید و یا بدتر از همه، به کسی پاسخگو باشید!
آشنایی کامل با همهٔ اجزاء سورس کد
وقتی به‌تنهایی کد می‌زنید، از آنجا که خط‌به‌خط کد را خودتان نوشته‌اید، بدیهی است که به تمام جنبه‌های سورس‌کد تسلط دارید، می‌دانید هر کدام از اجزاء چگونه نوشته شده‌اند و دقیقاً چه کاری انجام می‌دهند؛ بنابراین نیازی نیست بخشی از وقت خود را صرف این کنید که بفهمید منظور دولوپر از نوشتن فلان کد چه بوده است. پس وقتی که می‌خواهید قابلیت جدیدی را به کدهای خود اضافه کنید، می‌توانید بدون هدر دادن وقت، مستقیماً به سراغ کد موردنظر رفته و تغییرات لازم را در آن اعمال کنید.
تا اینجا معلوم شد که اگر به‌تنهایی کد بزنید، به همهٔ جنبه‌های سورس‌کد نوشته شده تسلط داشته و علاوه‌بر این، کسی نیز در کار شما دخالت نخواهد کرد اما مشکل دقیقاً از همین‌جا شروع می‌شود! مشکل این است که وقتی به‌تنهایی کد می‌زنید، اجباری برای رعایت قوانین خاص برای شما وجود ندارد پس مسائل را نه الزاماً از راه درست بلکه از راه‌های دلخواه خود -که در بسیاری از مواقع کوتاه‌ترین و سریع‌ترین راه است- حل می‌کنید. به‌عبارت دیگر، تست نمی‌نویسید، کدهای خود را مستند نمی‌کنید، همه‌چیز به میل شما پیش می‌رود و خلاصه برای خود ریاست می‌کنید!
این که شخص دیگری در کدنویسی همراه شما باشد، می‌تواند از لحاظ ذهنی شما را وادار کند تا مسائل را به روش درست حل کنید در‌حالی‌که وقتی به‌تنهایی کد می‌زنید، به‌راحتی ممکن است به سوی حل فوری و غیراصولی مسائل گرایش پیدا کنید.
درگیر بودن بیش از یک نفر در فرآیند کدنویسی، هرچند از نظر کمیت به‌معنای کاهش بازده کدنویسی شخصی هرکدام از این افراد است، اما درعوض کیفیت کدها و احتمال موفقیت پروژه را افزایش می‌دهد و همان‌طور که می‌دانیم اغلب نرم‌افزارهای موفق حاصل کار تیمی هستند.
اما در کنار هم کار کردن ۲ فرد الزاماً به‌معنای کار تیمی نیست بلکه این فرهنگ کار تیمی است که از چند دولوپر یک تیم می‌سازد؛ برای اینکه دولوپرها بتوانند در قالب یک تیم باهم کار کنند، باید فرهنگ کار فردی و قوانین شخصی خود را کنار گذاشته و خود و دیگران را در یک سطح ببینند.
در یک تیم، ریاست مفهومی ندارد بلکه این ارتباطات بین فردی است که اهمیت پیدا می‌کند و همین حس همکاری و کمک به دیگران است که می‌تواند به موفقیت خارق‌العادهٔ تیم منجر شود.
از همین روی، برای اینکه در یک تیم با دیگران کار کنیم باید از قوانین خاصی پیروی کنیم که ما در اینجا این قوانین خاص را اصطلاحاً Agile یا Scrum می‌نامیم.
به‌طور کلی، واژه‌های Scrum و Agile اصطلاحاتی هستند که برای توصیف فرآیند تولید یک نرم‌افزار در قالب یک تیم به‌کار می‌روند؛ هرچند این کلمات در موارد زیادی در جای نادرست مورد استفاده قرار می‌گیرند، اما باتوجه به متدولوژی اجایل، باید گفت که این کلمات معنای خاص و ویژه‌ای دارند که در ادامه شما را با چند اصطلاح و کاربرد عملی آن‌ها در تیم‌های اجایل یا اسکرام آشنا خواهیم نمود:
بک‌لاگ (انتظارات و نیازها)
Backlog (بک‌لاگ) یک محصول، درواقع فهرستی از تمام ویژگی‌ها و قابلیت‌هایی است که انتظار می‌رود در طی فرآیند تولید، به محصول اضافه شود؛ مدیران تولید و سایر مهندسان شرکت‌های نرم‌افزاری معمولاً به یک سیستم تیکتینگ (سیستمی برای مطرح نمودن درخواست‌ها، نیازها و انتظارات) دسترسی دارند؛ Basecamp ،Redmine ،Jira ،Rally ،Pivotal Tracker و GitHub Issues از جمله سیستم‌های تیکتینگی هستند که در شرکت‌ها مورد استفاده قرار می‌گیرند البته این در حالی است که برخی شرکت‌های سیستم‌های تیکتینگ اختصاصی خود را نوشته‌اند.
مدیران تولید -که کارشان این است که در هر مرحله از تولید محصول بگویند که در مرحلهٔ بعد چه کاری باید انجام شود- تیکت‌هایی را به سیستم تیکتینگ وارد نموده و مشخص می‌کنند که انتظار دارند در مرحلهٔ بعد چه ویژگی و قابلیتی به محصول اضافه شود.
آن‌ها فقط به شما می‌گویند که چه کاری باید انجام شود اما در مورد جز‌ئیات آن و اینکه تسک موردنظر چگونه باید انجام شود توضیح زیادی نمی‌دهند بلکه این خود مهندسان و دولوپرهای تیم هستند که باید درمورد نحوهٔ انجام خواسته‌ها و انتظارات مطرح شده و نکات فنی آن تصمیم بگیرند.
همچنین بخوانید : آیا دوستی مدیر و کارکنان در خارج از محیط کار منطقی است؟ حرفه ای رفتار کنید!
اسپرینت چیست؟
Sprint مجموعه‌ای از کارها و تیکت‌هایی است که برای انجام در یک بازهٔ زمانی مشخص درنظر گرفته شده‌اند؛ در دنیای واقعی، اسپرینت‌های ۱ هفته‌ای، ۲ هفته‌ای و ۱ ماهه مرسوم هستند. وظایف و اهدافی که انجام آن‌ها از بالاترین اولویت برخوردار است، در قالب اسپرینت برای تیم تعریف می‌شوند و سایر کارها در درجهٔ دوم اهمیت قرار می‌گیرند.
درواقع، اگر از اعضای تیم سؤال شود که مثلاً در ۲ هفتهٔ آینده مشغول انجام چه کارهایی خواهید بود، اعضاء برای پاسخ دادن به این سؤال باید به اسپرینت مراجعه کنند زیرا وظایف آن‌ها برای یک بازهٔ زمانی خاص در اسپرینت مشخص شده است.
به هر یک از اعضای تیم تعدادی از تیکت‌ها محول شده و در پایان بازهٔ زمانی اسپرینت، کدها دیپلوی خواهند شد (بنابراین قاعدتاً در پایان این بازه، تیکت انجام نشده و یا ناقصی نباید وجود داشته باشد). در‌صورتی‌که نتوانید تمام کارهای تعیین شده در اسپرینت را تا پایان بازهٔ زمانی به پایان برسانید، شما -و احتمالاً کل تیم- به دردسر خواهید افتاد زیرا بلافاصله پس از اتمام اسپرینت فعلی، اسپرینت بعدی آغاز خواهد شد.
بنابراین هر زمانی که متوجه شدید -بنا به هر دلیلی- قادر به تکمیل تسک‌ها تا پایان زمان مقرر نیستید، حتماً قبل از اینکه کل زمان اسپرینت را از دست بدهید، در این مورد با اعضای تیم و در صورت نیاز با مدیران شرکت گفتگو و مشورت کنید.
برنامه‌ریزی برای اسپرینت
اگر اسپرینت مجموعهٔ کارهایی است که در روزهای پیش‌رو باید انجام شود، پس ما از کجا باید بدانیم که از میان تمام تیکت‌های باقی‌مانده، کدام‌یک مربوط به اسپرینت بعدی هستند و کدام‌یک مربوط به اسپرینت‌های بعدتر؟ پاسخ این است که در مورد هر اسپرینت، قبل از پایان اسپرینت قبلی برنامه‌ریزی می‌شود. مهندسان، مدیران تولید و سایر اعضای تیم به فهرست تیکت‌های باقی‌مانده مراجعه نموده و از آن میان، تیکت‌هایی که در اولویت بالاتری قرار دارند را برای انجام در اسپرینت بعدی انتخاب می‌کنند.
بعضی از کارها نسبت به بقیه به زمان بیشتری نیاز دارند؛ در طی برنامه‌ریزی برای اسپرینت، معمولاً مهندسان بارها‌و‌بارها در مورد میزان پیچیدگی و دشواری انجام کارها با یکدیگر گفتگو و تبادل نظر می‌کنند؛ برای بحث در مورد این‌گونه موارد، تیم‌های اجایل ترجیح می‌دهند از مفهمومی به‌نام Story Point استفاده کنند.
انجام یک تسک مشخص برای یک دولوپر باتجربه ممکن است تنها ۱۰ دقیقه زمان ببرد اما یک دولوپر تازه‌کار برای انجام همان تسک ممکن است به ۲ ساعت زمان نیاز داشته باشد؛ بنابراین رده‌بندی تسک‌ها و وظایف براساس زمان مورد نیاز، امکان‌پذیر نیست و از این‌رو برای این کار از استوری پوینت استفاده می‌شود. به‌عبارت دیگر، استوری پوینت واحد اندازه‌گیری میزان پیچیدگی و دشواری یک تسک نسبت به تسک‌های دیگر است.
به‌عنوان مثال، رفع یک اشتباه تایپی در یک صفحه می‌تواند در مقیاس استوری پوینت امتیاز ۱ را دریافت کند و تسکی مانند بازنویسی کل اپلیکیشن می‌تواند امتیاز ۱۴ یا ۱۵ را دریافت نماید؛ بقیهٔ تسک‌ها نیز امتیازی بین این دو را دریافت خواهند نمود.
درعین‌حال، معنای امتیاز استوری پوینت برای تیم‌های مختلف متفاوت است و به توانایی‌ها و مهارت‌های اعضای تیم بستگی دارد؛ مثلاً تسکی که در یک تیم امتیاز ۴ دریافت نموده است ممکن است در تیمی دیگر امتیازی پایین‌تر یا بالاتر از ۴ دریافت نموده باشد؛ به هر صورت، هنگامی که آسان‌ترین و دشوارترین وظایف شناسایی شوند، بقیهٔ تسک‌ها و وظایف را می‌توان باتوجه به آن‌ها امتیازدهی کرد. پس از اینکه تیم توانست تعداد مناسبی از تیکت‌ها را برای اسپرینت پیش‌رو در نظر بگیرد، جلسهٔ برنامه‌ریزی برای اسپرینت پایان خواهد یافت.
جلسات سرپایی
تیم‌های توسعهٔ نرم‌افزار به‌منظور کسب اطلاعات در مورد همهٔ اعضای تیم، معمولاً هر روز یک جلسهٔ سرپایی برگزار می‌کنند که حدود ۱۰ تا ۱۵ دقیقه به طول می‌انجامد؛ در این جلسه همهٔ اعضا دور هم جمع شده و یک‌به‌یک به سؤالات زیر پاسخ می دهند:
– دیروز چه کاری انجام دادی؟
– امروز قرار است چه کاری انجام دهی؟
– آیا در انجام کارها به مشکل یا مانعی برخورده‌ای؟
اعضای تیم، هر یک توضیح کوتاهی در مورد کار خود می‌دهند و سپس به زیرگروه‌هایی تقسیم شده و در هر زیر گروه در مورد مسائل مرتبط با خود بیشتر باهم بحث می‌کنند.
این جلسات علاوه‌بر این که اطلاعاتی در مورد کار دیگران در اختیار افراد می‌گذارد، میزان پاسخگویی و مسئولیت‌پذیری اعضای تیم را نیز افزایش می‌دهد زیرا با برگزاری منظم این جلسات، افراد زیر ذره‌بین سایر اعضاء قرار می‌گیرند و بنابراین تلاش می‌کنند تا هر روز پیشرفت مناسبی داشته و چند روز متوالی را به انجام یک تسک یکسان سپری نکنند.
تابلوی وظایف
تابلوی وظایف، تابلویی است که در آن مشخص شده که هر کسی در‌حال‌حاضر مشغول چه کاری است؛ برای ایجاد این تابلو هم می‌توان از تکنولوژی‌های امروزی استفاده کرد و هم از وایت‌بردهای معمولی. در تیم‌های اجایل این تفکر وجود دارد که «اگر در‌حال‌حاضر روی بیش از یک تسک کار می‌کنید، درواقع روی هیچ‌کدام از آن‌ها کار نمی‌کنید».
در تیم‌های اجایل استفاده از تابلوی وظایف رایج است؛ در این تابلو، وظایف در ۳ ردیف «منتظر انجام»، «درحال انجام» و «انجام شده» قرار داده می‌شوند. در تابلوی وظایف بعضی از تیم‌ها، ستون‌های دیگری مانند «دیپلوی‌شده» و «تست‌شده» نیز وجود دارند. به‌طور کلی تابلوی وظایف تیم‌های مختلف اندکی با یکدیگر متفاوت است.
هر یک از اعضای تیم وظیفه دارد تا درصورت لزوم، تابلوی وظایف را به‌روزرسانی کند؛ مثلاً اگر شما به‌عنوان یکی از اعضای تیم کاری را شروع می‌کنید، باید عنوان آن کار را از ستون «منتظر انجام» به ستون «درحال انجام» منتقل نمایید.
چت روم
معمولاً شرکت‌ها امکان گفتگوی دولوپرها را در یک فضای چت‌روم خصوصی مانند Slack ،HipChat ،Campfire و یا IRC فراهم می‌آورند؛ این چت‌روم‌ها ارتباط سریع افراد با یکدیگر و مشورت و بازخورد گرفتن از سایر اعضاء را امکان‌پذیر می‌کنند (علاوه‌بر امور کاری، از این چت‌روم‌ها برای ایجاد روابط نزدیک‌تر میان اعضای تیم نیز استفاده می‌شود).
قانون هدفون
معمولاً در تیم‌های خیلی بزرگ، تمرکز کردن روی کاری مثل برنامه‌نویسی دشوار است زیرا هم‌تیمی‌ها، اعضای سایر تیم‌ها و حتی افرادی از بخش‌های دیگر شرکت ممکن است گاه‌و‌بیگاه برای یافتن پاسخ سؤال‌های خود کار شما را متوقف کنند؛ اما اگر قرار باشد شما دائماً مشغول پاسخگویی به سؤالات دیگران باشید دیگر فرصتی برای کدزدن باقی نمی‌ماند.
پس چاره چیست؟ به‌هر‌حال شما یک دولوپر هستید و برای کدزدن استخدام شده‌اید؛ چارهٔ کار استفاده از هدفون است؛ این قانون در اغلب تیم‌ها پذیرفته شده است که دولوپری که از هدفون استفاده می‌کند سعی دارد بر روی چیزی تمرکز نماید و نباید مزاحم او شد.
بهترین روش توسعهٔ نرم‌افزار چیست؟
اغلب تیم‌ها حداکثر سعی خود را می کنند تا بتوانند به بهترین روش برای پیشبرد کار خود دست پیدا کنند؛ هرچند تعریف مشخصی برای بهترین روش کار وجود ندارد اما اغلب تیم‌های موفق مواردی مانند توسعهٔ مبتنی بر تست، یکپارچه‌سازی مداوم و دیپلوی نمودن مداوم کدها، برنامه‌نویسی دونفره، بررسی و مطالعهٔ کدهای خود و دیگران و پیروی از دیزاین پترن‌های مشخص در کل تیم را سرلوحهٔ کار خود قرار می‌دهند.
در این مقاله شما را با بخشی از ویژگی‌ها، امکانات و قوانین تیم‌های اجایل آشنا نمودیم؛ مجموعهٔ این شرایط به تیم‌های اجایل کمک می‌کند تا کار گروهی خود را با هماهنگی و سرعت زیادی پیش برده و درنهایت به موفقیت‌های بزرگ و چشمگیری دست پیدا کنند.
شما چگونه کد می‌زنید؛ یک نفره یا تیمی؟ اگر با تیم کار می‌کنید آیا تاکنون از مواردی مانند موارد مطرح شده در این مقاله استفاده نموده و از فواید آن بهره برده‌اید و آیا پیروی از این موارد را مفید می‌دانید؟
