همه‌ی نوشته‌های غلامرضا صابری تبریزی

چاپ هشتم کتاب برنامه‌نویسی با پایتون

تصویر جلد کتاب برنامه نویسی با پایتون ۳ ترجمه غلامرضا صابری تبریزی

چاپ هشتم کتاب برنامه نویسی با پایتون هم به بازار آمد. نام دقیق این اثر «برنامه نویسی با پایتون ۳» است. چاپ اول این کتاب (همون طور که در این پست) توضیح دادم سال ۱۳۹۳ به بازار ارائه شد، و «برنامه نویسی با پایتون» نام داشت. با به روز شدن نسخه اصلی کتاب، و ترجمه اون انتشارات تصمیم گرفت اسم ویرایش دوم و چاپ سوم کتاب را به «برنامه نویسی با پایتون ۳» تغییر دهد. چاپ هشتم این کتاب هم با همین نام به بازار ارائه شده است (چاپ هشتم با احتساب دو بار چاپ شدن ویرایش اول و ششمین چاپ ویرایش دوم کتاب). امیدوارم مفید واقع بشه. می تونید کتاب رو به صورت آنلاین از نشر دانشگاهی کیان سفارش بدین. به علاوه میتوانید نسخه الکترونیکی کتاب رو هم از وب سایت فیدیبو خریداری کنید.

مطالعه رایگان یک فصل از کتاب برنامه نویسی با پایتون ۳

 

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

درخت

 

دانه از آن زمان كه در خاك است
با دلش آفتاب ادراك است

سرگذشتِ درخت می‌داند
رقم ِسرنوشته می‌خواند

گرچه با رقص و ناز در چمن است
سرنوشت ِ درخت، سوختن است…

آن درختِ کُهن منم كه زمان
بر سرم راند بس بهار و خزان

دست و دامن تُهی و پا در بند
سر كشیدم به آسمانِ بلند.‌

شبم از بی‌ستارگی، شبِ گور
در دلم پرتو ِ ستاره‌ی دور

آذرخشم گَهی نشانه گرفت
گه تگرگم به تازیانه گرفت

بر سرم آشیانه بست كلاغ
آسمان، تیره گشت چون َپر ِ زاغ

مرغ ِ شبخوان كه با دلم می‌خواند
رفت و این آشیانه خالی ماند…

آهوان، گم شدند در شبِ دشت
آه از آن رفتگان ِ بی ‌برگشت

گر نه گل دادم و بر آوردم
بر سری چند سایه گُستردم

دست هیزم شكن فرود آمد
در دل ِهیمه بوی دود آمد

كُنده‌ی پیر ِ آتش اندیشم
آرزومند ِ آتش ِ خویشم…

 

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

کار عاطفی، مدلهای رشد اخلاقی و اسکرام

اقوام روزگار به اخلاق زنده اند، قومی که گشت فاقد اخلاق مردنی است – محمد تقی بهار

یکی از مباحث روان شناسی رشد (Developmental Psychology) مدل های رشد اخلاقیات در افراد است. یکی از مدلهای مطرح در این زمینه مدل پیاژه (Jean Piaget) است. پیاژه از اولین روان شناسهایی بود که به بررسی فرآیند رشد شناختی و اخلاقی افراد پرداخت. او باور داشت درجه رشد شناختی فرد بر قضاوتهای اخلاقی او موثر است. از نظر پیاژه فرآیند رشد اخلاقی چهار مرحله دارد:

  1. پیش از پنج سالگی بچه ها موقع بازی سایرین را در نظر نمیگیرند و اگر قاعده و قانون خاصی را رعایت کنند صرفا جهت پیشبرد اهداف خودشان است
  2. با شروع پنج سالگی کودک یاد میگیرد که باید مجموعه قوانینی را رعایت کند. در این مرحله، این قوانین در نظر کودک وحی منزل هستند و نمی توان آنها را تغییر داد. در این مرحله بچه ها بیشتر بر اساس نتایج یک کار در مورد آن قضاوت می کنند و نه نیت آن
  3. در مرحله بعدی توسعه اخلاقی کودک یاد میگیرد قوانینی که باید رعایت کند وحی منزل نبوده و قواعد اجتماعی هستند که در صورت توافق اعضای گروه یا جامعه می توان آنها را تغییر داد. در این مرحله افراد نیت کارها را هم در نظر میگیرند
  4. در مرحله آخر فرآیند رشد اخلاقی فرد می تواند درباره موقعیت هایی که تا به حال با آنها مواجه نشده هم قواعد اخلاقی بسازد و درباره قواعد اخلاقی استدلال کند و عواقب اجتماعی تصمیماتش را در نظر میگیرد

