Agile

  • یوسف مهرداد بی‌بالان

I Don’t Care About “Agile”

All ideas are great, until they are confronted with reality.

The concept of Management By Objectives by Peter F. Drucker was great, except for the fact that it didn’t take into account that managers could easily abuse it to enrich themselves with big bonuses.

The idea of Shareholder Value, supported by Nobel-prize winner Milton Friedman, was great in theory and perfect for rational minds, as long as we ignored the fact that economic decisions are almost never rational.

The Balanced Scorecard by Kaplan and Norton is a very good tool for managers. But most managers think they’re driving their organization like a machine, instead of riding it as if it’s a horse, and digital dashboards don’t sit well on horses.

The list of failed management ideas goes on an on…

Now we are in the age of Agile Management, Lean Development, and Complexity Thinking, with Scrum, Kanban, and Cynefin trying to ride the waves. And the first signals of disillusion have already been heard. I hear, “It’s not working here”, “People don’t want to change” and “These are fads like all the others”.

And yes… they may be right.

If you don’t change the culture of your organization to one of learning instead of controlling, if you don’t see your business as a community instead of a computer, and if you don’t focus on improving through people rather than processes, you will get exactly that. The ideas won’t work, people won’t change, and it’s all just a fad.

No great idea survives contact with the ignorant.

Of course, words like Agile and Lean were conceived to try and change the mindsets of managers and the cultures of businesses. But if these words don’t succeed, we shouldn’t mourn their defeat. The Agile and Lean brands may be destined to end up on the same pile of discarded words as all the others. Not because the ideas weren’t any good. But because they couldn’t cope with the real world.

I don’t care.

My goal is not to define, use, and protect the word Agile.

My goal is to be happy while learning new things and creating value in a network with other people. I will use any cool words that can help me with this. And right now, I’m an optimist. For me, Agile is still an awesome brand.

Until it isn’t.

Reference: www.noop.nl

منبع: از میان نامه‌های محسن

Quote:
Having a style is like being in jail.
Anthon Beeke

در آغوش گرفتن تغییرات با XP – بخش چهارم

  • یوسف مهرداد بی‌بالان

مترجم: آقای مهندس مهدی نگاهی

وظیفه (Task)
برای پیاده‌سازی هر وظیفه، برنامه‌نویسِ مسئول ابتدا باید یک همکار پیدا کند، زیرا همه کدهای برنامه به صورت دو نفره پشت یک کامپیوتر نوشته می‌شود. اگر پرسشی در مورد محدوده یا روش پیاده‌سازی به وجود آید، دو همکار(برنامه‌نویس و همکار وی) جلسه کوتاهی (15 دقیقه‌ای) با مشتری، برنامه‌نویسان مرتبط یا هر دو برگزار می‌کند. برنامه‌نویسان مرتبط کسانی هستند که دانش بیشتری در مورد کدی دارند که در طول پیاده‌سازی وظیفه تغییر خواهد کرد.

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

وقتی مورد آزمونی وجود دارد که اجرا نمی‌شود:
+ یا یک راه تمیز برای اجرای مورد آزمون پیدا شده، که در این صورت همان راه پیش برده می‌شود؛

+ یا یک راه ناپسند برای اجرای مورد آزمون پیدا شده، اما راه تمیزی هم وجود دارد که نیاز به تغییر طراحی فعلی دارد. در این حالت، سیستم بازسازی (Refactor) می‌شود تا راه تمیز قابل اجرا شود؛

+ یا یک راه ناپسند برای اجرای مورد آزمون پیدا شده و راه تمیزی حتی با بازسازی سیستم نیز متصور نیست. در این حالت، همان راه ناپسند پیش برده می‌شود تا مورد آزمون اجرا شود.

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

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

گزیده:
مابک(کریستوفر پلامر): خدای من اینها دیگه کی‌یند؟
لوول(ال پاچینو): آدمهای عادی در یک شرایط غیرعادی. چه انتظاری داری مرد !
گفت‌وگویی از فیلم تماشایی Insider

سمینار برنامه‌ریزی چابک یا Agile Planning

  • یوسف مهرداد بی‌بالان

