برآورد نرم‌افزار

متشکرم که مرا دعوت کردید.

نه فکر می‌کنم، تقریباً به طور کامل توضیح دادید.

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

در عمل آن‌چه فهمیدیم این است که افراد در هر دو سوی تصمیمات فنی و کسب‌وکار، قطعاً گرایش دارند که از کلمه‌ی برآورد به معنی پیش‌گویی آماری استفاده کنند؛ اما از آن به معنی تعهد هم استفاده می‌کنند. یعنی افراد کسب‌وکار می‌پرسند به برآورد شما این کار چقدر طول می‌کشد؟ افراد فنی هم می‌گویند فکر می‌کنیم تا فلان تاریخ طول بکشد. در این لحظه تاریخ مورد نظر تبدیل به تعهدی به کسب‌وکار می‌شود؛ این کمی فراتر از برآورد می‌رود. فکر می‌کنم استفاده از این کلمه علاوه بر اشاره برآورد و تعهد، برای اشاره به اهداف هم استفاده می‌شود. مثلاً طرف کسب‌وکار ممکن است بگوید ما واقعاً دوست داریم که این کار تا فلان تاریخ تمام شود و در حین گفتگو ما به نحوی کلمات برآورد و تعهد را تلفیق می‌کنیم. این منجر به انواع مشکلات می‌شود که می‌توانیم در صورت نیاز در مورد آن‌ها صحبت کنیم؛ اما فکر می‌کنم برای کوتاه کردن سخن اگر بتوانیم در گفتگوهایمان و یا حداقل در ذهن‌مان میان برآورد‌ها، تعهدات و اهداف تمایز قائل شویم -حداقل در جنبه‌ی فنی معادله- خودمان را برای داشتن گفتگوهای بسیار سازنده‌تری درباره‌ی برآورد آماده کرده‌ایم. ما ارزش بسیاری در صِرفِ روشن کردن این مفهوم دیده‌ایم. چون روشن کردن مفهوم، منجر به روشن شدن فعالیت هم می‌شود. بنابراین می‌دانیم کِی برآورد می‌کنیم، کِی درباره‌ی یک هدف صحبت می‌کنیم، و کِی تعهد می‌دهیم. روشن کردن این کلمات در حقیقت به ما کمک می‌کند تا از دادن تعهد درحالی که فکر می‌کنیم صرفاً برآورد می‌کنیم، دوری کنیم.

فکر می‌کنم درست باشد. فکر می‌کنم روش سازنده‌ای برای فکر کردن به آن است. یعنی [تشریح] کامل آن این است که کسب‌وکار چیزی در ذهن دارد که فکر می‌کند به درد کسب‌وکار می‌خورد. این هدف است. معمولاً کسب‌وکار می‌پرسد چه برآوردی از این کار دارید؟ فکر می‌کنید چه تعداد ویژگی می‌توانید تا فلان تاریخ تحویل دهید؟ بنابراین آن‌چه که کسب‌وکار طبیعتاً فکر می‌کند این است که آن‌چه که امیدوار بودیم به آن دست پیدا کنیم، صد درصدِ آن‌چیزی است که در ذهنمان بود. عموماً این‌طور است که افراد خوش‌بین هستند. افراد فنی می‌روند و کار واقعیِ برآورد کردن را انجام می‌دهند که من در واقع به آن برآورد می‌گویم. و عموماً برمی‌گردند و همان‌طور که از نام خوش‌بینی پیداست متوجه می‌شوند در واقع هدف کسب‌وکار [در زمان] مورد نظر قابل دست‌یابی نیست؛ [هدف] خیلی خوش‌بینانه بود. توانایی حقیقی سازمان برای تحویل آن کافی نیست. اتفاقی که در اینجا رخ می‌دهد این است که ما از برآورد استفاده می‌کنیم تا بفهمیم توانایی ما در رسیدن به یک هدف و این‌که به آن متعهد شویم مقعول است یا خیر. برآورد در واقع به ما کمک می‌کند تعیین کنیم که این تعهدی است که «احتمالاً» به آن دست می‌یابیم یا این تعهدی است که «احتمالاً» نمی‌توانیم زیر بار آن برویم. اما مفهومی از بی‌ثباتی و احتمال در هر برآورد واقع‌بینانه وجود دارد. بنابراین در هر برآورد واقع‌بینانه درجه‌ای از انعطاف‌پذیری وجود دارد. وقتی می‌گوییم برآورد، حاکی از احتمال برآورده شدن تعهد است، برآورد آن را تضمین نمی‌کند. در عوض می‌گوید که فرصت خیلی خوبی برای برآوردن تعهد داریم یا این‌که امکان تلاش کردن برای آن را داریم یا این‌که هیچ شانسی برای عمل به تعهد نداریم و در نتیجه احتمالاً از همان ابتدا نباید زیر بار آن برویم.

بله حتماً. این بخش از کتاب در واقع از ستونی که کمی قبل‌تر در IEEE منتشر کرده بودم گرفته شده است. فرض کنید می‌خواهیم به تعطیلات برویم و می‌خواهیم تصمیم بگیریم که چمدان با چه اندازه‌ای برای لباس‌هایمان لازم داریم. واقعاً نمی‌خواهیم اندازه‌ی دقیقِ چمدانی را بدانیم که دقیقاً به اندازه‌ی لباس‌های ماست. ما می‌خواهیم چمدانی داشته باشیم که به اندازه‌ی همه‌ی لباس‌ها جا داشته باشد، اما نه آن‌قدر بزرگ که کلی جای خالی در آن باشد و در فرودگاه ما را دچار دردسر کند. مسئله‌ای که در آن فصل از کتاب مطرح می‌کنم این است که زمانی که می‌خواهید به سفر بروید، کاری که می‌کنید این است که چمدان‌تان را برمی‌دارید. ممکن است تعدادی لباس دیگر هم داشته باشید که باید در آن جا شوند و شاید لازم باشد چمدان را به زور ببندید. اما اگر اندازه‌ی آن به اندازه‌ی کافی بزرگ باشد می‌توانید به زور هم که شده آن را ببندید. [بنابراین] احتمالاً خوب است و چمدان به اندازه‌ی کافی بزرگ است. فکر می‌کنم این قیاس مناسبی با کاری است که ما می‌خواهیم در برآورد نرم‌افزار انجام دهیم. ما تلاش نمی‌کنیم با برآورد‌هایمان بگوییم که به طور دقیق به آن‌ها دست خواهیم یافت. چیزهای زیادی در پروژه‌های نرم‌افزاری تغییر می‌کند. این تصور که ما دقیقاً به هر آن‌چه برآورد می‌کنیم دست خواهیم یافت وابسته به این است که ما دقیقاً همان‌چیزی را که در ابتدا شروع کردیم، تحویل بدهیم؛ این به ندرت رخ می‌دهد. چیزهای زیادی در طول مسیر تغییر می‌کند. اما [کافی است] آن‌چه که در ابتدا برآورد می‌کنیم به اندازه‌ی کافی نزدیک به واقعیت باشد، به نحوی که بتوانیم به چیزی مشابه به آن دست یابیم حتی اگر نیاز به کار بیشتری داشته باشد،‌ شاید یکی دو آخر هفته یا آخر وقت (که معادل به زور چپاندن لباس‌ها در چمدان هستند). اگر این محقق شود ما کم و بیش آن‌چه که گفته بودیم تحویل می‌دهیم را، کم و بیش در بازه‌ی زمانی که گفته بودیم، تحویل داد‌ه‌ایم. من فکر می‌کنم اکثریت کسب‌وکارها درک می‌کنند که زندگی غیرقطعی است. با وجود این‌که همه چیز را در نظر گرفتیم و شاید دقیقاً مطابق آن‌چه که انتظار داشتیم پیش نرفتیم، اما به اندازه‌ی کافی به آن نزدیک شدیم، به طوری که این اجرای پروژه را خوب و به طور کلی یک پروژه‌ی موفق در نظر می‌گیریم. این به نوعی ماهیت داستان چمدان بود. هدف آن این بود که نشان دهد خیلی خوب بود اگر هیچ چیز هرگز تغییر نمی‌کرد و می‌توانستیم به دقت پیش‌بینی کنیم که دقیقاً چه رخ خواهد داد؛ هرچند در واقعیت این‌گونه نیست اما آن‌چه واقعاً می‌خواهیم این است که به اندازه‌ی کافی به برآورد‌هایمان نزدیک شویم؛ به طوری که بتوان فاصله را با حد معقولی از کار اضافی، یا حذف کردن ویژگی‌ها در مقیاس‌های کوچک، یا تغییرات کوچکی که روی موفق بودن پروژه تأثیر ندارند، پر کنیم.

