یکی از دوستان عزیزم پیام زیر را به شماره همراهم فرستاده بود:

«سلام،

دیشب خوابتون رو دیدم. یه پروژه بود که عقب افتاده بود. به من گفتید باید تمومش کنیم!

کلی توی خواب احساس غرور کردم»

پس از دریافت پیام با دوستم تماس گرفتم و کلی با هم خندیدیم؛

با خودم فکر می‌کنم «انگار پروژه‌‌های عقب‌افتاده، توی خواب هم علاقه‌ی زیادی به ما دارند». به هر حال، محبت، محبت به دنبال خواهد داشت

گزیده:
ندارد.

مترجم: مریم رضایی
منبع: Kellogg Insight
یک پرتاب سه امتیازی می‌تواند موفقیت یا عدم موفقیت یک تیم بسکتبال را رقم بزند. یک پرتاب‌کننده سه امتیازی به راحتی می‌تواند جریان مسابقه را عوض کند.

برای ثبت نام، لطفاً به اینجا مراجعه فرمایید.

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

بخش اول: بدهی فنی چیست؟
بدهی بیانگر تعهد یک شخص حقیقی یا حقوقی (بدهکار) به شخص حقیقی یا حقوقی دیگر (طلبکار) است. بدهی معمولاً به دارایی واگذارشده‌ی طلبکار به بدهکار اشاره دارد، اما می‌تواند به عنوان استعاره برای بیان تعهدات اخلاقی یا سایر تعاملات اقتصادی نیز استفاده شود. بازپرداخت بدهی معمولاً شامل دو بخش «اصل بدهی» و «بهره»ی آن است. [ویکی‌پدیا]
مفهوم بدهی فنی نخستین بار توسط کانینگهام مطرح شد. وی بدهی فنی را این‌گونه تعریف کرد:
«وقتی کدی را برای اولین بار تحویل می‌دهید مثل این است که خود را بدهکار کرده باشید. هر بدهی کوچکی باعث افزایش سرعت توسعه می‌شود به شرطی که آن را در اسرع وقت و با بازنویسی کد، بازپرداخت کنید… زمانی این موضوع خطرناک می‌شود که بدهی بازپرداخت نشود. هر دقیقه‌ای که از عمر این کد که کاملا ًدرست نوشته نشده است می‌گذرد، مانند بهره‌ای است که به بدهی قبلی افزوده می‌شود. کل شرکت‌های مهندسی زیر فشار بدهی ناشی از بی‌توجهی به این‌گونه پیاده‌سازی‌های بازنویسی‌نشده ممکن است زمین‌گیر شوند و پیشرفت آنها متوقف شود.»
کانینگهام برای این که به تیم کسب‌وکار خود نشان دهد ساخت سریع نرم‌افزار برای دریافت بازخورد روش خوبی است، از استعاره‌ی بدهی فنی استفاده کرد. برای این کار، وی بر دو نکته‌ی کلیدی تأکید کرده است: تیم و سازمان باید با افزایش درک و شناخت خود از حوزه‌ی کسب‌وکار، مراقب بازپرداخت بدهی‌ها باشند؛ و با افزایش شناخت تیم و برای استفاده از آموخته‌های جدید، طراحی و پیاده‌سازی سیستم باید تغییر کند و تکمیل گردد.
از زمان معرفی این واژه در اوایل دهه‌ی 1990، صنعت نرم‌افزار برداشت‌های آزادی از تعریف کانینگهام داشته است. امروزه بدهی فنی هم به میان‌برهایی (shortcut) که آگاهانه و عامدانه انتخاب می‌شوند و هم به موضوعات نادرستی که به سیستم نرم‌افزاری آسیب می‌زنند گفته می‌شود. این موضوعات شامل موارد زیر هستند:
○ طراحی نامناسب یا بد : بخشی از طراحی که زمانی معقول و قابل قبول بود اما به دلیل تغییرات مهم کسب‌وکار یا تکنولوژی، دیگر معقول و قابل قبول نیست.
○ نقصها(defect) : مشکلات شناخته‌شده‌ای در نرم‌افزار که تاکنون زمانی برای رفع آنها گذاشته نشده است.
○ پوشش ناکافیِ آزمون‌ها : بخش‌هایی که می‌دانیم به آزمون‌های بیشتری نیاز دارند اما تاکنون کاری برای آنها انجام نداده‌ایم.
○ آزمون دستیِ بیش از حد : آزمون‌ها دستی انجام می‌شوند در حالی که آزمون‌ها باید خودکار شوند.
○ یکپارچه‌سازی و مدیریت ضعیف انتشار: این فعالیت‌ها به گونه‌ای انجام می‌شوند که زمان‌بر و خطازا هستند.
○ کم‌تجربگی در استفاده از سکو (platform): برای نمونه برنامه‌های کاربردی برای رایانه‌های بزرگ و به زبان کوبول نوشته شده‌اند، در حالی که برنامه‌نویس باتجربه و مسلط به کوبول به تعداد کافی نداریم.
و موارد دیگری از این دست؛ چرا که امروزه اصطلاح بدهی فنی به عنوان استعاره‌ای برای بیان مشکلات چند وجهی مورد استفاده قرار می‌گیرد. [Essential Scrum]

