برای اینکه سرعت پیشرفت (Pace) خود را مشخص کنید، ابتدا باید Deadline هر دوره را جدی بگیرید و ارائه یک نرم افزار کامل، تست شده، یکپارچه، و آماده انتشار را هدف خود بدانید. نرم افزاری که کامل نباشد، یا باگ زیادی داشته باشد، مشکلاتی غیر قابل پیش بینی به وجود میآورد که به احتمال زیاد تلاشی نامعلوم برای برطرف کردن آنها نیاز دارد. اگر احتمال میدهید برای اتمام تمامی تسکها دچار مشکل هستید، جلسه Iteration Planning برگزار کنید تا Iteration با ظرفیت پروژه یا Project Velocity هماهنگ شود. حتی اگر تنها یک روز از Iteration باقی مانده است، به جای زخمی کردن چندین تسک، اعضای تیم را وادار کنید تا تنها روی یک تسک تمرکز کنند.
از دید متدولوژی XP ، اضافهکاری چه تاثیری بر بهره وری میگذارد؟
اضافهکاری انگیزه و هیجان کار کردن را از اعضای تیم میگیرد؛ وقتی تیم خسته و بیروحیه باشد کار با سرعت کمتری پیش میرود حتی اگر ساعات بیشتری کار کند. اضافهکاری اعضا باعث پایین آمدن بهره وری یا Productivity تیم در بلند مدت میشود. اگر تیم نسبت به ماه قبل و بعد کار بیشتری را پیش ببرد، برنامه ریزی دقیق و واقع گرایانه کاری غیرممکن خواهد بود. به جای اینکه از تیم بیش از حد انتظار داشته باشید، با استفاده از جلسه Release Planning میزان کار و زمان بندی را تغییر دهید.
فردریک بروکز (Fred Brooks) به وضوح اشاره می کند که استخدام نیروی بیشتر در زمانی که پروژه مشخصاً تاخیر خواهد داشت، کار بسیار اشتباهی است. در عوض رفته رفته و به محض دیدن نشانه هایی که حاکی از به تأخیر افتادن پروژه هستند، نیروی بیشتری استخدام کنید.
سرعت کاری پایدار و یکپارچه به شما کمک می کند Release ها و Iteration ها را به راحتی برنامه ریزی کنید بدون آنکه نگران Deadline باشید. پیدا کردن سرعت کاری بسیار حائز اهمیت است چرا که لازم است در تمام طول پروژه ثابت باقی بماند. از آن جایی که هر تیم با تیم دیگر متفاوت است، اینکه بخواهید به اجبار Velocity تیمی را تغییر دهید تا با تیم دیگری هماهنگ شوند اشتباه است؛ چرا که این کار در بلند مدت Velocity را کاهش می دهد. در نتیجه با Velocity تیم کنار آمده و سعی کنید واقع گرایانه برنامه ریزی کنید.