بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم

۱-۴- اسپرینت (sprint)
در اسکرام، کارها در تکرارها و دوره‌هایی انجام می‌گردد که مدت آنها حداکثر یک ماه تقویمی است. این تکرارها و دوره‌ها را اسپرینت می‌نامند (شکل زیر). کارهای انجام شده در هر اسپرینت باید منجر به خروجیِ با ارزش و ملموسی برای مشتری یا کاربر گردد.

شکل خصوصیات اسپرینت

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

۱-۵- برنامه‌ریزی اسپرینت (sprint planning)
ممکن است بک‌لاگ محصول حاوی هفته‌ها یا ماه‌ها کار باشد که معمولاً بیش از کارهای قابل انجام در یک اسپرینت است. مالک محصول، تیم توسعه و استاد اسکرام، برنامه‌ریزی اسپرینت را با هدف تعیین مهم‌ترین اقلام بک‌لاگ محصول برای انجام در اسپرینت جاری برگزار می‌کنند (شکل زیر).

شکل : برنامه‌ریزی اسپرینت

در برنامه‌ریزی اسپرینت، مالک محصول و تیم توسعه بر روی هدف اسپرینت (sprint goal) توافق می‌کنند. هدف اسپرینت بیانگر دستاوردهای مورد انتظار در پایان آن است. تیم توسعه با استفاده از این هدف، بک‌لاگ محصول را مرور و مهم‌ترین اقلام را انتخاب می‌کند. انتخاب اقلام به گونه‌ای است که تیم به صورت واقع‌بینانه و با آهنگی پایدار ( Sustainable pace) قادر به انجام آنها در اسپرینت جاری باشد. آهنگ پایدار سرعتی است که تیم توسعه با حفظ آن بتواند به راحتی برای مدت طولانی کار کند.
بسیاری از تیم‌های توسعه برای اطمینان از این که قادر به انجام کارهای تعیین‌شده هستند، هر یک از ویژگی‌ها (feature) را به مجموعه‌ای از وظایف (task) می‌شکنند. این وظایف و اقلام بک‌لاگ مرتبط با آنها، بک‌لاگ دیگری را تشکیل می‌دهند که بک‌لاگ اسپرینت (sprint backlog) نامیده می‌شود (شکل زیر).

شکل بک‌لاگ اسپرینت

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

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

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

مترجم: خانم مهندس فاطمه اردستانی

بخش اول

۱-۲- داستان کاربر به کاهش فاصله مشتری-توسعه‌دهنده کمک می‌کند
در توسعه‌ی چابک‏‏، توسعه‌دهنده موظف است به زبان کاربر صحبت کند، اما کاربر موظف به صحبت به زبان توسعه‌دهنده نیست. نکته اصلی، ارتباط مؤثر است که برای تحقق آن، نیاز به زبان مشترکی است. داستان کاربر این نقش ‏‏را بازی می‌کند چرا‏‏که کاربر و تیم فنی برداشت یکسانی از آن دارند.

بیل وِیک یکی از ابداع‌کنندگان XP، این موضوع را بدین شکل توصیف می‌کند:
زبان دست‌وپا شکسته، زبان ساده‌ای است که معمولاً برای تجارت‏‏ و توسط افرادی به‌کار می‌رود که علی‌رغم تمایل به همکاری، نمی‌توانند به زبان مادری‏‏ یکی از دو طرف با هم صحبت کنند. داستان‏‏ کاربر شبیه این زبان است. انتظار نداریم که مشتریان یا کاربران، سیستم را مانند برنامه‌نویسان بفهمند. لذا داستان کاربر، کارِ زبان دست‌وپا شکسته را می‌کند تا دو طرف تا اندازه‌ای که برای همکاری موثر لازم است، گفت‌وگو کنند و به توافق برسند.

به کمک داستان کاربر مجبور نیستیم زبان یکدیگر را با مهارتی که برای سرودن شعر و غزل لازم است، یاد بگیریم. بلکه نیازمان این است وقتی‌که درباره‌ی معامله‌ای برد-برد مذاکره می‌کنیم، همدیگر را به‌اندازه کافی درک کنیم!

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

– آنها کوتاه، روان و قابل فهم برای توسعه‌دهندگان، ذینفعان و کاربران هستند.

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