علاوه بر مدل رشد اخلاقی پیاژه می توان مدل لارنس کولبرگ (Lawrence Kohlberg) را هم در نظر گرفت. در مدل کولبرگ فرآیند رشد اخلاقی به سه مرحله کلی تقسیم می شود:

  1. مرحله پیش قراردادی (Pre-Conventional Stage): در این مرحله فرد قوانین اخلاقی را تنها برای اجتناب از تنبیه شدن و به دست آوردن جایزه دنبال می کند. در این مرحله، اخلاق اصطلاحا با مکانیزمهای بیرونی (پاداش و تنبیه) کنترل می شود و فرد در رعایت قوانین اخلاقی فقط منفعت خودش را در نظر میگیرد
  2. مرحله قراردادی (Conventional Stage): در این مرحله تمرکز از منفعت طلبی بر رابطه با سایرین قرار میگیرد. فرد قوانینی که توسط مدرسه، پدر، مادر و دولت وضع شده اند را رعایت می کند تا مورد تایید آنها واقع شود و بقیه او را انسان خوب و شایسته ای بدانند
  3. مرحله پسا قراردادی (Post-Conventional Stage): در این مرحله فرد می تواند درباره قواعد اخلاقی استدلال کند و موقع تصمیم گیری می تواند از زاویه دید بقیه هم به قضایا بنگرد و نفع و ضرر بقیه را هم در نظر بگیرد

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

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

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

 

 

حافظ

دیدی که یار، جز سَرِ جور و ستم نداشت
بشکست عهد، وز غمِ ما هیچ غم نداشت

یا رب مگیرش ار چه دلِ چون کبوترم
افکند و کُشت و عزتِ صیدِ حرم نداشت

بر من جفا ز بختِ من آمد وگرنه یار
حاشا که رسمِ لطف و طریقِ کَرَم نداشت

با این همه هر آن که نه خواری کشید از او
هر جا که رفت، هیچ کَسَش محترم نداشت

ساقی بیار باده و با محتسب بگو
انکارِ ما مَکُن که چنین جام، جم نداشت

هر راهرو که ره به حریمِ درش نبرد
مسکین بُرید وادی و ره در حرم نداشت

حافظ بِبَر تو گویِ فصاحت که مدعی
هیچش هنر نبود و خبر نیز هم نداشت

 

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

اندرباب شخصیت، آزمونهای فرافکن و مصاحبه های فنی

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

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

  1. چگونه می توان لیست جامع و کاملی از ویژگی های شخصیتی انسانها به دست آورد؟
  2. چگونه می توان شخصیت افراد را ارزیابی کرد؟

تا آنجا که من میدانم یکی از راههای به دست آوردن لیستی جامع از همه ویژگی های شخصیتی، بررسی دایره لغات یک زبان است. آلپورت و آدبرت در دهه ۳۰ این کار را برای زبان انگلیسی انجام دادند. آنها تمامی کلماتی که در فرهنگ لغات انگلیسی به ویژگی های شخصیتی ارجاع داشت را گردآوری کردند. در مجموع به ۱۸۰۰۰ کلمه رسیدند. در ادامه سعی کردند کلمات مشابه را حذف کنند و در نهایت ۴۵۰۰ کلمه به دست آوردند که در برگیرنده همه ویژگی های شخصیتی است.