اگر عمری باقی بود در هفته پایانی آذرماه، سمینار برنامه‌ریزی چابک یا Agile Planning را برگزار خواهم کرد.

بعد از برگزاری سمینار نیازمندی‌های چابک یا Agile Requirements علاقه‌مند بودم که سمینار برنامه‌ریزی را زودتر برگزار کنم. حالا خوشحال هستم که هر چند با تأخیر، این سمینار برگزار خواهد شد.

گزیده:
هر هدفی بدون برنامه، فقط یک آرزوست.
آنتونیو دو سنت هگزوپری

در آغوش گرفتن تغییرات با XP – بخش سوم

  • یوسف مهرداد بی‌بالان

بخش دوم ترجمه مقاله Embracing Change with Extreme Programming نوشته Kent Beck را می‌توانید در اینجا مطالعه نمایید.
مترجم: آقای مهندس مهدی نگاهی

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

انتخاب داستانهای هر انتشار تا حدودی شبیه خرید مواد غذایی از فروشگاه است. وقتی با 100 دلار به فروشگاه می‌رویم، به خریدهای ضروری(با الویت) فکر می‌کنیم، به قیمت اجناس نگاه می‌کنیم و بعد تصمیم می‌گیریم که چه چیزهایی خریداری کنیم. [در اینجا بودجه موجود برای خرید -100 دلار- قابل افزایش نیست. رویکرد دیگر این است که ابتدا اجناس ضروری انتخاب می‌شوند و بعد بودجه لازم برای خرید آنها با جمع قیمتها، براورد می‌شود-مثلاً 150 دلار-].

در بازی برنامه‌ریزی(فرایند برنامه‌ریزی XP)، داستانها معادل اجناس و برآورد هر داستان معادل قیمت است[به عنوان مثال اگر براورد پیاده‌سازی داستانی، 3 نفر-روز باشد، یعنی قیمت آن 3 واحد است]. بودجه با اندازه‌گیری خروجی تیم محاسبه می‌شود که مبنای آن جمع برآورد داستانهای انجام شده در واحد زمان است.

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

تکرار(Iteration)
هدف هر تکرار، افزودن داستانهای جدیدِ آزمایش شده و آماده‌ی استفاده به محصول است. فرایند با طرحی شروع می‌شود که در آن داستانهای انتخاب شده برای پیاده‌سازی و چگونگی انجام آنها توسط تیم مشخص شده است. هنگامی که تیم در حال پیاده‌سازی است، مشتری آزمونهای کارکردی (functional tests) را مشخص می‌کند. آزمون‌ها در پایان تکرار اجرا شده و تیم برای تکرار بعدی آماده می‌شود.

برنامه‌ریزی تکرار با درخواست دوباره از مشتری برای انتخاب باارزش‌ترین داستان‌ها آغاز می‌شود با این تفاوت که این‌بار، داستانها از بین داستانهای باقی‌مانده از انتشار انتخاب می‌شوند. داستان‌ها توسط تیم به مجموعه‌ای از وظایف (tasks) شکسته می‌شوند –وظیفه کاری است که یک نفر می‌تواند طی چند روز انجام دهد. در صورت وجود وظایف فنی– مانند ارتقاء (upgrade) پایگاه داده به نسخه جدید-، آنها نیز به لیست وظایف افزوده می‌شوند.

پس از آن، برنامه‌نویسان برای پذیرش انجام وظایف، اعلام آمادگی می‌کنند. وقتی گفت‌وگو درباره وظایف به پایان می‌رسد، برنامه‌نویس مسئول، زمان انجام وظیفه‌‌اش را بر مبنای روز ایده‌آل (ideal day) برآورد و اعلام می‌کند[روز ایده‌آل یکی از واحدهای براورد اندازه(سایز) داستان است. روز ایده‌ال مدت زمان انجام یک کار است به شرطی که مجری فقط همان یک کار را انجام دهد، وقفه‌ای در انجام کار به وجود نیاید و منابع لازم برای کار نیز فوراً آماده گردد].

در پایان ممکن است برنامه‌نویسی وظایف بیشتر یا کمتر از ظرفیت خود داشته باشد. در این صورت کسی که وظایف کمتری دارد، وظایف بیشتری برمی‌دارد تا تعادل برقرار گردد.

برنامه نویسان وظایف خود را طی تکرار انجام می‌دهند. با پایان یافتن هر وظیفه، برنامه‌نویس کد نوشته شده را با کد سیستم یکپارچه کرده و آزمون‌ها را اجرا می‌کند. همه آزمونها باید اجرا و پشت سر گذاشته شوند، در غیر این صورت کدها اجازه یکپارچه‌شدن با سیستم را نخواهند داشت.

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

گزیده:
زیستن، تنها با آنچه انسان می‌داند و آنچه به یاد می‌آورد و محروم از آنچه آرزو دارد، چه دشوار است. آلبر کامو

در آغوش گرفتن تغییرات با XP – بخش سوم

  • یوسف مهرداد بی‌بالان

بخش دوم ترجمه مقاله Embracing Change with Extreme Programming نوشته Kent Beck را می‌توانید در اینجا مطالعه نمایید.
مترجم: آقای مهندس مهدی نگاهی

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

انتخاب داستانهای هر انتشار تا حدودی شبیه خرید مواد غذایی از فروشگاه است. وقتی با 100 دلار به فروشگاه می‌رویم، به خریدهای ضروری(با الویت) فکر می‌کنیم، به قیمت اجناس نگاه می‌کنیم و بعد تصمیم می‌گیریم که چه چیزهایی خریداری کنیم. [در اینجا بودجه موجود برای خرید -100 دلار- قابل افزایش نیست. رویکرد دیگر این است که ابتدا اجناس ضروری انتخاب می‌شوند و بعد بودجه لازم برای خرید آنها با جمع قیمتها، براورد می‌شود-مثلاً 150 دلار-].

در بازی برنامه‌ریزی(فرایند برنامه‌ریزی XP)، داستانها معادل اجناس و برآورد هر داستان معادل قیمت است[به عنوان مثال اگر براورد پیاده‌سازی داستانی، 3 نفر-روز باشد، یعنی قیمت آن 3 واحد است]. بودجه با اندازه‌گیری خروجی تیم محاسبه می‌شود که مبنای آن جمع برآورد داستانهای انجام شده در واحد زمان است.

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

تکرار(Iteration)
هدف هر تکرار، افزودن داستانهای جدیدِ آزمایش شده و آماده‌ی استفاده به محصول است. فرایند با طرحی شروع می‌شود که در آن داستانهای انتخاب شده برای پیاده‌سازی و چگونگی انجام آنها توسط تیم مشخص شده است. هنگامی که تیم در حال پیاده‌سازی است، مشتری آزمونهای کارکردی (functional tests) را مشخص می‌کند. آزمون‌ها در پایان تکرار اجرا شده و تیم برای تکرار بعدی آماده می‌شود.

برنامه‌ریزی تکرار با درخواست دوباره از مشتری برای انتخاب باارزش‌ترین داستان‌ها آغاز می‌شود با این تفاوت که این‌بار، داستانها از بین داستانهای باقی‌مانده از انتشار انتخاب می‌شوند. داستان‌ها توسط تیم به مجموعه‌ای از وظایف (tasks) شکسته می‌شوند –وظیفه کاری است که یک نفر می‌تواند طی چند روز انجام دهد. در صورت وجود وظایف فنی– مانند ارتقاء (upgrade) پایگاه داده به نسخه جدید-، آنها نیز به لیست وظایف افزوده می‌شوند.

پس از آن، برنامه‌نویسان برای پذیرش انجام وظایف، اعلام آمادگی می‌کنند. وقتی گفت‌وگو درباره وظایف به پایان می‌رسد، برنامه‌نویس مسئول، زمان انجام وظیفه‌‌اش را بر مبنای روز ایده‌آل (ideal day) برآورد و اعلام می‌کند[روز ایده‌آل یکی از واحدهای براورد اندازه(سایز) داستان است. روز ایده‌ال مدت زمان انجام یک کار است به شرطی که مجری فقط همان یک کار را انجام دهد، وقفه‌ای در انجام کار به وجود نیاید و منابع لازم برای کار نیز فوراً آماده گردد].

