فصل ۸ — Lean: درک محصول و تحویل سریع | Learning Agile

عنوان اصلی اثر

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

عنوان این مقاله

فصل ۸ — Lean: درک محصول و تحویل سریع

عنوان بخش منبع

Chapter 8: Lean product understanding and fast delivery

نویسندگان

Andrew Stellman و Jennifer Greene

زبان اصلی

English

صفحات منبع

308 تا 334 از PDF

حق‌نشر منبع

Copyright © 2015 O’Reilly Media, Inc. — All rights reserved.

تاریخ ترجمه

1405/05/20 / 2026-08-11

اعتبار ترجمه

ترجمه با کمک هوش مصنوعی

فروش یا انتشار این ترجمه منوط به داشتن مجوز لازم از صاحب حقوق اثر است.

فصل ۸ — Lean: درک محصول، دیدن کل و تحویل سریع

ادامهٔ Value Stream Map: Work در برابر Waiting

Value Stream Map بخش قبل نشان می‌داد که یک Feature در مجموع ۷۱ روز از شروع Work تا Deployment زمان برده است؛ از این ۷۱ روز، ۳۵٫۵ روز Waiting بوده است. این انتظار می‌تواند دلایل مختلفی داشته باشد: Requirement Document بین Reviewerها دست‌به‌دست شده، Estimation Meeting به دلیل تقویم‌های پر عقب افتاده، یا Approval به Committeeای وابسته بوده که فقط هفته‌ای یک بار جلسه دارد. Value Stream Map لازم نیست ابتدا تک‌تک علت‌ها را توضیح دهد؛ مهم این است که اثر تجمعی Delay را روی Feature قابل مشاهده می‌کند.

برای Team، این Wait Time ممکن است چندان محسوس نباشد چون در فاصلهٔ انتظار روی Feature دیگری کار می‌کند؛ اما Customerی که همان Feature را می‌خواهد معمولاً به Priorityهای دیگر Team اهمیتی نمی‌دهد. از دید او ۷۱ روز بین آغاز Work و Delivery گذشته است. وقتی Boss می‌بیند نیمی از این زمان Waiting بوده، مخصوصاً اگر Customer ناراضی شده باشد، بحث دربارهٔ تغییر Process بسیار عینی‌تر می‌شود. اگر Waste کم شود و Waiting کاهش یابد، Delivery Time آینده نیز کمتر خواهد شد.

Gain a Deeper Understanding of the Product — درک عمیق‌تر محصول

«Perceived Integrity یعنی کلیت Product میان Function، Usability، Reliability و Economy تعادلی ایجاد کند که Customer را خشنود کند. Conceptual Integrity یعنی Conceptهای مرکزی System به‌صورت یک کل روان و منسجم با هم کار کنند.» — Mary و Tom Poppendieck

Lean Thinking فقط دربارهٔ دیدن Waste در روش انجام Work نیست؛ Team باید خود Product و نحوهٔ ایجاد Value برای User را نیز شفاف ببیند. این موضوع به Value دیگری می‌رسد: Build Integrity In.

Integrity دو بُعد دارد:

• Internal Integrity: کیفیت و انسجام از دید Developerها و ساختار داخلی System.
• External Integrity: کیفیت و انسجام از دید User و تجربه‌ای که Product ایجاد می‌کند.

برای Internal Integrity، Lean از Thinking Toolهایی مانند Refactoring و Testing استفاده می‌کند؛ همان چیزهایی که در فصل ۷ در XP دیدیم. TDD، Refactoring و Incremental Design راه‌های مؤثر ساخت System با Internal Integrity بالا هستند.

در این بخش تمرکز روی External Integrity است؛ یعنی درک اینکه User چگونه فکر می‌کند و چه چیزی Product را برای او ارزشمند می‌سازد.

Perceived Integrity

نخستین Thinking Tool، Perceived Integrity است: Product تا چه اندازه نیاز فرد را برآورده می‌کند و فرد تا چه حد فوراً احساس می‌کند نیازش برآورده شده است.

هر Product خوب برای حل Problem یا رفع Need ساخته می‌شود. گاهی Need کاملاً Business-Like است؛ مثلاً Accounting Firm به Software مالیاتی نیاز دارد که تغییرات Tax Code سال جاری را درست اعمال کند. گاهی Need سخت‌تر توصیف می‌شود؛ مثلاً Video Game باید «واقعاً سرگرم‌کننده» باشد.