مارتین فاولر بدهی فنی را از طرفی ناشی از بی‌دقتی یا بی‌ملاحظه بودن (reckless) یا ناشی از مصلحت یا دوراندیشی (prudent) می‌داند و از طرف دیگر آن را به دو دسته‌ی عمدی (deliberate) و سهوی یا غیرعمدی (inadvertent) تقسیم می‌کند. به عنوان نمونه وقتی برنامه‌نویسی، کد موجود را بدون توجه به تأثیرات جانبی آن حذف می‌کند، بدهی فنی از نوع inadvertent و reckless ایجاد کرده است یا وقتی تیم پس از کسب تجربه، مبادرت به تغییر کد قبلی می‌کند، بدهی deliberate و prudent ایجاد کرده است. [martinfowler.com]

رابرت مارتین (عمو باب) نویسنده‌ی کتاب Clean Code و ابداع‌کننده‌ی واژه‌ی mess در برنامه‌نویسی اعتقاد دارد که کد کثیف با بدهی فنی متفاوت است. برای اطلاعات بیشتر به نوشته‌ی زیر مراجعه نمایید.
https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt

بخش دوم: بازپرداخت بدهی فنی
روشهای مختلفی برای بازپرداخت بدهی وجود دارد که یکی از آنها «اجرای قانون پیشاهنگی» است.
«قانون پیشاهنگی»: «همیشه وقتی اردوگاه را ترک می‌کنید، تمیزتر از زمان ورودتان باشد.» اگر زباله‌ای روی زمین دیدید، بدون آن که دنبال این باشید که چه کسی آن را ریخته است، زباله را بردارید و آن جا را تمیز کنید. با این کار، آگاهانه محیط را برای گروه بعدی آماده‌تر می‌کنید.
باب مارتین به زیبایی توضیح داده‌اند که چرا از این قانون می‌توان در توسعه‌ی محصول و بدهی فنی نیز استفاده کرد [Clean Code]. با اجرای این قانون همواره تلاش می‌کنیم تا هر بار که به سراغ کد میرویم، طراحی و پیادهسازی آن را کمی بهتر از گذشته کنیم و نه بدتر.

بخش سوم: بوی اسکات چیست؟
چون اسکات اسم خانوادگی هم هست شاید بهتر بود می‌پرسیدم «بوی اسکات» کیست.
در هر صورت «بوی اسکات» تلفظ فارسی عبارت انگلیسی «Boy Scout» یا «Boy Scout rule» یا همان «قانون پیشاهنگی» است.
حالا این اتفاق به خاطره‌ای تبدیل شده است که یادآوری آن باعث خنده همه‌ی ما می‌شود.

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

گزیده:

