یادگیری کانبان (۲۰)

  • یاسر کازرونی

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

قلم‌های ضروری

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

مارکوس با دقت چالش های روی فلیپ چارت را مرور کرد و گفت: «با اینکه ممکنه هنوز همه چالش‌های این فهرست حل نشده باشه، ولی با من موافقید که الان برای مقابله با بیشتر اون‌ها ابزارهایی دارید؟»

  • ما معمولاً کارها را دیر انجام می‌دهیم
  • بیشتر اوقات برآوردها غلط هستند ·
  • تیم در باتلاقی از کارها گیر کرده است ·
  • اولویت­ها مشخص نیستند ·
  • از هرجایی کار به تیم سپرده می‌­شود
  • معلوم نیست که کی چه کار می‌کند ·

برای یک لحظه همه جا ساکت شد. آدام صدایش را صاف کرد، آهی کشید و گفت: «دوباره همه ‌چی خوب به نظر می‌رسه، ولی هنوز باید ساده‌تر بشه.»

او ادامه داد: «خودت می‌دونی که همه ‌چی ویژگی‌های جدید و حرکتِ رو به جلوی کار نیست. وقت‌هایی که کارها با خطا توی محصول نهایی می‌رن؛ اصلاً مهم نیست که اون لحظه داری چی کار می‌کنی یا چند تا کارِ در جریان داری؛ باید اول مشکل رو حل کنی! و بعدش به کارهات برسی!»

دافنه وسط حرف او پرید: «درسته. مسلمه که برای نقض نکردن محدودیتِ کار در جریان کار فوری رو نگه نمی‌داریم، نگه می‌داریم؟»

مارکوس به سمت گروه برگشت: «خُب، می‌تونید این کار رو انجام بدید ولی بیش‌تر تیم‌ها این کار رو نمی‌کنن چون به ضرره کسب‌وکار‌شونه. نتیجه‌ای که پایان روز بدست میاد منجر به عاملی موثر برای پیروی تمام و کمال از فرآیندتون می‌شه. الان با یه کار فوری چی‌کار می‌کنید؟ اگه در حالی‌که از کار روی ویژگی‌های جدیدخوشحال هستین، یهویی هشداری دریافت کنین، که سرورِ محصول از کار افتاده، چی‌کار می‌کنید؟»

اریک آخرین قطعه از آهنگی از ایرن میدن (Iron- Maiden) را خواند: «همه‌چیز رو ول می‌کنم و «به سوی تپه‌ها می‌دوم!». همه خندیدند چون هیچ‌کس ندیده بود اریک بدود.

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

«درسته!» مارکوس این را گفت و با دست راستش یک تپانچه دولول الکی را به دافنه داد.

یوآخیم چشمانش را برگرداند و به سرعت حرکت کرد: «این سناریو، متداوله. یه راه‌حل رایج، درست کردن یه مسیرِ مخصوص روی تابلو برای کار ضروریه، که اغلب به‌عنوان یه «مسیرِ سرعت» (Expedite Lane) به اون اشاره می‌شه.»

مارکوس تپانچه خیالی خود را در کیف چرمی قرار داد و در حالی‌که یوآخیم در حال توضیح دادن بود یک ردیف جدید بالای تابلو اضافه کرد.

«دافنه، قواعدی که به‌طور غیرمستقیم به اون اشاره کردی، فکر خوبیه که کارهای دیگرِتون رو ول ‌کنید و کمک ‌کنید که مشکل حل بشه؛ ولی اغلب معلوم نیست و هرکسی اون‌ رو درک نمی‌کنه یا باهاش موافق نیست. می‌تونه مشخص نباشه کی باید کاری بکنه و برای حلِ مشکل اقدام ‌کنه یا اگه قراره که همه کمک کنن. قلمِ جدید باید در مقابل محدودیتِ سقف کار در جریان شمرده بشه یا نه؟ و الی آخر. قواعد نامشخصه زیادی وجود داره.»

گروه متدهای چابک:
برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

بخش قبلی

https://bibalan.com/?p=2199
یاسر کازرونی

یاسر کازرونی

تست زندگینامه

