ایران‌تلنت نباشیم یا چطور ریدیزاین (اجایل) انجام دهیم

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

ادامه‌ی نوشته “ایران‌تلنت نباشیم یا چطور ریدیزاین (اجایل) انجام دهیم”

وقتی از زورق حرف می‌زنیم از چی حرف می‌زنیم

 

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

ادامه‌ی نوشته “وقتی از زورق حرف می‌زنیم از چی حرف می‌زنیم”

دویدن

تجربه‌ی کاملی دارم از راه‌های مختلف تلاش برای مداوم دویدن. همشون شکست خورد. تا پنج ماه پیش که کم کم راه‌حلش را فهمیدم. این نوشته را برای کسانی می‌نویسم که مثل من دوست دارن بدون ولی نمیدونن چطور یا از کجا باید شروع کرد. تو این نوشته توضیح می‌دم چطور از صفر شروع کردم و الان می‌تونم ده کیلومتر را در یک جلسه نسبتا راحت بدوم.
ادامه‌ی نوشته “دویدن”

چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت دوم

در یاداشت قبلی نوشتم که چطور کانتینر دیتابیس و اپلیکیشن را در محیط دولوپمنت اجرا کنیم. در این یادداشت اپلیکیشن را به پروداکشن انتقال می‌دهیم و CI و CD مختصری را پیاده می‌کنیم.

ادامه‌ی نوشته “چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت دوم”

چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت اول

در سال ۱۹۵۶ مالکوم مک‌لین اولین کانتینر برای حمل توسط کشتی‌های باربری را اختراع کرد. قبل از اون بارها با  پانزده برابر هزینه بیشتر به طور دستی بارگیری و تخلیه می‌شدند. با اختراع کانتینر مشکل دزدی از بارها، از دست رفتن بارها حین جابجایی، مشکل چیدمان بهینه در کشتی‌ها و از همه مهمتر کند بودن پروسه بارگیری فراموش شد. یک اختراع انقلابی که صنعت را به کلی متحول کرد. در دنیای نرم‌افزارها اگر از VM‌ها بگذریم، تکنولوژی داکر به نظر می‌رسه همین تاثیر را خواهد داشت. در نهایت تیم‌های توسعه نرم‌افزاری فقط مسئول کد نوشتن نیستند. مسئولیت مهم‌تر ایجاد پروسه صحیح آپدیت‌های مداوم با کمترین زمان و هزینه‌ی روانی و مالی است.

در این نوشته نشون میدهم چطور یک پروژه روبی (اپلیکیشن به اضافه دیتابیس) را به داکر منتقل کنیم. در نوشته بعدی ایجاد روال آپدیت پروداکشن را بررسی می‌کنم.
ادامه‌ی نوشته “چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت اول”

تصمیم گیری بر اساس اطلاعات با کمک کیبانا و الستیک

 

همیشه گفته می‌شه تیم‌ها باید بر اساس اطلاعات تصمیم گیری کنند یا به اصطلاح data-driven باشند. فکر نمی‌کنم کسی با این ایده مشکلی داشته باشه. پس چرا کمتر جایی می‌بینیم واقعا بر اساس اطلاعات تحلیل کنند و تصمیم بگیرند؟

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

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

آزمونی کوتاه برای سنجش سلامت تیم‌

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

ادامه‌ی نوشته “آزمونی کوتاه برای سنجش سلامت تیم‌”

چطور با دولوپرها کار کنیم؟

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

ادامه‌ی نوشته “چطور با دولوپرها کار کنیم؟”

سایت رامین

ramin
داستان اینجوری شروع شد که رامین ایده‌ای داشت در مورد تایم‌لاین و این‌که چطور این رو پیوند بده با سایت شخصی‌اش. از طرفی من هم دنبال پروژه ای بودم که عصرها و آخر هفته‌ها بهش برسم. اینطوری شد که شروع کردیم به کار و سایت ساخته شد.

ادامه‌ی نوشته “سایت رامین”

بدون سازمان اجایل، اسکرام امکان پذیر است؟

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

چه اتفاقی می‍افتد اگر افراد کلیدی سازمان درک مناسبی از این فرهنگ نداشته باشند؟
ادامه‌ی نوشته “بدون سازمان اجایل، اسکرام امکان پذیر است؟”