کانبَن

مطلبی که می‌خوانید ترجمه‌ قسمت ۱۵۶ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ یکی از موضوعات حوزه‌ مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.

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

سلام دیوید. خوشحالم که شما را اینجا در آلمان دارم. لطفاً خودتان را معرفی کنید و به ما بگویید که چه طور شد که به سراغ کانبن آمدید و الان چگونه با آن مشغولید؟

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

چطور شد که به سراغ کانبن رفتم؟ سئوال خیلی خوبی است. این روندی است که در مجموع، در طی حدود ۱۰ سال شکل گرفته است. ابتدا با توسعه مبتنی بر ویژگی‌ها (Feature Driven Development) که یک متد چابک است کار می‌کردم حتی قبل از آنکه بدانم متدهای چابک چه هستند. و با زمینه آن تجربه، و با خدمت گرفتن برخی ایده‌های Lean و برخی ایده‌های مربوط به تئوری قیود (Theory of Constraints)، آن متد را تکامل دادم و کتاب مدیریت چابک برای مهندسی نرم‌افزار را در سال ۲۰۰۳ منتشر کردم. نسبت به آن موقع، چیزهایی آموختم. توانستم که FDD را دوبار با موفقیت در پروژه‌هایی بکار بگیرم. در تیم‌هایی که مستقیماً به من گزارش می‌دادند. پس از آن موفقیت، از من خواسته شد که استفاده از FDD را در تمام بخش‌های واحد تجاری، گسترش دهم. یکبار با Sprint PCS که یک اپراتور تلفن همراه در آمریکاست و یکبار با Motorola که یک تولید کننده تلفن همراه در آنجاست. در هر دو مورد وقتی سعی می‌کردم که متد را برای چندین تیم گسترش دهم، مقاومت زیادی ایجاد می‌شد و کار، سازمانی نشد. در این موقع به این فکر افتادم که چرا افراد مزایای روشن انجام دادن کار صحیح را نمی‌بینند؟ چرا مقاومت می‌کنند؟ چرا کشمکش داریم؟

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

آیا ممکن است کانبن را در ۲ جمله توضیح دهید.

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

الان، همه در مورد اسکرام صحبت می‌کنند. بیش از ۶۱۰۰۰، استاد اسکرام (Scrum Master) در جهان وجود دارد. همه شرکت‌ها یا همین حالا، از اسکرام استفاده می‌کنند یا مشتاقند که آن را به خدمت بگیرند. بنابراین چرا همچنان به کانبن نیازمندیم؟

فکر می‌کنم این خوب است که می‌بینیم اسکرام به صورت چشمگیری موفق بوده است. شما نمی‌توانید این را نادیده بگیرید. اگر ۳۰۰ یا ۴۰۰ هزار نفر در جهان هستند که مدرک حرفه‌‌ای مدیریت پروژه دارند، برای اسکرام رسیدن به رقم ۶۱۰۰۰ استاد اسکرام، تنها در عرض چند سال، یک موفقیت بسیار بزرگ است.

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

اسکرام قواعد خوبی دارد که واقعاً کمک می‌کند که موفق باشد. ما اسپرینت‌های با طول ثابت را داریم. در روزهای اولیه یعنی ۱۰ سال پیش، ۴ هفته، متداول بود. در ابتدای این ۴ هفته در مورد حوزه کارمان، یعنی صورت کار اسپرینت (Sprint Backlog) توافق می‌کنیم و بعد ۴ هفته کار می‌‌کنیم و اجازه دخالت مشتریان در آن کارها داده نمی‌شود که روش جالبی برای حذف کردن امورتصادفی و تغییرپذیری‌‌ها است. مشتری برای ۴ هفته اجازه تغییر چیزی را ندارد که چیز واقعاً خوبی است. و مکانیزم‌هایی مانند جلسات سرپایی روزانه (Daily Stand-up Meeting) را داریم و در مورد کار صحبت می‌کنیم که باعث انتشار خوب کار در تیم می‌شود و فشارهایی از جانب همتایان برای پذیرش مسئولیت توسط همه افراد را داریم. همه تیم، تعهد اسپرینت، یعنی صورت کارها (Backlog) را در ابتدای کار می‌پذیرند و همه کار را با همدیگر انجام می‌دهند تا در پایان، تمام شود و بعد یک چیزی که کار می‌کند را برای مشتری دمو می‌کنند. و جلسات گذشته‌کاوی (Retrospective) را داریم. همگی اینها، چیزهای واقعاً خوبی هستند.