Bug و Crash واضح‌ترین نقص Perceived Integrity هستند، اما پس از رسیدن به Functional Correctness، موضوع ظریف‌تر می‌شود. نویسندگان نمونهٔ یک News Website را می‌آورند که رفتار Copy/Paste آن طی سال‌ها با انتظار User ناسازگار بوده است. زمانی Click-and-Drag به‌جای Selection، Definition یک Word را Pop-Up می‌کرد؛ بعد این رفتار حذف شد؛ سپس Redesign دیگری Selection متن را کاملاً می‌بست و تلاش برای انتخاب متن باعث بازشدن Related Article می‌شد. شاید Organization می‌خواست Intellectual Property را حفظ کند و User را به «Email this article» هدایت کند، اما Product آن‌طور که User انتظار داشت عمل نمی‌کرد؛ این Poor Perceived Integrity است.

Conceptual Integrity

Thinking Tool دوم، Conceptual Integrity است: Featureهای Software تا چه حد با هم یک Product واحد و Unified می‌سازند.

نمونهٔ صنعت Video Game این مفهوم را روشن می‌کند. در اواخر دههٔ ۱۹۹۰ بیشتر Playerها نسبتاً Experienced بودند و Casual Gamerها کمتر بودند. بسیاری از Casual Playerها Gameهای جدید را بیش‌ازحد سخت می‌دیدند، در حالی که Hardcore Gamerها از آسان‌شدن Gameها شکایت می‌کردند. با بزرگ‌شدن صنعت، Teamها یاد گرفتند برای هر دو Audience Conceptual Integrity بسازند.

Gameهای Casual مانند Tetris، Angry Birds و Candy Crush معمولاً Difficulty را طی Levelهای متعدد به‌تدریج افزایش می‌دهند و حس Achievement پیوسته می‌دهند. اگر پنج Level اول بسیار آسان باشند و ناگهان Level ششم تقریباً غیرممکن شود، User دچار Dissonance می‌شود؛ Breakی در Conceptual Integrity.

Hardcore Gamerها از سوی دیگر ممکن است از Grinding، تکرار دشوار و پاداشی که واقعاً Earn شده لذت ببرند. Gameهایی مانند Flappy Bird، Super Meat Boy و بسیاری از Final Fantasyها به Difficulty و تکرار لازم برای Mastery شناخته شده‌اند. Level بسیار آسان در Gameی که هویت آن Difficulty است همان‌قدر Dissonance ایجاد می‌کند که Level تقریباً غیرممکن در Game Casual.

صنعت با افزودن Difficulty Setting، تشخیص Marketهای جدا و Testing با Audience هدف این Problem را مدیریت کرد. Game ممکن است پس از Deathهای مکرر پیشنهاد کاهش Difficulty بدهد، اما Product با Conceptual Integrity خوب نباید این پیشنهاد را آن‌قدر تکرار کند که برای Hardcore Gamer آزاردهنده و ناسازگار با هویت Game شود. Teamها از ابتدای Project تصمیم می‌گیرند Product برای Casual، Hardcore یا هر دو Market است، Testing را بر همان اساس انجام می‌دهند و Marketing را با Audience هماهنگ می‌کنند.

این مثال نشان می‌دهد Build Integrity In فقط Design داخلی Code نیست؛ روش کار Team، Testing و حتی Marketing می‌تواند برای افزایش Conceptual Integrity تغییر کند.

See the Whole — کل را ببینید

Software Team در خلأ کار نمی‌کند. Structure سازمان، Policyها، Approvalها، Ticket Workflow و تصمیم‌های Managerها روی Flow پروژه اثر می‌گذارند. شاید برای شروع Feature به شش Approval نیاز باشد، چند Comment منفی User باعث شود Product Owner Weekendها را Schedule کند، یا Ticketing System هشت مرحلهٔ اجباری داشته باشد.

بعضی از این فعالیت‌ها از منظر Product Waste هستند ولی شاید برای Company لازم باشند. برای تشخیص تفاوت، Lean می‌گوید یک قدم عقب بروید و کل System را Objective ببینید. افراد به Solutionهایی که خود ساخته‌اند Emotional Investment پیدا می‌کنند. Project Managerی که Timesheet پانزده‌دقیقه‌ای طراحی کرده ممکن است از Status Data دائمی خوشحال باشد، اما نداند همین System مثلاً ۵٪ Productivity Team را می‌گیرد. Measurement می‌تواند این Cost را آشکار کند.

