مقالات

برنامه نویسی افراطی (XP) چیست؟، بر چه ارزش ها، اصول و شیوه هایی استوار است

شما با برنامه نویسی آشنا هستید، اما برنامه نویسی افراطی (به اختصار XP) هنوز برای شما کمی رمز و راز است.

اجازه ندهید این نام شما را ناامید کند، خطر از دست دادن اطلاعات مفید را دارید.

در این مقاله قصد داریم هر آنچه را که باید در مورد برنامه نویسی افراطی بدانید را پوشش دهیم تا بتوانید از آن به نفع خود استفاده کنید.

برنامه نویسی شدید (XP) چیست؟

برنامه نویسی افراطی یک متدولوژی توسعه نرم افزار است که بخشی از آن چیزی است که در مجموع به عنوان متدولوژی چابک شناخته می شود. XP بر اساس ارزش‌ها، اصول و شیوه‌ها ساخته شده است و هدف آن این است که تیم‌های کوچک و متوسط ​​را قادر به تولید نرم‌افزار با کیفیت بالا و انطباق با نیازهای در حال تغییر و تحول کند.

آنچه XP را از سایر متدولوژی های چابک متمایز می کند این است که XP بر جنبه های فنی توسعه نرم افزار تأکید دارد. برنامه نویسی شدید در مورد نحوه کار مهندسان دقیق است زیرا پیروی از روش های مهندسی به تیم ها اجازه می دهد کد با کیفیت بالا را با سرعتی پایدار ارائه دهند.

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

برنامه نویسی شدید (XP) چگونه کار می کند؟

XP، بر خلاف روش‌های دیگر، بر اساس ارزش‌ها و اصولی است که از نظر شیوه‌های مهندسی مهم و مرتبط هستند.

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

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

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

ارزش های برنامه نویسی افراطی XP

ارزش XP: ارتباط، سادگی، بازخورد، شجاعت و احترام. بیایید به هر یک از آنها با جزئیات بیشتری نگاه کنیم.

ارزش ها و اصول برنامه نویسی افراطی

طراحی BlogInnovazione.آن از تصویر alexsoft.com

Comunicazione: فقدان ارتباط مانع از جریان یافتن دانش در یک تیم می شود. اغلب، هنگامی که مشکلی وجود دارد، کسی از قبل می داند که چگونه آن را برطرف کند. اما عدم ارتباط آنها را از یادگیری در مورد مشکل یا کمک به حل آن باز می دارد. بنابراین، مشکل در نهایت دو بار حل می شود و باعث تولید زباله می شود.

سادگی: سادگی می گوید که شما همیشه برای انجام ساده ترین کاری که جواب می دهد تلاش می کنید. اغلب به اشتباه درک می شود و به عنوان ساده ترین چیز، نقطه، با نادیده گرفتن بخش "که کار می کند" در نظر گرفته می شود.

همچنین مهم است که به یاد داشته باشید که سادگی بسیار زمینه ای است. آنچه برای یک تیم ساده است برای تیم دیگر پیچیده است و کاملاً به مهارت، تجربه و دانش هر تیم بستگی دارد.

بازخورد: بازخورد در متدولوژی‌های سنتی‌تر توسعه نرم‌افزار آبشاری اغلب «خیلی کم، خیلی دیر» است.

با این حال XP تغییرات را پذیرفته و تیم های XP برای بازخورد به موقع و دائمی تلاش می کنند. در صورت نیاز به اصلاح دوره، XPers می‌خواهد در اسرع وقت بداند.

چرخه برنامه نویسی شدید

طراحی BlogInnovazione.آن از تصویر alexsoft.com

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

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

چیزی که ایده عالی به نظر می رسد ممکن است در عمل چندان خوب عمل نکند. از این رو، کد تمام شده نیز مانند یک محصول توزیع شده، منبع بازخورد است.

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

شجاعت: کنت بک defiشجاعت به عنوان «اقدام مؤثر در مواجهه با ترس» تعریف شده است. به عنوان یک مهندس نرم افزار، شما باید از چیزهای زیادی بترسید و بنابراین فرصت های زیادی برای نشان دادن شجاعت دارید.

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