اما ۴۵۰۰ هنوز عدد بسیار بزرگی است. در نتیجه، محققین مختلف برآن شدند تا این لیست را با خلاصه سازی هرچه بیشتر (به روشهای گوناگون) کاهش دهند. در نهایت این کار منتج به لیست های متعددی شد. در ادامه برخی از مهمترین آنها را آورده ام:

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

  • استفاده از پرسش نامه های ارزیابی شخصیت (Personality Inventories): در این حالت پرسش نامه ای با سوالات متعدد در اختیار شما قرار می گیرد. هر دسته از سوالات این پرسش نامه، سعی در سنجش یکی از ویژگی های شخصیتی شما دارند و در نهایت با جمع نمرات هر قسمت نتیجه ای در اختیارتان قرار می دهند. برخی از شناخته شده ترین انواع این پرسش نامه ها عبارتند از: آزمون MMPI، آزمون کتل و آزمون میلون
  • استفاده از روشهایی مثل Q-Sort: در این حالت از یک فرد ارزیابی کننده خواسته می شود حدود ۱۰۰ عدد کارت را که حاوی جملاتی درباره ویژگی های شخصیتی شما است مرتب و امتیاز دهی کند. خروجی این مرتب سازی لیست مهمترین ویژگی های شخصیتی شما است
  • استفاده از تست های فرافکن (Projective test): در این نوع تست ها که مبنا و اساس آنها نظریه تداعی آزاد (Free Association) فروید است یک محرک مبهم به فرد ارائه می شود و از او خواسته می شود نظرش را درباره این محرک مبهم بیان کند. فرد با بیان نظرش، احساسات و افکار نهان خود را آشکار می کند. برای مثال، در تست TAT تعدادی تصویر مبهم مثل شکل زیر به فرد نشان داده می شود و از او خواسته می شود درباره اتفاقی که در این تصاویر در حال رخ دادن است توضیح دهد. دو مورد از شناخته شده ترین تست های فرافکن تست رورشاخ (Rorschach test) و تست TAT است. از دیدگاه تئوریک می توان از هر محرک مبهمی برای این تست ها استفاده کرد

خوب در ابتدای مقاله درباره مشاهده خودم در مورد استفاده از تست های فرافکن در جلسات مصاحبه گفتم. حال که مختصری درباره این تست ها توضیح دادم میرسیم به میزان کارایی این تست ها و قابل اعتماد بودن (Reliability) و اعتبار (Validity) آنها. به عبارت دیگر، در این قسمت می خواهم به این سوال پاسخ دهم که آیا می توان با پرسیدن یک یا چند سوال مبهم از مصاحبه شونده (و نه با یک تست فرافکن استاندارد مثل تست رورشاخ یا TAT) به ویژگی های شخصیتی او پی برد؟ پاسخ به این سوال را به دو قسمت تقسیم می کنم. ابتدا بهتر است به بررسی تست های فرافکن استاندارد بپردازیم و سپس به بررسی پرسیدن یک یا چند سوال خواهیم پرداخت:

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

خوب این بود خلاصه آنچه میخواستم درباره استفاده از تست های فرافکن بگویم. امیدوارم مورد استفاده قرار بگیرد.

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

رودکی: هر چه بادا باد!

شاد زی با سیاه چشمان، شاد
که جهان نیست جز فسانه و باد

زآمده شادمان بباید بود
وز گذشته نکرد باید یاد

من و آن جعد موی غالیه بوی
من و آن ماهروی حورنژاد

نیک بخت آن کسی که داد و بخورد
شوربخت آن که او نخورد و نداد

باد و ابر است این جهان، افسوس!
باده پیش آر، هر چه باداباد

