ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్

అనేక లూప్‌ల కాల వ్యవధులతో కూడిన ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ (XP) యొక్క ప్లానింగ్ మరియు ఫీడ్‌బ్యాక్ లూప్‌లు

మూస:Software development process ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్(XP) అనేది ఒక సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ పరిశోధన పద్ధతి. ఇది మారుతున్న వినియోగదారుడి అవసరాలకు అనుగుణంగా సాఫ్ట్‌వేర్ నాణ్యత మరియు క్రియాశీలతను అభివృద్ధి చేస్తుంది. ఒక విధమైన చురుకైన సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ వలే, ఇది లఘు అభివృద్ధి చక్రాల్లో (టైమ్‌బాక్సింగ్ (ఒక విధమైన కాల నిర్వహణ పద్ధతి)) తరచుగా "విడుదలల"కు సిఫారసు చేస్తుంది. ఉత్పాదకతను మెరుగుపరచడం మరియు కొత్త వినియోగదారుడి అవసరాలను ఆమోదించే చెక్‌పాయింట్లు ఏర్పాటు చేయడం దీని ముఖ్యోద్దేశం.

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ యొక్క ఇతర ముఖ్యాంశాలు: జంట ప్రోగ్రామింగ్ లేదా విస్తృత కోడ్ సమీక్ష చేయడం, అన్ని కోడ్ల యూనిట్ టెస్టింగ్, వాస్తవంగా అవసరమైతే తప్ప విశిష్టాంశాల ప్రోగ్రామింగ్‌ను పక్కనపెట్టడం, విధి నిర్వహణ నిర్మాణం, కోడ్‌లో సరళత మరియు స్పష్టత, ఒకవేళ కాలం గడుస్తుంటే, వినియోగదారుడి అవసరాల్లో మార్పులను ఊహించడం మరియు సమస్యను చక్కగా అర్థం చేసుకోవడం, వినియోగదారుడితోనూ మరియు ప్రోగ్రామర్ల మధ్య తరచూ సంభాషణలు కొనసాగించడం. కొందరు మంచైతే, మరింత మంది ఉత్తమం అనే సిద్ధాంతం ఆధారంగా, సంప్రదాయక సాఫ్ట్‌వేర్ ఇంజినీరింగ్ విధానాల యొక్క లాభదాయక అంశాలను "ఉన్నత" శిఖరాలకు తీసుకెళ్లొచ్చనే ఆలోచన ద్వారా ఈ పరిశోధనపద్ధతికి ఈ పేరు వచ్చింది. దీనికి అత్యంత స్వేచ్ఛా పదాంశం మరియు లక్ష్యరహిత "కౌబాయ్ కోడింగ్‌"తో సంబంధం లేదు. ఇది "డెత్ మార్చ్‌" పని షెడ్యూళ్లను సిఫారసు చేయదు. అందుకు బదులు నిరంతరాయ గమనంతో పని చేయడాన్ని సూచిస్తుంది.

అయితే ఇందులో అనేక సాధ్యపర లోపాలను, విమర్శకులు ఎత్తిచూపారు. వీటిలో అస్థిర అవసరాలు, వినియోగదారుడి వివాదాలకు సంబంధించిన రాజీలకు ఎలాంటి ఆధారాలు లేకపోవడం, సమగ్ర రూపకల్పన వివరణ లేదా డాక్యుమెంట్ లేకపోవడం ముఖ్యమైనవి. మూస:TOC limit

చరిత్ర

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్‌ను కెంట్ బెక్‌ క్రిస్లర్ కాంప్రిహెన్సివ్ కాంపెన్సేషన్ సిస్టమ్ (C3) పేరోల్ (జీతాలు తీసుకొను ఉద్యోగుల జాబితా) ప్రాజెక్టుపై పనిచేస్తున్నప్పుడు రూపకల్పన చేశాడు. బెక్ మార్చి, 1996లో C3 ప్రాజెక్టు నాయకుడుగా మారాడు. ప్రాజెక్టులో ఉపయోగించిన డెవలప్‌మెంట్ పద్ధతిని మరింత అభివృద్ధి చేయడానికి పూనుకున్నాడు. దానిపై ఒక పుస్తకం (అక్టోబరు, 1999లో ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్ అనే పుస్తకం ముద్రించబడింది) రాశాడు. ఫిబ్రవరి, 2000లో తమ కంపెనీని డైమ్లర్-బెంజ్ హస్తగతం చేసుకున్న తర్వాత C3 ప్రాజెక్టును క్రిస్లర్ రద్దు చేశాడు.

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ సాపేక్షకంగా కొత్తదే అయినప్పటికీ, దీని పలు సాధనలు కొద్దికాలం పాటు అంతటా విస్తరించాయి. ఈ పరిశోధనపద్ధతి "ఉత్తమ విధానాల"ను ఉన్నత శిఖరాలకు తీసుకెళ్లింది. ఉదాహరణకు, "ప్రతి సూక్ష్మ-వృద్ధికి ముందు టెస్ట్ ఫస్ట్ డెవలప్‌మెంట్, వ్యూహం మరియు రాత పరీక్షలను నిర్వహించే విధానం" 1960ల్లో NASA ప్రాజెక్టు మెర్క్యురీ ప్రారంభం నుంచే ఉపయోగించడం జరిగింది.మూస:Harvard citation 1984లో ప్రచురించిన తన పుస్తకంలో రీఫ్యాక్టరింగ్, మాడ్యులారిటీ, బాటమ్-అప్ మరియు ఇంక్రిమెంటల్ డిజైన్‌లను లియో బ్రాడీ వివరించాడు.

మూలాలు

1990ల్లో సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ అనేది రెండు భారీ ప్రాబల్యాల ద్వారా రూపుదిద్దుకుంది. అంతర్గతంగా, ప్రొసీజరల్ ప్రోగ్రామింగ్ స్థానంలో ఆబ్జెక్ట్-ఓరియంటెడ్ ప్రోగ్రామింగ్ వచ్చి చేరింది. ఇందుకు కారణం పరిశ్రమలోని కొందరు ఈ ప్రోగ్రామింగ్ రూపావళి వైపు మొగ్గుచూపడం. ఇక బహిర్గతంగా చూస్తే, ఇంటర్నెట్ వ్యాప్తి మరియు డాట్-కామ్ విజృంభణ అనేవి పోటీయుత వ్యాపార అంశాలుగా మార్కెట్ వేగం మరియు కంపెనీ వృద్ధిని నొక్కిచెప్పాయి. శరవేగంగా మారుతున్న అవసరాలతో స్వల్ప ప్రాడక్ట్ లైఫ్-సైకిల్స్ (మార్కెటింగ్)కు డిమాండ్ ఏర్పడింది. అయితే ఇవి తరచూ సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ సంప్రదాయ పద్ధతులతో ఇమడలేకపోయాయి.

పరిశోధనా వస్తువుగా క్రిస్లర్, స్మాల్‌టాక్ భాషగా మరియు జెమ్‌స్టోన్ డాటా యాక్సెస్ లేయర్‌గా పేరోల్ సిస్టమ్స్‌ను ఉపయోగించి, ఆబ్జెక్ట్ టెక్నాలజీలను వాడటానికి ఒక అత్యుత్తమ మార్గాన్ని కనుక్కోవడానికి క్రిస్లర్ కాంప్రిహెన్సివ్ కాంపెన్సేషన్ సిస్టమ్ ప్రారంభించబడింది. సిస్టమ్‌ పెర్ఫార్మెన్స్ ట్యూనింగ్ కోసం ప్రముఖ స్మాల్‌టాక్ సాధకుడు కెంట్ బెక్‌,ను వారు పరిచయం చేశారు. వారు తమ డెవలప్‌మెంట్ ప్రక్రియతో ఎదుర్కొంటున్న వివిధ ఇబ్బందులను గుర్తించడంతో అతని పాత్ర మరింత విస్తరించబడింది. తన భాగస్వామి వార్డ్ కన్నింగ్‌హామ్‌తో కలిసి చేసిన పని ఆధారంగా వారి సాధనల్లోని కొన్ని మార్పులను సిఫారసు చేయడం మరియు వాటి అమలుకు అతను ఈ అవకాశాన్ని సద్వినియోగం చేసుకున్నాడు. పద్ధతుల ప్రారంభ భావనను బెక్ వివరించాడు.

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.