🙂 من تقریباً ۲۰ سال است که یک کلاس برآورد کردن را تدریس می‌کنم. حداقل در ۱۰ سال گذشته به دانشجویان تمرینی می‌دهم و به آن‌ها می‌گویم که سه دقیقه وقت دارید که طوفان فکری کنید و هر تعداد که می‌توانید از منابع تغییرات در پروژه را بیابید که باعث می‌شوند برآورد‌هایی که پروژه بر آن بنا شده بود باطل شود. از همان تغییراتی که به صورت روزمره رخ می‌دهند. من به دنبال تغییرات تصادفی و غیرمنتظره نیستم که شاید بتوان پیش‌بینی کرد بلکه به دنبال چیزهایی هستم که در برآورد‌ها در نظر گرفته نشدند و حتی اگر آن‌ها را در نظر می‌گرفتید نمی‌توانستید برآورد را بهبود دهید. چیزهایی که همواره در پروژه‌ها رخ می‌دهند. به آن‌ها سه دقیقه وقت می‌دهم تا هر تعداد که می‌توانند بگویند. در یک گروه بیست نفری معمولاً لیستی از ۳۰ یا ۴۰ مورد تهیه می‌شود. لیست را بررسی می‌کنیم و می‌گویم که از شما خواستم که اتفاقات نادر را نگویید. آیا این‌ها اتفاقات غیرمتداول هستند یا عموماً رخ می‌دهند؟ آن‌ها همیشه می‌گویند این‌ها متداول هستند و همیشه اتفاق می‌افتند. چیزهایی که از آن صحبت می‌کنیم از این قبیل‌اند: یک عضو کلیدی از دسترس خارج می‌شود، کار را ترک می‌کند، یا به پروژه‌ی دیگری ملحق می‌شود؛ اولویت‌های مدیریتی عوض می‌شود، یعنی اولویت‌ها در ابتدای پروژه در حین پروژه تغییر می‌کنند؛ بودجه تغییر می‌کند، پروژه را با ده نفر شروع می‌کنید، بودجه عوض می‌شود و باید با هفت نفر کار را انجام دهید؛ بازار تغییر می‌کند، رقیب ویژگی‌ای منتشر می‌کند که باید به آن در نسخه‌ی بعدی محصول عکس‌العمل نشان دهید. این لیست ادامه دارد… .

این قبیل چیزها هستند که در تمام پروژه‌ها اتفاق می‌افتد. در حقیقت فکر می‌کنم اگر پروژه‌ای پیدا کنید که از ابتدا تا انتها حقیقتاً پایدار مانده باشد، به شدت متعجب می‌شوید. در اکثر مواقع وقتی می‌گویم پایدار منظورم این است که فرض‌هایی که برآورد را تحت تأثیر قرار می‌دهند از ابتدا پایدار بمانند. این‌ها فرض‌هایی در مورد مجموعه ویژگی‌ها، افراد تیم، پشتیبانی سازمانی و … هستند.

بله، فکر می‌کنم بسته به جزئیات، این سناریو می‌تواند به دلایل مختلفی اتفاق بیفتد. دلیل ناسالمی که ممکن است این اتفاق رخ دهد این است که افرادی که پروژه را برآورد می‌کنند برآوردگران خوبی نیستند و در واقع چیزی تغییر نکرده است و باید همان ۱۲۰۰ نفر/ساعت را در ابتدا برآورد می‌کردند. اما این کار را نکردند و ۱۰۰۰ نفر/ساعت برآورد کردند. بنابراین از برنامه عقب افتادند. این اساس برحقی در انتقاد به تیم است. فکر می‌کنم این گاهی اتفاق می‌افتد. حقیقت موضوع این است که وضعیت سرمشق‌های (Practice) [نحوه‌ی] برآورد هنوز خیلی خوب نیست. هنوز در اغلب موارد تیم‌ها و سازمان‌هایی را می‌بینیم که از چیزهایی که به آن سرمشق‌های «عقیده‌ی خبره» (Expert’s Judgment) گفته می‌شود، استفاده می‌کنند. این به این معنی است که این سرمشق‌ها به طرزی که استفاده می‌شوند به شدت در معرض خطا هستند. بنابراین خیلی اوقات این انتقاد برحق است.

در مواقع دیگر فکر می‌کنم یکی از دلایلی که پروژه‌ای که ۱۰۰۰ نفر/ساعت برآورد شده بود، ۱۲۰۰ نفر/ساعت طول بکشد تغییرات ردگیری نشده در مفهوم پروژه هستند. فکر می‌کنم این خیلی متداول است. من موارد خیلی خیلی زیادی را دیده‌ام که تیم‌های پروژه با یک مفهوم از پروژه و مجموعه‌ای از نیازمندی‌ها شروع به کار روی پروژه می‌کنند. [سپس] تغییرات نیازمندی‌ها یا نیازمندی‌های جدید وارد می‌شوند. و همه‌ی افراد از جمله‌ی افراد کسب‌وکار دور میزی می‌نشینند و تغییرات را نگاه می‌کنند و می‌گویند این تغییرات خوب هستند؛ باید آن را انجام دهیم؛ هزینه‌ی آن ارزشش را دارد. اما اتفاقی که می‌افتد این است که هرچند همه با تغییرات موافق‌اند آثار تجمعی تغییرات را در پروژه ردگیری نمی‌کنند. از قدرت من خارج است که به شما بگویم چه تعداد تیم‌های پروژه را دیده‌ام که دور میز می‌نشینند و توافق می‌کنند که یک تغییر خوب است و به صورت داخلی موافقند که [این تغییر] روی پروژه و هزینه‌های آن تأثیرگذار است اما با این وجود این هیچ تأثیر موجی (Ripple Effect) [برای بروزرسانی] پروژه‌ی اصلی، بودجه‌ی اصلی یا زمان‌بندی اصلی ندارد. بنابراین فکر می‌کنم خیلی متداول است که پروژه‌ای که ۱۰۰۰ نفر/ساعت برآورد شده باشد اما ۱۲۰۰ نفر/ساعت طول بکشد. بسیار محتمل است که این ۲۰۰ نفر/ساعت را اضافه کرده باشیم؛ به صورت توافقی هم اضافه کرده باشیم. و اگر از کسب‌وکار بپرسید که فلان چیز یا بهمان چیز ارزشش را داشت؟ این تفاوت میان ۱۰۰۰ و ۱۲۰۰ ارزشش را داشت؟ خیلی محتمل است که بگویند بله. بنابراین آن‌چه که واقعاً از آن صحبت می‌کنیم اصلاً یک مسئله‌ی فنی نیست، یک مسئله‌ی ارتباطی [و انتقال مطلب] است. از این لحاظ که اطمینان حاصل کرد سازمان بفهمد که خود سازمان است که تصمیمی می‌گیرد و قلمروی (Scope) پروژه را افزایش می‌دهد. این تجاوز نیست؛ افزایش قلمرو آن است؛ این‌ها یکسان نیستند.

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

درست است.

