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

در این بخش به سراغ یک ارزش کلیدی دیگر در کانبان خواهیم رفت: توازن (Balance)

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

تجربه‌ی اصلی 2: کار در جریان را محدود کنید (Limit work-in-progress)

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

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

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

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

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

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

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

گزیده:
یکی از تأثیرات مهم سیستم‌های کششی آن است که کار در جریان را تا سقف مورد توافق، محدود می‌کنند و به این ترتیب سیستم را به تحقق اهداف تعیین‌شده هدایت می‌کنند.
دیوید جِی. اندرسون

بخش قبلی

بخش بعدی

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

QUESTION: I keep being asked at interviews what other companies I am interviewing with. Why do they ask? To gauge my popularity or to see if I am really interested in their specific position? Should I answer this question?

ANSWER: The motivations you suggested in your question for why an interviewer might ask are good possibilities, and there are additional reasons as well. Interviewers may be trying to get a sense of what is going on in the job market more generally. Or they may be trying to get a sense of how broadly or narrowly you are focused on a specific job function or industry.

It would be difficult or at least awkward not to offer some response to this question when it’s asked. Your response needs to be an honest one, so your specific circumstances will influence how you answer. For example, your answer depends on whether you are in fact interviewing elsewhere, interviewing with a company’s competitors, or pursuing a tight cluster of roles within an industry or a wide variety of jobs or jobs across industries, among other things. Whether you’re conducting the search while still employed can make a difference to your answer as well. This article offers some good examples of how you might respond in specific circumstances.

Here are some general tips:

• Do not name the other companies you are interviewing at or considering offers from; instead, use generic descriptions of the opportunity (or opportunities) and company (or companies).

• Don’t disclose more than you need to about your job search status for the interview to move on unless you are genuinely in the position of having—or being close to having—another acceptable offer on the table; in this case, explaining that you have an offer on the table may speed up the company’s decision whether or not to also make an offer.

• If you are pushed to disclose more than you want to, remind interviewers that you would extend the same courtesy in talking about them in any discussions you have with other companies.

• Reiterate your requirements for an opportunity to be of interest.

• Reiterate your interest in and value to the company; remind them how your skills, values, and interests align with theirs.

Reference: cfapubs.org

حلقه‌های بازخورد (Feedback Loops) با وجود این که ابتدا غیرضروری به نظر می‌رسند و اغلب نادیده گرفته می‌شوند، اما در افزایش سطح شفافیت فعالیت‌های تیم نقش موثری دارند. خروجی حلقه‌های بازخورد، سیگنال‌هایی است که ممکن است حاکی از وجود مشکلی در سیستم باشد. بدون بازخورد به موقع، نشانه‌های بیماری در سیستم مورد بی‌توجهی قرار می‌گیرند، نادیده گرفته می‌شوند یا آن‌قدر بی‌برنامه و سرسری بررسی می‌شوند که نمی‌توانیم از حل مشکلات واقعاً مطمئن شویم. بنابراین برای تبدیل شفاف‌سازی به محرک اثربخش تغییر و بهبود، حلقه‌های بازخورد ضروری هستند.

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

1- جلسات ایستاده (The Standup Meeting)

جلسات ایستاده، جلسات کوتاهی هستند که به طور منظم برگزار می‌شوند، آن‌قدر کوتاه که اغلب شرکت‌کنندگان می‌توانند (یا گاهی باید) تمام طول مدت جلسه را بایستند؛ ترکیبی از سرعت و تجربه: روش‌های انجام کار مرور می‌شود، اطلاعات افراد در مورد فعالیت‌های تیم تا سطح مناسبی از جزئیات به روز می‌شود و سایر مکالمه‌ها بیرون برده می‌شوند.

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

2- جلسات تکمیل مجدد (Replenishment Meetings)

در هر سیستم تولید کششی لازم است به طور مداوم ورودی‌هایی به درون سیستم تزریق شوند تا تداوم فعالیت سیستم تضمین شود. جلسات تکمیل مجدد نقاطی هستند که با تعیین ورودی‌های بعدی سیستم، جریان یافتن کار را تسهیل می‌کنند و مرز میان احتمالات و ایده‌آل‌ها را با توانایی‌های واقعی سیستم شفاف می‌کنند. هر کدام از روش‌های چابک نوعی از جلسات تکمیل مجدد را در خود دارند، برای نمونه در روش اسکرام، جلسات برنامه‌ریزی اسپرینت (Sprint Planning) نوعی جلسات تکمیل مجدد به شمار می‌آیند.

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