ఈ పద్ధతులను అభివృద్ధి చేయడం మరియు లోపాల సవరణకు రాన్ జెఫ్రీస్‌ని బెక్ తమ ప్రాజెక్టులోకి ఆహ్వానించాడు. అప్పటి నుంచి C3 బృందంలో ఈ సాధనలు (విధానాలు) అలవాట్లుగా మారే విధంగా జెఫ్రీస్ ఒక కోచ్ వలే వ్యవహరించాడు.

XP మూల సూత్రాలు మరియు సాధనలకు సంబంధించిన సమాచారం వాస్తవిక Wiki మరియు కన్నింగ్‌హామ్ యొక్క WikiWikiWebపై చర్చల ద్వారా ప్రపంచమంతా విస్తరించబడింది. పలువురు సహాయకులు సంబంధిత ఆలోచనలపై చర్చించడం మరియు విస్తరించడం చేశారు. ఫలితంగా కొన్ని ఉప పరిశోధనపద్ధతులు ఆవిష్కృతమయ్యాయి (చురుకైన సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ చూడండి). అంతేకాక సుమారు 1999 ప్రాంతంలో XP వెబ్‌సైటు "http://www.extremeprogramming.org"లోని ఒక హైపర-టెక్స్ట్ సిస్టమ్ మ్యాపును ఉపయోగించి, కొన్నేళ్ల పాటు XP ముఖ్యాంశాలను వివరించారు.

బెక్ తన సొంత పుస్తకం ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్ (1999, ISBN 0-201-61641-6)తో మొదలుపెట్టి, XPపై రాసిన పలు పుస్తకాలను సరిదిద్దాడు. తన ఆలోచనలను విస్తృతపరిచాడు. అవసరమైతే మరిన్ని మార్పులుచేర్పులకు మరియు ఆలకించడానికి ఇప్పటికీ సిద్ధంగా ఉన్నాడు. ఈ పుస్తకాలను రాసిన రచయితలు XP మరియు దాని సాధనలకు హాజరవుతూ, అనేక అంశాలను పరిశీలించారు. సాధనలను విమర్శిస్తూ, ఒక పుస్తకం రాయబడింది.

ప్రస్తుత పరిస్థితి

1990లు మరియు 2000ల్లో XP సంచలనం సృష్టించింది. దాని మూలాలకు పూర్తి భిన్నమైన అసంఖ్యాక రంగాల్లోనూ ఆమోదం పొందింది.

అత్యంత క్రమశిక్షణ అవసరమైన వాస్తవిక సాధనలు తరచూ పక్కదారి పట్టాయి. ఫలితంగా కఠినమైనవిగా భావించబడిన వీటిలోని కొన్ని సాధనలు తిరస్కరించబడటం లేదా పూర్తికాకుండా వ్యక్తిగత సైట్లపై విడిచిపెట్టడం జరిగింది. చురుకైన డెవలప్‌మెంట్ సాధనలు మనుగడ సాధించలేకపోయాయి. అయితే XP మాత్రం ఇప్పటికీ రూపుదిద్దుకుంటోంది. ఈ రంగంలో పొందిన అనుభవాల ద్వారా మరిన్న పాఠాలను జీర్ణించుకుంటోంది. ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్ రెండో ఎడిషన్‌లో బెక్ మరిన్ని విలువలు, సాధనలను పొందుపరచడంతో పాటు ప్రాథమిక మరియు పరిణామ సాధనల మధ్య భేదాలను వివరించాడు.

భావన

లక్ష్యాలు

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్ ఈ విధంగా వివరించింది, ఒక సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ విభాగంగా ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ అనేది ఎక్కువ నాణ్యత కలిగిన సాఫ్ట్‌వేర్‌ను మరింత లాభదాయకమైన రీతిలో నిపుణులు రూపొందించే విధంగా చేస్తుంది.

సంప్రదాయక సిస్టమ్ డెవలప్‌మెంట్ పద్ధతుల్లో (SSADM లేదా వాటర్‌ఫాల్ నమూనా వంటివి) సిస్టమ్ అవసరాలు ప్రాజెక్టు ప్రారంభంలోనూ మరియు తరచూ ఆ క్షణం మొదలుకుని నిర్ణయించబడతాయి. అంటే, మలి దశలో అవసరాల మార్పుకు అయ్యే ఖర్చు (సాఫ్ట్‌వేర్ ఇంజినీరింగ్ ప్రాజెక్టుల విషయంలో ఇది సర్వసాధారణమైనది) ఎక్కువగా ఉంటుందని అర్థం. ఇతర చురుకైన సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ పద్ధతుల మాదిరిగా, మార్పుకయ్యే ఖర్చును లఘు డెవలప్‌మెంట్ సైకిళ్లు ఒక దాని తర్వాత మరొకటి కాకుండా బహుళ సైకిళ్ల ద్వారా తగ్గించే ప్రయత్నాన్ని XP చేసింది. ఈ సిద్ధాంత మార్పులనేవి సహజమైనవి, దూరం చేయలేనివి మరియు సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ ప్రాజెక్టుల యొక్క వాంఛనీయ దృక్కోణం. అందువల్ల స్థిరమైన జంట అవసరాలను నిర్వచించే ప్రయత్నం చేయడానికి బదులు వీటి కోసం వ్యూహరచన చేయాలి.

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ చురుకైన ప్రోగ్రామింగ్ ముసాయిదా అగ్రభాగంలో అసంఖ్యాక ప్రధాన విలువలు, సూత్రాలు మరియు సాధనలను కూడా ఆవిష్కరించింది.

కార్యకలాపాలు

ఒక సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ ప్రక్రియలో చోటుచేసుకునే నాలుగు ముఖ్యమైన కార్యకలాపాలను XP వివరించింది.

కోడింగ్

సిస్టమ్ డెవలప్‌మెంట్ ప్రక్రియ యొక్క ఏకైక నిజమైన ప్రధాన ఉత్పత్తి కోడ్ అని XP మద్దతుదారులు వాదిస్తున్నారు. కోడ్ అంటే....కంప్యూటర్ అర్థవివరణ ఇచ్చే విధంగా రూపొందించిన సాఫ్ట్‌వేర్ సూచనలు. కోడ్ లేకుండా క్రియాత్మక ఉత్పత్తి అనేది ఉండదు.

అత్యంత ఆమోదయోగ్య పరిష్కారాన్ని కనుగొనడానికి కూడా కోడ్ ఉపయోగపడుతుంది. ఉదాహరణకు, ప్రోగ్రామింగ్ సమస్యకు వివిధ ప్రత్యామ్నాయాలతో ఇబ్బంది పడుతున్న వారికి XP సలహా ఇస్తుంది. వారు చేయాల్సిందల్లా అన్ని పరిష్కారాలను కోడ్ చేయడం మరియు స్వీయాత్మక పరీక్షల ద్వారా అత్యంత ఆమోదయోగ్యమైన పరిష్కారాన్ని గుర్తించడం.^{[citation needed]} ప్రోగ్రామింగ్ సమస్యలకు సంబంధించిన ఆలోచనలను తెలిపేందుకు కూడా కోడింగ్ దోహదపడుతుంది. ఎవరైనా ప్రోగ్రామర్ క్లిష్టమైన ప్రోగ్రామింగ్ సమస్యతో ఇబ్బంది పడుతూ, దాని పరిష్కారాన్ని తన సహచరులకు వివరించడానికి కష్టంగా భావించినప్పుడు, ముందుగా దానిని కోడ్ చేయాలి. తర్వాత దానిని ఉపయోగించి, అతడు లేదా ఆమె తను అర్థం చేసుకున్న దానిని వివరించాలి. కోడ్ అనేది ఎల్లప్పుడూ స్పష్టంగా మరియు క్లుప్తంగా ఉండాలి. ఒకటి కంటే ఎక్కువ మార్గాల్లో అర్థవివరణ ఇచ్చే విధంగా ఉండరాదని ఈ పరిస్థితి యొక్క ప్రతిపాదకులు పేర్కొన్నారు. ఇతర ప్రోగ్రామర్లు తమ ఆలోచనలను కోడింగ్ చేసి కూడా ఈ కోడ్‌పై ఫీడ్‌బ్యాక్ ఇవ్వగలరు.

