عزیزم کجایی؟

فرایند توسعۀ نرم‌افزار وجوه مختلفی دارد: «پیچیدگی ذاتی»، «نیازمندی‌های متنوع و متغیر» و شاید مهم‌تر از همه جنبۀ‌ «فناورانۀ» مهمی دارد!

اما من می‌گویم آن ادعای «شاید مهم‌تر از همه» بیخود است! قطعاً وجهۀ «انسانی» توسعۀ نرم‌افزار مهم‌ترین بخش فرایند است. چیزی که موفقیت و شکست هر نرم‌افزاری را تعیین می‌کند!

الگویی تکرارشونده در زندگی روزمرۀ همۀ ما آدم‌های جایزالخطا «نظریۀ بازی‌»هاست. در اصطلاح علم «روان‌شناسی» عرض می‌کنم: «والد، بالغ و کودک درون». همه‌مان خیلی دوست داریم نقش «والد» کنترل‌کننده را به‌عهده بگیریم! نه که لزوماً دستور بدهیم؛ اما این دو قصۀ آشنا و کاملاً مشابه به‌نظرم مصداق این بازی است:

قصۀ الف

تیم‌های کامپوننتی: روزهای اول «بله» این‌طور بود. حدود هفت نفر برنامه‌نویس داشتیم که به سه تیم تقسیم شده بودند: «سرور»، «اندروید» و «آی‌او‌اس».یک تیم دو نفرۀ «سیس‌ادمین» هم داشتیم.

روزهای خوش‌حالی بود. هر فردی با متخصصان رشتۀ خودش همکار بود و از آن‌ها چیز یاد می‌گرفت و کارها را پیش‌ می‌برد.
یک نوع حس «امنیت روانی» و «کنترل مطلوب شرایط» در همه وجود داشت!

قصۀ ب

مدل گیت‌فلوی گیت‌هاب‌طور: باز هم در روزهای اول «بله» این‌جور بود که برای هر کاری، برنچی برای خودمان بسازیم و مدت نسبتاً طولانی (از دو تا ده روز) با آن سروکله بزنیم و بعد از رضایت نسبی با برنچ اصلی (مستر) ادغامش کنیم! در طی آن دوره متغیرهای بیرونی ما را اذیت نمی‌کرد و مشغول کارمان بودیم و پیش می‌بردیمش.

یک نوع حس «امنیت روانی» و «کنترل مطلوب شرایط» در همه وجود داشت!

مختصر بگویم: جفتشان بیخود هستند! جفتشان دشمن Continuous Delivery هستند. جفتشان مانع همکاری «بالغ‌بالغ» و «بهره‌ور» و البته «دشوار» کار تیمی هستند، تیمی که هدفی مشخص دارد. افراد با نقش‌های مشخص و متفاوت با همکاری هم دنبال به‌نتیجه‌رساندن «هدف مشترک تیم» هستند؛ نه اینکه فقط به‌دنبال خواسته‌ها و آرامش شخصی خودشان باشند.

مشکلات قصۀ الف

مساله Sub Optimization شدید! ایجاد سیلوهای سفت و سخت. نیازمند مدیر پروژه‌ با کفش‌های آهنین و معمولاً خسته و غرغرو! سربارهای Dependency Management و...

مثلاً «بله» می‌خواست ویژگی «لایک» پیام را اضافه کند. تیم «سرور» کار را با انرژی زیاد شروع می‌کرد. وقتی نوبت هم‌کاری تیم «اندروید» بود، معمولاً تیم اندروید سرش به کار دیگری گرم بود. تیم «سرور» می‌رفت دنبال کار دیگری. تیم اندروید کار قبلی‌اش تمام می‌شد و می‌آمد سراغ «لایک». باگی وجود داشت که تیم سرور باید حلش می‌کرد. اما الان تیم «سرور» سرش جای دیگری گرم بود. قس‌علی‌هذا! تحویل ویژگی «لایک» حدود سه ماه طول می‌کشید! درحالی‌که شاید فقط کار یک هفتۀ همه بود.

مشکلات قصۀ ب

«درد و خون‌ریزی» زیاد هنگام «انتشار نسخه». بعضی وقت‌ها این درد همان زمان merge هم پیش می‌آید. خصوصاً در شرایطی که بیشتر از سه نفر روی بخش‌های مشترک کد بنویسند؛ اما خب مشکل اصلی زمان انتشار است.

مثلاً آخر ماه می‌خواهیم رلیز کنیم. دو نفر برنامه‌نویس اندروید ما تا هفتۀ آخر روی برنچ لوکال خودشان به‌شدت کار می‌کنند. باگ‌ها را برطرف می‌کنند و نهایتاً کد را مرج می‌کنند. گاهی ادغام هم کمی دشواری دارد؛ اما فرضاً با تلاش تحسین‌برانگیزی حاصل حدود یک ماه کار در برنچ اصلی ادغام می‌شود. تبریک! یک موفقیت شخصی دیگر!

اما مشکلات تازه شروع می‌شود. آدم‌ها در طول ماه بدون اطلاع هم تغییراتی داده‌اند که «ناهمخوان» است. هر دو تا فیچری که قبلاً روی کامپیوتر خودشان خیلی خوب کار می‌کرد، دیگر به‌درستی کار نمی‌کند! دوباره وارد فرایند دردناک «دیباگ» می‌شویم، سخت و دشوار! بعد از دو روز می‌فهمیم که آن یکی برنامه‌نویس «شمای دیتابیس» را دست‌کاری کرده بوده است و ما خبر نداشته‌ایم و ازین قبیل مشکلات!

هر انتشار تبدیل به کاری رنج‌آور و دشوار می‌شود! گاهی هم برای حلش فرایندهای احمقانۀ دیگری به‌وجود می‌آید: از این به بعد فلان ماژول فقط کار آقای فلان است و فلان بخش کد را فقط خانم فلان می‌تواند عوض کند و... (البته توجه داشته باشیم که این مدل برای مشارکت افراد خارج تیم در پروژه‌های متن‌باز ناگزیر است.)

خب، حالا چه کنیم؟ از بازی روانی «والد‌والد» چطور بیرون بیاییم؟ و «بالغ‌بالغ» رفتار کنیم؟ از چه الگوی فنی‌ای برای حل مشکلاتمان بهره بگیریم؟ در قسمت‌های بعدی به این موضوع می‌پردازم.