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

مقدمه مترجم

مقاله حاضر ترجمه ای است از Applying Lean Thinking to Software Development نوشته استیون پیترز (Steven Peeters) که در سال 2013 در مجله الکترونیکی InfoQ به چاپ رسیده است. در این مقاله در مورد مفهوم اصلی تفکر ناب و نحوه به‌کارگیری آن در تیم‌های توسعه نرم افزاری توضیحاتی ارائه گردیده تا با تمرکز بر تکنیک‌ها و مفاهیم توصیف شده، ضمن کاهش اتلاف و زمان راه اندازی، بتوان کار را با موفقیت به پایان رساند.

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

به‌کارگیری تفکر ناب در توسعه نرم افزار

تفکر ناب (Lean Thinking) مدت زمان زیادی است که وجود دارد. اصول آن در ابتدای قرن بیستم پایه‌گذاری شده است. با در نظر گرفتن چند تغییر جزئی، شرکت تویوتا در آغاز این سیستم را در اواسط دهه 70 میلادی ایجاد کرد (سپس سیستم تولید تویوتا نامیده شد). ناب همچنین اغلب در ترکیب با تکنیک‌های شش سیگما[1] برای کنترل آماری مورد استفاده قرار می‌گیرد و به‌طور گسترده‌ای به عنوان یک استاندارد در صنعت تولید پذیرفته شده است. اما فقط در چند سال گذشته است که ناب در صنایع خدماتی از جمله در بیمارستان‌ها، بانکداری و کارخانه‌های نرم افزاری محبوبیت خاصی کسب کرده است. 

تفکر ناب دقیقا چیست؟ 

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

در حال حاضر، مقداری اتلاف برای ادامه اداره کسب‌وکار شما لازم است، مانند چرخه‌های تأیید خاص، اعتبارسنجی تضمین کیفیت اضافی و غیره. اما بیشتر این به اصطلاح اتلاف‌، در واقع هدر دادن زمان و تلاش است و باید در مجموع حذف شود. در حالت ایده آل، شما می‌خواهید یک فرآیند تولید را 100% بدون اتلاف به پایان برسانید، اما ما در دنیای کاملی زندگی نمی‌کنیم، بنابراین ثابت می‌شود که این مورد به‌طور اسفناکی غیرممکن است. تشخیص اتلاف در محیط تولید نسبتا آسان است (اگر تولیدکنندگانی این مطلب را می‌خوانند، می‌دانم که همیشه این‌گونه نیست، اما تجسم مفهوم اتلاف در محیط تولید بسیار ساده‌تر است)، تصور کنید فرایند تولیدی دارید که جعبه‌های مقوایی ایجاد می‌کند. برای ایجاد آن جعبه‌ها، باید تعدادی مقوا را برش دهید. قطعاتی که برش داده‌اید در محصول نهایی (final product) قابل استفاده نیستند؛ در واقع آنها اتلاف هستند. راه حلی مانند انتخاب شکل جعبه یا طرح متفاوت ممکن است چنین اتلافی را کاهش داده یا همه را با هم حذف کند. 

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

استفاده از تابلوی اسکرام

پس چطور می‌توانید این اصول ناب را در محیط فناوری اطلاعات به‌کار ببرید؟ خوب، اکثر تیم‌های فناوری اطلاعات خارج از کشور(موجود در اینجا) هم‌اکنون نیز از ناب در کارهای روزانه خود استفاده می‌کنند. تابلوی اسکرام (scrum board) که به‌طور گسترده پذیرفته شده‌ در واقع یک کانبان است، ابزاری که اسکرام از ناب وام گرفته است. این بدان معنی است که نقطه شروع ما این است که ناب جایگزینی برای اسکرام نیست (اگرچه می‌تواند باشد) اما تقریبا روشی مکمل است. اسکرام برای کمک به کنترل چرخه توسعه نرم‌افزار (software development cycle) ایجاد شده است؛ ناب به کل فرایند نگاه می‌کند و بسیار فراتر از یک چرخه تولید را دربرمی‌گیرد. با این وجود، اگر واقعا بخواهید می‌توانید از اسکرام به عنوان یک ابزار در هر پروژه نابی استفاده کنید. 