شاد بوده‌ست از این جهان هرگز
هیچ کس؟ تا از او تو باشی شاد؟

داد دیده‌ست از او به هیچ سبب
هیچ فرزانه تا تو بینی داد؟

فرهنگ سازمانی

آخرین چیزی که نظر ماهی را جلب می کند آب است (رالف لینتون)

به زبان، نمادها، ابزارها، زبان بدن، ارزش ها و نرم هایی (Norms) که یک گروه را از گروهی دیگر متمایز می کند و از نسلی به نسل دیگر منتقل می شود فرهنگ (Culture) می گویند. فرهنگ مثل لنزی است که با آن دنیای اطرافمان را میبینیم. این لنز آنقدر شفاف است که گاهی وجودش را از یاد میبریم و فکر می کنیم آنچه در نظر داریم واقعیت جهان است و تنها راه نگاه به جهان راه و روش جامعه ای (گروهی)  است که عضو آن هستیم. اینجاست که فرهنگ تبدیل می شود به ابزار قضاوت سایر گروه ها و پای قوم مداری (Ethnocentrism) به میان می آید.

اما فرهنگ سازمانی چیست؟ فرهنگ سازمانی هم به زبان ساده به روشی گفته می شود که کارها را انجام میدهیم تا موفق شویم. اما چرا این فرهنگ اینقدر مهم است؟ فرهنگ یک سازمان کجاها نمایان می شود؟ یکی از فاکتورهای مهم موفقیت سازمان ها همین فرهنگ سازمانی است. این فرهنگ طبق برخی منابع در سه جا خودش را نشان می دهد:

  1. مسائل بیرونی : تبلور فرهنگ سازمانی در مسائل بیرونی را هر مشاهده کننده دقیقی می تواند در مواردی نظیر استراتژی، اهداف سازمانی، ساختار، فرآیندها و غیره ببیند
  2. مسائل درونی:  تبلور فرهنگ سازمانی در مسائل درونی را فقط افرادی که برای مدتی در آن سازمان کار کرده اند می توانند دریابند. منظور از مسائل درونی مواردی نظیر زبان مشترک و مفاهیم، هویت سازمانی و مرزبندی گروه ها، طبیعت آتوریتی در سازمان و روابط اعضای آن و چگونگی تقدیر از خدمات است
  3. مفروضات کلی و نهان: درک این مفروضات زمان بر است و گاهی غیرممکن. اما مفروضات کلی و نهان یک سازمان به طور عمیقی بر فرهنگ آن اثر می گذارند. منظور از این مفروضات مواردی نظیر رابطه انسان و طبیعت، مفهوم واقعیت و حقیقت، طبیعت انسان و سایر موارد فلسفی این چنین است

همان طور که گفتم یکی از عوامل بسیار مهم موفقیت و شکست سازمان ها فرهنگ سازمانی است. به نظرم یکی از مهمترین اجزای فرهنگ سازمانی “مفروضات کلی و نهان” مدیریت و اعضای یک سازمان است. برای مثال، اگر فرض کنید انسان ذاتا موجودی دروغگو، حیله گر و پلید است همه جای سازمان از دوربین و میکروفون استفاده می کنید که نکند خطایی از او سر بزند. در عوض اگر نگاهتان به انسان موجودی متعالی و دارای قوه تعقل و انتخاب باشد از روشهای دیگری استفاده خواهید کرد …

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

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

 

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

 

چاپ هفتم کتاب برنامه‌نویسی با پایتون

تصویر جلد کتاب برنامه نویسی با پایتون ۳ ترجمه غلامرضا صابری تبریزی

چاپ هفتم کتاب برنامه نویسی با پایتون هم به بازار آمد. نام دقیق این اثر «برنامه نویسی با پایتون ۳» است. چاپ اول این کتاب (همون طور که در این پست) توضیح دادم سال ۱۳۹۳ به بازار ارائه شد، و «برنامه نویسی با پایتون» نام داشت. با به روز شدن نسخه اصلی کتاب، و ترجمه اون انتشارات تصمیم گرفت اسم ویرایش دوم و چاپ سوم کتاب را به «برنامه نویسی با پایتون ۳» تغییر دهد. چاپ هفتم این کتاب هم با همین نام به بازار ارائه شده است (چاپ هفتم با احتساب دو بار چاپ شدن ویرایش اول و پنجمین چاپ ویرایش دوم کتاب). امیدوارم مفید واقع بشه. می تونید کتاب رو به صورت آنلاین از نشر دانشگاهی کیان سفارش بدین.

مطالعه رایگان یک فصل از کتاب برنامه نویسی با پایتون ۳

 

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

اسکرام‌نامه

در سالهای اخیر استفاده از اسکرام (Scrum) به عنوان روشی چابک (Agile) برای توسعه نرم‌افزار رواج زیادی یافته. من هم مثل بسیاری از توسعه‌دهندگان در تیمهای چابک متعددی حضور داشته‌‌ام و شاهد پیاده‌سازی‌ها و تفاسیر خوب، بد و زشت مختلفی از اسکرام بوده‌ام.

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

آغاز

همه چیز خیلی عادی شروع شد. مثل همه روزهای قبل با عنوان “توسعه‌دهنده/محقق تکنیکی” به شرکت رفتم. آن روز با مدیر پروژه‌ جلسه مختصری داشتم. ایشان از من خواستند به علت پاره‌ای از مشکلات و درخواست اعضای تیم به سراغ اسکرام برویم. به علاوه، پیشنهاد دادند کتاب Essential Scrum: A practical guide to the most popular agile process اثر Kenneth Rubin را برای آشنایی هر چه بیشتر با اسکرام بخوانم. مدتها قبل از این روز، کتاب Agile اثر Bertrand Meyer را خوانده بودم (که باید اعتراف کنم تا حدی کسالت آور، اما بسیار ارزشمند است). با پیش فرض کسالت آور بودن کتاب Rubin به مطالعه آن پرداختم. منبع بسیار خوبی بود و بر خلاف تصور من بسیار جذاب بود. این منبع دانش کافی برای آغاز پیاده سازی اسکرام را در اختیارم قرار داد. اما پیش از آغاز پیاده سازی سوالی برایم مطرح بود: چرا اعضای تیم درخواست استفاده از اسکرام را داده بودند؟

مصاحبه و مشخص شدن روند شکست کارها

برای پاسخ به این سوال که: “چرا اعضای تیم درخواست استفاده از اسکرام را داده بودند؟”؛ مصاحبه‌ای با آنها ترتیب دادم. هر چه باشد در کارشناسی ارشد مدتی را صرف یادگیری تفکر طراحی (Design Thinking) کرده بودم (برای آشنایی بیشتر با تفکر طراحی می‌توانید به این پست وبلاگ مراجعه کنید). مهمترین پیام تفکر طراحی همدلی (Empathy) و حل مشکل واقعی کاربران یک سیستم است. در این مصاحبه نکات خوبی از مشکلات تیم به دست آوردم:

  • افراد دوست داشتند تصویر کلی آنچه در حال اتفاق افتادن است را در اختیار داشته باشند
  • اعضای تیم دوست داشتند با هم تعاملات بیشتری داشته باشند (تیم‌تر باشند)
  • آنها دوست داشتند در بازه‌های زمانی مشخصی که کوتاه‌تر از چند ماه است بازخورد کارهایشان را از مشتری‌ها/ذی‌نفعان دریافت کنند
  • افراد دوست داشتند مکانیزمی در اختیار داشته باشند تا مشکلاتشان را در بازه‌های زمانی مشخص به گوش بقیه برسانند
  • و …

نتیجه مصاحبه مرا تا حدی قانع کرد که اسکرام ممکن است بتواند بعضی از این مشکلات را حل کند.

