تیم‌های توسعه محصول همواره برای تحویل سریع محصول با بالاترین کیفیت ممکن تحت فشارند؛ اما همچنان محصولات و پروژه‌های بسیاری هستند که در میان انبوهی از جلسات بیهوده و ضعف در تصمیم‌گیری به بیراهه می‌روند. مدیریت ناب برای نجات این پروژه‌ها و نرم‌افزارها پا به میدان می‌گذارد.
کاهش هدررفت منابع، بهبود کیفیت محصول و تحویل سریع‌تر نرم‌افزار: این‌ها رویای ذی‌نفعان در تمامی پروژه‌های توسعه نرم‌افزار است؛ رویایی که به کمک متد لین/Lean می‌تواند محقق شود.
فریمورک یا متد توسعه ناب یا Lean روشی است که بر بهینه‌سازی حداکثری و به‌حداقل‌رساندن هدررفت منابع تأکید دارد. این چارچوب یکی از انواع روش‌هایی است که زیر چتر اجایل قرار می‌گیرند.
در این یادداشت با هفت اصل متد لین آشنا می‌شویم و با بررسی نمونه‌هایی از نحوه پیاده‌سازی آن در پروژه‌های واقعی، یاد می‌گیریم چطور از آن در پروژه‌های توسعه نرم‌افزار خود استفاده کنیم.
اجیلیتی مرکز آموزش تخصصی اجایل، مدیریت پروژه و مهارت‌های نرم است؛ با منابع حرفه‌ای ما، آموزش Scrum را از پایه تا پیشرفته یاد بگیرید.
مدیریت ناب چیست؟
ناب یا لین به‌طور هم‌زمان یک متد و یک رویکرد است. یکی از متدهای ذهنیت اجایل است که البته ریشه در اتومبیل‌سازی و کمپانی تویوتا دارد. غول خودروسازی ژاپنی در قرن بیستم به دنبال دو هدف کلیدی بود: به‌حداقل‌رساندن هدررفت در فرایند تولید و به‌حداکثررساندن ارزش برای مشتری.
با وجود تفاوت‌های اساسی بین تولید خودرو به‌عنوان یک محصول فیزیکی و یک نرم‌افزار به‌عنوان یک محصول دیجیتال، دو هدف کلیدی ذکرشده به شکل عمیقی با فرایند توسعه نرم‌افزار همخوانی دارند. در اوایل قرن 21 و تقریباً هم‌زمان با شکل‌گیری مفهوم ذهنیت چابک، رویکرد لین به‌عنوان یک چارچوب اجایل معرفی و خیلی زود محبوب شد.
رویکرد لین می‌گوید توسعه‌دهندگان محصول باید به دنبال به حداکثر رساندن ارزش برای مشتری باشند و در این مسیر باید هر آنچه مزاحم است را کنار گذاشت. توسعه نرم‌افزار با متد لین به زبان ساده یعنی: فقط آنچه اهمیت دارد را خلق کن، سریع یاد بگیر و اجرا کن و پیوسته در حال بهبود و پیشرفت باش.
تصور کنید یک تیم توسعه، بک‌لاگ محصول خود را بررسی می‌کند و متوجه می‌شود حداقل نیمی از فیچرها در این فهرست بدون دریافت بازخورد از طرف کاربران و تنها بر اساس پیش‌فرض‌ها در بک‌لاگ گنجانده شده‌اند. این تیم به جای اقدام به توسعه و ساخت تمامی این فیچرها، تصمیم می‌گیرد تنها بر روی مواردی تمرکز کند که می‌داند کاربر به آنها نیاز دارد یا مستقیماً آنها را درخواست کرده است.
هفت اصل توسعه ناب نرم افزار
Lean فقط به‌معنای دستاورد بیشتر با زحمت کمتر و بهینه‌تر بودن نیست. بلکه به معنای فقط و فقط انجام دادن کارهایی است که واقعاً اهمیت دارند؛ انجام دادن سریع‌تر، هوشمندانه‌تر و بهتر آنها. در ادامه می‌بینیم این فلسفه چطور در هفت اصل کاربردی برای تیم‌های توسعه نمود پیدا می‌کند.
- حذف هدررفت
فیچرهایی نسازید که کسی از آنها استفاده نمی‌کند. کارهایی نکنید که ارزشی ایجاد نمی‌کنند. هدررفت و اتلاف در نرم‌افزار می‌تواند اشکال مختلفی داشته باشد: فیچرهای بلااستفاده، بک‌لاگ‌های بیش از حد طولانی، مستندنگاری وسواسی، جلسات بی‌پایان، دست‌به‌دست شدن تسک‌ها بین تیم‌های مختلف یا بدتر از همه کار روی چیزهایی که مشتری واقعاً نیازی به آنها ندارد.
مثال:
برنامه Dropbox زمانی تعداد زیادی ادغام‌سازی‌های بسیاری با سرویس‌های دیگر داشت. آنها به‌مرور متوجه شدند بسیاری از آنها اصلاً توسط کاربران استفاده نمی‌شوند؛ از این رو دراپ‌باکس تصمیم گرفت فقط بر روی ادغام با برنامه‌های واقعاً کاربردی و ارزش‌آفرین تمرکز کند. نتیجه؟ اثرگذاری بیشتر و زحمت کمتر در نگهداشت محصول.
- حفظ استاندارد کیفی از ابتدای کار
واکنش نشان ندهید، پیشگیری کنید؛ از همان ابتدا به‌دنبال اشکال‌زدایی باشید و اصلاحات و بهبودها را به پایان کار موکول نکنید. کیفیت باید در تمام مراحل توسعه نرم‌افزار در کار دیده شود، نه فقط در تست نهایی. استفاده از تست‌های خودکار، بازبینی کدها، «ادغام و ارائه مداوم یا CI/CD» ابزارهای اصلی Lean برای این کار هستند.
مثال:
تیم‌های مدرن برای هر فعالیتی از پایپ‌لاین CI/CD برای اجرای تست‌های خودکار استفاده می‌کنند؛ این کار کمک می‌کند مشکلات به‌موقع و پیش از رسیدن به مرحله تولید شناسایی شوند و از دوباره‌کاری و هزینه‌های جلوگیری کنند.
-
خلق دانش
با هر فیچر مثل یک آزمایش برخورد کن. یاد بگیر، ثبت کن، بهبود بده. نرم‌افزار پدیده‌ای پیچیده و بی‌ثبات است. توسعه نرم‌افزار برای تیم‌هایی که با رویکرد لین کار می‌کنند باید یک چرخه یادگیری باشد: ساختن، اندازه‌گیری، یادگیری. تست کردن ایده‌ها، دریافت بینش‌های نو و وفق‌پذیری، اسم رمز چنین تیمی است.
مثال:
تیمی برای انتخاب بهترین فرم ثبت‌نام، دو نسخه مختلف طراحی می‌کند و A/B تست اجرا می‌کند. بر اساس داده‌های واقعی، نسخه بهتر انتخاب می‌شود.
-
به تعویق انداختن تصمیم‌گیری
تصمیم‌های بزرگ را وقتی بگیر که داده‌های کافی داره، نه پیش از آن. رویکرد لین تأکید دارد که برای تصمیم‌گیری و متعهد شدن به یک تصمیم اصلاً عجله نکنید. با عدم تعهد زودهنگام به تصمیمات غیرآگاهانه از هزینه‌های بسیاری جلوگیری خواهید کرد.
مثال:
یک استارتاپ به جای انتخاب زودهنگام بین دو پلتفرم ابری آمازون / AWS یا گوگل / GCP، صبر می‌کند تا ابتدا الگوها و داده‌های شفافی از ترافیک و نیازهای خود به‌دست آورد.
-
تحویل سریع
سریع ارائه بده. بازخورد بگیر. سریع بهبود بده. تکرار کن. لین نه به‌دنبال بالا بردن کار به هر قیمتی بلکه به‌دنبال کاهش تأخیر بین ایده و اجراست. تیم‌های متعهد به رویکرد ناب با ارائه نسخه‌های کوچک و کاربردی از محصول خود یا همان «کمینه محصول پذیرفتنی»، از کاربران خود بازخورد می‌گیرند و در چرخه‌ای تکرارپذیر به سمت تکمیل محصول حرکت می‌کنند.
مثال:
یک تیم SaaS نسخه پایه محصول یا همان MVP رو منتشر می‌کنه و هر هفته بر اساس بازخورد کاربران، به‌روزرسانی میده. نتیجه؟ مشارکت بیشتر، مسیر توسعه واقعی‌تر.
-
احترام به افراد
به تیم خود اعتماد کنید و آنها را برای تصمیم‌گیری توانمند کنید. آنها از همه به کار نزدیک‌ترند. Lean روی فرهنگ احترام، همکاری و تفویض اختیار تأکید دارد. افرادی که نزدیک‌ترین درگیری را با کار دارند باید درباره نحوه انجام آن تصمیم‌گیرنده باشند.
مثال:
یک تیم توسعه که برای یک ماژول جدید، خودش فناوری مناسب رو انتخاب می‌کنه و منتظر و نیازمند تأیید مدیران و ذی‌نفعان نمی‌مونه؛ چرا؟ چون تخصص داره و مسئول نتیجه‌ست.
-
بهینه‌سازی کل سیستم
فقط بر روی یک گلوگاه تمرکز نکن؛ کل «جریان ارزش/Value Stream» رو بهبود بده. نگاه لین به سیستم‌هاست نه سیلوها؛ اگر تیم پشتیبانی و فروش ضعیف کار می‌کند پس صرفاً بهبود عملکرد تیم تیم توسعه دردی از شما دوا نخواهد کرد. Lean به کل مسیر - از ایده تا اجرا تا پشتیبانی - نگاه می‌کند؛ تنها در این صورت است که می‌توان اصطکاک‌ها را حذف کرد.
مثال:
یک شرکت کل چرخه‌عمر تحویل نرم‌افزار خود را از طراحی تا پشتیبانی طرح‌ریزی می‌کند و سپس تیم‌ها را طوری سازماندهی می‌کند که تأخیر و تعلل کاهش یافته و تحویل سریع‌تر اتفاق بیفتد.
لین در برابر اجایل: تفاوت‌ها و شباهت‌ها
اشتباه گرفتن دو مفهوم لین و اجایل پدیده ناشناخته‌ای نیست. از آنجایی که هر دوی آنها عمیقاً به یکدیگر مرتبط و حتی درهم‌تنیده‌اند، پیش می‌آید که افراد در مورد آنها دچار سوءتفاهم شوند. در این بخش سعی می‌کنیم سریع و مختصر تفاوت‌های کلیدی و ارتباط این دو مفهوم با یکدیگر را شفاف کنیم.
✅ لین یک رویکرد در باب جریان کار و عملکرد بهینه است.
توسعه ناب نرم‌افزار یک ذهنیت یا فلسفه است که در سیستم تولید خودروی تویوتا ریشه دارد. لین به شما نمی‌گوید چه کار کنید، بلکه شما را برای به‌دست آوردن یک ذهنیت تازه راهنمایی می‌کند.
لین می‌پرسد: «آیا در حال توسعه نرم‌افزار درستی هستیم؟ و آیا آن را به بهینه‌ترین شکل ممکن انجام می‌دهیم؟»
✅ ذهنیت اجایل خانواده‌ای از متدها برای توسعه تکرارپذیری است.
اجایل که در اوایل قرن جاری و با انتشار مانیفست اجایل متولد شد، راهی برای نظم دادن و ارائه دادن خروجی مفید است. ذهنیت Agile یا چابک دارای فریمورک‌های متنوعی از اسکرام و کانبان تا XP و SAFe است.
اجایل می‌پرسد: «چطور می‌توانیم یک خروجی کاربردی را در زمانی کوتاه ارائه کنیم؟ و چطور می‌توانیم بر اساس بازخوردهای واقعی آن را بهبود دهیم؟»
|
لین |
اجایل |
|
|
ریشه |
سیستم تولید تویوتا در قرن 20 |
تیم‌های توسعه نرم‌افزار در سال 2001 |
|
تمرکز |
کاهش هدررفت منابع، به حداکثر رساندن جریان خلق ارزش |
تحویل خروجی در فرایندی تکرارپذیر، همکاری تنگاتنگ با کاربر/مشتری |
|
آیا متدولوژی است؟ |
خیر؛ بیشتر یک ذهنیت و مجموعه‌ای از اصول است. |
بیشتر یک ذهنیت است اما دارای مجموعه گسترده‌ای از متدها و چارچوب‌هاست. |
|
نحوه ارائه |
تحویل خروجی در یک جریان مستمر |
تحویل خروجی در چرخه‌های زمان‌مند |
|
نحوه بهبود کار |
حل ریشه‌ای مشکلات؛ بهبود هم‌زمان کل سیستم |
بازبینی و بازنگری پس از هر مرحله و اعمال اصلاحات در مرحله بعد |
|
نحوه تصمیم‌گیری |
تصمیم‌گیری تنها پس از گردآوری داده‌های دقیق |
تصمیم‌گیری بر اساس بازخورد کاربران و ذی‌نفعان |
☑️ آیا می‌توان از این دو هم‌زمان استفاده کرد؟
بله، قطعاً!
👈تیم‌های اجایل می‌توانند اصول رویکرد ناب را برای بهبود جریان کار و کاهش هدررفت منابع به کار بگیرند.
👈تیم‌های لین می‌توانند از ریتم و فلوی رویکرد چابک را برای وفق‌پذیری بهتر و عملکرد سریع‌تر به فرایندهای خود اضافه کنند.
اجایل / Agile کمک می‌کند سریع و انعطاف‌پذیر باشید و لین / Lean کمک می‌کند هوشمندانه و هدفمند پیش بروید. تیمی که بتواند از این دو در کنار یکدیگر استفاده کند، موفقیت خود را تضمین خواهد کرد.
متد لید: کجا آری، کجا خیر
مدل لین اگر مناسب پروژه شما باشد بدون شک سرعت، شفافیت و ارزش بالایی برای تیم و مشتریان‌تان به همراه خواهد داشت؛ اما در عین حال باید توجه داشت که این مدل راهکاری نیست که برای همه تیم‌ها و پروژه‌ها مؤثر باشد. در این بخش می‌بینیم لین کجا مناسب است و کجا انتخابی نادرست.
کجا لین خوب است:
-
استارتاپ‌ها و توسعه MVP
چرا Lean جواب می‌دهد؟ استارتاپ‌ها نیاز به سرعت و بازخورد سریع دارند. Lean تیم‌ها را وادار می‌کند فقط آنچه واقعاً مهم است را بسازند، آن هم بر اساس داده‌ها و بازخوردهای واقعی از طرف کاربران.
مثال: یک استارتاپ SaaS در ۴ هفته یک MVP می‌سازد، آن را با کاربران اولیه تست می‌کند و بر اساس بازخوردها و بدون اتلاف وقت و سرمایه روی فیچرهای اضافی، سریعاً مسیر خود را اصلاح می‌کند.
-
تیم‌های کوچک یا چندوظیفهای
چرا Lean جواب می‌دهد؟ افراد کمتر یعنی ارتباط ساده‌تر و بوروکراسی کمتر. Lean از خودگردانی تیمی بهره می‌برد و هزینه هماهنگی در تیم‌هایی که چند وظیفه را به‌طور هم‌زمان انجام می‌دهند حذف می‌کند.
مثال: یک تیم ۵ نفره با استفاده از متد Kanban، جلسات روزانه و مستندسازی مشترک، هر هفته یک آپدیت جدید برای کاربران خود منتشر می‌کند.
-
نوسازی محصولات قدیمی/Legacy
چرا Lean جواب می‌دهد؟ در بازسازی کدهای قدیمی و پر از فیچرهای بلااستفاده، Lean کمک می‌کند تمرکز بر ارزش‌های واقعی باشد و از پیچیدگی بیش از حد جلوگیری شود.
مثال: یک شرکت، سیستم CRM قدیمی‌اش را فقط با تمرکز بر ویژگی‌های پرکاربرد بازطراحی می‌کند و تمامی موارد اضافی را حذف می‌کند.
-
محیط‌های محدود از نظر منابع
چرا Lean جواب می‌دهد؟ منابع محدود؟ بودجه فشرده؟ Lean به تیم‌ها کمک می‌کند با اولویت‌بندی ارزش کاربر، با کمترین هزینه بیشترین نتیجه را بگیرند.
مثال: یک سازمان غیرانتفاعی با تیم توسعه کوچک، به‌جای بازطراحی کامل، فقط ویژگی‌های ضروری نسخه موبایل را اصلاح می‌کند.
کجا لین کافی نیست:
تفکر ناب قدرتمند است، اما همیشه به‌تنهایی جواب نمی‌دهد. در این شرایط، باید آن را با مدل‌هایی مانند Agile ،DevOps یا حتی Waterfall ترکیب کرد:
-
محیط‌های با قوانین سختگیرانه
مشکل چیست؟ در صنایعی مانند بهداشت و درمان، فین‌تک یا هوافضا، مستندسازی رسمی و تأییدیه‌های متعدد اجباری است. ذهنیت ناب که روی انعطاف و سرعت تمرکز دارد، ممکن است با الزامات قانونی تضاد داشته باشد.
راهکار: از تفکر Lean در بخش‌هایی مثل ابزارهای داخلی یا نمونه‌های اولیه استفاده کنید، اما هم‌زمان چارچوب‌های قانونی را رعایت کنید.
-
شرکت‌های بزرگ یا تیم‌های پراکنده
مشکل چیست؟ همکاری بین 20 تیم یا بیشتر نیاز به ساختار و برنامه‌ریزی لایه‌لایه دارد.
راهکار: تفکر ناب را در سطح تیم پیاده‌سازی کنید، ولی برای هماهنگی کلی از چارچوب‌هایی مثل SAFe استفاده کنید.
-
تیم‌هایی با بلوغ پایین
مشکل چیست؟ فرض Lean بر این است که تیم‌ها مستقل و البته متعهدند. اگر تیم شما هنوز به سطح خودمدیریتی نرسیده، Lean ممکن است باعث بی‌نظمی شود.
راهکار: ابتدا با Scrum و چارچوب‌های منظم Agile شروع کنید. وقتی تیم بالغ شد، به‌تدریج اصول Lean را وارد کنید.
چه زمانی نباید فقط Lean را به کار برد؟
|
نشانه خطر |
مشکل |
راهکار |
|
نبود داده معتبر از کاربران |
Lean متکی به بازخورد واقعی است. |
ابتدا تحقیق یا Discovery Sprint انجام دهید. |
|
وابستگی‌های زیاد بین تیم‌ها |
Lean زمانی جواب می‌دهد که تیم مستقل باشد. |
لایه‌های برنامه‌ریزی مشخص اضافه کنید. |
|
فرهنگ مدیریتی بالا به پایین |
Lean نیاز به اعتماد و خودگردانی دارد. |
آموزش رهبری یا ترکیب با چارچوب Agile |
|
ترس از اشتباه یا شکست |
Lean بر آزمایش و یادگیری تأکید دارد. |
ترکیب با مدل‌های دارای مدیریت ریسک |
تفکر ناب در درجه اول یک طرز فکر است، نه فقط یک روش:
-
زمانی از آن استفاده کنید که سرعت، تمرکز بر ارزش و بهره‌وری اولویت دارند.
-
وقتی ساختار یا قوانین سختگیرانه نیاز است، آن را با روش‌های دیگر ترکیب کنید.
اصول لین در عمل: یک مطالعه موردی
یک کمپانی SaaS به نام CodeStream ارائه‌دهنده ابزارهای توسعه نرم‌افزار است. این کمپانی پیوسته با چالش تحویل به‌موقع ابزارها و از این رو نرخ تبدیل بسیار پایین روبروست. تغییر رویکرد این کمپانی به اصول لین نتایج زیر را برای آنها در بر داشت.
تعداد اعضای تیم: 20 توسعه‌دهنده، 3 مدیر محصول، 2 طراح.
مشکلات اولیه: انتشار کند ویژگی‌ها، فرسودگی تیم داخلی، نرخ بالای باگ و بک‌لاگ‌های پر از ویژگی‌های بی‌استفاده.
در ادامه می‌بینید که چگونه اجرای هر اصل از لین، اوضاع را دگرگون کرد:
-
حذف هدررفت
اقدامات:
-
بررسی دقیق بک‌لاگ محصول و حذف ۶۰٪ از فیچرهایی که براساس رفتار کاربران یا بازخورد مستقیم آنها نبودند.
-
حذف «شاخص‌های ظاهرفریب / Vanity Metrics» و ایده‌هایی که صرفاً توسط ذی‌نفعان داخلی مطرح شده ولی استفاده‌ای نداشتند.
نتیجه:
-
تمرکز تیم به‌طور چشمگیری بهتر شد.
-
زمان بیشتری صرف ساختن فیچرهایی شد که واقعاً برای کاربر ارزش داشت.
-
سرعت تحویل محصول در سه ماه اول، 40٪ افزایش یافت.
-
حفظ استاندارد کیفی از ابتدای کار / Build Quality In
اقدامات:
-
استفاده از «توسعه مبتنی بر تست» برای ماژول‌های حیاتی
-
پیاده‌سازی CI/CD با تست خودکار
-
ورود تیم تضمین کیفیت از ابتدای کار، نه در پایان فرایند
نتیجه:
-
نرخ باگ از ۶ مورد در ماه به یکی دو مورد کاهش یافت.
-
توسعه‌دهندگان زمان کمتری برای رفع بحران‌ها گذاشتند و زمان بیشتری برای بهبود.
-
انتشار نسخه‌ها قابل پیش‌بینی و کم‌تنش‌تر شد.
-
خلق دانش / Create Knowledge
اقدامات:
-
ساخت سیستم یادگیری مستمر و مستندسازی تجربیات
-
هر آزمایش (چه در UX و چه در بک‌اند) با خلاصه‌ای از آموخته‌ها همراه بود.
-
جلسات کالبدشکافی بعد از هر انتشار بزرگ به روال عادی تبدیل شد.
نتیجه:
-
اشتباهات تکراری کاهش یافت.
-
اعضای جدید سریع‌تر به تیم ملحق شدند.
-
تصمیم‌گیری‌ها به لطف اشتراک دانش بین تیمی، کیفیت بهتری پیدا کردند.
-
به تعویق انداختن تصمیم‌گیری / Defer Commitment
اقدامات:
-
تصمیم‌های بزرگ مانند انتخاب ارائه‌دهنده فضای ابری یا استراتژی مقیاس‌پذیری دیتابیس را تا زمان داشتن داده‌های واقعی به تعویق انداختند.
-
تمرکز اول بر ساختن MVP کاربردی به‌جای طراحی بیش‌از‌حد پیچیده بود.
نتیجه:
-
از ایجاد بدهی فنی پرهزینه جلوگیری شد.
-
تصمیم‌ها دقیق‌تر و هوشمندانه‌تر در زمان درست گرفته شدند.
-
حدود 20٪ از هزینه‌های زیرساختی صرفه‌جویی شد.
-
تحویل سریع / Deliver Fast
اقدامات:
-
تغییر روش از اسپرینت‌های دوهفته‌ای به جریان پیوسته با کانبان.
-
تحویل هفتگی فیچرهای کوچک و قابل استفاده به‌جای لانچ‌های پرهزینه و یکباره.
نتیجه:
-
زمان تحویل از 4-3 هفته به 10-8 روز کاهش یافت.
-
مشتریان زودتر ارزش دریافت کردند و بازخوردشان هدفمندتر شد.
-
تیم با دیدن نتایج سریع، انگیزه و روحیه بهتری گرفت.
-
احترام به افراد / Respect People
اقدامات:
-
تیم‌های توسعه اختیار کامل در انتخاب ابزار، معماری و برنامه‌ریزی کاری خود داشتند.
-
مدیران از میکرو منیج کردن فاصله گرفته و روی رفع موانع تمرکز کردند.
-
اجرای سیاست‌هایی مانند جمعه‌های بدون جلسه و ساعات کاری انعطاف‌پذیر
نتیجه:
-
افزایش رضایت داخلی تیم
-
ریسک ترک نیروها کاهش یافت.
-
همکاری بین اعضا طبیعی‌تر و مؤثرتر شد.
-
بهینه‌سازی کل سیستم / Optimize the Whole
اقدامات:
-
نقشه‌برداری از کل جریان ارائه ارزش: از ایده محصول تا پشتیبانی مشتری
-
شناسایی و رفع تأخیرهای بین طراحی، توسعه، QA و پشتیبانی
-
تشکیل تیم‌های چندوظیفهای با اهداف مشترک به‌جای ساختارهای سیلویی (جزیره‌ای)
نتیجه:
-
«زمان تحویل کلی» به‌صورت قابل توجهی کاهش یافت.
-
همه تیم‌ها دید بهتری نسبت به تأثیر کارشان روی مشتری پیدا کردند.
-
موفقیت تیم‌ها دیگر فردی نبود، بلکه یک موفقیت مشترک بود.
جمع‌بندی: تفکر ناب برای توسعه‌دهندگان مدرن
لین تنها یک ابزار نیست، یک طرز تفکر است. لین فقط به این معنا نیست که سریع‌تر پیش برویم، بلکه یعنی هوشمندانه‌تر حرکت کنیم. هر ویژگی، هر خط کد، هر جلسه باید یک هدف روشن داشته باشد: ارائه ارزش.
این سؤال را چه به‌عنوان یک توسعه‌دهنده، چه به‌عنوان یک مدیر محصول، یا یک تیم هر هفته از خود بپرسید: «آیا داریم چیزی می‌سازیم که واقعاً اهمیت داشته باشد؟» اگر جوابتان به این سؤال یک بله قاطع نبود، باید به فکر تفکر ناب باشید.
مدل Lean راهکاری برای انجام کارهای درست، با افراد درست، در زمان درست است و انجام آنها به درست‌ترین شکل است؛ بگذارید این استاندارد جدید شما باشد.