در پایان ممکن است برنامه‌نویسی وظایف بیشتر یا کمتر از ظرفیت خود داشته باشد. در این صورت کسی که وظایف کمتری دارد، وظایف بیشتری برمی‌دارد تا تعادل برقرار گردد.

برنامه نویسان وظایف خود را طی تکرار انجام می‌دهند. با پایان یافتن هر وظیفه، برنامه‌نویس کد نوشته شده را با کد سیستم یکپارچه کرده و آزمون‌ها را اجرا می‌کند. همه آزمونها باید اجرا و پشت سر گذاشته شوند، در غیر این صورت کدها اجازه یکپارچه‌شدن با سیستم را نخواهند داشت.

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

گزیده:
زیستن، تنها با آنچه انسان می‌داند و آنچه به یاد می‌آورد و محروم از آنچه آرزو دارد، چه دشوار است. آلبر کامو

فراموشی

  • یوسف مهرداد بی‌بالان

رویداد اول: دوره‌ای با شرکت کارشناسان زبده و باتجربه‌ی تعریف محصولات نرم‌افزاری
در نقش مدیر کتابخانه یکی از دانشکده‌های دانشگاه از آنها خواستم تا ویژگی‌های(Feature) سیستم کتابخانه را به همراه مدت و هزینه انجام پروژه اعلام کنند. در قالب گروه‌هایی شروع به کار می‌کنند. در پایان از دو گروه خواهش می‌کنم که پاسخ‌هایشان را روی تابلو بنویسند.
ثبت امانت، برگشت کتاب، تعریف عضو، ….
پس از آن از همه می‌خواهم که توجه کنند و این پرسش را مطرح می‌کنم: “شما به دنبال حل چه مسأله‌ای و مشکلی از مشتری بوده‌اید؟”.
به ناگاه همه ساکت می‌شوند، چند لحظه‌ای به سکوت می‌گذرد و بعد همه با هم شروع به خندیدن می‌کنند. دلیل خندیدن آنها این است که پی‌می‌برند اشتباهی را مرتکب شده‌اند که از افراد تازه‌کار انتظار می‌رود. آنها راه حل را بدون توجه به نیاز مشتری ارائه کرده‌اند.

رویداد دوم: دوره‌ای مرتبط با متدهای چابک (agile methods)
به عنوان مشتری از شرکت‌کنندگان خواسته‌ام تا بک‌لاگ محصول را در قالب تیم‌هایی کامل کنند. در پایان از آنها می‌پرسم: «کدامیک از ارزشها و اصول چابکی را به کار بردید؟». به موارد مهمی اشاره می‌کنند از جمله مشارکت: همه تیم در کار مشارکت داشتند. بعد از آنها می‌پرسم: می‌توانم بپرسم که در زمان «مشارکت»، مشتری کجا بود – اشاره به مشارکت مشتری در تیمهای چابک-؟». دقایقی به بحث و گفت‌وگو می‌گذرد. یکی از شرکت‌کنندگان به شوخی می‌گوید: مشتری در حال قدم زدن در کلاس بود-اشاره به من که موقع انجام تمرین در کلاس قدم می‌زدم. یکی دیگر می‌گوید: نمی‌خواستیم مزاحم وقت مشتری شویم.
همه می‌خندیم. همه پی‌می‌بریم که یک نکته اساسی را که می‌دانستیم، فراموش کرده‌ایم.

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

خوشحال خواهم شد که خواننده نظرات و راهنمایی‌های شما باشم.

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

آموخته‌های گریدی بوچ از سیستمهای نرم‌افزاری پیچیده

  • یوسف مهرداد بی‌بالان

