‫‫‫‫‫ ناسازگاری دولوپرها با اسکرام با کسری طوفانی

سلام به همه‌ی شنوندگان عزیز. من پدرام کشاورزی هستم و اینجا پادکست «اجایل گپ» است.
از زمانی که چارچوب اسکرام (Scrum) معرفی شد، همواره اجرای آن میان توسعه‌دهندگان (Developers) و اسکرام مسترها (Scrum Masters) با چالش‌هایی همراه بوده است. در این قسمت قصد داریم به چند نمونه از این چالش‌ها بپردازیم و بررسی کنیم که ماجرا دقیقاً از چه قرار است.

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

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

به نظر من اولین گام این است که شناختی کلی از روحیات توسعه‌دهندگان داشته باشیم. زیرا هر تیم ویژگی‌ها و شخصیت‌های خاص خود را دارد و نمی‌توان بدون شناخت کافی، انتظار هماهنگی کامل داشت. در گذشته معمول بود که تیم‌های منابع انسانی (HR) در مصاحبه‌ها از آزمون‌های شخصیت‌شناسی مانند MBTI یا DISC استفاده کنند. البته این کار گاهی حالت بوروکراتیک پیدا می‌کرد و چندان مورد استفاده‌ی عملی قرار نمی‌گرفت، اما در اصل، ابزارهای مفیدی هستند؛ به‌ویژه زمانی که با تیم‌های بزرگ سروکار داریم.

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

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

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

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

مسئله‌ی مهم دیگر، «تمرکز» توسعه‌دهندگان است. کار با کدها، خطاها (Bugs) و مسائل فنی نیازمند تمرکز بالا است و توسعه‌دهندگان هر کدام روش‌های شخصی خود را برای حفظ این تمرکز دارند؛ مثل نوشیدن قهوه یا گوش‌دادن به موسیقی. اما متأسفانه این تمرکز اغلب با عوامل بیرونی مختل می‌شود؛ از جمله تماس‌های مکرر در زمان دورکاری یا جلسات متعدد در ساعات کاری. تجربه نشان داده که برگزاری جلسات طولانی نه تنها خروجی مؤثری ندارد، بلکه زمان و انرژی زیادی از تیم می‌گیرد.

به‌عنوان مثال، در برخی تیم‌ها مشاهده می‌کنیم که بیش از نیمی از ساعات کاری روزانه صرف جلسات می‌شود و طبیعتاً فرصت کافی برای تمرکز روی کدنویسی و تحقق اهداف اسپرینت (Sprint Goals) باقی نمی‌ماند. این مسئله یکی از دلایل اصلی ناکامی در دستیابی به اهداف اسپرینت است.

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

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

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

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

از دیدگاه من، زمانی که کار فوری به‌درستی تعریف نشده باشد یا از منظر کسب‌وکار (Business) شفاف نباشد که دقیقاً چه چیزی «کار فوری» محسوب می‌شود، مشکلاتی به‌وجود می‌آید. در چنین شرایطی، مرتباً وظایف جدید به تیم اضافه می‌شوند، در حالی که ممکن است این وظایف در عمل اولویت واقعی نداشته باشند. از طرف دیگر، از منظر توسعه‌دهندگان (Developers)، ممکن است به‌طور مداوم باگ‌ها (Bugs) و مشکلات کیفی ایجاد شود و آن‌ها ناچار شوند زمان زیادی را صرف بازگشت به عقب، رفع اشکالات و پرداخت بدهی‌های فنی (Technical Debt) کنند.

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

دلیل تأکید بر گفت‌وگو درباره‌ی این موضوعات در جلسات بازنگری (Retrospective) این است که بتوانیم به‌مرور از حجم کارهای فوری بکاهیم و با ریشه‌یابی (Root Cause Analysis) مشخص کنیم که مشکلات از کجا سرچشمه گرفته‌اند.

موضوع دیگری که مایلم به آن اشاره کنم، «قانون پارکینسون» (Parkinson’s Law) است. این اصطلاح در صنعت نرم‌افزار رایج شده اما در واقعیت، یک «قانون علمی» محسوب نمی‌شود. این مفهوم در ابتدا به‌صورت طنزآمیز مطرح شد و بیان می‌کند که «کارها خود را تا هر زمانی که برایشان تعیین شود، کش می‌دهند.» برای مثال، کاری که در سه ساعت قابل انجام است، ممکن است به‌دلیل اختصاص زمان بیشتر، ده ساعت به طول انجامد.