3- سایر جلسه‌ها

در روش‌های چابک جلسات دیگری نیز به منظور مدیریت و بهبود خروجی‌های سیستم، فرایندها و روش‌های انجام کار طراحی شده‌اند که به جلسات بازنگری (Review) و بازاندیشی (Retrospective) معروفند. به عنوان نمونه می‌توان به جلسات بازنگری اسپرینت (Sprint Review) و جلسات بازاندیشی اسپرینت (Sprint Retrospective) در اسکرام و جلسات بازنگری ارائه‌ی خدمات (Service Delivery Reviews) و جلسات بازنگری قابلیت‌های سیستم (System Capability Reviews) اشاره کرد.

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

گزیده:
بازخورد صبحانه‌ی قهرمانان است. کِن بلانچارد

بخش قبلی

بخش بعدی

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

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

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

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

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

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

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

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

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

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

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

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

بخش قبلی

بخش بعدی

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

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

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

بسیاری از سیاست‌ها بیان‌گر کیفیتی هستند که اقلام کاری باید داشته باشند تا به یک ستون تخته اضافه یا از آن حذف شوند، برای نمونه:

• توسعه‌ی اقلامی که در ستون Ready (آماده‌‌ی انجام) قرار می‌گیرند نباید بیش‌تر از پنج روز طول بکشد.
• اقلام وقتی می‌توانند وارد ستون Test (آزمون) شوند که کاملاً بازنگری شده و به تیم نمایش داده شده‌ باشند .
• روی تابلو یا اطراف آن، یادداشت‌هایی مانند «توسعه‌ در کم‌تر از پنج روز»، «کد را بازنگری کنید» و «دمو بدهید!» وجود دارند تا آنچه از تیم انتظار می‌رود را یادآوری کنند.

سایر سیاست‌ها می‌توانند ماهیت جامع‌تری داشته باشند:

• اولویت حفظ ثبات تولید (Production stability) نسبت به تضمین کیفیت رفع خط (QA bug fixing) بیش‌تر است؛ و توسعه‌ی جدید نسبت به هر دو این موارد اولویت بیش‌تری دارد.
• هنگام شروع یک کار جدید، اگر روی کار موجود تأثیرگذار است، به مسئولان اطلاع دهید.

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

به همین دلیل بهتر است با سیاست‌های ساده‌ای آغاز کنیم که تجربه‌های فعلی را نشان می‌دهند و در صورت لزوم بهبود بخشیدن را از آنجا آغاز کنیم. این موارد را یادداشت کنید و سپس به چالش بکشید. آیا همیشه درست است که اینجا دمو داده شود؟ ممکن است این توسعه‌ی ده روزه بالاخره درست شود؟

گزیده:
بدون دانستن دلیل انجام کارها، نمی‌توانیم تصمیم‌های آگاهانه بگیریم یا محصولات باکیفیت تولید کنیم. جیم بِنسون

بخش قبلی

بخش بعدی

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

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

نویسنده: علیرضا اسماعیلی، مدیرعامل شرکت رویای سبز نرم افزارهای آینده (فیوسافت) و عضو تیم ترجمه کتاب اصول و روش کاربردی اسکرام

علیرضا اسماعیلی هستم. مدیر مجموعه‎ای که شاید یکی از مهمترین دغدغه‎هاشون، تولید محصول باکیفیت بوده. این قراریه که با هم گذاشتیم: محصول باکیفیت تولید می‎کنیم؛ محصولی که زیر اون رو امضا کنیم و همه‎ی مسئولیتش رو می‎پذیریم؛ هرچند در دوره‎های مختلف، تجربه‎های موفق و ناموفق زیادی داشته‎ایم.
به نظرم جا انداختن چنین ارزشی در تیم یا به اصطلاح فرهنگ‎سازی اون، نیازمند به‎کارگیری یکی از مهمترین تجربه‎های چابکه. Test Driven Development یا به اختصار TDD. برای اطلاعات بیشتر اینجا و اینجا رو که ببینید.

