گردآوری: یاسر کازرونی

پیش‌گفتار:

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

گفتگو:

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

———————–

محمد حسین:

کتاب The Art of Agile Development نوشته‌ی آقای جیمز شور را معرفی می‌کند. او دلیل این معرفی را متن روان کتاب می‌داند و این کتاب را به کسانی که بعد از خواندن چند متن کوتاه مثل بیانیه چابک و راهنمای اسکرام می‌خواهند با مفاهیم چابکی آشنایی عمیق‌تری پیدا کنند به عنوان اولین کتاب پیشنهاد می‌کند.

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

ایشان به شدت خواندن این کتاب را حتی برای باتجربه‌ها پیشنهاد می‌کنند.

———————–

روح‌الله:

او به تیم‌هایی که مشغول توسعه نرم‌افزارهای سازمانی هستند توصیه می‌کند که برای دستیابی به سرآمدی فنی (Technical Excellence) حداقل یک کتاب درباره Domain Driven Design مطالعه کنند.

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

کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software از اریک اوانس اولین کتابی است که در این زمینه نوشته شده است. در این کتاب، الگوهای تکنیکی و الگوهای استراتژیک را به خوبی توضیح داده شده است و کتاب مرجع محسوب می‌شود.

کتاب بعدی Implementing Domain-Driven Design نوشته ورنون است. این کتاب مکمل کتاب اوانس است. فرق مهم این کتاب با کتاب قبلی این است که به مباحث معماری CQRS می‌پردازد و از این نظر یک انسجام فکری در خواننده ایجاد می‌کند.

کتاب سوم Patterns, Principles, and Practices of Domain-Driven Design نوشته اسکات میلت است که جدیدترین کتاب در این زمینه محسوب می‌شود. این کتاب توانسته است بازخوردهای توسعه‌دهندگان و پیشنهادات آنها را مطرح کند و از کتاب‌های قبلی کامل‌تر به نظر می‌رسد.

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

———————–

محمد حسین:

او کتاب ماندگار و کلاسیک Working Effectively with Legacy Code از مایکل فذرز را معرفی می‌کند. این کتاب درباره این است که چگونه در سیستم‌های قدیمی (Legacy System) تغییر ایجاد کنیم و آنها را به سمت بهتر شدن سوق دهیم.

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

مارتین فولر در کتاب Refactoring به مبحث بازسازی کد می‌پردازد و فذرز درباره‌ی آماده کردن سیستم برای بازسازی کدها صحبت می‌کند. این موضوع از آن جهت حائز اهمیت است که بازنویسی کد بدون آزمون واحد خطرناک است و احتمالاً منجر به تولید باگ می‌شود؛ زیرا تا وقتی که پوشش آزمون صددرصد روی کُد نداشته باشیم، اطمینان نداریم تغییرات‌مان باعث ایجاد باگ شده است یا نه؟ از این رو فاولر در کتابش بازنویسی کد را با پشتیبانی آزمون واحد (Unit Test) توام می‌داند اما از طرفی به این سؤال هم جوابی نمی‌دهد که چگونه در سیستمی که از قبل موجود است آزمون واحد اضافه کنیم! او فرض می‌کند که سیستم از ابتدا با TDD توسعه‌ یافته است.

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

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

این کتاب از سه بخش اصلی تشکیل می‌شود که هر کدام شامل چند فصل است:

در بخش اول مفاهیم کلی را مطرح می‌کند (که خلاصه‌ای از آن را آوردیم) و مفاهیمی مثل آزمون واحد را تعریف می‌کند.

در بخش دوم که بخش اصلی کتاب است برای حالت‌های مختلف راهنمایی‌هایی برای تغییر کُد ارائه می‌دهد. مثلاً «من نمی‌توانم این متد را در آزمون فراخوانی کنم» یا «من می‌خواهم یک تغییر بدهم ولی نمی‌دانم چه تست‌هایی باید بنویسم که مکمل هم باشند».

در بخش سوم هم یک کاتالوگ از تکنیک‌های وابستگی‌شکنی (Dependency Breaking) را مطرح می‌کند که شبیه تکنیک‌های بازنویسی‌های فاولر است با این تفاوت که کم‌ریسک است و هدفش صرفاً شکستن وابستگی‌های داخل کُد برای آسان شدن نوشتن آزمون واحد است؛ تازه بعد از آن می‌توان بازنویسی‌های کتاب فاولر را انجام داد.

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

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

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

گردآوری: یاسر کازرونی

پیش‌گفتار:

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

گفتگو:

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

———————–
محمد حسین:

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