– برآورد آنها نسبتاً آسان است، در نتیجه حجم کار لازم برای پیاده‌سازی کارکردهای سیستم می‌تواند به‌سرعت تعیین گردد.

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

– آنها در ابتدای پروژه دارای جزئیات نیستند بلکه جزییات آنها در وقت مناسب(به‌موقع ) بیان می‌شود و به همین دلیل است که از تفصیل زودهنگام، تأخیر در توسعه‏‏، افزایش موجودی نیازمندی‏‏ها و اعلام قیدهای بیش‏ ‏‏‏‏‏از حد برای راه‌حل اجتناب می‌کنند.

– خیلی کم پیش می‌آید که نیاز داشته باشیم آنها را نگهداریم و از این‌رو می‌توان آنها را بعد از پیاده‌سازی با خیال راحت دور انداخت.

– داستان کاربر و کدی که به‌سرعت برای آن نوشته می‌شود، ورودیِ تدوین مستنداتی است که به تدریج و همزمان با کد کامل می‌شوند.

گزیده:
مراقب باش که نیروهایت را بر سر مسایل پراکنده از دست ندهی. همیشه تلاش کن که آنها را متمرکز کنی. گوته
مرجع: اس.جی.

برچسب‌ها: چابک Agile, نیازمندی‌ها Requirements

ضمن تشکر از دوست گرامی جناب آقای مهندس مهدی نگاهی، ترجمه مقاله “در آغوش گرفتن تغییرات با XP”
یا Embracing Change with Extreme Programming نوشته Kent Beck را می‌توانید از اینجا دریافت فرمایید.

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

برچسب‌ها: چابک Agile

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

مجموعه جدید مقاله‌ها، به حوزه نیازمندی‌ها در متدهای چابک اختصاص داده شده است. مرجع فعلی مطالب، کتاب Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise نوشته‌ی Dean Leffingwell است.

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

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

فصل ششم
۱-مقدمه
۱-۱-مروری بر داستان کاربر
۱-۲-داستان کاربر به کاهش فاصله مشتری-توسعه‌دهنده کمک می‌کند
۱-۳-داستان کاربر نیازمندی نیست
۲-شکل داستان کاربر
۳-INVEST در داستان‌های کاربر خوب
۴-تقسیم داستان‌های کاربر
۵-اسپایک‌ها(Spike)
۶-مدلسازی داستان با کارت‌های نمایه
۷-خلاصه فصل

۱-مقدمه
در فصل سوم، «نیازمندی‌های چابک برای تیم»، مفاهیم و روابط بین فرآورده‏های اصلی یعنی بک‏لاگ، داستانهای کاربر و وظیفه‏ها بیان گردیدند که توسط تیمهای چابک برای تعریف، ساخت و آزمون سیستم استفاده می‏شوند. در آنجا اشاره شد که داستان کاربر اسب بارکش توسعه‌ی چابک و وسیله‏ای برای انتقال و تحویل «ارزش» به مشتری است. همچنین داستان کاربر استعاره‏ای(metaphor) از رویکرد تدریجی و ارزش‏آفرینی‏ برای کاربر است یعنی این که:

درمورد آن‏چه که برای کاربر ارزشمند است، داستانی تعریف کنید؛
آن را در یک تکرار کوتاه پیاده‏سازی و آزمایش کنید؛
سپس آن را به کاربر نمایش یا تحویل دهید؛
تا ابد این کار را تکرار کنید!

شکل ۶-۱ خلاصه‏ای از فرآورده‏های مرتبط با نیازمندی‏ها را نشان می‏دهد که برای تحقق این رویکرد لازمند.

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

۱-۱-بازنگری داستان کاربر
به بخشی از تأثیرات اسکرام در توسعه تجربه‏های سازمانی چابک در فصلهای گذشته اشاره شد. به عنوان نمونه می‏توان به نقش «مالک محصول» اشاره کرد که بخش‏ مهمی از تجربه‌های حوزه نیازمندی‏ است. اما ابداع داستان کاربر را به متد XP مدیونیم و این طرفداران XP بودند که آن را بسط و گسترش دادند. بک(Beck) و فاولر(Fowler) در [۲۰۰۵] می‏نویسند:
«داستان، واحد کارکرد پروژه‏‏های مبتنی بر XP است. پیشرفت پروژه با تحویل کد هر داستان که آزمایش‏ و یکپارچه شده‏، نشان داده می‏شود. داستان باید قابلِ فهم برای مشتریان و توسعه‏دهندگان؛ آزمون‏پذیر؛ ارزشمند برای مشتریان؛ و به اندازه‏ای کوچک باشد که برنامه‏نویس بتواند تعدادی از آنها را در هر تکرار انجام دهد.»