టెస్టింగ్

ఏదైనా ఒక ఫంక్షన్ పనిచేస్తుందా లేదా అన్న విషయాన్ని దానిని పరీక్షిస్తే తప్ప ఎవరూ కచ్చితంగా చెప్పలేరు. తప్పులు మరియు డిజైన్ దోషాలు సాఫ్ట్‌వేర్ డెవలప్‌మెంట్‌లో సర్వవ్యాప్త సమస్యలు. ఒక చిన్న పరీక్ష కొన్ని తప్పులను తొలగించగలిగితే, భారీ స్థాయిలో పరీక్ష నిర్వహించడం మరిన్ని తప్పులను తొలగించగలదు అనేది ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ దృక్పథం.

• ఇవ్వబడిన విశిష్టాంశం కోరిన విధంగా పనిచేస్తుందా లేదా అన్న విషయాన్ని యూనిట్ టెస్ట్‌లు తెలుపుతాయి. ఒక ప్రోగ్రామర్ కోడ్‌ను "విచ్ఛిన్నం" చేయవచ్చని భావించి, పలు స్వీయాత్మక పరీక్షలు చేస్తాడు. అన్ని పరీక్షలు విజయవంతంగా నిర్వహించబడితే, కోడింగ్ పూర్తవుతుంది. తదుపరి విశిష్టాంశానికి (ఫీచర్) వెళ్లడానికి ముందు రాయబడిన కోడ్ యొక్క ప్రతి భాగం పరీక్షించబడుతుంది.
• సమ్మతి పరీక్షలు అనేవి ప్రోగ్రామర్లు అర్థం చేసుకున్న అవసరాలు వినియోగదారుడి యొక్క వాస్తవిక అవసరాలను సంతృప్తిపరుస్తాయా లేదా అన్న విషయాన్ని పరిశీలిస్తాయి. ఇవి రిలీజ్ ప్లానింగ్ యొక్క అన్వేషణ దశలో చోటుచేసుకుంటాయి.

"టెస్టేతన్" అనేది సహకార టెస్ట్ రైటింగ్ కోసం ప్రోగ్రామర్లు కలిసినప్పుడు జరిగే ఒక సంఘటన. అంటే సాఫ్ట్‌‍వేర్ టెస్టింగ్‌కు సంబంధించిన ఒక రకమైన సమూహ చర్య.

ఆలకించడం

సిస్టమ్ నుంచి వినియోగదారులు ఏమి కోరుకుంటారు మరియు ఏ "వ్యాపార తర్కం" అవసరం అన్న విషయాలను ప్రోగ్రామర్లు తప్పక ఆలకించాలి. సమస్యను ఎలా పరిష్కరించవచ్చు లేదా పరిష్కరించలేమా వంటి సాంకేతిక అంశాలకు సంబంధించిన ఫీడ్‌బ్యాక్‌ను వినియోగదారుడికి ఇచ్చే విధంగా ఈ అవసరాలను ప్రోగ్రామర్లు చక్కగా అవగతం చేసుకోవాలి. వినియోగదారుడు మరియు ప్రోగ్రామర్ మధ్య సంభాషణను ప్లానింగ్ గేమ్‌లో పొందుపరచడం జరిగింది.

డిజైనింగ్

సరళత దృష్ట్యా, సిస్టమ్ డెవలప్‌మెంట్‌కు కోడింగ్, టెస్టింగ్ మరియు లిజనింగ్ తప్ప మరేమీ అవసరముండదని బహుశా ఎవరైనా చెప్పొచ్చు. ఈ కార్యకలాపాలను చక్కగా నిర్వహిస్తే, ఫలితం సిస్టమ్ పనిచేసే విధంగా ఉంటుంది. అయితే ఆచరణలో, ఇది పనిచేయదు. రూపకల్పన లేకుండా ఎవరైనా దీర్ఘకాలం ప్రయత్నించవచ్చు. అయితే నిర్ణీత వ్యవధిలో పలు ఇబ్బందులు ఎదుర్కోవాల్సి వస్తుంది. సిస్టమ్ చాలా క్లిష్టంగా మారడం మరియు సిస్టమ్‌లోని పరాధీనతలు స్పష్టతను కోల్పోతాయి. సిస్టమ్‌లో లాజిక్‌ను నిర్వహించే ఒక రూపకల్పన నిర్మాణాన్ని (డిజైన్ స్ట్రక్షర్) రూపొందించడం ద్వారా ఈ సమస్యను అధిగమించవచ్చు. చక్కటి రూపకల్పన అనేది సిస్టమ్ పరిధిలోని అనేక పరాధీనతలను దూరం చేస్తుంది. అంటే, సిస్టమ్‌లోని ఒక భాగాన్ని మార్చడం వల్ల ఇతర భాగాలపై ఎలాంటి ప్రభావం ఉండదు.మూస:Facts

విలువలు

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ప్రాథమికంగా 1999లో నాలుగు విలువలను గుర్తించింది. ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్ రెండో ఎడిషన్‌లో ఒక కొత్త విలువను చేర్చారు. ఐదు విలువలను దిగువ పేర్కొనడం జరిగింది:

కమ్యూనికేషన్

సాఫ్ట్‌వేర్ వ్యవస్థల నిర్మాణానికి సిస్టమ్ డెవలపర్లకు సమాచార వ్యవస్థ అవసరాలు కావాలి. క్రమబద్ధ సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ పరిశోధనపద్ధతుల్లో, దీనిని డాక్యుమెంటేషన్ (ప్రమాణ పత్రరచన) ద్వారా పూర్తి చేస్తారు. ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ టెక్నిక్‌లు శరవేగ నిర్మాణ పద్ధతులుగానూ మరియు డెవలప్‌మెంట్ బృంద సభ్యుల్లో విస్తరించిన సంస్థాగత పరిజ్ఞానంగానూ చూడబడుతాయి. సిస్టమ్ వినియోగదారుల ఆలోచనతో సరిపోయే విధంగా అందరి డెవలపర్లకు వాటాయుత భావన కల్పించడం ప్రధాన లక్ష్యం. దీని ముగింపుగా, సరళమైన డిజైన్లు, మామూలు రూపకాలు, వినియోగదారులు మరియు ప్రోగ్రామర్ల భాగస్వామ్యం, తరచూ భాషా ప్రసారం మరియు ఫీడ్‌బ్యాక్‌లను ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ప్రోత్సహిస్తుంది.

సరళత