درگیری در فوریت‌های روزمره از قبیل رسیدگی به درخواست‌های مشتریان و رفع باگ‌ها باعث می‌شود تا به‌کارگیری تجربه‌های فنی چابک به تعویق بیفند.

ما در اولین فرصت، شروع به بازنویسی یکی از ماژول‌‌های بزرگ و مشکل‌دار سیستم کردیم. در این بازنویسی علاوه بر تجربه‌هایی همچون استفاده از توسعه تکراری-تدریجی، تعریف شرایط پذیرش، استفاده از آزمون‌گر در تیم، استفاده از CI، کار گروهی و آزمون پذیرش خودکار تصمیم گرفتیم از TDD هم استفاده کنیم و به اصول بازسازی کد و تمیز نوشتن کدها نیز اهمیت دهیم.

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

او دلیل موفقیت این تیم را عوامل زیر می‌داند:

1. تمرکز و همبستگی
2. انگیزه‌ی بالای تیم برای اثبات توانمندی خود به سازمان
3. داشتن دانش و تجربه‌ی قبلی در کسب‌و‌کار

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

———————–

روح‌الله:

معتقد است که بدون توجه به اصولی مانند SOLID‌ یا Design Patterns و به‌روش‌های TDD ادعای چابکی کردن ‌ادعای بی‌اساسی است. او به همه‌ی توسعه‌دهندگان و تیم‌های چابک پیشنهاد می‌دهد یک‌بار کتابClean Code را مطالعه کنند.

True flexibility (agility) can only happen when you are able to make changes to the product in a easy, fast, and flexible way. In that sense Organizational Agility is constrained by Technical Agility

او همچنین مثال قبلی (تیم محمد حسین) را یک نمونه خوب از تاثیر مثبت ارزش Courage و اثربخشی در موفقیت یک تیم چابک می‌داند.

———————–

سهیل:

به نقل جمله‌ای از ناپلئون می‌پردازد و تسلط نداشتن و استفاده نکردن از تجربه‌های خوب مهندسی را دلیل نرسیدن به چابکی می‌داند:
چابکی یعنی وقتی برای یک مساله چندین راه حل داشتی، اونی رو انتخاب کنی که تغییر در آینده رو بتونه مهار (ساده) کنه [نه حتی بهترین یا سریعترین راه رو!]

———————–

فرید:

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

———————–

مهرداد:

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

1. پاسخ‌گویی نامناسب به نیاز‌های مشتری در پروژه‌های قدیمی
2. تمایل نداشتن توسعه‌دهندگان تیم برای بازنویسی کدهای این پروژه‌ها
3. نداشتن قابلیت نگهداری کدها و استفاده مجدد از آنها
4. عدم امکان استفاده از معماری و چارچوب‌های جدید
5. نداشتن مرجع کاملی از مستندات کدها
6. تکراری و طولانی بودن کدها

منابع پیشنهادی:

1. Working Effectively with Legacy Code, Michael-Feathers
2. Refactoring: Improving the Design of Existing Code, Martin Fowler
3. Clean Code: A Handbook of Agile Software Craftsmanship, Robert C.Martin

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

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

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

ابتدا با اسکار فیشینگر آشنا شویم:

اسکار فیشینگر (به آلمانی: Oskar Fischinger) (متولد ۲۲ ژوئن ۱۹۰۰ در آلمان – متوفی ۳۱ ژانویه ۱۹۶۷ در لس آنجلس) انیماتور، فیلمساز و نقاش آبستره آلمانی بود.
او بیش از پنجاه انیمیشن کوتاه و هشتصد تابلوی نقاشی در کارنامه خود دارد که بسیاری از آن‌ها در موزه‌ها، نمایشگاه‌ها و مجموعه‌های مختلف در سراسر دنیا نگهداری می‌شوند. یکی از انیمیشن‌های او با عنوان نقاشی متحرک شمارهٔ ۱ که در سال ۱۹۴۷ ساخته شد، در فهرست ملی فیلم در کتابخانه کنگره آمریکا ثبت شده‌است. فیشینگر هم‌چنین به عنوان یکی از پیشگامان ساخت نماهنگ شناخته می‌شود و از معدود فیلمسازانی است که ذوق سمعی و بصری چشمگیرش را با دید علمی و هندسی عمیق به اجسام -که بخاطر تجربهٔ فیشینگر در معماری در او بوجود آمده بود- در خلق شاهکارهای بصری تلفیق می‌کند. او در سال ۱۹۳۵ و پس از شدت گرفتن فشارهای ممیزی حزب نازی روی هنر آبستره، مجبور به ترک آلمان به مقصد هالیوود شد و پایه‌گذار سنتِ تلفیق حرکت و موسیقی در انیمیشنهای والت دیزنی گردید. (مرجع: ویکی پدیا)

