ارائه توسط: David Anderson
مترجم: محمد علی بزرگ زاده 1393/01/25
Arne Roock با David Anderson در مورد Kanban مصاحبه می‌کند. Anderson از پیشگامان متد Kanban است و نویسنده کتاب Kanban – Successful Evolutionary Change for your Technology Business است. او همچنین مدیر شرکتی است که در زمینه آموزش Lean Kanban و برگزاری کنفرانس‌های آن فعالیت می‌کند.
سلام David. خوشحالم که شما را اینجا در آلمان دارم. لطفاً خودتان را معرفی کنید و به ما بگویید که چطور بسراغ Kanban آمدید و الان چگونه مشغولش هستید؟
خیلی ممنون که من را دعوت کردید. خوشحالم که اینجا در فرانکفورت هستم. در واقع اولین بار است که به فرانکفورت می‌آیم البته خیلی به آلمان آمده‌ام.
چطور شد که بسراغ Kanban رفتم؟ سئوال بزرگی است. این یک تکاملی است که در مجموع، در طی حدود 10 سال شکل گرفته است. ابتدا با Feature Driven Development که یک متد Agile است کار می‌کردم حتی قبل از آنکه بدانم متدهای Agile چه هستند. و با زمینه آن تجربه، و با خدمت گرفتن برخی ایده‌های Lean و برخی ایده‌های مربوط به تئوری قیود (Theory of Constraints)، آن متد را تکامل دادم و کتاب The Agile Managament for Software Engineering را در سال 2003 منتشر کردم. نسبت به آن موقع، چیزهایی آموختم. توانستم که FDD را دوبار با موفقیت در پروژه‌هایی بکار بگیرم. در تیم‌هایی که مستقیماً به من گزارش می‌دادند. پس از آن موفقیت، از من خواسته شد که استفاده از FDD را در تمام بخش‌های واحد تجاری، گسترش دهم. یکبار با Sprint PCS که یک اپراتور تلفن همراه در آمریکاست و یکبار با Motorola که یک تولید کننده تلفن همراه در آنجاست. در هر دو مورد وقتی سعی می‌کردم که متد را برای چندین تیم گسترش دهم، مقاومت زیادی ایجاد می‌شد و کار، سازمانی نشد. در این موقع شروع به این فکر کردم که چرا افراد مزایای روشن انجام دادن کار صحیح را نمی‌بینند؟ چرا مقاومت می‌کنند؟ چرا کشمکش داریم؟
به این نتیجه رسیدم که وقتی یک تعریف تجویزشده در مورد یک پروسس جدید می‌آورید و به افراد می‌گویید که می‌بایست با آن مطابقت یابند و احتمالاً می‌بایست تعریف شغلی و تکنیک‌هایی که استفاده می‌کرده‌اند، را عوض کنند، مقاومت می‌کنند. بنابراین شاید بهتر باشد که تکنیکی را بیازماییم که در عوض «انقلاب»، اجازه می‌دهد تا «تکامل» یابید. براساس یکسری مشاهدات، متوجه شدم که به جای یک متد تجویزشده، با پیاده‌سازی یک سیستم Kanban می‌توان آن تغییرات تکاملی را ایجاد کرد. خلال سال‌های 2004 تا 2007 با چندین تیم در مکان‌های مختلف این را آزمودم تا اینکه اعتماد پیدا کردم که درست کار می‌کند. و شروع کردم به اینکه آموخته‌‌هایم را به معرض عموم بگذارم تا آنها نیز آن را بیازمایند. الان دو سال دیگر گذشته است و واقعاً تیم‌های زیادی درجاهای مختلف دنیا دارند آن را امتحان می‌کنند. یعنی اینکه از Kanban استفاده می‌کنند و بجای یک انقلاب Agile، تغییرات تکاملی را امتحان می‌کنند.
آیا ممکن است Kanban را در 2 جمله توضیح دهید.
در مورد 2 جمله مطمئن نیستم اما خیلی خلاصه اینکه Kanban، یک ایده خیلی ساده است. اینکه تصمیم بگیرید که حجم کارهای در حال انجام خود را محدود کنید. و اینکه کارهای در حال انجام خود را با استفاده از مکانیزم‌هایی از قبیل یادداشت‌های چسبانده شده بر روی وایت‌برد، تصویرسازی کنید. و اینکه تنها زمانی کار جدیدی را آغاز می‌کنید که یک کار جاری را تمام کرده باشید. بنابراین یک مکانیزم آگاه‌سازی وجود دارد که نشان می‌دهد که ما چیزی را تمام کرده‌ایم و می‌توانیم آیتم جدیدی را شروع کنیم. همین است: مکانیزم تصویرسازی، محدودیت کارهای درحال انجام و مکانیزم آگاه‌سازی برای برداشتن کار جدید وقتی کاری تمام شده است.
ادامه مطلب ...