با این حال، هر چند سرآغاز داستان کاربر از XP است، اما از جمله موضوعاتی است که درباره‏ی آن در متدولوژی‏ها اتفاق‏نظر وجود دارد. به همین دلیل، هم‏اکنون داستان‏ کاربر بخشی از دوره‏های آموزشی اسکرام به عنوان ابزاری جاافتاده برای ایجاد بک‏لاگ محصول و تعریف اسپرینت است. بخش عمده‏ای از یکپارچه‏سازی داستان‏کاربر با اسکرام توسط مایک کوهن(Mike Cohn) انجام شده که از وی سپاسگزاریم. او یکی از فعالان انجمن‏های اسکرام و کسی است که مفهوم داستان کاربر را در کتابش [۲۰۰۴] بسط و گسترش داد.

به دلایلی، داستان کاربر را به شکل ساده‏ی زیر تعریف می‏کنیم:
«داستان کاربر شرح کوتاهی است از انگیزه‌ی کاربر در مورد کاری که انتظار دارد سیستم برایش انجام دهد».

اغلب داستان‏های کاربر در XP توسط مشتری نوشته می‏شود که باعث حضور مستقیم وی در فرایند توسعه می‏شود. در اسکرام نیز اغلب مالک محصول داستانهای کاربر را با دریافت اطلاعات از مشتریان، ذینفعان و تیم می‏نویسد. عملاً هر عضو تیم که درباره‏ی قلمروی مسأله دانش کافی داشته باشد، می‏تواند داستانهای کاربر را بنویسد، اما وظیفه‏‏ی پذیرش و اولو‏یت‏دهی آنها با مالک محصول است.

داستان کاربر ابزاری برای تعریف رفتار سیستم است به‏گونه‏ای که برای کاربر و توسعه‏دهنده قابل فهم باشد. با به‏کارگیری داستان کاربر، کارها براساس ارزش تعیین‏شده‏‏ی کاربر انجام می‌شوند و نه براساس روش رایجِ ساختار شکستِ کارکردی(functional breakdown structure) . از طرف دیگر داستان کاربر، رویکردی سبک و مؤثر برای مدیریت نیازمندی‏ها نیز فراهم می‏کند.

داستان کاربر شرح کوتاهی از کارکرد سیستم است که بر روی یک کارت نمایه (index card) یا احتمالاً در یک ابزار نوشته می‏شود. در ساده‏‏ترین شکلِ بک‏لاگ، داستان‏ها فقط فهرستی از کارهایی‌اند که سیستم باید برای کاربر انجام دهد. به عنوان مثال:
○ ورود به صفحه‏ی پرتال پایش انرژی
○ دیدن مصرف انرژی روزانه
○ کنترل نرخ هزینه‏ی فعلی برق

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

گزیده:
انسانها ابزارِ ابزارهای خود شده‌اند.
اچ دی تورو

برچسب‌ها: چابک Agile, نیازمندی‌ها Requirements

مترجم: مهندس شهاب‌الدین فرحبخش
بخش اول
بخش دوم

۳-۲-تیم توسعه

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

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

۳-فعالیتها و فرآورد‌ه‌های اسکرام

مالک محصول چشم‌اندازی از محصول در اختیار دارد. از آنجایی که این چشم‌انداز می‌تواند خیلی بزرگ باشد، آن را به کمک فعالیتی به نام «آماده‌سازی»(Grooming) به مجموعه‌ای از ویژگی‌ها شکسته و در فهرست اولویت‌بندی شده‌ای به نام بک‌لاگ محصول (Product Backlog) گردآوری می‌کنند.

اسپرینت با برنامه‌ریزی شروع می‌شود، با انجام کارهای توسعه در طول اسپرینت که اجرای اسپرینت نامیده می‌شود، ادامه می‌یابد و با بازنگری (Sprint Review) و بازاندیشی(Sprint Retrospective) اسپرینت به پایان می‌رسد.