అత్యంత సరళమైన పరిష్కారం ద్వారా ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ప్రోత్సహిస్తుంది. అదనపు ఫంక్షనాలిటీని తర్వాత జోడించుకోవచ్చు. ఈ విధానానికి మరియు అత్యంత సంప్రదాయక సిస్టమ్ డెవలప్‌మెంట్ పద్ధతులకు మధ్య తేడా రేపటి, వచ్చే వారం లేదా వచ్చే నెల కంటే నేటి అవసరాలకు తగ్గట్లుగా డిజైనింగ్ మరియు కోడింగ్‌పై దృష్టి సారించడం. ఇది కొన్ని సందర్భాల్లో "యు ఆర్ నాట్ గొన్నా నీడ్ ఇట్" (YAGNI) పద్ధతి మాదిరిగా క్రోడీకరించబడుతుంది. భవిష్యత్తులో కొన్ని సందర్భాల్లో ఇది సిస్టమ్‌ మార్పుకు మరింత శ్రమించాల్సిన పరిస్థితులను కల్పించవచ్చన్న ప్రతికూలతను XP ప్రతిపాదకులు గుర్తించారు. సాధ్యపర భవిష్యత్ అవసరాలకు పెట్టుబడి చేయకపోవడం వల్ల కలిగే ప్రయోజనం వల్ల ఇది నష్టపరిహారం చెల్లించడం కంటే ఎక్కువవుతుందని మరియు తాము సుసంగతం కాక ముందే ఇది మారుతుందని వారి వాదన. అనిశ్చిత భవిష్యత్ అవసరాలకు కోడింగ్ మరియు డిజైనింగ్ అనేవి అవసరం లేని పనిపై వనరులను వినియోగించాల్సిన ఇబ్బందికర పరిస్థితిని తెలుపుతుంది. "కమ్యూనికేషన్" (సమాచార) విలువకు సంబంధించి, సరళమైన డిజైన్ మరియు కోడింగ్ కమ్యూనికేషన్ నాణ్యతను మెరుగుపరుస్తాయి. అతి సరళమైన కోడ్‌తో రూపొందించిన సరళమైన డిజైన్‌ను బృందంలోని ఎక్కువ మంది ప్రోగ్రామర్లు సులువుగా అర్థం చేసుకోగలరు.

ఫీడ్‌బ్యాక్

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ పరిధిలో ఫీడ్‌బ్యాక్ అనేది సిస్టమ్ డెవలప్‌మెంట్‌కు సంబంధించిన విభిన్న పరిమాణాలను తెలుపుతుంది.

• సిస్టమ్ ఫీడ్‌బ్యాక్: యూనిట్ టెస్ట్‌లు, రాయడం లేదా ఆవర్తన సమాకలన పరీక్షలు నిర్వహించడం ద్వారా మార్పులను అమలు చేసిన తర్వాత ప్రోగ్రామర్లు సిస్టమ్ స్థితి నుంచి ప్రత్యక్ష ఫీడ్‌బ్యాక్ పొందుతారు.
• వినియోగదారుడి ఫీడ్‌బ్యాక్ : ఫంక్షనల్ టెస్టులు (సమ్మతి పరీక్షలు

అని కూడా అంటారు) వినియోగదారుడు మరియు పరిశీలకులు రాస్తారు. తద్వారా వారు తమ సిస్టమ్ యొక్క ప్రస్తుత పరిస్థితికి సంబంధించిన వాస్తవిక ఫీడ్‌బ్యాక్ పొందుతారు. ఈ సమీక్ష ప్రతి రెండు లేదా మూడు వారాలకు ఒకసారి నిర్వహించబడుతుంది. తద్వారా వినియోగదారుడు డెవలప్‌మెంట్‌ను తేలికగా నిర్దేశించగలడు.

• బృందం యొక్క ఫీడ్‌బ్యాక్: వినియోగదారులు ప్లానింగ్ గేమ్‌లో కొత్త అవసరాలను తీసుకొస్తే, వాటి అమలుకు పట్టే సమయాన్ని బృందం నేరుగా అంచనా వేసి, వారికిస్తుంది.

ఫీడ్‌బ్యాక్ అనేది కమ్యూనికేషన్ మరియు సరళతతో అతి దగ్గర సంబంధం కలిగి ఉంటుంది. ఖచ్చితమైన కోడ్ భాగం దెబ్బతింటుందన్న విషయాన్ని నిరూపించగలిగే యూనిట్ టెస్ట్ ద్వారా సిస్టమ్‌లోని దోషాలు తేలికగా తెలుపబడుతాయి. సిస్టమ్‌ యొక్క ప్రత్యక్ష ఫీడ్‌బ్యాక్ ఈ భాగాన్ని తిరిగి కోడ్ చేయమని ప్రోగ్రామర్లకు చెబుతుంది. యూజర్ స్టోరీస్‌ గా పేర్కొనే ఫంక్షనల్ అవసరాలను బట్టి వినియోగదారుడు సిస్టమ్‌ను నిర్ణీత కాలంలో పరీక్ష చేయవచ్చు. "ఆశావహదృక్పథం అనేది ప్రోగ్రామింగ్ యొక్క వృత్తిసంబంధమైన ప్రమాదం, ఫీడ్‌బ్యాక్ అనేది చికిత్స" అని కెంట్ బెక్ తెలిపాడు.^{[citation needed]}

సాహసం

వివిధ సాధనలు సాహసోపేతమైనవి. అందులో ఒకటి డిజైన్ మరియు కోడ్ అనేది ఎప్పుడూ ఈరోజే చేయాలి రేపు కాదు అనే ఆదేశం. డిజైన్ చేస్తున్నప్పుడు ముందుకు కదలేని పరిస్థితిని దూరం చేసే ప్రయత్నంగా దీనిని చెప్పొచ్చు. అలాగే దేన్నైనా అమలు చేయడానికి అత్యంత కృషి అవసరం. అవసరమైనప్పుడు తమ కోడ్‌ను ఇబ్బంది లేకుండా రీఫ్యాక్టరింగ్ చేసే విధంగా సాహసం డెవలపర్లను సశక్తిపరుస్తుంది. అంటే, ప్రస్తుతమున్న సిస్టమ్ (వ్యవస్థ)ను సమీక్షించడం మరియు దానిని సరిచేయడం. తద్వారా భవిష్యత్ మార్పులు అత్యంత సులువుగా అమలు చేయబడతాయి. కోడ్‌ను ఎప్పుడు నాశనం చేయాలో తెలుసుకోవడం సాహసానికి మరో ఉదాహరణగా చెప్పుకోవచ్చు. అంటే సోర్స్ కోడ్‌ను రూపొందించడానికి ఎంత శ్రమించామన్న విషయాన్ని పట్టించుకోకుండా దానిని తొలగించే సాహసం చేయడం. అలాగే సాహసానికి అర్థం పట్టుదల. ఎవరైనా ఒక ప్రోగ్రామర్ క్లిష్టమైన సమస్య చేతిలో చిక్కి, రోజంతా ఇబ్బందిపడుతుంటాడు. అలాంటప్పుడు అతనికి పట్టుదల ఉంటేనే ఆ సమస్యను మరుసటి రోజు పరిష్కరించగలుగుతాడు.

మర్యాద

ఇతరులకు మర్యాద ఇవ్వడం మరియు ఆత్మాభిమానం కలిగి ఉండాలి. కూర్పును విచ్ఛిన్నం చేసే మార్పులకు ప్రోగ్రామర్లు ఎప్పుడూ ఉపక్రమించరాదు. అలా చేస్తే, అప్పటికే ఉనికిలో ఉన్న యూనిట్-టెస్టులు విఫలమవడం లేదా తమ సహచరుల పని ఆలస్యమవుతుంది. ఎల్లప్పుడూ అత్యధిక నాణ్యతను సాధించే విధంగా సభ్యులు తమ సొంత పనిని గౌరవించుకోవాలి. రీఫ్యాక్టరింగ్ ద్వారా తమ చేతిలోని పరిష్కారానికి అత్యుత్తమ డిజైన్ కోసం కృషి చేయాలి.

నాలుగు విలువలను అనుసరించడం ద్వారా బృందంలోని ఇతరుల నుంచి గౌరవం పొందవచ్చు. బృందంలోని ఎవరూ తమను మెచ్చుకోలేదని లేదా ఉపేక్షించారని భావించరు. ఇది ఉన్నత స్థాయి ప్రేరణ కలిగించడం, బృందం పట్ల మరియు ప్రాజెక్టు లక్ష్యం పట్ల విధేయతతో మెలిగే విధంగా చేస్తుంది. ఈ విలువ ఇతరుల విలువలపై చాలా వరకు ఆధారపడి ఉంటుంది. అలాగే బృందంలోని సభ్యుల మధ్య సత్సంబంధాల దిశగా పనిచేస్తుంది.

