فصل ۶ — XP: ارزشها، اصول و Mindset پذیرش تغییر
تیمی که XP را فقط در سطح «better-than-not-doing-it» اجرا میکند متوجه میشود Pair Programming جلوی ورود بعضی Defectها را میگیرد و TDD و Continuous Integration بعضی Defectهای اضافهشده را پیدا میکنند. اما چنین تیمی Practiceها را معمولاً «nice-to-have» میبیند. حداقل چیزی که برای بیروندادن Project لازم است نوشتن Code است؛ بنابراین وقتی Schedule عقب میافتد وسوسه میشوند همهٔ «اضافهکاریها» را حذف کنند: «دیر کردهایم، Time برای Unit Test نداریم» یا «اگر Manpower داشتیم دو Programmer روی هر Task میگذاشتیم، ولی برای Deadline نمیشود.»
این Mindset در برخورد نخست با XP غیرعادی نیست. Problem این است که Practiceهای مهم شبیه Diet یا Exercise میشوند: همه قبول دارند عالیاند، ولی Busy Life بهانهای برای انجامندادنشان میشود. اگر Practice Optional حس شود، درست وقتی Project سخت میشود حذف خواهد شد.
به همین دلیل Checklistکردن XP یا محاسبهٔ «چند درصد XP را پیاده کردهایم» بر اساس تعداد Practiceهای Tickخورده ضدproductive است. Practice وسیله است، نه Goal نهایی. Checklist Mindset علامت قرمز بزرگی است که Team هنوز برای XP آماده نیست.
پس چه چیزی باعث میشود Team Practiceهای XP را First-class Citizen بداند، یعنی جزء ضروری ساخت Software عالی، نه Add-on اختیاری؟
Mindset مؤثر از XP Values شروع میشود
Teamی با Mindset درست، Practice خوب را بدون Nagging به کار میگیرد، چون میداند نتیجهاش Software بهتر است. XP مثل Scrum پنج Value دارد. این Valueها کمک میکنند Team از اجرای سطحی فراتر برود و Practice را راه طبیعی ساخت Code خوب ببیند.
ارزشهای XP
Communication
هر عضو Team از Workی که دیگران انجام میدهند آگاه است.
Simplicity
Developerها روی سادهترین و مستقیمترین Solution ممکن تمرکز میکنند.
Feedback
Test دائمی و Feedback Loopها Quality محصول را زیر کنترل نگه میدارند.
Courage
هر عضو بر بهترین Choice برای Project تمرکز میکند، حتی اگر لازم باشد Solution ناموفق را دور بیندازد یا مسیر دیگری انتخاب کند.
Respect
هر عضو برای Project مهم و باارزش است.
اینها Abstract و جذاب به نظر میرسند؛ چه کسی میتواند مخالفشان باشد؟ ممکن است کمی بعد بفهمید با بعضیشان راحت نیستید و اشکالی ندارد، اگر ذهن باز نگه دارید.
جادهای با نیتهای خوب
وقتی Team XP را Adopt میکند همه Optimistic هستند. از Bug و Headache خسته شدهاند و Practiceها به نظر میرسد مشکل Quality را بالاخره حل میکنند. سپس Real Life وارد میشود.
Pair Programming Intuitively گران به نظر میرسد: چرا کسی کنار شما بنشیند و Thought Process شما را تماشا کند؟ اگر تنها Benefit یک جفت چشم اضافه برای Catch Bug باشد، Code Review بعد از نوشتن Code تقریباً همان کار را ارزانتر انجام میدهد. وقتی Deadline نزدیک است بهسادگی میگویید «Code Review تقریباً همان Pairing است؛ پس یک جورهایی Pair میکنیم.»
برای تقریباً هر XP Practice Shortcut مشابهی وجود دارد:
- لازم نیست Sit Together؛ Daily Meeting کافی است.
- لازم نیست اعضا در Sandbox دائماً Integrate کنند؛ Server خودکار انجام میدهد.
- لازم نیست Test را اول بنویسیم؛ بعداً هم Test مینویسیم و Bug را Catch میکنیم.
همهٔ اینها تا حدی درستاند و بهتر از هیچکاریاند، بنابراین نتیجهٔ «better-than-not-doing-it» میدهند؛ اما Intention و Mindset را عوض نمیکنند.
Kent Beck میگوید Practice بدون Value «barren» میشود. همانطور که Scrum بدون Self-organization و Collective Commitment فقط ظاهر Scrum را دارد، XP Practice هم فقط Extra Eyeball یا Extra Test نیست؛ باید XP Values را وارد Project کند.
مبتدیها معمولاً Values را رد میکنند و مستقیم به Practice میروند، چون Practice Concrete است، قابل تصور است و میتوان یک مورد را بدون تغییر کل Mindset به Project اضافه کرد. Values Abstractترند و روی همهٔ Project و شیوهٔ فکرکردن افراد اثر دارند. فهم Values بدون تجربهٔ Practice سخت است و همین یک Catch-22 میسازد.
Justin، Danielle و Team Fantasy Basketball دقیقاً همین خطا را کردند. مستقیم Practice اضافه کردند، بیآنکه Values را بفهمند.
Communication در داستان آنها
Justin و Danielle دربارهٔ کنارگذاشتن Practiceهایی که لازم میدانستند حرف نزدند. مهمتر، Status واقعی Work را هم به Bridget نگفتند. Bridget هم بعداً میتواند آنها را بابت دیر خبر دادن Blame کند.
Simplicity
Code Justin پیچیده و Convoluted شده بود. میتوانست بهتر بنویسد، اما احساس میکرد Time ندارد.
Feedback
با توقف Pair Programming تقریباً Interactionشان هم قطع شد. اگر Danielle زودتر Code او را دیده و Feedback داده بود شاید Code آنقدر Mess نمیشد. Informative Workspace هم Data نامربوطی میداد؛ دانستن «چند درصد XP هستیم» Software را بهتر نمیکند.
Courage
وقتی Team میداند «بههیچوجه» On time نمیرسد، گفتن Truth به Manager Courage میخواهد، مخصوصاً اگر Messenger تنبیه شود. Justin و Danielle این Courage را نشان ندادند.
Respect
از بیاحترامیهای بزرگ حرفهای این است که از Team بخواهید Schedule ناممکن را تحویل دهد. Bridget بارها Deadline بیش از حد Aggressive گذاشته بود و حتی همیشه کنار Team نمیماند تا Cost آن را ببیند.⁵
⁵ نویسندگان مثال میزنند که مطالبهٔ Weekend Work از Team و رفتن Manager به Vacation نمونهای از همین بیاحترامی است.
Practice چگونه Value را آموزش میدهد؟
اگر Continuous Integration را واقعی Adopt کنید، شاید یک Developer مدام Integration را عقب بیندازد چون Task فعلی را مهمتر میبیند. Team مجبور میشود دربارهٔ اهمیت CI با او Communication کند. او باید Respect برای Need تیم را بالاتر از Preference فردی بگذارد. Failure زودهنگام Integration Feedback میدهد، و اگر Problem ناشی از Change همتیمی باشد گفتوگوی مستقیم با او Courage میخواهد.
یعنی Practice فقط Mechanic نیست؛ Valueها را تمرین میدهد و Mindset را شکل میدهد.
برای سنجش آمادگی XP میتوان بازی «Are you OK with?» را انجام داد:
- آیا Team واقعاً با ساخت Software و دورریختن آن وقتی فهمید کار نمیکند راحت است؟ Boss چطور؟
- اگر Boss Deadline را Tightتر کند، آیا Team واقعاً باور دارد نوشتن Unit Test سریعترین راه رسیدن است، حتی اگر Code بیشتری نوشته شود؟
- اگر Junior Programmer Task را بگیرد، آیا Team Authority تکمیلش را به او میدهد؟ اگر Approachش را قبول نداشته باشند چه؟ اگر فرد دیگری Faster باشد؟ آیا Failure و Learning او قابل قبول است؟
اگر پاسخها ناراحتکنندهاند، همانها نقطهٔ شروع کار روی Mindset هستند.
پردهٔ سوم: Momentum تغییر میکند
Danielle به Justin گفت اتفاق عجیبی افتاده. Justin روی Algorithm Ranking بازیکنان با چند Statistic کار میکرد. Danielle یادآوری کرد Pair Programming قبلیشان تقریباً بیفایده بود: یکی Code مینوشت و دیگری فقط نگاه میکرد؛ Line Count per Hour هم تقریباً نصف شده بود و Pairing بهتدریج متوقف شد.
اما Danielle بهتازگی با Tyler، Graduate تازهکار ششهفتهای، Pair کرده بود. هدف اولیه فقط این بود که سریع او را با Code آشنا کند. وقتی به Player Data Cache رسیدند ــ بخشی پیچیده که Justin و Danielle برای Performance Problem ساخته بودند ــ Tyler پرسید چرا Key و Hash همراه Player Object ذخیره نمیشود.
Justin لحظهای خشکش زد و Design Cache را در ذهن مرور کرد: «صبر کن... این یعنی Bad Data داخل Cache خواهیم داشت.» Danielle گفت دقیقاً. Test نشان داد Bug جدی است؛ Fix الآن آسان بود اما اگر دیر کشف میشد Player گاهی Statistic اشتباه میگرفت و شاید تا Production هم دیده نمیشد.
Justin به برگهٔ XP Values روی دیوار اشاره کرد که مدتها نادیده گرفته بود: «فکر کنم الآن چیزی دربارهٔ Communication فهمیدم.» Danielle افزود: «و Respect. از این به بعد حتماً نظر Tyler را میپرسم و میخواهم Pairing با او را ادامه دهم.»
XP Principles کمک میکنند Change را Embrace کنیم
بین Valueهای Broad و Practiceهای مشخص Gap وجود دارد. XP مجموعهای از Principle دارد که کمک میکند Valueها در Project واقعی به Practice وصل شوند. هدف Memorizeکردن List نیست؛ این Principleها Detail بیشتری دربارهٔ Mindset XP میدهند.
Humanity
Software را انسانها میسازند. باید میان Need هر Team Member و Need Project Balance برقرار شود.
Economics
همیشه کسی Cost Software Project را میپردازد؛ همه باید Budget را در نظر بگیرند.
Mutual Benefit
Practiceهایی پیدا کنید که همزمان برای Individual، Team و Customer سود داشته باشند.
Self-similarity
Pattern Monthly Cycle، Weekly Cycle و Daily Cycle شبیه یکدیگر است.
Improvement
امروز بهترین کاری که میتوانید انجام دهید و همزمان بدانید فردا برای بهترشدن چه باید کرد.
Diversity
Opinion و Perspectiveهای متفاوت کنار هم Solution بهتر تولید میکنند.
Reflection
Team خوب دائماً میداند چه چیزی در Process کار میکند و چه چیزی نه.
Flow
Continuous Delivery یعنی Flow پیوستهٔ Development Work، نه Phaseهای مجزا.
Opportunity
هر Problem فرصتی برای یادگیری چیز جدید دربارهٔ Software Development است.
Redundancy
چیزی که در نگاه اول Waste به نظر میرسد میتواند از Quality Problem بزرگ جلوگیری کند.
Failure
از Failure زیاد میآموزید؛ امتحانکردن چیزی که جواب نمیدهد قابل قبول است.
Quality
با قبول Product کمکیفیت نمیتوانید Faster Deliver کنید.
Accepted Responsibility
اگر کسی مسئول چیزی است، باید Authority لازم برای انجامش را هم داشته باشد.
Baby Steps
برای Adoptکردن Practice تازه، قدم کوچک در Direction درست بردارید، نه Wholesale Change.
چرا Principleها مهماند؟
مبتدی ممکن است مثل Values، Principleها را هم رد کند و مستقیم به Practice برود. Checklist Adoption آسان است چون لازم نیست بپذیرید Problemی در Culture یا Project دارید. میتوانید بگویید «خوبیم، فقط میخواهیم بهتر شویم» و Practiceها را یکییکی Tick کنید.
اگر Goal فقط «Adopt کامل Practiceها» باشد Checklist جواب میدهد؛ اگر Goal Software بهتر باشد، Fail خواهد شد. در بهترین حالت نتیجهٔ سطحی میگیرید و بهمرور Practiceها محو میشوند و Team به روش قدیمی برمیگردد. بعد افراد Methodology را Blame میکنند: «این همه وقت برای Test یا Pairing یا Daily Scrum گذاشتیم و چیز زیادی نگرفتیم؛ پس Methodology کار نمیکند.»
Principleها Self-reflection میخواهند و Team را مجبور میکنند از بیرون به شیوهٔ کار خودش نگاه کند. این گاهی ناراحتکننده و حتی خطرناک است. ممکن است Principle «Failure» را ببینید و بفهمید Culture شما Failure را تحمل نمیکند؛ اعتراف به Problem باعث Yellکردن Boss یا آسیب شغلی میشود. در بعضی Companyها Change Culture واقعاً ممکن است، در بعضی ممکن است شخصی که موضوع را مطرح کرده Fired شود.⁶ همین یکی از دلایلی است که «Agile سخت است».
⁶ نویسندگان هشدار میدهند Adoption یک Principle در Teamی ممکن است عالی باشد و در Team دیگر حتی به اخراج منجر شود؛ نباید تیمهایی را که در Agile مشکل دارند مسخره کرد.
شکل ۶-۴ — Scrum و XP مشابهاند، اما یکسان نیستند.
XP Principles و Planning
Kent Beck میگوید Role در Mature XP Team ثابت و Rigid نیست. ابتدا Role ثابت میتواند Habit جدید را آموزش دهد ــ Technical Person تصمیم Technical و Business Person تصمیم Business ــ اما پس از ایجاد Mutual Respect، Role ثابت مانع این Goal میشود که هرکس بهترین Contribution خود را ارائه کند.
Scrum و XP Values مشترک زیادی دارند اما Difference مهم هم دارند. Scrum Product Owner و Scrum Master دارد؛ Mature XP Team Role ثابت ندارد. این Difference به فهم Planning XP کمک میکند.
Scrum مقدار زیادی Planning دارد: Product Backlog برای Big Picture، Sprint Backlog برای Iteration و Daily Scrum برای Collaboration روی Plan. XP هم Quarterly Cycle، Weekly Cycle و Informative Workspace/Task Board دارد، اما Planning و Tracking آن دقیقاً Scrum نیست.
چرا XP Role ثابت را رد میکند؟
اصلهای Opportunity و Diversity جدی گرفته میشوند. اگر کسی را از Role بیرون نگه دارید، ممکن است Opportunity Contribution او را از دست بدهید. Perspective تازه نیز میتواند Problem سخت را حل کند. Technical Developer شاید Idea عالی برای User داشته باشد و Project Manager شاید بهخاطر Perspective متفاوت Input ارزشمند Architecture بدهد.
Danielle وقتی با Tyler تازهکار Pair شد Diversity را تجربه کرد. به همین دلیل بسیاری از XP Teamها Pair Partner را Rotate میکنند؛ Fresh Eye بیشتر Problem میگیرد و Innovation میآورد. Humanity هم وارد میشود: Interaction دائم، Feedback و Criticism را به رفتار عادی تبدیل میکند و Junior Member Courage بیشتری برای حرفزدن با Senior پیدا میکند.
این Principleها با Communication، Respect و Courage Pair Programming را مؤثر میکنند.
XP Practice مستقلی مثل Retrospective Scrum ندارد، چون Improvement و Reflection در خود Work پخش شدهاند. Team مراقب Navel-gazing یا Reflection بیش از حد است. Pair Programming فرصت میدهد Developer حین انجام Work دربارهٔ Work حرف بزند. Baby Steps نیز میگوید بهجای Goal «همهٔ XP را Adopt کنیم» بگویید «Pair Programming را شروع کنیم و هر روز دربارهٔ Improvement حرف بزنیم.»
Principle و Practice یکدیگر را توضیح میدهند
XP هم مثل Scrum Story استفاده میکند و Format جهانی تحمیل نمیکند. ممکن است Story به شکل Free-form Sentence باشد و Estimate Hour روی Card نوشته شود.
شکل ۶-۵ — XP Team همان Storyهای Scrum را استفاده میکند، اما Value و Principle خودش را بر آن اعمال میکند.
برای یک Story، Principleها چنین دیده میشوند:
- Economics: Customer Story بعدی را انتخاب میکند تا Team روی Highest-value Work بماند.
- Failure: Story کوچک و Self-contained است، سریع به Customer میرسد و اگر Wrong باشد Change سریع انجام میشود.
- Accepted Responsibility: Programmer Card را خوانده و Estimate داده، پس مسئول Work پذیرفتهشده است.
- Communication: Story با زبان User نوشته میشود تا Prioritization آسان شود.
- Quality: از ابتدا فکرکردن به Test، Product باکیفیتتر میدهد.
Feedback Loopها
Scrum و XP هر دو Feedback را ارزشمند میدانند. Openness در Scrum و Communication در XP Mindset مشابهی دارند. XP با Weekly Cycle Loop را کوتاهتر میکند. Team برای Iteration مؤثر باید فعالانه Need و Value User را بفهمد و مرتب روی وضعیت Project Reflection کند. Sit Together و Osmotic Communication Feedback را در Team پخش میکنند.
وقتی این عناصر کنار هم قرار گیرند، Flow شکل میگیرد: مسیر مستقیم و کارآمدی که جریان دائمی Software با Function و Quality بالا تحویل میدهد. Sit Together، Osmotic Communication، Feedback Loop، Communication و Reflection با Design/Coding خوب ترکیب میشوند. Team Bottleneck را زودتر میبیند و با هم حذف میکند تا Flow آزادتر شود.
شکل ۶-۶ — وقتی Team Mindset درست XP را دارد، Practiceها طبیعیترین و مؤثرترین راه ساخت Software احساس میشوند.
Flow یکشبه ساخته نمیشود. Baby Step و Improvement لازم است. اگر Team با Pair Programming راحت نیست، دقیق بررسی کنید کدام «Are you OK with?» ناراحتکننده است، دربارهاش حرف بزنید و Goalهای کوچک برای کاهش آن ناراحتی بسازید. اگر یک Practice فعلاً ناممکن است از Practice دیگری شروع کنید، اما Practice «barren» اجرا نکنید؛ Values و Principles را جدی نگه دارید و بعداً ممکن است Mindset تغییر کرده باشد.
پرسشهای متداول
چرا Programmer باید این همه Test بنویسد؟ مگر QA ارزانتر برای Catch Bug نداریم؟
Test-first Programming فقط افزودن Test نیست. اگر TDD ناراحتتان میکند، بررسی کنید کدام Value یا Principle با Mindsetتان Clash دارد. شاید با Quality مشکل دارید، چون XP میگوید همهٔ افراد مسئول Quality هستند؛ نمیتوان Code را از روی دیوار به Tester انداخت و Responsibility Bug را واگذار کرد. یا شاید Redundancy ناراحتتان میکند چون Test را Duplicate Code میبینید.
نوشتن Unit Test Time میگیرد و Developer بیتجربه ممکن است آن را Waste یا کاری پایینتر از شأن خود بداند.⁷ اما وقتی یک Unit Test Fail میشود و Bug بدی را در چند ثانیه آشکار میکند که وگرنه ساعتها Debug میخواست، Skeptic کمکم «test infected» میشود و TDD برایش راه طبیعی ساخت Software است.
مهمتر، فصل ۷ نشان میدهد Test-first Design خود Software را تغییر میدهد. TDD فقط Bug را Catch نمیکند؛ کمک میکند Software از ابتدا متفاوت و بهتر Design شود.
⁷ نویسندگان با طنز میگویند چنین Developerی عملاً میگوید «وقت ندارم Bug پیدا کنم؛ خیلی مشغول Injectکردنشان هستم!»
XP برای Programmerی که Ticket روزانه میخواهد خیلی Loose به نظر میرسد. چطور بفهمم Task بعدی چیست؟
اگر به Tracking System یا Gantt عادت دارید، List Taskهای روزانه حس Progress و Structure میدهد. در Command-and-control کسی Requirements را از قبل به WBS یا Ticket شکسته است.
XP این Up-front Planning تفصیلی را انجام نمیدهد. Theme و Story در Quarterly Cycle مطرح میشوند، اما Iteration یکهفتهای است و Task فقط Week-by-week Plan میشود. این همان بخش «Extreme» است: تصمیم را تا Last Responsible Moment جلو میآورد.
Pairها هم مرتب Switch میشوند و اینکه چه کسی Task را انجام دهد تا لحظهٔ انجام قطعی نیست. بهجای Daily Meeting Scrum برای Self-assign Task، XP بهخاطر Iteration کوتاه و Feedback Loop کوتاه میتواند Taskها را در یک Queue بگذارد و Pair آماده، Task بعدی را Pull کند.
آیا Pullکردن Task بدون Assignment دقیق Expertise را هدر نمیدهد؟
نه. Team Robot نیست. ابتدای Weekly Cycle Story به Task شکسته میشود و پایان Cycle Working Software «Done Done» تحویل میشود. Taskها در Queue میمانند و Pair بعدی آنها را Pull میکند. اگر Expertise خاص لازم باشد Pair میتواند عوض شود: فرد Expert با کسی که میخواهد یاد بگیرد Pair میشود. بار بعد Team دو نفر Expert دارد، نه یک نفر.
Kent Beck میگوید بعد از ایجاد رابطهٔ Mutual Respect، Fixed Role مانع بهترین Contribution میشود. Programmer میتواند Story بنویسد اگر بهترین فرد برای آن است؛ Project Manager میتواند Architecture Improvement پیشنهاد دهد اگر Insight دارد.
دو Principle مهم اینجا:
- Accepted Responsibility: Pair با گرفتن Task متعهد به تکمیل میشود و اگر Problem دارد Help میخواهد، حتی اگر Ego آسیب ببیند.
- Opportunity: هر Task فرصتی برای Learning Technology یا Domain جدید است و Knowledge را در Team پخش میکند.
Corollary Practices و Collective Ownership
علاوه بر 13 Primary Practice، XP یازده Corollary Practice دارد:
- Real Customer Involvement: آوردن Customer به Quarterly/Weekly Planning و واقعاً گوشدادن.
- Incremental Deployment: Deploy قطعههای کوچک، نه یک Big-bang Deployment.
- Team Continuity: Team مؤثر را کنار هم نگه دارید.
- Shrinking Teams: با افزایش Productivity بهجای افزودن Work، یک عضو را آزاد کنید تا XP Culture را به Team دیگر ببرد.
- Root-cause Analysis: وقتی Problem رخ داد، Cause، Causeِ Cause و Upstream Source را پیدا و حذف کنید.
- Shared Code: همه با هر بخش Code راحتاند و Ownership جمعی است.
- Code and Tests: Team Code و Test را Maintain میکند؛ Documentation تا حد ممکن از Codebase Generate و Knowledge تاریخی در Team Culture زنده نگه داشته میشود.
- Single Codebase: چند Version مستقل Code را مدیریت نکنید.
- Daily Deployment: هر روز Version تازه را به Production Push کنید.
- Negotiated Scope Contract: برای Consulting بهجای Fixکردن Scope و مذاکره روی Time/Quality، Time را Fix و Scope را پیوسته Negotiation کنید.
- Pay-per-use: بهجای Charging Development Work، وقتی Customer System را استفاده میکند Charge کنید تا Usage واقعی Featureها Feedback فوری بدهد.
کتاب روی همهٔ اینها عمیق نمیشود، اما Shared Code اینجا مهم است. در XP همه ــ حتی Project Manager اگر عضو Team باشد ــ حق Edit هر بخش Codebase را دارند. Everyone owns everything. اگر کسی Bug ببیند Fix میکند، حتی اگر دیگری Inject کرده باشد. این برخلاف Team سنتی است که هر فرد فقط Owner قطعهٔ خودش است.
Root-cause Analysis و Five Whys در فصل ۸ دوباره بررسی میشوند.
وقتی Ownership Barrier میشکند، همه Accepted Responsibility برای Problem دارند. اگر همه مسئول Code هستند، همه بالقوه میتوانند Task Queue را حل کنند یا یاد بگیرند چگونه حلش کنند؛ Learning نیز بخشی معتبر از Project Work است.
چرا XP این همه Practice دارد؟
اگر تعداد Practiceها Overwhelming است، شاید Checklist Mindset دارید. Corollary Practiceها برای Problemهاییاند که Team هنگام بهترشدن با آنها روبهرو میشود. سؤال «چطور همه را یکباره انجام دهم؟» Warning است. اصل Baby Steps و Improvement میگوید بفهم Practice چه Benefit دارد و Gradually آن را وارد Work کنید. فصل ۷ نشان میدهد Practiceها چگونه همدیگر را تقویت میکنند و XP یک Whole System است، نه Checklist.
کارهایی که همین امروز میتوانید انجام دهید
- Pair Programming را چند ساعت امتحان کنید، حتی اگر ابتدا عجیب است؛ لازم نیست تعهد دائمی بدهید.
- اگر Developer هستید، Continuous Integration را همین امروز شخصاً آغاز کنید: در Breaking Point مناسب Latest Code را Pull، Integrate و Test کنید و چند ساعت بعد دوباره تکرار کنید. ببینید چند Integration Problem را زود میگیرید.
- TDD را امتحان کنید: پیش از ساخت Class/Module/Subroutine، یک Unit Test ساده بنویسید که Run میشود اما فعلاً Fail است. لازم نیست همهٔ Edge Caseها را همان ابتدا پوشش دهید.
برای مطالعهٔ بیشتر
- Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd Edition, Addison-Wesley, 2004.
- Andy Hunt and Dave Thomas, Pragmatic Unit Testing, Pragmatic Bookshelf؛ نسخهٔ Java 2003 و C# 2007.
نکتههایی برای مربیان Agile
- این یکی از دشوارترین بخشهای Agile Coaching است، بهخصوص برای Coach بدون Programming Background. روی XP Values و Principles تمرکز کنید و بگذارید Team خودش اثر آنها بر Code را کشف کند.
- Courage و Respect آسان گم میشوند. موقعیتهایی را پیدا کنید که Team Quality واقعی را از بیرون پنهان کرده؛ مثلاً Demo را برای دورزدن Known Bug دستکاری کرده یا Severity Bug Report را کم کرده است. دربارهٔ Communication بهتر صحبت کنید.
- فرصتهای بهتر برای Communication و ساخت Information Radiator را پیدا کنید.
صفحهٔ PDF 238
تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و بهصورت دادهٔ داخلی Base64 جاسازی شدهاند.
تصویر منبع - صفحهٔ PDF 224
تصویر منبع - صفحهٔ PDF 227
تصویر منبع - صفحهٔ PDF 229