توجه: یک فرض اساسی XP این است که همه به کار خود اهمیت می دهند. اگر دقت و احترامی وجود نداشته باشد، هیچ برتری فنی نمی تواند پروژه را نجات دهد.

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

اصول برنامه نویسی شدید XP

اصول راهنمایی خاص تری نسبت به ارزش ها ارائه می کنند. آنها دستورالعمل هایی هستند که ارزش ها را روشن می کنند و آنها را واضح تر و کمتر مبهم می کنند.

طراحی BlogInnovazione.آن از تصویر alexsoft.com

برای مثال، تنها بر اساس ارزش شجاعت، ممکن است به این نتیجه برسید که توصیه می شود فوراً تغییر بزرگی در برنامه خود ایجاد کنید. با این حال، اصل Baby Steps به ما می گوید که تغییرات بزرگ خطرناک هستند. بنابراین، به جای آن، موارد کوچک را ترجیح دهید.

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

اقتصاد: در XP، تیم ها همیشه به واقعیت های اقتصادی توسعه نرم افزار توجه می کنند، به طور مداوم ریسک های اقتصادی و نیازهای پروژه را ارزیابی می کنند.

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

منافع مشترک: بعد از XP، از راه حل هایی که به ضرر یک طرف به ضرر طرف دیگر است، اجتناب می کنید. به عنوان مثال، مشخصات توسعه یافته ممکن است به شخص دیگری کمک کند تا آن را درک کند، اما شما را از اجرای آن منحرف می کند و آن را برای کاربرانتان به تاخیر می اندازد.

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

منفعت (نفع متقابل): اگر یک راه حل داده شده در یک سطح کار کند، ممکن است در سطح بالاتر یا پایین تر نیز کار کند. به عنوان مثال، دریافت بازخورد اولیه و ثابت به درجات مختلف در XP در خطر است.

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

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

تنوع: شما و همکارانتان از دیدگاه‌ها، مهارت‌ها و نگرش‌های متنوعی بهره می‌برید. چنین تنوعی اغلب منجر به درگیری می شود، اما این اشکالی ندارد.

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

بازتاب: تیم های بزرگ به کار خود فکر می کنند و چگونگی بهتر شدن را تجزیه و تحلیل می کنند. XP فرصت های زیادی را برای این کار ارائه می دهد. نه فقط در چرخه های هفتگی و سه ماهه، بلکه در هر عملی که تبلیغ می کند.

علاوه بر تحلیل منطقی، باید احساسات را نیز در نظر گرفت. قبل از اینکه بتوانید در مورد هر چیزی استدلال کنید، دل شما می تواند به شما اطلاع دهد. و بنابراین او می تواند با افراد غیر فنی صحبت کند، آنها می توانند سؤالاتی بپرسند که فرصت های کاملاً جدیدی را ایجاد می کنند.

فلوسو: متدولوژی‌های سنتی توسعه نرم‌افزار دارای مراحل مشخصی هستند که مدت طولانی دوام می‌آورند و فرصت کمی برای بازخورد و اصلاح دوره دارند. در عوض، توسعه نرم‌افزار در XP در فعالیت‌هایی اتفاق می‌افتد که به طور مداوم و در یک "جریان" ارزش ثابت رخ می‌دهند.

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

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

عیب ها را بگیرید. هیچ تاکتیک واحدی وجود ندارد که بتواند از فرار همه عیوب از تولید جلوگیری کند.

بنابراین راه حل XP این است که مجموعه ای از معیارهای کیفیت را روی هم قرار دهد. برنامه نویسی جفت، آزمایش، ادغام مداوم. هر کدام یک خط دفاعی واحد، با هم یک دیوار عملا غیر قابل نفوذ.

شکست: شکست وقتی به دانش تبدیل شود هدر نمی رود. اقدام و یادگیری سریع چیزهایی که کار نمی کند بسیار مؤثرتر از بی عملی ناشی از عدم تصمیم گیری هنگام انتخاب از بین گزینه های زیاد است.