تعداد اقلام بک‌لاگ محصول(Product Backlog Item) بیشتر از چیزی است که تیم توسعه قادر به انجام آنها در یک اسپرینت باشد. به همین دلیل در ابتدای هر اسپرینت، تیم توسعه تعیین می‌نماید که کدام یک از اقلام بک‌لاگ محصول را می‌تواند تا پایان اسپرینت انجام دهد. این فعالیت برنامه‌ریزی اسپرینت(Sprint Planning) نامیده می‌شود.

تغییرات سال ۲۰۱۱ «راهنمای اسکرام»(شوئبر و سادرلند ۲۰۱۱) منجر به بروز این بحث گردید که واژه مناسب برای توصیف نتیجه‌ی برنامه‌ریزی اسکرام چیست: پیش‌بینی یا تعهد؟

گزیده:
پسرخاله: یه روز رفتم نونوایی، نونوا گفت هر کسی اومد بگو پشت سرت وا نسه، نون نمی‌رسه؛
منم هر کی اومد گفتم بیا جلوی من واسا؛ پشت سرم نون نمی‌رسه….
کلاه قرمزی

برچسب‌ها: Scrum اسکرام, Agile چابک

مترجم: مهندس شهاب‌الدین فرحبخش
بخش اول

۱-۲-مالک محصول(Product Owner)
مالک محصول، نفر اصلی و صاحب صلاحیت در رهبری محصول است. وی تنها مرجع تصمیم-گیری برای انتخاب ویژگی‏های محصول و ترتیب ساخت آنها است. مالک محصول، چشم‏انداز روشنی از کار تیم اسکرام را با همکاری ذینفعان تهیه و همواره به‏روز نگه‏ می‏دارد. به همین دلیل، وی مسئول موفقیت کلی راهکار است که می‏تواند توسعه سیستمی جدید یا نگهداری سیستم موجود باشد.

مهم‏نیست که هدف، تولید محصولی برای مشتریان خارجی است یا برنامه‏ای برای داخل سازمان. در هر صورت وظیفه مالک محصول، اطمینان از انجام باارزش‏ترین کار ممکن -شامل کارهای فنی- است. مالک محصول برای کسب اطمینان از برآورده شدن سریع خواسته‏هایش توسط تیم، فعالانه با راهبر اسکرام و تیم توسعه همکاری می‏کند و باید برای پاسخگویی به پرسش‏های آنان در زودترین زمان ممکن در دسترس باشد.

۲-۲-راهبر اسکرام( SCRUM Master)
راهبر اسکرام به کسانی که در حال یادگیری و پذیرش ارزشها، اصول و تجربه‏های اسکرام هستند، کمک می‏کند. وی مانند یک مربی، رهبری فرآیند را بر عهده دارد و به تیم اسکرام و سازمان کمک می‏کند که روشی مبتنی بر اسکرام با کارایی بالا و خاص سازمان ایجاد کنند. همزمان با این کار، راهبر اسکرام به سازمان در رفع چالش‏های ناشی از پذیرش و بکارگیری اسکرام نیز کمک می‏کند.

وی در نقش تسهیل‏کننده(Facilitator)، به تیم در رفع مشکلات ناشی از اجرای اسکرام و ایجاد بهبود در آن کمک می‏کند. وظیفه حفاظت از تیم در برابر عوامل مزاحم بیرونی بر دوش راهبر اسکرام است. وی با برداشتن موانعی که بهره‏وری تیم را کاهش می‏دهد، نقش رهبری‏اش را ایفا می‏کند(در صورتی که افراد تیم قادر به رفع آنها نباشند).

راهبر اسکرام مجاز به اعمال کنترل بر تیم نیست، از این رو، این نقش به نقش‏های سنتی مدیر پروژه یا مدیر توسعه شباهتی ندارد. وی مانند یک رهبر عمل می‏کند، نه یک مدیر.

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

برچسب‌ها: Scrum اسکرام, Agile چابک

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