بله، حتماً. چند دقیقه پیش در مورد وضعیت نامطلوبِ سرمشق‌های برآورد صحبت کردیم. یکی از جنبه‌هایی که وضعیت سرمشق‌ها نامطلوب است این است که هنوز هم افراد در زمان اشتباهی در پروژه‌ها برآورد می‌کنند و بار زیادی به برآوردها تحمیل می‌کنند. [برآوردهایی] که قبل از آن‌که بدانند چه می‌کنند تهیه شده است. فکر می‌کنم تمام جنبه‌های برآورد، چندوجهی هستند. تقریباً هر چیزی که از آن صحبت می‌کنیم، یک نقطه‌نظرِ کسب‌وکاری و یک نقطه‌نظرِ فنی دارد. نقطه‌نظرِ کسب‌وکاری سالم و ناسالم و همین‌طور نقطه‌نظرِ فنی سالم و ناسالم. به نظر من هیچ چیز ناسالمی در این نیست که کسب‌وکار در روز صفر پروژه، قبل از این‌که هیچ کاری انجام شده باشد، بخواهد بداند پروژه دقیقاً چقدر طول می‌کشد و چقدر هزینه دارد؟ این درخواست برای کسب‌وکار منطقی است. چیزی که منطقی نیست این است که افراد فنی بروند و وانمود کنند که چیزی که خواسته شده را به آنان داده‌اند. چون در روز صفر پروژه همان‌طور که گفتید مجهولات زیادی وجود دارد. ممکن است بی‌ثباتی‌هایی داشته باشیم. انواع مختلفی از بی‌ثباتی خواهیم داشت. بی‌ثباتی در تعداد کارمندان، به طور خاص چه کسانی عضو کارمندان خواهند بود؟ پروژه کی شروع خواهد شد؟ کارمندان کی در دسترس قرار می‌گیرند؟ دقیقاً چه ویژگی‌هایی در مجموعه قرار خواهند گرفت؟ توصیف جزئیات پیچیدگی‌های این ویژگی‌ها و … . ما بی‌ثباتی‌های بی‌شماری در روزهای نخست پروژه داریم. یکی از روش‌هایی که من در این مقطع می‌پسندم این است که سازمان لیستی از پروژه‌های قبلی که انجام داده است داشته باشد، که شامل هزینه و نیرو و زمان‌بندی است. بنابراین حتی در روز صفر پروژه کسب‌وکار می‌تواند بگوید ما فکر می‌کنیم پروژه‌ی جدید از لحاظ حجم چیزی شبیه به فلان پروژه است که بر اساس اطلاعات گذشته‌ی ما ۱۵۰۰ نفر/ساعت و ۴ ماه طول کشید. بنابراین پس از این افراد فنی می‌توانند بازگردند و بگویند بله به نظر ما هم این شبیه فلان پروژه است و یک برآورد کلی -چیزی مانند آن‌که با انگشت در هوا نگه داشتن مسیر باد را تشخیص دهیم- فکر می‌کنیم در همان محدوده باشد. این بدین معنی است که با پیشرفت بیشتر کار ممکن است دو برابر بیشتر یا کم‌تر باشد. این فکر منطقی است. یا ممکن است افراد فنی بازگردند و بگویند نه، من فکر می‌کنم شما فلان پروژه را در نظر دارید در حالی که واقعاً منظورتان فلان چیز و بهمان چیز دیگر هم هست و وقتی همه‌ی این‌ها را تجمیع کنیم چیزی شبیه به بیسار می‌شود که به میزان چشم‌گیری بیشتر است. می‌توانید این گفتگوها را در روزهای خیلی ابتداییِ پروژه داشته باشید. این‌ها به شما اعداد و ارقام نمی‌دهند و اما حداقل انتظارات شما را در محدوده‌ی مناسبی قرار می‌دهند.

مفهوم مخروط عدم قطعیت به ما می‌گوید زمانی پروژه‌های نرم‌افزاری با سطوح بالای تغییر که از تمامی منابع سرچشمه می‌گیرند، شناخته می‌شوند که پروژه واقعاً در مسیر قرار بگیرد. از مجموعه‌ی ویژگی‌ها، عدم قطعیت‌های معماری، و عدم عطعیت‌های کارمندان گرفته تا چیزهایی مثل این‌که مفهوم پروژه تا چه حد در حین پروژه تغییر خواهد کرد و انواع عدم قطعیت‌های دیگر وجود دارد. اگر ما کارمان را در بخش مدیریت فنی خوب انجام بدهیم، تلاش خواهیم کرد به منشأهای عدم قطعیت هجوم برده تا میزان تغییر را کاهش دهیم. اگر کارمان را خیلی خوب انجام دهیم، این کار را به ترتیب انجام خواهیم داد و ابتدا به منشأهای دارای بی‌ثباتی زیاد هجوم می‌بریم. یعنی در هر برهه از پروژه به منشأ دارای بیشترین میزان بی‌ثباتی هجوم می‌بریم طوریکه تمامی منشأهای دیگر نسبت به مواردی که تا به حال به آن‌ها هجوم برده‌ایم بی‌ثباتی کم‌تری داشته باشند. این فعالیت‌ها است که مخروط عدم قطعیت را شکل می‌دهد و بی‌ثباتی را به شدت و به سرعت کاهش می‌دهد. بسیاری از تیم‌ها این‌طور عمل نمی‌کنند. تیم‌هایی را می‌بینیم که سخت‌ترین کار را برای آخر کار می‌گذارند که از منظر برآورد کنترل پروژه مطلقاً بدترین کار ممکن است 🙂 بنابراین مخروط عدم قطعیت راهی برای توصیف آن چیزی است که می‌تواند در یک پروژه‌ی سالم اتفاق بیفتد و به هیچ وجه توصیفی از آن‌چه که در تمام پروژه‌ها اتفاق می‌افتد نیست.

فکر می‌کنم اگر نگاهتان را به مدیریت مخاطرات گسترده‌تر کنید، این‌طور باشد. وقتی ما در شرکت خودمان از مدیریت مخاطرات صحبت می‌کنیم معمولاً میان مدیریت مخاطرات ذاتی و اتفاقی تفاوت قائل می‌شویم. آن‌چه در پروژه‌های نرم‌افزاری می‌بینیم این است که همیشه روی مخاطرات اتفاقی تمرکز می‌کنیم. مثل این‌که فلانی و بهمانی پروژه را ترک کنند، یا این‌که فلان یا بهمان روش فنی جواب ندهد. اما فکر می‌کنم در اکثر پروژه‌ها مخاطرات اتفاقی در واقع در مقایسه با مخاطرات ذاتی ناچیز هستند. می‌توانیم این‌ها را مخاطرات عمومی هم بنامیم. مخاطرات عمومی یا ذاتی، مخاطراتی شبیه به این هستند که ما کارمان را در فهم نیازمندی‌ها خوب انجام نمی‌دهیم و [در نتیجه] مجبور خواهیم شد دوباره‌کاری کنیم. زمان زیادی را صرف ساختن چیز اشتباهی می‌کنیم و آن را به مشتری نشان می‌دهیم و آن‌ها می‌گویند ما این را نمی‌خواستیم و آن چیز دیگر را می‌خواستیم. کیفیت پایین هم یکی دیگر از مخاطرات فجیع ذاتی است. تیم‌های پروژه‌ی زیادی را می‌بینیم که کاری را بسیار عجولانه انجام می‌دهند و بخش زیادی از کار کیفیت را به تعویق می‌اندازند. بدهی فنی (Technical Debtt) بدی را در حین پیشرفت کار انباشت می‌کنند. کارشان را روی پروژه انجام می‌دهند و فکر می‌کنند که در حال پیش‌رفت هستند اما در واقع به صورت غیر رسمی، در حال انباشت کردن مقدار زیادی کارِ رفع خطا هستند. این در واقع باعث ناپایدار شدن برآوردهای کنترل پروژه می‌شود. فکر می‌کنم خوب است که روی مخاطرات منحصر به فرد اتفاقی تمرکز کنیم؛ اما وقتی که به مخاطرات ذاتی -مخاطراتی که تقریباً در تمامی پروژه‌ها واقعاً رخ می‌دهند- بنگریم، [خواهیم دید] که میان کارهایی که برای باریک کردن مخروط عدم قطعیت انجام می‌دهیم و کارهایی که برای مدیریت مخاطرات ذاتی در پروژه‌ها انجام می‌دهیم، همپوشانی زیادی وجود دارد.

