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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بخش قبلی

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

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

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

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

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

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

بخش بعدی

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

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

پیش‌گفتار:

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

گفتگو:

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

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

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

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

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

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

نسخه‌ی اول این کتاب در سال 1995 نوشته شده. ویرایش سومش مربوط به سال 2004 هست که سعی شده بخش‌های فرایندی کتاب با مفاهیم روز (به خصوص چابکی) به‌روز بشه. اما همون‌طور که اشاره کردم، به نظرم چندان در این کار موفق نبوده.”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 بیان می‌کنه که یک برنامه‌نویس برای این که حرفه‌ای باشه، چه رفتارها و عادت‌هایی رو در خودش پرورش می‌ده.

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

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

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

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

در روز تولدم در کنار سایر هدیه‌ها، یک هدیه‌ی تولد غیرمعمول هم دریافت کردم. کتاب “اصول و روش کاربردی اسکرام” 🙂 🙂 (اینجا را ببینید) این هدیه توسط دوستان عزیزم در شرکت فیوسافت تهیه شده بود که از تک‌تک آنها برای تهیه هدیه‌ی تولد و برگزاری جشن، سپاسگزارم.

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

گزیده:

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

کاروان شهید رفت از پیش
وآن ما رفته گیر و می‌اندیش
از شمار دو چشم یک تن کم
وز شمار خرد هزاران بیش

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

خداحافظ ای همنشین همیشه / خداحافظ ای داغ بر دل نشسته

تو تنها نمی‌مانی ای مانده بی من / تو را می‌سپارم به دلهای خسته

تو را می‌سپارم به مینای مهتاب / تو را می‌سپارم به دامان دریا

اگر شب نشینم اگر شب شکسته / تو را می‌سپارم به رویای فردا

به شب می‌سپارم تو را تا نسوزد / به دل می‌سپارم تو را تا نمیرد

اگر چشمه واژه از غم نخشکد / اگر روزگار این صدا را نگیرد

خداحافظ ای برگ و بار دل من / خداحافظ ای سایه سار همیشه

اگر سبز رفتی اگر زرد ماندم / خداحافظ ای نوبهار همیشه

گردآوری: یاسر کازرونی
پیش‌گفتار:

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

گفتگو:

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

———————–

فرید:

او کتاب Adaptive Code: Agile coding with design patterns and SOLID principles, 2nd Edition نوشته‌ی گری مک‌لین هال را معرفی می‌کند. این کتاب با توضیح مختصری در مورد اسکرام و سازکارهای آن آغاز می‌شود. در ادامه برای سازکارهای تشریح شده نمونه کدهایی را ارائه می‌کند. در این نمونه‌ها از اصول SOLID و فن‌آوری‌های مایکروسافت استفاده می‌کند. کتاب روی موضوع کدنویسی تطبیقی (Adaptive) تمرکز دارد؛ به‌طوری که در طول فرایند تولید نرم‌افزار با اسکرام نیازها و تغییرات جدید را تطبیق داد.

برای آشنایی و یادگیری تست‌نویسی ایشان کتاب The Art of Unit Testing, Second Editionنوشته‌ی رُی اُشیرِو را معرفی کرده است. در این کتاب اصول تست‌نویسی تشریح شده است. همچنین در بخش‌هایی از کتاب نیز از تکنولو‌ژی‌های پرطرفدار دات نت برای پیاده‌سازی اصول استفاده کرده و آنها را مقایسه و تشریح کرده است. مثلاً در بخشی از کتاب مفهومIsolation Framework را مفصل توضیح داده است و ضمن تشریح اصول حاکم بر آن، نمونه‌هایی هم که در دانت از آن‌ها وجود دارد را در کتاب آورده است.

در کتاب Poepleware :productive projects and teams, 3rd Edition نوشته‌ی تام دِمارکو نکات خیلی مهمی از محیط فیزیکی کار، استخدام و نکات مربوط به آن‌ها، نحوه رفتار در تیم و مباحث نسبتا فنی را مطرح می‌کند. این کتاب فوق العاده است و شما با خواندن آن حس می‌کنید نویسنده‌های این کتاب در کنار شما نشسته‌اند و چیزهایی که در محیط کار با آن‌ها مواجه هستید را دیده و تحلیل‌ کرده است.

چاپ دوم کتاب Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries نوشته‌ی براد آبرامز با این که قدیمی به نظر می‌رسد ولی معمولا به توسعه‌دهندگان کم تجربه اکیداً توصیه می‌شود که حتما این کتاب را مطالعه کنند. این کتاب دید خیلی خوبی در مورد نوشتن کدها می‌دهد که مصرف کنندگانش خودشان برنامه‌نویس‌ها هستند. لازم نیست که یک کتابخانه برنامه نویسی مفصل بنویسید تا این کتاب بدرد شما بخورد. برای نوشتن کد در پروژه‌های نستباً کوچکی که چند نفر در آن کار می‌کنند هم بسیار مفید است. نویسنده کتاب مدیر تولید یک یا دو نسخه دات‌نت بوده است و از تجربیاتش در طراحی چارچوب دات‌نت و بعضاً اشتباهاتشان در طراحی صحبت کرده است! این کتاب به نحوی یاد می‌دهد در دات‌نت چطور با الگوهای آن خوب کد بنویسیم.