تغییر نیازمندها
غول [بزرگ‌ترین و ترسناک‌ترین] مشکلات بسیاری از روشهای توسعه نرم‌افزار، فقط در حد یک مشکل ساده در XP است. با به کارگیری دستورالعمل «انجام طراحی فقط برای مسأله‌های امروز»، سیستمی که بر اساس XP در حال ساخت است، روز بعد برای پیمودن هر مسیری آمادگی دارد. انجام کارهای مشابه با کارهای قبلی، به دلیل ماهیت تکنیک بازسازی( Refactoring) در برآورده کردن اصل «یک بار و فقط یک بار»، ساده تر خواهد بود. لازم به یادآوری است که کارهای مشابه در یک پروژه زیاد است. با این حال، با اعلام یک نیازمندی اساسی و متفاوت-نامشابه-، برای انجام آن مجبور نیستید پای‌بند بسیاری از مکانیزمهای قبلی باشید.
در ابتدا درکی از میزان توانایی XP برای مواجهه با تغییر نیازمندی‌ها نداشتم. در اولین نسخه XP، تعیین این که هر داستان در کدام تکرار انجام شود، بخشی از برنامه‌ریزی انتشار(Release Planning) بود. تیم به مرور به این نتیجه رسید که می‌توان با کاهش زمان برنامه‌ریزی به نتایج بهتری دست یافت؛ کافی است از مشتری بخواهید فقط داستانهای تکرار جاری را انتخاب کند. در این روش، با شناسایی هر داستان جدید، نیازی نیست ترتیب داستانهای موجود در تکرارهای باقی‌مانده را بهم ریخته و دوباره مرتب کنید تا تکرار انجام داستان جدید مشخص شود. تنها کاری که باید انجام دهید، قراردادن داستان جدید در بین داستانهای انجام‌نشده است. یک یا دو هفته بعد، اگر داستان جدید هنوز هم برای مشتری اهمیت داشته باشد، وی آن را برای انجام در تکرار پیش‌رو انتخاب خواهد کرد.
(مترجم:
فرض کنید که در سه تکرار پیش رو، قرار است داستانهای زیر انجام شود(اندازه هر داستان جلوی آن مشخص شده است). سرعت تیم برای هر تکرار را ۷ فرض کنید.
تکرار ۱:
داستان A‏ = ۳ داستان B‏ = ۴
تکرار ۲:
داستان C‏ = ۵ داستان D‏ = ۲
تکرار ۳:
داستان E‏ = ۲ داستان F‏ = ۳ داستان G‏ = ۲

حال اگر داستان Z با اندازه ۲ به تازگی شناسایی شود و مشخص گردد باید که بعد از داستان A انجام شود، ترتیب انجام داستان‌ها و تکرارهای متناظر آنها دچار تغییر می‌شود که در زیر نمایش داده شده است. این تغییر فقط یک جابه‌جایی ساده نیست، بلکه واقعاً به‌هم ریختن داستان‌ها و مرتب‌سازی دوباره است(به ترتیب حروف الفبای انگلیسی در بالا و پایین دقت کنید).
تکرار ۱:
داستان A‏ = ۳ داستان Z‏ = ۲ داستان D‏ = ۲
تکرار ۲:
داستان B‏ = ۴ داستان F‏ = ۳
تکرار ۳:
داستان C‏ = ۵ داستان E‏ = ۲
تکرار ۴:
داستان G‏ = ۲
)

این روش برنامه‌ریزی که در آن هر بار فقط تکرار بعدی برنامه‌ریزی می‌شود، موجب خودمانایی (self-similarity) مطلوبی می‌گردد. بدین شکل که در بازه‌ ماهانه و سالانه، با دو دسته داستان روبرو هستید: داستانهای انتشار جاری و داستانهای باقی‌مانده برای انتشارهای بعدی. در بازه هفتگی و ماهیانه نیز با دو دسته داستان روبرو هستید: داستانهای تکرار جاری و داستان‌های باقی‌مانده از انتشار جاری. در بازه روزانه و هفتگی هم با دو دسته کار(وظیفه) سروکار دارید: کارهای در دست انجام و کارهای باقی‌مانده از تکرار جاری. همچنین در بازه دقیقه و روزانه نیز با دو دسته مورد آزمون روبرو هستید: موردهای آزمون در دست انجام و موردهای آزمون باقی‌مانده.

Ron Jeffries

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

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