فصل ۶ — XP و پذیرفتن تغییر: Practiceهای اصلی
«مردم از تغییر متنفرند... و دلیلش این است که مردم از تغییر متنفرند... میخواهم مطمئن شوم منظورم را گرفتید. مردم واقعاً از تغییر متنفرند. واقعاً، واقعاً متنفرند.» — Steve McMenamin، The Atlantic Systems Guild، 1996؛ نقلشده در Peopleware اثر Tom DeMarco و Timothy Lister.
آیا دقت کردهاید برنامهنویسان چقدر از کاربرانشان شکایت میکنند؟ کمی در Forumهای برنامهنویسی بگردید و خیلی زود Threadی پیدا میکنید که Developerها گلایه دارند User پیش از درخواست ساخت چیزی، خودش نمیداند چه میخواهد؛ و وقتی دائم نظرش را عوض میکند زندگی آنها را سخت میکند. این نگاه سالها بخشی از فرهنگ برنامهنویسی بوده است.
در فصلهای قبل دیدیم Scrum برای این مسئله پاسخی دارد: با Users کار کنید تا بفهمید چه چیزی برایشان Value دارد و Working Software را مرتب تحویل دهید تا این Understanding در طول زمان تغییر کند. این کار به Project Manager و Business Owner امکان میدهد اگر بیشترین Value را ایجاد میکند، Goal پروژه را دائماً بازبینی کنند.
اما حالا Team باید برای همگامشدن با این تغییرها مرتب Code را تغییر دهد. Developerها از تجربه میدانند دستکاری Code نوشتهشده Bug میآورد و هرچه Change بیشتر شود Codebase میتواند Brittleتر شود. آیا همهٔ این Changeها نرمافزار را Buggy و Unstable نمیکنند؟
یکی از مسئلههایی که Extreme Programming (XP) برای حلش ساخته شده همین است. XP یک Agile Methodology است و مثل Scrum از Practice، Value و Principle تشکیل شده. Practiceها یادگیری آسان و اثر زیادی دارند، اما فقط وقتی Mindset تیم درست باشد شیوهٔ فکرکردن به Work را تغییر میدهند.
در این فصل Practiceهای اصلی XP، کاربرد و سوءکاربرد آنها، Values و Principles و نقششان در ساخت Mindsetی را میبینید که بهجای نفرت از Change، آن را embrace میکند.
صفحهٔ PDF 195
شکل ۶-۱ — ده Practice نخست XP در چهار گروه Programming، Integration، Planning و Team دستهبندی شدهاند.
روایت
تیمی روی وبسایت Fantasy Basketball کار میکند:
- Justin — Developer.
- Danielle — Developer دیگر.
- Bridget — Project Manager.
پردهٔ اول: رفتن به وقت اضافه
Justin همیشه وقتی تا آخر شب در Office میماند حس عجیبی در شکمش داشت، انگار Coffee زیاد خورده باشد، در حالی که زیاد Coffee نمیخورد. وقتی از Home تا دیر وقت کار میکرد این حس را نداشت؛ فقط Office.
Danielle گفت: «قرار است یکی از همان شبها باشد، نه؟» او دوست دانشگاهی Justin بود، دو سال بالاتر در همان Computer Science Program معتبر، و حتی در Chemistry Lab هم Pair بودند. وقتی Justin برای کار در Chalk Player Online، شرکتی سازندهٔ Sports Website و Fantasy Basketball، درخواست داد Danielle Reference او بود و اولین کسی بود که به Team خوشامد گفت.
Justin قصد نداشت دیر بماند. با Late Work هم مسئلهای نداشت و Bridget اجازه میداد از Home کار کند. ولی باز بعد از ساعت 10 شب Office بود، برای Girlfriend پیام عذرخواهی میفرستاد و از Roommate میخواست Dog را بیرون ببرد.
آن روز عصر Bridget با خبر بد آمده بود: Product Managerها تصمیم گرفته بودند Software علاوه بر NBA باید European Leagueها را هم در Launch پشتیبانی کند؛ چون درآمد بیشتری میآورد. این در حالی بود که سه ماه قبل صریحاً تأیید کرده بودند فقط NBA لازم است.
Justin عصبانی بود: «ما سه ماه پیش دو بار چک کردیم که فقط NBA باشد.» Danielle گفت همان جلسه پیشنهاد خودش بوده. Justin ادامه داد اضافهکردن Leagueهای اروپا یعنی بیرونکشیدن حجم زیادی Code و Change بزرگ Database. او Bridget را مقصر میدانست و گفت او نمیفهمد این کار چقدر سخت خواهد بود؛ سپس دید Danielle وحشتزده پشت سرش را نگاه میکند. Bridget درست پشت سرش بود.
Justin توضیح داد مسئله صرفاً Change نیست؛ آنها ماهها قبل گفته بودند چه میسازند و Business Sign-off کرده بود. اگر از European League خبر داشتند System را کاملاً متفاوت Design میکردند. Architecture فعلی حتی Conceptی به نام League نداشت چون فقط یک League فرض شده بود. Danielle افزود این یک Basic Assumption بوده و تغییرش کل Design را عوض میکند و احتمال Problem میسازد.
Bridget پرسید چه نوع Problem؟ Justin گفت: «تا حالا Car را با Duct Tape و Paperclip تعمیر کردهای؟ یک چیزی شبیه همان.» هر سه فهمیدند Late Nightهای زیادی در پیش است.
Practiceهای اصلی XP
XP سیزده Primary Practice دارد که Team را در پیچوخم Software Development هدایت و کمک میکند Codeی بسازد که پذیرای Change باشد. برخلاف بسیاری از Scrum Practiceها، تعداد زیادی از XP Practiceها مستقیماً Programming محورند و مسئلههایی را هدف میگیرند که Team را به ساخت Code ضعیف میرسانند. همین تمرکز باعث سوءبرداشت رایج شده که XP فقط برای Programmerهای فوقحرفهای یا «Rock Star» است.
این فصل ده Practice نخست را در چهار Category توضیح میدهد: Programming، Integration، Planning و Team.
Programming Practices
دو Practice مستقیم برای Programmer عبارتاند از Test-first Programming و Pair Programming.
Test-first Programming / Test-driven Development (TDD)
در Test-first Programming یا TDD، Programmer پیش از Production Code یک Automated Test مینویسد. چون Code هنوز وجود ندارد Test Fail میشود. سپس Code نوشته میشود تا Test Pass شود. این چرخه Feedback نزدیک ایجاد میکند: Test شکستخورده بنویس، Code لازم برای Pass شدن را بساز، Problem و Understanding تازه را کشف کن، و Test بعدی را اضافه کن.
این Automated Testها معمولاً Unit Test هستند. تقریباً همهٔ Programming Languageها Code را به Unitهایی مانند Class، Method، Function، Subroutine یا Module تقسیم میکنند و Frameworkی برای اجرای Test روی همان Unitها دارند. وقتی Test اول نوشته میشود Programmer از ابتدا روشن میکند هر Unit باید چه Behaviorی داشته باشد.
Test-first فقط درستی Unit را نمیسنجد؛ از Problemهای Maintainability هم جلوگیری میکند. Change در یک بخش ممکن است بهدلیل Dependency پنهان، Bugی در Feature ظاهراً نامرتبط ایجاد کند. اگر Unit Testها در هر Build اجرا شوند، چنین Dependencyهایی خیلی زود با Failشدن Test آشکار میشوند، پیش از اینکه مشکل عمیقاً وارد Codebase شود.
Unit Test همچنین API و Reusability را بهتر میکند. مثلاً Java Classی با Name مبهم یا Initialization دستوپاگیر ممکن است تا وقتی Test مجبور به استفاده از آن نشده بد بودن Interface را نشان ندهد. چون Production Code هنوز کامل نشده، Design را سریعتر میتوان تغییر داد. Test نیز بخشی از Codebase میماند تا Developerهای بعدی Behavior مورد انتظار را ببینند.
Pair Programming
در Pair Programming دو Developer روی یک Workstation و یک Codebase مشترک کار میکنند. یکی Driver است و Keyboard را کنترل میکند؛ دیگری Navigator است و Design، خطاها، Next Step و Big Picture را میبیند. آنها مرتب Role عوض میکنند.
Pairing شبیه Code Review دائمی است، اما فقط Finding Bug نیست. Knowledge در Team پخش میشود، دو ذهن دربارهٔ Design گفتوگو میکنند و فرد کمتر در Tunnel Vision گیر میافتد. Pair Programming ممکن است در نگاه اول «دو نفر برای کار یک نفر» به نظر برسد، اما هدفش Quality، Shared Understanding و کاهش Rework است.
Integration Practices
10-minute Build
XP Team یک Automated Build دارد که در کمتر از حدود 10 دقیقه اجرا میشود. Build باید Compile، Test و مراحل لازم برای آمادهکردن Software را انجام دهد.
عدد 10 دقیقه از دید Team مهم است: اگر Build خیلی طول بکشد افراد کمتر آن را Run میکنند. Build سریع مرتب اجرا میشود و خیلی زود جواب سؤال «آیا Code ما تا اینجا کار میکند؟» را میدهد. چون Unit Testها بخشی از Build هستند، Team View دائماً بهروزی از Quality دارد.
Continuous Integration
Team برای کار همزمان روی Source Code از Version Control استفاده میکند. هر Developer Copy خصوصی یا Sandbox دارد و Changeهایش را Periodically به Repository برمیگرداند. مشکل وقتی رخ میدهد که Developer دیگری در این فاصله Change ناسازگار داده باشد. Conflict گاهی در Compile ظاهر میشود و گاهی Software Compile میشود اما Behavior خراب است.
Continuous Integration یعنی Team دائماً جدیدترین Code را Integrate کند، Build و Test را Run کند و Problem را سریع Fix کند. Build Server میتواند مرتب Latest Code را Checkout، Build و Test کند و Failure را به Team اطلاع دهد؛ اما CI فقط Build Server نیست. هر عضو باید Sandbox خودش را مرتب با Repository Synchronize کند.
بعضی Pair Programming Teamها حتی یک Build Token فیزیکی مثل Plush Toy یا Rubber Chicken دارند. Pairی که Token را میگیرد، در اولین فرصت Latest Code را Integrate، Problem را Fix و Token را به Pair بعدی میدهد. هدف این است که Integration Problem هرچه زودتر پیدا شود.
Planning Practices
XP از Iterative Development استفاده میکند. مانند Scrum، Long-term Planning به Cycleهای کوتاه شکسته میشود.
Weekly Cycle و Stories
در Weekly Cycle Team با Iteration یکهفتهای کار میکند و از Stories تقریباً همان User Storyهای Scrum استفاده میکند. Cycle با Planning Meeting شروع میشود: Progress Review، انتخاب Storyها همراه Customer، سپس شکستن Story به Task، Estimate و Assignment.
این روند بسیار شبیه Scrum Planning است و بسیاری از XP Teamها همان Practiceهای Scrum را Adopt میکنند؛ یکی از دلایل محبوبیت Hybrid Scrum-XP. بعد از Planning، Team در بخش ابتدایی Iteration Automated Testهای Story/Task را مینویسد و سپس Code لازم برای Passشدن Testها را میسازد. بعضی XP Teamها Taskها را Stack میکنند و Developer پس از تکمیل کار فعلی، Task بعدی Stack را برمیدارد تا Cherry-picking کمتر و توزیع Work متعادلتر شود.
Quarterly Cycle
هر Quarter، Team Big Picture را بررسی میکند. دربارهٔ Themeها ــ ایدههای بزرگتر دنیای واقعی که Storyها را به هم متصل میکنند ــ صحبت میشود. Theme کمک میکند Storyهای لازم کشف و اتصال پروژه به Business Problem واقعی حفظ شود. Team همچنین Internal/External Problem، Bugهای مزمن، Repairهای عقبافتاده، Progress، Needهای User و وضعیت کلی Project را Review میکند. بعضی Teamها Retrospective شبیه Scrum دارند.
Slack
Practice آخر Planning در این بخش Slack است. Team در هر Weekly Cycle چند Story کوچک و Low-priority قرار میدهد که Taskهایشان به انتهای Iteration موکول میشود. اگر Unexpected Problem رخ داد، Slack Storyها بدون لطمه به Featureهای اصلی حذف میشوند و Team هنوز Working Software کامل تحویل میدهد. مثل دیگر Iterative Methodها، پایان Cycle باید «Done Done» باشد: Software کار کند، Testها Pass باشند و قابل Demo به User باشد.
Team Practices
Sit Together
XP فقط Programming نیست. Teamها وقتی نزدیک هم مینشینند بهتر کار میکنند و دسترسی سادهتری به یکدیگر دارند. Programming فردی گاهی Isolation میخواهد، اما عضویت در Programming Team فعالیتی بهشدت Social است: افراد دائم دربارهٔ Problem مشورت، Advice درخواست و Alert مبادله میکنند.
Open Workspace این تعامل را تقویت میکند، ولی Balance لازم است چون Programmer برای Concentration به محافظت از Distraction و گاهی Privacy صفحه نیاز دارد. یکی از Layoutهای مشهور caves and commons است که Stewart Brand در How Buildings Learn شرح میدهد: Office خصوصی/مشترک به Common Area بزرگ با Meeting Table و Pairing Workstation باز میشود.¹
Informative Workspace
Workspace باید خودش Project Information مهم را به کسی که در آن کار میکند منتقل کند. Task Board و Burndown Chart بزرگ روی دیوار نمونهٔ رایجاند. وقتی Data جلوی چشم همه است، تکتک اعضا وضعیت Project را میدانند و Decision بهتر میگیرند.
این Chartها و Displayهای دائماً Visible را Information Radiator مینامند چون Information جاری را به اطراف «Radiate» میکنند. فقط Chart نیست؛ Discussion در Shared Workspace هم Information پخش میکند. اعضای اطراف Conversation را میشنوند و Context میگیرند. این جذب طبیعی Project Information Osmotic Communication نام دارد.
البته باید Value این Communication با Cost Distraction متعادل شود. Informative Workspace مهم است چون Information برای کل Team Democratize میشود، نه فقط Lead یا Manager. هرچه Project Information بیشتر Share شود، هر فرد بهتر میتواند بر Direction پروژه اثر بگذارد.
¹ Stewart Brand, How Buildings Learn: What Happens After They’re Built, Penguin Books, 1995.
چرا Teamها در برابر Change مقاومت میکنند و Practiceها چگونه کمک میکنند؟
هیچکس دوست ندارد Code بنویسد و بعد چون سفارشدهنده نظرش عوض شده دوباره آن را تغییر دهد. Change دیرهنگام میتواند از آزاردهنده تا توهینآمیز و حتی Disaster باشد، مخصوصاً وقتی نتیجهاش چند Weekend کار اجباری باشد.
شکل ۶-۲ — Project Manager حس درماندگیِ نیاز به Change و مقاومت Developer را میشناسد؛ Developer هم Anxiety تبدیل Change ظاهراً کوچک به Monster زمانبر را میشناسد.
به همین دلیل Developerها میگویند Business User «مدام نظرش را عوض میکند» و سؤال آشنا را میپرسند: «اگر از اول میدانستم، Code را کاملاً متفاوت میساختم. چرا از ابتدای Project دقیقاً نمیگویید چه میخواهید؟»
صفحهٔ PDF 203
تصویر منبع - صفحهٔ PDF 203
مقاومت قابل فهم است. Change یعنی Rework روی چیزی که فکر میکردید Finished است: شکافتن Code و بازسازی بخشهایی از آن. علاوه بر کار فیزیکی، Team Mental Effort زیادی برای Solution Elegant گذاشته و حالا انگار باید Taj Mahal را خراب کند چون Customer در واقع Eiffel Tower میخواسته است.
اما از دید User هم داستان متفاوت است. او Software را برای انجام Job نیاز دارد و ناگهان باید به سؤالهای Technical پاسخ دهد که شاید واقعاً نفهمد: چه کسی Access داشته باشد؟ چند Concurrent User؟ Response Time قابل قبول چقدر؟ ترتیب Optionها چه باشد؟
جلسهای که برای توضیح Business Problem شروع شده تبدیل میشود به Stream بیپایانی از سؤالهای Technical، همراه Tick یک Clock: اگر جواب ندهد Team Project را Delay میکند و احتمالاً او را Blame خواهد کرد. پس بهترین حدسش را میدهد تا Meeting تمام شود و Budget نسوزد.
Agile Methodology و بهخصوص XP از ابتدا میپذیرند که دقیقاً نمیدانیم چه میسازیم و یکی از مؤثرترین راههای فهمیدن، ساختن آن است. Working Software بر Comprehensive Documentation ترجیح دارد چون برای گرفتن Feedback، بهترین ابزار قراردادن بخشی از Software در دست User است.
آیا میتوان بهجای شلیک به هر Change، Environmentی ساخت که Team Change را Gracefully و بدون Weekend Disaster یا Emotional Conflict مدیریت کند؟ XP پاسخ مثبت میدهد و این نگرش را Embracing Change مینامد. Team Change را Necessary Evil نمیبیند؛ میداند بهترین Software فقط با Feedback مکرر و Response سریع ساخته میشود. XP Team Change را انتظار میکشد و حتی صریحاً آن را درخواست میکند.
Embracing Change دو بُعد دارد: Scope پروژه و خود Codebase. این بخش بیشتر روی Scope، Functionality و Behavior تمرکز دارد؛ فصل ۷ روی Changeability Code و Design عمیقتر میشود.
Planning چگونه کمک میکند؟
Iterative Planning و Working Software در پایان هر Iteration Feedback مداوم میآورد. Team خودش Change را درخواست کرده، پس Emotional Resistance به آن کمتر میشود.
Team Practice چگونه کمک میکند؟
وقتی افراد کنار هم هستند Problem زودتر دیده میشود. Informative Workspace همه را روی Problemهای یکسان نگه میدارد. فرد از Change غافلگیر نمیشود و Autonomy بیشتری برای Decisionهایی دارد که روی Code و زندگی کاریاش اثر دارد.
Integration چگونه کمک میکند؟
Change ممکن است در سراسر Codebase Ripple کند. اگر یک Change در بخش شما Bugی در بخش من ایجاد کند، Continuous Integration و Build سریع آن را زود آشکار میکنند تا پیش از تبدیلشدن به Surprise بزرگ Fix شود.
Programming Practice چگونه کمک میکند؟
Unit Testهایی که در هر Integration اجرا میشوند، اثر Change را روی بخشهای دیگر سریع نشان میدهند. اگر Test من با Change شما Fail شد، میتوانیم با هم ــ حتی بهصورت Pair ــ Problem هر دو بخش را حل کنیم.
وقتی این Practiceها در کنار هم هستند، حتی Change بزرگ Impact کوچکتری دارد و Team یاد میگیرد Change قابل مدیریت است.
نکتههای کلیدی
- در Test-first Programming، XP Team ابتدا Unit Testی میسازد که Behavior مورد انتظار Code را بیان میکند و سپس Code را برای Passکردن Test مینویسد؛ این Feedback Loop از Defect جلوگیری میکند.
- Team یک Automated 10-minute Build دارد.
- Developerها با Continuous Integration Change همتیمیها را مرتب وارد Sandbox خود میکنند.
- XP از Weekly Cycle و Quarterly Cycle و Storyها شبیه Scrum استفاده میکند.
- Team Storyهای Minor و Low-priority را برای Slack در Cycle میگذارد.
- Sit Together زمینهٔ Osmotic Communication را فراهم میکند.
- Informative Workspace با Information Radiatorهایی مثل Wall Chart اطلاعات Project را خودکار منتشر میکند.
پردهٔ دوم: Game Plan تغییر کرده، اما هنوز میبازیم
شش هفته قبل Justin فکر میکرد اوضاع بهتر شده. نخستین Alpha Release سایت Fantasy Basketball با NBA و European League تمام شده بود، اما Bug زیاد بود. Danielle گفته بود «Buggy as hell». Team جلسهٔ بزرگی برای Code Quality داشت و Bridget خواست فوراً کاری کنند: Design Review و Code Review بیشتر، Test Event جمعی با Product Managerها، حتی Hiring یک Full-time Tester.
همانجا Danielle دربارهٔ XP گفت: «باید این کار را شروع کنیم. این Practiceها مشکل Code ما را حل میکند.» Team همراه شد و Bridget Resources واقعی گرفت: چند هفته برای راهاندازی XP، از جمله یک هفته فقط برای نوشتن Unit Test، چون هیچ Unit Testی نداشتند.
Office Manager اجازهٔ Sit Together نداد، اما Danielle دیوار خالی کنار Coffee Machine را با Checklist بزرگ XP به Informative Workspace تبدیل کرد و کنار «Informative Workspace» Tick زد. بعد از هفتهٔ Unit Test کنار «Test-first Development» هم Tick گذاشت. Justin Build Server راه انداخت که هر ساعت Code را از Version Control بگیرد، Build و Unit Test را Run و Result را Email کند: «Continuous Integration» هم Tick خورد.
شش هفته گذشته بود اما Justin حس میکرد هیچ چیز واقعاً تغییر نکرده. او و Danielle از جلسهٔ بدی با Bridget بیرون آمده بودند؛ Bridget از طولانیشدن Fixهای Database آمار Player عصبانی بود. Justin و Danielle قبل از جلسه خصوصی توافق کرده بودند Deadline عملاً دستنیافتنی است، اما در Meeting وقتی Bridget پرسید On time هستند هر دو گفتند بله. Danielle گفته بود «بعداً عذرخواهی میکنیم.» آنها Corner Cut میکردند ولی باز Late میشدند و تصور میکردند گفتن Truth حالا فقط Trouble بیشتر ایجاد میکند.
در Coffee Break Justin پرسید: «XP Adoption تا الآن چطور بوده؟» Danielle ناراحت شد: Practiceها قرار بود Code را درست کنند، اما چهار ساعت دنبال Bug در Code کاملاً جدیدی گشته بود که بعد از شروع XP نوشته شده بود. همان Mistakeهای قدیمی تکرار میشد.
Pair Programming عملاً متوقف شده بود، بیآنکه Decision رسمی گرفته شود. یک نفر Vacation رفت و Pair از هم پاشید. TDD هم واقعی نبود: Justin فقط چند Unit Test مینوشت و Danielle احساس میکرد Time ندارد. چند روز قبل Danielle Code Justin را دیده بود: Commented-out Block، Methodهای عظیم Spaghetti. پرسید چه شد آن Code Elegant؟ Justin گفت Deadline آنقدر Tight است که Time فکرکردن ندارد.
Justin به یاد آورد Pairing آنها هم وقتی Production Bug مهم آمد قطع شد؛ او مجبور شد روی Bug بپرد و Danielle Database Code را تنها ادامه داد. «ما برای هیچکدام از این چیزها Time نداریم!» Danielle بعد از سکوت اعتراف کرد هیچوقت واقعاً Unit Test را اول نمینوشته؛ مثل قبل Code مینوشت و بعد از تمامشدن Object Test اضافه میکرد. پرسید مگر این تفاوتی ایجاد میکند؟
Justin نتیجه گرفت: «پس واقعاً خیلی متفاوت از قبل XP کار نمیکنیم، درست است؟»
XP Values Mindset تیم را تغییر میدهند
Kent Beck در Extreme Programming Explained, 2nd Edition میگوید Practice بهتنهایی عقیم است. Value به آن Purpose میدهد. Pair Programming فقط برای Tickزدن Box بیمعنا و آزاردهنده است؛ اما Pairing برای Communication، Feedback، Simplifyکردن System، Catch Error و تقویت Courage منطقی است.
الگوی مشابه Scrum اینجا هم وجود دارد. اگر Team Change را پس بزند، Userی را که Behavior دیگری میخواهد Blame کند، یا باور نداشته باشد Software Changeable میتواند ساخته شود، XP را «نگرفته» است. اگر Simplicity را نفهمد ــ تفاوت Simple Design با Complex Design، منبع Simplicity، اثر Team Culture بر Simple Code/Architecture و نقش Simplicity در جلوگیری از Bug ــ باز هم XP را نگرفته است.
برای Embraceکردن Change باید بفهمیم Bug از کجا میآید. بسیاری از Software Engineering Textbookها یک پاسخ مهم دارند: Rework. Defect از جاهای مختلف Inject میشود اما Rework یکی از رایجترین منابع است: Software برای کار A ساخته شده، Change میآید، Team Code قدیمی را میکَند، Existing Code را تغییر میدهد و Code جدید Patch میکند.
میشود Change را Prevent کرد؟ در Theory بله: Requirements را کامل Gather، Document و Review کنید. این رویکرد در بعضی پروژهها واقعاً Software عالی ساخته است.³⁴ اما بسیار Rigid است چون فقط وقتی جواب میدهد که Specification Writer بتواند از ابتدا Requirements کافی را درست کشف کند. در بسیاری از موقعیتها نمیتواند؛ به همین دلیل Change Management System لازم میشود.
XP Code را طوری میسازد که Change آسیب کمتری بزند. Rework نهتنها قابل قبول بلکه Embrace میشود، چون Codebase برای Changeability ساخته شده است. یک مزیت مهمتر جلوگیری از خفهشدن Ideaهای خوب است. Early Version نرمافزار اغلب بهترین Brainstorming را ایجاد میکند، اما در BRUF گفتوگو ممکن است اینگونه شود: Programmer Idea عالی دارد، Lead میگوید Change زیاد است و شش ماه بعد Backlog Grooming بررسی میکنیم؛ Programmer میگوید ده دقیقه طول میکشد؛ Manager میگوید Risk Bug زیاد است و «نه نمیگوییم، فقط الآن نه.» نتیجه؟ احتمالاً Programmer دفعهٔ بعد Idea را برای خودش نگه میدارد.
Teamی که از Change میترسد Innovation از پایین را خفه میکند. BRUF میتواند Software خوب و مطابق Requirement بسازد و برای بعضی Teamها Goal مناسبی است، اما Tradeoff دارد.
³ نویسندگان اشاره میکنند Traditional Software Engineering و Project Management Mindset جلوگیری از Change دارد؛ معتبر است و الزاماً با Agile ناسازگار نیست.
⁴ خود نویسندگان نیز Software موفقی با Requirements مفصل ساختهاند.
XP به Developer یاد میدهد با User کار کند
BRUF Waterfall در Release اول و گاهی دوم ممکن است بسیار موفق باشد. قبل از شروع پروژه Discussion زیادی شده، Need مشخص و مهم است و Company برایش Money/Resource داده. Requirements اولیه بهترین Ideaها را جمع میکنند و Version دوم هم اغلب Featureهای باارزشی است که در Version اول Time نشده بود. بنابراین Early Success طبیعی است.
Problem در Releaseهای بعدی ظاهر میشود. مردم Software را استفاده کردهاند و Working Software Feedback عالی تولید میکند. حالا Feedbackهای خوب برای Implementation به Rework نیاز دارد. اگر Codebase سختتغییر باشد، Team Change را High Risk میبیند و Fear کاملاً Rational شکل میگیرد. User و Stakeholder مجبور میشوند Requirement را با Existing Code وفق دهند. Partnership اولیه به رابطهٔ Antagonistic تبدیل و Requirement Elicitation شبیه Contract Negotiation میشود؛ Customer Collaboration سخت میشود.
XP با Practiceها و Mindset درست Codebase را آسانتر برای Change میکند. علاوه بر آن Definition Quality را تغییر میدهد: Quality فقط نبود Bug نیست؛ Software باید Need واقعی User را برآورده کند، حتی اگر دقیقاً چیزی نباشد که شش ماه قبل درخواست کرده بود.
BRUF معمولاً Functional Design را از Technical Design جدا میکند. Functionality در Spec نوشته و به Team تحویل میشود. اگر Programmer سؤال داشته باشد، Spec Writer میپرسد و جواب User/Manager را «ترجمه» میکند؛ نوعی game of telephone. این روش گاهی Efficient تلقی میشود چون Time Developer را با User «هدر نمیدهد».
XP این فاصله را میشکند و Developer را وادار میکند مثل User فکر کند و حتی مستقیم با User حرف بزند. اگر Skill ارتباطی ندارد، آن را میسازد. TDD هم همین Mindset را تقویت میکند: قبل از Code باید بپرسد «این Code دقیقاً چه کاری باید بکند؟» و این سؤال در Weekly Planning هم منتقل میشود.
XP همچنین CYA نهفته در Specification را کم میکند. Developer دیگر نمیتواند صرفاً بگوید «من دقیقاً Spec را پیاده کردم» بدون فکر به Need. چون برای Test باید Behavior را بفهمد، Clarification را مطالبه میکند و Responsibility را به Spec Writer هل نمیدهد. وقتی همه این کار را کنند، Team مستقیم از User میپرسد و تلاش میکند Software واقعاً Job او را ممکن کند.
به بیان ساده: BRUF کمک میکند چیزی را بسازید که قصد داشتید؛ XP کمک میکند چیزی را بسازید که User واقعاً نیاز دارد. Team خوشحالتر است چون Problem واقعی حل میکند نه اینکه با Code برای Change بجنگد؛ User هم چیزی را میگیرد که امروز نیاز دارد، نه لزوماً چیزی که شش ماه قبل تصور میکرد.
Practice فقط وقتی «میچسبد» که تیم واقعاً به آن باور داشته باشد
XP Practiceها Team را وادار میکنند پیش از زیادشدن Code روی Quality تمرکز کند. Scrum بیشتر دربارهٔ شفافکردن چیزی است که Team میتواند و نمیتواند تحویل دهد؛ XP دربارهٔ ممکنکردن Change سریع و کمDefect است. این نگرش Quality باید سراسر Development را بگیرد.
برای Technical Person حتی Rock-star Developer، این Mindset تازه است. Scrum Practice گاهی آسانتر پذیرفته میشود چون افراد Problem را Planning میدانند. اما XP مستقیم میگوید شیوهٔ Coding خودت را تغییر بده.
شکل ۶-۳ — واکنش رایج به XP: «در Theory خوب است، اما Pair Programming و TDD برای Team ما جواب نمیدهد.» این لزوماً استدلال علیه Practice نیست؛ بیشتر نشاندهندهٔ دشواربودن Change است.
برای یک Program بینهایت راه نوشتن وجود دارد. دو Developer برای یک Unit تقریباً هرگز Code کاملاً یکسان نمیسازند و یکی ممکن است Code بسیار بهتری تولید کند. Skill مهم است، اما همهچیز نیست. Teamهای بسیار Skilled هم زیر Pressure Change و Deadline Code ضعیف ساختهاند، Bug زیاد دیدهاند و Fear از Change در آنها پخش شده است.
همین Fear باعث میشود Team به XP روی بیاورد و Managerها روی Practiceهای ضدBug تمرکز کنند: Pair Programming مثل Code Review دائمی؛ TDD برای Test دائمی؛ Continuous Integration برای Run همیشگی Testها. اینها واقعاً Bug بیشتری را پیدا میکنند، اما بدون Values و Mindset لازم، اجرای مکانیکیشان پایدار نمیماند؛ همان اتفاقی که برای Justin و Danielle افتاد.
صفحهٔ PDF 214
تصویر منبع - صفحهٔ PDF 214
تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و بهصورت دادهٔ داخلی Base64 جاسازی شدهاند.
تصویر منبع - صفحهٔ PDF 196