کانال تلگرام

یادگیری کانبان (۱۹)

  • یاسر کازرونی

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

کار در جریان(ادامه)

«نمی‌­دونیم که سقف مناسب چنده. اما به نظر می‌رسه می‌تونیم از عدد چهار برای شروع استفاده ­کنیم. یه عدد کم­ حضور دائمی ما رو می‌خواد، چیزی که اصلاً نمی‌تونیم اون رو اداره کنیم چون یا در سفر هستیم یا در جلسات کاری گیر افتادیم. یه عدد بالا هم به این معنی‌که تیم مدت­ طولانی بدون دریافت بازخورد از ما کارش رو ادامه می‌­ده؛ که در صورتی‌که مشکل بوجود بیاد ممکن باعث دوباره­‌کاری بشه؛ و ما می‌خوایم قبل از این‌که در کار دیگه‌ای غرق بشن اون‌رو اصلاح کنیم.»

دافنه پرسید: «اما چرا باید ستونی برای کارهای منتظر انجام وجود داشته باشه؟ منظورم اینِ که منتظر می­‌مونید تا اون ستون پر بشه و بعد شروع به پذیرش قلم‌ها می­‌کنید؟»

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

سزار گفت: «یوآخیم مطمئن نیستم در این مورد با شما موافق باشم.»

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

دافنه گفت: «این شبیه کاریه که در مورد آزمون و در انتظار عملیات انجام دادیم نیست؟»

یوآخیم به ساعتش نگاه کرد و گفت: «ممکنه. جایی که فکر می‌کنید صف‌ها بدرد می‌خورن می‌تونید اون‌ها رو داشته باشید. مثلاً، جایی که محدودیت منابع وجود داره یا می‌خواید تفاوت بین کار در حال انجام و کار در حال انتظار رو تصویرسازی کنید. اگر دست به دست کردن کار مورد نظر باشه، مثلاً از کسی که مشغول پیاده­‌سازیه به کس دیگه‌ای که مشغول آزمونه، استفاده از یه صف روش خوبی برای علامت دادن کار آماده شده برای انتقال به مرحله بعده.»

محدود کردن کار در جریان

  • شروع کنید: شروع کردن رو متوقف کنید و تمام کردن رو آغاز کنید
  • محدود کردن کار در جریان فرصت‌های بهبود را آشکار می‌کند
    • اقدام روی آن‌ها منجر به جریان بهتر کار می‌شود
  • سقف کار در جریان مشخصی برای یک تیم وجود ندارد
  • یک سقف کار در جریان کم‌تر معمولاً بهتر است. به عنوان یک قاعده کلی:
    • کار در جریان خیلی زیاد معطلی کار را به همراه دارد
    • کار در جریان خیلی کم بی‌کاری افراد را به همراه دارد
  • سقف‌های کار در جریان قانون نیستند-بلکه دلایلی برای راه‌انداختن بحث‌ها هستند

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

گروه متدهای چابک:
برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

بخش قبلی

بخش بعدی

https://bibalan.com/?p=2070
یاسر کازرونی

یاسر کازرونی

تست زندگینامه

کانال تلگرام

یادگیری کانبان (۱۸)

  • یاسر کازرونی

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

کار در جریان(ادامه)

آدام گفت: «بسیار خب، در مورد شما توسعه‌دهنده‌ها چه­‌طور؟ چه عددی برای شما مناسبه؟» و ماژیک را به سمت اریک پرتاب کرد که او هم فوراً آن را به دافنه داد.

دافنه گفت: «دو قلم کاری به‌­نظرم برای ما کمه. بعضی وقت‌ها ما مجبوریم منتظر بقیه بمونیم، درنتیجه کاری برای انجام دادن نداریم. اما عدد چهار به نظر خوب می‌رسه. تو چی فکر می‌­کنی اریک؟»

اریک با اعتماد به نفس گفت: «به نظرم ۴ قلم کاری. ما توی یه روز بیش‌تر از این کار انجام می‌دیم. از پسش برمی‌­یایم.»

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