کتاب «Peopleware» نیز به این موضوع پرداخته و آن را در کنار قوانین علمی مانند قوانین نیوتن (Newton) قرار داده و توضیح داده است که قانون پارکینسون اساس علمی ندارد. مشکل زمانی ایجاد می‌شود که برخی مدیران با استناد به این نگاه نادرست، نسبت به تخمین‌های زمانی (Estimation) توسعه‌دهندگان بدبین می‌شوند. آن‌ها تصور می‌کنند اگر توسعه‌دهنده زمانی مانند چهار ساعت اعلام کند، در واقع می‌تواند کار را در دو ساعت انجام دهد و بر این اساس حجم بیشتری از کار را به او تحمیل می‌کنند.

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

بنابراین نباید به تخمین‌ها به‌عنوان مقادیر دقیق نگاه کنیم. تخمین صرفاً برآوردی تقریبی است و نباید مبنای قضاوت قطعی قرار گیرد. تمرکز بیش از حد بر تخمین‌ها می‌تواند اعتماد (Trust) و شفافیت (Transparency) را خدشه‌دار کند.

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

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

نکته‌ی بعدی که مایلم به آن بپردازم «تعهد» (Commitment) است. تعهد یکی از ارزش‌های بنیادین اسکرام (Scrum Values) به شمار می‌آید. اما پرسش اصلی این است که تعریف ما از تعهد دقیقاً چیست؟ از نگاه یک مدیر، تعهد ممکن است به این معنا باشد که توسعه‌دهنده موظف است حتی پس از ساعات کاری، مثلاً تا ساعت ۸ یا ۹ شب همچنان مشغول کار باشد. در حالی‌که این برداشت اشتباه است.

به عنوان نمونه، در مقاله‌ای که یکی از مدرسان رسمی اسکرام نوشته بود، ذکر شده بود که مدیری از او گلایه کرده چرا توسعه‌دهندگان تیم در تعطیلات آخر هفته یا خارج از ساعات کاری پاسخ‌گو نیستند. این در حالی است که در اصول چابک (Agile Principles) صراحتاً آمده است که «افراد بالاتر از ابزارها و فرآیندها قرار دارند.» اما چنین نگاهی باعث می‌شود اهداف صرفاً در اولویت قرار گیرند و انسان‌ها به حاشیه رانده شوند.

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

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

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

مسئله‌ی بعدی به قوانین و سیاست‌هایی (Policies) مربوط است که در تیم‌ها وضع می‌شود. برخی از این قوانین بسیار سخت‌گیرانه و دست‌وپاگیر هستند. در حالی‌که اسکرام اساساً یک متدولوژی نیست، بلکه یک چارچوب (Framework) است و ذات آن انعطاف‌پذیری است. اگر قوانین بیش از حد سختگیرانه باشند، خلاف روح اسکرام عمل کرده‌ایم.

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

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

در چنین شرایطی، نقش اسکرام مستر بسیار کلیدی است. او می‌تواند با ایفای نقش رهبری خدمت‌گزار (Servant Leadership) به تیم کمک کند تا هم استقلال بیشتری داشته باشند و هم در مسیر درست حرکت کنند.

برای آغاز بهبود، بهتر است ابتدا نقاط بحرانی (Pain Points) را شناسایی کنیم. زمانی که این نقاط مشخص شوند، می‌توانیم از همان ابتدا به توسعه‌دهندگان (Developers) کمک کنیم. در چنین شرایطی، آن‌ها اسکرام مستر (Scrum Master) را به‌عنوان یک رهبر خدمت‌گزار (Servant Leader) خواهند شناخت که به آن‌ها یاری می‌رساند و این امر موجب اعتمادسازی می‌شود. مفهوم رهبری در اینجا بسیار کلیدی است و یکی از مهم‌ترین وظایف اسکرام مستر دقیقاً همین است که ارتباط میان توسعه‌دهندگان، مالک محصول (Product Owner) و دیدگاه کسب‌وکار (Business Perspective) را به‌خوبی مدیریت کرده و این حلقه‌ها را به هم پیوند دهد.

نکته‌ی دیگری که می‌خواهم به‌عنوان یک توصیه بیان کنم این است که بسیاری از اسکرام مسترها در برقراری ارتباط مؤثر با توسعه‌دهندگان موفق عمل نمی‌کنند. یکی از دلایل اصلی این مسئله آن است که اسکرام مسترها معمولاً دانش فنی (Technical Knowledge) عمیقی ندارند. این موضوع البته طبیعی است، زیرا مسئولیت‌ها و تخصص آن‌ها با توسعه‌دهندگان متفاوت است. با این حال، اسکرام مستر باید تا حدی با زبان و ادبیات توسعه‌دهندگان آشنا باشد. اگر توسعه‌دهندگان در جلسات درباره‌ی مفاهیمی مانند «سرور» یا «هاست» صحبت می‌کنند، اسکرام مستر باید دست‌کم درک کلی از این اصطلاحات داشته باشد تا بتواند در گفت‌وگوها مشارکت کند.

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

افزون بر این، نباید فراموش کنیم که اسکرام صرفاً یک چارچوب (Framework) نیست، بلکه یک طرز فکر (Mindset) است. توسعه‌دهنده نمی‌تواند صرفاً در ساعات کاری نقش یک فرد منظم و چارچوب‌مند را بازی کند و سپس در زندگی شخصی هیچ پایبندی به نظم نداشته باشد. به همین دلیل، اسکرام مستر باید ارزش‌ها (Values) و رویدادهای اسکرام (Scrum Events) را برای اعضای تیم شفاف کند. اگر توسعه‌دهنده نسبت به به‌روزرسانی برد (Board) بی‌اعتنا است، باید دلیل این ضرورت برای او توضیح داده شود. اگر برگزاری جلسه‌ی روزانه (Daily Scrum) یا برنامه‌ریزی (Planning) و بازنگری (Retrospective) ضروری است، باید علت آن به‌روشنی بیان گردد تا مقاومت اعضا کاهش یابد.

توسعه‌دهندگان ذاتاً ذهنی منطقی و صفر و یکی دارند؛ هر مسئله‌ای را با شرط و نتیجه می‌سنجند. بنابراین باید به زبان آن‌ها صحبت کرد. به‌عنوان مثال باید گفت: «اگر برد به‌روزرسانی نشود، این مشکلات پیش خواهد آمد.» با چنین رویکردی، دلیل پایبندی به ارزش‌ها و رویدادها برای آن‌ها قابل درک‌تر خواهد شد.

برای روشن‌تر شدن ماهیت اسکرام نیز می‌توان از روش‌های تجربی استفاده کرد. مثلاً می‌توان یک یا دو روز جلسه‌ی روزانه (Daily Scrum) را حذف کرد و سپس نتایج را بررسی نمود تا اعضای تیم خودشان متوجه اهمیت آن شوند. این روش که در برخی منابع با عنوان «Minimum Specs» مطرح می‌شود، کمک می‌کند تیم‌ها مشخص کنند کدام رویدادها و قواعد واقعاً حیاتی‌اند و کدام‌یک را می‌توان حذف یا ادغام کرد. در تجربه‌ای که خود ما داشتیم، برخی جلسات حذف یا ادغام شدند؛ مثلاً جلسه‌ی روزانه و بخشی از برنامه‌ریزی در یک جلسه‌ی نیم‌ساعته ترکیب شد و در عین حال برخی دیگر از رویدادها مانند بازنگری (Retrospective) کنار گذاشته شدند. گاهی چنین تغییراتی نتیجه‌بخش است و گاهی نیاز به بازگشت به حالت اولیه وجود دارد؛ بنابراین هر تیم باید بسته به نیاز خود عمل کند.

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

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

ضروری است که اسکرام مستر (Scrum Master) یا مالک محصول (Product Owner) از مسائل درون تیم مطلع باشند و مشکلات تنها میان اعضا باقی نماند و به صورت گفت‌وگوهای غیررسمی (Gossip) انباشته نشود. این نکته بسیار کلیدی است که هر فردی احساس مسئولیت کند و خود را درگیر حل مسئله بداند؛ به این معنا که نه تنها مشکل را بیان کند، بلکه خود را نیز بخشی از راه‌حل بداند. فرهنگ تیمی باید به‌گونه‌ای باشد که اعضا به جای سرزنش یا بی‌تفاوتی، در کنار یکدیگر برای رفع موانع تلاش کنند.

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

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

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

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

در پایان، مایلم به منابعی اشاره کنم که مطالعه‌ی آن‌ها می‌تواند برای توسعه‌دهندگان و مدیران مفید باشد. کتاب Peopleware اثر Tom DeMarco از جمله آثاری است که بینش ارزشمندی درباره‌ی مسائل تیم‌های نرم‌افزاری ارائه می‌دهد و حتی به موضوعاتی مانند قانون پارکینسون (Parkinson’s Law) نیز پرداخته است. همچنین کتاب‌هایی مانند Soft Skills، The Pragmatic Programmer و The Ideal Team Player اثر Patrick Lencioni منابع بسیار مفیدی هستند. این آثار به توسعه‌دهندگان کمک می‌کنند تا فراتر از مهارت‌های فنی، دیدگاه درستی نسبت به کار تیمی، روحیات افراد و تعامل در سازمان به دست آورند.

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

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

‫‫‫اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید