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