فصل ۸ — Lean: حذف اتلاف و دیدن کل سیستم
«Lean یک طرز فکر است؛ یک مدل ذهنی از نحوهٔ کارکرد جهان.» — Mary و Tom Poppendieck، The Lean Mindset: Ask the Right Questions
در بخشهای قبلی کتاب با Scrum و XP آشنا شدیم. هر دو روش مجموعهای از Practiceها دارند که تیم میتواند آنها را اجرا کند، و مجموعهای از Valueها و Principleها که به اعضای تیم کمک میکند به Mindset مناسب برسند. در Scrum نشانههای ظاهری روش روشناند: Daily Scrum برگزار میشود، کار در Sprintها جریان دارد و Product Owner و Scrum Master نقشهای مشخصی دارند. در XP نیز Practiceهایی مانند Refactoring مداوم، Test-Driven Development، Continuous Integration و Incremental Design نشان میدهند تیم از XP استفاده میکند.
بااینحال، اجرای Practiceها بدون درک Valueها و Principleها فقط نتیجهای «بهتر از انجامندادن» میدهد. Ken Schwaber تأکید کرده بود که بدون فهم Collective Commitment و Self-Organization، ماهیت Scrum درک نشده است. در XP نیز اگر Simplicity، Energized Work و سایر Valueها صرفاً به مجموعهای از آیتمهای چکلیست تقلیل داده شوند، تیم واقعاً تغییر را نمیپذیرد و در نهایت نرمافزاری پیچیده و دشوار برای نگهداری تولید میکند.
Lean از این جهت متفاوت است. برخلاف Scrum و XP، Lean یک فهرست ثابت از Practiceهای اجرایی نیست؛ Lean یک Mindset است. این Mindset نیز Valueها و Principleهایی دارد که در واژگان Lean از آنها با عنوان Thinking Tools یا «ابزارهای تفکر» یاد میشود. عبارت Lean Thinking برای همین مدل ذهنی به کار میرود. ایدههای Lean دههها در تولید و Manufacturing استفاده شده بودند و Tom و Mary Poppendieck در دههٔ نخست قرن بیستویکم آنها را برای توسعهٔ نرمافزار اقتباس کردند. در این کتاب واژهٔ Lean با L بزرگ به همین کاربرد در توسعهٔ نرمافزار Agile اشاره دارد.
در این فصل، Valueهای Lean و Thinking Toolهایی بررسی میشوند که به تیم کمک میکنند اتلاف را تشخیص دهد و حذف کند و در عین حال کل سیستمی را که نرمافزار در آن ساخته میشود ببیند.
Lean Thinking
نامگذاری یک Mindset شاید در ابتدا عجیب به نظر برسد، اما بسیار کاربردی است. در فصلهای قبل دیدیم که Scrum برای پذیرش مؤثر به Mindsetی نیاز دارد که Valueهای Commitment، Focus، Openness، Respect و Courage به شکلگیری آن کمک میکنند. XP نیز Mindset خودش را دارد و Valueهای Simplicity، Communication، Feedback، Respect و Courage همین نقش را برای آن بازی میکنند. بنابراین طبیعی است که Lean نیز مجموعهای از Valueها داشته باشد که نقطهٔ شروع پذیرش Lean Thinking هستند.
Valueهای Lean
- Eliminate waste — حذف اتلاف: کاری را پیدا کنید که مستقیماً به تولید نرمافزار ارزشمند کمک نمیکند و آن را از پروژه حذف کنید.
- Amplify learning — تقویت یادگیری: از Feedback پروژه استفاده کنید تا روش ساخت نرمافزار را بهبود دهید.
- Decide as late as possible — تصمیمگیری تا حد ممکن دیر: تصمیم مهم را زمانی بگیرید که بیشترین اطلاعات ممکن را در اختیار دارید؛ یعنی در Last Responsible Moment.
- Deliver as fast as possible — تحویل تا حد ممکن سریع: Cost of Delay را بشناسید و با Pull Systemها و Queueها آن را کاهش دهید.
- Empower the team — توانمندسازی تیم: محیطی متمرکز و مؤثر ایجاد کنید و Whole Teamی از افراد پرانرژی بسازید.
- Build integrity in — Integrity را در محصول بسازید: نرمافزاری ایجاد کنید که برای کاربر بهصورت شهودی معنادار باشد و اجزای آن یک کل منسجم تشکیل دهند.
- See the whole — کل را ببینید: کل کاری را که در پروژه اتفاق میافتد درک کنید و Measurementهای مناسب انجام دهید تا واقعیت سیستم، با نقاط قوت و ضعفش، روشن دیده شود.
هر Value با Thinking Toolهایی همراه است که بهکارگیری آن را در موقعیت واقعی ممکن میکند. نقش این ابزارها تقریباً همان نقشی است که Principleها در XP دارند: آنها کمک میکنند تصمیمهای روزمره با Mindset روش هماهنگ شوند.
بسیاری از این Valueها را از قبل میشناسید
Tom و Mary Poppendieck در Lean Software Development: An Agile Toolkit توضیح میدهند که سازمان در نهایت چیزی را به دست میآورد که برایش ارزش قائل است؛ Agile Manifesto برداشت ما از «ارزش» را از Process به People، از Documentation به Code، از Contract به Collaboration و از Plan به Action منتقل میکند.
Lean بخش مهمی از دنیای Agile است و همپوشانی آن با Scrum و XP تصادفی نیست. Poppendieckها هنگام انتقال ایدههای Lean Manufacturing به توسعهٔ نرمافزار از تجربههای Agile، از جمله XP، استفاده کردند. از سوی دیگر بسیاری از ایدههایی که در Lean مطرح میشوند سالها پیش در Engineering و Quality Management وجود داشتهاند. Ken Schwaber نیز برای توسعهٔ Scrum از برخی از همین ایدههای Quality الهام گرفت؛ نمونهاش Daily Scrum بهعنوان یک Inspection رسمی است.
Decide as late as possible و Last Responsible Moment
Value «تصمیمگیری تا حد ممکن دیر» دقیقاً همان مفهوم Last Responsible Moment است که در Scrum و XP دیدهایم. Scrum آن را در Planning به کار میبرد؛ XP علاوه بر Planning در Design و Coding نیز از آن استفاده میکند. Lean همین مفهوم را بهعنوان یکی از Thinking Toolهای صریح خود در نظر میگیرد.
Amplify learning
دو Thinking Tool نخست این Value، Feedback و Iterations هستند؛ همان مفاهیمی که در Scrum و XP نیز پایهٔ یادگیری تدریجیاند. دو ابزار دیگر Synchronization و Set-Based Development هستند. Synchronization شباهت زیادی به Continuous Integration و Collective Ownership در XP دارد.
Empower the team
Thinking Toolهای این Value شامل Self-Determination، Motivation، Leadership و Expertise هستند. این مفاهیم به Practiceهای Whole Team و Energized Work در XP بسیار نزدیکاند. بهخصوص، Lean نیز مانند XP بر این واقعیت تکیه میکند که شبهای طولانی و کار فرسایشی کیفیت نرمافزار را پایین میآورند. Scrum نیز در Value «Focus» به همین نیاز میرسد: تیمی که اعضایش کنترل معقولی بر زندگی و کار خود دارند نرمافزار بهتری میسازد. Openness در Scrum نیز به See the Whole مرتبط است، زیرا اطلاعات پروژه باید برای افراد درگیر، از جمله مدیران، قابل مشاهده باشد.
Commitment، Options Thinking و Set-Based Development
در فصل ۴ گفته شد: Plan ما را متعهد نمیکند؛ Commitmentهای ما هستند که تعهد میسازند. Plan صرفاً جایی است که Commitment ثبت میشود. Commitment را انسانها ایجاد میکنند و Project Plan تنها آن را مستند میکند. وقتی کسی برای اثبات تعهد به یک Plan اشاره میکند، در واقع به خود کاغذ یا فایل اشاره ندارد؛ به قولی اشاره دارد که روی آن ثبت شده است.
بنابراین در Planning، ابتدا Commitment شکل میگیرد و سپس Plan آن را ثبت میکند.
Commitment فقط Value صریح Scrum نیست؛ در Mindsetهای XP و Lean نیز اهمیت دارد. اما Lean یک تمایز دقیقتر اضافه میکند:
- Options Thinking: تفاوت میان چیزی که به آن متعهد هستید و چیزی که حق انجامدادنش را دارید اما الزام به انجامش ندارید.
- Set-Based Development: پروژه را طوری پیش ببرید که چند مسیر یا راهحل بهصورت همزمان بررسی شوند و تیم بتواند بعداً با اطلاعات بیشتر میان آنها انتخاب کند.
تیم Scrum به Value متعهد میشود، نه به جزئیات دوردست
این واقعیت که Scrum از Planning بلندمدتِ بسیار جزئی پرهیز میکند به معنی فرار از Commitment نیست. وقتی از عضو Scrum Team دربارهٔ Feature چند ماه آینده سؤال میشود، پاسخ معقول این نیست که «این Scrum است و من فقط تا پایان Sprint فعلی تعهد دارم.» Product Backlog برای همین وجود دارد: تیم و Business دائماً دربارهٔ آنچه Value دارد گفتوگو میکنند. تیم متعهد است در پایان Sprint فعلی، Sprint بعدی و Sprintهای آینده نرمافزار ارزشمند تحویل دهد.
این وضعیت را با Command-and-Control Project Manager مقایسه کنید که Project Plan بسیار مفصلی میسازد و افراد را از ماهها قبل به Taskهای مشخص متعهد میکند. چنین Planی ممکن است توهم کنترل ایجاد کند؛ حتی ممکن است نشان دهد فلان Developer چهار هفته بعد، سهشنبه ساعت ۱۰:۳۰ دقیقاً روی چه Taskی کار خواهد کرد. اما تیم در آن لحظه اطلاعات لازم برای چنین Commitmentی را ندارد. تنها چیزی که با اطمینان بالا میتوان گفت این است که فعالیت پیشبینیشده برای ساعت ۱۰:۳۰ چهار هفتهٔ بعد احتمالاً همان چیزی نخواهد بود که واقعاً اتفاق میافتد.
به همین دلیل Scrum Team بهجای Commitment به جزئیات، Self-Organize میکند و Collective Commitment خود را روی تحویل Value میگذارد. تصمیم دربارهٔ Task خاص تا Responsible Moment بعدی به تعویق میافتد؛ شاید در Daily Scrum چهار هفتهٔ بعد.
Product Owner نیز تا پیش از شروع Sprint به Backlog Item مشخص Commitment نمیدهد، و حتی پس از آغاز Sprint میتواند Itemی را که دیگر منطقی نیست خارج کند. آیتمهای Sprint Backlog ممکن است از نظر روانی «تعهد» به نظر برسند، چون در Sprint Planning دربارهٔ آنها صحبت شده و روی Task Board آمدهاند، اما بسیاری از آنها در واقع Option هستند. Product Owner میتواند آنها را حذف کند و اگر تیم متوجه شود یک Item تا پایان Timebox «Done Done» نخواهد شد، آن را به Sprint بعد منتقل میکند.
قدرت Scrum تا حدی در همین جداسازی است: Commitment واقعی یعنی تحویل Working Software با Value در انتهای Sprint؛ تحویل یک Feature مشخص در تاریخ خاص میتواند تا مدت زیادی Option باقی بماند.
پاورقی منبع: کتاب گرافیکی Commitment نوشتهٔ Olav Maassen، Chris Matts و Chris Geary منبعی برای Options Thinking است که David Anderson آن را پیشنهاد کرده است. نویسندگان همچنین شباهت این مفهوم را با Optionهای مالی یادآوری میکنند: Option حق انجام معامله را میدهد، نه الزام آن را؛ بنابراین امکان باز نگهداشتن مسیرها فراهم میشود.
چرا سازمانها بیش از حد Commitment میخواهند؟
Options Thinking برای بسیاری از سازمانها دشوار است. اغلب در جلسهای دیدهایم که مدیر از عضو تیم یک تاریخ قطعی میخواهد و فرد با ناراحتی پاسخی مبهم میدهد. این رفتار معمولاً زمانی شدت میگیرد که مدیر احساس کرده قبلاً از Commitmentهای شکستخورده آسیب دیده است. واکنش غریزی او Micromanagement است: درخواست Commitmentهای فراوان از افراد برای Taskهای کوتاهمدت. نتیجه محیطی است که Developerها از متعهدشدن میترسند.
از سوی دیگر، خود تیمها نیز گرایش به Overcommitment دارند. گاهی دلیل آن Heroics است؛ Developer مشتاق بیش از توان واقعی وعده میدهد. گاهی فرهنگ سازمانی Commitment را پاداش میدهد: فرد امروز قول میدهد و بعداً بابت «شرایط غیرقابلپیشبینی» عذرخواهی میکند. در فرهنگ Blame و CYA، این رفتار ممکن است برای حفظ شغل یا افزایش حقوق مؤثرتر از تحویل واقعی نرمافزار باشد.
پس یک تضاد تکرارشونده شکل میگیرد: مدیران Commitment بیشتری مطالبه میکنند و تیمها بیش از ظرفیت واقعی Commitment میدهند.
Incremental Design و گزینههای باز
Task روی Scrum Task Board معمولاً از سه حالت میگذرد: To Do، In Progress و Done. وقتی Task در To Do است، هنوز Option است. حتی هنگام In Progress نیز تیم میتواند در Daily Scrum بر اساس اطلاعات جدید جهت را تغییر دهد. Scrum عمداً زمان زیادی صرف مدلسازی Dependencyهای دوردست نمیکند، چون این Dependencyها بیشتر برای Schedule Prediction مفیدند. Taskها تاریخ سررسید مستقل ندارند و مفهوم «Task دیرکرده که تمام پروژه را عقب میاندازد» به شکل Waterfall وجود ندارد.
فرض کنید در Sprint Planning یک User Story به چهار Task شکسته شده و بر اساس یک Assumption، Task طراحی Database برای DBA تعریف شده است. دو هفته بعد Developer کشف میکند دادهٔ موردنیاز از قبل در Database با Format دیگری وجود دارد و یک Object یا Service میتواند آن را برای بخشهای دیگر سیستم آماده کند. برای Scrum Team این خبر خوبی است: Taskهای غیرضروری از Board حذف میشوند و زمان آزادشده میتواند صرف Backlog Item دیگری یا Technical Debt شود.
در Waterfall، همین کشف ممکن است Project Manager را مجبور به Reallocation Resource کند، Dependencyهای متعدد را جابهجا کند و Commitmentهای ثبتشده را دوباره مذاکره کند. حتی ممکن است مدیر یا Architect اصرار کند «چون در Design اولیه Database نوشته شده، همان را انجام دهید.» این همان تجربهٔ آشنای بسیاری از Developerهاست: مجبورشدن به Technical Compromise غیرضروری فقط برای حفظ تصمیمی که خیلی زود به Commitment تبدیل شده است.
مشکل واقعی این نیست که نیاز جدید طراحی قدیمی را نقض کرده است؛ مشکل این است که Design پیش از داشتن اطلاعات کافی به Commitment تبدیل شده بود. Incremental Design در XP راهی برای باز نگهداشتن Optionهاست. وقتی Requirement جدید میآید، تیمی که Codebase را با Dependencyهای زیاد به یک Design زودهنگام قفل کرده مجبور به Shotgun Surgery و بازکردن ساختارهای درهمتنیده میشود. XP Team با Incremental Design، Refactoring و TDD فقط حداقل Code لازم را اضافه میکند و Dependencyها را تا جای ممکن کم نگه میدارد؛ در نتیجه Optionهای آینده نیز باز میمانند.
Set-Based Development
Set-Based Development روش صریحی برای ساختن Option است. تیم عمداً بیش از یک مسیر را برای مدتی دنبال میکند و هزینهٔ اضافی کوتاهمدت را میپذیرد، چون انتظار دارد اطلاعات بهدستآمده امکان تصمیم بهتر در آینده را فراهم کند.
فرض کنید تیم نمیداند راهحل Database بهتر است یا Object-Based Solution. در پروژههای Software معمولاً نمیتوان بهترین مسیر را فقط با بحث نظری تشخیص داد؛ گاهی باید هر دو را تا حدی ساخت. مسئلهای که «ساده» به نظر میرسد میتواند پس از شروع کار پیچیده از آب درآید. اگر تیم زود Commitment داده باشد، با کشف Complexity دو انتخاب بد دارد: شکستن Commitment یا تحویل Hack همراه با Technical Debt.
در Set-Based Development بهجای انتخاب فوری یک مسیر، Taskهایی برای بررسی هر دو Option ایجاد میشود. در نگاه نخست این کار Waste به نظر میرسد، اما اگر یکی از مسیرها به Solution تمیز و دیگری به Hack پرهزینه برسد، سرمایهگذاری روی هر دو مسیر تا زمانی که اطلاعات کافی جمع شود میتواند هزینهٔ زیادی را در آینده حذف کند. Responsible Moment تصمیمگیری بعد از کسب همین اطلاعات است.
A/B Testing بهعنوان نمونهٔ Set-Based Development
A/B Testing در UI و User Experience نمونهٔ رایج Set-Based Development است. تیم دو یا چند Solution، مثلاً دو Layout یا دو Decision Path، میسازد. سپس گزینههای A و B بهصورت تصادفی در اختیار Beta Testerها یا حتی Live Userها قرار میگیرند و Usage و Success Rate اندازهگیری میشود. شرکتهایی مانند Amazon و Microsoft از این روش استفاده کردهاند. ساخت دو Solution کامل هزینه دارد، اما Measurement نشان میدهد کدام گزینه مؤثرتر است. حتی گزینهٔ ضعیفتر نیز میتواند Feature یا Lesson مفیدی برای نسخهٔ نهایی داشته باشد.
بنابراین Options Thinking و Set-Based Development ادامهٔ منطقی همان چیزهایی هستند که در Scrum و XP دربارهٔ Feedback، Last Responsible Moment و Incremental Design آموختهایم.
نکات کلیدی این بخش
- Lean یا Lean Thinking نام یک Mindset است.
- Lean Methodology اجرایی با مجموعه Practiceهای ثابت نیست.
- Decide as late as possible همان خانوادهٔ فکری Last Responsible Moment است.
- Amplify learning بر Feedback و Iteration تکیه میکند.
- Empower the team به Focus در Scrum و Energized Work در XP نزدیک است.
- Options Thinking میان «حق انتخاب» و «Commitment» تفاوت میگذارد.
- Set-Based Development چند Option را همزمان بررسی میکند تا تصمیم نهایی با اطلاعات بیشتر گرفته شود.
روایت: تیم اپلیکیشن دوربین تلفن همراه
شخصیتها: Catherine، Developer؛ Timothy، Developer دیگر؛ Dan، مدیر آنها. شرکت کوچک قبلی این تیم توسط یک Internet Conglomerate بزرگ خریداری شده است.
پردهٔ اول: فقط یک چیز دیگر...
Catherine از شنیدن جملهٔ «همه کمی بیشتر تلاش کنید و انجامش دهید» خسته شده بود. دو Developer هنگام ساخت Feature جدید با مشکلی روبهرو شده بودند و کار بیش از برآورد قبلی زمان میبرد، اما Dan حاضر نبود زمان بیشتری بدهد. او مستقیماً تهدید نکرده بود، ولی برای همه روشن بود که Delay پذیرفتنی نیست.
Catherine سال قبل در شرکت کوچک قبلی بسیار خوشحالتر بود. یک Programming Team کوچک روی یک Product واحد، اپلیکیشن دوربین تلفن همراه، کار میکرد. اعضا خلاق بودند و همکاری خوبی داشتند. وقتی Internet Conglomerate بزرگی پیشنهاد خرید داد، تیم با هیجان از محیط کاری Relaxed، نوشیدنی رایگان، ساعت کاری Flexible و مزایای دیگر شنیده بود. بعد از معامله Bonus خوبی گرفتند و به دفتر جدید و زیبایی در مرکز شهر منتقل شدند.
اما حالا Catherine به Timothy گفت: «چطور به اینجا رسیدیم؟ قبلاً کار سرگرمکننده بود. چه اتفاقی افتاد؟» Timothy پاسخ داد که همهچیز انگار دو برابر زمان لازم طول میکشد. Catherine گفت از کار بیشتر نمیترسد، ولی هرقدر هم سختتر و طولانیتر کار کنند باز احساس میکنند عقب هستند.
Dan دوباره صدایشان زد. او از Senior Manager سایت Social Networking شرکت یک درخواست تازه گرفته بود و مثل همیشه آن را «خبر عالی» نامید. Featureهایی برای Integration دادههای شبکهٔ اجتماعی با Camera App باید فوراً وارد Sprint بعدی میشدند. Timothy یادآوری کرد که Sprint در نیمه است و پرسید چه چیزی را باید حذف کنند. Dan با تعجب پرسید آیا Resource کافی ندارند و وقتی Timothy گفت چهار Feature دیگر در جریان است و یکی از آنها هم عقب افتاده، Dan آن را «بهانه» دانست: خودش ساعت ۶ صبح در شرکت بوده و کسی را ندیده است؛ Request جدید هم از نظر او کوچک است و «خودم میتوانم یکروزه Code کنم».
Catherine این صحنه را قبلاً دیده بود. بار قبل تیم برای جا دادن Request ناگهانی Unit Testها را کنار گذاشته و Technical Debt ایجاد کرده بود؛ Userها هم متوجه شدند و Reviewهای چهار و پنج ستاره پس از Release به دو و سه ستاره افتاد. بااینحال Dan دوباره گفت کافی است همه «کمی بیشتر فشار بیاورند» تا این درخواست سریع آماده شود و تیم در شرکت Recognition بگیرد.
ساختن Hero و Magical Thinking
در میان بعضی مدیران این باور وجود دارد که Goalهای بسیار سخت و Timelineهای فشرده باعث Motivation میشوند. اگر برای هر فرد Goal تهاجمی تعیین شود، همه «به سطح چالش» خواهند رسید. این نگاهِ Rugged Individualism ظاهراً Bureaucracy را کم میکند: هر فرد مسئول حل Problemهای خودش است و در نهایت گروهی از Problem Solverهای بسیار مؤثر خواهیم داشت.
چنین مدیری Heroics را تشویق میکند. Developerی که شب میماند، Weekend کار میکند و Solution کامل را بهتنهایی برمیگرداند بیشترین Recognition را میگیرد. او نه به خاطر Teamwork، بهترکردن کل Product یا بهبود Process، بلکه به دلیل کاری که بهتنهایی و خارج از ساعت کاری انجام داده Hero میشود.
این رفتار Counterproductive است. تجربهٔ Scrum و XP بارها نشان داده نرمافزار بهتر زمانی ساخته میشود که Team واقعاً با هم کار کند: Self-Organization و Collective Commitment در Scrum، و Whole Team و Energized Work در XP نمونههای همین نگاهاند. شرایط کاری منطقی و امکان همکاری کیفیت محصول و سرعت پایدار را افزایش میدهد.
چرا پس مدیر همچنان گروهی از «افراد قهرمان» میسازد؟ از بیرون، Team ممکن است Black Box به نظر برسد: Manager میگوید چه چیزی ساخته شود، چند روز صبر میکند و Software ظاهر میشود. Developerی که مستقل و شبانهروزی کار میکند برای این Manager مثل هدیه است؛ Work بیشتری روی او میریزد و Work ظاهراً انجام میشود. پاداش به این فرد دیگران را هم به تقلید دعوت میکند.
در این نگاه هرچه Pressure بیشتر باشد Output هم بیشتر میشود. Late-Night Worker و کسی که در Chaos سریعتر دستوپا میزند Reward میشود. Team دائماً میشنود Work بیشتری وجود دارد و هر چیزی که اکنون در دست است باید «هرچه سریعتر» بیرون برود.
نویسندگان تأکید میکنند باید این Manager را صرفاً بدخواه تصور نکرد. او شاید اثر محیط Un-Energized را بر Design و Maintainability نرمافزار ندیده باشد. او گرفتار Magical Thinking است.
در Magical Thinking، تقریباً هر چیزی ممکن فرض میشود: هر Project هرقدر بزرگ قابل قبول است؛ هر Feature جدید «کوچک» است؛ هفتهٔ بعد همیشه میتوان Work بیشتری اضافه کرد؛ Task جدید somehow بدون اثر بر Taskهای قبلی انجام میشود؛ اگر لازم باشد Team یک Power Week با ۲۰ ساعت اضافه یا Weekend Work خواهد داشت. نتیجه باید «مثل جادو» ظاهر شود.
Hero Developer نیز بخشی از همین Symbiosis است. او برای Recognition، Leadership Position یا Salary بیشتر حاضر است Miracle ایجاد کند. ساعات کاری به معیار ارزش فرد تبدیل میشود و کسی به کیفیت Design، Stopgapهای بد یا Long-Term Cost نگاه دقیقی نمیکند.
Magical Thinking در کوتاهمدت حس خوبی میدهد: Manager احساس میکند Team را «Motivate» کرده و Hero احساس میکند Problem بزرگی را حل کرده است. اما در بلندمدت Technical Debt جمع میشود، Software هیچوقت Done Done نیست، Quality و Testing به Nice-to-Have تبدیل میشوند، Bugها به User میرسند و Team بهتدریج بیشتر وقت خود را صرف Fix و Maintenance کد ضعیف میکند تا Feature جدید.
Scrum و XP نشان دادند سریعترین روش پایدار برای تولید Software خوب، دادن زمان کافی از طریق Timeboxed Iteration، Focus روی Work محدود و محیط Collaboration است. Magical Thinking و Hero Culture با این شرایط ناسازگارند.
Lean یکی از اهداف اصلی خود را مقابله با این نگاه میداند. Team دیگر Black Box نیست. Lean Thinking کمک میکند Day-by-Day و Week-by-Week ببینیم Team دقیقاً برای ساخت Software چه میکند، قبل از شروع Work چه اتفاقی میافتد و پس از Delivery چه فرایندهایی وجود دارد. این دیدگاه دروغهای کوچک و فرضهای خوشایندی را که مدیران به تیم، مدیران به یکدیگر و افراد به خودشان میگویند آشکار میکند و Focus را از «سوزاندن Effort» به «ایجاد Value» برمیگرداند.
Eliminate Waste — حذف اتلاف
دیدن Waste همیشه آسان نیست. Teamها معمولاً یک «روش کار رایج در اینجا» دارند که افراد جدید نیز آن را یاد میگیرند، بدون اینکه کسی بپرسد چرا. اگر همیشه Project با Specification بزرگ شروع شده، کار بدون آن عجیب به نظر میرسد. اگر Framework سه سال قبل همیشه استفاده شده، Project بعدی نیز احتمالاً همان را استفاده خواهد کرد.
اما همانطور که Refactoring مداوم Code در XP Design را انعطافپذیرتر میکند، «Refactor کردن روش کار Team» نیز Process را انعطافپذیرتر میکند. نخستین قدم در Code Refactoring یافتن Antipattern است؛ در Lean Thinking، Antipatternهای Process را Waste مینامیم: هر کاری که فعالانه به ساخت Software بهتر و Value بیشتر کمک نمیکند.
به Projectهای اخیر فکر کنید: Specificationی نوشتید که هیچکس نخواند؟ Documentی تحویل گرفتید که هیچوقت استفاده نشد؟ Unit Test یا Code Review برنامهریزی شد ولی انجام نشد؟ Review درست قبل از Release انجام شد و اعضا از ترس Delay، Problem واقعی را مطرح نکردند؟ Project Manager ساعتها Gantt Chart را بعد از وقوع رویدادها Update کرد فقط تا Status Meeting ظاهری مرتب داشته باشد؟ همهٔ اینها میتوانند Waste باشند.
مثالهای دیگر:
- Binder بزرگی از Specificationها که روی قفسه خاک میخورد.
- Code Reviewهایی که فقط Style یا Preference شخصی را بررسی میکنند و Design یا Bug واقعی را بهتر نمیکنند.
- Statement of Work طولانی که Team یک روز مرورش میکند و با آغاز Work کنار گذاشته میشود.
- ساعتها Debug کردن Deployment Problemی که Script میتوانست Automate کند.
- Status Meetingی که افراد به نوبت وضعیتشان را میخوانند تا Coordinator Minutesی بنویسد که هیچکس بعداً نمیخواند.
جایگزینکردن Status Meeting بیارزش با Daily Scrum نمونهای از حذف Waste است.
Waste لزوماً «بیفایده برای همه» نیست
اگر فعالیتی از منظر Software Development Waste باشد، الزاماً به این معنا نیست که برای کل Company هیچ Value ندارد. Senior Manager شاید برای تأمین Funding به Project Plan نیاز داشته باشد؛ Meeting Minute ممکن است Regulatory Requirement باشد؛ Statement of Work شاید Contractual Requirement باشد. این فعالیتها لازماند، اما مستقیماً Product را نمیسازند و از دید Flow پروژه Waste محسوب میشوند. این تمایز کمک میکند بدون قضاوت اخلاقی، Cost واقعی Process را ببینیم.
هفت Waste توسعهٔ نرمافزار
Poppendieckها مفهوم Seven Wastes of Software Development را از ایدههای Toyota اقتباس کردند:
- Partially Done Work — کار نیمهتمام: تا وقتی Feature صددرصد کامل و Working نباشد، User Value تحویل نشده است. Work نیمهتمام Value بالقوه است، نه Value تحویلشده.
- Extra Processes — Process اضافی: Tracking، Reporting یا Estimationی که صرفاً برای Update Status Sheet انجام میشود و تصمیم مفیدی ایجاد نمیکند، Waste است.
- Extra Features — Feature اضافی: ساخت چیزی که User درخواست نکرده، مثلاً فقط برای تجربهٔ Technology جدید، ممکن است برای فرد آموزشی باشد اما Value مستقیم Product ایجاد نمیکند.
- Task Switching — جابهجایی میان Taskها: Multitasking بیشازحد Cognitive Overhead دارد. حرکت مداوم میان Projectها یا کارهای نامرتبط زمان و Focus را میسوزاند.
- Waiting — انتظار: انتظار برای Specification Review، Access Approval، Fix کامپیوتر، Software License و انواع Queueها همگی زمان بدون Value هستند.
- Motion — حرکت: وقتی Team کنار هم نیست، حتی زمان فیزیکی رفتوآمد برای گفتوگو در مجموع میتواند روزها یا هفتهها به Project اضافه کند.
- Defects — نقصها: Bugهایی که میتوانستند با TDD یا Practiceهای Quality زودتر جلوگیری شوند، بعداً چند برابر هزینه ایجاد میکنند؛ خصوصاً اگر پس از Release توسط User پیدا شوند.
حتی موارد Waste معمولاً برای شخصی Utility دارند. Layout نامناسب صندلیها شاید مشکل دیگری از Office Manager را حل کرده باشد. هدف «دیدن Waste» فهم Motivationهای پشت فعالیت و مقایسهٔ Objective آنها با Costی است که به Delivery تحمیل میشود.
Framework Trap فصل ۷ مثال خوبی است: Framework بزرگی که مسئله را با Code بسیار بیشتر حل میکند در ابتدا با هدف حذف Duplicate Work ساخته شده، اما خود میتواند Waste شود؛ در آینده هر Feature جدید یا باید Framework را Extend کند یا آن را دور بزند. Teamی که Waste را میبیند تشخیص میدهد این Framework مانع افزودن Value شده است.
Value Stream Map برای دیدن Waste
در Lean Software Development، Mary و Tom Poppendieck تمرینی ساده با کاغذ و مداد پیشنهاد میکنند: Value Stream Map. این Technique از Manufacturing آمده، اما برای Software نیز مناسب است.
ساخت Map برای یک Project نباید بیش از حدود نیم ساعت زمان ببرد:
- یک واحد کوچک Value انتخاب کنید که Team قبلاً ساخته و به Customer یا User تحویل داده است.
- کوچکترین واحد ممکن را انتخاب کنید؛ این همان Minimal Marketable Feature (MMF) است، یعنی کوچکترین «تکه» Product که Customer حاضر است آن را Prioritize کند. در Scrum، Backlog Itemها اغلب MMF هستند و میتوانند User Story، Requirement یا Feature Request باشند.
- تمام Stepهایی را که این MMF از Idea تا Delivery طی کرده به یاد بیاورید.
- برای هر Step یک Box بکشید و آنها را با Arrow به هم وصل کنید. چون History واقعی یک Feature را رسم میکنید، Path خطی است؛ Decision Point فرضی اضافه نمیشود.
- برای هر Step مقدار Work Time را تخمین بزنید و سپس Wait Time تا شروع Step بعدی را ثبت کنید.
- خطوط یا Annotationهایی زیر Boxها بکشید تا Work و Wait آشکار شوند.
شکل 8-2 نمونهای از Value Stream Map برای Featureای است که از Traditional Waterfall Project Management عبور کرده است. هدف شکل این است که Team بتواند ببیند زمان واقعاً کجا صرف Work و کجا صرف Waiting شده است.
[پایان بخش تخصیصیافته از فصل ۸ — ادامه در مقالهٔ بعدی]
تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و بهصورت دادهٔ داخلی Base64 جاسازی شدهاند.
تصویر منبع - صفحهٔ PDF 292
تصویر منبع - صفحهٔ PDF 307