مشکلی که وجود دارد این است که ۴ هفته خیلی خوب نیست. ممکن است ۲ هفته خوب باشد. من طرفدار این ایده نیستم که اسکرام برای همه شرایطی کار می‌کند. در واقع مطمئنم که امروز من و شما افرادی را ملاقات خواهیم کرد که به طور خاص به این علت به کلاس امروز می‌آیند که شرایطی دارند که اسکرام خیلی به کارشان نمی‌آید (دیوید به کارگاه آموزشی اشاره می‌کند که قرار بوده در همان روز مصاحبه برگزار شود - مترجم). مثلاً در شرایط مأموریت‌های IT و نگهداری سیستم‌ها، این مفهوم که چیزهای مربوط به کارهای ۲ یا ۴ هفته را در یک صورت کار گردآورند، کاملاً برایشان غریبه است.

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

آیا اسکرام و کانبن، رقیب هم هستند یا اینکه مکمل هم هستند؟

من آنها را رقیب هم نمی‌بینم زیرا کان‍بن یک متدولوژی توسعه یا یک متدولوژی مدیریت پروژه نیست. همچنان که اخیراً می‌بینیم که جامعه اسکرام در صدد تعریف کردن مجدد آن هستند، بازتعریف‌هایی از آن بوجود آمده است که رقیب هم هستند. اگر اولین کتاب‌ها را نگاه کنید، یک متدولوژی مدیریت پروژه بود و هیچ محتوای مهندسی در آن نبود. در واقع، خیلی از کسانی که اسکرام استفاده می‌کنند می‌گویند که در کنار اسکرام به XP نیاز دارید. به این ترتیب هم مهندسی و هم مدیریت پروژه خواهید داشت. کانبن هیچکدام این دو، نه متد مهندسی و نه متد مدیریت پروژه، نیست بلکه یک متد مدیریت تغییرات (Change Management) است.

ما تغییرات را تحریک می‌کنیم و تحریک کردن تغییرات، منجر به یک سازمان Lean می‌شود که به شکل مستمر، فرهنگش را بهبود می‌دهد. روشی برای تحریک مستمر تغییرات تکاملی به جای انقلاب در نحوه کار کردن در یک سازمان است. شما کان‍بن را به تنهایی استفاده نمی‌کنید. مردم به سراغم می‌آیند یا از طریق اینترنت می‌پرسند که: ما یک تیم جدید داریم و هنوز یک متدولوژی انتخاب نکرده‌ایم. کان‍بن را استفاده کنیم یا اسکرام را؟ از نظر من، این یک سئوال صحیح به حساب نمی‌آید زیرا شما می‌بایست کان‍بن را بر روی چیز دیگری اجرا کنید. اولین تیمی که با آنها کان‍بن را اجرا کردیم، یک تیم PSP-TSP بود که در هند برای مایکروسافت کار می‌کردند و ما کان‍بن را بر روی PSP-TSP اضافه کردیم. ما PSP-TSP را تغییر ندادیم و توانستیم بهره‌وری تیم را حفظ کرده و زمان دوره‌ها را به ۹۰٪ کاهش دهیم. تیم دیگری که با آنها کان‍بن را اجرا کردیم یک تیم با متد از مدافتاده آبشاری بود. متدولوژی که از دهه ۱۹۷۰ می‌آید. از آن موقع، تیم‌های زیادی را دیده‌ایم که کان‍بن را در شرایط مختلفی به خدمت گرفته‌اند.