1-اصول و مبانی هیچ گاه کهنه نمی‌شوند.
پروژه‌های بزرگ و طولانی می‌توانند ترسناک و حتی در شرایط بد شبیه به نزدیک شدن لحظه مرگ باشند- با برداشتن هر قدم، یک قدم به مرگ نزدیکتر می‌شوند. به گفته بوچ، پروژه‌های با بهره‌وری بالا هیچگاه چهار موضوع اصلی زیر را فراموش نمی‌کنند:
1- ایجاد انتزاعهای (abstraction) دقیق و انعطاف‌پذیر
2- جداسازی موضوعات مهم (separation of concerns)
3- تخصیص توزیع‌شده و متعادل مسئولیت بین اجزاء
4- تأکید بر سادگی

بوچ رمز ایجاد انتزاعهای مناسب را به کارگیری دیدگاه شیءگرا به جای دیدگاه مبتنی بر الگوریتم می‌داند. …
به گفته وی جداسازی موضوعات مهم به زبان ساده یعنی «هیچ کس ماشین ظرفشویی را در حمام نمی‌گذارد». مشخصات اجزای سیستم بستگی به نیازمندی‌ها دارد، اما «بهتر است اجزای مرتبط به شکل منطقی در کنار هم قرار گیرند و اجزا غیرمرتبط از هم جدا شوند»
توجه داشته باشید که مبانی طراحی، دوری از معماری بی‌قواره را نیز شامل می‌شود. هیچ کس خانه‌ای با چندین آشپزخانه و فقط یک اتاق خواب طراحی نمی‌کند.
اهمیت ساده نگهداشتن اجزای سیستم و رسیدن به سادگی را دست کم نگیرید. وی هشدار می‌دهد که «ایجاد و حفظ اجزای ساده نیاز به انرژی دارد»

2-نیاز به ریتم (دوره منظم) انتشار دارید
هر پروژه نیاز به ضرب‌آهنگی شبیه به ضربان قلب دارد. وی می‌گوید:«ایجاد ریتم موجب افزایش ثبات و قابل پیش‌بینی بودن پروژه می‌شود». …

3-تمرکز بر معماری قابل اجرایی که به مرور کامل می‌شود
… «واقعیت، کد برنامه است» اما «کد برنامه همه واقعیت نیست» [خیلی‌ها عقیده دارند که کدبرنامه تنها واقعیت پروژه است و می‌تواند جایگزین خیلی چیزها از جمله معماری، مستندات و … شود]

4- ایجاد ساختارهای اجتماعی که با حفظ قابلیت پیش‌بینی، موجب افزایش نوآوری شوند
کارتیمی عنصر اصلی هر پروژه بزرگ نرم‌افزاری است…. کسب‌وکار نیاز به پیش‌بینی دارد (نرم‌افزار کی آماده تحویل می‌شود؟) و در کنار آن نیاز به نوآوری. ایجاد ساختارهای اجتماعی که هر دو هدف را محقق کند، کار ساده‌ای نیست، اما پروژه‌های مؤفق توانسته‌اند نقطه تعادل بین آن دو – پیش‌بینی و نوآوری- را پیدا کنند.
یکی از نقاط مورد بحث و مجادله در ساختارهای اجتماعی میزان مشارکت مدیران در فرایند ایجاد و توسعه نرم‌افزار است. گریدی بوچ اعتقاد دارد که با وجودی‌ که خطی بین مدیران و توسعه‌دهندگان وجود دارد، اما به عنوان مثال معمار بهتر است عضوی از تیم پیاده‌سازی تیم هم باشد. هر چند با مشارکت زیاد مدیران، امکان ایجاد اشکالاتی در روابط تیم وجود دارد، اما به یاد داشته باشید که بین «خط» و «دیوار» تفاوت وجود دارد-خط یا دیوار بین مدیران و اعضای تیم-….

5- لذت ببرید
این توصیه، یک توصیه دوستانه ساده نیست. بوچ اعتقاد دارد که پروژه‌های مؤفق، نتیجه کارِ تیمی است که از کارش لذت می‌برد. «اکثر انسانها می‌خواهند کارهای زیبا و برازنده انجام دهند. اگر به این خواسته درونی آنها بی‌توجه باشید، در حقیقت شوق رشد و پیشرفت را از آنها گرفته‌اید»
مرجع:www.cio.com

گزیده
:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
John Gall

برای خروج از جستجو کلید ESC را بفشارید