بعد از مصاحبه سراغ پیاده‌سازی اسکرام رفتم. برای آنکه مفاهیم کتاب Rubin را فراموش نکنم یک MindMap از کتاب تهیه کردم تا هر وقت با ابهامی مواجه می‌شوم به آن رجوع کنم.

برای پیاده سازی اولیه لازم بود روند شکستن پروژه و چگونگی مستندسازی نیازمندی‌ها را مشخص کنم. اسکرام استاندارد مشخصی برای مستندسازی نیازمندیها ندارد. در اکثر منابع از جمله Rubin پیشنهاد شده از User Story ها بدین منظور استفاده شود. برای اینکه با User Storyها آشنا شوم به منبع دیگری مراجعه کردم: User Stories Applied اثر Mike Cohn. نویسنده در این کتاب به خوبی نحوه استفاده از User Storyها را شرح می دهد. در ادامه ساختاری چهار سطحی برای شکستن پروژه‌ها طراحی کردم. در این ساختار هر پروژه به مجموعه‌ای اپیک (Epic) می‌شکند. هر اپیک که خود یک User Story درشت‌دانه است به مجموعه‌ای Story ریزدانه‌تر شکسته می‌شود. هر Story باید به اندازه‌ای باشد که در یک اسپرینت قابل انجام است. در ادامه، هر Story برای پیاده سازی به مجموعه‌ای Task شکسته می شود.

اما اپیک‌ها، استوری‌ها و تسکها را چگونه باید تخمین زد؟ برای یافتن پاسخ این سوال مجبور شدم دو منبع دیگر را هم بخوانم. یکی کتاب Agile Estimating and Planning اثر Mike Cohn و دیگری کتاب Return on Software اثر Steve Tockey. با خواندن این دو کتاب با اصول و روش‌های تخمین کارها به خوبی آشنا شدم. در ادامه، برای تخمین اپیک‌ها T-Shirt Size، استوری‌ها Story Points و تسک‌ها ساعت ایده آل را برگزیدم.

باید اعتراف کنم تخمین (Estimation) کارها با این واحدها عموما فرایندی دشوار و گاها مبهم است. البته این ابهام در ذات هر تخمینی نفهته است (به علت رابطه بین دانش و احتمال). اما به نظر میرسد تعریف این واحدها و به خصوص استوری پوینت گاهی به این ابهام دامن میزند. برای مثال، کوهن در سال ۲۰۰۴ در کتاب خود میگوید بهتر است هر استوری پوینت معادل یک روز کاری ایده آل باشد (پاراگراف آخر صفحه ۸۷). در ادامه کوهن در سال ۲۰۰۵ در کتاب دیگرش روز ایده آل را به کل از استوری پوینت جدا می کند و میگوید ترجیح میدهد از استوری پوینت به عنوان معیاری برای پیچیدگی کارها استفاده کند (پاراگراف اول صفحه ۷۵). در ادامه سایر نویسنده ها مثل لفینگول تعریف متفاوت تری از استوری پوینت ارائه میدهند. برخی دیگر مثل واکانتی به کل متریک های مبتنی بر استوری پوینت را زیر سوال میبرند و … 

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

فلسفه اسکرام برای انجام کارها

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

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

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

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

توجه داشته باشید اسکرام برای هر پروژه‌ای مناسب نیست. برای اطلاعات بیشتر می‌توانید به کتاب Rubin و منابع مربوط به چهارچوب Cynefin مراجعه کنید. هرچند گاهی منابع مربوط به چهارچوب Cynefin هم آنقدر شفاف نیستند …

جلسات اسکرام و چالشهای آنها