నిబంధనలు

XP మొదటి వెర్షన్ నిబంధనలను కెన్ ఆయర్ XP/Agile Universe 2003లో ప్రతిపాదించాడు. XP దాని నిబంధనల ద్వారా నిర్వచించబడుతుంది తప్ప సాధనల (మరింత వ్యత్యాసం మరియు సందిగ్ధతను అనుసరించి) ద్వారా కాదని అతను అభిప్రాయపడ్డాడు. అతను రెండు తరగతులను వివరించాడు: "రోజువారీ కార్యక్రమ నిబంధనలు", ఇది సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ సమర్థవంతంగా రూపకల్పన జరిగే పర్యావరణాన్ని తెలుపుతుంది. ఇక "వ్యవహార నిబంధనలు" అనేది ప్రతి నిమిష కార్యకలాపాలను వివరిస్తుంది. అలాగే రోజువారీ కార్యక్రమ నిబంధనల ముసాయిదాలోని నిబంధనలను తెలుపుతుంది.

ICSE 2008 సమావేశం సందర్భంగా జరిగిన APSO శిక్షణాశిబిరంలో మెహ్ది మీరాఖోర్లి ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ నిబంధనలకు ఒక కొత్త మరియు అత్యంత ఖచ్చితత్వం కలిగిన మరియు సమగ్ర వెర్షన్‌ను ప్రతిపాదించాడు. సాధనల పరంగా అత్యంత స్వతంత్రమైనదిగానూ మరియు అత్యంత "చురుకైనది"గా ఉండాలనేది దీని ఉద్దేశం.

రోజువారీ కార్యక్రమ నిబంధనలు

మెహ్ది మీరాఖోర్లి ప్రకారం, ఇవి:^{[citation needed]}

• వ్యాపారులు మరియు డెవలపర్లు కలిసి పనిచేయాలి: వ్యాపారులు మరియు డెవలపర్లు ప్రాజెక్టు పూర్తయ్యేంత వరకు ప్రతినిత్యం కలిసి పనిచేయాలి.
• వినియోగదారుడిని సంతృప్తిపరచడమే అత్యంత ప్రధానం: డెవలపర్లు మరియు బృందంలోని ఇతర సభ్యులు పొందుపరిచిన అంచనాలు మరియు ఇతర సమాచారం ఆధారంగా లక్ష్యాలు మరియు ప్రాధాన్యతలను వినియోగదారుడు నిర్దేశించడం మరియు వాటిని ఎల్లప్పుడూ సరిదిద్దడం చేయాలి. ఏది ఎలా చేయకూడదన్న రీతిలో లక్ష్యాలు నిర్వచించబడతాయి.
• వర్కింగ్ సాఫ్ట్‌వేర్‌ను తరచుగా విడుదల చేయడం: స్వల్ప కాల వ్యవధి (టైమ్‌బాక్సింగ్)కి ప్రాధాన్యతనిస్తూ, రెండు వారాల నుంచి రెండు నెలల వరకు వర్కింగ్ సాఫ్ట్‌వేర్‌ను తరచూ విడుదల చేయాలి.
• వర్కింగ్ సాఫ్ట్‌వేర్: వర్కింగ్ సాఫ్ట్‌వేర్ అనేది పురోగతిని తెలుసుకోవడానికి ప్రాథమిక ప్రమాణం.
• అంతర్జాతీయ అవగాహన: ఏదో ఒక సందర్భంలో బృందంలోని ఎవరైనా సభ్యుడు వినియోగదారుడి లక్ష్యాల దిశగా బృందం పురోగతిని గుర్తించే సామర్థ్యాన్ని కలిగి ఉండాలి. తద్వారా ఎలా మరింత సమర్థవంతంగా మారాలనే దానిపై బృందం దృష్టి పెడుతుంది. ఫలితంగా పరిస్థితికి అనుగుణంగా తన ప్రవర్తన మార్చుకుంటుంది.
• బృందం తప్పనిసరిగా ఒక సమర్థవంతమైన సామాజిక వ్యవస్థ

(సోషియల్ నెట్‌వర్క్)గా పనిచేయాలి. అంటే:

• • నిజాయితీ సంభాషణ ద్వారా ప్రమాణ పత్రరచన (డాక్యుమెంటేషన్) కంటే నిరంతర అభ్యాసం మరియు వ్యక్తికి-వ్యక్తికి మధ్య జరిగే సంకర్షణపై అవధారణ సాధ్యమవుతుంది.
  • పురోగతిని సాధించే దిశగా బృందానికి అవసరమైన వాటి నుంచి మరియు వినియోగదారులు/వనరుల నుంచి తక్కువ స్థాయిల్లో దూరమవడం ద్వారా ఆయా అవసరాలు తీరుతాయి.
  • అధికారం మరియు బాధ్యతల అమరిక.

మూల సూత్రాలు

XP పునాదికి కారణమైన మూల సూత్రాలు పైన వివరించిన విలువలపై ఆధారపడి ఉంటాయి. ఇవి సిస్టమ్ డెవలప్‌మెంట్ ప్రాజెక్టు విషయంలో నిర్ణయాలు తీసుకునేలా ప్రోత్సహిస్తాయి. ఈ మూల సూత్రాలు విలువల కంటే అత్యంత వాస్తవికమైనవిగా ఉండే విధంగా ఉద్దేశించడమైనది. కార్యశీల పరిస్థితిలో ఇవి మార్గదర్శకంగా సులువుగా అనువదించబడతాయి.

ఫీడ్‌బ్యాక్

ఫీడ్‌బ్యాక్‌ అనేది శరవేగంగా పూర్తిచేయబడి, వెల్లడించబడినట్లయితే అది అత్యంత ప్రయోజనకరమని ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ భావిస్తోంది. ఒక చర్యకు మరియు దాని ఫీడ్‌బ్యాక్‌కు మధ్య సమయం మార్పులు తెలుసుకోవడానికి మరియు మార్చడానికి చాలా కీలకమని కూడా సూచిస్తోంది. సంప్రదాయక సిస్టమ్ డెవలప్‌మెంట్ పద్ధతుల వలే కాకుండా, వినియోగదారుడితో సంప్రదింపులు తరచూ పునరావృతమవుతుంటాయి. అభివృద్ధి చెందుతోన్న సిస్టమ్ పట్ల వినియోగదారుడికి స్పష్టమైన అంతర్గత జ్ఞానం ఉంటుంది. అతడు లేదా ఆమె ఫీడ్‌బ్యాక్‌ను ఇవ్వగలరు. తద్వారా అవసరమైన విధంగా అభివృద్ధికి బాటలు వేసుకోవచ్చు.

శరవేగ ఫీడ్‌బ్యాక్ సూత్రానికి యూనిట్ టెస్టులు కూడా దోహదపడుతాయి. కోడ్ రాస్తున్నప్పుడు, ఎవరైనా చేసిన మార్పులకు సిస్టమ్ ఏ విధంగా ప్రతిస్పందిస్తుందనే దానిపై యూనిట్ టెస్ట్ ప్రత్యక్ష ఫీడ్‌బ్యాక్‌ను అందిస్తుంది. ఉదాహరణకు, చేసిన మార్పులు సిస్టమ్‌లోని ఏదైనా ఒక భాగాన్ని దెబ్బతీస్తే, ఒకవేళ అది వాటిని చేసిన ప్రోగ్రామర్ పరిమితిలో లేకుంటే, అతను దోషాన్ని గుర్తించలేడు. అయితే సిస్టమ్ రూపకల్పన జరుగుతున్నప్పుడు ఈ దోషం కన్పిస్తుంది.

ఆమోదిత సరళత

