بایگانی دسته: تکنولوژی

چاپ کتاب شبکه عصبی خود را بسازید

 

امروز چاپ اول کتاب “شبکه عصبی خود را بسازید: مقدمه ای بر مفاهیم، ریاضیات و ساخت شبکه های عصبی با پایتون” به بازار آمد. این اثر ترجمه Make Your Own Neural Network نوشته طارق رشید است و از نظر بنده یکی از بهترین منابع برای شروع یادگیری شبکه های عصبی برای مبتدیان به حساب می آید. کتاب پیش نیاز خاصی ندارد و حتی زبان پایتون را هم به حد کفایت به مخاطب می آموزد.

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

خرید نسخه چاپی کتاب + نسخه الکترونیکی رایگان از نشر دانشگاهی کیان

خرید نسخه الکترونیکی کتاب از فیدیبو

امیدوارم مفید واقع شود.

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

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

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

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

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

 

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

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

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

به زبان، نمادها، ابزارها، زبان بدن، ارزش ها و نرم هایی (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ها توسط اعضای تیم زمان‌بر است
  • برای پیاده‌سازی اسکرام منبع جامعی وجود ندارد و باید اطلاعات لازم را مانند تکه‌های یک پازل از منابع مختلف و پراکنده‌ گرد هم آورید (هرچند بعضی این را نقطه قوت اسکرام می‌دانند)
  • رعایت نظم در اسکرام اهمیت بسیار زیادی دارد. بی‌نظمی یکی از اعضا می‌تواند ضربات قابل توجهی به فرآیند وارد آورد
  • اسکرام کسانی که روحیه کار تیمی ندارند را به کلی کنار میگذارد

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

نتیجه‌گیری

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

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

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

 

 

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

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

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

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

 

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

داکر چیست؟

لوگوی داکر

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

داکر متشکل از یک ابزار خط فرمان و یک سرویس (Daemon) است که:

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

در ادامه هر یک از این موارد را با جزئیات بیشتر مورد بررسی قرار می دهیم.

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

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

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

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

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

یکی دیگر از امکانات داکر فراهم آوردن یک مخزن برای دانلود و نصب نرم افزارها است. این مخزن به آدرس https://hub.docker.com در دسترس است (هرچند به علت تحریم ها در حال حاضر این سایت به صورت مستقیم قابل استفاده نیست. اما می توانید با ابزارهای دور زدن تحریم یا اندیس های جایگزین از این امکان استفاده کنید).

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

در نوشتن این پست سعی شده موارد تا حد امکان بدون ذکر جزئیات فنی مطرح شوند تا مطلب برای همه مخاطبان قابل مطالعه باشد. اگر به یادگیری بیشتر در این باره علاقه دارید، پیشنهاد می کنم کتاب Docker In Action نوشته Jeff Nickoloff رو مطالعه کنید. در نهایت امیدوارم موارد مطرح شده مورد استفاده قرار بگیرد.

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

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

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

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

 

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

هدف تفکر طراحی (Design Thinking)

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

دانلود اسلایدهای ارائه دانلود فایل صوتی ارائه

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

اگر تاریخچه پدید آمدن تفکر طراحی را مطالعه کنید، حتما با مقاله مهم و ارزشمند هورست ریتل (Horst Rittel) با عنوان Dilemmas in a general theory of planning مواجه خواهید شد. ریتل در این مقاله به بررسی مسائل خاصی، که خود آنها را مسائل بدخیم (Wicked Problems) می نامد پرداخته است (ممکن است بدخیم معادل فارسی مناسبی برای کلمه Wicked نباشد، اما در حال حاضر معادل بهتری برای آن نیافته ام. برخی، آن را به بدسرشت هم ترجمه کرده اند. اما، بد سرشت ترجمه مناسبی برای این واژه نیست. به خصوص وقتی با کلمه مسئله همراه می شود). مسائل بدخیم، مسائلی پیچیده (پیچیده به معنای تشکیل شده از اجزا) و چندبعدی هستند. از نظر ریتل این مسائل بیشتر در تقابل با جامعه رخ می دهند. به قول ریتل: «مشکلات اجتماعی هیچ گاه به صورت قطعی حل نمی شوند بلکه بارها و بارها فیصله می یابند». فیصله را به عنوان ترجمه Resolve به کار برده ام. وقتی مسئله ای حل می شود عموما همه طرفین از حل آن راضی هستند. اما، وقتی دعوا یا اختلافی فیصله می یابد یا اصطلاحا Resolve می شود همه طرفین رضایت ندارند!

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

  1. مسائل بدخیم صورت مسئله مشخصی ندارند: مهمترین معضل در حل مسائل بدخیم نوشتن صورت مسئله است. منظور از «نوشتن صورت مسئله» مشخص کردن سه مورد زیر است:
    • نوشتن ویژگی های حالت ایده آل و حالت فعلی.
    • پیدا کردن علت مشکل. به عبارت دیگر، علت تفاوت بین حالت ایده آل و حالت فعلی چیست؟
    • انتخاب مجموعه ای از اقدامات برای رفع علت مشخص شده.
  2. مسائل بدخیم شرط توقف ندارند: در حل مسائل ریاضی یا موقع بازی شطرنج می دانیم کی مسئله حل شده یا بازی به اتمام رسیده است. اما، مسائل بدخیم شرط توقف ندارند. نمی دانیم مشکل چه موقع حل شده است. در واقع، مجموعه رویدادها و وقایع خاصی وجود ندارند که با رخ دادن آنها متوجه شویم مسئله حل شده است. عموما، کسانی که مسائل بدخیم را حل می کنند به علت اتمام وقت یا بودجه حل مسئله را متوقف می کنند.
  3. راه حل های مسائل بدخیم درست یا غلط نیستند، بلکه خوب یا بد هستند: این ویژگی دخیل بودن عوامل انسانی و قضاوت انسان در بررسی کارایی راه حل مسائل بدخیم را شرح می دهد. در حل مسائل ریاضی، فرد یا افرادی وجود دارند که می توانند با آگاهی از قوانین ریاضیات، راه حل ارائه شده را بررسی کرده و اعلام کنند آیا راه حل ارائه شده درست است یا غلط. اما، در بررسی صحت و کارایی راه حل های مسائل مرتبط با اجتماع سلیقه، بافت جامعه، ساختار اجتماعی و سلسله مراتبی و قضاوت افراد دخیل است. ممکن است راه حل از نظر یک فرد خوب و از نظر شخص دیگری بد باشد.
  4. پیش از پیاده سازی راه حل، تستی برای اینکه مشخص کند آیا راه حلی برای مسئله به دست آمده است وجود ندارد: در مسائل خوش خیم، پیش از پیاده سازی راه حل، می توان تصمیم گرفت راه حل ارائه شده تا چه حد خوب یا بد است. به عبارت دیگر، بررسی و تست راه حل کاملا در کنترل کسانی است که به حل مسئله علاقه مند هستند. در مسائل بدخیم، هر راه حلی، پس از پیاده سازی، موجی از عواقب و نتایج را به همراه خواهد داشت. این موج می تواند به مدت زمان نامتناهی ادامه یابد. به علاوه، ممکن است پس از پیاده سازی راه حل، نتایج به بار آمده آنقدر وخیم باشند که حل کننده گان مسئله به این نتیجه برسند که بهتر بود اصلا راه حلی ارائه نمی شد! نتایج و عواقب راه حل پیاده سازی شده بر زندگی تک تک افراد را نمی توان پیشاپیش و قبل از پیاده سازی راه حل بررسی کرد.
  5. هر راه حلی که برای یک مسئله بدخیم مطرح می شود بسیار حائز اهمیت است و نمی توان با سعی و خطا مسئله را حل کرد: فرض کنید می خواهید مشکلات سیستم آموزشی یک کشور را رفع کنید. نمی توانید این کار را با سعی و خطا انجام دهید. کوچکترین تغییری باعث تحت تاثیر قرار گرفتن زندگی یک یا چند نسل از جامعه می شود.
  6. مسائل بدخیم مجموعه راه حل های قابل شمارشی ندارند. به علاوه، اعمال مشخصی هم وجود ندارد که بتوان از آنها در برنامه ریزی استفاده کرد: راهی وجود ندارد که بتوان بر اساس آن اثبات کرد همه راه حل های یک مسئله بدخیم شناسایی و بررسی شده است. ممکن است به علت تناقض های منطقی که در صورت مسئله وجود دارد اصلا نتوان راه حلی یافت (برای مثال ممکن است در صورت مسئله نیاز به A و نقیض آن ذکر شده باشد). عموما، در زمان تلاش برای حل یک مسئله بدخیم، مجموعه ای از راه حل ها در نظر گرفته می شوند و مجموعه ای دیگر به طور کامل از نظر پنهان می مانند. تلاش برای افزایش اندازه مجموعه راه حل ها و انتخاب یک راه حل خاص تنها به قضاوت وابسته است.
  7. هر مسئله بدخیمی اساسا یکتا است: به ازای هر دو مسئله، می توان حداقل یک وجه تمایز یافت. اما، «اساسا یکتا» یعنی به ازای تعداد بسیار زیادی ویژگی مشابه بین دو مسئله بدخیم، یک ویژگی متمایز کننده وجود دارد که اهمیت بسزایی دارد. در نتیجه نباید برای انتخاب راه حل مسائل بدخیم عجله کرد.
  8. هر مسئله بدخیمی را می توان نشانه ای از یک مسئله بدخیم دیگر (و سطح بالاتر) در نظر گرفت: برای مثال جرم و جنایت را می توان نشانه ای از افول اخلاق در جامعه در نظر گرفت.
  9. توضیحات مختلفی برای وجود تفاوت بین حالت ایده آل و حالت فعلی در صورت مسائل بدخیم قابل ارائه است. اگر توضیح خاصی را به عنوان علت مسئله در نظر بگیرید در واقع راه حل خود را انتخاب کرده اید. برای مثال می توان علت جرم و جنایت در جامعه را افول اخلاق، فقر، تولید فیلم های خشن و غیره دانست. اگر علت خشونت در جامعه را افول اخلاق در نظر بگیرید راه حلتان هم در همین جهت پیش خواهد رفت!
  10. طراح (حل کننده گان مسائل بدخیم) حق اشتباه کردن ندارد: در علم، دانشمندان نظریه های مختلفی برای توضیح یک پدیده بیان می کنند. یک نظریه را می توان با استفاده از شواهد نقض کرد و نظریه جدیدی ارائه داد. هیچ کس، دانشمندان را برای ارائه نظریاتی که نقض می شوند سرزنش نمی کند. اما، در حل مسائل بدخیم، بر خلاف علم، هدف یافتن حقیقت نیست. هدف، بهبود شرایط زندگی مردم است. از این رو طراحان و کسانی که مسائل بدخیم را حل می کنند حق اشتباه کردن ندارند و باید مسئولیت تصمیمات خود را بپذیرند.

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

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

رفتار نرم افزار دربرابر خطا

تصویری که کاربری خیالی را در مواجهه با خطا نشان می دهد

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

در سال ۱۹۸۶ دون نورمن (Don Norman) و کلیتون لوییس (Clayton Lewis) مقاله ای را با عنوان طراحی برای خطا (Designing for error) در کتاب User-Centered System Design چاپ کردند. آنچه در ادامه می خوانید خلاصه این مقاله (با کمی تغییر) است.

اگر با سیستم های کامپیوتری کار کرده باشید حتما با پیغامهای خطا هم مواجه شده اید. برخی از پیغام هایی که ممکن است دیده باشید عبارتند از:

  • فایل یا دایرکتوری مقصد موجود نیست
  • خطا در اتصال به سرویس دهنده
  • خطا در نوشتن فایل در دایرکتوری مقصد

اما آیا استفاده از کلمه خطا (Error) در چنین شرایطی درست است؟ نویسندگان مقاله می گویند خیر! چون خطا کلمه ای است که عموما با شنیدن آن، دنبال مقصر می گردیم. این کلمه بار منفی دارد و کاربر با دیدن آن احساس می کند ناتوانی او باعث خطا شده، در حالیکه نرم افزار نتوانسته به درستی به درخواست یا ورودی کاربر پاسخ دهد. بنابراین نویسندگان مقاله استفاده از هر کلمه دیگری را در این شرایط، بر خطا، مقدم می دانند. به علاوه انسانها همان طور که با دیگر انسانها در تعاملند، با کامپیوترها تعامل (Interact) می کنند. سیستمی که مدعی تعاملی بودن است باید همان طور که دو طرف یک گپ و گفت سعی در رفع اشکالات کلامی و مفهومی هم می کنند (تا حرف هم را بفهمند) سعی کند به کاربر کمک کند و اشکالات او را رفع کند.

اما آیا می توان “خطاهای” کاربر را دسته بندی کرد؟ به طور کلی کاربران هدف یا مقصودی (Intention) برای استفاده از نرم افزار دارند:

  • اگر هدف و مقصود کاربر درست باشد اما عملی که برای دست یافتن به آن انجام می دهد اشتباه باشد او مرتکب لغزش (Slip) شده است
  • اگر هدف و مقصود به کلی اشتباه باشد کاربر مرکتب اشتباه (Mistake) شده است

عموما کسانی که در استفاده از نرم افزار خاصی خبره هستند دچار لغزش می شوند چون کارها را ناخودآگاه (به علت تمرین و تکرار) و بدون دقت انجام می دهند.

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

  1. Gag: در این حالت سیستم کار مورد نظر کاربر را انجام نمی دهد. این توقف کاربر را آگاه می کند که خطایی رخ داده، اما کاربر متوجه نمی شود این خطا چیست. برای مثال وقتی سعی می کنید ماشین را روشن کنید اما هیچ اتفاقی نمی افتد. در این حالت متوجه می شوید که مشکلی وجود دارد اما نمی توانید تشخیص دهید این مشکل چیست؟
  2. Do Nothing: در صورت بروز خطا سیستم، هیچ عکس العملی از خود نشان نمی دهد. این روش تنها در شرایطی قابل استفاده است که کاربر متوجه شود در پاسخ به درخواست وی هیچ اتفاقی نیفتاده است، در غیر این صورت ممکن است کاربر به اشتباه فکر کند درخواستش انجام شده است.
  3. Warn: در این حالت در صورت بروز خطا یک اخطار به کاربر نمایش داده می شود اما سیستم به کار خود ادامه می دهد. برای مثال در حین کپی فایل سیستم به کاربر اطلاع می دهد دیسک در حال پر شدن است اما به کپی فایل ادامه می دهد.
  4. Self-Correct: در این روش در صورت خطای کاربر، سیستم سعی می کند به صورت خودکار هدف کاربر را تشخیص و کار مورد نظر او را انجام دهد. این مکانیزم تنها در شرایطی مفید است که بتوان کار انجام شده توسط سیستم را به راحتی لغو کرد. مثالی از این سیستم ها را می توان در برنامه هایی که به صورت خودکار کلمات تایپ شده کاربر را کامل می کنند مشاهده کرد.
  5. Teach Me More: در این حالت اگر نرم افزار نتواند درخواست کاربر را به درستی درک کند از کاربر می خواهد اطلاعات بیشتری در اختیارش قرار دهد. برای مثال دیکشنری هایی که برخی از کلمات را ندارند به کاربر امکان می دهند کلمه ناموجود را اضافه کند.
  6. Let’s Talk About It: این روش که قدمی به سوی تعاملی تر شدن برنامه ها است سعی می کند با برقراری دیالوگ با کاربر مشکل را حل کند. برای مثال با پرسیدن مجموعه ای از سوالات.

توجه داشته باشید رفتار نرم افزار در برابر خطا می تواند ترکیبی از موارد فوق باشد.

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

  1. اینکه خطایی رخ داده است (Detection of error)
  2. اینکه خطا در چه سطحی از نرم افزار اتفاق افتاده (Identification of error)

عموما پیغام های خطا مورد اول را در اختیار کاربر قرار می دهند اما اطلاعات دقیقی در مورد مکان و علت دقیق رخ دادن خطا به کاربران نمی دهند و این امر می تواند باعث سردرگمی کاربران شود.

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

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