تیم‌هایی هم بوده‌اند که کان‍بن را به اسکرام اضافه کرده‌اند. مشکل اینجاست که وقتی کان‍بن را به اسکرام اضافه می‌کنید، خیلی سریع، شروع می‌کنید که اسکرام را تغییر دهید. تیم شروع می‌کند به پرسیدن سئوالاتی از این قبیل که چرا ما دوره‌های ۲ هفته‌ای داریم. کان‍بن کمکشان می‌کند که پیوستگی برخی چیزها را از بین ببرند. مثلاً وابستگی بین ورودی (اولویت‌ها در برنامه‌ریزی) را از خروجی (مکانیزم نسخه جدید دادن). اما در اسکرام این ۳ مورد بهم‌ متصل و پیوسته هستند. یعنی اگر اسپرینت‌های دوهفته‌ای داشته باشید، هر دو هفته یک بار برنامه‌ریزی می‌کنید؛ طول دوره‌تان دو هفته است و هر دو هفته یک بار هم نسخه جدید بیرون می‌دهید. برای برخی سازمان‌ها، این، بهترین انتخاب نیست.

اما اگر دیگر اسپرینت‌های با طول ثابت ۲ یا ۴ هفته‌ای نداشته باشید، آن دیگر اسکرام نخواهد بود. این یکی از چالش‌هاست زیرا جامعه اسکرام، این استاندارد را کنار نگذاشته‌اند. مثلاً، آزمون Nokia برای ارزیابی کیفیت اجرای اسکرام را داریم و می‌توان نتیجه گرفت که اگر نتوانید آزمون را قبول شوید، به نوعی، اسکرام ندارید.

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

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

آیا درست است که اسکرام بیشتر انسان‌محور است در حالیکه کانبن بیشتر در مورد منافع کسب و کار است؟

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

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

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

همانند اسکرام، کانبن هم رویه‌های خاصی را برای توسعه بیان نمی‌کند. آیا رویه‌ای وجود دارد که ترجیح دهید داخل سیستم کانبن باشد؟

فکر می‌کنم برخی رویه‌ها وجود دارند که برای موفقیت کانبن نیاز است. بطور خاص اگر کانبن را برای توسعه نرم‌افزار بکار برید، باید بتوانید نرم‌افزار را منتشر کنید. اگر یک برنامه اینترنتی یا یک سیستم IT داشته باشید، باید بتوانید آن را منتشر کنید. اگر مانند شرکت‌های بازی‌سازی، محصولاتی دارید که نیاز به تولید فیزیکی دارد، باید CD ها را تولید کنید و آن‌ها را تا قفسه مغازه‌ها، پخش کنید. اگر بخواهید این قابلیت انتشار را پشتیبانی کنید باید یک هسته مدیریت پیکربندی (Configuration Management) داشته باشید. لازم است بتوانید نیازمندی‌ها را شناسایی و دنبال کنید. لازم‌است که بر روی نسخه‌های نرم‌افزار، کنترل داشته باشید و بتوانید انشعاب‌ها (Branch) را مدیریت کنید. لازم است بتوانید انشعاب‌ها را به خوبی با هم ادغام (Merge) کنید. باید برای نسخه‌ها اسم بگذارید و اطمینان یابید که چیز درستی منتشر می‌شود و چیزهایی که هنوز تمام نشده‌اند تصادفی، منتشر نشوند. بنابراین مدیریت پیکربندی، قابلیت بنیادی برای قابل اجرا کردن کانبن است.

لازم نیست خیلی پیچیده باشد. فکر می‌کنم اغلب تیم‌های چابک، اغلب تیم‌هایی که XP کار می‌کنند، این قابلیت را از پیش دارند. آنها می‌دانند که چطور داستان‌های کاربری (User Story) را دنبال کنند. آنها می‌دانند که چطور نسخه‌ها را کنترل کنند. می‌دانند چطور انشعاب بگیرند و چطور یکپارچه‌سازی مستمر (Continuous Integration) داشته باشند. آنها می‌دانند چطور نسخه اجرایی نرم‌افزار را برای انتشار، آماده کنند. بنابراین با وجود این که این قابلیت، ضروری است، اما غیرمعمول نیست.

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

در ارتباط با TDD چطور؟

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

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

در کانبن چه مفهوم چابکی وجود دارد؟