ప్రతి సమస్య యొక్క పరిష్కారం "అత్యంత సరళం"గా ఉన్నట్లయితే, ఇది దాని పరిష్కారానికి సంబంధించినది. సంప్రదాయక సిస్టమ్ డెవలప్‌మెంట్ పద్ధతులు భవిష్యత్ వ్యూహం రూపొందించమని మరియు పునర్‌వినియోగానికి కోడ్‌ రాయమని సూచిస్తాయి. అయితే ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఈ ఆలోచనలను తోసిపుచ్చుతుంది.

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ మద్దతుదారులు ఒకేసారి అన్ని పెద్ద పెద్ద మార్పులు చేయడం వల్ల ఫలితం ఉండదని చెబుతున్నారు. ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ అనేది ఆవృత్త మార్పులకు వర్తిస్తుంది. ఉదాహరణకు, ఒక సిస్టమ్ ప్రతి మూడు వారాలకు చిన్న విడుదలలను కలిగి ఉండొచ్చు. పలు చిన్న చిన్న చర్యలు తీసుకున్నప్పుడు, డెవలప్‌మెంట్ ప్రక్రియ మరియు అభివృద్ధి చేయబడుతున్న సిస్టమ్‌పై వినియోగదారుడు అత్యంత నియంత్రణ పొందుతాడు.

ఆలింగన మార్పు

ఆలింగన మార్పు యొక్క మూల సూత్రం మార్పులను వ్యతిరేకించడం కంటే వాటిని ఆలింగనం చేసుకోవడం. ఉదాహరణకు, ఒకానొక పునరావృత సందర్భాల్లో, వినియోగదారుడి అవసరాలు నాటకీయంగా మారిపోవడం కన్పిస్తుంది. ప్రోగ్రామర్లు ఈ పరిస్థితిని సానుకూలంగా స్వీకరించి, తదుపరి పునరుక్తి (ఇటిరేషన్) కోసం కొత్త అవసరాలకు వ్యూహరచన చేయాలి.

సాధనలు

మరిన్ని వివరాలకు చూడండి: Extreme programming practices.

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ మొత్తం 12 సాధనలు కలిగి ఉన్నట్లు మరియు నాలుగు విభాగాలుగా విభజించినట్లు వివరించడం జరిగింది.

పైన్ స్కేల్ ఫీడ్‌బ్యాక్

• జంట ప్రోగ్రామింగ్
• ప్లానింగ్ గేమ్
• టెస్ట్-డ్రివెన్ డెవలప్‌మెంట్
• యావత్ బృందం

నిరంతర ప్రక్రియ

• నిరంతర సమాకలనం
• రీఫ్యాక్టరింగ్ లేదా డిజైన్ అభివృద్ధి
• చిన్న విడుదలలు

విభాజిత అవగాహన

• కోడింగ్ ప్రమాణాలు
• సమూహ కోడ్ యాజమాన్యం
• సరళమైన డిజైన్
• సిస్టమ్ రూపకం

ప్రోగ్రామర్ సంక్షేమం

• స్థిర గమనం

కోడింగ్

• వినియోగదారుడు ఎల్లప్పుడూ అందబాటులో ఉంటాడు
• యూనిట్ టెస్ట్‌ను తొలుత కోడ్ చేయాలి
• ఒక జంట మాత్రమే కోడ్‌ను ఒకేసారి సమాకలనం చేస్తుంది
• ఆప్టిమైజేషన్‌‍ను చివరి వరకు విడిచిపెట్టండి
• అధికకాలం ఉండరాదు

టెస్టింగ్