Perception افراد نیز متفاوت است. Developer شاید Project را Success بداند چون Problem فنی جذابی حل کرده؛ Project Manager شاید Success را Early Delivery بداند؛ اما اگر Developer برای Deadline شب‌ها و Weekendها را از دست داده باشد، تجربهٔ او کاملاً متفاوت است. Measurement به‌عنوان Thinking Tool Lean کمک می‌کند همه دربارهٔ یک Reality مشترک صحبت کنند.

Lead Time به‌عنوان Measurement

فرض کنید Business Owner دائماً Status Reportهای سبز دریافت می‌کند: Schedule و Budget On Track هستند، Risk Register مرتب است و Ticketها حرکت می‌کنند. ظاهر Dashboard می‌گوید Project کاملاً تحت کنترل است. اما Customerها می‌گویند Requestهای ساده‌شان ماه‌هاست وارد Software نشده و بعضی به Competitor مهاجرت کرده‌اند. در این حالت Status Reportهای مثبت Reality ارزش تحویلی را نشان نمی‌دهند.

یک Measurement مفید Lead Time است: زمان میان Request شدن Feature و Delivery آن.

روش سادهٔ محاسبه در مثال کتاب:

1. هنگام User Request، Start Date را ثبت کنید.
2. وقتی Release شامل آن Request منتشر شد، End Date را ثبت کنید.
3. اختلاف این دو، Lead Time همان Request است.
4. Lead Time همهٔ Requestهای Release را جمع و بر تعداد Featureها تقسیم کنید تا Average Lead Time به دست آید.

ممکن است Teamی که ماهانه Release می‌دهد حدس بزند Lead Time یک تا دو ماه است، اما Measurement نشان دهد Request ساده نیز بیش از شش ماه طول می‌کشد. حالا Problem Objective شده است. هنوز معلوم نیست Fault با Team، Manager یا Structure Business است، اما دیگر نمی‌توان با Green Dashboard وجود Problem را انکار کرد. Goal مشترک و قابل اندازه‌گیری جای «من Boss هستم، درستش کنید» را می‌گیرد؛ این تفاوت Objective Improvement با Magical Thinking است.

پاورقی منبع: Lead Time را می‌توان به روش‌های پیچیده‌تر، مثلاً با Weight دادن بیشتر به Featureهای بزرگ، محاسبه کرد. کتاب برای شفافیت مثال از روش ساده استفاده می‌کند.

Root Cause را پیدا کنید

Measurement فقط نیمهٔ نخست See the Whole است. نیمهٔ دوم یافتن Root Cause، یعنی علت واقعی Problem است.

Lean و XP هر دو از Technique Five Whys استفاده می‌کنند. این Technique نیز ریشه در Manufacturing ژاپن دارد. Team می‌پرسد «چرا Problem رخ داد؟» و پاسخ را دوباره با «چرا؟» دنبال می‌کند، معمولاً حدود پنج مرتبه، تا از Symptom به علت بنیادی برسد.

در مثال Lead Time:

1. چرا Average Lead Time طولانی است؟ چون بیشتر Feature Requestهای User بیش از شش ماه طول می‌کشند تا وارد Software شوند.
2. چرا بیش از شش ماه؟ چون Requestها مرتب برای Last-Minute Changeهای دیگر از Schedule عقب رانده می‌شوند.
3. چرا Last-Minute Change زیاد است؟ چون پیش از Release، Senior Managerها Review نهایی دارند و تقریباً همیشه Fundamental Change می‌خواهند.
4. چرا Senior Managerها Change بنیادی می‌خواهند؟ چون دربارهٔ Appearance، Function و حتی Technical Tool نظرهای مشخص دارند، اما Team این نظرها را تا پس از ساخت Code و Demo نهایی نمی‌شنود.
5. چرا Team زودتر نظر آن‌ها را نمی‌شنود؟ چون Managerها برای تعامل زودهنگام «بیش از حد مشغول» هستند و فقط Final Demo را می‌بینند؛ سپس Team را به Drawing Board برمی‌گردانند.

