روشهایی که به‌نظر مفید هستند و روشهایی که واقعا کار می‌کنند

فرآیند پراکنده‌سازی و گردآوری (Scatter-Gather Process)

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

برای هر ویژگی جدید یا تغییر در یک محصول نرم‌افزاری، یک فرد ارشد فنی طراحی‌ای را ایجاد می‌کند که احتمال موفقیت آن بالا باشد و با معماری کلی کسب‌وکار سازگار باشد. این فرد که می‌توان او را «طراح اصلی» نامید، سپس کار را به وظایف کوچک‌تر تقسیم می‌کند که هرکدام باید توسط افراد تیم انجام شوند.

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

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

این کار در شاخه‌های جداگانه در یک سیستم کنترل نسخه (مانند Git) انجام می‌شود و از طریق یک سیستم مدیریت تیکت (مانند Jira) پیگیری می‌شود.

هنگامی که همه بخش‌ها تکمیل شده و کد بررسی شد، این بخش‌ها در یک شاخه توسعه مشترک ادغام می‌شوند. پس از آزمایش یکپارچه، کد نهایی در شاخه اصلی (trunk) یا یک شاخه انتشار (release) ادغام می‌شود.

به عبارت دیگر:

1. کار ابتدا به بخش‌های کوچکتر تقسیم می‌شود.
2. این بخش‌ها بین اعضای مختلف تیم توزیع می‌شوند.
3. پس از تکمیل همه بخش‌ها، آن‌ها گردآوری می‌شوند.
4. بخش‌های نرم‌افزاری ادغام و یکپارچه‌سازی می‌شوند.
5. کد ترکیبی آزمایش می‌شود.
6. زمانی که راه‌حل نهایی به درستی کار کرد، مستقر (deploy) می‌شود.

این سبک کاری را توسعه پراکنده-گردآوری (Scatter-Gather Development) می‌نامیم.

چه چیزی در مورد آن جذاب است؟

این سیستم به دلایل مختلف برای افراد جذاب است:

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

مشکلات روش پراکنده-گردآوری (Scatter-Gather)

این سیستم چند مشکل قابل توجه دارد که باید به آن‌ها اشاره کرد:

گسترش زمانی (Time Spread):

کار معمولاً به‌صورت موازی انجام نمی‌شود زیرا هر فرد یک فهرست از وظایف مرتبط با داستان‌های مختلف دارد. طول و ترتیب فهرست وظایف ممکن است برای هر فرد متفاوت باشد. این موضوع ممکن است باعث شود که کار تکمیل آن زمان بیشتری ببرد زیرا کار در فهرست‌های مختلف کاری پخش می‌شود.

شکل‌گیری سیلوها (Silos Form):

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

ساخت آجر (Brick Making) (بر اساس یک داستان قدیمی که در مقاله‌ای از Huffington Post ذکر شده است):

توسعه‌دهندگان به ساخت قطعات کد مشغول هستند، نه به ادغام کامل و انتشارهای مکرر.

تضعیف همکاری (Collaboration Discouraged):

وظایف فردی و شخصی‌سازی‌شده برای برنامه‌نویسی تیمی (ensemble programming) چندان مناسب نیستند. همچنین، از آنجا که هر توسعه‌دهنده وظیفه خود را دارد، نمی‌تواند در کار دیگری مشارکت کند بدون اینکه کار خود را در معرض خطر ناتمام ماندن قرار دهد. به همین دلیل به تخصیص وظایف فردی، "عدم تیم‌سازی" (unteaming) گفته می‌شود.

بار روی طراح اولیه (Burden on Pre-designer):

رهبر تیم نه‌تنها باید طراحی را از ابتدا انجام دهد (که اغلب به‌تنهایی صورت می‌گیرد)، بلکه باید بهترین روش برای تخصیص کارها به اعضای تیم را نیز درک کند. علاوه بر این، او موظف است به تمام سؤالات مربوط به پیاده‌سازی، یکپارچه‌سازی و تحلیل کسب‌وکار در طول پیشرفت داستان پاسخ دهد.

تأخیر در تست (Late Testing):

ویژگی‌ها تا زمانی که تمام بخش‌های آن تکمیل نشود، به‌صورت یک جریان کامل از ابتدا تا انتها در دسترس نیستند. بنابراین، تست سرتاسری (end-to-end testing) به‌ناچار به تأخیر می‌افتد.

فرصت‌های از دست رفته (Lost Opportunity):

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

شگفتی‌های دیرهنگام (Late Surprises):

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

وضعیت نامشخص (Obscured Status):

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

پیش‌بینی سخت است و سخت‌تر می‌شود

شرکت‌های فعال در حوزه نرم‌افزار سعی می‌کنند با انجام تخمین‌های دقیق‌تر، مشکلات مربوط به پیش‌بینی و کیفیت را مدیریت کنند، اما این کار بی‌فایده است. مشکل پیش‌بینی‌پذیری به دلیل تخمین‌های نادرست نیست، بلکه در ذات سیستم پراکنده‌سازی و گردآوری (Scatter-Gather) نهفته است.

احتمالات علیه ما هستند

ایده تقسیم کار بین توسعه‌دهندگانی که برنامه‌های زمانی متفاوتی دارند، باعث افزایش احتمال ریسک می‌شود.

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

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

