Alexander و Arno در دو اپيزود در مورد XP بحث كرده‌اند. در ادامه مطالب مطرح شده در اپيزود دوم را مطالعه خواهيد كرد.
Practice 7: User Stories
User Story: User Story به نوعي نيازمندي‌هاي پروژه را بيان مي‌كند. البته در XP مستندات زيادي مثلاً تعداد زيادي Use Case يا دياگرام براي نيازمندي‌ها تهيه نمي‌شود. از كاربر مي‌خواهيم كه امكاناتي كه مورد نظرش است را بيان كند. هر كدام از اين امكانات در قالب يك يا دو جمله بر روي يك Index Card نوشته مي‌شود. به هر كدام از اين كارت‌ها يك User Story گفته مي شود. همه كارت‌ها در يك جعبه مقوايي نگهداري مي‌شوند. بنابراين User Story بيان Abstract و به زبان كاربر دارد و شامل جزييات نيست. اطلاعات User History براي پياده سازي كافي نيست بلكه فقط بعنوان يك مارك استفاده مي‌شود كه بعداً كاربر و تيم توسعه به آن مراجعه كنند و آن را بخاطر بياورند و در مورد جزييات آن بحث كنند.
Practice 8: Weekly Cycle
در هنگام برنامه‌ريزي (Planning Game) توسعه‌دهندگان از كاربران مي‌خواهند كه كارت‌ها را اولويت‌بندي كنند. سپس كارت‌هايي كه قرار است در اولين Iteration پياده شوند را انتخاب مي‌كنند. هنگام برنامه‌ريزي هربار تنها يك Iteration برنامه‌ريزي مي‌شود. سپس اين كارت‌هاي انتخاب شده بر روي تخته نصب مي‌شود تا نمايش داده شود چه مقدار كار انجام شده است.
مدت هر Iteration تنها يك يا دو هفته خواهد بود و در هر Iteration انواع كارهاي نيازسنجي، طراحي، پياده‌سازي و تست انجام مي‌شود. در واقع ايده اين است كه در پايان هر Iteration يك Release جديد تهيه ‌شود. آنگاه اين نسخه Release در اختيار كاربر قرار داده شود تا از كاربر فيدبك گرفته شود.
هزينه و سربار (Overhead) تا اين حد سريع Release دادن چيست؟ از آنجاييكه در XP سعي مي‌شود كارها خودكار انجام شود خصوصاً Unit Test ها خودكار هستند و هزينه‌اي ايجاد نمي‌كنند، مي‌توانيم Release هاي كم‌هزينه داشته باشيم. نكته ديگر اين است كه نيازي نيست اين Release هاي مياني تمامي نيازمندي‌هاي يك Release نهايي را داشته باشند. از آنجاييكه كاربرد اصلي اين Release ها اين است كه مشتري با سيستم آشنا شود و تعامل كند مسائلي از قبيل Data Migration (انتقال داده‌ها از سيستم‌هاي قبلي) يا تست‌هاي جامع عملكردهاي سيستم نيازي نيست در اين Release ها انجام شود.
اما مشكلي كه هست اين است كه برخي مواقع خود مشتري‌ها نمي‌توانند، با اين سرعت Release ها را تحويل گرفته و فيدبك بدهند. البته در چنين حالتي هم Release هاي هفتگي مفيد است زيرا ملزم مي‌سازد همواره در يك وضعيت Releasable قرار داشته باشيم و به معناي واقعي Incremental و با تغييرات كوچكي كه سيستم بزرگ را بهم نمي‌ريزد جلو برويم و از اينكه ليستي از كارهاي مختلف، براي انتهاي پروژه انباشته شود، جلوگيري مي‌كند.
Practice 9: Quarterly Cycle
در XP بغير از دوره‌هاي هفتگي يا Iteration ها كه به آن اشاره شد، دوره‌هاي فصلي (Quarter) داريم. در هر Quarter يك Release اصلي و يك نسخه اجرايي محصول تحويل مي شود. براي هر Quarter شما مي‌بايست، محصول، Resource ها، افراد و زمانبندي‌ها را برنامه‌ريزي كنيد. البته دقت داشته باشيد كه اين برنامه‌ريزي‌ها سطح بالا هستند و اصلاً اينطور نيست كه زمانبندي جزييات فعاليت‌هاي يك فرد را براي يك دوره 3 ماهه تعيين كند بلكه اينكار براي دستيابي به يك ديد سطح بالا و اهداف انجام مي‌شود و در جريان كار اشتباهات برنامه‌ريزي‌ها اصلاح خواهد شد.
Practice 10: Slack
نكته‌اي كه در برنامه‌ريزي بايد در نظر گرفته شود قرار دادن Slack است يعني بايد در نظر داشت كه در برنامه‌ريزي‌ها جايي براي كارهايي از قبيل زمان‌هاي شخصي (در Pair Programming به آن اشاره شد) و زمان‌هايي براي تحقيق و مطالعه و از اين دست وجود داشته باشد مثلاً بسته به مورد ممكن است در XP يك هفته يا يك ماه فرصت مطالعه و تحقيق داده شود (در كتاب دوم XP به اين مطلب تصريح شده است).
Practice11: Ten Minutes Build
در XP، در فواصل زماني كوتاه نرم‌افزار Build مي‌شود. مدت زمان بين Build ها بسته به شرايط پروژه و تكنولوژي و IDE مورد استفاده توافق مي شود مثلاً زمان‌هاي 5 يا 10 دقيقه‌اي بين هر Build خواهيم داشت. با هر Build تست‌ها مجدداً Run مي‌شوند و نتايج آنها در دسترس قرار خواهد گرفت.
انجام Build با فواصل بسيار كوتاه در زبان‌هايي مانند C# و Java و Smalltalk عملي است اما در پروژه‌هاي بزرگ C++ بعلت طولاني بودن زمان Build، با مشكل مواجه خواهيم شد. شايد بتوان كارهايي كرد تا اين مشكل را حل كرد مثلاً سيستم را به تعدادي زيرسيستم Decoupled تفكيك كنيم كه هركدام جداگانه كامپايل شود و نتيجه كامپايل در Source Control، قرار داده شود و وقتي Build مي‌كنيم فقط زيرسيستمي كه تغيير داده شده است كامپايل شود و ديگر زيرسيستم‌ها مجدداً كامپايل نشود. اما اگر زمان Link طولاني باشد چه بايد كرد؟ اگر نتوان راه‌حلي يافت مي‌توان گفت كه XP روش مناسبي براي چنين پروژه‌اي نيست! زيرا اين جزيي از XP و Test Driven Development است كه تغييرات كوچك داشته باشيم و هربار بعد از آن مجدداً تست‌ها اجرا شوند.
Practice 12: Continuous Integration
ايده Continuous Integration اين است كه هربار كه يك كدي به سيستم Source Control ، Commit مي‌شود، همان موقع سيستم مجدداً Build شود و كليه تست‌ها اجرا مي‌شود و اگر تستي Fail شود همان موقع اعلان مي‌شود. براي خودكار كردن اينكار در زبان‌هاي مختلف ابزارهايي وجود دارد مثلاً در زبان جاوا، ابزار Cruise Control را داريم كه بطور خودكار مي‌تواند اين عمليات را انجام دهد.
حتي در مايكروسافت در پروژه ويندوز NT، هر شب يك Build كامل و خودكار از تمامي كدهايي كه تا آن شب Commit شده بود، تهيه مي‌شد و هربار يك مجموعه تست بر روي كد انجام مي‌شد كه آن را تست Smoke مي‌ناميدند انجام مي‌شد. در واقع آنها در چنين پروژه عظيمي كه ساختار لينك‌هاي Static داشت، آنها از ايده Continuous Integration (در حدي كه براي آنها مقدور و ممكن بود) بهره مي‌بردند.
اگر شما تعدادي تيم مجزا داشته باشيد كه هريك بر روي يك زيرپروژه كار كنند و بخواهيد كه بعد از چند ماه كدهاي آنها را با هم Integrate كنيد به مشكلات عديده بر مي‌خوريد. اول اينكه بعد از آنكه كدها را Integrate كرديد كامپايل نخواهد شد، بعد از دو هفته كه توانستيد كدها را كامپايل كنيد خواهيد ديد كه تركيب آنها با هم درست كار نمي‌كند! اين يك مسأله نمايي (Exponential) است يعني هرچقدر زمان Integration را به تأخير بياندازيد، انجام Integration به نسبت نمايي سخت‌تر مي‌شود. يعني اغلب در ابتدا قسمت‌هاي مختلف يك سيستم درست با هم كار نمي‌‌كنند اگر شما در همان ساعت اول يا 10 دقيقه اول توليد شدن زيرسيستم‌ها، متوجه اين مطلب بشويد، خيلي راحت‌تر مي‌توانيد مشكل را حل كنيد و ارتباطات را برقرار كنيد چون شما هنوز مي‌دانيد و در ذهن داريد كه مشكل چه مي‌تواند باشد اما اگر بعد از يك هفته متوجه آن شويد برطرف كردن مشكل خيلي سخت‌تر شده، چون پيچيدگي‌ها و Dependency هاي متعددي در اين يك هفته ايجاد شده كه شما نمي‌دانيد مشكل از كدام ناحيه ايجاد شده است، و همينطور بعد از يك‌ماه كار بمراتب سخت‌تر است و ...
Practice 13: Incremental Design
در XP يك فرآيند زمانگير براي طراحي معماري يا ساختار اوليه هرگز وجود ندارد.
ايده اين است كه تغيير در طراحي و معماري تا زماني كه واقعاً لازم مي‌شود به تعويق بياندازيم. يعني اگر شما مي‌خواهيد يك User Story را پياده كنيد و با معماري موجود قابل پياده سازي است آن را انجام دهيد و تنها وقتي مي‌خواهيد يك User History را پياده كنيد كه با طراحي‌هاي موجود قابل پياده‌سازي نيست، طراحي را تغيير دهيد.
اين Practice يكي از موضوعات بحث‌برانگيز و پرچالش بين XP كاران بوده است. من شنيده‌ام كه حتي Kent Beck گفته است حتي مسأله بظاهر بديهي مانند نياز به داشتن يك Relational Database را از ابتدا فرض نمي‌كنيم بلكه تا زماني كه واقعاً نياز به آن در مراحل واقعي توسعه و با فيدبك الزام نشود، به سراغش نمي‌رويم. زيرا در ابتدا ممكن است كاملاً به نظر برسد كه يك سيستم به Relational Database نياز دارد اما در ابتدا دانش ما از سيستم كم است و اگر جلوتر برويم ممكن است نظرمان عوض شود. در واقع تجربه نشان مي‌دهد كه ما خيلي مواقع خيلي چيزهايي را از قبل پيش‌بيني و طراحي مي‌كنيم كه بعداً هيچگاه از آن استفاده نمي‌كنيم. در واقع معماران سيستم، طراحان و مديران كارهاي زيادي براي Feature Safe بودن در آينده انجام مي‌دهند كه نه تنها در آينده استفاده نمي‌شود بلكه حتي كار را در آينده سخت‌تر مي‌كند چون سيستم بي‌دليل بزرگ شده است.
ايده Incremental Design در تناقض با مطالبي كه در كتاب‌ها است و افراد در دانشگاه آموخته‌اند قرار مي‌گيرد. زيرا در منابع مختلفي گفته مي شود هر چقدر يك تغيير در سيستم زودتر انجام شود، راحت‌تر انجام مي‌شود و هرچقدر به تأخير بيافتد بصورت نمايي سخت‌تر و پرهزينه‌تر مي‌شود! در اينجا ايده XP اين است كه ما هزينه تغييرات در آينده را پايين نگه مي‌ داريم يعني Practice هاي مختلفي از قبيل Test Driven Development، Pair Programming ، Fast Builds، Continuous Integration همگي اين كاركرد را دارند كه هزينه تغييرات آتي را پايين نگه دارند، و وقتي شما هزينه تغييرات را پايين نگه داريد، آنوقت بصرفه است كه تغييرات را تا زمان ممكن به تعويق بياندازيد. در واقع ايده، تغيير دادن هزينه تغييرات است!
گشتي بر مراحل انجام يك پروژه در XP
گام اول، قرارداد، است.
XP با يك قرارداد كه هزينه ثابتي در آن قيد شده باشد، كار نمي‌كند بلكه بجاي آن مي‌بايست در ابتداي كار مشتري توجيه شود كه او خود جزيي از تيم است و در اجراي پروژه همكاري خواهد كرد و در ريسك‌هاي آن شريك خواهد شد. در واقع، مشتري و تيم توسعه با هم يك مسيري را آغاز مي‌كنند و آنقدر ادامه خواهند داد تا مشتري بگويد كه همين مقدار امكانات كفايت مي‌كند.
اما مشتري مي‌خواهد از قبل بداند كه كار چقدر هزينه مي‌برد. چطور با مشتري كنار بياييم؟ اين مسأله پيچيده‌اي است. اشكال مختلفي براي قرارداد با مشتري وجود دارد كه در اينباره منابع فراواني براي مطالعه در وب وجود دارد. قرارداد بر مبناي Time و Material بسته مي‌شود. مشتري مي‌تواند بودجه را Fix كند و Feature ها را باز بگذارد. بهرحال بايد يكي از محرك‌ها باز باشد. ما مي‌توانيم تخميني از هزينه و زمان ارائه كنيم كه البته يك امر الزام‌‌آور نخواهد بود. رابطه بر اساس اعتماد شكل مي‌گيرد. لازم است مشتري اعتماد كند كه تخمين ارائه شده صادقانه بوده است.
گام اول، خصوصاً وقتي مشتري شما را نمي‌شناسد واقعاً كار سختي است اما اگر اين مرحله را رد كنيد كار خيلي آسانتر مي‌شود چون مشتري مستقيماً در سايت شما حضور يافته با شما كار مي‌كند و از آنچه مي‌كنيد مستقيماً آگاه مي‌شود در اين مرحله اعتماد شكل خواهد گرفت.
بعد از آن، برنامه‌ريزي سطح بالا يا Quarter Planning را خواهيد داشت. با آغاز كار لازم است كه فردي از طرف سازمان مشتري براي تعامل معرفي شود. اين فرد در عين حال كه مي‌بايست Business را بشناسد لازم است كه بطور كامل به تيم توسعه بپيوندد و در محل توسعه با آنها همكاري كند. گاهي مواقع سخت است كه فردي را بيابيم كه كل Business را بشناسد و از طرفي بتواند درگير توسعه نرم‌افزار هم بشود بهمين خاطر يكي از تغييراتي كه XP در اين چند سال كرده است اين است كه از ناحيه مشتري لزوماً تنها يك نفر معرفي نمي‌شود و ممكن است براي بخش‌هاي مختلف Business افراد مختلفي معرفي شوند. اين فرد يا اين افراد واقعاً درگير مي‌شوند و بصورت تمام وقت در اتاق توسعه يا توسعه‌دهندگان همكاري مي‌‌كنند. آنها User Story مي‌نويسند. User Story ها را اوليت‌بندي مي‌كنند. تست‌هاي عملكردي انجام مي‌دهند و خيلي كارهاي ديگر. اين فرد مسئول تصميم‌گيري از طرف مشتري است. بنابراين، از جهت دريافت سريع فيدبك‌ها و دريافت سريع تصميم‌گيري‌ها شما سود خواهيد كرد.
اولين كاري كه با هم انجام خواهيد داد نوشتن User Story است كه حداكثر چند ساعت طول مي‌كشد. User Story ها را مشتري بيان ‌مي‌كند و توسعه‌دهندگان در مورد معناي واقعي جملاتي كه مشتري مي‌گويد بحث و گفتگو مي‌كنند تا متوجه منظور هم شوند تا اينكه مشتري بگويد كه اين تعداد Story براي آغاز كار كفايت مي‌كند.
پس از آن توسعه‌دهندگان يك تخمين كلي از اينكه هر User Story چقدر زمان مي‌برد، انجام مي‌دهند. فرض كنيد يك User Story را برمي‌داريم و تخمين مي‌زنيم كه يك روز زمان مي‌برد، آنگاه User Story بعدي را برمي‌داريم. در اينجا كاري كه مي‌كنيم اين است كه تخمين User Story بعدي را بصورت نسبتي از اولي ارائه مي‌كنيم يعني مثلاً مي‌گوييم اين دو برابر User Story اول زمان مي‌برد. اينكار در Iteration هاي بعدي مفيد واقع خواهد شد، چون در Iteration بعدي مقدار زمان واقعي صرف شده بر روي تعدادي از User Story ها را مي‌دانيم بنابراين تخمين‌هاي ديگر User Story ها دقيق‌تر خواهد شد.
تكليف زمان لازم براي تدارك ديدن Infrastructure اوليه چه مي‌شود؟ منظور اين است كه تخمين كارهايي كه در ابتداي پروژه براي شروع كار لازم است و جزء هيچكدام از User Story ها قرار نمي‌گيرد اما پيش‌نيازي براي خيلي از آنهاست. مانند راه‌اندازي يك لايه براي ارتباط با DB يا راه‌اندازي يك Servlet Engine؟ اينها چيزهايي نيست كه مستقلاً براي كاربر معنا داشته باشد و در User Story ها نمي‌آيد. براي اينگونه نيازمندي‌ها مي‌بايست موارد زير را رعايت كرد:
بعد از نوشتن User Story ها، مشتري آنها را به ترتيب اولويت Sort مي‌كند و User Story هايي كه در Iteration اول بايد انجام شوند مشخص مي‌شود، به مجموعه اين كارها (نوشتن User Story، تخمين و اولويت‌بندي و انتخاب User Story ها) در ادبيات XP، برنامه ريزي يا Planning Game گفته مي‌شود.
بعد از آن شما مشغول پياده‌سازي خواهد شد البته طبق Practice هايي كه قبلاً شرح داديم يعني Test First Programming، Pair Programming، Continuous Integration و ... . بعد از يك هفته يا دو هفته كه دوره به پايان رسيد، User Story هايي كه مشتري اولويت‌بندي كرده بود، تحت يك Release ارائه مي‌شود.
مشتري در سايت توسعه در طي اين 2 هفته چه كار مي‌كند؟ تست. مشتري بعد از اينكه هر قسمت پياده‌سازي شد اولين نفري خواهد بود كه با سيستم تعامل كرده، آن را تست مي‌كند و فيدبك مي‌دهد.
محاسبه سرعت: در پايان هر Iteration سرعت كار و مدت زمان باقي مانده از كار تخمين زده مي‌شود. چون تخمين هر User Story بصورت نسبي بيان شده و چندين User Story پياده شده و زمان واقعي آنها مشخص شده، مي‌توانيم محاسبه كنيم اگر با همين سرعتي كه تا كنون داشته‌ايم كار كنيم چه مدت ديگر انجام پروژه بطول خواهد كشيد. بديهي است هر چه تعداد بيشتري Iteration انجام داده باشيد مي‌توانيد تخمين بهتر و مطمئن‌تري بزنيد.
چه زماني پروژه به پايان مي‌رسد؟ وقتي مشتري بگويد ديگر كافي است. يعني User Story هاي باقيمانده آنقدر كم‌اهميت باشد كه مشتري حاضر نباشد برايش هزينه كند! يكي از مزاياي XP اين است كه مشتري همان مقدار دريافت مي‌كند كه مي‌خواهد نه بيشتر و نه كمتر. چون در روش‌هاي ديگر مي‌دانيد خيلي مواقع در سيستم نهايي چيزهايي وجود دارد كه از نظر مشتري خيلي مهم نيستند و بجاي آن برخي چيزهاي مهم‌تر اصلاً وجود ندارد.
چطور مي‌توان XP را در سازمان خودمان راه بياندازيم؟ اول بايد مزايا و فوايد آن تبيين شود. الان طرفداران XP واقعاً زياد هستند. براي شروع كار، بهترين روش اين است كه يك فردي كه قبلاً به شيوه XP كار كرده به تيم ملحق شود. اگر كسي را نداريد اول يك تست بزنيد كه آيا مي‌توانيد Test Driven Development و Pair Programming داشته باشيد؟ يعني آيا احساس راحتي با اين روش كار مي‌كنيد و مي‌توانيد با آن كنار بياييد. چون برخي افراد با Pair Programming مشكل دارند.
چطور مديريت را راضي كنيم؟ مي‌توانيد از ابتدا مديريت را قانع نكنيد و كار را شروع كنيد و بعد از يكي دو هفته وقتي سرعت پيشرفت كار افزايش يافته، آن موقع مديريت را قانع كنيد البته يك مشكلي كه خواهيد داشت اين است كه بدون پشتيباني مديريت نخواهيد توانست مشتري را در سايت خودتان داشته باشيد! مي‌توان گاهي مواقع برخي Practice هاي XP را كنار گذاشت اما هيچگاه نمي‌توان Unit Test و Refactor را از XP حذف كرد.
متأسفانه در خيلي از پروژه‌ها اين ايده كه نماينده‌اي از مشتري تمام‌وقت در سايت ما باشد عملي نيست. اين بيشتر برمي‌گردد به فرهنگي كه براي دهه‌ها براي توليد نرم‌افزار شكل گرفته است كه ارتباطات بر اساس مستندات انجام مي‌شود. در اين شرايط ايده‌اي كه Arno مطرح مي‌كند (البته مي‌گويد ايده شخصي خودش است و در مراجع XP نيامده) اين است كه يك نفر از تيم توسعه نقش Proxy را ايفاء كند و كليه ارتباطات با مشتري (تلفن، email و ...) از طريق او انجام شود.
يكي از اشكالات كه به XP گرفته مي‌شود اين است كه در XP همه توسعه‌دهندگان بايد همه تكنولوژي‌ها را بشناسند مثلاً همه بايد كار با DB، كار GUI، كار با XML و ... را بدانند. يا مي‌گويند XP يك روش است كه بدرد يك برنامه‌نويس تنها مي‌خورد كه بخواهد همه كار را خودش بكند نه گروهي كه از مهارت‌هاي مختلف تشكيل يافته است. اما واقعاً اينگونه نيست بلكه كافيست در هر يكي از زمينه‌ها لااقل يك فرد خبره داشته باشيد و اگر فرد ديگري بخواهد درگير كاري شود كه به هريك از اين زمينه‌ها مرتبط است كافيست او را با فرد خبره آن زمينه Pair كنيم به اين ترتيب انتشار دانش هم خواهيم داشت.
يك فهم بد در مورد XP و در كل در مورد روش‌هاي Agile وجود دارد كه اين روش‌ها ضابطه‌مند نيستند و كارها در آن با عجله صرف انجام مي‌شود و هيچ مستندسازي وجود ندارد. برخلاف اين برداشت، Arno مي‌گويد به نظر او XP ، سفت‌ و سخت‌ترين و ضابطه‌مندترين روشي است كه تا بحال ديده است:
گرچه حجم عظيمي از مستندسازي در XP انجام نمي‌شود اما درك كردن طراحي‌ها و معماري از روي كد در XP كار سختي نيست زيرا: