ارائه توسط: Randy Shoup
مترجم: محمد علی بزرگ زاده 1393/12/15
در این اپیزود که در سال 2014 ضبط شده است در مورد فرهنگ حاکم بر شرکت و همینطور استخدام در صنعت نرم‌افزار صحبت می‌شود. در این اپیزود با رندی شاپ مصاحبه می‌شود. رندی برای چندین شرکت بزرگ مانند اوریکو، ای‌بِی و گوگل کار کرده است و در حال حاضر مدیر ارشد فنی شرکت کیکسای است.
سلام رندی، به SE Radio خوش آمدی. دفعه قبل که با تو مصاحبه کردیم (اپیزود 109) در مورد معماری نرم‌افزار در ای‌بِی صحبت کردی اما الان در صنعت بازی‌سازی کار می‌کنی. چطور شد؟
این جابجایی مفرحی بود. من در ای‌بِی بعنوان مدیر ارشد برای 6 سال و نیم کار کردم و همانطور که گفتی در اپیزود 109 در مورد تجربه‌هایی که در آنجا داشتم صحبت کردم. بعد از آن یک استارتاپ کوچک برای خودم راه انداختم. از درآمدش نتوانستم جزیره اختصاصی برای خودم بخرم اما در نهایت چیزهای خیلی زیادی آموختم. بعد از آن در گوگل بعنوان مدیر فنی پروژه موتور برنامه‌های گوگل (Google App Engine) کار کردم که یک پلتفرم بعنوان سرویس (Platform as a Service) بود که 3 میلیون برنامه مختلف بر روی آن پلتفرم اجرا می‌شدند اما در سال گذشته بعنوان مدیر ارشد فنی یک شرکت بازی‌سازی در سانفرانسیسکو با نام کیکسای کار کرده‌ام. این جابجایی، یک جابجایی جذاب بود. به من در گوگل و ای‌بِی خیلی خوش گذشت و چیزهای زیادی در مورد ساختن سیستم‌های خیلی بزرگ و بزرگ کردن مقیاس سازمان آموختم. یکی از کارهایی که در کیکسای در حال انجام است همین بزرگ شدن است و به همین دلیل آنها به کسی که تجربه چنین کارهایی را داشته باشد علاقه نشان می‌دهند که هم در مورد بزرگ کردن مقیاس زیرساخت‌ها برای پشتیبانی از ده‌ها بلکه صدها میلیون کاربر تجربه داشته باشد و هم بداند چطور می‌توان مقیاس سازمان را برای پشتیبانی از این حجم عظیم، بزرگ کرد. من از زمانی که در کیکسای گذرانده‌ام لذت برده‌ام. صنعت بازی‌سازی به شدت با هیجان، مفرح و دوست‌داشتنی است. آنچه من می‌توانستم (برایشان) بیاورم، زیرساخت‌های برای مقیاس‌های بالای اینترنتی و رهیافت‌های ای‌بِی و گوگل برای کارهای سمت سرور (Server Side) بود که بیشتر کارهایم در آن ارتباط بوده است و آنچه می‌آموختم نیمه دیگر بازی‌سازی بود که خیلی جذاب بود یعنی مباحث مربوط به گرافیک، بازی کردن، موتورهای بازی‌سازی، شبیه‌سازی و خیلی جنبه‌های دیگر علوم کامپیوتر که در 20 سال گذشته هیچگاه با آن تماس نداشتم. برایم خیلی مفرح بود.
خیلی خوبه. اما فکر کنم هنوز گام‌های زیادی در پیش داشته باشید.
بله، همانطور که گفتم من این فرصت را دارم که در زمینه تکنیک‌های سمت سرور مربوط به مقیاس‌های بالا که در گوگل و ای‌بِی آموخته‌‌ام به آنها کمک کنم و آنها را در حوزه کاملاً جدیدی بکار بگیریم. کیکسای هم بر روی وب و هم بر روی دستگاه‌های موبایل، بازی‌های استراتژیک بلادرنگ می‌سازد. بخش جالب مهندسی ماجرا، بلادرنگ بودن آن است. بنابراین همه چیزی که ما باید یاد بگیریم این است که سیستم‌های با مقیاس بالایی داشته باشیم که تأخیر (Latency) به شدت پایینی داشته باشد و سرعت واکنش بالا داشته باشد. اینها می‌تواند در مورد موتور برنامه‌های گوگل بعنوان پلتفرم بکارگرفته شود یا بصورت یک وبسایت تجارت الکترونیک مانند ای‌بِی باشد و یا می‌تواند در بازی‌ها مثل کیکسای باشد. بنابراین خیلی از آموخته‌هایم بلکه همه آنها مستقیماً بکار می‌آید و این برای من ارزنده بوده است.
موضوع که امروز می‌خواهیم داشته باشیم یک بحث عمومی برای همه مخاطبان است که البته شامل خود من هم می‌شود اما شما در این موضوع، صحبت کرده‌اید. چرا تصمیم گرفتید که بیایید و عقاید خود در مورد استخدام و فرهنگ و اینجور موارد را به اشتراک بگذارید.
متشکرم. سئوال خوبی است. فکر می‌کنم همانطور که گفتید این یک موضوع جهانی است. من تاکنون در مورد خیلی چیزها صحبت کرده‌ام مثلاً برای مدت طولانی در مورد معماری‌های برای مقیاس بالا صحبت کرده‌ام، در مورد تحلیل‌گری و DevOps صحبت کرده‌ام. اما درسته، همانطور که شما گفتید فرهنگ، استخدام و سبکی که افراد در مهندسی دارند، موضوعاتی هستند که کمتر از حد درباره آنها صحبت شده است و برای همه شرکت‌ها به شدت مهم هستند چه شرکت‌های مهندسی باشند و چه نباشند اما خصوصاً در شرکت‌های مهندسی ما خیلی در مورد این صحبت می‌کنیم که چطور ماشین‌ها را خوشحال نگه داریم اما شاید آن مقدار که باید برای خوشحال نگه داشتن آدم‌ها وقت صرف نمی‌کنیم.
ادامه مطلب ...