طبق آنچه در منابع مختلف خواندم‌ اسکرام چند جلسه اصلی دارد:

  • جلسات پلنینگ (Planning): هدف این جلسات برنامه ریزی برای کارهایی است که در طول اسپرینت انجام می‌شود
  • جلسات روزانه (Daily): هر روز جلسه‌ای با عنوان Daily Standup برگزار می‌شود. در این جلسات اعضای تیم درباره کارهایی که باید در آن روز انجام شود با هم هماهنگ می‌شوند
  • جلسات بازبینی (Review): در انتهای هر اسپرینت یک جلسه بازبینی برگزار می‌شود. در این جلسات کارهای انجام شده در طول اسپرینت برای ذی‌نفعان اصطلاحا دمو می‌شود و تیم توسعه بازخوردهای مربوطه را دریافت می‌کند. به علاوه، اگر نیازی به تغییر جهت انجام کارها باشد در این جلسات بحث و گفتگویی شکل می‌گیرد
  • جلسات رترو (Retrospective): در انتهای هر اسپرینت یک جلسه رترو برگزار می‌شود. در طول این جلسه اعضای تیم به بررسی اسپرینت قبل و مشکلاتی که حین انجام کارها با آن مواجه شدند می‌پردازند و سعی می‌کنند راهکارهایی برای حل برخی از این مشکلات در اسپرینت‌های آینده بیابند. در نتیجه، جلسات رترو مکانیزمی برای اصلاح فرآیند انجام کارها در اختیار اعضای تیم قرار می‌دهد

توجه داشته باشید که اسکرام دو مکانیزم اصلاح دارد: یکی برای بهینه سازی و اصلاح خروجی کار (جلسات بازبینی) و دیگری برای بهینه‌سازی فرآیند رسیدن به هدف.

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

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

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

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

تئوری و عمل

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

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

متاسفانه در ادبیات اسکرام راهکار خاصی برای تعامل با “افراد بدرفتار” وجود ندارد. اسکرام فرض می‌کند همه اعضای تیم مطیع هستند و کاری بر خلاف هدف تیم، و سازمان انجام نمی‌دهند. در اندک مواردی که اشاره‌ای به نحوه تعامل با افراد بدرفتار شده است هم راهکار به سیب گندیده (Bad Apple) خواندن آنها، تذکر و نهایتا اخراجشان ختم می‌شود. برای مدتی این سوالات ذهن مرا به شدت مشغول کرده بود:

  • با افراد بدرفتار چه باید کرد؟
  • آیا تنها راهکار طرد فرد از گروه و سازمان است؟ اگر چنین نیست تا چه مدت باید با افراد بدرفتار مدارا کرد؟
  • آیا چنین تصمیمی (که مسلما خارج از وظایف اسکرام مستر است اما وی هم در آن نقش دارد) اخلاقی است؟
  • پس کسانی که نمی‌توانند در چهارچوبی مثل اسکرام کار کنند چه؟

برای پاسخ این سوالات به فیلدهای مطالعاتی متعددی از جمله فلسفه اخلاق، نظریه تصمیم‌ (Decision Theory) و روان شناسی مراجعه کردم. البته از قبل هم در برخی از این زمینه‌ها مطالعات قابل توجهی داشتم. این سوالات مرا بر آن داشت به طور خاص در این منابع دنبال پاسخ باشم. برخی از کتبی که در این راستا خواندم عبارتند از کتاب Exploring Ethics اثر Steven Cahn، برخی از کتب اروین یالوم و کتاب An introduction to decision theory اثر Martin Peterson. مسلما خواندن این کتب خالی از لطف نبودند اما پاسخ خاصی هم در اختیارم قرار ندادند.

گاهی به عنوان اسکرام مستر باید تصمیماتی بگیرید که صورت آنها بی شباهت به مسئله تراموا (Trolley Problem) نیست. در این میان نظریه تصمیم هم کمک زیادی نمی‌کند زیرا عقلانیت (Rationality) یک تصمیم در موقعیتی خاص به هدفتان بستگی دارد (به این ویژگی اصطلاحا Instrumental Rationality می‌گویند). طبق تعاریف اقتصادی هدف کارکنان یک سازمان باید در راستای اهداف آن سازمان یعنی رسیدن به ماکزیمم سود (و کاهش هزینه) باشد. در نتیجه، ممکن است طبق هدف سازمان و تحلیل‌های نظریه تصمیم به نتیجه‌ای برسید که در راستای هدف سازمان عقلانی است اما اخلاقی نیست و شما را راضی نمی‌کند…

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