من عمدتاً به این شکل می‌بینمش -البته روی آن تأکید زیادی هم دارم- که آیا این واقعاً یک پیاده‌سازی کاملاً وفادار به اسکرام است؟ و آیا ما داریم دقیقاً در مورد اسکرام صحبت می‌کنیم؟ فکر می‌کنم بیش از حد بارِ کلمه چابک شده و در حال حاضر فریبنده و آبکی شده است. به حدی که اگر تیمی بگوید که چابک کار می‌کند به من هیچ اطمینانی در رابطه با این‌که روش کار آن‌ها بهتر از آبشاری باشد، نمی‌دهد. فرض کنیم تیمی بگوید که از اسکرام استفاده می‌کند و حقیقتاً اسکرام انجام دهند و فقط حرف آن را نزده باشند و یک پیاده‌سازی تا حد زیادی وفادار به اسکرام داشته باشند. در این صورت، فکر می‌کنم بخشی از آن‌چه در اسکرام خیلی خوب جواب می‌دهد این باشد که روشی که اسکرام جا انداخته می‌شود در واقع این استعداد نهانی را دارد که به برخی از مخاطرات ذاتی در پروژه‌ها هجوم ببرد. بنابراین این خیلی وابسته به این است که تیم یک پیاده‌سازی با وفاداری بالا به اسکرام داشته باشد.

شما به دوره‌های دو هفته‌ای اشاره کردید. بله اگر تیم حقیقتاً دوره‌ها را کوتاه نگه دارد و چیزی را پایان هر دوره تحویل دهد، به چند طریق کمک می‌کند. یک راه این است که اگر از نظام (Discipline) پیش‌برد نرم‌افزار به سمت یک سطح قابل انتشار از کیفیت پیروی کنیم، به بررسی مخاطرات عمومیِ مربوط به کیفیت پایین کمک کرده‌ایم. اما بسیاری از تیم‌ها را می‌بینیم که از اسکرام استفاده می‌کنند و این‌کار را انجام نمی‌دهند. این یکی از حالت‌های اصلی شکست در اسکرام است. این که تیم‌ها نظام نگه‌داشتن نرم‌افزار در یک سطح قابل انتشار از کیفیت را ندارند. و وقتی چنین کاری را انجام می‌دهند مقدار زیادی از مزایای اسکرام را از دست می‌دهند. صِرف این‌که ما هر دو هفته یکبار [مؤلفه‌ها را] ادغام می‌کنیم حس بهتری از پیش‌رفت نسبت به آن‌چه در حالت آبشاری انجام می‌دهیم به ما می‌دهد. فرض کنید نیازمندی‌هایمان را به صورت دسته‌های بزرگ انجام داده‌ایم و بیشتر آن را در ابتدای کار انجام داده‌ایم. بنابراین طرح‌ریزیِ اسپرینت را انجام می‌دهیم و آن را به یک دوره‌ی دو هفته‌ای نگاشت می‌کنیم. تصور می‌کنیم این دوره‌ی دوهفته‌ای حدود ده درصد از نیازمندی‌های کلی پروژه را برآورده می‌کند. خوب اگر به انتهای دوره‌ی دو هفته‌ای برسیم و فقط نیمی از کار را انجام داده باشیم -به عبارت دیگر تنها پنچ درصد از پروژه را انجام داده باشیم- این یک داده‌ی اولیه‌ی خیلی قوی به ما می‌دهد که پروژه‌ی ما احتمالاً دو برابر بیشتر از آن‌چه فکر می‌کردیم طول خواهد کشید. این یک تضمین صد درصدی نیست اما باعث می‌شود سؤال ایجاد شود و باعث می‌شود این سؤال زودتر ایجاد شود. وقتی به دوهفته‌ی دوم وارد می‌شویم می‌توانیم بگوییم خود را می‌رسانیم و یا این که بگوییم همچنان با نیمی از آن سرعتی که فکر می‌کردیم پیش خواهیم رفت. دو هفته‌ی دیگر یک نقطه‌ی بررسی (Check Point) جدید خواهیم داشت. این عالی است. در پروژه‌های آبشاری سنتی که برای بیست هفته طرح‌ریزی شده بود، به راحتی ممکن بود پانزده هفته در پروژه پیش رویم پیش از آن‌که به فکر بیفتیم که مشکلی داریم. در بسیاری موارد ممکن بود نوزده و نیم هفته پیش برویم، پیش از آن‌که به این مشکل اقرار کنیم. اما اجرای خوب از یک پیاده‌سازی اسکرام ممکن است بعد از دو تا چهار هفته پس از طرح‌ریزی متوجه این مشکل شویم. بنابراین به لحاظ مدیریت مخاطرات عمومی، افکار واهی و برآوردهای کم، خیلی تأثیر گذار است.

مسئله‌ی دیگر این است که ما به موضوع مدیریت مخاطرات رسیدیم. مدیریت مخاطرات شامل کنترل مخاطرات، مدیریت مخاطرات، اولویت‌بندی مخاطرات و … می‌شود. اما نقطه‌ی شروع همه‌ی این‌ها شناسایی مخاطرات است. فکر می‌کنم یکی از چیزهایی که در اسکرام خصوصاً با دوره‌های کوتاه، تعبیه شده است این است که اگر در یک دوره آن‌چه که تصور می‌کردیم را تحویل ندهیم، باعث می‌شود از خود بپرسیم چرا این‌طور شد؟ این طبیعتاً به سرعت و مکرر موجب شناسایی مخاطرات می‌شود. بنابراین [با این که] اسکرام هرگز مستقیماً از شناسایی مخاطرات صحبت نمی‌کند، این مفهوم شناسایی مخاطرات اساساً از آن نتیجه می‌شود. با یک پیاده‌سازیِ با وفاداری بالا به اسکرام، شناسایی مخاطرات مداوم و زودهنگام را به دست می‌آوریم. اگر بتوانیم مخاطرات را زودهنگام شناسایی کنیم معمولاً گزینه‌های قدرت‌مندتری برای رسیدگی به آن مخاطرات داریم. در نتیجه همه چیز بهتر کار خواهد کرد. بنابراین بله، فکر می‌کنم اگر اسکرام بر اساس کتاب و با وفاداری بالا اتخاذ شود این استعداد نهفته برای کاهش مخاطرات مهمِ ذاتیِ سنتی و منشأهای بی‌ثباتی در نرم‌افزار را دارد.

چیز دیگری که می‌خواهم توضیح دهم این است که یک زیرجریان (Undercurrent) در اسکرام وجود دارد که به نظر من با برآورد مغایر است. در اسکرام یک جوّ فرهنگی وجود دارد که فکر می‌کنم جزئی از سرمشق‌های اسکرام نباشد. اما اگر ادبیات اسکرام از جمله کتاب اصلی آن که توسط کِن شوِیبر و … نوشته شده است را بخوانید، تأکیدی قوی بر توانایی اسکرام در انعطاف‌پذیری و پاسخ دادن به تغییرات و نیازمندی‌ها وجود دارد. به طوری که هر چند واقعاً ذکر نمی‌شود خیلی راحت ممکن است به این ایده برسید که تنها راهی که باید همواره یک پروژه‌ی اسکرام را اجرا کنیم این است که نیازمندی‌ها را در ابتدا تثبیت نکنیم و حتی تلاشی برای این کار نکنیم؛ صرفاً باید نیازمندی‌ها را در حین انجام کار شناسایی کنیم و در حین انجام کار آن را دگرگون کنیم و فقط از همین طریق آن را انجام دهیم. اگر این روش را اتخاذ کنیم -که ممکن است در برخی موارد جواب دهد- از هرگونه اندیشه‌ی برآوردهای طولانی مدت‌تر دست برداشته‌ایم. بنابراین زمانی که از اسکرام به این شکل سرمشق گرفته شود -به طور خاص اگر نیازمندی‌ها فقط دوره به دوره انجام شوند- ما از توانایی خود برای برآورد کردن، به شکل ضعیفی استفاده کرده‌ایم. من نمی‌گویم که این خوب است یا بد است، من می‌گویم وقتی که از [این] ترکیب اسکرام و برآورد کردن صحبت می‌کنم، این ترکیبی است که جواب نخواهد داد.