حالا Root Cause روشن‌تر است. Problem صرفاً «کند بودن Developerها» نیست. Team بسیاری از Featureها را تمام می‌کند، اما Demo نهایی Changeهای زیادی ایجاد می‌کند. Changeها شاید Necessary و حتی درست باشند، ولی Project Manager باید Impact Analysis کند، Plan را Update کند و Featureها را به Release بعد ببرد؛ Featureهای قبلی نیز Push می‌شوند و Lead Time آن‌ها رشد می‌کند. بعضی Customerها هم در همین فاصله به Competitor می‌روند.

راه‌حل‌های بالقوه:

• Software را Iterativeتر بسازید و Senior Managerها را به Demo انتهای هر Iteration بیاورید.
• Approval را به فردی مثل Product Owner Delegate کنید که در Project حضور مداوم دارد و Managerها به Decision او اعتماد می‌کنند.
• Process فعلی را حفظ کنید، اما Account Managerها Expectation Customer را مدیریت کنند و Long Lead Time را به‌عنوان Constraint پذیرفته‌شده ببینند.

نکته این نیست که کدام Solution همیشه درست است؛ نکته این است که Measurement و Root-Cause Analysis به Team و Boss اطلاعات مشترک و Objective می‌دهد تا تصمیم مشترک بگیرند.

Deliver As Fast As Possible — تا حد ممکن سریع تحویل دهید

این عبارت ممکن است در نگاه نخست یادآور Boss فشارآور، حذف Test، کار شبانه و Quick-and-Dirty Hack باشد. اما Agile دقیقاً می‌گوید این رفتارها Delivery را کندتر می‌کنند. Sustainable Development در Agile Principleها بر Pace ثابت و قابل‌دوام تأکید دارد. Shortcut، Corner Cutting و Long Hours معمولاً Time و Money بیشتری در آینده مصرف می‌کنند.

Scrum با Focus و XP با Energized Work این مفهوم را عملی‌تر کردند. Lean سه Thinking Tool دیگر اضافه می‌کند:

• Pull Systems
• Queuing Theory
• Cost of Delay

Queue فهرستی مرتب از Task، Feature یا To-Do برای Team یا فرد است و معمولاً FIFO است، مگر Priority عمداً تغییر کند. Queuing Theory مطالعهٔ ریاضی Queueها و اثر آن‌ها بر System است. Lean تأکید می‌کند Queue Work باید Visible و مرکزی در Decision Making باشد؛ Teamی که Work Intake را شفاف می‌کند بهتر می‌تواند Overload را کنترل کند.

WIP Area Chart برای Visualize کردن Work in Progress

چطور بفهمیم واقعاً «تا حد ممکن سریع» تحویل می‌دهیم؟ پاسخ Lean: Measurement.

Work-in-Progress Area Chart (WIP Area Chart) نموداری است که نشان می‌دهد MMFها چگونه از Value Stream عبور می‌کنند. بهتر است Unit نمودار MMF باشد، نه Task؛ زیرا MMF تکهٔ کوچک Value تحویلی است. در Scrum، User Story می‌تواند MMF باشد و Taskهای ساخت آن داخل Story قرار می‌گیرند. Story در WIP Chart دیده می‌شود، Taskهای ریز نه.

ساخت نمودار

• محور X = Date.
• محور Y = تعداد MMFها.
• برای هر Stage در Value Stream یک Line وجود دارد.
• Area میان Lineها تعداد MMFهای موجود در همان Stage را نشان می‌دهد.

در مثال کتاب، Team در شروع با ۹ User Story کار می‌کند و چند روز بعد ۳ Story دیگر اضافه می‌شود؛ Total WIP به ۱۲ می‌رسد. سپس Programmerها Wireframe چهار Story را شروع می‌کنند. Total هنوز ۱۲ است، اما ۸ Story در Stage اول و ۴ Story در Stage دوم هستند. با حرکت MMFها، Stripeهای مربوط به Stageهای مختلف ضخیم و نازک می‌شوند و History Flow شکل می‌گیرد.

اگر Done Itemها را روی نمودار نگه داریم، به‌مرور Area Done بسیار بزرگ می‌شود و Active WIP مثل نوار باریکی بالای کوه دیده می‌شود. این برای Status Report و نمایش «چقدر Work انجام داده‌ایم» جذاب است، ولی برای Manage Flow بد است. به همین دلیل اغلب WIP Area Chartها Done Work را حذف می‌کنند تا حرکت Work فعال واضح بماند.