ارائه توسط: Lasse Koskela, Johaness Link
مترجم: محمد علی بزرگ زاده 1393/01/13
در این اپیزود، Johaness Link که یک مربی مهندسی نرم‌افزار مستقل در آلمان است با Lasse Koskela مصاحبه می‌کند.
Lasse، قبل از اینکه وارد مصاحبه شوم. می‌خواهم که در زمینه زندگی حرفه‌ای خودت کمی برایمان صحبت کنی.
من یک خوره‌ی کامپیوتر (Geek)هستم.من برای تقریباً یک دهه در زمینه‌ای که عمدتاً برنامه‌نویسی بود، کار می‌کردم. برای 4-5 سال گذشته اختصاصاً با روش‌های Agile در حوزه مربی‌گری هم برای سازمان‌ها و هم در سطح تیم‌ها، کار می‌کرده‌ام اما هیچگاه برنامه‌نویسی را کنار نگذاشته‌ام بعنوان مثال تا کنون مقدار زیادی تجربه‌های زیبای برنامه‌نویسی Pair داشته‌ام.
هنوز هم بیشتر وقتتان را به برنامه‌نویسی می‌گذرانید؟
بله. در واقع، ابتدای سال تصمیم گرفتم که به یک تیم برای مدت بیشتری بپیوندم. الان برای مدت 7 ماه است که عضو یک تیم هستم.
و آیا این خوب است؟ اینکه فقط کد بزنیم؟
بله. فکر می‌کنم زمانش رسیده بود. برای 5 سال قبل از این، من با هر تیمی بطور ماکزیمم دو هفته کار می‌کردم و بعد جای دیگری می‌رفتم. البته ممکن بود برگردم اما این فرق می‌کند.
علتی که من شما را دعوت کرده‌ام این است که شما کتابی منتشر کرده‌اید. فکر می‌کنم در سال 2008 بوده است.
در واقع سال 2007.
بله، یک کتاب در مورد توسعه‌ به روش (Test Driven Development) TDD. عنوانش چه بود؟
Test Driven
اینکه چیزی شما را جلو ببرد (Driven By Something) تا حدی با اعتیاد به آن همراه می‌شود. آیا شما به نوعی معتاد تست هستید؟
تا اندازه‌ای بله. قطعاً اگر بدون تست کار کنم، احساس ناخوشایندی دارم. بنابراین، بله می‌توان من را معتاد تست خواند.
آیا شده که برخی مواقع بدون تست کار کنید؟
متأسفانه هر از چند گاهی، در چنین وضعیتی قرارمی‌گیرم. به عنوان مثال، در کاری که هم‌اکنون انجام می‌دهم کدهای میراثی (Legacy Code) هستند که نقاط زیادی از آن پوشش کافی تست ندارد. همچنین برخی تکنولوژی‌های استفاده‌شده، نوشتن تست را سخت کرده است. من احساس غریبی دارم. اگر با تست کار می‌کردم احساس راحتی و لذت خیلی بیشتری داشتم.
TDD مدتی است که مطرح شده است اما هنوز افراد مختلف وقتی این لغت را استفاده می‌کنند، منظورهای مختلفی دارند. شما چطور TDD را تعریف می‌کنید؟
من اعتقاد دارم اولین بار، TDD در نوشته‌های انتشاریافته تعریف شد. TDD بیشتر به برنامه‌نویسی به روش تست اول (Test First Programming) اشاره داشت؛ ترکیبی از ایده‌های تست و ایده‌ی پیاده‌سازی حداقل (ساده‌ترین چیزی که کار مورد نظر را انجام دهد) و سپس تست بعدی و پیاده‌سازی بعدی و به این شکل پیش بردن طراحی.
آیا در مورد چرخه TDD فکر نمی‌کنید؟
اولین تعریف TDD ترکیبی از این دو موضوع بود که: اول تست را می‌نویسید و بعد پیاده‌سازی می‌کنید و دیگر تأکید بر طراحی ناشی‌شده از آن (Emergent Design). بنابراین طراحی‌تان به شدت تحت تأثیر تست، نمو پیدا می‌کند. من برای TDD یک تعریفساده‌تری در ذهنم دارم. قطعاً منظورم مفهوم «تست اول» هست ولی شما حتماً قبل از آنکه آغاز کنید در مورد طراحی فکر می‌کنید. شما حتماً ایده‌ای از اینکه کدتان را به کجا می‌خواهید ببرید دارید اما با این وجود اجازه می‌دهید که کد به شما بگوید که آن، پاسخ کار را نمی‌دهد. ممکن است به جهت‌های دیگر برویم. بنابراین تعاریف مختلفی که کم ‌و بیش از خودم هست دارم.
مؤلفه‌های TDD کدامند؟ شما تا حالا، به «ابتدا تست را نوشتن» و «اجازه دادن به کد که مسیر بعدی را نشان دهد» اشاره کردید. من می‌توانم چیزهای دیگری از قبیل Refactoring بعد از تست یا در حین تست را متصور شوم.
بله. اساساً چرخه TDD، عبارتست از: «تست نوشتن، کد زدن و Refactor کردن». اینها قطعاً مؤلفه‌ها هستند. اینها چیزهایی است که وقتی شما TDD کار می‌کنید همواره انجام می‌دهید.
آیا در مورد TDD فکر می‌کنید چیزی وجود دارد که آن را یقیناً لازم می‌کند؟
بله. فکر می‌کنم وجود دارد. تحقیقات و مقالات مختلفی در مورد مؤثر بودن TDD، تأثیر TDD بر روی کیفیت کد و ... وجود دارد. اگر به آن دسته از تحقیقاتی که اظهار می‌کنند که ممکن است TDD تأثیرات منفی در کیفیت داشته باشد، نگاه کنید؛ وقتی خود نتایج واقعی را نگاه می‌کنید می‌بینید که برخی شاخص‌های شیء‌گرایی هستند که امتیاز پایین‌تری آورده‌اند. این واقعاً به علت استفاده از TDD بعنوان روش توسعه نیست بلکه به علت فقدان مهارت طراحی شیءگرا است. اساساً TDD موتوری است که یک ریتم طبیعی برای ایجاد یک طراحی شیءگرای خوب ایجاد می‌کند. مشکل اینجاست که TDD جادویی نیست که این حس را به شما بدهد که طراحی شیء گرای خوب چیست. این یک مؤلفه فراموش‌شده یا ذکرنشده TDD است.
ادامه مطلب ...