qualità: مردم اغلب فکر می کنند که بین کیفیت و سرعت دوراهی وجود دارد.

برعکس است: تلاش برای بهبود کیفیت چیزی است که شما را سریع‌تر می‌کند.

خبرنامه نوآوری
مهم ترین اخبار نوآوری را از دست ندهید. برای دریافت آنها از طریق ایمیل ثبت نام کنید.

برای مثال، refactoring – تغییر ساختار کد بدون تغییر رفتار آن – عملی است که درک و تغییر کد را آسان‌تر می‌کند. در نتیجه، کمتر احتمال دارد که نقص های کد را معرفی کنید، که به شما اجازه می دهد ابتدا ارزش بیشتری را با عدم نیاز به رفع اشکال ارائه دهید.

قدم های کوچک: تغییرات بزرگ خطرناک هستند. XP با ایجاد تغییرات در مراحل کوچک، در هر سطح، این خطر را کاهش می دهد.

برنامه نویسان با استفاده از توسعه تست محور کد را در مراحل کوچک می نویسند. آنها کد خود را به جای هر چند هفته یا حتی ماه یک بار در روز چندین بار در خط اصلی ادغام می کنند. خود پروژه در چرخه های کوتاه به جای فازهای طولانی مدت انجام می شود.

مسئولیت پذیرفته شد: در XP، مسئولیت باید پذیرفته شود، هرگز اختصاص داده نشود.

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

شباهت ها و تفاوت ها با روش های سنتی و غیر چابک

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

XP به طور قابل توجهی با روش های سنتی متفاوت است، به عنوان مثال، آبشاری، اجتناب از فازهای طولانی مدت.

  • به جای مرحله برنامه ریزی، در XP شما در ابتدای هر چرخه توسعه برنامه ریزی می کنید که معمولاً فقط یک هفته طول می کشد.
  • به جای آزمایش اپیزودها، برنامه خود را در اسرع وقت آزمایش کنید: یعنی قبل از اجرای کد واقعی.
  • به‌جای اینکه ویژگی‌ها را به‌صورت مجزا در طول مراحل پیاده‌سازی طولانی اجرا کنید و سپس برای ادغام مشارکت‌های خود در خط اصلی تلاش کنید، در بخش‌های کوچک کار می‌کنید و آنها را تا حد امکان ادغام می‌کنید.

XP چه تفاوتی با سایر متدولوژی های چابک دارد؟

برنامه نویسی افراطی، به دلیل ماهیت خود، اشتراکات زیادی با سایر متدولوژی های چابک دارد، اما در بین آنها نیز منحصر به فرد است.

اکثر متدولوژی های توسعه دیگر در مورد چگونگی انجام کار چیز زیادی نمی گویند. از سوی دیگر، XP در این مورد بسیار خوش بین است و تاکید زیادی بر روی شیوه های مهندسی نرم افزار دارد.

برنامه نویسی افراطی در مقابل اسکرام

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

چارچوب اسکرام

طراحی BlogInnovazione.en تصویر راه حل های خالص

همچنین XP به وضوح در مورد برنامه نویسی است. از سوی دیگر، اسکرام را می توان برای هر پروژه ای که از رویکرد تکراری سود می برد، اعمال کرد.

XP تغییرات اجزای خود را می پذیرد. تیم ها برای اصلاح شیوه ها بر اساس نیازهای خاص خود توانمند شده و حتی تشویق می شوند. از سوی دیگر، راهنمای اسکرام بر این نکته تاکید دارد که «اگرچه تنها بخش‌هایی از اسکرام قابل پیاده‌سازی هستند، اما نتیجه اسکرام نیست».

همچنین، اسکرام چارچوبی است که برای انجام کار باید با متدولوژی ها و شیوه ها تکمیل شود.

این بدان معنی است که کار در برنامه نویسی شدید و اسکرام به شدت توصیه می شود.