ارائه توسط: James Lewis
مترجم: محمد علی بزرگ زاده 1393/11/24
این مصاحبه در اکتبر سال 2014 ضبط شده است. مهمان این مصاحبه جیمز لوییس است. او مشاور ارشد در ToughtWorks است. او عضو شورای مشورتی تکنولوژی در ThoughtWorks است که هر 3 ماه یکبار، ملاقات دارند و رادار تکنولوژی ThoughtWorks را تولید می‌کنند. (رادار تکنولوژی، نام سندی است که حدوداً هر 6 ماه یکبار در ThoughtWorks منتشر می‌شود و در آن تغییراتی که در گرایش‌های مربوط به تکنیک‌ها، تکنولوژی‌ها، زبان‌ها و ابزارهای توسعه نرم‌افزار رخ داده به شکل گرافیکی و توضیحات موجز مطرح می‌شود- مترجم). علاقه جیمز، تولید نرم‌افزار از طریق سرویس‌های کوچک همکار است. جیمز، در دهه 90 فیزیک نجومی خوانده است اما از برنامه‌نویسی به زبان فرترن خسته شد. او بعد از 15 سال کارهای مدیریت پایگاه داده و بعدها طراحی و معماری نرم‌افزار، اعتقاد دارد که نوشتن نرم‌افزار، ساده‌ترین بخش مسأله است و بیشتر کار مربوط به درست فکر کردن افراد است.
جیمز، به برنامه خوش آمدی!
خیلی ممنون!
آیا چیزی هست که بخواهی به بیوگرافی‌ات اضافه کنی؟
فکر نکنم. فکر کنم خوب پوشش دادید. من حدود 8 سال و نیم است که این کار را انجام می‌دهم. من تغییرات زیادی در صنعت نرم‌افزار را دیده‌ام و فکر می‌کنم تغییرات خیلی خیلی سریع است و فکر می‌کنم آنچه امروز می‌خواهیم در مورد آن صحبت کنیم، یکی از آن آخرین تغییرها باشد.
بیا در مورد موضوع عمیق شویم. ما می‌خواهیم در مورد ریزسرویس‌ها (Microservice) صحبت کنیم. ممکن است با این شروع کنید که ریزسرویس چیست؟
بله، البته. ریزسرویس به اعتقاد من، یک برنامه کوچک است که می‌تواند مستقلاً مستقر (Deploy) شود، مستقلاً مقیاس بپذیرد، مستقلاً تست شود و یک مسئولیت منفرد دارد. این مسئولیت منفرد، چند وجه دارد. یکی از این نظر که یک علت منفرد برای تغییرکردن داشته باشد و هم یک علت منفرد برای جایگزین شدن داشته باشد؛ این ضروری است. اما وجوه دیگر مسئولیت منفرد این است که فقط یک کار را انجام دهد و به سادگی برای کسانی که آن را توسعه می‌دهند قابل فهم باشد.
چنین چیز منفردی، چه می‌تواند باشد؟
سئوال خوبی است. یک مثال از چیز منفرد می‌تواند یک مسئولیت منفرد در ارتباط با نیازمندی‌های عملکردی یا غیرعملکردی یا نیازمندی‌های تقاطعی (Cross Functional) باشد. یک مثال می‌تواند یک پردازشگر صفی باشد؛ چیزی که یک پیغام را از صف می‌خواند، بر روی آن یک تکه پردازش کوچک مرتبط با منطق کار (Business Logic) انجام می‌دهد و آن را منتقل می‌کند. می‌تواند یک کار غیرعملکردی یا تقاطعی باشد و یا می‌تواند چیزی باشد که مسئولیتش این باشد که در مورد منبعی (Resource) خدمت بدهد و نمایشی از یک منبع باشد. مثلاً (نمایشی از) کاربر، مقاله، ریسک بیمه، ... . چیزی که خیلی خیلی مشخص و کوچک باشد و به تنهایی کار منفردی را انجام دهد.
من این احساس را دارم که ریزسرویس‌ها، اخیراً خیلی محبوب شده‌اند. شما در مورد آن صحبت کرده‌اید، دیگران در مورد آن صحبت کرده‌اند و ... . چرا اینطور شده است؟
سئوال خوبی است که چرا ریزسرویس‌ها، به ناگهان محبوب شده‌اند. حدود 4 سال پیش، یک کارگاه بود که افراد مختلفی از اجتماع‌‌های مختلف صنعت نرم‌افزار شرکت داشتند، بعنوان مثال برخی افراد از اجتماع طراحی برآمده از حوزه (Domain Driven Design)، برخی از اجتماع Restful، برخی از اجتماع تبادلات پیغام (Messaging) و ... . من در این کارگاه شرکت کردم. در آنجا برایم مشخص شد که سئوال‌هایی درباره اندازه برنامه‌ها هستند که زیاد تکرار می‌شوند. بعنوان مثال اینکه فلان برنامه ما طی 2 سال و نیم یا 5 سال یا 10 سال آنچنان بزرگ شده است که دیگر نمی‌توانیم آن را نگهداری کنیم؛ انجام هر تغییر عملکردی در آن سخت شده است یا اینکه ما می‌خواهیم بتوانیم این برنامه را بر روی ابر (Cloud) مستقر کنیم و بصورت نرم‌افزار بعنوان خدمت (Software as a Service) عرضه کنیم، اما در حال حاضر ممکن نیست.
ادامه مطلب ...