ارائه توسط: Alexander Arno, Markus Voleter
مترجم: محمد علی بزرگ زاده 1393/01/02
در این اپیزود Michael و Arno ادامه بحث مربوط به رسیدگی خطا را پی می‌گیرند.
فکر می‌کنم ما در مورد دو دسته شرایط Exception بحث کردیم. آیا می‌توانید بطور خلاصه آنها را توضیح دهید؟
بله، خوب است که با تعریف کردن اصطلاحات (Terminology) شروع کنیم. نه بخاطر اینکه من به اینجور موارد رسمی علاقه‌مندم بلکه به این خاطر که خوب است برای ادامه اپیزود، معانی لغات شفاف باشد. در ارتباط با Exception و شرایط Exception، تمایز از آنجا ناشی می‌شود که آیا واقعاً برای برنامه‌نویس مورد انتظار (Expected) هستند یا خیر. Exception های موردانتظار، مواردی هستند که درباره آنها اطلاع دارید و می‌تواند رخ دهد و فردی ممکن است بخواهد آن را به نحوی رسیدگی کند. مواردی که فراخواننده کد شما ممکن است انتظار آن را داشته باشد یا شما بخواهید که انتظارش را داشته باشد. بعنوان مثال، وقتی شبکه یا پایگاه داده ازکارافتاده است یا وقتی که کسی، یک نام غیرمعتبر وارد کرده است. در این زمان، فراخواننده را آگاه کرده و انتظار دارید که فراخواننده به آن رسیدگی کند. شما در مستندات کلاس، متد، زیرسیستم‌ یا ... مسیرهای ممکن را مستند می‌کنید.
و دسته دوم؟
دسته دوم چیزهایی هستند که موردانتظار نیستند. در وهله اول، فکر کردن و اطلاع دادن آنها غریب به نظر می‌رسد. منشأ اصلی Exceptionهایی که مورد انتظار نیستند، Bug ها یا هر شرایط Exception دیگری هستند که کسی فکر نکرده است که نیاز به رسیدگی دارد. اگر این موارد رخ دهد، کسی نمی‌تواند واقعاً از آن، بازسازی شود. فقط می‌توان مطمئن شد که چیز خیلی بدی رخ نداده است و سیستم را خاموش کنیم و مواردی از این قبیل. بنابراین خودتان را به این محدود کنید که شرایط Exception موردانتظار را به روش خوش‌تعریفی (Well-Defined) رسیدگی کنید و در مورد شرایط Exception ای که انتظار آن نمی‌رود، یک Catch خواهید داشت که در همه موارد آنها را رسیدگی می‌کند که اطمینان می‌یابد که چیز خیلی بدی رخ نداده است و سیستم مانند شرایط مورد انتظار، به شکل برازنده‌ای، رفتار می‌کند.
من معتقدم صحبت در مورد شرایط Exception، خطاها و مشکلات نرم‌افزار، یکی از رهاترین موضوعات در مهندسی نرم‌افزار است. رسیدگی به خطاها، به خوبی شناخته نشده است. تعداد زیادی تعریف و روش‌ مختلف وجود دارد اما تعداد خیلی خیلی کمی، قاعده تعریف‌شده مشخص در مورد آن داریم که چگونه می‌بایست آن را انجام داد و چگونه می‌توان آن را خوب انجام داد.
بله، توصیه ما در این مورد این است که اصطلاحات را از هم مجزا کنید. شرایط Exception ای که به نوعی انتظارش را دارید Error خوانده می‌شوند و شرایط Exception ای که بهیچ‌عنوان انتظارش نمی‌رفته را Exception می‌گوییم. و این نمی‌بایست با اصطلاحات زبان جاوا به اشتباه گرفته شود.
بله، دقیقاً. زبان جاوا این موارد را بخوبی از هم مجزا نمی‌کند. اما این تمایز برای نحوه رسیدگی به آنها در سطح معماری بسیار مفید خواهد بود.
من فکر می‌کنم مدلی که در مورد سطوح گارانتی داریم بر روی طراحی معماری نرم‌افزار نقش دارد.
بله، دقیقاً. در واقع، تعریف این سطوح گارانتی به Herb Sutter برمی‌گردد که در کتابش، Exceptional C++   آنها را مستند کرد. سطوح گارانتی که ما می‌خواهیم معرفی کنیم مرتبط با همان سطوحی است که Sutter در کتابش گفته است. البته دقیقاً همان دسته‌بندی‌های او نیست اما به آن نزدیک است. آن کتاب، کتاب خیلی خوب و قابل توصیه‌ای است.
اولین و بنیادی‌ترین سطح گارانتی، می‌گوید: هر اتفاقی بیافتد، می‌بایست پایدار باشیم. می‌بایست بتوانیم بعد از رخداد مشکل، دوباره فراخوانی داشته باشیم و نمی‌بایست نشتی منابع (Resource Leak) داشته باشیم. کدهای زیادی هست که این سطح از گارانتی را پشتیبانی نمی‌کند با این وجود می‌بایست، این سطح از گارانتی، یک سطح مبنایی باشد که همه بخش‌های کد محصول آن را برآورده کند و اگر در جایی، بعضی جنبه‌های این سطح بنیادی گارانتی برآورده نمی‌شود، می‌بایست فکر کنیم که مشکل کجاست که می‌تواند هرگونه مشکل یا Exception ای باشد که منجر به نشتی یک منبع مثلاً یک هندل دیتابیس، هندل GUI، سوکت، Thread یا هر چیز دیگری شود. شرایطی که یک منبعی از سیستم‌عامل برای همیشه باقی بماند یا حداقل به اندازه طول عمر Process باقی بماند که به همان اندازه باقی ماندن برای همیشه، بد است.
ادامه مطلب ...