خصوصاً بخاطر دو بررسی موردی که در ابتدا منتشر شدند، همیشه این سؤال در مورد چابک بودن در کانبن مطرح بوده است، اولین مورد، بر اساس یک تیم PSP-TSP بود. بحث‌های زیادی در مورد PSP-TSP وجود دارد. بَری بوهم و ریچارد تِرنر یک کتاب با عنوان تعادل بین چابکی و انضباط نوشته‌اند. آنها، PSP-TSP را واقعاً به عنوان یک متد شناخته شده چابک، تعریف کرده‌اند. با این وجود مؤسسه مهندسی نرم‌افزار (SEI)، همچنان این را انکار می‌کند و می‌گوید که PSP یک متد چابک نیست. فکر می‌کنم، اعتقاد فراگیر این است که PSP، متد چابک نیست. دومین بررسی موردی که ما داشتیم در مورد یک تیم بود که کانبن را بر روی یک متد آبشاری (Waterfall) انجام می‌داد که آن هم به وضوح چابک نبود. بنابراین [سوال پیش می‌آید] وقتی که کانبن سیاست‌های سختی در مورد محدودیت کارهای در حال انجام و موارد این چنینی دارد چرا باید چابک باشد؟

من سعی دارم به ایده‌های اصلی که در پس بیانیه چابک قرار دارد، نگاهی بیاندازم. چابک بر این پایه است که به جای اینکه به دنبال اطلاعات کامل بگردیم تا براساس آن مستندات حجیم و کامل را بسازیم و کلی تحلیل انجام دهیم، بدون این اطلاعات کامل، پیشرفت داشته باشیم. چابک می‌گوید: بگذارید کمی وقت برای فهم چیزها صرف کنیم و سریعتر کد زدن را آغاز کنیم و اگر، بعداً بیشتر آموختیم، بازسازی (Refactoring) می‌کنیم زیرا به این شکل ارزانتر است. چابک می پندارد که جلو رفتن بدون اطلاعات کامل، پی‌آمد اقتصادی بهتری دارد. و اگر به جای تلاش برای از ابتدا کامل بودن، بازسازی (Refactoring) داشته باشیم، هزینه و طول دوره کمتر خواهد بود. اگر به همین مفهوم در کانبن توجه کنید، تناقضی وجود ندارد. کانبن اجازه می‌دهد کارها را بدون اطلاعات کامل جلو ببرید. کانبن در این زمینه که باید اطلاعات کامل داشته باشید یا خیر، نظری ندارد. هر سیاستی که برای آغاز کردن فعالیت‌ها داشته باشید، قابل قبول است. اگر با داشتن ۸۰٪ از اطلاعات اجازه دارید از تحلیل به توسعه بروید، قابل قبول است.

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

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

سومین مفهوم موجود در بیانیه، این است که طول دوره واقعاً مهم است. محدودیت کارهای درحال انجام، به بهترین شکل، این امر را ارج می‌نهد. بازار در حال تغییر است. ما برداشتی از محصول، ویژگی‌ها و سرویس‌ها داریم اما این برداشت‌ها طول عمر دارند و در آینده، زمانی می‌رسد که دیگر ارزشی نخواهند داشت یا ارزش کمتری پیدا خواهند کرد. بنابراین اگر، برداشتی از یک ویژگی خیلی جالب در محصولمان داشته باشیم و ۶ ماه طول بکشد که آن را توسعه داده و به بازار برسانیم، اما ۳ ماه بعد، رقیبانمان آن ویژگی را ارائه کنند، در آن صورت ارزش کار به شدت کاهش می‌یابد. بنابراین باید هر چقدر که می‌توانید سریعتر ویژگی‌ها را پیاده‌سازی کرده و آنها را راهی بازار کنید تا سود را بیشینه کنید. بهترین روش ارج نهادن به نیازمندی‌ها، داستان‌های کاربری (User Story)، ویژگی‌ها یا هر چیز دیگری که اسمش را بگذارید این است که به جای این که آنها را به صورت سرمایه ببینید آنها را به عنوان بدهی‌های خود درنظر بگیرید و بگذارید خیلی سریع، جابجا شوند. اگر شما چیزی را به عنوان بدهی بدانید، باعث می‌شود تمایل داشته باشید که مقدار آن را کم نگه دارید. وقتی جامعه چابک این را فهمیدند، شروع به کوتاه کردن طول دوره‌ها کردند. ۴ هفته به خوبی ۲ هفته نیست و ۱ هفته بهتر از حتی ۲ هفته است. گروه‌های کوچک‌تر، طول دوره کوچک‌تر، کم نگه داشتن کارهای در حال انجام، درجهت این نوع نگاه بدهی است. کانبن با تنظیم کردن محدودیت کمیت کارها، شما را به این کار تشویق می‌کند. همچنین تشویقتان می‌کند که در طی زمان این کمیت را کوچکتر کنید و به طول دوره بعنوان یک مقیاس، توجه کنید.

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

شما قبلاً مشتاق FDD بودید. آیا کانبن رهیافتی برای توسعه بدون سربار همان ویژگی‌های FDD است؟

من این مزیت فوق‌العاده را داشته‌ام که در زندگی شغلی‌ام، با یک تیم و گروه عالی، مشغول FDD بوده‌ام. من فکر می‌کنم که کانبن در زمینه‌هایی خارج از FDD، رشد پیدا کرد. به این شکل نیست که تلاش کرده باشیم FDD را با کانبن بهبود دهم اما اگر هیچ گاه FDD را انجام نداده بودم و پیش‌زمینه آن را نداشتم و اگر تفکراتی از Lean را تکامل نمی‌دادم، در انتها به کانبن نمی‌رسیدم. پیش‌زمینه‌هایی مانند نمودار جریان تجمعی (Accumulative Flow Diagram) و فکر کردن در مورد تمام مشکل را داشتم و از آنجا بود که در مورد تئوری قیود (Theory of Constraints) و فهمیدن گلوگاه‌ها (Bottleneck) و نحوه تخفیف دادن آنها فکر کردم. اگر این مجموعه پیش‌زمینه‌ها را نداشتم در پایان به کانبن نمی‌رسیدم. من نظراتی در اینترنت می‌بینم که کانبن، بهینه‌سازی FDD بود اما من مستقیماً آنها را به هم مربوط نمی‌کنم هرچند این تکامل تفکرات خودم در طی سال‌ها را درک می‌کنم.

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

در این باره هم صحبت‌های زیادی در اینترنت، در بلاگ‌ها، در توییتر و در کنفرانس‌ها می‌بینم. گفته می‌شود که کانبن یک رهیافت پیشرفته است و باید قبل از آنکه کانبن را امتحان کنید، در اسکرام خوب شوید. مشاهدات من نشان می‌دهد افرادی این صحبت را می‌کنند که اولاً کانبن را امتحان نکرده‌اند و دوماً علاقه زیادی دارند که ابتدا در اسکرام خوب شوند. من فکر می‌کنم که این مطلب به وضوح درست نیست زیرا اولین تیمی که کانبن را اجرا کرد یک تیم PSP-TSP بود. تیم دوم، یک تیم آبشاری بود. و غالب مطالعات موردی منتشر شده در ۲ کنفرانسی که ما برگزار کرده‌ایم، نیز اینگونه بوده‌اند. مثلاً در سایت Developer.com، یک مطالعه موردی از رابی بوش وجود دارد. مطالعه موردی دیگر که در اینترنت منتشر شده است، مربوط به شرکت گاماسوترا است که یک شرکت بازی‌سازی با تمرکز خاص بر روی تولید بازی است. (اخیرا این شرکت به GameDeveloper تغییر نام داده است -مترجم) در هیچ کدامشان، تیم‌ها قبل از آن که در کانبن خوب بشوند در اسکرام خوب نشده بودند. بنابراین هیچ کسی که در کانبن موفقیت داشته است، چنین چیزی را نمی‌گوید.

و این سئوال را داریم که آیا کانبن تکنیک پیشرفته‌تری است؟ از تجربیات آشکار است که تیم‌هایی که کانبن را اجرا می‌کنند، خیلی سریع، بالغ می‌شوند. اگر با مقیاس CMMI بسنجید، ما به وضوح تیم‌هایی داشتیم که واقعاً در مدت زمان اندکی (۹ ماه، ۱۲ ماه، ۱۵ ماه و ...) از سطوح به نسبت نابالغ و بی‌نظم به سطح واقعاً بالغ مدیریت‌شده کمی (Quantitatively Managed) یعنی سطح چهارم CMMI رسیده‌اند. و به عقیده من، تنها پیش‌نیاز آن، همان طور که پیش از این اشاره کردم، قابلیت مدیریت پیکربندی است. اگر به مدل CMMI نگاه کنید، مدیریت پیکربندی، یک رفتار در سطح ۲ است و یکی از اولین قابلیت‌هایی است که برای تیم‌هایی که بی‌نظمی دارند، توصیه می‌شود. اگر نتوانند پیکربندی را ردیابی و مدیریت کنند نمی‌توانند جلوتر بروند. فکر می‌کنم کاملاً واضح است که تیم‌ها حتی اگر خیلی نابالغ هم باشند، از کانبن سود می‌برند. حتی اگر چابک هم نباشند از کانبن سود می‌برند. اما این سودمندی در مقایسه با آنچه در مورد دیگر متدهای چابک می‌بینیم بیشتر و سریعتر است. علتی که همچنان به کانبن می‌پردازم و آن را تبلیغ می‌کنم این است که تیم‌هایی را دیده‌ام که به چیزهایی رسیده‌اند که من پیش از این در زندگی حرفه‌ای ام نتوانسته بودم به آنها فائق آیم. این را یک نکته خیلی مثبت می‌بینم.

برای سال‌ها، جامعه چابک می‌گفت که نیاز به قاب‌های زمانی (Time box) داریم تا بتوانیم بصورت واقع‌بینانه پیشرفت کار پروژه را اندازه‌گیری کنیم. اما شما خواستار پایان دادن به حکمرانی قاب‌های زمانی شدید. چرا؟

در پس این موضوع چندین ایده وجود دارد. اول اینکه بیانیه چابک، اظهار نمی‌کند که دوره‌های با قاب‌زمانی، لازم است. آنچه واقعاً می‌گوید این است که باید هر ۲ الی ۸ هفته، نسخه نرم‌افزار منتشر کنیم (با ترجیح زمان‌های کمتر). این نسخه‌دادن است که مهم است نه قاب زمانی. فکر می‌کنم بیانیه درست می‌گوید. اما اگر به سال ۲۰۰۱ یا قبل از آن برگردیم، اگر در آن زمان به کسی می‌گفتید که هدف این است که هر دو هفته یکبار نسخه منتشر کنید، تنها ابزار در دسترس، دوره‌های با قاب‌زمانی بود. یک قاب زمانی ۱ هفته‌ای یا ۲ هفته‌ای یا ۴ هفته‌ای.