نقاط ضعف اسکرام

اسکرام نقاط ضعف متعددی دارد. این نقاط ضعف بدین معنی نیستند که اسکرام فرآیند بدی است. هر ابزاری مزایا و معایبی دارد. در ادامه برخی از آنها را آورده‌ام:

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

نقض هر یک از این مفروضات شما را با مشکلات متعددی مواجه خواهد ساخت…

نتیجه‌گیری

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

در نهایت امیدوارم این یادداشت برایتان مفید باشد.

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

 

 

مسئولیت پذیری

اخیرا کتابی خواندم به نام The Great ScrumMaster اثر Zuzana Sochova. نویسنده در این کتاب مدلی از مسئولیت پذیری ارائه کرده بود که به نظرم جالب آمد. ترجمه مختصری از این مدل را در ادامه آورده ام.

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

  1. نادیده گرفتن (Denial): ساده ترین گزینه نادیده گرفتن اتفاقی است که افتاده. اصلا به ماشین کناری خوردم؟ من که رد هیچ خط و خشی نمی بینم. آثار موجود روی بدنه ماشین دیگر هم به خاطر کثیف بودن آن است و با کارواش رفتن برطرف خواهند شد. اما صدا از کجا آمد؟ صدای خرد شدن سنگ های پارکینگ بود
  2. دنبال مقصر گشتن (Laying blame): اگر با نادیده گرفتن اتفاقی که افتاده راحت نباشید ذهنتان گزینه دیگری پیشنهاد می دهد. ناگهان در کسری از ثانیه، ذهن دنبال مقصر می گردد: اینکه به ماشین کناری خوردم مشکل راننده آن ماشین است. اگر به درستی پارک کرده بود چنین نمی شد!
  3. توجیه کردن (Justify): اگر با دنبال مقصر گشتن هم راضی نشوید ذهنتان گزینه دیگری پیشنهاد می دهد. کارتان را توجیه می کند: همه گاه و بی گاه تصادف می کنند؛ نه؟ تازه پارک کردن در پارکینگ های طبقاتی شلوغ هم سخت است.
  4. شرمندگی (Shame): گزینه بعدی شرمنده شدن است. این تصادف تقصیر من است. من هیچ وقت یاد نگرفتم در پارکینگ های طبقاتی شلوغ پارک کنم. شرمنده ام!
  5. وظیفه (Obligation): گزینه بعدی مواجهه با مشکل به گونه ایست که نشان دهد انجام یک کار خاص وظیفه شما است. شماره تلفنم را روی یک تکه کاغذ نوشتم و پشت برف پاک کن ماشینی که به آن زدم گذاشتم. در نهایت بیمه خسارتم را جبران خواهد کرد.
  6. بی خیال شدن (Quit): هر وقت بخواهید می توانید بی خیال همه چیز شوید.
  7. مسئولیت پذیری (Responsibility): این گزینه آخری است که ذهنتان در اختیار شما قرار می دهد. برای مسئولیت پذیری باید از خودتان بپرسید «دفعه بعد باید چه کار کنم تا این اتفاق نیفتد؟». در مثال پارک کردن ماشین پاسخ این سوال می تواند پارک کردن در یک جای خلوت تر، نصب سنسور پارک روی ماشین و غیره باشد.

استفاده از گزینه های مختلف این مدل را در خودم و دیگران بارها دیده ام. امیدوارم با آگاهی از این مدل بتوانیم در مواجهه با مشکلات بهتر تصمیم بگیریم.

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