• وقتی MMF از Stage قدیمی به جدید می‌رود، Stripe قدیمی نازک و Stripe جدید ضخیم می‌شود.
• Delay، Accumulation و Trendها بصری می‌شوند.
• Figureهای 8-3 تا 8-9 در منبع، ساخت تدریجی همین Chart را نشان می‌دهند.

پاورقی منبع: WIP Area Chart با Cumulative Flow Diagram (CFD) یکسان نیست. تفاوت آن‌ها در فصل ۹ توضیح داده می‌شود.

Bottleneckها و Theory of Constraints

Eliyahu M. Goldratt، فیزیک‌دانی که به Management مشهور شد، Theory of Constraints را معرفی کرد. ایدهٔ کلیدی: یک Constraint می‌تواند کل Throughput System را محدود کند. وقتی Critical Constraint رفع شود، Constraint دیگری Critical می‌شود. بنابراین هر Workflow Overloaded حداقل یک Constraint دارد.

وقتی Work پشت یک Stage جمع می‌شود، آن نقطه را معمولاً Bottleneck می‌نامیم. با تغییر Process یا افزودن Capacity ممکن است Bottleneck اول حذف شود، اما Theory می‌گوید Constraint دیگری ظاهر خواهد شد. Improvement فرایندی یعنی Critical Constraintها را یکی‌یکی پیدا و کاهش دهیم.

برای فردی که خود Bottleneck است، تجربه شبیه Multitasking دائمی است. اصطلاح Multitasking گاهی پوششی برای این واقعیت است که Work بیشتر از Time موجود است. Teamی که ۱۰۰٪ Capacity خود را روی Development مصرف کرده ممکن است از Boss با Magical Thinking درخواست Support، Training، Maintenance و Meeting اضافی بگیرد. چون Work کم‌کم اضافه می‌شود، اعضا شاید فقط احساس فرسودگی کنند و علت Systemic آن را نبینند. Queuing Theory نشان می‌دهد Queue پشت Bottleneck در حال رشد است.

Pull System برای حذف Constraint

Keoki Andrus در Beautiful Teams: «اگر حماقت وارد اتاق شد، وظیفهٔ اخلاقی دارید به آن شلیک کنید، فرقی نمی‌کند چه کسی همراهش باشد.»

Pull System یک Process مبتنی بر Queue یا Buffer است که برای کاهش Constraint استفاده می‌شود. ریشهٔ آن در Manufacturing ژاپن و Toyota دهه‌های ۱۹۵۰ و ۱۹۶۰ است.

Toyota دریافت که Stockpile عظیم Partها مشکل را حل نمی‌کند. ممکن است تقریباً تمام Partها موجود باشند، اما کمبود چند Part خاص کل Assembly Line را متوقف کند. اینجا Cost of Delay اهمیت دارد: Delay در Part کمیاب و Critical بسیار گران است، در حالی که Delay در Part فراوان Cost پایین‌تری دارد.

در Toyota Production System (TPS)، Stationها زمانی Signal می‌دهند که به Part بیشتری نیاز دارند. هر Station Queue کوچکی دارد. Warehouse دیگر Part را دائماً Push نمی‌کند؛ Assembly Line فقط زمانی که Queue پایین می‌آید Part را Pull می‌کند.

سه نوع Waste: muda، mura، muri

TPS سه نوع Waste/Constraint را برجسته می‌کند:

• muda (無駄): futility، uselessness، idleness، superfluity، waste؛ کاری که Value ایجاد نمی‌کند.
• mura (斑): unevenness، irregularity، عدم یکنواختی؛ Flowی که Stop-and-Go است.
• muri (無理): unreasonableness، impossible، beyond one’s power، too difficult، excessiveness؛ Overburden و انتظار غیرواقعی.

این مفاهیم در Software بسیار آشنا هستند:

