شی‌گرایی:
چه خوب است که بهانه‌ای پیدا کردم تا از برادر، دوست و استاد عزیزم، علی آقای عبداللهی، تشکر کنم.
یادم می‌آید بعد از این که فهمیدم شی‌گرایی (Object Orientation) به معنای واقعی چیست و چه کاربردی دارد، علاقه‌ی من به دنیای نرم‌افزار دوچندان شد. این داستان بر می‌گردد به سال دوم یا سوم دانشگاه. علی آقای عبداللهی که هم در دبیرستان و هم در دانشگاه سال بالایی ما بودند، نقش اصلی این داستان هستند. یک روز که در خوابگاه با ایشان صحبت می‌کردم صحبت از شی‌گرایی شد و ایشان از یک کتابخانه‌ی نرم‌افزاری صحبت کرد که خودشان نوشته بود. بخشی از این کتابخانه، یک کلاس با زبان سی‌پلاس‌پلاس بود که موقع ایجاد (new) دو نقطه از صفحه‌ی نمایش (مانیتور) را دریافت می‌کرد، محتویات صفحه‌ی نمایش بین این دو نقطه را ذخیره می‌کرد و موقع حذف این کلاس (delete) محتویات ذخیره شده، یعنی همان صفحه‌ی قبلی دوباره روی صفحه‌ی نمایش نوشته می‌شد. کاربرد این برنامه این بود که در محیط سیستم عامل داس (MS DOS)، شما می‌توانستید نرم‌افزاری بنویسید که در آن، به راحتی پنجره‌ها روی هم باز و بسته شوند. فقط و فقط این کد، یک بار نوشته شده بود و امکان ارث بری و بقیه‌ی قابلیت‌های شی‌گرایی نیز در آن وجود داشت. دیدن این کد و برنامه، جرقه‌ای بود که درک کنم شی‌گرایی چیست و بیش از پیش از آن لذت ببرم. لذتی که هنوز هم ادامه دارد. سپاسگزارم آقای مهندس عبداللهی عزیز.

پایتون: چه زبان عجیب و غریبی
روزهای اولی که کدهای پایتون را می‌دیدم، تحت تاثیر زبان‌هایی مانند س‌پلاس‌پلاس، سی‌شارپ و جاوا، مدام این جمله در ذهنم تکرار می‌شد: “این چرا این جوریه!”. 🙂 “پایتون هم شد زبان برنامه‌نویسی!” 🙂 . مانند اکثر دوستانم به تجربه آموخته بودم که وقتی با زبان جدیدی رو به رو می‌شوید، باید صبور باشید.

باغبان گر پنج روزی صحبت گل بایدش
بر جفای خار هجران صبر بلبل بایدش

ای دل اندر بند زلفش از پریشانی منال
مرغ زیرک چون به دام افتد تحمل بایدش

پایتون: زندگی شیرین می‌شود!
برنامه‌نویسی با کتابخانه‌های پایتون مانند نام‌پای (numpy) و پانداس (pandas) باعث شد کم‌کم این جمله‌ها جایگزین جمله‌های قبلی شود: “وای! چقدر قشنگه این زبان” 🙂 . “اوف! چقدر برنامه با این زبان راحته!” 🙂 هر چند می‌دانستم که اول راه است و آموختنی‌ها بسیار و تمام‌نشدنی.

رند عالم سوز را با مصلحت بینی چه کار
کار ملک است آن که تدبیر و تأمل بایدش

تکیه بر تقوی و دانش در طریقت کافریست
راهرو گر صد هنر دارد توکل بایدش

با چنین زلف و رخش بادا نظربازی حرام
هر که روی یاسمین و جعد سنبل بایدش

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

سخنرانی اول: James Powell: So you want to be a Python expert?
سخنرانی دوم: Joel Grus: Learning Data Science Using Functional Python

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

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

ساقیا در گردش ساغر تعلل تا به چند
دور چون با عاشقان افتد تسلسل بایدش

The concept that keeping staff busy might be an ineffective way of managing will be so counterintuitive to many managers that further justification is probably needed.

There are several aspects to excessive WiP that are relevant to effectiveness, among them multi-tasking, context switching, focus, and long lead times.

Recent research on the brain has shown that one of the most expensive things your brain does (in terms of energy consumption) is changing tasks (Levitin,2015). Doing it constantly is draining and ineffective.

Focusing on one task, for periods of around 90 minutes at a time, enables your brain to get into the state known as flow. That’s when your most effective work gets done, and amazingly, it makes you feel good while tiring you out less.

Periods of flow are not your most creative periods, however. Focus is your brain’s mode when you“get things done,” but in your brain’s default mode, your mind flits between ideas. This is when you make connections between things and where creativity springs from. It is also where learning and long-term memories are created.