بث گفت: «برای کار تحلیل، به نظرم سقف ۲ قلم کاری منطقی باشه.» و عدد ۲ را بدون معطلی بالای ستونش نوشت. به نظر می‌رسید که هچ کس اعتراضی به آن ندارد.

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

یوآخیم که کنار ایستاده بود و به نظر می‌­رسید از این­که به تیم اجازه داده تا خودش جواب رو بفهمد راضی است، گفت: «منظورت چیه؟»

فرانک گفت: «خب، ستون­های آماده‌ی انجام، پذیرش و در انتظار عملیات و غیره. نباید مثل بقیه عددهایی روی اون‌ها باشه؟»

مراکوس گفت: «اون‌ها هم می‌تونن. اما چرا؟ چه نفعی برای شما داره؟»

فرانک اعتراف کرد: «اِه، من فکر ‌کردم همه ستون­ها باید یه عدد داشته باشن.»

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

سزار در حالی‌که با خودش به آرامی حرف می‌­زد جلو رفت: «بذارید ببینم. محدود کردن آن ستون، ۴ قلم به‌­معنی اینِ که اگه این ستون با چهار واحد کاری پر بشه…» کمی مکث کرد و عدد ۴ را بالای ستون پذیرش نوشت.

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

مارکوس پیشنهاد کرد: «چه‌طوری می‌­تونید محدودیت را بردارید؟» بقیه ساکت بودند و سزار به فکر کردن ادامه داد.

«خب، من و بث قلم‌ها رو بررسی و پذیرش می‌­کنیم…»

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

آدام پرسید: «بسیار خب، پس چرا سقف۱ قلم رو برای اون نداریم؟»

مارکوس گفت: «چون…» اما قبل از این­که بیش­تر توضیح بدهد، سزار وسط حرف او پرید.

واقعیت برای سزار روشن شد و گفت: «چون در این صورت من باید هر زمان که کاری آماده است، با عجله سراغ آن بیایم وگرنه گردش کار دچار مشکل می­‌شه. متوجه شدم. جالبه.»

بخش قبلی

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

https://bibalan.com/?p=2017
یاسر کازرونی

یاسر کازرونی

تست زندگینامه

کانال تلگرام

رسیدن به سرآمدی فنی؛ مراجع – بخش سوم

  • یاسر کازرونی

پیش‌گفتار:

متن زیر بخشهایی از گفتگوی آقای مسعود خاری است که در گروه تلگرامی «متدهای چابک» (Agile Methods) آمده است.

گفتگو:

در گروه پیشنهاد شد که دوستان با همفکری هم یک فهرست از کتابهای ضروری برای مطالعه‌ی تیم‌های چابک تهیه کنند.
موضوعاتی که تیم‌ها برای رسیدن به سرآمدی فنی (Technical Excellence) بایستی به صورت جدی و عمیق مطالعه کنند.

مسعود در پاسخ به این سوال که «کتاب‌های خوب طراحی شی‌ گرا کدام کتاب‌ها هستند» پنج کتاب را معرفی می‌کند:

“کتاب Design Patterns: Elements of Reusable Object-Oriented Software یا Gang of Four کتاب معروف الگوهای طراحی هست که خیلی عالیه. در ابتدا چند اصل طراحی رو بیان می‌کنه و به شرح بعضی مفاهیم شیءگرایی می‌پردازه و بعد شروع به معرفی الگوهای طراحی می‌کنه.

اما این کتاب در سال ۱۹۹۵ نوشته شده و متنش و ادبیاتش و اصطلاحاتش برای برنامه‌نویسان امروز کمی ناآشناست و کمی هم ثقیل هست. عمده‌ی برنامه‌نویسانی که در شرکت‌های امروزی می‌بینم، با متن این کتاب ارتباط برقرار نمی‌کنند. به علاوه بعد از گذشت بیش از ۲۰ سال و طی تجربه، به نظر میاد بعضی الگوهای این کتاب چندان مفید نیستند و بعضی الگوهای مفید وجود دارند که در کتاب نیومدند. اما به هر حال اگر کسی عزم خودش رو جزم کنه که مطالعه‌اش در این زمینه رو عمیق کنه، به شدت توصیه میشه.”

 


