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

مطلبی که می‌خوانید ترجمه ی قسمت قسمت ۲۷۳ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ی یکی از موضوعات حوزه‌ی مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.
در این قسمت که در نوامبر ۲۰۱۶ منتشر شده است، سوِن یوهان با استیو مک‌کانل درباره‌ی برآورد نرم‌افزار (Software Estimation) صحبت می‌کند. مباحثی که مطرح می‌شود:

• چرا و چه وقت کسب‌وکارها به برآورد نیاز دارند یا چه وقت ندارند؟
• تبدیل برآورد‌ها به طرح‌ریزی و سنجش پیشرفت بر اساس این طرح‌ریزی به چه نحوی است؟
• چرا برآورد‌های نرم‌افزار همواره مملو از عدم قطعیت است؟
• این عدم قطعیت‌ها چه هستند و چه‌طور با آن‌ها روبرو شویم؟

من سوِن یوهان هستم و امروز استیو مک‌کانل مهمان من است. استیو مدیر ارشد اجرایی و مهندس ارشد نرم‌افزار در شرکت نرم‌افزاری Construx است؛ او مؤلف Code Complete ، Rapid Development و بسیاری کتاب‌های دیگر است. او در سال ۲۰۰۶ کتابی در مورد برآورد نرم‌افزار منتشر کرد. همچنین به عنوان سردبیر مجله مهندسی نرم‌افزار IEEE فعالیت کرده است. من امروز با استیو درباره‌ی برآورد هزینه‌ی نرم‌افزار صحبت می‌کنم. استیو به برنامه خوش آمدی!

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

آیا چیز مهمی را در معرفی شما فراموش کردم؟

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

خوب. برآورد چیست؟

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

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

تعهد، هدف و برآورد. رئیس من از من یک برآورد خواست اما در واقع می‌خواست به هدفی برسد و از ما تعهدی برای رسیدن به هدف بگیرد. آیا این بازگویی از زبان من درست است؟ :-)

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

وقتی کتاب‌تان را خواندم توضیح خیلی خوبی در این مورد داده بودید؛ با [تمثیل] یک چمدان زمانی که به تعطیلات می‌روید. با تثبیت میزان چیزهایی که می‌تواند در چمدان قرار بگیرد. شاید بخواهید در مورد این مثال به مخاطبان بگویید. فکر می‌کنم [موضوع را] خیلی واضح کند.

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

اما خطای برآورد از کجا سرچشمه می‌گیرد؟

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

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

ین کار را سخت می‌کند. منظورم این است که برخی از همکاران سابقم را می‌شناسم که برآورد می‌خواستند و در انتها فقط اعداد را مقایسه می‌کردند. [آن‌ها می‌گفتند:] این‌ها ۱۰۰۰ نفر/روز برآورد کرده بودند در حالی که ۱۲۰۰ نفر/ساعت وقت گرفت؛ [پس] این افراد، بد هستند. من فرصتی برای دفاع ندارم. چه‌طور باید از خودم دفاع کنم. راهی وجود دارد؟ آیا باید همه چیز را بنویسم، یا این صرفاً احساس شخصی من است که افراد اسلحه‌ای روی سر من گذاشته‌اند [و می‌گویند] تو کاملاً اشتباه برآورد کردی!

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

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

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

باشه، من این را امتحان خواهم کرد :-) خوب به نظر می‌رسد. میزان زیادی عدم قطعیت در برآورد وجود دارد. درست است؟ حتی اگر همه‌ی این کارها را انجام دهم، ممکن است خیلی اشتباه کنم. چون وقتی یک پروژه را برآورد می‌کنم خصوصاً در ابتدای آن، زمانی که مشتری می‌گوید می‌خواهم یک فیسبوک برای سگ‌ها داشته باشم :-)) و ما آن را برآورد می‌کنیم. در شروع کار، من اطلاعات خیلی کمی در مورد آن دارم. هر چه بیش‌تر پیش می‌روم درک بیش‌تری از مشکلات پروژه پیدا می‌کنم و برآوردی بهتری می‌کنم. فکر می‌کنم یک اصطلاح برای آن وجود داشته باشد: مخروط عدم قطعیت (Cone of Uncertainty).

درست است.

می‌توانید این را توضیح دهید؟

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

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

این‌طور به نظر من می‌رسد که عدم قطعیت و مدیریت مخاطرات (Risk Management) خیلی به هم نزدیک هستند یا تقریباً یکسان هستند.

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

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

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

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

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

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

چطور برآوردهای اسکرام و آن‌چه که واقعاً تحویل داد‌ه‌ایم را ارزیابی می‌کنید؟ مثلاً یک پروژه‌ی اسکرام را شروع می‌کنیم و برآوردهایمان را انجام می‌دهیم و تصمیم می‌گیریم که پنج ویژگی را می‌خواهیم. معمولاً [این کار را] تک به تک انجام نمی‌دهیم،‌ احتمالاً دو ویژگی را به صورت موازی انجام می‌دهیم. برآوردمان را [با] درجه‌ی داستان (Story Point) انجام می‌دهیم، و یک سرعت (Velocity) داریم. بعد از مدتی خیلی دشوار است که آن‌چه که قبلاً انجام داده‌ایم را با نیازمندی‌های اولیه تطبیق دهیم. چون هرگز میزان زمانی را که برای یک نیازمندی صرف کرده‌ایم را یادداشت نکرده‌ایم.

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

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

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

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

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

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

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

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

چطور این کار را انجام دهیم؟ چه روش‌های خوب و بدی در برآورد کردن وجود دارد؟ اگر کسی از من بخواهد که فیس‌بوکی برای سگ‌ها بسازم. چطور به برآورد برسم؟

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

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

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

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

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

اما اگر درجه داستان‌ها را بشمارید هنوز هم به فهم خوبی از نیازمندی‌ها نیاز دارید. درست است؟

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

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

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

اگر مدیر من بخواهد بداند...

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

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

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

بسیار خوب. نزدیک به پایان هستیم. سؤال آخر. ما در مورد اسکرام زیاد صحبت کردیم. اگر در اسکرام برآورد کنیم، معمولاً پوکرِ طرح‌ریزی (Planning Poker) را داریم،‌ یعنی تعداد زیادی از افراد برآورد می‌کنند. آیا این خوب است؟ و اگر بله، چرا؟

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

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

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

بسیار خوب. آیا چیز مهمی هست که من یادم رفت از شما بپرسم؟

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

فکر می‌کنم این‌طور باشد. به جز کتاب‌تان منبع دیگری هم دارید که شنوندگان ما باید در مورد برآورد نرم‌افزار بدانند؟

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

خوب است. استیو از شما متشکرم که در برنامه حضور داشتید.