بعد هم این آدرس را ببینید:

http://g.co/doodle/p23u5q

حالا سعی کنید به صورت تصویری، آهنگ بسازید و از شنیدن آهنگ‌تان لذت ببرید.

اگر هم فرصت داشتید فیلم An Optical Poem محصول 1938 را در اینجا ببینید .

سپاسگزارم گوگل!

گزیده:

Everything in the world has a spirit which is released by its sound. Oskar Fischinger

در زندگی برای همه لحظاتی وجود دارد که رو به رو شدن با یک پدیده باعث می‌شود ذهن‌اش برای مدت طولانی درگیر شود و در پایان، نگرش وی به محیط پیرامونی‌اش، به دنیا و به زندگی دچار تغییرات اساسی و بنیادی شود.

خواندن کتاب، دوستی با یک فرد، دیدن یک فیلم، ….، نمونه‌ای از این پدیده‌ها و رویدادها هستند.

چند وقتی است که ذهن‌ام به شدت درگیر موضوع anti-fragile است که آقای نسیم نیکولاس طالب نظریه‌پرداز آن است. فعلا جز برخورد کردن با در و دیوارهای ندانستن و نفهمیدن، کار دیگری از دست‌ام بر نمی‌آید.

گزیده:

ندارد.

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

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

پارمیس و آمیتیس رو به بابا می‌کنند و می‌پرسند:”مثلاً چه چیزهایی؟”

پدر در پاسخ می‌گوید: “من نمی‌دونم چه چیزهایی، می‌خوایم اسباب‌کشی کنیم، کارگر میاد. دو سه تا چیزی که خیلی براتون مهمه که توی اسباب‌کشی گم و گور نشه، خراب نشه، بردارید بذارید توی کارتون”.

و این هم دو کارتون دخترهای خوشگل که مهم‌ترین دارایی آنها در زندگی است:

گزیده:

«فرزندانِ شما، حضورتان را بیشتر از هدیه‌هایتان لازم دارند.» جسی جکسون

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

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

مارکوس عدد 2 را بالای ستون توسعه نوشت.

”در این ستون دو قلم در جریان داریم. حالا کار تحلیل­گرها آماده‌ شده و می‌خواهند اون‌ها رو به ستون توسعه ببرند. این کار، محدودیت ما رو برای 2 قلم هم­زمان نقض می‌کنه، درسته؟“

یوآخیم پرسید: ”حالا چی‌کار کنیم؟“

فرانک به­ سرعت نظرش را داوطلبانه گفت: ”اون­ها رو توی ستون توسعه بذارید. به هر حال دیر یا زود باید اون‌ها رو بذاریم اون‌جا.“

مارکوس پرسید: ”کی دیگه فکر می‌کنه ایده‌ای خوبیه که «اون­ها رو بذاریم توی ستون توسعه»؟“

دافنه جواب دندان شکنی داد: ”من مطمئنم که کار درستی نیست! این همون ایده‌ی پاس دادن با هم سکه­ ها نیست؟ که تعداد قلم‌های در جریان رو حداقل ممکن نگه داریم؟“

”درسته- در عوضش چی‌کار می‌تونیم بکنیم؟“

اریک پیشنهاد کرد: ”اگه کار مهمتری بیاد، کار دیگه‌ای حذف می‌شه.“

بث این وضعیت رو تصور کرد، اما با آن راحت و موافق نبود: ”هیچ کاری نکنیم؟ صبر کنیم؟ یوا‌ش‌تر کار کنیم؟“

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

دافنه درحالی‌که صدا و حالت صورتش به بقیه نشان می‌داد که شوخی می‌کند؛ فریاد زد: ”صبر کنید! این غیرممکنه.“

آدام خیلی زود شوخی دافنه را ادامه داد و گفت: ”اصلاً من به شما اجازه نمی‌دم!“

به خاطر داشته باشید حد کار در جریان یک قانون سخت‌گیرانه نیست؛ بلکه دلیلی برای این بحث‌هاست.

اریک وارد بحث شد و گفت: ”ما اکثراً قبل از یه انتشار یه عالمه کار تست داریم. بنابراین حدس می‌زنم بهتره تست ­ها رو به ­مرور انجام بدیم تا از تلنبار شدن اون‌ها جلوگیری بشه. می­ دونید؟ نداریم، نداریم،نداریم، بعد ناگهان همه چی با هم یک دفعه می‌رسن.“