با دوست عزیزم آقای مهندس مسعود خاری مشورت کردم، آمازون را جستجو کردم و کتاب‎های مختلف تو این حوزه رو بررسی کردم تا به کتاب Professional Test Driven Development with C#: Developing Real World Applications with TDD از انتشارات راکس رسیدم.

کتابی که مفاهیم TDD رو به زبانی ساده بیان می‎کنه و در کنارش شما رو تا جزییات پیاده‎سازی همراهی می‎کنه. این کتاب به زبانی ساده نوشته شده و مرجع مفیدی برای برنامه نویساست. لذت خوندن این کتاب رو از دست ندید!
متأسفانه رویکردی که بیشتر افراد در برخورد با مطالب جدید در پیش می‎گیرند مراجعه به اینترنت و استفاده از مطالب جسته و گریخته است. به جد توصیه می‎کنم که برای یادگیری این موضوع به سراغ اینترنت نرید و از کتاب‎های معتبر استفاده کنید. در این مورد کتابی دیدم با عنوان «کم‌عمق‌ها – اینترنت با مغز ما چه می‌کند». این کتاب در سال 93 توسط آقای امیر سپهرام، ترجمه و توسط انتشارات مازیار به چاپ رسیده. برای اطلاعات بیشتر اینجا رو ببینید.

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

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

آرین شمشیری، عضو تیم توسعه سیستم‌های مالی

با اینکه حرفای آرین شبیه به تبلیغاته ولی عین واقعیته.

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

سیدحسین جلیلی، عضو تیم توسعه پروژه فین‌تک و نرم‌افزارهای اندروید

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

پیمان چیت‎ساز، مدیر پروژه فین‌تک

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

امیرمحمد قزوینی، عضو تیم توسعه سیستم‌های مالی

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

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

ریحانه جعفری، عضو تیم توسعه BPMS

یکی از ارزش‌هایی که در کانبان نقش کلیدی دارد و برخی تجربه‌های کانبان براساس آن تدوین شده‌اند، «شفاف‌سازی» (Transparency) است و سه مورد از شش تجربه‌ی اصلی کانبان با این ارزش مرتبط هستند:
تجربه‌ی اصلی 1: تصویرسازی کنید (Visualize)
تجربه‌ی اصلی 4: سیاست‌ها را شفاف بیان کنید (Make policies explicit)
تجربه‌ی اصلی 5: حلقه‌های بازخورد را طراحی و پیاده‌سازی کنید (Implement feedback loops)

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

تصویرسازی کنید
کانبان واژه‌ای ژاپنی است و معادل آن «علامت تصویری» (Visual Sign) است. بنابراین تعجبی ندارد که پیاده‌سازی و اجرای آن این گونه شروع شود: یک تخته‌ی کانبان که به عنوان نوعی سیستم تصویرسازی برای مدیریت کارها استفاده می‌شود. دلیل تأکید کانبان بر استفاده از تکنیک‌های تصویرسازی در اجرای کار، تلاش برای مشهود کردن کارهای دانشی نامشهودی است که در تیم‌های نرم‌افزاری انجام می‌شود. کار دانشی، طبق تعریف، کاری است که طی آن داده‌ها و اطلاعات از شکلی به شکل دیگر تبدیل می‌شوند بنابراین نتیجه‌ی کار اغلب نامشهود و ناملوس است. کانبان سعی می‌کند با بردن این کارها روی تخته، به مشهود شدن آنها کمک کند و بر قابلیت رهگیری این کارها بیفزاید.

به این ترتیب، به راحتی و با یک نگاه می‌توانیم بفهمیم:

• چه کاری متوقف شده است؟
• هر فرد مشغول انجام چه کاری است؟
• چند نوع کار داریم و هر کدام چند درصد از کل کار است؟
• چه‌قدر کار داریم و هر کدام در چه مرحله‌ای است؟

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

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

به این ترتیب، یک حلقه‌ی تأثیرگذاری متقابل (Virtous Circle) شکل می‌گیرد:

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

گزیده:
کانبان بهتر از اسکرام نیست، بلکه تنها از آن کوچکتر است.
هنریک نیبِرگ

بخش قبلی

بخش بعدی

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

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