اگر این کار به دو بخش تقسیم و به دو نفر محول شود، هر بخش ممکن است به‌موقع انجام شود یا نشود. برای موفقیت، هر دو بخش باید تکمیل شوند. اما اکنون سه سناریوی شکست وجود دارد (تنها بخش A انجام شود، تنها بخش B انجام شود، یا هیچ‌کدام تکمیل نشوند) و فقط یک راه برای موفقیت وجود دارد.

با افزایش تعداد بخش‌های تقسیم‌شده، احتمال شکست بیشتر می‌شود و پیش‌بینی زمان اتمام کار پیچیده‌تر و نامطمئن‌تر خواهد شد

اگر کار را به سه بخش تقسیم کنید، ۸ حالت ممکن برای تکمیل آن وجود دارد، اما تنها یک حالت منجر به موفقیت می‌شود.

با تقسیم کار به ۴ بخش، فقط ۱ حالت از ۱۶ حالت ممکن موفقیت‌آمیز خواهد بود.

با تقسیم کار به ۵ بخش، فقط ۱ حالت از ۳۲ حالت ممکن موفقیت‌آمیز خواهد بود.

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

اگر قرار است ترتیب انجام کارها را هماهنگ کنیم، بهتر است که همه با هم روی کارها کار کنند، به‌خصوص روی مهم‌ترین کارها اول.

مشکل در مقیاس بزرگ‌تر

در سیستم scatter-gather، ویژگی‌ها مانند یک دسته کارت جابجا می‌شوند و افراد در زمان‌های مختلف بخش‌های مختلف کارها را انجام می‌دهند.

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

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

این مشکل زمانی بیشتر می‌شود که ویژگی در سطح بالا طراحی شود و سپس میان تیم‌ها تقسیم گردد و نه فقط افراد در همان تیم. اغلب تیم‌ها اولویت‌های مختلفی دارند که باعث می‌شود احتمالاً کار نیمه‌تمام، تست‌نشده و غیرقابل‌استفاده باقی بماند.

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

باز هم، فقدان هماهنگی که پیشرفت را مبهم کرده و تکمیل ویژگی‌ها را به تأخیر می‌اندازد، بخشی از سیستم scatter-gather است و نه نقصی در عملکرد توسعه‌دهندگان.

چه کار می‌توانیم برای پیشبرد کارها انجام دهیم؟

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

ما می‌توانیم اولویت‌بندی کارها را تغییر دهیم، اما این به این معنی است که ویژگی‌های دیگر بیشتر منتظر خواهند ماند چون کارهایشان به تأخیر افتاده است (در بهترین حالت) یا قطع می‌شود (در بدترین حالت). سیستم scatter-gather بر تقسیم تمرکز سازمان توسعه متکی است، بنابراین اگر از scatter-gather استفاده کنیم باید بپذیریم که نمی‌توانیم تمرکز واضحی را حفظ کنیم.

اگر تصمیم بگیریم که به روش scatter-gather کار کنیم، باید مشکلاتی را که این سیستم به همراه دارد بپذیریم.

راه‌حل جایگزین

در عوض می‌توانیم تصمیم بگیریم که به روش scatter-gather کار نکنیم.

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

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

زمانی که کار از مرزهای تیم عبور می‌کند، اعضای تیم از تیم‌های مختلف می‌توانند همان ویژگی را با هم کار کنند؛ ممکن است بخشی از عملکرد پشتیبان را بسازند در حالی که عملکرد جلویی در حال ساخت است؛ شاید بخش روی دستگاه را بسازند در حالی که بخش ابری در حال ساخته شدن است. شاید هم میکروسرویس‌ها را به صورت موازی بسازند.

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

چون تیم تمام کار را با هم انجام می‌دهد، نیازی نیست که یک تکنسین اصلی تمام ویژگی‌ها را از پیش طراحی و تقسیم کند.

اغلب اوقات تیم‌ها با استفاده از تکنیک‌هایی مثل برنامه‌نویسی گروهی (mob programming) یا تجمع (swarming) با هم کار خواهند کرد.

آیا این کار راحت است؟

نه.

کار فردی از کار تیمی تفکیک‌ناپذیر می‌شود که این مسئله فرآیند مدیریت عملکرد فردی را دشوار می‌کند.

اشتراک دانش و بهبود شخصی به سرعت و به طور طبیعی رخ می‌دهد. در یک ربع کاری با هم، آن‌ها ممکن است بیشتر از دو سال قبل یاد بگیرند، اما چگونه می‌توان مطمئن بود که چون شما نمی‌توانید مشارکت‌های آن‌ها را از دیگر همکارانشان جدا کنید؟

زمانی که یک ویژگی را یک ب74/

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

این مشکلات معمولاً در صورتی که ایمنی روانی کافی میان اعضای تیم وجود داشته باشد و تیم از مدیرانی که ارزش یک فرآیند سبک‌تر و همکارانه‌تر را درک می‌کنند و از مشکلات scatter-gather خسته شده‌اند، پشتیبانی شود، قابل غلبه است.

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

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

شاید ارزش امتحان کردن را داشته باشد.

ترجمه مطلبی از Tim Ottinger با عنوان The Scatter-Gather Process

ترجمه شده با استفاده از هوش مصنوعی