همانطور که پیش‌از این اشاره کردم، این قاب زمانی ۳ چیز واقعاً متفاوت را به هم وابسته می‌کند. مورد اول این است که هر از چند وقت می‌توانیم با نمایندگان کسب‌وکار، جلسه داشته باشیم تا برای کارهایی که باید انجام دهیم اولویت‌بندی و برنامه‌ریزی کنیم. مورد دوم این است که چقدر طول می‌کشد که یک نیازمندی عملکردی یا ویژگی یا داستان کاربری (User Story) یا هر اسمی که در سازمانتان به آن می‌دهید را تحلیل، طراحی، پیاده‌سازی و تست کنیم. و مورد سوم این است که هر از چند وقت می‌توانیم یک نسخه منتشر کنیم. اینها، هر کدام، مؤلفه‌های متفاوت خودشان را دارند.
این که هر ازچند وقت جلسات کسب‌وکار داریم وابسته به هزینه هماهنگی این جلسات است. دفعات بیشتر بهتر از کمتر است. بهتر است دفعات بیشتری باشد که اطلاعات مربوط به اولویت‌بندی را بدست بیاوریم. این می‌تواند خروجی بهینه‌تری بدهد. این که چقدر طول می‌کشد تا یک داستان کاربری را کد بزنیم، کاملاً بی ربط با این موضوع است که هر از چند وقت با صاحبان کسب‌وکار یا دپارتمان بازاریابی، جلسه داریم. بنابراین چرا باید اینها را با هم، همبسته کنیم؟ چرا باید جلسات برنامه‌ریزی دوهفته یکبار را به منظور دوره دوهفته‌ای پیاده‌سازی داستان‌های کاربری اجبار کنیم؟ باید اجازه داده شود که همبستگی این چیزها از بین برود. وقتی ناهمبستگی (Decoupling) یک اصل خوب در مهندسی نرم‌افزار است چرا آن را در مهندسی فرآیند بکار نبریم؟ همین مطلب در مورد این که هر از چندوقت نسخه بدهیم نیز صادق است.
آخرین بار که یک کلاس کانبن در هامبورگ داشتیم، یک مثال خیلی جالب داشتیم. یکی از شرکت‌کنندگان از یک شرکت تولید فولاد در آلمان می‌آمد. او می‌گفت که می‌توانند جلسات کسب‌وکار را برای اولویت‌بندی، یک بار در هفته داشته باشند که کاملاً معقول است. و زمان دوره مورد نیاز برای این که تحلیل، طراحی، توسعه و تست داشته باشند برای اغلب کارها، حدود ۶ هفته طول می‌کشد اما آنها نرم‌افزاری را توسعه می‌دادند که کنترل بخش حساس خط تولید را به عهده داشت و هزینه از کار انداختن آن برای بروزرسانی نرم‌افزار، خیلی زیاد بود. ارزش فولادهایی که در هرساعت تولید می‌شوند، خیلی زیاد بود. بنابراین می‌خواستند این کار را فقط هر ۶ ماه یک بار انجام دهند زیرا هزینه بسیاری زیادی داشت و ریسک بالایی داشت و زمان زیادی لازم بود تا اطمینان یابند که کدی که مستقر می‌کنند، بدون خطا است. آنها نمی‌توانستند تحمل کنند که خط را راه بیاندازند و به هم بریزد. این یک مثال از جایی است که یک ریتم یک‌هفته‌ای برای اولویت‌بندی، ۶ هفته طول زمان دوره برای توسعه و یک ریتم ۶ ماهه برای استقرار، داشتند. از این مثال کاملاً روشن است که هر متد چابکی که بخواهد طول دوره‌های ۲ هفته‌ای داشته باشد، به چنین فضایی، نمی‌خورد. بنابراین با ناهمبسته‌ کردن این چیزها و این که به آنها امکان دهیم آزادانه حرکت کنند، سازمان‌ها را از حکمرانی قاب‌ زمانی، آزاد می‌کنیم.

خیلی از افراد می‌گویند که گذشته‌کاوی (Retrospective)، قلب رهیافت‌های چابک است. گذشته‌کاوی در کانبن چطور است؟

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

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

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

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

نکته جالب دیگر، «تخمین» است. آیا درست است که کانبن، نسبت به هزینه‌های تخمین زدن کاملاً محتاط است؟

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

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

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

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

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