فکر می‌کنم چند سؤال در اینجا وجود دارد. روشی که من با آن اسکرام و برآورد آشتی می‌دهم این است که -صادقانه بگویم، من فکر نمی‌کنم کار زیاد یا تغییر بزرگی در اسکرام نیاز باشد که تا این آشتی برقرار شود- از یک رویکرد دسته‌ای به نیازمندی‌ها در ابتدای پروژه استفاده شود. این به آن معنی نیست که بعداً نمی‌توانیم نظرمان را عوض کنیم. تمام فکر اصلی بیانیه چابک‌سازی (Agile Manifesto) در XP پذیرفتن تغییرات بود. این نبود که تعهد ندهید بلکه این بود که خودتان را به نحوی آماده کنید که وقتی تغییرات اتفاق افتاد بتوانید به آن پاسخ دهید و آن را بپذیرید. اسکرام به شما قابلیت خوبی در پذیرفتن تغییرات می‌دهد اما این به آن معنی نیست که شما نمی‌خواهید ثبات داشته باشید. بنابراین با قرار دادن حد کافی از تعاریف در نیازمندی‌ها این آشتی برقرار می‌شود. منظورم [تعریف کردن] هر اندازه از مجموعه کل نیازمندی‌هایتان است که می‌توانید در ابتدای پروژه‌ی اسکرام داشته باشید. این شامل این است که آن‌ها به قدری خوب تعریف شده باشند که بتوانید از برآوردهای درجه‌ی داستان برای آن استفاده کنید. سپس برآوردهای درجه‌ی داستان را انجام می‌دهید. محاسبه می‌کنید که در مجموع چند درجه داستان در پروژه دارید و آن را در زمان‌بندی نگاشت می‌دهید: تعداد داستان‌ها در هر دوره. سپس کار توسعه‌ی جزئیات پروژه را شروع می‌کنید و سرعت‌تان را اندازه می‌گیرید. این به شما توانایی چشمگیری می‌دهد تا بر این که آیا واقعاً درحال پیش‌رفت بر اساس طرح‌ریزی هستید و این که آیا واقعاً به برآوردهایتان دست می‌یابید، نظارت کنید. همیشه تصوری از آن‌چه که فکر می‌کنید سرعت اولیه‌تان خواهد بود دارید و بعد از دو یا سه دوره، داده‌های واقعی پروژه را خواهید داشت که می‌توانید از آن برای اصلاح کردن برآوردهایتان استفاده کنید. این داده‌ها یا به شما می‌گویند برآوردهای اولیه شما خوب بودند و یا این که نیاز به اصلاح دارند. در هر صورت هنوز هم در ابتدای پروژه هستید و این توانایی را دارید که بگویید ما فکر می‌کردیم سرعت‌مان ۲۵ درجه داستان در هر دوره خواهد بود اما الان که دست به کار شدیم با سرعت ۱۵ درجه داستان در هر دوره پیش می‌رویم. بنابراین اگر با همین سرعت پیش برویم ۶۷٪ از برآورد تجاوز خواهیم کرد. هیچ کس دوست ندارد که این را بشنود. کسی خبر بد را دوست ندارد. اما اگر به جای دیرتر گفتن، زودتر به آن‌ها بگویید رضایت بیشتری دارند. اسکرام قابلیت خوبی برای این به شما می‌دهد. اگر نیازمندی‌هایتان را از پیش تعریف کنید و تا سطحی از جزئیات این کار را انجام دهید که بتوان به آن درجه‌ی داستان نسبت داد. اتفاقی که می‌افتد این است که شاید شما چند دوره پیش بروید و تغییرات زیادی رخ ندهد و شما اولویت‌ها را به صورت نزولی تحویل می‌دهید. همه چیز خوب پیش می‌رود تا این‌که تغییرات رخ می‌دهند. این خیلی خوب است چون اسکرام سازوکار فوق‌العاده‌ای برای پذیرفتن این تغییرات به شما می‌دهد. می‌توانیم تغییرات پیشنهادی را در قالب درجه داستان برآورد کنیم و اولویت آن را در مقایسه با داستان‌های موجود در انباره‌ی انتشار (Release Backlog) تعیین کنیم. می‌توانیم آن‌ها را اضافه کنیم و بدانیم زمان‌بندی‌مان چه‌قدر زیاد می‌شود، چون چیزی به آن اضافه می‌کنیم و سرعت‌مان را می‌دانیم. یا این‌که می‌توانیم ویژگی‌های جدید را با کارهای کم اولویت‌تر در انباره جابجا کنیم و مجموع درجات داستان را ثابت نگه‌داریم.

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

چیز دیگری که می‌گویم این است که من به شدت به این نتیجه رسیده‌ام که یکی از پاشنه‌های آشیل در توسعه‌ی چابک و تکرارشونده با نگاه از منظر کسب‌وکار این است که کسب‌وکارها ترجیح می‌دهند اشتباه کنند تا این‌که در ابهام باشند. منظورم این است که اگر بگوییم می‌خواهیم این مجموعه ویژگی‌ها را بسازیم که این‌قدر طول می‌کشد و این قدر هزینه دارد و به میانه‌ی پروژه برسیم و بگوییم می‌دانی چیست؟ الان تصویر بهتری داریم و می‌خواهیم برنامه‌مان را اصلاح کنیم؛ فلان ویژگی‌ها را اضافه می‌کنیم و بهمان ویژگی‌ها را حذف می‌کنیم و الان برنامه این است. کسب‌وکار در واقع با تغییر عقیده کنار می‌آید؛ با اشتباه بودن کنار می‌آید؛ اما برای شروع به چیزی واقعی نیاز دارد. بنابراین الگویی که توصیف کردم از منظر کسب‌وکار یک الگوی دوام‌پذیر و قابل‌پذیرش است. آن‌چه که معمولاً از منظر کسب‌وکار قابل قبول نیست این توصیف متعارف چابک است که می‌گوید پولی که دارید را به ما بدهید و مجموعه ویژگی‌های مورد نظرتان را هم بدهید که لازم نیست کامل باشد. ما هر دو هفته یک‌بار از شما می‌پرسیم ارزشمندترین چیز بعدی که می‌خواهید برایتان انجام دهیم چیست؟ این به شما امکان می‌دهد که حداکثر میزان ارزش را از پولی که خرج کردید دریافت کنید چون ما همیشه روی مهم‌ترین چیز باقی‌مانده کار می‌کنیم. منطقی در این [نگاه] وجود دارد. چیز بدی در این تحلیل وجود ندارد، آن‌چه که بد است این است که در اکثر موارد [این نگاه] با نحوه‌ی بودجه‌بندی و خرج‌کردن کسب‌وکار مطابقت ندارد. کسب‌وکار بودجه را صرف نمی‌کند مگر این‌که حداقل تصویری کلی از آن‌چه که برای پولش خواهد گرفت داشته باشد. بنابراین این اندیشه که به من اعتماد کن، [چون] من همیشه ارزشمندترین چیز بعدی را تحویل می‌دهم برای کسب‌وکار به این معنی نیست که شما [اجازه دارید] آن کار را انجام دهید. این ما را به موضوع برآورد بر می‌گرداند. برآورد به این هدف کسب‌وکار کمک می‌کند که می‌خواهد از آنچه در ازای پولش خواهد گرفت تصویری حداقلی داشته باشد.