To be effective, you need time at work to be in both these modes; constant pressure with multiple unfinished tasks is damaging to both modes and results in poorer outcomes. For more on this topic, see (Benson, 2014).

Essential Kanban Condensed, Andy Carmichael and David J. Anderson, 2015

Read this book: Stop Starting, Start Finishing

سوگیری‌های شناختی (به انگلیسی: Cognitive bias)، خطاهایی هستند ذهنی که به صورتی نظام‌مند به گرایش، نگرش، وهم یا باوری غلط منجر می‌شوند و در تصمیم‌گیری، استدلال، ارزیابی، یادآوری، ادراک و شناخت افراد تاثیر می‌گذارند. سوگیری‌ شناختی یکی از مباحث مهم علوم شناختی است. علوم شناختی تعداد بسیاری از این خطاهای ذهنی را شناسایی کرده و زوایای متفاوتی از شرایط ظهور و بروزشان را بررسی کرده است. فهرست انواع خطاهای شناختی بسیار طولانی است.

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

Credit: Scott Galloway @profgalloway

No matter how educated, talented or rich you are, how you treat people ultimately tells all. Vala Afshar

Ethical debt is the implied cost of not considering social/ethical implications or harms now, assuming you can fix them after you find out what they are.

As Yonatan Zunger says “Software engineers continue to treat safety and ethics as specialities, rather than the foundations of all design.”

Reference: Casey Fiesler, CU Denver Data Science Symposium 2020

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

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

سوال 2:
توی تیم اسکرام یک سری ارزش ها و باور ها وجود داره: تعهد، شجاعت، تمرکز، باز بودن، احترام.
این ارزش ها رو چگونه میشه به تیم آموخت؟ آیا اسکرام مستر علاوه بر نظارت به فرایند باید طی جلساتی این ارزش ها رو آموزش بده و یا کتاب هایی معرفی کنه که از اون منابع یاد گرفته بشه. چون درک ارزش ها از فرد به فرد دیگر متفاوت میشه در دنیای واقعی. به عنوان مثال یک نفر تعهد رو چیزی میفهمه و دیگری یک چیز دیگر!
مفاهیم مشترک که قرار هست بین تیم باشه چگونه میتوانیم رواج بدهیم؟

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

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

سوال 5:
با توجه به اینکه در شرکت های نرم افزاری نیرو ها در حال جابه جایی هستند چگونه می‌توان فرهنگ چابک رو یکسان سازی کرد ؟

گزیده:

The greatest risk we face in software development is that of overestimating our own knowledge.
Jim Highsmith

سوال 6:
چرا در برخی منابع و مراجع نقش‌های کاری یک تیم چابک را به ۳ نقش مالک محصول- اسکرام مستر و توسعه‌دهنده محدود می‌کنند و اشاره‌ای به نقش‌های تحلیل‌گر کسب‌و کار/ نرم‌افزار، تستر و … نمی‌شود. شاید در یک تیم چابک فرد توسعه‌دهنده لزوما به مهارت‌های دیگر مسلط نباشد که آنها را در نقش توسعه‌دهنده بخواهیم ادغام کنیم.
از طرف خانم بربند

عزیزانم!
نمی‌خواهم با نوشته‌هایم حال‌تان را بد کنم. دوست دارم هر چه می‌گویم از شادی‌ها بگویم و حتی برای لحظه‌ای خوشحال‌تان کنم. ولی شاید یادآوری بعضی چیزها گاهی ضروری باشد.
داشتم پیام‌های توییتر رو مرور می‌کردم. این پیام را که یکی از دوستانم لایک کرده بود دیدم.

توییت اول:
به نظر می‌رسید که نویسنده‌ی بنده‌خدا زندگی‌اش به دنیا نیست. در جنگ با بیماری کبد پیروز نشده است.

This looks like the end. My liver has so much cancer that it is collapsing my bile ducts. My bilirubin is on it’s way to true liver failure levels. Insurance is denying treatments. I’m still trying but things look very bad.

توییت دوم:
حالا در توییت دوم به انسان‌ها توصیه‌هایی کرده که واقعا تاثیرگذار و عمیق است.

This all brings me back to my earlier post. Life is short – enjoy your good days. Hug your family. Don’t waste time on things that don’t interest you. Love each other. Forgive each other. Find balance in your life and maintain it.

توییت سوم:

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

It’s a sunny day and I feel like sh*t but this is not the end of it. Maybe this drug works or maybe not but I’ll keep on going until my options are shot. Wishing for another day where I can take a walk with my family.

آرزوی سلامتی و بهبود برای ایشان و همه‌ی بیماران دارم. ای کاش می‌شد کاری کرد!
مراقب خودتان باشید.