راه‌اندازی سیستم کششی 

ابزار دیگری از ناب که من بسیار دوستش دارم و در پروژه فعلی‌ام اثبات شده که بسیار اثربخش است سیستم کششی (pull system) است. به طور خلاصه، سیستم کششی سیستمی است که در آن شما فقط هنگامی وظیفه بعدی را شروع می‌کنید که وظیفه قبلی تمام شده باشد. این به معنای کاهش میزان کار در جریان (WIP) است. قانون لیتل (Little’s law)[2]، که در مورد جزئیات آن بیشتر بحث خواهم کرد، یک فرمول ارزشمند برای استفاده در تعیین تعداد بهینه WIP شماست. 

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

کاهش مدت زمان راه‌اندازی

در پاراگراف قبلی، به‌طور خلاصه درمورد توسعه‌دهندگان بی‌توجهی نوشتم که به انجام هیچ وظیفه‌ای کمک نمی‌کنند، اما کماکان بر روی آن‌ها وقت می‌گذارند. این یکی از اتلاف‌هایی است که باید از آن آگاه باشید و به آن مدت زمان راه‌اندازی (setup time) گفته می‌شود. بهترین راه برای توضیح دادن مدت زمان راه‌اندازی در توسعه فناوری اطلاعات، توصیف اقداماتی است که یک توسعه‌دهنده باید هنگامی که کار بر روی یک وظیفه معین را آغاز می‌کند انجام دهد. ابتدا، او باید وظیفه قبلی را از ذهن خود پاک کند. (بله، این ممکن است شبیه به برخی از صحبت‌های بروس لی (Bruce Lee) باشد، اما واقعی است.) در مرحله بعد، احتمالاً او باید شروع به وارد کردن زمان خود در نوعی سیستم ردگیری زمان (time-tracking system) کند. باید در مورد وظیفه جدید اطلاع کسب کند. شاید مجبور به گرفتن کد از مخزن گیت شود و کار روی فایل مورد نظر را شروع کند. که این کار زیادی برای راه‌اندازی وظیفه است و البته زمان هم می‌برد، که ما به‌طور اختصاصی آن را زمان راه‌اندازی می‌نامیم.

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

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

ناب به شما کمک می کند تا کار را به انجام برسانید! 

همه این تکنیک‌ها (کاهش زمان راه‎‌اندازی، سیستم کششی و غیره) به تیم شما کمک می‌کنند تا بر روی انجام شدن کار تمرکز کنید و از پرت شدن حواس به چیزهایی که نباید روی آنها تمرکز شود، خودداری کنید. این بدان معنی است که به اصطلاح مدت انجام کار  فرایند (process lead time) کم خواهد شد. PLT مدت زمانی است که یک وظیفه برای طی کردن کل فرآیند، از درخواست تا تولید، طول می‌کشد.

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

[1]. شش سیگما یک استراتژی تحول سازمانی است که موجب توسعه و گسترش متدهای مدیریتی، آماری و نهایتاً حل مشکلات شده و به کمپانی امکان جهش و تحول را می‌دهد.

[2]. قانون لیتل قضیه‌ای است که توسط جان لیتل (john little) نگاشته شده‌است و در تئوری ریاضی صف‌ها کاربرد دارد.

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

مترجم: علی مفخر

ویراستار: مهدیه قدسی نژاد

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

بیشتر بیاموزید

Steven Peeters, Applying Lean Thinking to Software Development. Lean & Kanban InfoQ eMag Issue 10 – March 2014.
Available at URL:https://www.infoq.com/articles/applying-lean-thinking-to-software-development