نمی‌خواهم این‌طور جلوه دهم که رویکرد تکرارشونده‌ی خالص هرگز مفید نیست. فکر می‌کنم عرصه‌هایی هست که در آن مفید است مثلاً در یک زمینه‌ی اکتشافی تحقیقاتی. فکر می‌کنم یک راه برای توضیح آن -که عوام پسند نیست- این باشد: نیازمندی‌ها [به روش] آبشاری، توسعه [به روش] اسکرام. این به نوعی آن‌چه که می‌گویم را خلاصه می‌کند. فکر می‌کنم در خیلی موارد خوب کار می‌کند. اما نمی‌خواهم این را القا کنم که محیط‌های دیگری وجود ندارد که در آنجا انجام نیازمندی‌ها به روش تکرارشونده‌ی خالص مفید نباشد. اگر من در فضایی در حال ظهور قرار داشته باشم، مثلاً اگر من پنج سال پیش روی برنامه‌های تلفن همراه کار می‌کردم که نمی‌دانستم و نمی‌توانستم برای یک سال طرح‌ریزی کنم چون خیلی در حال تغییر بود آن زمان، برنامه‌ام را می‌نوشتم و هر دو هفته مهم‌ترین چیز بعدی را انجام می‌دادم. اگر بازار تا این حد ناشناخته و متغیر است احتمالاً این رویکرد خیلی خوبی است. اگر در یک زمینه‌ی تحقیقاتی هستم و میزان زیادی از مجهول‌های مرکب (Unknown Unknown) دارم؛ [یعنی] حتی نمی‌دانم مجهول‌هایم چه هستند؛ آن‌وقت این‌که سعی کنم بفهمم بزرگ‌ترین مجهولات پیش‌رو چه هستند و دوهفته‌ی بعدی را روی آن‌ها کار کنم و سپس برگردم و بزرگ‌ترین مجهول بعدی را پیدا کنم، فکر می‌کنم پاسخ مناسبی باشد. نکته این است که ما در حال صحبت کردن از برآورد هستیم و با وجود این‌که این [برآورد کردن] رویکرد درستی برای مدیریت و کنترل یک پروژه با میزان زیادی عدم قطعیت است، اما این روش‌ها [ی کاملاً اکتشافی] از برآورد حمایت نمی‌کنند. بنابراین برآورد در تک‌تک پروژه‌ها ضروری نیست. فکر می‌کنم همیشه مفید است که از کسب‌وکار پرسید آیا به برآورد اهمیت می‌دهد؟ اما عموماً حتی لازم نیست این سؤال را بپرسیم. کسب‌وکارها از همان اول شدیداً برآورد را از شما می‌خواهند. بنابراین خیلی واضح است که کسب‌وکار به برآورد اهمیت می‌دهد.

بله فکر می‌کنم در محیط استارتاپ اگر صد درصد اطمینان دارید که ایده‌ی خوبی دارید به این شکل باشد. مثلاً اگر به عقب برگردیم و من Lotus 1-2-3 باشم وVisiCalc از پیش در بازار وجود داشته باشد و من می‌دانم که مأموریت من این است که می‌خواهم نرم‌افزار صفحه گسترده‌ی نسل بعد را تولید کنم. اگر بخواهم محصولی جالب و پیش‌گام و تغییردهنده‌ی دنیا را به صحنه بیاورم، مجهولات زیادی از لحاظ نیازمندی در اینجا وجود ندارد. باید نسل بعدی صفحه گسترده را منتشر کنم. بله ممکن است جزئیاتی در ویژگی‌ها باشد، اما تا حد زیادی آبشاری است و می‌توانید با آن مثل یک پروژه‌ی آبشاری رفتار کنید. بنابراین لزوماً تمام استارتاپ‌ها چنین رویکردی ندارند .استارتاپ‌های دیگر وجود دارند که افراد فکر می‌کنند زمینه‌ای در حال ظهور است و فرصت‌های بالقوه‌ی زیادی در آن هست. دقیقاً مطمئن نیستیم که این فرصت‌ها چیست. ممکن است شما یا سرمایه‌گذاران مایل باشید که پول یا سهمی از سود را صرف کاوش برای یافتن ایده‌های مفید کنید. ما موارد زیادی در اطراف خودمان نزدیک سیاتل می‌بینیم، استارتاپ‌هایی که افراد حاضرند چیزی را برای یک یا دو سال بیازمایند و می‌گویند می‌خواهیم ببینیم تا کجا می‌توانیم پیش برویم و سرمایه‌گذاران بر اساس ایده، علاقه و زمینه‌ی مملو از فرصت‌های بالقوه، گاهاً حاضر به صرف مقدار زیادی پول هستند.

وقتی به کسب‌وکارهای جاافتاده می‌رویم فکر می‌کنم کمی متفاوت باشد. در یک کسب‌وکار جاافتاده، کسب‌وکار می‌خواهد بداند اگر صدهزار دلار یا یک میلیون دلار خرج می‌کند در قبال آن چیزی به دست می‌آورد و بنابراین اینجاست که دوباره به فکر برآورد برمی‌گردیم. آن‌ها به برآورد نیاز دارند قبل از این‌که حتی حاضر باشند در مورد فرصت کسب‌وکاری که به پول نیاز دارد صحبت کنند. همیشه استثناهایی در همه چیز وجود دارد. اما متداول‌ترین حالت در اینجا این است که کسب‌وکارها به هر چیزی که نیاز به هزینه‌ی زیادی دارد نگاه می‌کنند و می‌خواهند به نوعی آن را مورد بررسی تجاری قرار دهند. این ممکن است رسمی یا غیررسمی باشد اما می‌خواهند این بررسی را انجام دهند. این [بررسی] شامل هزینه و سود است. هر دوی این‌ها خیلی تقریبی هستند. همه ما این را می‌دانیم؛ اما این به این معنی نیست که این کار را به طور کل رها خواهیم کرد. کاری که واقعاً باید انجام دهیم این است که بفهمیم چطور این اعداد را بهتر کنیم. بنابراین از نظر افراد فنی کاری که باید انجام دهیم این است که تقریب بهتری از این اعداد ارائه دهیم. این کار ماست که بدانیم توانایی واقعی تحویل سازمان چیست تا بتوانیم به کسب‌وکار بگوییم که هزینه چقدر است. در دنیای بی‌نقص، کسب‌وکار هم، به همین میزان در برآورد فرصت‌های بالقوه‌ی کسب‌وکار خوب است و می‌تواند سود را محاسبه کند. اما خوب این مسئله‌ی آن‌هاست 🙂 مسئله‌ی ما این است که کارمان را به بهترین شکلی که می‌توانیم برای محاسبه‌ی هزینه‌ها انجام دهیم.

فکر می‌کنم قبلاً به چند مورد کلیدی اشاره کرده‌ایم. یکی این است که قبل از آنکه بتوانیم برآوردی کنیم که ارزش زیادی داشته باشد، باید به اندازه‌ی کافی در مخروط [عدم قطعیت] پیش‌رفته باشیم تا بدانیم از چه صحبت می‌کنیم. بنابراین کلیدی است که تشخیص دهیم که در کجای مخروط عدم قطعیت قرار داریم، و تشخیص دهیم که اگر هنوز در سمت پهن مخروط باقی مانده باشیم نمی‌توانیم قطعیت زیادی داشته باشیم. بنابراین بدون آمادگی فکری، برآورد نکنید. اعداد حسی و تصادفی را که کسی از خود در می‌کند، به عنوان برآوردهای معنی‌دار تلقی نکنید. این‌ها واقعاً نکات کلیدی هستند. یک نکته‌ی کلیدی دیگر که فکر می‌کنم در مورد آن صحبت کردیم، این است که اطمینان حاصل کنیم تمایز واضحی میان برآوردها، اهداف و تعهد وجود دارد. ما می‌خواهیم مطمئن شویم که خودمان را با این افکار گیج نمی‌کنیم که واقعاً یک برآورد کرده‌ایم یا این‌که با فکر گروهی یک هدف یا تعهد را پذیرفته‌ایم بدون این‌که واقعاً آن را بسنجیم و برآورد کنیم. در مورد داده‌های تاریخی هم صحبت کردیم. از چند طریق در مورد نگه‌داری هزینه‌ها، زمان‌بندی‌ها و میزان نیروی مورد نیاز در پروژه‌های گذشته صحبت کردیم؛ این یک نوع از اطلاعات تاریخی است. گفتیم که با یک برآورد اولیه پروژه‌ی اسکرام را شروع کنیم، اما به محض این‌که بتوانیم سرعت واقعیِ مشاهده شده را محاسبه کنیم، فرصت داریم [برآورد را] اصلاح کنیم؛ این نوع دیگری از داده‌های تاریخی است که من به آن داده‌های پروژه می‌گویم. این با داده‌های سازمان متفاوت است. داده‌های پروژه در واقع قدرت‌مندترین نوع داده‌های تاریخی برای اهداف برآورد هستند. اگر این قبیل کارها را انجام دهیم از اکثر خطاهای بارز در برآورد جلوگیری کرده‌ایم و حداقل تا نیمه‌ی راه پیش رفته‌ایم.

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