ارائه توسط: Markus Volter, Martin Lippert
مترجم: محمد علی بزرگ زاده 1393/09/30
در این اپیزود در مورد کار مربی‌گری و مشاوره و تفاوت آن‌ها صحبت می‌شود. مارکوس ولتر و مارتین لیپرت که هر دو بصورت حرفه‌ای در حوزه‌های مشخصی از مهندسی نرم‌افزار، کار مشاوره و مربی‌گری می‌کنند، تجربیاتشان را با شما به اشتراک می‌گذارند.
ما تصمیم نگرفته‌ایم که چه کسی سئوال کند و چه کسی مطالب را ارائه کند. می‌خواهیم به یک روش برنامه‌ریزی نشده و منعطف اینکار را بکنیم! وقتی می‌خواهیم در مورد مشاوره و مربی‌گری صحبت کنیم فکر می‌کنم ابتدا باید آنها را تعریف کنیم. آیا می‌خواهید امتحان کنید؟
بله، صادقانه بگویم که من یک تعریف واقعاً روشنی از تفاوت بین مشاوره و مربی‌گری ندارم. شاید بیشتر به این خاطر باشد که من در کارم، همواره به عنوان مربی عمل کرده‌ام اما در قرارداد ممکن است مشتری بیشتر به مشاوره علاقه نشان دهد.
وقتی به عنوان مربی عمل می‌کنید، چکار می‌کنید؟ شاید به این روش، برداشتی از آن پیدا کنیم.
در پروژه‌هایی که من شرکت داشته‌ام، کمک می‌کرده‌ام که تیم چیزی را یاد بگیرد و کاری که احتمالاً قبلاً انجام نداده را انجام دهد. به عنوان مثال، اینکه اسکرام را به عنوان یک فرآیند چابک (Agile Process) بکارگیرند. کمکشان می‌کردم که اسکرام را اعمال کنند. من واقعاً اسکرام را برای آنها انجام نمی‌دادم بلکه کمک‌شان می‌کردم که این کار را بکنند. شاید تفاوت همین باشد. شما به عنوان مشاور همواره کاری را برای مشتری انجام می‌دهید و چیزی را برایش آماده می‌کنید. چیزی را پیاده‌سازی می‌کنید یا نرم‌افزاری را می‌دهید یا مسئله‌ای را برای‌شان حل می‌کنید اما به عنوان مربی بیشتر کمک‌شان می‌کنید که خودشان کارها را انجام دهند.
این قطعاً همان روشی است که من برای مجزا ساختن این دو استفاده می‌کنم. من اگر پروژه‌ای داشته باشم که برای یک هفته یا یک ماه طول بکشد، عموماً آن را مربی‌گری می‌نامم زیرا همان کاری را که گفتی انجام می‌دهم. در واقع کمک‌شان می‌کنم که کار کنند اما مشاوره را معمولاً برای موردی بکار می‌برم که برای دو یا سه روز به سراغ تیم می‌روم و بوسیله آموزش کمک‌شان می‌کنم که در جهت خاصی هماهنگ شوند مثلاً تلاش می‌کنیم که اولین مرحله تولید یک DSL برای یک تنظیم‌کننده یخچال را بیابیم. برای من اینطور است که چیزهای کوتاه‌مدت که اساساً فقط شامل صحبت کردن و شاید تولید یک پروتوتایپ باشند را مشاوره می‌نامم و وقتی کاری را برای مدت طولانی‌تری انجام می‌دهم و مانند یک عضو واقعی تیم هستم و کار واقعی را انجام می‌دهم یا اینکه برای مدت طولانی کمک‌شان می‌کنم، آن را مربی‌گری می‌نامم اما روشن است که تعریف واقعاً روشنی نیست.
بله، خصوصاً در کارهای روزمره.
بله، منظورم این است که فکر می‌کنم مهم باشد که این موضوع مربی‌گری و مشاوره‌‌ای که داریم در موردش صحبت می‌‌‌کنیم را از رفتار آدم‌های کاسب کلاسیک متمایز کنیم که بیشتر با خودجلوه‌گری همراه است! :-)
بله، چون این چیزها برای ما مهم نیست و این کارها را خیلی دوست نداریم! :-)
وقتی ما در مورد مشاوره صحبت می‌کنیم واقعاً منظورمان کار عملی نرم‌افزار است نه امور تجاری.
بله، من هم همینطور.
فکر می‌کنم یکی از اهداف اصلی مشاوره و مربی‌گری، انتقال دانش است. می‌خواهید به تیمی کمک کنید که چیزی را فرا بگیرد یا در انجام آن خوب شود. درسته؟
بله، فکر می‌کنم بین مشاوره و مربی‌گری با یک قرارداد ساده اجاره افراد (Body Leasing) -که بعلت نبود مثلاً نیروی کافی برای توسعه کد بسته می‌شود- تفاوت زیادی وجود دارد.
بسیار خوب. آنچه می‌خواهیم انجام دهیم این است که کمی توضیح دهیم که به عنوان مربی یا مشاور چه می‌کنیم. بعد از آن می‌توانیم کمی نظرمان را در این مورد توضیح دهیم که چه صلاحیت‌های ضروری برای افرادی که می‌خواهند این شغل را داشته باشند، وجود دارد. این خطر را دارد که اینطور به نظر برسد که می‌خواهیم به شما بگوییم چقدر وارد هستیم اما منظورمان این نیست. راستش ما اخیراً نامه‌ای دریافت کردیم که ارسال‌کننده به ما یادآوری کرده بود که با این وجود باید این اپیزود را اجرا کنیم. بخاطر همین، دور هم جمع شدیم و اجرایش کردیم زیرا بعضی افراد واقعاً دوست دارند در مورد این موضوع بشنوند.
بسیار خوب، لطفاً در مورد یکی دو نمونه پروژه‌ (که درگیرش بوده‌اید) و کارهای روزمره‌اش بگویید.
یکی از نمونه پروژه‌ها برای من این بوده است که با تیمی همراه شده‌ام که می‌خواستند روش‌های چابک مثلاً اسکرام را به خدمت بگیرند. آنها واقعاً می‌خواستند این حس را پیدا کنند که برای آنها بکارگیری اسکرام یعنی چه؟ آنها من را دعوت کردند و ما دوسه روز در مورد اینکه اسکرام چیست و چطور تعریف شد و خصوصاً اینکه انجام اسکرام برای آنها چه معنی می‌دهد صحبت کردیم یعنی در مورد این ترجمه دانش تئوری به زندگی عملی روزمره (صحبت کردیم). ما حسی پیدا کردیم که اسکرام به چه معنی است و چطور می‌توانند آن را آغاز کنند و چطور می‌توانند آن را ادامه دهند. اینکار عموماً بیشتر با یک روش کارگاه مانند انجام می‌شود. کنار هم و بدون میز می‌نشینیم و از تخته‌های الصاقی (Pin board) یا وَرَقی (Flip chart) استفاده می‌کنیم. بصورت تعاملی مسائل را با گروه بحث می‌کنیم.
شما گفتید «گروه». آنها چه نوع افرادی هستند؟
فکر می‌کنم خیلی متنوع باشد: توسعه‌دهنده‌ها، مدیر پروژه‌ها، گاهی حتی مدیران محض (Pure Manager). فکر می‌کنم دامنه‌اش به همه نقش‌هایی که در شرکت‌ها برای توسعه نرم‌افزار می‌شناسید، بکشد. مشتری‌های من عموماً شرکت‌های بزرگ بوده‌اند و داخل خود ساختارهای سلسله‌مراتبی داشته‌اند و از من کمک می‌خواسته‌اند. در این نوع شغل‌های دوروزه کارگاهی یک دستور جلسه ثابت یا 200 صفحه اسلاید آماده نمی‌کنید که همه وقت را برایشان صحبت کنید بلکه کم و بیش بصورت تعاملی به افراد توضیح می‌دهید که معنای چیزی چیست و چه سئوال‌هایی در موردش هست. من دوست دارم با فهرستی از سئوال‌ها آغاز کنم. مشتریان، سئوال‌های بیشتری هم می‌افزایند. در ابتدای کارگاه، به آنها می‌گوییم که سئوال‌هایتان چیست و مهم‌ترین چیزها و بزرگترین سئوال‌هایی که در ذهنتان دارید چیست. ما سئوال‌ها را اولویت‌بندی و فهرست می‌کنیم و گام به گام به سراغ همه آنها می‌رویم. در حین پاسخ دادن به این سئوال‌ها، مقداری اصطلاحات و دانش تئوری را مطرح می‌کنم. (مثلاً می‌گویم که) الان باید در مورد نحوه گذشته‌کاوی (Retrospective) کردن (نام یکی از جلساتی که در اسکرام برگزار می‌شود - مترجم) صحبت کنم یا الان باید در مورد چگونگی برنامه‌ریزی‌ Sprint (در اسکرام، دوره‌ها Sprint خوانده می‌شوند - مترجم) صحبت کنم اما این تکه بحث‌های تئوری بیشتر اینطور هستند که به هنگام لزوم ارائه می‌شوند.
ادامه مطلب ...