“نسخه سوم کتاب Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development به معرفی روش‌های تحلیل و طراحی می‌پردازه و متدهای توسعه‌ی تکراری-افزایشی و به طور خاص UP رو معرفی می‌کنه و به شرح فازهای اون می‌پردازه، که راستش توصیه نمی‌کنم که درگیرش بشید. 🙂 به نظرم چندان مفید نیستند. اما غیر از فرایندها، فصل‌هایی از کتاب به معرفی اصول و پترن‌های طراحی شیءگرا می‌پردازه که خیلی خوبه.

به طور خاص در فصل ۱۷ به معرفی اصول طراحی GRASP می‌پردازه که در عین ساده به‌نظررسیدن، به نظرم خیلی مهم و پایه‌ای و مفید هستند. در بخش‌های بعد از اون هم در مورد شیءگرایی صحبت می‌کنه.

نسخه‌ی اول این کتاب در سال ۱۹۹۵ نوشته شده. ویرایش سومش مربوط به سال ۲۰۰۴ هست که سعی شده بخش‌های فرایندی کتاب با مفاهیم روز (به خصوص چابکی) به‌روز بشه. اما همون‌طور که اشاره کردم، به نظرم چندان در این کار موفق نبوده.”

 

“کتاب معروف Refactoring: Improving the Design of Existing Code آقای فولر که نیازی به توضیح نداره. خیلی از الگوهای ریفکتورینگ بر مبنای اصول طراحی شیءگرا هستند.

 

 

 

 

 

 

“کتاب معروف Domain-Driven Design: Tackling Complexity in the Heart of Software آقای اوانس که عالی است. و برای کسانی که بعد از مسلط‌شدن به مفاهیم شیءگرایی، بخوان با مفاهیم پیشرفته‌تر آشنا بشن خیلی خوبه. اما برای کسی که بک‌گراند شیءگرایی نداشته باشه مناسب نیست.”

 

 

 

 

 

“کتاب Analysis Patterns; Reusable Object Models فاولر، که به روش‌های تحلیل حوزه‌ی مسئله، با استفاده از مفاهیم طراحی شیءگرا می‌پردازه و بی‌اندازه عالی و عمیق هست. اما کتاب در سال ۱۹۹۶ نوشته شده، یعنی قبل از این که UML استاندارد بشه 🙂 و متاسفانه نمودارهای کتاب با نمادهای عجیب و غریب دوره‌ی قبل از UML ترسیم شده که کمی خوندن کتاب رو دشوار می‌کنه.”

 

 

 

 

 

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

 

“ویرایش دوم کتاب Extreme Programming Explained: Embrace Change که به معرفی متد چابک خودش یعنی XP یا همون Extreme Programming می‌پردازه. یکی از بهترین کتاب‌هایی هست که خوندم.

از نقاط قوت متد اکس‌پی اینه که نه تنها فرایندهای مدیریتی، بلکه پرکتیس‌های مهندسی لازمه‌ی چابکی رو به خوبی پوشش میده (مثلاً تست و TDD و CI و غیره) که بدون اون‌ها، اجرای فرایندهایی مثل ایتریشن و جلسات روزانه به تنهایی موجب چابکی تیم نمیشه. خیلی از پرکتیس‌هایی که توسط اکس‌پی معرفی شدند باعث ایجاد انقلابی در نحوه‌ی توسعه‌ی نرم‌افزار شده و هنوز پابرجا هستند.

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

ارزش‌ها، اصول، و پرکتیس‌ها (Values, Principles, Practices)

ارزش‌های اکس‌پی ریشه‌ی همه‌ی فرایندهای اکس‌پی هستند و طبعاً خیلی کلی هستند. (مثلاً «فیدبک»، یا «احترام».) پرکتیس‌ها هم روش‌های عملی هستند که به بیان نحوه و هدف اجرای کارها می‌پردازند، که در کتاب به دو دسته‌ی اصلی و جانبی تقسیم میشن. (مثلاً TDD یا CI.) اما برای این که بتونیم بین ارزش‌ها و پرکتیس‌ها پلی برقرار کنیم و به تعامل بین اون‌ها پی ببریم، اکس‌پی به معرفی مجموعه‌ای از اصول می‌پردازه که مثل چسبی بین ارزش‌ها و پرکتیس‌ها عمل می‌کنند. (مثلاً «منفعت متقابل» یا «کیفیت» یا «شکست».)

روی هم‌رفته پی می‌بریم که اون‌چه باعث موفقیت تیم چابک میشه، ایجاد بالانس مناسبی از مجموعه‌ی همه‌ی این آیتم‌هاست که روی هم تاثیر افزاینده و یا حتی گاهاً متناقض دارند، و حذف بعضی از اون‌ها احتمالاً باعث شکست کل فرایند توسعه‌ی نرم‌افزار میشه. مثلاً «تست» و «CI» به دریافت سریع‌تر «فیدبک» کمک می‌کنه و …

این سطح از انسجام بین پرکتیس‌ها رو در متدهای دیگه مشاهده نمی‌کنیم. حتی اسکرام صرفاً اخیراً به اضافه‌کردن مجموعه‌ای از «ارزش‌ها» به راهنمای رسمی اسکرام پرداخته.

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

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

نکته‌ی دیگه‌ای که برای من کتاب رو خیلی ارزش‌مند می‌کنه، پرداختن به مسائل انسانی در کنار مسائل فنی هست که در این سطح نظیرش در کتاب‌ها و متدولوژی‌های دیگه کمتر دیده میشه. این گزیده‌ای از فصل اول کتاب هست:

XP is my attempt to reconcile humanity and productivity in my own practice of software development and to share that reconciliation. I had begun to notice that the more humanely I treated myself and others, the more productive we all became. The key to success lies not in self-mortification but in acceptance that we are people in a person-to-person business “.

 

“کتاب Planning Extreme Programming از آقایان کنت بک و فاولر در مورد برنامه‌ریزی پروژه به روش XP. این کتاب به طور بنیادی به شرح این می‌پردازه که برنامه‌ریزی چیه و چرا برنامه‌ریزی می‌کنیم و در روش‌های چابک برنامه‌ریزی چطوری کار می‌کنه. موضوعاتی مثل برنامه‌ریزی رلیز و ایتریشن، نوشتن استوری‌ها و تخمین اون‌ها، این که اصلاً تخمین به چه معنی هست و چرا و چگونه انجام میشه، و مسائل گوناگون پیرامون برنامه‌ریزی، محتوای کتاب رو تشکیل می‌ده.

کتاب نسبتاً کم‌حجم هست و قلم شیرینی داره. و در این دور و زمونه که دید خیلی‌ها نسبت به تخمین در توسعه‌ی نرم‌افزار منفی هست، به نظرم می‌تونه خیلی مفید باشه. 🙂

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

Do not develop an attachment to any one weapon or any one school of fighting.”

 

“کتاب The Clean Coder: A Code of Conduct for Professional Programmers کتابی عالی از رابرت سی مارتین که به شرح رفتار حرفه‌ای برنامه‌نویسان می‌پردازه. این رو با کتاب Clean Code از همین نویسنده اشتباه نگیرید. کتاب Clean Code که کتاب خوبی هم هست و دوستان معرفی کردند، بیشتر به تکنیک‌های کدنویسی می‌پردازه. اما کتاب The Clean Coder بیان می‌کنه که یک برنامه‌نویس برای این که حرفه‌ای باشه، چه رفتارها و عادت‌هایی رو در خودش پرورش می‌ده.

موضوعات کتاب شامل عادت‌های کدنویسی، تمرین‌های روزمره، «نه گفتن» و «بله گفتن» به مدیران (!)، کار تیمی، رفتارهای محیط کار، مدیریت زمان و مدیریت فشار، اشتباهات برنامه‌نویسی، تخمین و ماهیت و تکنیک‌های تخمین، بعضی پرکتیس‌های مهندسی و … هست.

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

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

https://bibalan.com/?p=1939
یاسر کازرونی

یاسر کازرونی

تست زندگینامه

کانال تلگرام

برای خروج از جستجو کلید ESC را بفشارید