“The old adage ‘People are your most important asset’ is wrong. People are not your most important asset. The right people are.” Jim Collins, author of Good to Great

به نقل از http://viewer.blogfa.com نوشته‌ی دوست گرامی جناب آقای مصطفی فرهادخانی

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

بخش دوم:

“من چقدر خنگم” “چقدر احمق بودم که اون کار رو انجام دادم” … اینها نمونه هایی از برچسب هایی ست که ممکن است حتی روزانه به خود بچسبانیم . اما منظور از برچسب زدن ، چیست ؟

بر چسب زدن (labeling) ، در نظر گرفتن يك يا چند نمونه از رفتار خود و يا ديگران و سپس تعميم افراطي آن در حد رسيدن به يك برچسب است ( من يك “بازنده” هستم …. او يك “دروغگو” است) . اين برچسب‌ها که جزئی از خطاهای شناختی می باشند ، خيلي ساده شكل مي‌گيرند . درست هنگامي كه به ديگران اجازه مي‌دهيم ما را براساس آنچه از ما درك مي‌كنند تعريف كنند يا زماني كه در مورد خود به نادرست قضاوت مي كنيم و اين قضاوت به عنوان توصيفي ماندگار از شخصيت ما، متبلور شده و در واقع ، دروني مي‌شود.
دکتر فيليپ مك گرا معتقد است وقتي ما برچسبي را مي ‌پذيريم به اين ترتيب ، يك خود ‌ادراكي غيرواقعي را مدل‌سازي کرده‌ايم . برچسب‌ها تعميم داده مي‌شوند و به شكل يك الگوي اصلي درمي‌آيند كه درواقع خويشتن حقيقي ما ناديده انگاشته مي‌شود . چه اين برچسب از بيرون بر ما اعمال شده باشد و چه از درون . به زودي آن را به عنوان خويشتن مي‌پذيريم و باور مي‌كنيم . نكته اينجاست که وقتي به خود اجازه مي‌دهيم با عينك ديگران و با محكي كه به ما تحميل شده، خود را سبك ، سنگين كنيم و اين گونه بسنجيم، برچسب‌ها نتايج خود را برما منعكس و نمايان مي‌كنند . بي‌عرضه، زشت ، خنگ ،بازنده ، كند ، احمق و… مي‌تواند تنها معيارهاي ديگران باشد تا واقعيت.

برچسب زدن شکل حاد تفکر همه یا هیچ چیز است. به جای اینکه بگوییم«اشتباه کردم». به خود برچسب منفی می زنیم:«من بازنده هستم». گاه هم اشخاص به خود برچسب «احمق» یا «شکست خورده» یا “خنگ” و غیره می زنند. برچسب زدن غیر منطقی است ، زیرا ما با کاری که می کنیم ، تفاوت داریم . انسان وجود خارجی دارد اما «بازنده» و «احمق» به این شکل وجود ندارد . این برچسب ها تجربه های بی فایده ای هستند که منجر به خشم، اضطراب ، دلسردی و کم شدنِ عزت نفس می شوند . گاه برچسب متوجه دیگران است . وقتی کسی در مخالفت با نظرات ما حرفی می زند ممکن است او را متکبر بنامیم. بعد احساس می کنیم مشکل به جای رفتار یا اندیشه بر سر«شخصیت» یا «جوهر و ذات» او است . در نتیجه او را به کلی “بد” قلمداد می کنیم و در این شرایط فضای مناسبی برای ارتباط سازنده ایجاد نمی شود .

اگر ما از اين راهبردهاي فكري تحريف شده استفاده كنيم ، بطور غيرقابل اجتنابي احساس خشم ، اضطراب ، افسردگي و فشار زياد خواهيم كرد . ما مي‌توانيم شيوه تفكر منطقي و آرامش بخش را نيز ياد بگيريم . وقتي قادر به شناسايي الگوهاي فكري مختل خود شديم ، مي‌توانيم شروع به جايگزيني تفكر منطقي‌تر به جاي آنها نموده و احساس كنترل بيشتري را برخود داشته باشيم !