کانبن خود را به خوبی با این فضا وفق داده است زیرا کمک می‌کند که این فرآیند را تعریف کرده و نحوه پیشرفت کار در آن را نظارت کنید. اما همچنان توسعه نرم‌افزار نسبت به تولید کارخانه، تغییر‌پذیری‌های بییشتری دارد. ممکن است بپرسید انجام دادن یک داستان کاربری (User Story) چه قدر زمان می‌گیرد. پاسخ می‌تواند هرچیزی بین نصف روز تا ۱۰ روز باشد. روشن است که مفهوم زمان تاکت (Takt Time) که در تولید کارخانه‌ای داریم را در اینجا نمی‌توانید داشته باشید. اگر به چیزی مانند خط تولید تویوتای کورولا نگاه کنید، زمان تاکت ممکن است ۱۹۷ ثانیه باشد. این به آن معناست که هر ۱۹۷ ثانیه یک خودروی تویوتا در آخر خط، کامل شده است. چطور به ۱۹۷ ثانیه رسیده‌اند؟ این خیلی راحت پاسخ داده می‌شود. ۱۹۷ ثانیه از محاسبه سه‌سیگمای مربوط به UCL (Upper Control Limit) طولانی‌ترین فعالیت در خط تولید حاصل می‌شود. ممکن است به عنوان مثال فعالیتی مانند چسباندن شیشه جلو باشد که بطور متوسط ۸۰ ثانیه طول بکشد و UCL آن ۹۷ ثانیه باشد و LCL آن ۷۳ ثانیه باشد و برای آن بازه ۷۳ تا ۹۷ ثانیه را داشته باشیم و این فعالیت، کندترین فعالیت خط تولید باشد. در این صورت اگر زمان تاکت را برابر با ۹۷ ثانیه قرار دهیم، برای این که همه چیز روان کار کند، باید هیچ گاه خط تولید متوقف نشود. در توسعه نرم‌افزار نمی‌توانید مفهوم زمان تاکت را داشته باشید. اینکه UCL در دوره توسعه و تست یک داستان کاربری (User Story) چقدر است به نوعی یک سئوال بی‌معنی است.
از طرف دیگر، ما برای مقابله با تغییر‌پذیری‌ها و شرایط مختلف ریسک، تعدادی تکنیک در کانبن نرم‌افزاری توسعه داده‌ایم که واقعاً سیستم را خیلی منعطف کرده است و قابلیت مقابله و به نوعی بهره‌مند شدن از تغییر‌پذیری‌ها را فراهم می‌کند. مثلاً با استفاده از مفهوم‌هایی مانند رده‌های سرویس (Classes of Service) این کار را می‌کنیم. در تولید کارخانه‌ای، تنها دو رده سرویس داریم: صف استاندارد وروداول-خروج اول (First in - First Out) و موارد تسریع شده مربوط به امور واقعاً فوری (در خیلی از سیستم‌های کانبن حتی آن موارد تسریع شده را هم نداریم و فقط همان صف استاندارد FIFO را داریم). علتی که آنجا این روش کار می‌کند این است که چیزهایی که وارد خط می‌شوند یک جور هستند. اگر شما ماشینی را مونتاژ کنید که نیاز به جعبه‌دنده دارد، جعبه‌دنده‌ بعدی با جعبه‌دنده پشت سرش با جعبه دنده پشت سر آن، همگی یکسان هستند. بنابراین هزینه تأخیر برای یک جعبه دنده با هزینه تأخیر جعبه‌دنده بعدی و بعد از آن همگی برابر است.

اما در توسعه نرم‌افزار ارزش هر داستان کاربری (User Story)، منحصربفرد و متفاوت است. بنابراین هزینه تأخیر یک داستان کاربری با هزینه تأخیر داستان کاربری بعد از آن متفاوت است. از این اطلاعات می‌توانید برای مدیریت بهتر ریسک و رسیدن به یک خروجی بهینه‌تر ریسک استفاده نمایید. این که بیشترین ارزش را در کمترین زمان و با کمترین هزینه، تحویل دهید. روش این کار، استفاده از رده‌‌های سرویس است. یعنی کارهای متفاوتی تعریف کنید و رده‌های مختلفی از سرویس با سطوح مختلف پذیرش سرویس را به آنها منتسب کنید و این که اهداف متفاوتی برای طول دوره و زمان تحویل مورد انتظار داشته باشید. با محدودکردن مجموع کارهای در حال انجام، (مثلاً اینکه می‌توانید در مجموع ۲۰ کار در حال پیشرفت داشته باشید) و با تفکیک کردن آنها به رده‌های مختلف سرویس، اجازه می‌دهید که سیستم منعطف باشد. انعطاف نسبت به این موارد که: برخی چیزها بزرگ هستند، برخی کوچکتر هستند، برخی می‌توانند سریعتر انجام شوند، برخی باید کندتر انجام شوند و هرکدام، هزینه‌های تأخیر متفاوتی دارند.

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

آیا صنایع یا انواعی از سازمان‌ها هستند که کانبن را برایشان توصیه نکنید؟

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

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

بسیار خوب دیوید. برای مصاحبه متشکرم. کلام آخر در مورد کانبن؟

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