نقش ها و مسئولیت ها

به گفته کنت بک، یک تیم بالغ XP نباید نقش‌های سفت و سختی را تعیین کند، اما بداند که نقش‌ها می‌توانند برای تیم‌های تازه کار مفید باشند تا زمانی که شروع به کاهش سرعت کنند یا همکاری را دشوار کنند.

بیایید به چند نقش کلیدی نگاه کنیم:

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

روش ها و تکنیک ها

اینها رویه هایی هستند که در XP به کار گرفته شده اند. آنها به سه گروه اصلی تقسیم می شوند: مهندسی نرم افزار، محل کار و مدیریت پروژه.

مهندسی نرم افزار

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

محدودیت ده دقیقه: Required اجازه می دهد تا 10 دقیقه برای ساخت کل پروژه، از جمله اجرای تمام تست های خودکار، حداکثر در ده دقیقه. این محدودیت برای ساده و موثر نگه داشتن آزمایش است.

تست های قبل از برنامه نویسی: پیاده سازی ویژگی ها با استفاده از رویکرد تست اول، همچنین نامیده می شود توسعه تست محور (TDD). TDD شامل توسعه با استفاده از یک روش تکراری ساده است:

  • نوشتن کد پس از شکست تست؛
  • سپس کد تولید را برای قبولی در آزمون بنویسید.
  • در صورت لزوم، کد تولید خود را تغییر دهید تا آن را تمیزتر و درک کنید.

TDD چندین مزیت به همراه دارد.

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

ثانیا، TDD به برنامه نویسان اجازه می دهد تا به کدهایی که می نویسند اعتماد کنند و یک ریتم حلقه خوب ایجاد می کند که در آن مرحله بعدی همیشه واضح است.

آخرین اما نه کم اهمیت، استفاده از TDD از ابتدا پوشش 100٪ کد را تضمین می کند. سپس مجموعه آزمایشی واقعاً به یک شبکه ایمنی برای تغییرات آتی تبدیل می‌شود، که بازسازی کد را تشویق می‌کند و دایره‌ای از کیفیت را ایجاد می‌کند.

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

ادغام مداوم: در XP، شما چندین بار در روز کار خود را در مخزن اصلی مشترک ادغام می کنید و باعث ایجاد خودکار کل سیستم می شود. ادغام هرچه زودتر و اغلب اوقات ممکن است به طور چشمگیری هزینه ادغام را کاهش می دهد زیرا احتمال وقوع ادغام و تضادهای منطقی را کاهش می دهد. همچنین مسائل زیست محیطی و اعتیاد را آشکار می کند.

کد مشترک (مالکیت جمعی): XP کد اشتراکی یا مالکیت جمعی را ترویج می کند: هر توسعه دهنده مسئول همه کدها است. اگر اصل تنوع را در نظر بگیریم، تبادل اطلاعات را تشویق می کند، عامل اتوبوس تیم را کاهش می دهد و کیفیت کلی هر ماژول را افزایش می دهد.

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

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

کد و تست: این عمل به این معنی است که کد منبع، از جمله تست ها، تنها مصنوع دائمی یک پروژه نرم افزاری است. درگیر شدن در تولید انواع دیگر مصنوعات، از جمله اسناد، اغلب بیهوده است زیرا ارزش واقعی برای مشتری ایجاد نمی کند.

اگر به مصنوعات یا اسناد دیگری نیاز دارید، سعی کنید آنها را از طریق کد تولید و آزمایشات تولید کنید.

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

محیط کار

کنار هم بنشینید: در XP، تیم ها ترجیح می دهند با هم در یک فضای باز کار کنند. این تمرین باعث ارتقای ارتباط و احساس تعلق به یک تیم می شود.

کل تیم: همه کسانی که برای موفقیت پروژه مورد نیاز هستند بخشی از تیم XP هستند. این بسیار زمینه ای است - برای هر تیم متفاوت است - و پویا است، می تواند در یک تیم تغییر کند.