متأسفانه یکی از الگوهای متداولی که در سازمان‌هایی -که خالصانه برای بهبود برآوردهایشان تلاش می‌کنند ولی فهم درستی از آن ندارند- می‌بینیم این است که قبل از موعد به سطح جزئیات زیادی وارد می‌شوند. این مایه‌ی ناراحتی است. چون کار به شدت زیادی انجام می‌دهند و انگیزه‌شان خوب است اما زیادی کار می‌کنند. روش مورد استفاده‌شان روش درستی نیست. بنابراین گاهی سخت است که شرکت‌ها را متقاعد کنید که می‌توانند با کار کم‌تر و وارد شدن به جزئیات کم‌تر به برآوردهای بهترِ زودهنگام‌تری دست‌یابند. افراد نرم‌افزاری گرایش به ورود به جزئیات دارند اما در حقیقت وقتی وارد پروژه‌های با اندازه‌های مختلف می‌شویم، برآورد بر اساس داده‌های تاریخی و براساس صفاتی در سیستم که قابل شمارش‌اند و … [کاملاً مفید است]. این‌ها، سرمشق‌هایی هستند که به ما در ارائه‌ی برآوردهای معنی‌دار و دقیق‌تر در ابتدای پروژه کمک می‌کنند. مگر این‌که در مورد یک پروژه‌ی دو یا سه نفری صحبت بکنیم که چند ماه بیشتر طول نمی‌کشد. برای پروژه‌های بزرگ‌تر لازم است به جای استفاده از عقیده [خبره] یا لیست وظایف، به سراغ چیزی که من در کتابم به آن شمارش و محاسبه می‌گویم برویم.

🙂 در این مورد فهمیدنش سخت است. مواردی هستند که چیزهایی که گفتید نشانه‌های خوبی از کلیت قلمروی پروژه هستند؛ نمی‌توانم در مورد خاص شما بگویم که این‌طور است یا نه. به طور کلی چون بسیاری از تیم‌ها از اسکرام استفاده می‌کنند، فکر می‌کنم درجه‌ی داستان در دسترس‌ترین چیز برای شمارش باشد. تفاوت چشم‌گیری میان بررسی یک لیست ویژگی‌های جزئی و برآورد نیرو یا زمان لازم برای هر یک از آن‌ها به جای برآورد کردن درجه‌ی داستان آن‌ها وجود دارد. وقتی درجه‌ی داستان را برای ویژگی‌ها برآورد می‌کنیم، احتمالاً تصوری کلی از این‌که هر درجه داستان به چند روز یا ساعت یا هفته تبدیل می‌شود، داریم. با این حال اندازه‌ی آن را با درجه‌ی داستان بیان می‌کنیم. بعداً چون همه چیز را با درجه‌ی داستان برآورد کرده‌ایم و درجه‌ی داستان یک مقیاس نسبی است، مقادیر مختلف درجه داستان‌ها وابسته به یکدیگر هستند. زمانی که پروژه آغاز شود ما این توانایی را داریم که درجه داستان‌ها را با توجه به داده‌های واقعی پروژه اصلاح کنیم. اگر از اسکرام استفاده کنیم می‌توانیم خیلی زود در ابتدای پروژه این کار را انجام دهیم. مثلاً دو یا چهار هفته بعد از شروع پروژه باید اصلاحاتی معقول داشته باشیم. از سوی دیگر اگر دقیقاً همان کار را و دقیقاً با همان سطح از جزئیات اما بر اساس تلاش [لازم برای انجام کار] برآورد کنیم، ممکن است منجر به خوش‌خیالی شود یعنی بگویم من فکر می‌کردم این سه روز طول بکشد اما وقتی شروع به کار کردم، متوجه شدم که نمی‌‌شود. ممکن است چون می‌خواهم در سه روز تمام شود لازم شود میان‌بر بزنم در نتیجه بدهی فنی وارد پروژه کنم. فکر می‌کنم حتی اگر از یک دید سطحی، عمل برآورد کردن در هر دو، خیلی یکسان به نظر برسد اما در تحرکات (Dynamicss) کاملاً متفاوت باشند.

به فهم کافی از نیازمندی‌ها نیاز دارید تا بدانید یک برای یک داستان مقیاس درجه‌ی آن در کجا قرار می‌گیرد. اگر درجه‌ی داستان را بر اساس کتاب انجام دهید مقیاس آن بی‌نهایت قابل تقسیم نیست. این‌طور نیست که بگوییم ۱، ۲، ۳، ۳.۱، ۳.۲ و … . اعداد متداول درجه داستان، اعداد فیبوناچی هستند ۱، ۲، ۳، ۵، ۸۸، … بنابراین لازم نیست بدانید که یک چیز دقیقاً ۵ است، کافی است بدانید که به اندازه‌ی ۳ کوچک نیست و به اندازه‌ی ۸ بزرگ نیست. باید به اندازه‌ای بدانیم که این گفتگو میسر باشد. لازم نیست در ذهن مان بدانیم که ۵.۵ است یا ۵.۷ هدف این سرمشق این نیست.

در واقع خیر. منظورم این است که در نهایت باید درجه داستان‌ها را به طرح اسپرینت تبدیل کنید و این‌که ما فکر می‌کنیم چه مقدار کار در یک اسپرینت می‌توانیم انجام دهیم…

بله البته. اگر تیمی دست نخورده داشته باشید که قبلاً تعدادی پروژه انجام داده باشد؛ که گاهاً اتفاق می‌افتد. خوشحالم که بگویم یکی از آثار جانبی برنامه‌ریزی‌نشده و غیر شایعِ حرکت به سمت اسکرام و [متدولوژی‌های] چابک این باشد که تیم‌ها را نسبت به قبل بیشتر در کنار هم نگه می‌دارد. این عقیده که یک تیم کارای دست‌نخورده را تجزیه کنیم در بیست سال نخست [فعالیت] من در صنعت خیلی دردآور بود. فکر می‌کنم در ده سال اخیر کم‌تر آن را دیده‌ام و فکر می‌کنم خوب باشد. اگر تیم دست‌نخورده‌ای داشته باشید، آن‌ها احتمالاً درکی سنجیده از [درجه داستان] سه، پنج یا … دارند. بنابراین می‌توانید سرعت آن‌ها را از پروژه‌های قبلی که روی آن کار کردند بفهمید. ممکن است دقیقاً مطابق نباشد اما معمولاً خطا حدود دو برابر است و خیلی نزدیک خواهد بود. اگر تیم دست‌نخورده‌ای نداشته باشید و افراد را جمع کرده‌اید،‌ احتمالاً افراد تصورات متفاوتی از [درجه داستان] سه یا پنج دارند. بنابراین تیم باید به عنوان یک تیم، مقداری کار کند تا همگام شود. می‌توانید که این برآورد را خیلی زود در ابتدای پروژه به مدیرتان ارائه کنید و بگویید که مجموعه ویژگی‌ها ما ۲۴۰ درجه داستان است و بهترین حدس ما این است که می‌توانیم ۲۰ درجه داستان در هر دوره انجام دهیم که این پروژه را در ۱۲ دوره به پایان می‌رساند. قطعاً می‌توانید این را ارائه کنید اما می‌توانید همزمان با آن بگویید که ما سرعت تیم جدید را از روز اول اندازه خواهیم گرفت و وقتی که به دوره‌ی دوم یا سوم برسیم، یعنی ۴ تا ۶ هفته بعد از شروع پروژه، تصویری سنجیده‌تر از این‌که آیا ۲۰ درجه داستان در هر دوره قابل دست‌یابی است یا نه خواهیم داشت. حداکثر ۶ هفته دیگر برمی‌گردیم و به شما می‌گوییم که زمان‌بندی ۲۰ هفته‌ای هنوز هم واقع‌بینانه است یا باید آن‌ها بر اساس مشاهدات تغییر دهیم.

در واقع از بین نمی‌رود چون عدم قطعیت از درجه داستان‌ها نشأت نمی‌شود، از سرعت نشأت می‌شود. بنابراین فکر می‌کنم به موضوع تمایز میان برآورد و تعهد برگشتیم. اگر مدیر من واقعاً یک برآورد از من می‌خواهد می‌توانم بگویم ما درجه داستان‌ها را شمرده‌ایم که ۲۴۰ است. اگر به سابقه‌ی افراد در این تیم و سرعت آن‌ها در پروژه‌های دیگر نگاه کنیم، به نظرمان می‌رسد سرعت‌مان چیزی بین ۱۵ تا ۲۵ درجه داستان در هر دوره باشد. هنوز به اندازه‌ی کافی اطلاعات نداریم تا مطمئن باشیم که سرعت‌مان ۱۵، ۲۰، یا ۲۵ است یا چیزی بین این‌هاست. بنابراین اگر امروز از ما برآورد بخواهید به شما بازه‌ای بر اساس ۲۴۰ درجه داستان با سرعتی بین ۱۵ تا ۲۵ درجه داستان در هر دوره می‌دهیم. اگر امروز از ما تعهد می‌خواهید،‌ تعهدمان را بر اساس حداقل بهره‌روی می‌دهیم که همان ۱۵ درجه داستان در هر دوره است. اما اگر به ما شش هفته فرصت بدهید می‌توانیم تعهد دقیق‌تر و بازه‌ی کوچک‌تری بدهیم و در حقیقت بازه نمی‌دهیم، تعهد می‌دهیم. ممکن است در ذهنمان بازه‌ای داشته باشیم اما آن زمان شرایط‌مان شبیه همان چمدان است؛ می‌دانیم که چه اندازه‌ای از چمدان نیاز داریم. ممکن است تغییراتی وجود داشته باشد که میزان زور مورد نیاز برای بسته شدن آن را تحت تأثیر قرار دهد، یعنی این‌که آیا پروژه به راحتی تمام خواهد شد یا باید مقداری اضافه‌کاری کنیم. اما تصور خیلی خوبی از تحویل کاری که سازمان از ما می‌خواهد، خواهیم داشت. ما با سازمان‌هایی کار می‌کنیم که عکس‌العمل‌های متفاوتی نسبت به این دارند. برخی‌ها می‌گویند ما الان تعهد را می‌خواهیم و اگر تنها چیزی که الان می‌توانید متعهد شوید سرعتی برابر با ۱۵ درجه داستان در هر دوره و تبعات آن است، ما امروز در فرایند طرح‌ریزی‌مان به آن احتیاج داریم و اشکالی ندارد. برخی دیگر می‌گویند متوجه هستیم که مقداری عدم قطعیت وجود دارد و ما ترجیح می‌دهیم تصویر واضح‌تری داشته باشیم. اگر ارزش بیشتری وجود داشته باشد نمی‌خواهیم عجولانه بهره‌وری شما را از آن‌چه که هست کم‌تر در نظر بگیریم. هرچند فعلاً عددی مثل ۲۰ درجه داستان در هر دوره را به عنوان سرعت در طرح‌ریزی قرار می‌دهیم و بر اساس آن زمان‌بندی می‌کنیم. اما برنامه داریم که طرح‌ریزی را در چهار تا شش هفته‌ی آینده بر اساس سرعت مشاهده‌شده به‌روزرسانی کنیم و می‌دانیم که این عدد قطعی تعهد شماست که می‌توانید به آن دست پیدا کنید. چون بر اساس داده‌های تاریخی و به طور خاص داده‌های پروژه است.

بله قطعاً پوکرِ طرح‌ریزی رویکرد مثبتی است که می‌تواند خوب عمل کند. پوکرِ طرح‌ریزی مثالی از خانواده‌ای از روش‌های برآورد کردن است که با عنوان روش‌های تصمیم‌گیری گروهی ساخت‌یافته (Structured Group Decision Making Techniquess) شناخته می‌شوند که در واقع همانی است که به نظر می‌رسد. افراد را در گروهی کنار هم قرار می‌دهد و ساختاری حول نحوه‌ی تصمیم‌گیری آنان شکل می‌دهد. پوکرِ طرح‌ریزی مقرراتی دارد که این ساختار را فراهم می‌کند. این مقررات شامل چیزهایی مثل این است که از مقیاس اعداد فیبوناچی استفاده می‌کنیم، هر کدام از ما جداگانه برآوردهایمان را می‌کنیم و همزمان نتیجه را نشان می‌دهیم. ممکن است مقرراتی در مورد این‌که اگر افراد بازه‌ای از برآورد داشتند یا هر کسی برآورد متفاوتی داشت، وجود داشته باشد یا وجود نداشته باشد. این یک راه انجام آن است. من فکر می‌کنم می‌تواند خوب جواب دهد. تیم‌هایی را دیده‌ایم که بخش پوکر را به معنای کلمه تعبیر می‌کنند و به اتاق کنفرانس می‌روند و عینک‌های سبز می‌گذارند و 🙂 فایده‌ای برای من ندارد اما اگر یک فعالیت خسته‌کننده را کمی جذاب‌تر می‌کند فکر می‌کنم ایرادی نداشته باشد.

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

حالا که این‌ها را گفتم و با این‌که پوکرِ طرح‌ریزی را دوست دارم و هیچ‌وقت تلاش نمی‌کنم تیمی را که از آن استفاده می‌کند و آن را دوست دارد و برای آن‌ها خوب جواب می‌دهد، را از انجام آن باز دارم اما این تنها راه ممکن برآورد کردن نیست. در کلاس‌های شرکت من یک روش جایگزین که ما تدریس می‌کنیم «دم را به برآورد بچسبان» نام دارد (این اصلاح از بازی کودکانه‌ی دم را به الاغ بچسبان برگرفته شده است-مترجم). در این روش ما مقیاسی را روی دیوار داریم که اعداد فیبوناچی روی آن نوشته شده‌اند. داستان‌های مختلف در کاغذ یادداشت‌ها نوشته شده‌اند. سپس در یک فرایند گروهی تصمیم می‌گیریم که یک کاغذ یادداشت در کجای دیوار قرار می‌گیرد، در عدد ۵، در عدد ۸، در عدد ۱۳ یا … . این مثال دیگری از روش تصمیم‌گیری گروهی ساخت‌یافته است. جزئیات آن متفاوت‌ است اما موفقیت خوبی با استفاده از این روش داشته‌ایم. من نمی‌گویم که این روش از پوکر طرح‌ریزی بهتر است یا بدتر. بعضی از گروه‌هایی که با آن‌ها کار می‌کنیم آن روش را دوست دارند. مثلاً برخی گروه‌ها این‌که به جای ایستادن، می‌نشینید و چنین چیزهایی را بیشتر دوست دارند. فکر می‌کنم در حالت کلی روش‌های تصمیم‌گیری گروهی ساخت‌یافته یکی از روش‌های خوب برای برآورد و قطعاً نسبت دادن درجه داستان‌ها به طور خاص، هستند.

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

کتاب من در بردارنده‌ی اکثر مفاهیم مهم در مورد برآورد است. در سال ۲۰۰۶ منتشر شده است و در آن زمان برخی از سرمشق‌های اسکرام به هیچ‌وجه به توسعه‌یافتگی امروز نبودند و برآورد در اسکرام به نسبت آن‌چه که در کتاب توضیح داده‌ام پیش‌رفت کرده است. شرکت من یک کلاس آموزشی آنلاین در مورد برآورد دارد که من آن را تدریس می‌کنم، ممکن است افراد به آن علاقه‌مند باشند. یکی از چیزهای مورد علاقه‌ی من یک مطلب است که چند سال پیش در مورد یک پروژه‌ی تابستانی برای ساختن یک قلعه برای بچه‌هایم، نوشتم. فکر می‌کنم چند نکته‌ی جالب در مورد برآورد در آن پروژه وجود داشت. فکر می‌کنم یکی از جالب‌ترین مطالبی باشد که نوشته‌ام 🙂