استفاده از تفكر منطقي و خود گويي‌هاي مثبت در مواجهه با استرس بيروني به ما كمك مي كند تا كنترل بيشتري بر عواطف خود داشته ، در مورد خود مثبت تر انديشيده و قادر به دستكاري بهتر موقعيت‌ها شويم . هنوز هم شايد احساس ناكامي داشته باشيم ولي احساس اضمحلال نخواهيم داشت ، مي رنجيم ولي خشمگين نمي‌شويم ، عصبي مي‌گرديم ولي توسط اضطراب كارآيي خود را از دست نمي دهيم . شايد ما قادر باشيم كه موقعيت خارجي را تغيير دهيم وشايد هم نباشيم ولي توسط حفظ ديدگاههاي خود مي‌توانيم تاثير آنها بر خودتان را تغيير دهيم .

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

گزیده:
«من می‌دونم که ما موفق نمی‌شیم» مرجع: کارتون داستانهای گالیور

فیلیپ کراچن در وبلاگ مطلبی نوشته است با نام Friction.

By analogy, in software development, friction is the set of phenomena that limits or constraints our progress, therefore reduces our velocity (or productivity). An element of friction that we have been looking at more closely in the last few years is the result of technical debt: the accumulation of design or coding decisions that looked expedient at the time we made them, but are in retrospect suboptimal, and a hindrance now.

But there is another aspect of friction that is not related to the state of the code, but resides at the organizational and social level. Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop].

Social debt is a state of a development project which is the result of the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc.

Social debt + Technical debt => Friction => delays, unpredictable schedule, and/or poor quality.

As we have defects and code smells on the technical side, we can observe on the social side defects and “smells”: not problems but potential source of a series of concrete problems if left not addressed. Examples of social and organizational and social smells Tamburri identified and studied are: Organizational silos, or Prima donnas.

Bas Vodde که به همراه کریگ لارمن چندین کتاب معروف از جمله Scaling Lean & Agile Development نوشته است در توضیحی ذیل متن وبلاگ نوشته است

In our work, Craig and me have used the word “learning debt” for short-cuts in learning, lack of improvement and over-specialization (and others). In your description, that might also be a part of the friction then I guess. It seems different than the social debt you mentioned.

گزیده:
بی‌فایده ترین کار این است که فرد کار غیر‌لازمی را با توانایی هر چه تمام‌تر انجام دهد. پیتر دراکر

به نقل از programmerday.ir

«روز ۲۵۶ام هر سال (معادل عدد ۱۰۰در مبنای شازده) به عنوان روز برنامه نویس نام گرفته است. عدد ۲۵۶بالاترین عدد دودویی در بین ۳۶۵ روز سال است که از یک رقم 1 و بقیه 0 تشکیل شده است. این عدد ارزش ویژه ای بین برنامه نویسان دارد.

برای اولین بار در سال ۲۰۰۲، کارمندان یک شرکت کامپیوتری در روسیه بودند که امضاهایی را جهت به رسمیت شناختن روزی با عنوان روز برنامه‌نویس جمع‌آوری کردند. در۱۱ سپتامبر ۲۰۰۹رئیس جمهور وقت روسیه، این روز را به عنوان روز برنامه‌نویس نام‌گذاری کرد و پس از آن کشورهای دیگر از جمله بریتانیا و ایالات متحده آمریکا این روز را به عنوان روز برنامه‌نویس پاس میدارند.

ممکن است ما عضو تیم یا شرکتی باشیم که به توسعه نرم‌افزار می پردازد، یک آزادکار و یا یک دانشجو باشیم، اینروز متعلق به همه ماست. ما به کمک هم ۱۰آذرماه -یعنی ۲۵۶امین روز سال شمسی- را به عنوان روز برنامه نویس جشن میگیریم و آن را در تقویم ملی کشورمان ثبت می‌کنیم.»

با تشکر از دوست عزیزمانُ جناب آقای مهندس بختیاری

گزیده:
ندارد