فضاهای کاری اطلاعاتی: یک فضای کاری اطلاعاتی از فضای فیزیکی تیم برای نمایش اطلاعاتی استفاده می کند که به همه اجازه می دهد در یک نگاه از پیشرفت پروژه مطلع شوند. نحوه انجام این کار می تواند متفاوت باشد، از یادداشت ها و نمودارهای فیزیکی گرفته تا اسکرین شات هایی که تابلوها و داشبوردهای Kanban را از نرم افزار مدیریت پروژه نشان می دهد.

کار پر انرژی: در XP فقط تا زمانی کار می کنید که بتوانید کار پر انرژی انجام دهید. ساعات کاری باید حداکثر به 40 ساعت در هفته محدود شود.

مدیریت پروژه

Analisi- الزامات کاربر را در قالبی که به عنوان تحلیل کاربر شناخته می شود بنویسید. تجزیه و تحلیل کاربر یک نام کوتاه و توصیفی دارد و همچنین توضیح کوتاهی از آنچه باید پیاده سازی شود.

شل: هنگام برنامه ریزی یک چرخه، وظایف جزئی را اضافه کنید که در صورت نیاز، تیم می تواند آنها را رها کند. اگر تیم بیش از حد ارائه دهد، همیشه می توان داستان های بیشتری اضافه کرد.

چرخه (ماهانه و هفتگی): توسعه در XP در دو چرخه اصلی رخ می دهد: چرخه هفتگی و چرخه ماهانه.

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

چرخه هفتگی: چرخه هفتگی "نبض" یک پروژه XP است. این چرخه با جلسه ای شروع می شود که در آن مشتری انتخاب می کند که چه داستان هایی را می خواهد در طول هفته بسازد. علاوه بر این، تیم کار خود، از جمله پیشرفت هفته گذشته را بررسی می کند و در مورد راه هایی برای بهبود روند خود فکر می کند.

چرخه ماهانه: هر ماه، تیم فرصت های بهبود را در فرآیند خود منعکس و شناسایی می کند. مشتری یک یا چند موضوع را برای آن ماه به همراه تحلیل های موجود در این مضامین انتخاب می کند.

چگونه با برنامه نویسی شدید شروع به کار کنیم؟
یادگیری مهارت های فنی و عادات XP ممکن است سخت باشد. برخی از روش ها ممکن است برای برنامه نویسانی که به آنها عادت ندارند غریب به نظر برسد.

Ercole Palmeri

خبرنامه نوآوری
مهم ترین اخبار نوآوری را از دست ندهید. برای دریافت آنها از طریق ایمیل ثبت نام کنید.

مقالات اخیر

آینده اینجاست: چگونه صنعت کشتیرانی اقتصاد جهانی را متحول می کند

بخش دریایی یک قدرت واقعی اقتصادی جهانی است که به سمت یک بازار 150 میلیاردی حرکت کرده است.

1 می 2024

ناشران و OpenAI توافق نامه هایی را برای تنظیم جریان اطلاعات پردازش شده توسط هوش مصنوعی امضا می کنند.

دوشنبه گذشته، فایننشال تایمز از قراردادی با OpenAI خبر داد. FT مجوز روزنامه نگاری در سطح جهانی خود را صادر می کند…

آوریل 30 2024

پرداخت های آنلاین: در اینجا نحوه پرداخت خدمات جریانی شما را برای همیشه توضیح می دهد

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

آوریل 29 2024

Veeam دارای جامع ترین پشتیبانی از باج افزار، از محافظت تا پاسخ و بازیابی است

Coveware توسط Veeam به ارائه خدمات پاسخگویی به حوادث اخاذی سایبری ادامه خواهد داد. Coveware قابلیت‌های پزشکی قانونی و اصلاحی را ارائه می‌دهد…

آوریل 23 2024

نوآوری را به زبان خود بخوانید

خبرنامه نوآوری
مهم ترین اخبار نوآوری را از دست ندهید. برای دریافت آنها از طریق ایمیل ثبت نام کنید.

ما را دنبال کنید