• Specification باید Approvalهای طولانی بگیرد و Developer منتظر می‌ماند؛ Project قبل از شروع Late شده است.
• Budget آن‌قدر دیر Approved می‌شود که Project از روز اول Delay دارد.
• Design یا Architecture در نیمهٔ Development باید عوض شود ولی Dependencyهای زیاد تغییر را بسیار پرهزینه می‌کنند.
• QA تا پایان همه Featureها Test نمی‌کند و سپس Major Bug یا Performance Problem پیدا می‌شود.
• Analysis و Design آن‌قدر طول می‌کشد که Coding با Night/Weekend Work جبران می‌شود.
• Architect System بسیار زیبا اما غیرعملی طراحی می‌کند.
• کوچک‌ترین Change نیازمند Change-Control Process سنگین است و افراد برای دورزدن Process، Changeهای عظیم را به شکل Ticket کوچک ثبت می‌کنند.
• Project Late است و Boss در هفته‌های آخر افراد بیشتری اضافه می‌کند؛ در نتیجه Confusion و Chaos بیشتر می‌شود.

پاورقی منبع: Fred Brooks در The Mythical Man-Month قانون معروف Brooks’s Law را بیان کرد: افزودن نیروی انسانی به Project دیرکرده، آن را دیرتر می‌کند.

اگر Work بی‌فایده است، muda می‌بینیم. اگر افراد Idle می‌مانند و Work در Burstها می‌آید، mura است. اگر Team مجبور است بیشتر از Capacity انسانی کار کند یا Deadline غیرممکن دارد، muri رخ داده است.

Pull System در Software

در Software به‌جای اینکه User، Manager یا Product Owner Taskها را دائماً به Team Push کند، Requestها وارد Queue می‌شوند و Team با Capacity خودش آن‌ها را Pull می‌کند. اگر Stage خاصی Back Up شود، Buffer می‌تواند Unevenness را هموار کند. ممکن است Project چند Queue و Buffer داشته باشد.

مثال کتاب: Team باید صبر کند تا تمام Featureها در Specification بزرگ نوشته و سپس Review شوند. Team شاید برای فرار از Waiting، Prework براساس Draft و Guess انجام دهد، اما اگر Guess اشتباه باشد، Undo Work Waste دیگری می‌سازد.

Pull System بهتر:

1. Specification بزرگ را به MMFهای کوچک و Pullable، مثلاً Storyهای مستقل با Documentation حداقلی، تقسیم کنید.
2. هر Story جداگانه Review و Approve شود.
3. اگر Review کل Spec به دلیل اختلاف روی چند Feature متوقف می‌شد، حالا Featureهای بدون اختلاف زودتر Approved می‌شوند.
4. به محض Approval نخستین MMF، Team آن را Pull کرده و Work واقعی را شروع می‌کند.
5. اگر Approval به دلیل Regulation یا نیاز واقعی به Perspectives مختلف لازم است، همان Requirement حفظ می‌شود، اما Queue دیگر همهٔ Featureها را پشت یک Item بحث‌برانگیز نگه نمی‌دارد.

این مثال نشان می‌دهد See the Whole، Identify Waste و Pull System چطور با هم Work می‌کنند: Unevenness و Overburdening کم می‌شود و Flow بهتر می‌شود.

نکات کلیدی فصل

• MMF کوچک‌ترین Unit ارزشمند یا Functional است که Team می‌تواند Deliver کند.
• Value Stream Map عمر کامل MMF را همراه Work Time و Wait Time نشان می‌دهد.
• Five Whys برای پیدا کردن Root Cause و See the Whole مؤثر است.
• WIP Area Chart نشان می‌دهد MMFها چگونه در Value Stream Flow می‌کنند.
• Bottleneck نتیجهٔ Constraintی است که Work پشت آن جمع می‌شود.
• سه Waste مهم در TPS: muda، mura و muri هستند.
• Deliver As Fast As Possible به معنی فشار بیشتر نیست؛ یعنی حذف Waste، مدیریت Queue و Flow و کاهش Cost of Delay.

پرسش‌های متداول

Lean در کار روزمره چه کمکی می‌کند؟

Lean واقعاً بیش از آنکه فهرست Practiceهای روزانه باشد یک Mindset است، همان‌طور که Agile Manifesto و Valueهای Scrum/XP خودشان Task روزانه نیستند. Value آن در تغییر Lens تیم است. Lean Thinking کمک می‌کند Fractured Perspective فصل ۲ را پشت سر بگذاریم و Project، Team، Company، Ruleها، Policyها و Culture را به‌عنوان یک System ببینیم.

وقتی دنبال Waste می‌گردید، Eliminate Waste عملی می‌شود؛ وقتی روش ساخت Software را مجموعهٔ Taskهای جداگانه نمی‌بینید و System می‌بینید، See the Whole رخ می‌دهد؛ وقتی با Five Whys از Symptom عبور می‌کنید، Amplify Learning رخ می‌دهد. در فصل ۹ این Perspective برای Improvement دائمی Process به کار گرفته می‌شود.

آیا گفتن اینکه muri می‌تواند «ناممکن» باشد منفی‌نگری نیست؟

کتاب یک Thought Experiment می‌دهد: CEO یک Startup کوچک می‌گوید بزرگ‌ترین Client عاشق Brooklyn است و Team باید در کمتر از یک ساعت با Toothpick و Popsicle Stick مدل مقیاس‌دار بی‌نقص Brooklyn Bridge بسازد؛ وگرنه Company شکست می‌خورد. Motivation هرقدر بالا باشد، مگر اینکه مهارت و شرایط بسیار خاصی وجود داشته باشد، Task عملی نیست.

برخی مدیران فرض می‌کنند Motivation برای هر Goal کافی است؛ این همان Magical Thinking خطرناک است. Deadline غیرواقعی یا Problem فنی تقریباً غیرممکن می‌تواند Team را وارد muri کند. Lean Thinking می‌گوید Effort صرف‌شده برای انجام امر واقعاً غیرممکن Waste است؛ مؤثرترین راه حذف این Waste، حذف Magical Thinkingی است که چنین Expectationی ساخته است.

کارهایی که امروز می‌توانید انجام دهید

• همهٔ MMFهای Project را شناسایی کنید؛ ببینید Story، Sticky Note یا Requirement چگونه Manage می‌شود و Feature بزرگ را به Chunkهای کوچک‌تر بشکنید.
• مثال‌های muda، mura و muri را در Project یادداشت کنید.
• برای MMF تمام‌شده Value Stream Map بسازید و آن را با MMF دیگری مقایسه کنید.
• Bottleneck تکرارشونده را پیدا و دربارهٔ راه کاهش آن گفت‌وگو کنید.
• Commitmentهای زمانی فعلی را بازبینی کنید؛ ببینید واقعاً چه چیزی Commitment است و چه چیزهایی هنوز Option هستند.

منابع معرفی‌شده در کتاب

• Lean Software Development: An Agile Toolkit — Mary و Tom Poppendieck، Addison-Wesley، 2003.
• Lean-Agile Software Development: Achieving Enterprise Agility — Alan Shalloway، Guy Beaver و James R. Trott، Addison-Wesley، 2009.
• User Stories Applied — Mike Cohn، Addison-Wesley، 2004؛ برای شکستن User Storyها و MMFها.
• Commitment — Olav Maassen، Chris Matts و Chris Geary، 2013؛ Graphic Novel دربارهٔ Options Thinking و Project Risk.

Coaching Tips

• برای بسیاری از Software Teamها، «Mindsetی که اسم دارد» مفهوم تازه‌ای است؛ Coach باید روشن کند Lean Mindset است، نه Methodology با Practiceهای ثابت.
• گفت‌وگو دربارهٔ Waste ممکن است منفی به نظر برسد. گاهی یک Gripe Session کنترل‌شده کمک می‌کند Team نمونه‌های Unreasonableness و Impossibility را کشف کند.
• برای مثبت نگه‌داشتن بحث، مثال‌هایی پیدا کنید که از دید Project Waste هستند اما برای Company واقعاً ضروری‌اند. هدف قضاوت افراد نیست؛ Objective Cost Process است.
• Coach باید Friction میان Team و Company را کم کند. اگر Culture طوری است که حتی مطرح‌کردن Problem با Senior Manager پیامد شدید دارد، Agile Adoption آسیب می‌بیند. در صورت امکان Managerها را آرام‌آرام با Magical Thinking خودشان روبه‌رو کنید.
• Process/System را از People جدا کنید. Waste، Inefficiency و Feedback قضاوت دربارهٔ انسان‌ها نیستند؛ ویژگی‌های System هستند.

شکل‌ها و تصاویر منبع

تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و به‌صورت دادهٔ داخلی Base64 جاسازی شده‌اند.