کتاب 97Things Every Software Architect Should Know: Collective Wisdom from the Experts نوشته‌ی ریچارد مانسون مجموعه‌ای از مقالات کوتاه در مورد موضوعات خاص طراحی، معماری و تیم است که توسط افراد شناخته شده‌ای نوشته شده و تحت عنوان این کتاب مجموعاً به چاپ رسیده است. این کتاب به نظر ایشان در رده کتاب Peopleware قرار می‌گیرد. این کتاب ابزار انتقال تجربه‌ی نویسندگان به خوانندگان است. زمانی که خواننده این کتاب را می‌خواند با نویسندگان کتاب هم صحبت می‌شود و از دانش و تجربه ایشان بهره‌مند می‌شوند.

———————–

ابراهیم:

یکی از نویسندگان کتاب Object-Oriented Analysis and Design with Applications, 3rd Edition گریدی بوچ است که یکی از اعضای گروه موسوم به Three Amigos از پیشگامان مفاهیم شی‌گرایی می‌باشد. کتاب سه بخش کلی دارد. در بخش اول مفاهیم شی‌گرایی به شکل بسیار عمیق (خصوصا در فصل اول که بحث‌ها جنبه فلسفی پیدا می‌کند) مورد بحث قرار می گیرد. در بخش دوم کتاب یک روش تکراری-افزایشی برای تولید شی‌گرای نرم افزار معرفی می‌شود که خیلی شبیه به متدولوژی RUP است. البته نویسنده کتاب آن را به نحو دیگری معرفی می‌کند. در بخش سوم کتاب روش معرفی شده در بخش دوم با چند کاربرد عملی توضیح داده می‌شود. کتاب متن روانی دارد که با توجه به حوزه مورد بحث (شی‌گرایی) به نسبت کتاب قدیمی محسوب نمی‌شود.

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

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

گزیده:
ندارد

چند روز پیش، یکی از دوستانم در تلگرام از من پرسید: “می‌خواستم ازتون بپرسم اگه بخوام شروع کنم به مطالعه در زمینه‌ی Lean، شما مطالعه‌ی چه کتابی را توصیه می‌کنید؟”

در پاسخ برایش نوشتم: “برای چه می‌خواهید Lean یاد بگیرید؟”

ایشان پاسخ دادند: “

متاسفم که من شفاف درخواستم رو بیان نکردم. برای مفاهیم بیزنسی/مدیریتی/استارتاپی برپایه تفکر ناب.

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

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

پیدا کردن چنین کتابی کار سختی نبود، زیرا زمانی همین پرسش برای خودم مطرح بود و به دنبال منابعی بودم تا پاسخ این پرسش را پیدا کنم. یکی از کتاب‌های مناسب را پیدا کردم و به ایشان معرفی نمودم.

علاوه بر آن، آدرس مقاله‌ای را هم برای ایشان فرستادم که بتوانند خیلی زود، پاسخ‌ پرسش‌های خود را پیدا کنند. این مقاله به قلم “مری پاپندیک” (Mary Poppendieck)، نویسنده و متفکر معروف حوزه‌ی توسعه‌ی ناب (Lean Software Development) است.

مقاله‌ی Lean Software Development: The Backstory که در سال ۲۰۱۵ نوشته شده است، مروری دارد بر تاریخ‌چه، تفکر، شباهت و تفاوت آن با چابکی، اصول و وضعیت توسعه‌ی ناب نرم‌افزار در سال ۲۰۱۵.

به صورت خلاصه چند نکته‌ی مهم در مورد تفکر ناب را به نقل از سایت پاپندیک‌ها در اینجا ذکر می‌نمایم .

Lean software development came to focus on these areas:
* Build the right thing: Understand and deliver real value to real customers.
* Build it fast: Dramatically reduce the lead time from customer need to delivered solution.
* Build the thing right: Guarantee quality and speed with automated testing, integration and deployment.
* Learn through feedback: Evolve the product design based on early and frequent end-to-end feedback.

Principles:

Appreciate the Entire Value Stream
… from concept to cash.
Optimizing any part will sub-optimize the whole.

Think Long Term
Think backward from the future.
Think forward to the next generation.

۳) Energize Workers

Building the Thing Wrong
If it seems like there is not enough time to build it right, then there certainly is not enough time NOT to build it right.

A Batch and Queue Mentality
Work in progress hides defects, gets obsolete, causes task switching, and delays realization of value.

۵) Enhance Learning

Integrating Events
Knowledge-based development seeks out knowledge gaps, develops multiple options for solutions, and frequently synchronizes all teams developing the system.

The Last Responsible Moment
Don’t make expensive-to-change decisions before their time – and don’t make them after their time!

Focus on Flow Efficiency, not Resource Efficiency
Resource efficiency interferes with the smooth flow of value; it often delivers half the value for twice the effort.

Manage Workflow rather than Task-based Schedules
The best way to establish reliable, predictable deliveries is to establish reliable, repeatable workflows.

Integrate Early and Often
Every development process ever invented had as its primary purpose to find and fix defects as early in the development process as possible.

Don’t Tolerate Defects
If you expect to find defects during final verification, your development process is defective.

Pay Attention to the Small Stuff
Reliable performance comes when noise is not tolerated, when small failures are deeply investigated and corrected.

Use the Scientific Method
Establish a hypothesis, conduct many rapid experiments, create concise documentation, and implement the best alternative. Then choose another problem and do it again.