• అన్ని కోడ్‌లకు తప్పనిసరిగా యూనిట్ టెస్టులు ఉండాలి
• అన్ని కోడ్‌లు విడుదలకు ముందే తప్పక అన్ని యూనిట్ టెస్టులలో ఉత్తీర్ణత సాధించాలి.
• ఏదైనా తప్పు (బగ్)ను గుర్తిస్తే, ఆ తప్పును తెలపడానికి ముందే టెస్టులు నిర్వహించాలి (లాజిక్‌గా చెప్పాలంటే బగ్ అనేది పొరపాటు కాదు. అది నువ్వు రాయడం మరిచిపోయిన ఒక పరీక్ష మాత్రమే.
• సమ్మతి పరీక్షలను తరచూ నిర్వహిస్తూ, ఫలితాలను ముద్రిస్తారు.

వివాదాస్పద అంశాలు

XPలోని సాధనలపై తీవ్రమైన చర్చ జరిగింది. ఆన్‌సైట్ వినియోగదారుడి విజ్ఞప్తి నియమరహితంగా మారడం వల్ల, ఈ ప్రక్రియ సరళతరమవడం తద్వారా లాంఛనప్రాయ నియత కాలిక వ్యయం పొదుపు చేయబడుతుందని ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ప్రతిపాదకులు అభిప్రాయపడుతున్నారు. XP విమర్శకులు మాత్రం దీని వల్ల ఎక్కువ ఖర్చయ్యే విధంగా తిరిగి పనిచేయడం మరియు ప్రాజెక్టు స్కోప్ క్రీప్ (పరిమితి భీతి) అంతకుముందు కుదుర్చుకున్న ఒప్పందం లేదా పెట్టిన పెట్టుబడిని మించిపోతుందని చెబుతున్నారు.

ప్రాజెక్టు లక్ష్యాల్లో సంభావ్య సంఘర్షణలు మరియు బహుళ వినియోగదారుల మధ్య అడ్డంకులు ఉన్నాయనే దానికి మార్పు నియంత్రణ బోర్డులు (ఛేంజ్ కంట్రోల్ బోర్డ్స్) ఒక సంకేతం. అభివృద్ధిపరచిన XP పరిశోధనపద్ధతి (మెథడాలజీ) ఒక తాదాత్మ్య క్లయింట్ యొక్క దృక్కోణాన్ని ఆమోదించడానికి కొంతవరకు ప్రోగ్రామర్లపై ఆధారపడుతుంది. అందువల్ల ప్రోగ్రామర్ రాజీ లక్ష్యాల ప్రమాణ పత్రరచన మరియు అడ్డంకులపై కంటే కోడింగ్‌పై దృష్టి సారించగలడు. బహుళ ప్రోగ్రామింగ్ సంస్థలు పాలుపంచుకున్నప్పుడు కూడా ప్రత్యేకించి, ప్రాజెక్టుల వాటాల కోసం సంస్థలు పోటీపడినప్పుడు ఇది వర్తిస్తుంది.^{[citation needed]}

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ యొక్క ఇతర సంభావ్య వివాదాస్పద అంశాలు:

• అవసరాలు విశిష్ట డాక్యుమెంట్ల మాదిరిగా కంటే స్వీయాత్మక సమ్మతి పరీక్షల వలే తెలియజేయబడతాయి.
• అవసరాలు సంకలనాత్మకంగా నిర్వచించబడతాయి తప్ప ముందుగా వాటిని క్రోడీకరించే ప్రయత్నం జరగదు.
• సాఫ్ట్‌వేర్ డెవలపర్లు సాధారణంగా జంటలుగా పనిచేయాల్సిన అవసరముంటుంది.
• బిగ్ డిజైన్ అప్ ఫ్రంట్ అనేది ఉండదు. ఎక్కువ భాగం రూపకల్పన వేగంగానూ మరియు సంకలనాత్మకంగా జరుగుతుంది. "అత్యంత సరళమైనది బహుశా పనిచేయొచ్చు"తో మొదలై, టెస్టులు వైఫల్యం చెందిన సమయంలో అవసరమైతేనే సంక్లిష్టతను జోడించడం జరుగుతుంది. అయితే విమర్శకులు దీనిని "కనిపించే విధంగా సిస్టమ్ దోషాలను సవరించడం"తో పోల్చారు. దీని ఫలితంగా, అవసరాలు మారినప్పుడు కేవలం రీ-డిజైనింగ్ కంటే మరింత రీ-డిజైన్ చేయాల్సిన పరిస్థితి ఏర్పడవచ్చని వారు ఆందోళన వ్యక్తం చేశారు.
• వినియోగదారుడి ప్రతినిధి ఒకరు ఈ ప్రాజెక్టుతో సంబంధం కలిగి ఉంటాడు. ప్రాజెక్టుకు సంబంధించి ఈ పాత్ర ఏకైక వైఫల్యంగా మారవచ్చని కొందరు చెబితే, మరికొందరు ఇది ఒత్తిడికి మూలమని గుర్తించారు. అంతేకాక ఎవరైనా సాంకేతికయేతర ప్రతినిధి టెన్నికల్ సాఫ్ట్‌వేర్ విశిష్టతలు మరియు నిర్మాణం యొక్క ఉపయోగాన్ని వివరించే ప్రయత్నం చేసినప్పుడు సూక్ష్మ-నిర్వహణ ప్రమాదం తలెత్తే అవకాశముంది.
• XP ఇతర అన్ని అంశాలపై ఆధారపడటం: "XP అనేది ఒక విషపూరిత సర్పాల వలయం వంటిది, ఇతర భాగాలను అనుసంధానం చేస్తుంది. ఇదంతా కూడా అందులో ఒకటి బయటపడే విధంగా చేస్తుంది. అందువల్ల నీకు విపరీతమైన కోపం వస్తుంది. విషపూరిత సర్పం నీ వైపుగా కదులుతోంది."

శ్రేణీకరించదగిన

చారిత్రాత్మకంగా, XP పన్నెండు మంది లేదా కొద్ది మంది మాత్రమే ఉండే బృందాలపై మాత్రమే పనిచేసేది. ఈ పరిమితిని దాటడానికి ఒక మార్గంగా ప్రాజెక్టుకు చిన్నచిన్న భాగాలుగానూ మరియు టీమ్‌ను చిన్నచిన్న సమూహాలగానూ విడగొట్టారు. వందమందికి పైగా డెవలపర్లు ఉన్న బృందాలపై XP విజయవంతంగా ఉపయోగించబడిందని పేర్కొన్నారు.^{[citation needed]} అయితే అరవై మంది సభ్యులకు పంపిణీ చేసిన XP ప్రాజెక్టులు మాత్రమే విశ్వసనీయమైన విజయం సాధించాయని ThoughtWorks స్పష్టం చేసింది.^{[citation needed]}

XP కొత్త పరిణామంగా 2004 ఇండస్ట్రియల్ ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ (IXP) పరిచయం చేయబడింది. అతిపెద్ద మరియు విస్తరించిన బృందాల్లో పనిచేసే సామర్థ్యాన్ని కల్గించడం దీని ఉద్దేశం. ఇది ప్రస్తుతం 23 సాధనలు మరియు సరళమైన విలువలను కలిగి ఉంది. ఎజైల్ కుటుంబంలో ఇది కొత్తగా అడుగుపెట్టడంతో దీని ప్రయోజకత్వాన్ని నిరూపించడానికి తగిన డాటా లేకపోయింది. అయితే XP యొక్క లోటుపాట్లుకు ఇది ఒక జవాబుగా నిలిచింది.

విభాజ్యత మరియు స్పందనలు

2003లో మట్ స్టీఫెన్స్ మరియు డౌ రోసెన్‌బర్గ్ ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ రీఫ్యాక్టర్డ్ : ది కేస్ ఎగనెస్ట్ XP ని ముద్రించారు. ఇది XP ప్రక్రియ విలువను ప్రశ్నించడం మరియు అది మెరుగయ్యే మార్గాలను సూచించింది. ఫలితంగా దీనిపై పలు కథనాలు, ఇంటర్నెట్ న్యూస్‌గ్రూపులు మరియు వెబ్‌సైటు చాట్ ప్రదేశాల్లో విస్తృతమైన చర్చ జరిగింది. XP సాధనలు అంతర్గతంగా ఆధారపడినవి అనేది పుస్తకం యొక్క ప్రధాన వాదన. అయితే కొన్ని క్రియాశీల సంస్థలు అన్ని సాధనలను ఆమోదించడానికి సంసిద్ధత వ్యక్తం చేశాయి. దీంతో ఈ మొత్తం ప్రక్రియ విఫలమైంది. ఈ పుస్తకం ఇతర విమర్శలు కూడా చేసింది. XP యొక్క "సమూహ యాజమాన్యం" నమూనా మరియు సమాజవాదం మధ్య పోలికను విరుద్ధమైన రీతిలో వివరించింది.

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ రీఫ్యాక్టర్డ్ (2003) అనే పుస్తకం ముద్రించిన తర్వాత XP యొక్క కొన్ని అంశాలు మార్చబడ్డాయి. ప్రత్యేకించి, XP ప్రస్తుతం అవసరమైన లక్ష్యాలను చేరుకునేంత వరకు సాధనలకు పలు మార్పులు చేస్తోంది. XP ప్రక్రియలకు ఎక్కువగా సాధారణ పదాలు కూడా వాడుతోంది. ఈ మార్పులు గత విమర్శలను తొలగించలేవని కొందరు వాదిస్తున్నారు. అయితే ఇది ప్రక్రియ దెబ్బతినడానికి చేసే ప్రయత్నమేనని మరికొందరు అంటున్నారు.

RDP సాధన ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్‌ను అనుసరించడానికి ఒక టెక్నిక్ వంటిది. ఈ సాధన ప్రాథమికంగా ఫిలిప్పీ క్రుచ్టెన్ మరియు స్టీవ్ అడాల్ఫ్ (ICSE 2008 సందర్భంగా నిర్వహించిన APSO శిక్షణా శిబిరంను చూడండి) నిర్వహించిన శిక్షణాశిబిరంలో ఒక సుదీర్ఘ పరిశోధనా పత్రంగా ప్రతిపాదించబడింది. XPకి మార్పులు చేర్పులు చేయడానికి ఇప్పటికీ ఇదే ఏకైక ప్రతిపాదిత మరియు అనువర్తిత పద్ధతి. RDP సాధన వెనుక ఉన్న విలువైన భావనలు అతి తక్కువ వ్యవధిలో పరిశ్రమల్లో దాని యోగ్యతను సమర్థించే కారణాలను అందించాయి. సంవిధాన XP నిబంధనలపై ఆధారపడి, XPని సవరించడానికి RDP సాధన ప్రయత్నిస్తోంది.

తాదాత్మ్య పరిశోధనపద్ధతిని ఆవిష్కరించే దిశగా పాత పద్ధతుల ద్వారా XPని సమన్వయపరచడానికి ఇతర రచయితలు ప్రయత్నించారు. XP యొక్క వాటర్‌ఫాల్ పద్ధతి వంటి కొన్ని సాధనలను మార్చడానికి ప్రయత్నాలు జరుగుతున్నాయి. ఉదాహరణ: ప్రాజెక్ట్ లైఫ్‌సైకిల్స్: వాటర్‌ఫాల్, రేపిడ్ అప్లికేషన్ డెవలప్‌మెంట్ అండ్ ఆల్ దట్. కేపబిలిటీ మెచ్యూరిటీ మోడల్ ఇంటెగ్రేషన్ (CMMI) మరియు Six Sigma యొక్క కంప్యూటర్ ప్రోగ్రామింగ్ పద్ధతులతో XPని చేర్చడానికి JPMorgan Chase & Co. ప్రయత్నించింది. ఉత్తమ డెవలప్‌మెంట్‌ సాధ్యపడే విధంగా ఈ మూడు సిస్టమ్‌లు ఒక దానితో మరొకటి దృఢంగా కలిసిపోయాయని, పరస్పర విరుద్ధంగా లేవని అవి గుర్తించాయి.

విమర్శ

ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ యొక్క ప్రాథమిక సంచలనం మరియు జంట ప్రోగ్రామింగ్ మరియు నిరంతర రూపకల్పన వంటి వివాదాస్పద సిద్ధాంతాలు ప్రత్యేకమైన విమర్శలకు గురయ్యాయి. అందులో ఒకటి మెక్‌బ్రీన్ మరియు బోయమ్ మరియు టర్నర్ నుంచి వచ్చాయి. అయితే పలు విమర్శలు చురుకైన డెవలప్‌మెంట్ (ఎజైల్ డెవలప్‌మెంట్)ను సరిగా అర్థం చేసుకోకపోవడం వల్లనే వచ్చాయని ఎజైల్ సాధకులు అభిప్రాయపడ్డారు.

ప్రత్యేకించి, ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్‌ను మట్ స్టీఫెన్ మరియు డౌ రోసెన్‌బర్గ్‌ యొక్క ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ రీఫ్యాక్టర్డ్ సమీక్షించడం మరియు సవిమర్శక పరిశీలన చేసింది.

పలు విమర్శలు...

• ఏదైనా పరిశోధనపద్ధతి అనేది ప్రోగ్రామర్లు పాలుపంచుకుంటేనే సమర్థవంతంగా తయారవుతుంది. ఎజైల్ దీనిని పరిష్కరించలేదు.
• విడుదలకు సిద్ధంగా ఉన్న ఒక ఉత్పత్తిని సరిగా వివరించకపోవడం ద్వారా వినియోగదారుల నుంచి డబ్బులు పిండుకునే ప్రయత్నం జరిగిందనే అర్థం వచ్చేలా తరచూ వాడబడటం
• నిర్మాణం మరియు అవసరమైన ప్రమాణ పత్ర రచన లేకపోవడం
• ఉన్నత స్థాయి డెవలపర్లతో మాత్రమే పనిచేయడం
• తగినంత సాఫ్ట్‌వేర్ డిజైన్ లేకపోవడం
• వినియోగదారులకు ఖర్చెక్కువయ్యే విధంగా తరచూ సమావేశాలు నిర్వహించాల్సి రావడం
• ఆమోదానికి అధిక సాంస్కృతిక మార్పు అవసరమవడం
• అత్యంత క్లిష్టమైన ఒప్పందబద్ధమైన సంప్రదింపులకు దారితీయడం
• ఒక కోడ్ ప్రాంతానికి సంబంధించిన అవసరాలు అనేక పునరావృతాల ద్వారా మారితే, అదే ప్రోగ్రామింగ్ అనేక పర్యాయాలు చేయాల్సిన పరిస్థితి ఏర్పడవచ్చు. ఫలితంగా అది అసమర్థంగా మారవచ్చు. అదేవిధంగా అనుసరించాల్సిన వ్యూహం ఉన్నప్పుడు, కోడ్ యొక్క ఒక్క ప్రాంతం ఒకేసారి రాయాల్సిన పరిస్థితి రావొచ్చు.
• ధర నిర్ణయానికి ఎంత మేర శ్రమించాలనే దానికి సంబంధించి వాస్తవిక అంచనాలు రూపొందించడం అసాధ్యమవుతుంది. ఎందుకంటే, ప్రాజెక్టు ప్రారంభంలో ఎవరికీ మొత్తం పరిమితి/అవసరాలు తెలియవు.
• వివరణాత్మక ప్రమాణ పత్రరచన (డాక్యుమెంటేషన్) లేని కారణంగా స్కోప్ క్రీప్ సమస్య జఠిలంకావొచ్చు.
• ఎజైల్ అనేది విశిష్టతపై దృష్టి సారిస్తుంది. క్రియాశీల-యేతర నాణ్యతా లక్షణాలను యూజర్ స్టోరీస్లో చేర్చడం చాలా కష్టమవుతుంది.

వీటిని కూడా చూడండి

• సాఫ్ట్‌వేర్ ఇంజినీరింగ్
• సాప్ట్‌వేర్ క్రాఫ్ట్‌మన్‌షిప్
• ఎజైల్ సాఫ్ట్‌వేర్ డెవలప్‌మెంట్
• ఎక్స్‌ట్రీమ్ ప్రాజెక్టు నిర్వహణ
• ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ సాధనలు
• జంట ప్రోగ్రామింగ్
• RDP టెక్నిక్
• కై జెన్
• సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ సిద్ధాతాల జాబితా
• స్క్రమ్ (డెవలప్‌మెంట్)

మరింత చదవడానికి

• కెన్ ఆయర్ మరియు రాయ్ మిల్లర్. ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ అప్లైడ్: ప్లేయింగ్ టు విన్ , యాడిషన్-వెస్లీ.
• కెంట్ బెక్: ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్: ఎంబ్రేస్ ఛేంజ్ , యాడిషన్-వెస్లీ
• కెంట్ బెక్ మరియు మార్టిన్ ఫోలర్: ప్లానింగ్ ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ , యాడిషన్-వెస్లీ
• కెంట్ బెక్ మరియు సింథియా ఆండ్రెస్ ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఎక్స్‌ప్లెయిన్డ్: ఎంబ్రేస్ ఛేంజ్, సెకండ్ ఎడిషన్ , యాడిషన్-వెస్లీ
• ఆలిస్టన్ కాక్‌బర్న్: ఎజైల్ సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ , యాడిషన్-వెస్లీ
• మార్టిన్ ఫోలర్: రీఫ్యాక్టరింగ్: ఇంప్రూవింగ్ ది డిజైన్ ఆఫ్ ఎగ్జిస్టింగ్ కోడ్ , యాడిషన్-వెస్లీ
• హార్వే హెరెలా (2005). కేస్ స్టడీ: ది క్రిస్లర్ కాంప్రహెన్సివ్ కాంపెన్సేషన్ సిస్టమ్. గ్యాలన్ ల్యాబ్, U.C. ఇర్విన్
• జిమ్ హైస్మిత్. ఎజైల్ సాప్ట్‌వేర్ డెవలప్‌మెంట్ ఎకోసిస్టమ్స్ , యాడిషన్-వెస్లీ
• రాన్ జెఫ్రీస్, అన్ అండర్సన్ మరియు చెట్ హెండ్రిక్సన్ (2000), ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ ఇన్‌స్టాల్డ్ , యాడిషన్-వెస్లీ
• మెహ్ది మీరాఖోర్లి (2008). RDP టెక్నిక్: ఎ ప్రాక్టీస్ టు కస్టమైజ్ xp , 2008లో లీప్‌జిగ్, జర్మనీలో సాఫ్ట్‌వేర్ డెవలప్‌మెంట్‌పై జరిగిన అంతర్జాతీయ సదస్సు, స్క్రుటినైజింగ్ ఎజైల్ ప్రాక్టీసెస్ ఆర్ షూట్‌-ఔట్ అట్ ది ఎజైల్ కోరల్‌పై అంతర్జాతీయ శిక్షణాశిబిరం. పేజీలు 23-32
• క్రెయిగ్ లార్మన్ & V. బాసిలి (2003). "ఇటిరేటివ్ అండ్ ఇంక్రిమెంటల్ డెవలప్‌మెంట్: ఎ బ్రీఫ్ హిస్టరీ", కంప్యూటర్ (IEEE కంప్యూటర్ సొసైటీ) 36 (6): 47-56.
• మట్ స్టీఫెన్స్ మరియు డౌ రోసెన్‌బర్గ్ (2003). ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ రీఫ్యాక్టర్డ్: ది కేస్ ఎగనెస్ట్ XP , Apress.
• వాల్డ్‌నర్, JB. (2008). "నానోకంప్యూటర్స్ అండ్ స్వార్మ్ ఇంటెలిజెన్స్". In: ISTE, 225-256.

బాహ్య లింకులు

వికీమీడియా కామన్స్ లో

Extreme Programming

కి సంభందించిన మీడియా ఉంది

• ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్
• ఎ జంటిల్ ఇంట్రడక్షన్
• పారిశ్రామిక ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్
• XP సంచిక
• XP అమలుకు సంబంధించిన సమస్యలు మరియు పరిష్కారాలు
• యూజింగ్ ఎన్ ఎజైల్ సాఫ్ట్‌వేర్ ప్రాసెస్ విత్ ఆఫ్‌షోర్ డెవలప్‌మెంట్ - విస్తృతమైన పంపిణీ ప్రాజెక్టుల్లో XP అమలుపై ThoughtWorks' అనుభవాలు