مارکوس سعی کرد دوباره بحث را به مسیر قبلی بازگرداند: ”ممکنه دلایل قابل قبولی گاه و بی‌گاه برای شکستن محدودیت­ وجود داشته باشه. اما اگر اغلب این کار رو انجام می‌دید شاید مجبور بشید حد رو مرور کنید و ببینید آیا حد بیش­تر به جریان بهتر کار کمک می‌کنه. از طرف دیگه اگر به ندرت و یا هرگز به این حد نمی‌رسید هرگز این بحث‌های مفید و این کشمکش رو برای بهبود ندارید. بنابراین لازمه حد رو کاهش بدید.“

یوآخیم به ساعتش نگاه کرد و متوجه شد که مجبور هستند که ادامه بدهند: ”پس الان مشکلی با پیدا کردن مقداری برای حد تعداد کارهای در جریانتون ندارید، درسته؟“

فرانک شروع به صحبت کرد: ”خب، عدد یک برای هر ستون خوبه، اما این عدد درستیه؟“

مارکوس گفت: ”به­ عنوان یک حد به اون فکر کنید و دنبال پیدا کردن مقدار درست نباشید. همان­طور که قبلاً گفتیم، به مرور زمان بازرسی و تطبیق کنید. اگر تصمیم بگیریم که با یک قلم در هر ستون پیش برویم، چه­ طوری می­توان اون رو در یه راه ساده بدست بیارید؟“

آدام پیشنهاد کرد: ”تعداد افرادی که در هر ستون کار انجام می­ دهند رو بنویسید.“

مارکوس گفت: ”آره، ایده خوبیه! این کار رو چه­ طوری انجام می ­دید؟ دوست دارید چه جوری به ما کمک کنید؟“ سپس ماژیک را به آدام داد و یک قدم به عقب رفت.

آدام گفت: ”خب، فکر کنم چون من الان تنها فردی هستم که کار تست را انجام می­دم، این­جا تا آخر عدد 1 بمونه.“ و عدد 1 بزرگی رو بالای ستون آزمون نوشت.

بث به سمت تابلو رفت و گفت: “صبر کنید. من هم گهگاهی کار تست رو انجام می­ دم. این یه راه خوبیه که کارها رو زودتر پیگیری کنیم. کار تحلیل به ندرت همه‌ی وقت من رو میگیره چون من اکثراً منتظرم تا جلسه برگزار شود. فکر کنم 2 عدد بهتری باشه.“

آدام عدد را تغییر داد: ”بله درسته. بیا اینم 2.“

بخش قبلی

بخش بعدی

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

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

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

یوآخیم همین­‌طور که حرف می­‌زد، نقطه‌­هایی روی فلپ‌چارت می‌­گذاشت.

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

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

لحظه‌ای بعد، فرانک سکوت را شکست: ”توی این سناریو زمان انتظار به نظر زیاد میاد، یا یه چیزی رو فراموش کردم؟“

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

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

دافنه گفت: ”بازم به ما کمکی نشد که بفهمیم چه مقداری رو باید در نظر بگیریم.“

یوآخیم شانه‌اش را بالا انداخت و گفت: ”نه، متاسفانه ما نمی‌تونیم بگیم.“

”این چیزیه که خودتون باید به اون برسید و به‌­طور مرتب اون رو بهبود بدید تا بطور مداوم جریان سریع‌تر و بهتری در گردشِ کارتون داشته باشید.“

طاقت فرانک تمام شد و گفت: ”بسیار خب، تعداد قلم‌های کاری هم­زمان رو تغییر می‌­دیم. اما از چی به چی؟ شما یه معیاری باید به ما بدید!“

یوآخیم گفت: ”شروع آسونی داره. هر کی با یه قلم روی تابلو شروع می‌کنه. خیلی زود می‌بینید که کلی از مشکلات در یه جا تلنبار شده، مثلاً زمانی‌­که توسعه‌دهنده‌ها یه شرایط سختی رو دارند.“

دافنه با شوخی و کنایه گفت: ”«منظور» شما از این حرف‌ها چیه؟“ البته دافنه سریع بود و همه این را می‌دانستند.

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

مارکوس یادداشت­های روی تابلو را پاک کرد و با دافنه مشورت کرد: ”اگه بگم چون دو تا توسعه‌دهنده داریم فکر می‌کنیم که دو تا قلم‌ اندازه‌ی معقولی برای پیاده‌سازی همزمانِ، درسته؟“

دافنه پاسخ داد: «حتماً»

بخش قبلی

بخش بعدی