Ni nini programu kali. Upangaji Uliokithiri (XP) sio wa watu waliochoka. Mbinu za Msingi za XP

Pengine kila mbuni au mchambuzi angalau mara moja katika maisha yake amekutana na mteja anayetaka kupata mradi wake kwa bei nafuu iwezekanavyo na, zaidi ya hayo, kwa muda mfupi iwezekanavyo. Lakini kama gharama ya mradi ni kabisa kitu halisi kujadiliana, ni vigumu zaidi kujadiliana kuhusu kurekebisha makataa ya utoaji wa mradi. Kuna wateja zaidi na zaidi wasio na subira leo, ambayo inaelezewa na hali ya soko la kisasa la nguvu, kiwango cha kuanguka cha uaminifu kati ya wasanii na wateja, na tabia ya wawekezaji ambao hamu yao huja wakati wa kula (ikiwa kuna kazi zaidi au chini). toleo la bidhaa, pesa kwa maendeleo zaidi wanatoa kwa hiari zaidi), nk. Katika suala hili, mbinu za maendeleo ya classical (ambayo mzunguko mrefu wa kubuni halisi na kukusanya taarifa, wakati mteja anawekeza fedha muhimu, lakini haipati matokeo halisi kwa muda mrefu kabisa) huja katika mgongano mkali sana na maslahi ya mteja asiye na subira. Haya yote yalitoa msukumo kwa ukuzaji wa mbinu mbadala za usanifu katika pande mbili kuu: kuongeza imani ya wateja kwa kutoa ushahidi halisi wa mchakato wa maendeleo unaoendelea na kupunguza kwa kasi muda wa maendeleo ya bidhaa. Kundi la mbinu kama hizo huitwa "programu hai".

Uendelezaji wa programu kwa kasi na shirikishi

Kwa kawaida, watumiaji wa mwisho na usimamizi wa mteja wanaamini kuwa mchakato wa kubuni umeshindwa ikiwa hakuna halisi vipengele vilivyotengenezwa tayari. Mara nyingi, mteja anasisitiza kutekeleza hatua ya utekelezaji wa mradi kabla ya ratiba ili kupata matokeo maalum na kuionyesha haraka iwezekanavyo. Katika hali hii, inavutia sana kuchagua Ukuzaji wa Maombi ya Kuharakishwa (AAD) au Ukuzaji wa Maombi ya Shirikishi (CAD). Mbinu kama hizo zinahusisha kutengeneza kielelezo kinachofanya kazi na kisha kuionyesha kwa watumiaji, ambao wanatambua kile wanachopenda na kile wasichopenda. Baada ya hayo, mbuni huboresha mfano kwa kuzingatia maoni yaliyotolewa, na kisha anaonyesha tena kile kilichotokea. Mchakato unarudiwa hadi watumiaji waridhike na kile wanachokiona na mfano kuwa programu inayofanya kazi. Kwa kawaida kikomo cha muda na idadi ya marudio huwekwa, vinginevyo watumiaji watahitaji uboreshaji mpya kwa mfano. Kwa nadharia, hii hukuruhusu kupata mfumo ambao watumiaji wanahitaji.

Kwa hivyo hapa tunaona mfano wa ukuzaji unaorudiwa na mizunguko mifupi ya ond katika visa vyote viwili. Njia zote mbili hupunguza muda uliotumiwa hatua za awali kubuni: mkakati (ikiwa imeachwa kabisa au imeunganishwa na uchambuzi), uchambuzi (katika hali nyingi ni mdogo kwa uteuzi wa awali wa habari na uchambuzi wa fomu - kama sheria, ripoti, ambayo hujaribu kurejesha muundo wa kazi za mfumo); kubuni (inayolenga kwa haraka iwezekanavyo kupata mfano wa msingi). Matokeo ya maendeleo ni mfano, ambayo ni chini ya utekelezaji wa viwanda. KATIKA kwa kesi hii upimaji unafanywa kwa ushiriki amilifu wa mteja, au mteja anakuwa mjaribu (bora zaidi, anayejaribu beta).

Katika mazoezi, mbinu hii ya maendeleo ya maombi inahusishwa na matatizo yafuatayo:

Tahadhari zote zimejikita kwenye fomu za skrini, na kila kitu kinachohusiana na sheria za usindikaji wa data na kazi za mfumo, inabaki nyuma ya pazia. Kuna jaribu la kuanza kufanya kazi na ripoti, wakati ripoti sio bidhaa ya kuanzia, lakini bidhaa inayotokana na mfumo wa habari.

Watumiaji wanadhani kwamba ikiwa toleo la mfano limekubaliwa, basi moduli iko tayari. Kwa kweli, hii inaweza kuwa picha tu na seti ya "stubs" kwa wito kazi za mfumo na kuingiliana na modules nyingine.

Moduli zimeundwa kwa kutengwa kutoka kwa kila mmoja. Matokeo ya hii ni mgongano kati ya moduli, marudio ya kazi na data, ambayo inaweza kutambuliwa tu kwa kupima seti ya moduli.

Utendaji hupanuliwa kwa sambamba katika mwelekeo kadhaa, hivyo muundo wa ghala la data lazima udhibiti. Kwa URP, taratibu za hifadhidata zinafanana na jaa la taka, ambapo majedwali yametungwa kurekebisha haraka, na matokeo yake ni seti ya data kinzani na nakala.

Nyaraka wakati wa kutumia njia ya URP kawaida haipo kwa sababu mbili: hakuna muda wa kutosha na udanganyifu huundwa kwamba mtumiaji anaweza kuelewa kiini cha kile kinachotokea bila nyaraka. Wakati programu inapoanza kufanya kazi tofauti na ilivyotarajiwa na mtumiaji, matatizo hutokea.

Mbinu za usindikaji hali za kipekee kugeuka kuwa tofauti kwa moduli tofauti.

Shida ya kujumuisha moduli hutokea: mfumo kamili, kama sheria, haufanyi kazi, kwa sababu hapo awali iliundwa kama seti ya vipengele, ambazo baadaye ziliunganishwa kwa haraka.

Udhibiti wa ubora wa bidhaa huja katika mgongano mkali na muda wa maendeleo ya mradi, kwa sababu hiyo hatua za majaribio na utekelezaji wa toleo linalofuata la bidhaa huunganishwa kivitendo na kuhamishiwa moja kwa moja kwenye tovuti ya majaribio ya mteja. Ni wazi kile kinachotokea katika kesi hii kwa mteja, ambaye hajaridhika sana na ubora wa bidhaa; kwa maneno mengine, nguo chafu huoshwa hadharani kwa wakati mbaya kabisa.

Swali linatokea: shida kama hizo zinaweza kutatuliwa na jinsi gani? Baada ya yote, unataka kupata mradi haraka iwezekanavyo! Kwa kiasi fulani, programu kali (EXtreme Programming, XP) inaweza kuchukuliwa kuwa mageuzi, na labda hata mapinduzi, katika uwanja wa mbinu za utayarishaji wa vijana. Ikiwa mbinu hii inafaa mahsusi kwa timu yako ya ukuzaji ni juu yako na wewe tu kuamua, kwani, kwa mfano, sio kila mtu anafurahishwa na michezo iliyokithiri.

Utayarishaji Mkubwa

Kanuni za XP na mbinu zinazotumiwa kuharakisha maendeleo

Kent Beck anachukuliwa kuwa baba-itikadi wa upangaji uliokithiri. XP ni mbinu changa, tathmini ambazo zinapingana sana - kutoka kwa shauku hadi hasi kali. Kanuni kuu ni:

Urahisi wa ufumbuzi.

Maendeleo makubwa katika vikundi vidogo (si zaidi ya watu 10), mawasiliano ya kazi ndani ya kikundi na kati ya vikundi (mawasiliano).

Maoni kutoka kwa mteja, ambaye kwa hakika anahusika katika mchakato wa ukuzaji.

Kiwango cha kutosha cha ujasiri na nia ya kuchukua hatari.

Jambo la kwanza katika kuharakisha maendeleo ni kurudia: maendeleo hufanywa kwa marudio mafupi na uhusiano hai na mteja. XP ni mchakato wa maendeleo unaorudiwa, ambao yenyewe sio wa mapinduzi. Inapendekezwa kuweka marudio kama mafupi, muda uliopendekezwa ni wiki 2-3 na sio zaidi ya mwezi 1. Kwa kurudia mara moja, kikundi cha waandaaji wa programu kinahitajika kutekeleza mali kadhaa za mfumo, ambayo kila moja inaelezewa katika hadithi ya mtumiaji. Hadithi za watumiaji katika kesi hii ni habari ya awali kwa misingi ambayo moduli imeundwa. Hadithi za watumiaji hutofautiana na kesi za utumiaji: hadithi ya mtumiaji ni fupi - aya 1-2, wakati kesi za utumiaji kawaida huandikwa kwa kina kabisa, na kuu na. mikondo mbadala- kwa hivyo, inageuka kuwa takriban ukurasa pamoja na mchoro (urasimishaji wa kawaida unaopendekezwa sasa katika UML); Hadithi za watumiaji huandikwa na watumiaji wenyewe (ambao katika XP ni sehemu ya timu) kinyume na kesi za utumiaji, ambazo kwa kawaida huandikwa na mchambuzi wa mifumo. Ukosefu wa urasimishaji wa maelezo ya data ya pembejeo ya mradi katika XP hutafutwa kulipwa kwa kujumuisha mteja kikamilifu katika mchakato wa maendeleo kama mshiriki kamili wa timu na kwa kuwasiliana mara kwa mara na mteja (mawasiliano hai na usaidizi unaoendelea. maoni) Katika kesi hii, uliokithiri ni kiwango ambacho mteja anahusika katika jikoni ya programu, ambayo ni kutokana na tamaa ya kukandamiza muda wa maendeleo kwa njia ya mawasiliano na maoni.

Jambo la pili katika kuharakisha maendeleo ya bidhaa ni uwepo wa vikundi vidogo na programu za jozi (wakati watengeneza programu wawili huunda msimbo pamoja katika sehemu moja ya kazi ya kawaida). Yote haya yanalenga kufikia ngazi ya juu mawasiliano katika kikundi, pamoja na ugunduzi wa mapema wa shida (makosa na tarehe za mwisho zilizokosa). Programu ya jozi ina lengo la kuimarisha mradi huo, kwa kuwa kwa mbinu hii kuna hatari kubwa ya kupoteza msimbo kutokana na kuondoka kwa programu ambaye hakuweza kuhimili ratiba kali ya kazi. Katika kesi hii, programu ya pili kutoka kwa jozi ina jukumu la "mrithi" wa kanuni (ambayo kwa njia za classical inatekelezwa katika nyaraka za kiufundi). Pia ni muhimu jinsi hasa vikundi vinasambazwa katika nafasi ya kazi - XP hutumia nafasi ya kazi ya wazi, ambayo inachukua upatikanaji wa haraka na wa bure kwa kila mtu kwa kila mtu; Kwa kawaida, nafasi ya kazi imejengwa karibu na mduara.

Jambo la tatu katika kuharakisha maendeleo ya mchakato ni kufanya suluhisho la kwanza rahisi zaidi la kufanya kazi. Katika kesi hii, mwisho wa njia unahusishwa na kiwango cha juu cha hatari ya uamuzi kutokana na uchanganuzi wa juu na ratiba ya muda mfupi. Seti ya chini ya kazi kuu za mfumo inatekelezwa mara ya kwanza na kila iteration inayofuata; utendakazi hupanuliwa kwa kila marudio.

Mazoezi

XP kawaida ina sifa ya seti ya vitendo 12 (mazoea) ambayo lazima yafanywe ili kufikia matokeo mazuri. Mazoea ya XP hayafafanui mchakato wa XP yenyewe, lakini XP inafafanua mazoea hayo - yaani, kufanya mazoea hakuhakikishi matokeo. Hakuna mazoea ambayo kimsingi ni mapya, lakini XP inawaleta pamoja.

Upangaji wa mchakato (mchezo wa kupanga). Timu nzima hukutana na uamuzi wa pamoja unafanywa kuhusu sifa gani za mfumo zitatekelezwa katika marudio yanayofuata. Seti ya mali imedhamiriwa na hadithi za watumiaji. Utata wa XP wa kila mali imedhamiriwa na waandaaji wa programu wenyewe.

Funga mwingiliano na mteja (mrejesho, mteja wa tovuti). Mteja lazima awe mwanachama wa timu ya XP (mteja wa tovuti). Anaandika hadithi za watumiaji, huchagua hadithi ambazo zitatekelezwa kwa marudio fulani, na kujibu maswali yanayohusiana na biashara. Mteja lazima awe mtaalamu katika eneo la somo linaloendeshwa kiotomatiki. Ni muhimu kuwa na maoni mara kwa mara kutoka kwa mteja (malisho-nyuma).

Sitiari ya mfumo. Sitiari nzuri ya mfumo ina maana ya kutaja madarasa na vigeu kwa urahisi. KATIKA maisha halisi kutafuta sitiari ni kazi ngumu sana; kupata sitiari nzuri si rahisi. Kwa hali yoyote, timu lazima iwe na sheria zinazofanana za majina.

Usanifu rahisi (muundo rahisi). Mali yoyote ya mfumo inapaswa kutekelezwa kwa urahisi iwezekanavyo. Watengenezaji programu katika timu ya XP hufanya kazi chini ya kauli mbiu: "Hakuna kitu cha juu!" Suluhisho la kwanza rahisi zaidi la kufanya kazi linapitishwa, kiwango kinachohitajika cha utendaji kinatekelezwa kwa sasa. Hii inaokoa wakati wa msanidi programu.

Mikataba ya usimbaji. Viwango vya usimbaji vinahitajika ili kusaidia mbinu zingine: umiliki wa msimbo ulioshirikiwa, upangaji wa programu jozi, na urekebishaji upya. Bila kiwango sare Angalau ni vigumu zaidi kutekeleza mazoea haya, na kwa kweli haiwezekani kabisa: kikundi kitafanya kazi kwa ukosefu wa muda wa mara kwa mara. Viwango vya kina havihitajiki, vitu muhimu tu vinapaswa kusawazishwa. Kuamua vitu muhimu zaidi vya viwango katika XP ni jambo la kibinafsi.

Kuunda upya. Refactoring ni utoshelezaji wa kanuni zilizopo kuelekea kurahisisha, ambayo inahusisha kazi ya kudumu ili kurahisisha kanuni. Kwa kuweka msimbo kwa uwazi na kufafanua vipengele vya msimbo mara moja tu, watayarishaji programu hupunguza idadi ya hitilafu wanazopaswa kurekebisha baadaye. Wakati wa kutekeleza kila kipengele kipya cha mfumo, mpangaji programu lazima azingatie ikiwa inawezekana kurahisisha msimbo uliopo na jinsi hii itasaidia kutekeleza kipengele kipya. Kwa kuongeza, urekebishaji upya hauwezi kuunganishwa na muundo: ikiwa msimbo mpya unaundwa, urekebishaji upya lazima uahirishwe.

Upangaji wa programu jozi ni mojawapo ya mazoea maarufu ya XP. Watayarishaji programu wote lazima wafanye kazi kwa jozi: mmoja anaandika msimbo, mwingine anaangalia. Kwa hivyo, ni muhimu kuweka kikundi cha waandaaji wa programu katika sehemu moja, ambayo ni rahisi kufanya kwenye majengo ya mteja (washiriki wote wa timu muhimu wanapatikana kijiografia katika sehemu moja); XP inafanya kazi kwa mafanikio zaidi katika timu zisizosambazwa za watayarishaji programu na watumiaji.

Saa 40 za wiki ya kazi. Mpangaji programu haipaswi kufanya kazi zaidi ya masaa 8 kwa siku. Haja ya nyongeza ni kiashiria wazi cha shida katika eneo hili la maendeleo; Kwa kuongeza, mteja hailipi kazi ya ziada katika XP. Kutafuta sababu za kazi ya ziada na kuziondoa haraka iwezekanavyo ni mojawapo ya sheria za msingi.

Umiliki wa kanuni za pamoja. Kila programu kwenye timu ya XP anapaswa kupata msimbo katika sehemu yoyote ya mfumo na kufanya mabadiliko kwenye msimbo wowote. Utawala wa lazima: ikiwa programu hufanya mabadiliko na mfumo haufanyi kazi kwa usahihi baada ya hayo, basi ni programu hii ambayo lazima irekebishe makosa. Vinginevyo, uendeshaji wa mfumo utafanana na machafuko ya jumla.

Mabadiliko ya mara kwa mara ya matoleo (matoleo madogo). Iteration ya chini ni siku moja, kiwango cha juu ni mwezi; Kadiri matoleo yanavyotolewa mara nyingi, ndivyo dosari nyingi za mfumo zitatambuliwa. Matoleo ya kwanza husaidia kutambua mapungufu katika hatua za mwanzo, kisha utendaji wa mfumo hupanuliwa (kulingana na hadithi za watumiaji sawa). Kwa kuwa mtumiaji anahusika katika mchakato wa usanidi kuanzia toleo la kwanza, yeye hutathmini mfumo na kutoa hadithi ya mtumiaji pamoja na maoni. Kulingana na hili, iteration inayofuata imedhamiriwa: toleo jipya litakuwa nini. XP inahusu kutoa maoni kila mara kwa watumiaji.

Kuunganishwa kwa kuendelea. Uunganisho wa sehemu mpya za mfumo unapaswa kutokea mara nyingi iwezekanavyo, angalau mara moja kila masaa machache. Kanuni ya msingi ya kuunganishwa ni ifuatayo: ushirikiano unaweza kufanyika ikiwa vipimo vyote vinapita kwa ufanisi. Ikiwa majaribio hayatafaulu, mpangaji programu lazima afanye masahihisho na kisha aunganishe vifaa vya mfumo, au asiviunganishe kabisa. Sheria hii ni kali na isiyo na utata - ikiwa kuna angalau kosa moja katika sehemu iliyoundwa ya mfumo, basi ushirikiano hauwezi kufanywa. Ushirikiano wa mara kwa mara unakuwezesha kupata mfumo wa kumaliza kwa kasi, badala ya kutumia wiki kwenye mkusanyiko.

Kupima Tofauti na mbinu nyingine nyingi, kupima katika XP ni mojawapo ya vipengele muhimu zaidi. Njia iliyokithiri ni kuandika majaribio kabla ya kuandika nambari. Kila moduli lazima iwe na jaribio la kitengo - jaribio la moduli hii; Kwa hivyo, katika upimaji wa urekebishaji wa XP unafanywa (upimaji wa kurudi, "usio na uharibifu wa ubora" wakati wa kuongeza utendaji). Makosa mengi yanarekebishwa katika hatua ya kuweka msimbo. Vipimo vimeandikwa na watengeneza programu wenyewe; programu yoyote ana haki ya kuandika mtihani kwa moduli yoyote. Mwingine kanuni muhimu: mtihani huamua msimbo, na si kinyume chake (njia hii inaitwa maendeleo yanayotokana na mtihani), yaani, kipande cha msimbo huwekwa kwenye hazina ikiwa na tu ikiwa vipimo vyote vinapita kwa mafanikio, vinginevyo mabadiliko haya ya kanuni yamekataliwa.

Kwa hivyo, XP inapuuza sana mabaki yote ya mchakato wa ukuzaji, isipokuwa msimbo wa chanzo. Mchakato wa XP sio rasmi sana, lakini unahitaji kiwango cha juu cha nidhamu. Ikiwa sheria hii haijafuatwa, basi XP inabadilika mara moja kuwa mchakato wa machafuko na usioweza kudhibitiwa. XP haihitaji waandaaji wa programu kuandika ripoti nyingi na kujenga mifano mingi. Katika XP, kila mpangaji programu anachukuliwa kuwa mfanyakazi aliyehitimu ambaye huchukua majukumu yake kitaaluma na kwa wajibu mkubwa. Ikiwa timu haina hii, basi kuanzisha XP haina maana kabisa - ni bora kuanza kuunda tena timu kwanza. Hatari ya maendeleo hupunguzwa tu katika timu ambayo XP ni bora; katika hali zingine zote, XP ni mchakato wa maendeleo na kiwango cha juu cha hatari, kwani hakuna njia zingine za kupunguza hatari za kibiashara, isipokuwa kwa sababu ya kibinadamu. , katika XP.

Hatari zilizopo matumizi ya mbinu

Inafaa kuangazia hatari za XP ambazo zinaweza kushindwa mradi ikiwa hazitazingatiwa na kuzuiwa.

Mchezo wa kupanga. Watayarishaji wa programu hutekeleza tu kazi ambazo ni muhimu kwa vipengele vilivyochaguliwa na mteja kwa marudio fulani. Kama matokeo ya uamuzi huu, maendeleo ya mfumo yanabaki nyuma ya pazia, kama matokeo ambayo wakati wa maendeleo kuna haja ya kujenga "stubs" na kuandika upya kanuni.

Ushiriki wa mara kwa mara wa mteja (mteja kwenye tovuti). Katika kipindi cha kazi kwenye mfumo, mwakilishi wa mteja yuko katika timu ya maendeleo, na mahitaji ya sifa za mtu huyu au timu ni ya juu sana. Ikiwa mteja hatakubali kutoa wafanyikazi wa kiwango cha wataalam, basi mradi unaanguka katika kundi la hatari zaidi.

Sitiari. Fomu ya jumla mfumo hufafanuliwa kwa kutumia sitiari au seti ya mafumbo ambayo mteja na watayarishaji programu hufanya kazi pamoja. Ikiwa hakuna logi iliyohifadhiwa mchakato huu na muundo wa kutaja haujasanifishwa, mchakato kama huo unaweza kuwa wa kurudiarudia.

Usanifu rahisi (kubuni rahisi). Kwa kila wakati kwa wakati, mfumo uliotengenezwa hufanya majaribio yote na inasaidia uhusiano wote uliofafanuliwa na mtayarishaji, hauna nakala za msimbo na ina idadi ya chini iwezekanavyo ya madarasa na mbinu. Sheria hii inaweza kuonyeshwa kwa ufupi kama ifuatavyo: "Tengeneza kila wazo mara moja na mara moja tu." Kanuni hii inakinzana na kasi ya uandishi wa msimbo. Bila nidhamu ya hali ya juu na viwango vikali vya kanuni, mfumo unakuwa hatarini mara moja.

Mabadiliko ya mara kwa mara ya matoleo (matoleo madogo). Mfumo huo umewekwa ndani ya miezi michache baada ya kuanza kwa utekelezaji, bila kusubiri ufumbuzi wa mwisho wa matatizo yote yaliyotolewa. Mzunguko wa kutolewa kwa matoleo mapya unaweza kutofautiana kutoka kila siku hadi kila mwezi. Jaribu ndani ya kipindi hiki zaidi au kidogo sehemu tata haiwezekani; mteja hufanya kama kijaribu beta. Mifumo inayohitaji kuendelea operesheni ya kuaminika(kinachojulikana hitaji la 24/7) wako hatarini.

Urekebishaji wa mfumo. Usanifu wa mfumo unaendelea kubadilika. Mradi wa sasa unabadilishwa, huku ukihakikisha kuwa majaribio yote yanafanywa kwa usahihi. Programu iliyokithiri inaendelea kutokana na ukweli kwamba daima inawezekana kufanya upya sehemu ya mfumo, na bila gharama maalum. Walakini, mazoezi mara nyingi yanaonyesha kinyume.

Kuunganishwa kwa kuendelea. Msimbo mpya umeunganishwa kwenye mfumo uliopo ndani ya saa chache. Baada ya hayo, mfumo unaunganishwa tena kuwa moja na vipimo vyote vinaendeshwa. Ikiwa angalau moja yao haijafanywa kwa usahihi, mabadiliko yaliyofanywa yanaghairiwa. Katika kesi hii, sio wazi kila wakati ni nani atakayesahihisha makosa, sio tu ya ndani, bali pia yale yanayosababishwa na kanuni mbaya. Kutekeleza majaribio magumu haitarajiwi katika hatua hii; Kwa kuongeza, mabadiliko yanahifadhiwa hata kama kosa limegunduliwa.

Oanisha programu. Nambari zote za mradi zimeandikwa na vikundi vya watu wawili wanaotumia kituo kimoja cha kazi. Sababu ya kibinadamu katika kesi hii ina jukumu la kuamua: wanandoa wanaweza kufanya kazi au la, hakuna chaguo la tatu.

Wiki ya saa 40. Kiasi cha kazi ya ziada haiwezi kuzidi wiki moja ya kazi kwa muda. Hata matukio ya pekee ya kazi ya ziada, inayorudiwa mara nyingi sana, ni ishara matatizo makubwa zinazohitaji suluhu za haraka. Kama mazoezi ya kutumia programu kali inavyoonyesha (licha ya mifano kadhaa chanya iliyotolewa na wafuasi njia hii), nyongeza na njia hii ni sheria, sio ubaguzi, na mapambano dhidi ya shida katika kesi hii ni jambo la kawaida. Inaongezeka wakati wa uingizwaji wa toleo la sasa la bidhaa ghafi na lingine - chafu kidogo. Ikiwa mteja hatapokea ushahidi thabiti wa uboreshaji wa mfumo, basi una tatizo kubwa.

Umiliki wa pamoja. Kila programu ina fursa, ikiwa ni lazima, kuboresha sehemu yoyote ya msimbo katika mfumo wakati wowote. Bila kiwango cha udhibiti wa msimbo wa chanzo, mchakato wa uendelezaji huwa hauwezi kudhibitiwa kabisa.

Fungua nafasi ya kazi. Timu ya maendeleo iko katika chumba kikubwa kilichozungukwa na vyumba vidogo. Katikati ya nafasi ya kazi, kompyuta imewekwa ambayo jozi za waandaaji wa programu hufanya kazi (na kwa mujibu wa kanuni zilizo hapo juu, yote haya yanapaswa kuwekwa kwenye majengo ya mteja, kwa kuwa anahusika sana katika mchakato wa maendeleo). Ikiwa kuna kikundi kilichosambazwa kijiografia cha watengenezaji na wateja, mradi unahitaji kusawazisha itifaki ya mwingiliano (haraka, ya kuaminika, isiyo na shida) au iko katika kikundi cha hatari.

Vipimo. Watayarishaji wa programu huandika majaribio ya kitengo kila wakati. Kwa pamoja, vipimo hivi vinapaswa kufanya kazi kwa usahihi. Kwa hatua za kurudia, wateja huandika vipimo vya kazi, ambavyo pia vinahitajika kufanya kazi kwa usahihi. Walakini, katika mazoezi hii haipatikani kila wakati. Kukubali uamuzi sahihi, ni muhimu kuelewa ni nini gharama ya kutoa mfumo na kasoro iliyojulikana hapo awali, na kulinganisha hii na gharama ya kuchelewesha kuiondoa. Vipimo vilivyoandikwa na waandaaji wa programu wenyewe (haswa wakati wa kufanya kazi kwa muda wa ziada) hazifanyi kazi kikamilifu na kwa hakika hazizingatii upekee wa kazi ya watumiaji wengi. Wasanidi programu kwa kawaida hawana muda wa kutosha kwa ajili ya majaribio ya kina zaidi. Tatizo hili linatatuliwa kwa kuwasiliana na wawasiliani kwa muda fulani, ambao unahusishwa na jukumu kubwa la sababu ya kibinadamu: tangu nyaraka za kiufundi hazipo hapo awali, habari hupitishwa kwa njia ya mawasiliano kati ya waandaaji wa programu. Ingawa, bila shaka, inawezekana kujenga mfumo wa maendeleo kwa namna ambayo watu sawa watakabiliana na kila kitu tangu mwanzo hadi mwisho. Ni muhimu kuongeza kwa hapo juu kwamba upimaji wa mfumo sio mdogo kwa vipengele vya kupima (vitengo); Vipimo vya mwingiliano kati yao sio muhimu sana, na hiyo hiyo inatumika kwa vipimo vya kuegemea. Walakini, Mbinu ya Utayarishaji Mkubwa haijumuishi kuunda majaribio. wa darasa hili. Hii inaelezewa na ukweli kwamba majaribio kama haya yenyewe yanaweza kuwakilisha nambari ngumu (hii ni kweli haswa kwa majaribio ambayo yanaiga. kazi kweli mifumo). Teknolojia hii pia haizingatii darasa lingine muhimu la vipimo - vipimo vya tabia ya mfumo wakati kiasi cha habari iliyosindika huongezeka. Kwa mzunguko wa juu wa mabadiliko ya toleo, haiwezekani kiteknolojia kufanya mtihani huo, kwani utekelezaji wake unahitaji msimbo wa mradi thabiti na usiobadilika, kwa mfano, ndani ya wiki. Katika kesi hii, itabidi ama kusimamisha maendeleo ya vipengele, au kuunda toleo la sambamba la mradi wakati wa mtihani, ambao utabaki bila kubadilika, wakati mwingine utabadilika. Kisha utahitaji kupitia mchakato wa kuunganisha msimbo. Lakini katika kesi hii, mtihani utalazimika kuundwa upya, kwa kuwa mbinu kali za programu haitoi tu maendeleo ya zana zinazoruhusu kutabiri tabia ya mfumo chini ya mabadiliko fulani. XP inapendekeza kusuluhisha matatizo haya kupitia kipengele sawa cha binadamu na nidhamu binafsi.

Hakuna zaidi ya sheria tu. Wanachama wa timu wanaofanya kazi kwa kutumia teknolojia iliyokithiri ya upangaji hujitolea kufuata sheria zilizowekwa. Walakini, hizi sio zaidi ya sheria, na timu inaweza kuzibadilisha wakati wowote ikiwa washiriki wake watafikia makubaliano kimsingi kuhusu mabadiliko yaliyofanywa. Kanuni hii inategemea sana sababu ya kibinadamu; Ukiukaji wa nidhamu ya maendeleo unahusisha muda uliopangwa na, kwa sababu hiyo, husababisha kuanguka kwa mradi.

Kama matokeo, tunapata njia ambayo inaweza kubadilika sana kwa umakini na mahitaji ya mara kwa mara ya mradi, lakini wakati huo huo sio huru kutokana na idadi ya mapungufu ya kimsingi na sana. shahada ya juu inategemea sababu ya kibinadamu.

Kwa hivyo, matokeo ya kutumia njia iliyokithiri ya programu inaweza kuwa nzuri sana au mbaya sana.

KATIKA Hivi majuzi miongoni mwa watengenezaji programu ikawa
teknolojia maarufu inayoitwa "programu uliokithiri" au XP. Kuhusu
nakala nyingi na vitabu vinaandikwa ambavyo vinatoa wazo la misingi ya kinadharia
mbinu hii. Ningependa kukuambia jinsi hii inaonekana katika mazoezi, na
nini faida na hasara

Kwanza kabisa, XP ni nini? Unaweza kupata ufafanuzi na maelezo mengi kwenye mtandao.
muda huu. Kimsingi, kila mmoja wao zaidi au chini huonyesha kiini
matukio, lakini aina mbalimbali za ufafanuzi zinaweza kumchanganya msanidi programu. Kwa hiyo ni lazima
kuelewa kwamba XP ni seti ya mbinu zilizotengenezwa ili kuwa chini
mchakato wa maendeleo ya programu nne kanuni za msingi. Yaani:

mawasiliano;
unyenyekevu;
Maoni;
ushujaa.

Kwa kawaida, mbinu hizi zinatajwa katika vifaa vya XP. Hapa ndio wengi
orodha ya kawaida yao:

Mchezo wa kupanga;
Uchunguzi kabla ya maendeleo kuanza;
Upangaji wa jozi;
Usafishaji wa mara kwa mara;
Urahisi wa maendeleo;
Umiliki wa kanuni za pamoja;
Ushirikiano unaoendelea;
Mteja kwenye tovuti ya kazi;
Kutolewa kwa haraka kwa matoleo;
Wiki ya kazi ya saa arobaini;
Viwango vya Usimbaji;
Sitiari ya mfumo.

Nitatoa maoni tu juu ya baadhi ya mbinu, kwani maana ya wengi wao ni
ni wazi kabisa kutoka kwa jina na imeelezewa kwa undani katika fasihi. Baadhi yao
njia zinaonekana kuwa za kimantiki, zingine, badala yake, husababisha mshangao.

Kupanga mchezo Wazo la mbinu hii ni rahisi sana. Watengenezaji pamoja na
wateja hukusanyika na kucheza baadhi ya hali zinazowezekana (katika
kila kitu) ambacho kinaweza kutokea wakati wa kutatua shida maishani. Mikutano kama hiyo
ni vyema kupanga kabla ya kuanza maendeleo ya kila mfumo mdogo, yaani, kufanya
hii inafanywa mara kwa mara katika mchakato wa maendeleo. Hii hukuruhusu
kushiriki katika maendeleo kulingana na mpango mkali, na kukabiliana kwa wakati unaofaa
mabadiliko katika eneo la somo.

Uchunguzi kabla ya maendeleo kuanza. Inachukuliwa kuwa kabla ya maendeleo kuanza
ya kipande chochote cha programu, mtihani umeandikwa kwa ajili yake. Hii inatoa idadi ya faida.
Kwanza, hutokea kwamba mabadiliko moja katika kipande kimoja cha nambari yanajumuisha
makosa kwa wengine. Mbinu hii ya kupima hukuruhusu kutambua mara moja
hali kama hizo. Pili, ni rahisi zaidi kwa mteja kuona wazi kuwa mtihani unafanya kazi,
kuliko kusoma vitabu vingi vya nyaraka. Ndiyo sababu matokeo ya mtihani
inahitaji kutazamwa.

Sitiari ya mfumo. Bidhaa au vipande vya msimbo vinavyotengenezwa vinalinganishwa na
bidhaa au matukio yoyote yanayofanana. Sitiari hujengwa. Hii
hurahisisha uelewa wa shida, na, ipasavyo, huharakisha maendeleo.

Lakini pia unahitaji kuelewa kwamba ikiwa, kwa sababu fulani,
yoyote ya mbinu hizi huanza kwenda kinyume na kanuni za msingi za XP, na
Hali kama hizo zinawezekana kabisa, basi inapaswa kuachwa.

Kwa kusema ukweli, licha ya ukweli kwamba kabla ya matukio yaliyoelezewa kuanza, I
alikuwa na uelewa wa jumla wa programu kali, lakini katika mchakato
maendeleo ya programu ambayo nataka kukuambia, fuata kwa uangalifu
Sijajaribu njia za XP. Walakini, kwa maoni yangu hii ni ya kawaida
mfano XP. Kwa hali yoyote, matokeo mazuri yalipatikana.

Sasa hebu tuone jinsi mbinu za XP zinaweza kutumika katika mazoezi katika
masharti yetu. Moja ya kazi zangu katika kazi ni automatisering ya elimu
mchakato. Kwa kweli, kwa muda mrefu sana I
Ninaandika maombi ambayo yanatekeleza (na angalau kwa kubuni
mwandishi:)) suluhisho la kina kwa shida hii. Bajeti ya mradi ni ndogo, na kiasi
kazi - heshima. Sababu nyingine karibu ya kuamua ilikuwa mara kwa mara
marekebisho ya eneo la somo. Fomu za kuripoti hubadilika mara kwa mara
nyaraka na mbinu za kuzipata. Hali ilitokea wakati mradi uliposimama
endelea na mahitaji ya mtumiaji. Na siku moja wakati ulikuja wakati
lengo na sababu za msingi, maendeleo yanaweza kuzikwa kwa usalama. Hata hivyo
ghafla akawekwa mbele yangu kazi maalum ufafanuzi
mzigo wa kazi wa mfuko wa darasa kwa muhula. Katika hatua hii, ya washiriki watatu
Nilikuwa peke yangu niliyebaki wa mradi, lakini mfumo huu mdogo haukutekelezwa na utekelezaji wake
haikuwa hata katika mipango ya maendeleo ya haraka ya mradi. Kuhusu vitu vidogo kama vile
uundaji mzuri wa shida, hesabu ya nguvu ya kazi ya kazi, mgao
Hakuna hata aliyefikiria juu ya rasilimali za ziada. Ili kukamilisha kazi iliyokuwepo
wiki mbili zimetengwa. Wakati huo huo, hoja zangu kuhusu kutowezekana kwa kutimiza
tatizo hili halikuzingatiwa kimsingi. Uamuzi wangu wa kwanza ulikuwa kutafuta
mwenyewe mwajiri mwingine, kwani katika wiki mbili nililazimika kuandika sio tu
moduli ya kuchambua mzigo wa kazi wa mfuko wa darasani, lakini pia mfumo wa kuingia kwa ratiba
madarasa, udhibiti wa overlays na mengi zaidi. Nje ya mtandao, kazi hii haiwezi kutatuliwa
Kimsingi, tunahitaji data ya awali. Na si tu data ya awali, lakini moja sahihi
data ya awali, ambayo kazi zote hapo juu hufuata. Hata hivyo,
Sijui kwanini, lakini nilichukua suluhisho la shida hii.

Ni kawaida kuzungumza juu ya maendeleo kwa kutumia njia za classical katika kesi hii
isiyofaa. Hapa ndipo mbinu za XP zinakuja kwa manufaa. Muhtasari wa jumla kuhusu kazi I
tayari ilikuwa, lakini kulikuwa na nuances nyingi ambazo zinaweza uwezekano
kwa kiasi kikubwa kuongeza kiasi cha kazi. Nilianza kazi kwa kupiga namba
idara ya elimu na kuanza bombard mtu ambaye alijibu simu na maswali mengi, majibu kwa
ambayo sikuweza kuipata peke yangu au ambayo sikuwa na uhakika nayo.
.
Nilizindua Rational Rose na kuanza kujenga mfano. Mwishoni mwa siku ya kazi
Nilichora mfano ambao ulionekana kunitosha zaidi au kidogo. Baada ya kazi I
alichukua hatua nyingine kulingana na itikadi ya XP. Nilimtoa rafiki yangu nje
kufanya kazi katika idara ya elimu kunywa bia. Katika mchakato huu, muhimu katika yote
mahusiano ya tukio hilo, nilimweleza maono yangu ya programu, interface yake na
mantiki ya kazi. Yeye, kwa upande wake, alianza kuzungumza juu ya hitaji hilo
kutatua baadhi ya matatizo ya ndani. Kufikia jioni nilielewa wazi zaidi nini
bado inahitaji kufanywa ndani ya mfumo wa mradi huu (sikuwa na shaka tena kuwa kazi hiyo
inapaswa kuzingatiwa kama mradi tofauti). Walakini, nyingine haikutatuliwa
Suala muhimu ni uchaguzi wa zana za maendeleo. Matukio yanayoelezwa yalitukia lini?
matukio, nilianza kujifunza kikamilifu teknolojia ya MDA. Kwa kifupi, kiini chake ni hiki:
vipande vya msimbo wa programu na miundo ya data huzalishwa kiotomatiki kulingana na
kutoka kwa mfano wa UML, ambayo inaweza kupunguza kwa kiasi kikubwa muda wa maendeleo. Ndani
Katika makala hii sitaelezea kwa undani kanuni za uendeshaji wa MDA, lakini nataka
kuteka mawazo yako kwa ukweli kwamba matumizi ya teknolojia hii ni kabisa
inalingana na "roho ya XP". Hii ni kutokana na ukweli kwamba moja ya masharti ambayo
Mbinu za XP zitafanya kazi kwa mafanikio, hii itapunguza gharama ya mabadiliko yaliyofanywa
Programu iko katika hatua za mwisho za maendeleo. Miongoni mwa sababu zinazochangia
Ili kufikia hili, sio muhimu kutumia mpya mbalimbali
teknolojia za programu. Ninagundua kuwa ni unyenyekevu wa kurekebisha tena MDA
maombi ni moja ya faida kuu za teknolojia hii. Kwa ujumla, juu
Leo kuna utekelezaji mwingi wa MDA, nilichagua
Ujasiri kwa Delphi.

Lakini katika hali yangu kulikuwa na "wakati wa kuteleza". Kwanza, kutambua hilo
MDA hutoa manufaa fulani, bado sina uhakika wa kutosha
walimiliki teknolojia hii na hawakuwa na uzoefu wa kuandika maombi ya MDA.
Pili, nilielewa kuwa vipande vingine vya nambari vitakuwa shida
kutekelezwa kwa kutumia zana za kawaida za MDA, na kuna kazi nyingi za "mwongozo" zinazopaswa kufanywa
coding", ambayo katika kesi hii itakuwa na maelezo fulani.

Njia mbadala ilikuwa kuandika "kawaida" Maombi ya Delphi. Nilizindua
ICQ na nikaandika ujumbe kwa rafiki yangu, mfuasi wa Bold. Baada ya I
Nilimweleza kwa ufupi kiini cha tatizo, nikauliza atafanya nini badala yangu.
Alijibu kitu kama hiki: “Ama piga mbizi moja kwa moja kwenye Bold, au
hutawahi bwana. Kufanya mradi mkubwa ni njia bora ya kujifunza
teknolojia." Kwa kweli, sikutarajia jibu lingine.

Asubuhi nilichukua mfano uliopo na kuanza kujenga maombi. Kweli, jenga. KWA
Sikuanza kuweka msimbo, nilichora tu kiolesura cha mtumiaji, wengi
vipengele ambavyo vilianza kufanya kazi karibu mara moja. Kwa mapumziko ya moshi nilijaribu kutoka ndani
kampuni ya wafanyikazi wa idara ya elimu, hii iliniruhusu kuvuta nyingine
"mwathirika" kwenye skrini ya kufuatilia kwake na (sio bila kiasi fulani cha kiburi) alionyesha
matokeo ya kati. Hivyo, kanuni ya maoni ilitekelezwa.
Unaweza kusema kwa kufaa: "Vipi kuhusu upangaji wa programu jozi?" Ndiyo,
Kwa kweli, mimi ndiye pekee niliyehusika katika mradi kama mpanga programu. Lakini mimi hapa
Acha nitajie bahati mbaya moja zaidi. Katika kipindi hicho
wakati matukio yaliyoelezewa yalitokea, mimi, pamoja na kikundi cha watengenezaji -
wapendaji walianzisha mradi wa mtandao uliotolewa mahususi kwa MDA. Na hapo ndipo nilipo
ilikuja mahali pagumu zaidi katika maendeleo yake, mradi huu uliletwa
matokeo yasiyotarajiwa kabisa.

Kwa muda wa siku kadhaa, niliandika kanuni kwa utaratibu unaotekeleza maonyesho ya shughuli
kwenye skrini. Vipengele vya kawaida udhibiti haukuruhusu kila kitu kuonyeshwa kwenye skrini
data katika fomu ambayo kawaida huwasilishwa. Nilitaka hivyo
ikiwa mtumiaji wa mwisho angalau takriban anaelewa kile programu hufanya
na jinsi ya kufanya kazi nayo. Niliandika sehemu yangu mwenyewe kulingana na TStringGrid ya kawaida.
Sikuwa na uhakika ni nini uamuzi mzuri, lakini nambari ilifanya kazi. Katika jukwaa
ya mradi wetu, nilielezea suluhisho langu, nikitarajia kupokea aina fulani ya tathmini ndani
kwa muda mrefu kabisa. Walakini, dakika 15-20 baadaye alifika
jibu la kwanza. Imependekezwa Chaguo mbadala suluhisho, na baada ya dakika nyingine 10
mfano wa mtihani ulifika, si mmoja tu, bali wawili mara moja, kutoka kwa waandishi wawili. Kama
fikiria kwa nini watengenezaji walianza kutatua kwa shauku kama hiyo
shida ya mtu mwingine, basi unaweza kuja hitimisho rahisi. Kwanza, walikuwa nayo tu
kuvutia kupata baadhi suluhisho la ulimwengu wote, ambayo inaweza kuwa
tumia katika miradi yako. Na pili, walikuwa na nia ya mchakato yenyewe
mawasiliano. Ikumbukwe kwamba matatizo mengine yalitatuliwa kwa shauku sawa.
viwango mbalimbali vya ugumu. Kwa kweli, hii sio programu ya jozi ndani
uelewa wa kawaida. Badala yake, ni aina ya surrogate, lakini, hata hivyo, kuna pia
faida zake. Wacha tuseme kwamba mawazo na maoni yote yaliyoonyeshwa ni moja kwa moja
zilirekodiwa na zinaweza kupatikana wakati wowote.

Ningependa kukaa juu ya vipimo tofauti. Kama anavyopendekeza katika kitabu chake
"Programu Iliyokithiri" Kent Beck, vipimo vinapaswa kuandikwa mapema. Zaidi
Kwa kuongeza, kwa mwandishi inaonekana kama hii. Kuna programu maalum
iliyoandikwa na msanidi mwenyewe, unapobofya kwenye moja ya vifungo
vipimo vyote vinazinduliwa, na matokeo yake "mwanga" wa kijani huonekana kwenye skrini
katika kesi ya matokeo chanya na nyekundu vinginevyo. Haya ndiyo maelezo yangu
kiasi fulani cha kukatisha tamaa. Kukubaliana, ni vigumu kufikiria jinsi gani
unaweza kuandika programu inayoiga vitendo vya mtumiaji kabisa
hali.

Kama nilivyokwisha sema, sikujaribu kufuata madhubuti njia za kupita kiasi
kupanga programu. Na katika vitabu nilivyosoma ilisemwa bila shaka
kuandika mtihani ni moja ya pointi muhimu zaidi katika XP, na bila hiyo wengine
mbinu zisifanye kazi. Kwa nini nilipata kitu chanya mwishoni?
matokeo? Kila kitu kiligeuka kuwa rahisi sana. Ilinisaidia kujibu swali hili
hasa mfano huu na balbu za kijani na nyekundu. Jambo ni kwamba katika Bold
inawezekana kuonyesha kama inalingana kitu hiki mifano. NA
Hii inafanywa kwa usahihi kwa msaada wa "balbu za mwanga". Kwa kweli mistari miwili
ambayo karibu mara moja niliiingiza kwenye nambari ya maombi, iliniruhusu kuona ni ipi
ambapo tofauti hutokea (ikiwa ipo). Hii ndio iliyochukua nafasi
mimi kupima. Inawezekana kwamba mbinu hii haikuwa thabiti kabisa
wazo la asili la "kupima kabla ya maendeleo", lakini ilifanya kazi.

Ndani ya wiki moja nilikuwa na karibu maombi tayari. Wakati wa pili
wiki, nilifanya matoleo mawili zaidi, ambayo nilipanua kwa umakini utendaji, na
pia iliagiza data nyingi muhimu kwa kazi kutoka kwa zingine
mifumo ya kazi. Tatizo lilitatuliwa, na kwa kiasi kikubwa kutokana na matumizi
Mbinu za XP. Maana ya yote hapo juu, naona tu katika ukweli kwamba mfano huu ni
Kwa mazoezi, alithibitisha ufanisi wa programu kali.

Kwa kumalizia, nataka kutoa hoja moja zaidi. Upangaji wa hali ya juu,
kwa maoni yangu, sio tiba. Na njia zake zinaweza kutumika mbali na
kwa mradi wowote. Kimsingi, mradi unaozingatiwa, kulingana na ishara zingine
ilianguka katika kitengo cha miradi ambapo kutumia XP haipendekezi.
Hata hivyo, kwa mbinu rahisi zaidi, matumizi ya mbinu kali
programu inaweza kuleta matokeo ya kushangaza kabisa. Wakati wa kusoma
vitabu vya waandishi wa kigeni vilivyotolewa kwa mada hii kwa wasomaji wa ndani
Mtu anaweza kufikiria kuwa mbinu za XP haziwezi, kimsingi, kutumika katika
masharti yetu. Na sio tu kwamba uhusiano kati ya watengenezaji na
wateja, pamoja na uhusiano katika timu ya maendeleo iliyoelezwa katika vitabu
mifano inategemea kanuni tofauti kidogo. Ni suala la tofauti zaidi
mawazo. Walakini, kurekebisha XP kwa hali zetu inawezekana kabisa, na hii inaweza
toa matokeo ya kuvutia sana.

http://xprogramming.com.ua/ - dunia
programu kali

http://www.xprogramming.ru/ -
programu kali katika Kirusi

http://www.maxkir.com/ - kuhusu maendeleo
programu

http://xprogramming.com/ - tovuti
Mwana itikadi wa XP Ron Jeffries

Pengine kila mbuni au mchambuzi angalau mara moja katika maisha yake amekutana na mteja anayetaka kupata mradi wake kwa bei nafuu iwezekanavyo na, zaidi ya hayo, kwa muda mfupi iwezekanavyo. Lakini ikiwa gharama ya mradi ni somo halisi la kujadiliana, basi kujadiliana kuhusu kurekebisha tarehe za mwisho za utoaji wa mradi ni ngumu zaidi. Kuna wateja zaidi na zaidi wasio na subira leo, ambayo inaelezewa na hali ya soko la kisasa la nguvu, kiwango cha kuanguka cha uaminifu kati ya wasanii na wateja, na tabia ya wawekezaji ambao hamu yao huja wakati wa kula (ikiwa kuna kazi zaidi au chini). toleo la bidhaa, pesa kwa maendeleo zaidi wanatoa kwa hiari zaidi), nk. Katika suala hili, mbinu za maendeleo za kitamaduni (ambazo mzunguko mrefu wa muundo halisi na ukusanyaji wa habari, wakati mteja anawekeza pesa kubwa, lakini hapati matokeo halisi kwa muda mrefu) huingia kwenye mgongano mkali sana na masilahi ya mteja. mteja asiye na subira. Haya yote yalitoa msukumo kwa ukuzaji wa mbinu mbadala za usanifu katika pande mbili kuu: kuongeza imani ya wateja kwa kutoa ushahidi halisi wa mchakato wa maendeleo unaoendelea na kupunguza kwa kasi muda wa maendeleo ya bidhaa. Kundi la mbinu kama hizo huitwa "programu hai".

Uendelezaji wa programu kwa kasi na shirikishi

Kwa kawaida, watumiaji wa mwisho na usimamizi wa wateja wanaamini kuwa mchakato wa kubuni umeshindwa ikiwa vipengele halisi vya nje ya rafu havipatikani. Mara nyingi, mteja anasisitiza kutekeleza hatua ya utekelezaji wa mradi kabla ya ratiba ili kupata matokeo maalum na kuionyesha haraka iwezekanavyo. Katika hali hii, inavutia sana kuchagua Ukuzaji wa Maombi ya Kuharakishwa (AAD) au Ukuzaji wa Maombi ya Shirikishi (CAD). Mbinu kama hizo zinahusisha kutengeneza kielelezo kinachofanya kazi na kisha kuionyesha kwa watumiaji, ambao wanatambua kile wanachopenda na kile wasichopenda. Baada ya hayo, mbuni huboresha mfano kwa kuzingatia maoni yaliyotolewa, na kisha anaonyesha tena kile kilichotokea. Mchakato unarudiwa hadi watumiaji waridhike na kile wanachokiona na mfano kuwa programu inayofanya kazi. Kwa kawaida kikomo cha muda na idadi ya marudio huwekwa, vinginevyo watumiaji watahitaji uboreshaji mpya kwa mfano. Kwa nadharia, hii hukuruhusu kupata mfumo ambao watumiaji wanahitaji.

Kwa hivyo hapa tunaona mfano wa ukuzaji unaorudiwa na mizunguko mifupi ya ond katika visa vyote viwili. Katika njia zote mbili, wakati unaotumika katika hatua za mwanzo za muundo umepunguzwa: mkakati (ikiwa umeachwa kabisa au umeunganishwa na uchambuzi), uchambuzi (katika hali nyingi ni mdogo kwa uteuzi wa awali wa habari na uchambuzi wa fomu - kama sheria, ripoti, ambayo hutumiwa kurejesha muundo wa kazi za mfumo), kubuni (inayolenga kupata mfano wa msingi haraka iwezekanavyo). Matokeo ya maendeleo ni mfano, ambayo ni chini ya utekelezaji wa viwanda. Katika kesi hii, upimaji unafanywa kwa ushiriki kamili wa mteja, au mteja anakuwa mjaribu (bora, anayejaribu beta).

Katika mazoezi, mbinu hii ya maendeleo ya maombi inahusishwa na matatizo yafuatayo:

Uangalifu wote umewekwa kwenye fomu za skrini, na kila kitu kinachohusiana na sheria za usindikaji wa data na utendaji wa mfumo hubaki nyuma ya pazia. Kuna jaribu la kuanza kufanya kazi na ripoti, wakati ripoti sio bidhaa ya kuanzia, lakini bidhaa inayotokana na mfumo wa habari.

Moduli zimeundwa kwa kutengwa kutoka kwa kila mmoja. Matokeo ya hii ni mgongano kati ya moduli, marudio ya kazi na data, ambayo inaweza kutambuliwa tu kwa kupima seti ya moduli.

Utendaji unapanuliwa kwa sambamba katika pande kadhaa, kwa hivyo muundo wa ghala la data lazima udhibitiwe. Kwa URP, muundo wa hifadhidata unafanana na junkyard, ambapo meza hutupwa pamoja kwa haraka, na matokeo yake ni seti ya data kinzani na nakala.

Njia ambazo isipokuwa zinashughulikiwa zinageuka kuwa tofauti kwa moduli tofauti.

Shida ya kujumuisha moduli huibuka: kama sheria, mfumo kamili haufanyi kazi, kwa sababu hapo awali iliundwa kama seti ya vifaa ambavyo baadaye viliunganishwa haraka kwa kila mmoja.

Utayarishaji Mkubwa

Kanuni za XP na mbinu zinazotumiwa kuharakisha maendeleo

Kent Beck anachukuliwa kuwa baba-itikadi wa upangaji uliokithiri. XP ni mbinu changa, tathmini ambazo zinapingana sana - kutoka kwa shauku hadi hasi kali. Kanuni kuu ni:

Urahisi wa ufumbuzi.

Maendeleo makubwa katika vikundi vidogo (si zaidi ya watu 10), mawasiliano ya kazi ndani ya kikundi na kati ya vikundi (mawasiliano).

Maoni kutoka kwa mteja, ambaye kwa hakika anahusika katika mchakato wa ukuzaji.

Kiwango cha kutosha cha ujasiri na nia ya kuchukua hatari.

Jambo la kwanza katika kuharakisha maendeleo ni kurudia: maendeleo hufanywa kwa marudio mafupi na uhusiano hai na mteja. XP ni mchakato wa maendeleo unaorudiwa, ambao yenyewe sio wa mapinduzi. Inapendekezwa kuweka marudio kama mafupi, muda uliopendekezwa ni wiki 2-3 na sio zaidi ya mwezi 1. Kwa kurudia mara moja, kikundi cha waandaaji wa programu kinahitajika kutekeleza mali kadhaa za mfumo, ambayo kila moja inaelezewa katika hadithi ya mtumiaji. Hadithi za watumiaji katika kesi hii ni habari ya awali kwa misingi ambayo moduli imeundwa. Hadithi za watumiaji ni tofauti na kesi za utumiaji: hadithi ya mtumiaji ni fupi - aya 1-2, wakati kesi za utumiaji kawaida huandikwa kwa kina, na mtiririko kuu na mbadala - na hivyo kusababisha takriban ukurasa pamoja na mchoro (urasimishaji wa kawaida ni inayopendekezwa sasa katika UML); Hadithi za watumiaji huandikwa na watumiaji wenyewe (ambao katika XP ni sehemu ya timu) kinyume na kesi za utumiaji, ambazo kwa kawaida huandikwa na mchambuzi wa mifumo. Ukosefu wa urasimishaji wa maelezo ya data ya pembejeo ya mradi katika XP hutafutwa kulipwa kwa kujumuisha mteja kikamilifu katika mchakato wa ukuzaji kama mshiriki kamili wa timu na kwa kuwasiliana mara kwa mara na mteja (mawasiliano hai na usaidizi wa maoni endelevu. ) Katika kesi hii, uliokithiri ni kiwango ambacho mteja anahusika katika jikoni ya programu, ambayo ni kutokana na tamaa ya kukandamiza muda wa maendeleo kwa njia ya mawasiliano na maoni.

Jambo la pili katika kuharakisha maendeleo ya bidhaa ni uwepo wa vikundi vidogo na programu za jozi (wakati watengeneza programu wawili huunda msimbo pamoja katika sehemu moja ya kazi ya kawaida). Yote hii inalenga kufikia kiwango cha juu cha mawasiliano katika kikundi, na pia katika kuchunguza matatizo (makosa yote na muda uliopotea) mapema iwezekanavyo. Programu ya jozi ina lengo la kuimarisha mradi huo, kwa kuwa kwa mbinu hii kuna hatari kubwa ya kupoteza msimbo kutokana na kuondoka kwa programu ambaye hakuweza kuhimili ratiba kali ya kazi. Katika kesi hii, programu ya pili kutoka kwa jozi ina jukumu la "mrithi" wa kanuni (ambayo kwa njia za classical inatekelezwa katika nyaraka za kiufundi). Pia ni muhimu jinsi hasa vikundi vinasambazwa katika nafasi ya kazi - XP hutumia nafasi ya kazi ya wazi, ambayo inachukua upatikanaji wa haraka na wa bure kwa kila mtu kwa kila mtu; Kwa kawaida, nafasi ya kazi imejengwa karibu na mduara.

Mazoezi

Sitiari ya mfumo. Sitiari nzuri ya mfumo ina maana ya kutaja madarasa na vigeu kwa urahisi. Katika maisha halisi, kupata sitiari ni kazi ngumu sana; kupata sitiari nzuri si rahisi. Kwa hali yoyote, timu lazima iwe na sheria zinazofanana za majina.

Mikataba ya usimbaji. Viwango vya usimbaji vinahitajika ili kusaidia mbinu zingine: umiliki wa msimbo ulioshirikiwa, upangaji wa programu jozi, na urekebishaji upya. Bila kiwango cha umoja, ni angalau vigumu zaidi kutekeleza mazoea haya, na kwa kweli haiwezekani kabisa: kikundi kitafanya kazi kwa ukosefu wa mara kwa mara wa muda. Viwango vya kina havihitajiki, vitu muhimu tu vinapaswa kusawazishwa. Kuamua vitu muhimu zaidi vya viwango katika XP ni jambo la kibinafsi.

Kuunda upya. Kurekebisha upya ni uboreshaji wa nambari iliyopo kuelekea kurahisisha, ambayo inahusisha kazi ya mara kwa mara ili kurahisisha msimbo. Kwa kuweka msimbo kwa uwazi na kufafanua vipengele vya msimbo mara moja tu, watayarishaji programu hupunguza idadi ya hitilafu wanazopaswa kurekebisha baadaye. Wakati wa kutekeleza kila kipengele kipya cha mfumo, mpangaji programu lazima azingatie ikiwa inawezekana kurahisisha msimbo uliopo na jinsi hii itasaidia kutekeleza kipengele kipya. Kwa kuongeza, urekebishaji upya hauwezi kuunganishwa na muundo: ikiwa msimbo mpya unaundwa, urekebishaji upya lazima uahirishwe.

Kupima Tofauti na mbinu nyingine nyingi, kupima katika XP ni mojawapo ya vipengele muhimu zaidi. Njia iliyokithiri ni kuandika majaribio kabla ya kuandika nambari. Kila moduli lazima iwe na jaribio la kitengo - jaribio la moduli hii; Kwa hivyo, katika upimaji wa urekebishaji wa XP unafanywa (upimaji wa kurudi, "usio na uharibifu wa ubora" wakati wa kuongeza utendaji). Makosa mengi yanarekebishwa katika hatua ya kuweka msimbo. Vipimo vimeandikwa na watengeneza programu wenyewe; programu yoyote ana haki ya kuandika mtihani kwa moduli yoyote. Kanuni nyingine muhimu: mtihani huamua msimbo, na si kinyume chake (njia hii inaitwa maendeleo yanayotokana na mtihani), yaani, kipande cha msimbo huwekwa kwenye hifadhi ikiwa na tu ikiwa majaribio yote yatapita kwa mafanikio, vinginevyo mabadiliko haya ya kanuni ni. kukataliwa.

Hatari zilizopo za kutumia mbinu

Inafaa kuangazia hatari za XP ambazo zinaweza kushindwa mradi ikiwa hazitazingatiwa na kuzuiwa.

Sitiari. Mwonekano wa jumla wa mfumo hubainishwa kwa kutumia sitiari au seti ya mafumbo ambayo mteja na watayarishaji programu hufanya kazi pamoja. Ikiwa mchakato haujasajiliwa na muundo wa kumtaja haujasanifishwa, mchakato huo unaweza kurudiwa mara kwa mara.

Mabadiliko ya mara kwa mara ya matoleo (matoleo madogo). Mfumo huo umewekwa ndani ya miezi michache baada ya kuanza kwa utekelezaji, bila kusubiri ufumbuzi wa mwisho wa matatizo yote yaliyotolewa. Mzunguko wa kutolewa kwa matoleo mapya unaweza kutofautiana kutoka kila siku hadi kila mwezi. Haiwezekani kupima sehemu ngumu zaidi au chini katika kipindi kama hicho; mteja hufanya kama kijaribu beta. Mifumo ambayo inahitaji operesheni ya kudumu ya kuaminika (kinachojulikana hitaji la 24/7) iko hatarini.

Kuunganishwa kwa kuendelea. Msimbo mpya umeunganishwa kwenye mfumo uliopo ndani ya saa chache. Baada ya hayo, mfumo unaunganishwa tena kuwa moja na vipimo vyote vinaendeshwa. Ikiwa angalau moja yao haijafanywa kwa usahihi, mabadiliko yaliyofanywa yanaghairiwa. Katika kesi hii, sio wazi kila wakati ni nani atakayesahihisha makosa, sio tu ya ndani, bali pia yale yanayosababishwa na nambari isiyo sahihi. Haijapangwa kufanya majaribio magumu katika hatua hii; Kwa kuongeza, mabadiliko yanahifadhiwa hata kama kosa limegunduliwa.

Wiki ya saa 40. Kiasi cha kazi ya ziada haiwezi kuzidi wiki moja ya kazi kwa muda. Hata matukio ya pekee ya saa za ziada ambayo hutokea mara kwa mara ni ishara ya matatizo makubwa ambayo yanahitaji uangalifu wa haraka. Kama mazoezi ya kutumia programu kali inavyoonyesha (licha ya mifano kadhaa chanya iliyotolewa na wafuasi wa njia hii), nyongeza ya njia hii ni sheria, sio ubaguzi, na mapambano dhidi ya shida katika kesi hii ni jambo la kawaida. Inaongezeka wakati wa uingizwaji wa toleo la sasa la bidhaa ghafi na lingine - chafu kidogo. Ikiwa mteja hatapokea ushahidi thabiti wa uboreshaji wa mfumo, basi una tatizo kubwa.

Vipimo. Watayarishaji wa programu huandika majaribio ya kitengo kila wakati. Kwa pamoja, vipimo hivi vinapaswa kufanya kazi kwa usahihi. Kwa hatua za kurudia, wateja huandika vipimo vya kazi, ambavyo pia vinahitajika kufanya kazi kwa usahihi. Walakini, katika mazoezi hii haipatikani kila wakati. Ili kufanya uamuzi sahihi, unahitaji kuelewa ni nini gharama ya kutoa mfumo na kasoro inayojulikana, na kulinganisha hii na gharama ya kuchelewesha uondoaji wake. Vipimo vilivyoandikwa na waandaaji wa programu wenyewe (haswa wakati wa kufanya kazi kwa muda wa ziada) hazifanyi kazi kikamilifu na kwa hakika hazizingatii upekee wa kazi ya watumiaji wengi. Wasanidi programu kwa kawaida hawana muda wa kutosha kwa ajili ya majaribio ya kina zaidi. Tatizo hili linatatuliwa kwa kuwasiliana na wawasiliani kwa muda fulani, ambao unahusishwa na jukumu kubwa la sababu ya kibinadamu: tangu nyaraka za kiufundi hazipo hapo awali, habari hupitishwa kwa njia ya mawasiliano kati ya waandaaji wa programu. Ingawa, bila shaka, inawezekana kujenga mfumo wa maendeleo kwa namna ambayo watu sawa watakabiliana na kila kitu tangu mwanzo hadi mwisho. Ni muhimu kuongeza kwa hapo juu kwamba upimaji wa mfumo sio mdogo kwa vipengele vya kupima (vitengo); Vipimo vya mwingiliano kati yao sio muhimu sana, na hiyo hiyo inatumika kwa vipimo vya kuegemea. Walakini, njia iliyokithiri ya programu haitoi uundaji wa majaribio ya darasa hili. Hii inafafanuliwa na ukweli kwamba vipimo vile wenyewe vinaweza kuwakilisha kanuni ngumu kabisa (hii ni kweli hasa kwa vipimo vinavyoiga uendeshaji halisi wa mfumo). Teknolojia hii pia haizingatii darasa lingine muhimu la vipimo - vipimo vya tabia ya mfumo wakati kiasi cha habari iliyosindika huongezeka. Kwa mzunguko wa juu wa mabadiliko ya toleo, haiwezekani kiteknolojia kufanya mtihani huo, kwani utekelezaji wake unahitaji msimbo wa mradi thabiti na usiobadilika, kwa mfano, ndani ya wiki. Katika kesi hii, itabidi ama kusimamisha maendeleo ya vipengele, au kuunda toleo la sambamba la mradi wakati wa mtihani, ambao utabaki bila kubadilika, wakati mwingine utabadilika. Kisha utahitaji kupitia mchakato wa kuunganisha msimbo. Lakini katika kesi hii, mtihani utalazimika kuundwa upya, kwa kuwa mbinu kali za programu haitoi tu maendeleo ya zana zinazoruhusu kutabiri tabia ya mfumo chini ya mabadiliko fulani. XP inapendekeza kusuluhisha matatizo haya kupitia kipengele sawa cha binadamu na nidhamu binafsi.

Hakuna zaidi ya sheria tu. Wanachama wa timu wanaofanya kazi kwa kutumia teknolojia iliyokithiri ya upangaji hujitolea kufuata sheria zilizowekwa. Walakini, hizi sio zaidi ya sheria, na timu inaweza kuzibadilisha wakati wowote ikiwa wanachama wake watafikia makubaliano kimsingi juu ya mabadiliko yaliyofanywa. Kanuni hii inategemea sana sababu ya kibinadamu; Ukiukaji wa nidhamu ya maendeleo unahusisha muda uliopangwa na, kwa sababu hiyo, husababisha kuanguka kwa mradi.

Kama matokeo, tunapata njia ambayo inaweza kubadilika kwa umakini na mahitaji ya mara kwa mara ya mradi, lakini wakati huo huo sio huru kutokana na idadi ya mapungufu ya kimsingi na inategemea sana sababu ya kibinadamu.

Kwa hivyo, matokeo ya kutumia njia iliyokithiri ya programu inaweza kuwa nzuri sana au mbaya sana.

Upangaji uliokithiri - mbinu maendeleo ya haraka programu. Inajumuisha seti ya mbinu na kanuni zinazoruhusu, kibinafsi na kwa pamoja, kuboresha mchakato wa maendeleo. Mbinu hii pia inadhibiti haki za watengenezaji na wateja.

Haki na majukumu

Katika Upangaji Uliokithiri, majukumu yote yameelezewa wazi. Kila jukumu linakuja na seti maalum ya haki na wajibu. Kuna majukumu mawili muhimu hapa: mteja na msanidi.

Mteja

Mtu au kikundi cha watu wanaopenda kuunda maalum bidhaa ya programu. Ana haki na wajibu zifuatazo:

rekebisha tarehe za kutolewa kwa matoleo ya bidhaa;
kufanya maamuzi kuhusu vipengele vya programu iliyopangwa;
kujua makadirio ya gharama ya kila sehemu ya kazi;
kufanya maamuzi muhimu ya biashara;
kujua hali ya sasa ya mfumo;
badilisha mahitaji ya mfumo wakati ni muhimu.

Ili kutekeleza haki zake kwa mafanikio, mteja lazima ategemee data iliyotolewa na wasanidi programu.

Msanidi

Mmoja au kikundi cha watu wawili hadi kumi wanaohusika moja kwa moja katika upangaji programu na masuala yanayohusiana na uhandisi. Msanidi programu ana haki na majukumu yafuatayo:

kupata ujuzi wa kutosha wa masuala ya kupangwa;
kuwa na uwezo wa kufafanua maelezo wakati wa mchakato wa maendeleo;
toa makadirio elekezi lakini ya wazi ya juhudi zinazohitajika kwa kila kipengele au hadithi ya mtumiaji;
kurekebisha makadirio kwa ajili ya sahihi zaidi wakati wa mchakato wa maendeleo;
kutoa tathmini ya hatari zinazohusiana na matumizi ya teknolojia maalum.

Majukumu ndani ya jukumu

Kila moja ya majukumu ya msingi ya Utayarishaji Uliokithiri yanaweza kuboreshwa na majukumu madogo. XP inaruhusu mchanganyiko wa majukumu ndani ya mtu mmoja.

Upande wa mteja

Mkusanyaji wa Hadithi- mtaalamu wa somo na uwezo wa kueleza wazi na kuelezea mahitaji ya mfumo unaotengenezwa. Mtu huyu au kikundi cha watu kina jukumu la kuandika hadithi za watumiaji na kuondoa kutokuelewana kutoka kwa watayarishaji wa programu.

Mpokeaji- mtu anayefuatilia utendaji sahihi wa mfumo. Ana ufahamu mzuri wa eneo la somo. Majukumu ni pamoja na kuandika majaribio ya kukubalika.

Bosi mkubwa- inafuatilia kazi ya ngazi zote, kutoka kwa watengenezaji hadi watumiaji wa mwisho. Anadhibiti utekelezaji wa mfumo na masuala yanayohusiana na shirika. Anaweza pia kuwa mwekezaji katika mradi huo.

Upande wa msanidi programu

Mtayarishaji programu- mtu anayehusika katika uandikaji wa kiwango cha chini na muundo. Ana uwezo wa kutosha kutatua matatizo ya sasa ya maendeleo na kutoa makadirio ya uaminifu ya kazi zilizopangwa.

Mwalimu- msanidi mwenye uzoefu na ujuzi mzuri wa mchakato mzima wa maendeleo na mbinu zake. Kuwajibika kwa kutoa mafunzo kwa timu katika nyanja za mchakato wa maendeleo. Inatekeleza na kufuatilia utekelezaji sahihi wa mbinu za mchakato zinazotumika. Huvuta umakini wa timu kwa muhimu, lakini kwa sababu fulani, pointi za maendeleo zimekosa. Wakati huo huo, mwalimu, kama mtu mwingine yeyote, hajui yote na huzingatia maoni ya washiriki wengine wa timu.

Mtazamaji- mjumbe wa timu ya maendeleo, anayeaminiwa na kikundi kizima, ambaye anafuatilia maendeleo ya maendeleo. Analinganisha makadirio ya awali gharama za kazi na kutumika kwa kweli, kuonyesha viashiria vya kiasi cha kazi ya timu. Hizi ni kama vile kasi ya wastani na asilimia ya kazi zilizokamilishwa na zilizopangwa. Taarifa hii hutolewa kwa mteja kwa udhibiti wa wakati wa hali hiyo. Baadhi ya habari hii hutolewa kwa watengenezaji bila kutarajia, ili wajue hali ya mradi, ambapo shida hutokea, na nini kingine kinaweza kufanywa.

Mwanadiplomasia- mtu mwenye urafiki ambaye huanzisha mawasiliano kati ya washiriki wa timu. Kwa kuwa mtiririko wa hati umepunguzwa, mawasiliano ya mara kwa mara na uhamisho wa uzoefu ndani ya timu, ufahamu bora wa mahitaji ya mfumo, ni muhimu. Mwanadiplomasia hudhibiti na kurahisisha mawasiliano kati ya wateja na watengenezaji. Ni kiungo muhimu katika mikutano. Inazuia kuachwa, kuongezeka kwa shauku na ugomvi usio wa lazima. Mwanadiplomasia hawezi kulazimisha maoni yake kwa wale wanaojadili.

Majukumu ya nje

Mshauri- mtaalamu aliye na ujuzi mahususi wa kiufundi kusaidia watengenezaji wenye matatizo magumu kusuluhisha. Kawaida huletwa kutoka nje.

Sheria za Utayarishaji Mkubwa

Mkataba wa kuweka msimbo

Uko kwenye timu inayoshughulikia mradi huu muda mrefu. Watu huja na kuondoka. Hakuna misimbo moja pekee na msimbo ni wa kila mtu. Kutakuwa na nyakati ambapo unahitaji kuelewa na kurekebisha msimbo wa mtu mwingine. Wasanidi programu wataondoa au kubadilisha nakala za msimbo, kuchanganua na kuboresha madarasa ya watu wengine, n.k. Baada ya muda, haitawezekana kusema ni nani mwandishi wa darasa fulani.

Kwa hivyo, kila mtu lazima atii viwango vya kawaida vya kuweka msimbo - uundaji wa msimbo, kutaja madarasa, vigeu, vidhibiti, mtindo wa maoni. Kwa njia hii, tutakuwa na uhakika kwamba tunapofanya mabadiliko kwenye msimbo wa mtu mwingine (ambayo ni muhimu kwa maendeleo ya fujo na ya kukithiri), hatutaigeuza kuwa Babel Pandemonium.

Hapo juu ina maana kwamba wanachama wote wa timu lazima wakubaliane viwango vya kawaida kusimba. Haijalishi zipi. Kanuni ni kwamba kila mtu azitii. Wale ambao hawataki kufuata yao wanaondoka kwenye timu.

Umiliki wa kanuni za pamoja

Umiliki wa msimbo unaoshirikiwa huhimiza wasanidi programu kuwasilisha mawazo kwa sehemu zote za mradi, si tu moduli zao wenyewe. Msanidi programu yeyote anaweza kubadilisha msimbo wowote ili kupanua utendakazi, kurekebisha hitilafu, au kirekebisha tena.

Kwa mtazamo wa kwanza inaonekana kama machafuko. Walakini, kwa kuzingatia kwamba angalau nambari yoyote iliundwa na watengenezaji kadhaa, kwamba vipimo vya kitengo hukuruhusu kuangalia usahihi wa mabadiliko yaliyofanywa, na kwamba katika maisha halisi bado unapaswa kuelewa msimbo wa mtu mwingine kwa njia moja au nyingine, inakuwa wazi kuwa umiliki wa pamoja wa kanuni hurahisisha sana kufanya mabadiliko na kupunguza hatari inayohusishwa na umaalumu wa juu wa mwanachama mmoja au mwingine wa timu.

Kikao cha CRC

Tumia kadi za Daraja, Majukumu, Ushirikiano (CRC) kuunda mfumo kama timu. Kutumia kadi hurahisisha kujifunza kufikiria katika suala la vitu badala ya kazi na taratibu. Kadi pia huruhusu watu zaidi kushiriki katika mchakato wa usanifu (haswa timu nzima), na kadiri watu wanavyofanya muundo, ndivyo mawazo ya kuvutia italetwa.

Kila kadi ya CRC inawakilisha mfano wa kitu. Darasa la kitu linaweza kuandikwa juu, majukumu upande wa kushoto, mwingiliano upande wa kulia. Tunasema "huenda ikaandikwa" kwa sababu wakati kipindi cha CRC kinaendelea, washiriki kwa kawaida wanahitaji idadi ndogo ya kadi za majina ya darasa na si lazima zijazwe kabisa.

Kipindi cha CRC kinaenda hivi: kila mshiriki anatoa tena mfumo akisema ni ujumbe gani anatuma kwa vitu gani. Inapitia ujumbe mzima wa mchakato kwa ujumbe. Udhaifu na matatizo yanatambuliwa mara moja. Njia mbadala za muundo pia zinaonekana wazi katika uigaji wa mchakato.

Ili kurejesha utulivu, kupunguza idadi ya wakati huo huo kuingiliana kwa mbili hutumiwa mara nyingi.

Mteja

Moja ya mahitaji ya XP ni kwamba mteja anapatikana kila wakati. Hapaswi tu kusaidia timu ya maendeleo, lakini kuwa mwanachama wake. Awamu zote za mradi wa XP zinahitaji mawasiliano na mteja, ikiwezekana ana kwa ana - kwenye tovuti. Ni bora kukabidhi mteja mmoja au zaidi kwa timu ya usanidi. Tahadhari, mteja atahitaji muda mrefu, na ofisi ya mteja inaweza kujaribu kukupa mwanafunzi wa ndani kama mtaalamu. Unahitaji mtaalam.

Hadithi za Mtumiaji iliyoandikwa na mteja kwa msaada wa watengenezaji. Mteja husaidia kuhakikisha kuwa vipengele vingi vinavyohitajika vya mfumo vinashughulikiwa na Hadithi ya Mtumiaji.

Wakati wa kupanga toleo, mteja anahitaji kujadili chaguo la Hadithi za Mtumiaji ambazo zitajumuishwa katika toleo lililopangwa. Inaweza pia kuwa muhimu kukubaliana juu ya kipindi cha kutolewa yenyewe. Mteja hufanya maamuzi yanayohusiana na malengo ya biashara.

Chagua suluhisho rahisi zaidi

Muundo rahisi daima ni rahisi kutekeleza kuliko ngumu. Kwa hivyo kila wakati nenda kwa suluhisho rahisi zaidi ambalo linaweza kufanya kazi. Ikiwa unapata kitu ngumu, badala yake na kitu rahisi. Daima hubadilika kuwa haraka na kwa bei nafuu kuchukua nafasi ya nambari ngumu na rahisi kabla ya kuanza kuelewa nambari ngumu.

Refactor nambari ya mtu mwingine ikiwa inaonekana kuwa ngumu kwako. Ikiwa kitu kinaonekana kuwa ngumu, ni ishara ya uhakika matatizo katika kanuni.

Weka suluhisho rahisi iwezekanavyo kwa muda mrefu iwezekanavyo. Kamwe usiongeze utendakazi kwa siku zijazo - kabla ya kuhitajika. Walakini, kumbuka: kuweka muundo rahisi ni kazi ngumu.

Vipimo vya kiutendaji

Majaribio ya kukubalika (hapo awali yaliitwa pia majaribio ya Utendaji) yameandikwa kulingana na Hadithi ya Mtumiaji. Wanaona mfumo kama sanduku nyeusi. Mteja ana jukumu la kuthibitisha usahihi wa majaribio ya utendakazi. Majaribio haya hutumika kuthibitisha utendakazi wa mfumo kabla ya kuutoa katika toleo la umma. Majaribio ya kiutendaji ni ya kiotomatiki ili yaweze kuendeshwa mara kwa mara. Matokeo yanaripotiwa kwa timu na timu ina jukumu la kupanga marekebisho ya majaribio ya utendakazi.

Kuunganishwa mara kwa mara

Wasanidi wanapaswa kujumuisha na kutoa nambari zao za kuthibitisha kila baada ya saa chache ikiwezekana. Kwa hali yoyote, haupaswi kamwe kuweka mabadiliko kwa zaidi ya siku moja. Ushirikiano wa mara kwa mara huepuka kutengwa na kugawanyika katika maendeleo, ambapo watengenezaji hawawezi kuwasiliana kwa maana ya kubadilishana mawazo au tumia tena kanuni. Kila mtu anapaswa kuwa anaendesha toleo jipya zaidi.

Kila jozi ya wasanidi wanapaswa kuchangia msimbo wao haraka iwezekanavyo. Hii inaweza kuwa wakati UnitTests zote zitapita 100%. Kwa kuwasilisha mabadiliko mara kadhaa kwa siku, unapunguza matatizo ya kuunganisha hadi karibu sifuri. Ujumuishaji ni shughuli ya "lipa sasa au lipa zaidi baadaye". Kwa hiyo, kwa kuunganisha mabadiliko ya kila siku kwa sehemu ndogo, hutahitaji kutumia wiki ili kuunganisha mfumo katika moja nzima kabla ya mradi huo kutolewa. Daima fanyia kazi toleo jipya zaidi la mfumo.

Kwa meneja. Ikiwa msanidi hatawasilisha mabadiliko kwa zaidi ya siku moja, hii ni kiashirio dhahiri cha tatizo kubwa. Lazima ujue mara moja kinachoendelea. Uzoefu mzima wa timu za XP unasema kuwa sababu ya kuchelewa ni muundo duni kila wakati na lazima ifanyike upya baadaye.

Upangaji wa Kurudia

Mkutano wa Kupanga Marudio huitishwa kabla ya kuanza kwa kila marudio ili kupanga kazi zitakazofanywa kwa marudio hayo. Kwa kurudia, Hadithi za Mtumiaji huchaguliwa ambazo zilichaguliwa na mteja katika mpango wa kutolewa kuanzia muhimu zaidi kwa mteja na mbaya zaidi (kuhusisha hatari) kwa watengenezaji. Pia, majaribio ya Utendaji yaliyovunjwa yanajumuishwa katika urekebishaji.

Hadithi za Mtumiaji na kumbukumbu nyuma Majaribio ya kiutendaji yamegawanywa katika majukumu. Kazi zimeandikwa kwenye kadi. Kadi hizi ni mpango wa kina wa kurudia. Kila kazi inapaswa kuwa kati ya siku 1 hadi 3 zinazofaa kwa muda.

Wasanidi programu huchanganua kazi na kukadiria urefu wa muda unaohitajika ili kuzikamilisha. Kwa hivyo, kila msanidi anakadiria ni muda gani kazi itamchukua. Ni muhimu kwamba tathmini ya mwisho ya upeo wa kazi inafanywa na msanidi mwenyewe.

Kasi ya mradi huamua kama kazi zako zinafaa katika marudio au la. Muda wa jumla wa kazi zilizopangwa kwa marudio haipaswi kuzidi kasi iliyopatikana katika marudio ya awali. Ikiwa umeandika nyingi sana, basi mteja lazima aamue ni Hadithi zipi za Mtumiaji za kuahirisha kwa marudio yanayofuata. Ikiwa uliandika kidogo sana, basi unahitaji kuongeza Hadithi inayofuata ya Mtumiaji. Katika baadhi ya matukio, unaweza kumwomba mteja agawanye moja ya Hadithi ya Mtumiaji katika sehemu mbili ili kujumuisha sehemu katika marudio ya sasa.

Kuahirisha Hadithi ya Mtumiaji kwa marudio yanayofuata kunaweza kuonekana kuwa ya kutisha, lakini usijiruhusu kujitolea urekebishaji upya na Majaribio ya Vitengo ili kufanya mengi zaidi. Madeni katika makundi haya yatapunguza kasi yako haraka. Usifanye kile unachofikiri kitahitajika katika marudio yanayofuata - fanya kile kinachohitajika ili kukamilisha Hadithi za sasa za Mtumiaji.

Fuatilia kasi ya mradi na Hadithi za Watumiaji zinazosubiri. Inawezekana kwamba mpango wa kutolewa utalazimika kufanywa upya kila marudio matatu hadi tano. Hii ni sawa. Baada ya yote, mpango wa toleo ni kuangalia kwa siku zijazo na ni kawaida kutarajia kwamba utabiri wako utalazimika kurekebishwa.

Marudio

Ukuzaji wa kurudia huongeza kubadilika kwa mchakato. Gawanya mpango wako katika marudio ya wiki 2 hadi 3. Dumisha urefu wa kurudia mara kwa mara kwa muda wa mradi. Acha marudio yawe mapigo ya mradi wako. Huu ndio mdundo ambao utafanya maendeleo ya kupima na kupanga kuwa rahisi na ya kuaminika.

Usipange kazi mapema. Kusanya badala yake Upangaji wa Kurudia mwanzoni mwa kila marudio kupanga kitakachofanyika. Pia inachukuliwa kuwa ni ukiukaji wa sheria za kujitanguliza na kufanya kitu ambacho hakijapangwa katika iteration hii. Kwa hivyo, inawezekana kuweka mahitaji yanayobadilika ya Mteja chini ya udhibiti.

Chukua makataa ya kukamilisha kurudia kwa umakini. Pima maendeleo unapofanya kazi. Ikiwa ni wazi kuwa hutaweza kukamilisha kazi zote zilizopangwa kwa tarehe ya mwisho, kisha kukusanya Upangaji wa Iteration tena na utathmini upya kazi na uahirishe baadhi ya kazi.

Zingatia juhudi zako katika kukamilisha zaidi kazi muhimu, iliyochaguliwa na Mteja, badala ya kuwa na kazi kadhaa ambazo hazijakamilika zilizochaguliwa na msanidi.

Badilisha kazi

Ni muhimu mara kwa mara kubadilisha kazi kwa watengenezaji ili kupunguza hatari ya mkusanyiko wa maarifa na vikwazo katika kanuni. Ikiwa mtu mmoja tu kwenye timu yako anaweza kufanya kazi katika eneo fulani na mtu huyo kuondoka, au una mengi ya kufanya katika sehemu fulani ya programu, utagundua kuwa mradi wako unasonga mbele kidogo.

Mafunzo ya Msalaba ni kawaida kipengele muhimu katika makampuni ambayo yanajaribu kuepuka mkusanyiko wa ujuzi kwa mtu mmoja. Kuhamisha watu kupitia msimbo pamoja na upangaji wa jozi kimya kimya hukufanyia Mafunzo ya Msalaba. Badala ya mtu mmoja kujua kila kitu kuhusu kipande fulani cha msimbo, kila mtu kwenye timu yako anajua mengi kuhusu msimbo katika kila sehemu.

Timu inakuwa rahisi zaidi ikiwa kila mtu anajua vya kutosha kuhusu kila sehemu ya mfumo ili kuanza kuifanyia kazi. Badala ya kusubiri "guru" ili kumaliza kufanya kazi kwenye kipande muhimu cha kanuni, waandaaji wa programu kadhaa wanaweza kufanya kazi juu yake wakati huo huo.

Wakati wa kuanza mpya marudio kila msanidi lazima ahamie kwa kazi mpya. Upangaji wa programu wa Jozi husaidia kuondokana na tatizo la kuabiri (kumaanisha kuwa msanidi mpya anaweza kuanza kufanya kazi katika jozi na msanidi mwenye uzoefu kwenye uwanja).

Zoezi hili pia huhimiza mawazo mapya na msimbo ulioboreshwa.

Acha uboreshaji kwa ajili ya baadaye

Kamwe usiboresha chochote hadi usimbaji ukamilike. Usijaribu kamwe kukisia vikwazo vya utendaji vitakuwa wapi. Pima!

Fanya kazi, kisha uifanye kwa usahihi, kisha uifanye kazi haraka.

Oanisha programu

Nambari zote za mfumo wa uzalishaji (na hii inamaanisha isipokuwa suluhisho za majaribio) zimeandikwa kwa jozi. Watengenezaji wawili wameketi karibu na kila mmoja. Mmoja anaandika, mwingine anatazama. Wanabadilika mara kwa mara. Hairuhusiwi kufanya kazi peke yako. Ikiwa kwa sababu fulani wa pili wa jozi alikosa kitu (mgonjwa, mstaafu, nk), analazimika kukagua mabadiliko yote yaliyofanywa na wa kwanza.

Inaonekana isiyo ya kawaida, lakini XP inadai kwamba baada ya muda mfupi marekebisho: Watu wengi hufanya kazi vizuri wakiwa wawili-wawili. Wanaipenda hata kwa sababu kazi inafanywa haraka sana. Kanuni "Kichwa kimoja ni nzuri, lakini mbili ni bora" inatumika. Wanandoa kwa kawaida hupata masuluhisho bora zaidi. Kwa kuongeza, ubora wa kanuni huongezeka kwa kiasi kikubwa, idadi ya makosa hupungua, na kubadilishana ujuzi kati ya watengenezaji huharakishwa.

Refactor Bila Ruthlessly!

Sisi waandaaji programu huwa tunashikamana na muundo muda mrefu baada ya kuwa gumu. Tunaendelea kutumia tena nambari ya kuthibitisha isiyodumishwa kwa sababu bado inafanya kazi kwa njia fulani na tunaogopa kuivunja. Lakini ni ya manufaa kweli? XP inachukua maoni kwamba hii haina faida. Tunapoondoa upungufu, kuboresha muundo wa kizamani, ondoa vipande visivyotumiwa - tunafanya refactoring. Refactoring hatimaye kuokoa muda na kuboresha ubora wa bidhaa.

Kagua msimbo wowote bila huruma ili kurahisisha muundo wako unapoutengeneza. Weka nambari yako wazi na inayoeleweka ili iwe rahisi kueleweka, kurekebisha na kupanua. Hakikisha kila kitu kimeandikwa mara moja na mara moja tu. Hatimaye, inachukua muda kidogo kuliko polishing mfumo ngumu.

Mpango wa Kutolewa

Mpango wa Kutolewa unatengenezwa katika mkutano wa kupanga Toleo. Mipango ya Utoaji inaelezea mtazamo wa mradi mzima na hutumiwa baadaye kupanga marudio.

Ni muhimu kwamba watu wa kiufundi kufanya maamuzi ya kiufundi na wafanyabiashara kufanya maamuzi ya biashara. Upangaji wa Toleo hufafanua seti ya sheria zinazoruhusu kila mtu kufanya maamuzi yake. Sheria hizi zinafafanua njia ya kuunda mpango wa kazi ambao unakidhi kila mtu.

Kiini cha mkutano wa kupanga toleo kwa timu ya ukuzaji ni kukadiria kila Hadithi ya Mtumiaji katika wiki bora. Wiki inayofaa ni muda ambao unafikiri itachukua kukamilisha kazi ikiwa hakuna kitu kingine kinachokukengeusha. Hakuna utegemezi, hakuna kazi za ziada, lakini pamoja na vipimo. Kisha mteja anaamua ni kazi gani ni muhimu zaidi au kuwa na kipaumbele cha juu.

Hadithi za Watumiaji zimeandikwa kwenye kadi. Wasanidi programu na Mteja kwa pamoja huchanganya kadi kwenye jedwali hadi wapate seti ya Hadithi za Watumiaji ambazo kwa pamoja zitaunda Toleo la kwanza (au linalofuata). Kila mtu anataka kuifungua haraka iwezekanavyo. mfumo muhimu ambayo inaweza kujaribiwa.

Kutolewa kunaweza kupangwa kwa wakati au kiasi. Ili kubainisha ni Hadithi ngapi za Mtumiaji zinaweza kutekelezwa kwa tarehe mahususi au itachukua muda gani halisi seti hii kazi hutumia kasi ya mradi. Ukipanga kulingana na wakati, zidisha idadi ya marudio kwa kasi ya mradi ili kujua ni Hadithi ngapi za Mtumiaji zinaweza kutekelezwa. Unapopanga kwa kiasi, gawanya jumla ya idadi ya wiki zinazofaa zinazohitajika kwa Hadithi zote za Watumiaji kwa kasi ya mradi na utapata idadi ya marudio yanayohitajika ili kukamilisha toleo.

Ikiwa usimamizi haujaridhika na tarehe ya kukamilisha, inaweza kujaribu kupunguza makadirio ya upeo. Hupaswi kufanya hivi kamwe. Makadirio ya chini yana uhakika wa kuunda matatizo mengi baadaye. Badala yake, jadiliana na wasimamizi, wasanidi programu na wateja hadi upate mpango wa toleo ambao kila mtu anaweza kukubaliana nao.

Matoleo ya Mara kwa Mara

Wasanidi programu wanapaswa kutoa matoleo ya mfumo kwa watumiaji (au wanaojaribu beta) mara nyingi iwezekanavyo.

Kutolewa kwa Mipango kutumika kupata vipande vidogo vya utendaji ambavyo vina maana kubwa ya biashara na vinavyoweza kutolewa katika mazingira halisi katika hatua za mwanzo za maendeleo. Hii ni muhimu kwa upokeaji wa wakati kitaalam muhimu kuwa na uwezo wa kuathiri mchakato wa maendeleo. Kadiri unavyochelewesha kutoa sehemu muhimu ya mfumo, italazimika kuirekebisha.

Suluhisho la majaribio

Unda suluhu za majaribio ili kujibu maswali changamano ya kiufundi na kuhalalisha masuluhisho fulani ya kiteknolojia. Kuna hatari inayohusika katika uamuzi wowote wa teknolojia na suluhu za majaribio zimeundwa ili kupunguza hatari hii.

Tengeneza programu ambayo huzalisha tena tatizo chini ya uchunguzi na kupuuza kila kitu kingine. Masuluhisho mengi ya majaribio hayakusudiwi kutumiwa, kwa hivyo tarajia kutupiliwa mbali. Madhumuni ya kuziunda ni kupunguza hatari ya kufanya uamuzi usio sahihi wa kiufundi au kukadiria kwa usahihi zaidi wakati wa kutekeleza Hadithi ya Mtumiaji.

Mkutano umesimama

Kila asubuhi mkutano unafanyika kujadili matatizo, ufumbuzi wao na kuimarisha umakini wa timu. Mkutano huo unafanyika kwa kusimama ili kuepusha mijadala mirefu ambayo haiwavutii washiriki wote wa timu.

Katika mkutano wa kawaida, washiriki wengi hawachangia chochote, shiriki tu ili kusikia kile ambacho wengine wanasema. Kiasi kikubwa cha muda wa watu hupotezwa kupokea kiasi kidogo cha mawasiliano. Kwa hiyo, kuwa na kila mtu katika mikutano kunaondoa rasilimali kutoka kwa mradi na kuleta fujo katika kupanga.

Aina hii ya mawasiliano inahitaji mkutano wa kudumu. Ni bora kuwa na mkutano mmoja mfupi, wa lazima kuliko wengi mrefu ambao wasanidi wengi wanapaswa kuhudhuria.

Ikiwa una mikutano ya kila siku iliyosimama, basi mikutano mingine yote inapaswa kuhudhuriwa tu na watu hao ambao ni muhimu na wataleta kitu kwenye meza. Aidha, inawezekana hata kuepuka baadhi ya mikutano. Washiriki wakiwa wachache, mikutano mingi inaweza kufanyika moja kwa moja mbele ya mfuatiliaji, ambapo kubadilishana mawazo ni kubwa zaidi.

Mkutano wa asubuhi wa kila siku sio upotezaji mwingine wa wakati. Itakuruhusu kuzuia mikutano mingine mingi na kukuokoa wakati zaidi kuliko unavyotumia.

Sitiari ya Mfumo

Kila mara chagua Sitiari ya Mfumo - dhana rahisi na wazi ili washiriki wa timu waite kila kitu kwa jina moja. Ili kuelewa mfumo na kuondoa msimbo unaorudiwa, ni muhimu sana jinsi unavyotaja vitu. Ikiwa unaweza kudhani kitu kwenye mfumo kinaitwa (ikiwa unajua kile kinachofanya) na kwa kweli inaitwa hivyo, utahifadhi muda mwingi na jitihada. Unda mfumo wa kutaja vitu vyako ili kila mwanachama wa timu aweze kuutumia bila ujuzi maalum wa mfumo.

Vipimo vya Kitengo

Vipimo vya kitengo hucheza jukumu muhimu katika XP. Wanakuruhusu kubadilisha msimbo haraka bila hofu ya kufanya makosa mapya. Mtihani wa kitengo umeandikwa kwa kila darasa, mtihani unapaswa kuangalia vipengele vyote vya darasa - jaribu kila kitu ambacho kinaweza kufanya kazi.

Ujanja hapa ni kwamba mtihani wa darasa lazima uandikwe kabla ya darasa lenyewe. Hii ina maana kwamba mara tu unapotoa matokeo ya kwanza ya kazi, itasaidiwa na mfumo wa kupima. Ili kufanya vipimo imeandikwa mfumo maalum kujaribu na kiolesura chako mwenyewe.

Jaribio la Kitengo cha darasa huhifadhiwa kwenye hazina ya kawaida pamoja na msimbo wa darasa. Hakuna msimbo unaoweza kutolewa bila jaribio la Kitengo. Kabla ya kutoa msimbo, msanidi lazima ahakikishe kwamba majaribio yote yanapita bila makosa. Hakuna mtu anayeweza kutoa nambari isipokuwa kila mtu apitishe 100%. Kwa maneno mengine, kwa kuwa vipimo vyote vilipita kabla ya mabadiliko yako, ikiwa una makosa, basi hii ni matokeo ya mabadiliko yako. Ni juu yako kuirekebisha. Wakati mwingine msimbo wa jaribio si sahihi au haujakamilika. Katika kesi hii, unahitaji kurekebisha.

Jaribio kubwa ni kuokoa pesa kwenye majaribio ya kitengo wakati muda ni mfupi. Lakini kwa kufanya hivi unajidanganya tu. Ni vigumu zaidi kuandika mtihani, wakati zaidi utahifadhi baadaye. Hii imethibitishwa na mazoezi.

Majaribio ya kitengo huruhusu umiliki wa pamoja wa msimbo. Wanafanya iwe rahisi kukagua nambari mbaya. Vipimo vya kitengo pia hukuruhusu kuwa na mfumo thabiti wa kufanya kazi wakati wowote.

Hadithi ya Mtumiaji

Hadithi ya Mtumiaji (kitu kama hadithi ya mtumiaji) ni maelezo ya jinsi mfumo unapaswa kufanya kazi. Kila Hadithi ya Mtumiaji imeandikwa kwenye kadi na inawakilisha baadhi ya sehemu ya utendaji wa mfumo ambayo inaleta mantiki kutoka kwa mtazamo wa Mteja. Fomu - aya moja au mbili za maandishi ambayo inaeleweka kwa mtumiaji (sio kiufundi sana).

Hadithi ya Mtumiaji imeandikwa na Mteja. Hizi ni sawa na, lakini sio tu, matukio ya matumizi ya mfumo kiolesura cha mtumiaji. Kwa kila hadithi, majaribio ya utendaji huandikwa ili kuthibitisha kwamba hadithi hii inatekelezwa kwa usahihi - pia huitwa majaribio ya kukubalika.

Kila Hadithi ya Mtumiaji inapewa kipaumbele kutoka kwa upande wa biashara (mtumiaji, mteja, idara ya uuzaji) na makadirio ya muda wa utekelezaji kutoka kwa wasanidi programu. Kila hadithi imegawanywa katika kazi na kupewa wakati ambapo itaanza kutekelezwa.

Hadithi za Mtumiaji hutumiwa katika XP badala ya mahitaji ya jadi. Tofauti kuu kati ya Hadithi ya Mtumiaji na mahitaji ni kiwango cha maelezo. Hadithi ya Mtumiaji ina maelezo ya chini zaidi yanayohitajika ili kufanya makadirio yanayofaa ya muda gani itachukua ili kuitekeleza.

Hadithi ya Mtumiaji ya kawaida huchukua wiki 1-3 za wakati unaofaa. Hadithi inayohitaji chini ya wiki 1 ina maelezo mengi sana. Hadithi inayohitaji zaidi ya wiki 3 inaweza kugawanywa katika sehemu - hadithi tofauti.

Kasi ya mradi

Kasi ya Mradi (au kasi tu) ni kipimo cha jinsi kazi ya mradi wako inavyokamilika haraka.

Ili kupima kasi ya mradi, lazima tu uhesabu kiasi cha Hadithi za Watumiaji, au ni kazi ngapi (kwa wakati) zilikamilishwa kwa kila marudio. Hesabu tu jumla ya muda wa kukadiria kiasi cha kazi (wakati unaofaa).

Wakati wa kupanga toleo, kasi ya mradi hutumiwa kukadiria ni Hadithi ngapi za Mtumiaji zinaweza kufanywa.

Wakati wa kupanga marudio, kasi ya mradi katika marudio ya awali hutumika kubainisha ni Hadithi ngapi za Mtumiaji za kupanga katika marudio ya sasa.

Utaratibu huu rahisi huruhusu watengenezaji kupona kutoka kwa kurudia ngumu. Ikiwa bado una wakati wa bure baada ya kurejesha, nenda kwa mteja na uulize Hadithi nyingine ya Mtumiaji. Matokeo yake, kasi itaongezeka tena.

Hakuna haja ya kutumia parameta hii kama parameta kabisa. Haifai kwa kulinganisha tija ya miradi miwili, kwani kila timu ina sifa zake. Kigezo hiki ni muhimu tu kwa timu kuiweka kwenye keel sawa.

Unapaswa kutarajia mabadiliko kidogo katika kasi ya mradi unapofanya kazi. Lakini ikiwa kasi inabadilika sana, ni muhimu kupanga upya kutolewa. Punde tu mfumo mpya unapoenda kwa watumiaji, tarajia mabadiliko katika kasi ya mradi kwani una kazi za usaidizi.

Hitilafu inapogunduliwa

Ikiwa hitilafu itapatikana, jaribio linaundwa ili kuizuia kutokea tena. Hitilafu inayotokea kwenye mfumo wa uzalishaji (tayari umewekwa) inahitaji kuandika mtihani wa utendaji. Kuunda jaribio la kufanya kazi mara moja kabla ya kugundua hitilafu huwaruhusu wateja kuelezea tatizo kwa uwazi na kuwasilisha tatizo kwa wasanidi programu.

Jaribio la utendaji lisilofaulu linahitaji kuundwa Mtihani wa Kitengo. Hii husaidia kulenga juhudi za utatuzi na inaonyesha wazi wakati hitilafu imerekebishwa.

Hutahitaji

Epuka kujaza mfumo na vitu utakavyohitaji katika siku zijazo. 10% tu ya kile ulichotarajia kitahitajika katika hali yake ya asili, kumaanisha 90% ya wakati wako itapotea.

Daima kuna kishawishi cha kuongeza utendakazi sasa badala ya baadaye, kwa sababu tunaona jinsi ya kuiongeza sasa na kuhisi kuwa mfumo utakuwa bora zaidi. Lakini lazima tujikumbushe kila wakati kwamba hatutahitaji kamwe. Utendaji wa ziada hupunguza kasi ya maendeleo na kula rasilimali. Sahau kuhusu mahitaji ya siku zijazo na kubadilika zaidi. Zingatia kile kinachopaswa kufanywa sasa.

Maendeleo (maendeleo yanayoendeshwa na kazi za mfumo), nk.

Kulingana na waandishi wa XP, mbinu hii haifuati sana baadhi miradi ya jumla vitendo, wangapi hutumia mchanganyiko wa mbinu zifuatazo. Hata hivyo, kila mbinu ni muhimu, na bila matumizi yake, maendeleo inachukuliwa kuwa si XP, kulingana na Kent Beck, mmoja wa waandishi wa mbinu hii pamoja na Ward Cunningham na Ron Jeffries.

Mchezo wa kupanga moja kwa moja
Kazi yake ni kuamua haraka iwezekanavyo kiasi cha kazi kinachohitajika kufanywa kabla ya toleo linalofuata la programu. Uamuzi unafanywa, kwanza kabisa, kwa kuzingatia vipaumbele vya mteja (yaani, mahitaji yake, kile anachohitaji kutoka kwa mfumo ili kuendesha biashara yake kwa mafanikio zaidi) na, pili, kwa misingi ya tathmini za kiufundi (yaani, makadirio ya utata). ya maendeleo, utangamano na vipengele vingine vya mfumo, nk). Mipango inabadilishwa mara tu inapoanza kutofautiana na ukweli au matakwa ya mteja.
Mabadiliko ya mara kwa mara ya matoleo (matoleo madogo)
Toleo la kwanza kabisa la kufanya kazi linapaswa kuonekana haraka iwezekanavyo na linapaswa kuanza kutumika mara moja. Matoleo yanayofuata yanatayarishwa kwa muda mfupi (kutoka saa kadhaa kwa mabadiliko madogo katika programu ndogo, hadi mwezi mmoja au mbili kwa rework kubwa ya mfumo mkubwa).
Sitiari ya mfumo
Fumbo, kwa njia rahisi na inayoeleweka kwa timu, inapaswa kuelezea utaratibu wa msingi wa mfumo. Wazo hili ni ukumbusho wa usanifu, lakini inapaswa kuelezea kiini kikuu cha maamuzi ya kiufundi yaliyofanywa kwa urahisi zaidi, kwa maneno moja au mbili tu.
Rahisi ufumbuzi wa kubuni(muundo rahisi)
Wakati wowote, mfumo unapaswa kuundwa kwa urahisi iwezekanavyo. Hakuna haja ya kuongeza vipengele mapema - tu baada ya ombi wazi kwa hilo. Utata wote usio wa lazima huondolewa mara tu unapogunduliwa.
Maendeleo yanayotokana na mtihani
Waendelezaji kwanza huandika vipimo, kisha jaribu kutekeleza moduli zao ili vipimo vifanye kazi. Wateja huandika majaribio mapema ambayo yanaonyesha uwezo mkuu wa mfumo ili waweze kuona kuwa mfumo unafanya kazi kweli.
Urekebishaji unaoendelea
Watayarishaji wa programu wanafanya upya mfumo mara kwa mara ili kuondoa ugumu usiohitajika, kuongeza uelewa wa kanuni, kuongeza kubadilika kwake, lakini bila kubadilisha tabia yake, ambayo inathibitishwa na kukimbia baada ya kila rework ya vipimo. Wakati huo huo, upendeleo hutolewa kwa ufumbuzi zaidi wa kifahari na rahisi, ikilinganishwa na wale ambao hutoa tu matokeo yaliyohitajika. Vipengee vilivyoundwa upya bila kufaulu vinapaswa kutambuliwa wakati wa utekelezaji wa jaribio na kurudishwa hadi hali ya mwisho kamilifu (pamoja na vijenzi vinavyovitegemea).
Oanisha programu
Coding inafanywa na watengeneza programu wawili kwenye kompyuta moja. Kuoanisha ni kiholela na hutofautiana kutoka kazi hadi kazi. Yule ambaye mikono yake kibodi inajaribu kutatua tatizo la sasa kwa njia bora zaidi. Mtayarishaji wa pili anachambua kazi ya kwanza na anatoa ushauri, anazingatia matokeo ya maamuzi fulani, vipimo vipya, ufumbuzi usio wa moja kwa moja lakini rahisi zaidi.
Umiliki wa pamoja wa kanuni
Wakati wowote, mwanachama yeyote wa timu anaweza kubadilisha sehemu yoyote ya msimbo. Hakuna mtu anayepaswa kuwa na eneo lake la uwajibikaji; timu nzima kwa ujumla inawajibika kwa kanuni zote.
Kuunganishwa kwa kuendelea
Mfumo huu unakusanywa na kufanyiwa majaribio ya ujumuishaji mara nyingi iwezekanavyo, mara kadhaa kwa siku, kila wakati watayarishaji programu kadhaa wanapomaliza kutekeleza utendakazi unaofuata.
Saa 40 za wiki ya kazi
Kufanya kazi kwa muda wa ziada inachukuliwa kuwa ishara matatizo makubwa katika mradi. Kazi ya muda wa ziada kwa wiki 2 mfululizo hairuhusiwi - hii huwachosha waandaaji programu na kufanya kazi yao kuwa na tija kwa kiasi kikubwa.
Ikiwa ni pamoja na mteja katika timu (mteja wa tovuti)
Timu ya uendelezaji daima inajumuisha mwakilishi wa wateja ambaye anapatikana siku nzima ya kazi na anaweza kujibu maswali yote kuhusu mfumo. Wajibu wake ni kujibu mara moja maswali ya aina yoyote kuhusu kazi za mfumo, interface yake, utendaji unaohitajika, operesheni sahihi mifumo katika hali ngumu, hitaji la kudumisha mawasiliano na programu zingine, nk.
Kutumia kanuni kama njia ya mawasiliano
Kanuni huonekana kama njia muhimu zaidi ya mawasiliano ndani ya timu. Uwazi wa kanuni ni mojawapo ya vipaumbele vikuu. Kufuata viwango vya usimbaji vinavyotoa uwazi huu ni muhimu. Viwango hivyo, pamoja na uwazi wa msimbo, vinapaswa kuhakikisha lugha ndogo (hakuna nakala za msimbo na habari) na vinapaswa kukubaliwa na washiriki wote wa timu.
Fungua nafasi ya kazi
Timu inawekwa katika chumba kimoja chenye nafasi nyingi ili kurahisisha mawasiliano na kuwezesha majadiliano ya kikundi wakati wa kupanga na kufanya maamuzi muhimu ya kiufundi.
Kubadilisha sheria kama inahitajika (sheria tu)
Kila mwanachama wa timu lazima akubali sheria zilizoorodheshwa, lakini ikiwa hitaji litatokea, timu inaweza kuzibadilisha ikiwa washiriki wake wote watakubali mabadiliko haya.

Kama inavyoonekana kutoka kwa mbinu zinazotumiwa, XP imeundwa kwa ajili ya matumizi ndani ya timu ndogo (sio zaidi ya watengeneza programu 10), ambayo inasisitizwa na waandishi wa mbinu hii. Ukubwa wa timu kubwa huharibu urahisi wa mawasiliano muhimu kwa mafanikio na hufanya kuwa vigumu kutekeleza mbinu nyingi zilizoorodheshwa.

Faida za XP, ikiwa inaweza kutumika, ni kubadilika zaidi, uwezo wa haraka na kwa usahihi kufanya mabadiliko ya programu kwa kukabiliana na mabadiliko ya mahitaji na matakwa ya mteja binafsi, ubora wa juu matokeo na hakuna haja ya kuwashawishi wateja kwamba matokeo yanakidhi matarajio yao.

Ubaya wa njia hii ni kutowezekana kwa miradi mikubwa na ngumu ya kutosha kwa mtindo huu, kutokuwa na uwezo wa kupanga wakati na ugumu wa mradi kwa muda mrefu wa kutosha na kutabiri wazi matokeo ya mradi wa muda mrefu kwa suala la uwiano. ubora wa matokeo na gharama za muda na rasilimali. Inaweza pia kuzingatiwa kuwa XP haifai kwa kesi hizo ambazo suluhu zinazowezekana hazipatikani mara moja kwa misingi ya uzoefu uliopatikana hapo awali, lakini zinahitaji utafiti wa awali.

XP kama seti ya mbinu zilizofafanuliwa ilitumika kwa mara ya kwanza wakati wa kazi ya mradi wa C3 (Mfumo wa Fidia Kamili wa Chrysler, uundaji wa mfumo wa uhasibu wa faida za mfanyakazi huko Daimler Chrysler). Kati ya washiriki 20 katika mradi huu, 5 (ikiwa ni pamoja na waandishi 3 waliotajwa hapo juu wa XP) walichapisha vitabu 3 na idadi kubwa ya nakala zilizotolewa kwa XP wakati wa mradi wenyewe na baadaye. Mradi huu umetajwa mara kwa mara katika vyanzo mbalimbali kama mfano wa matumizi ya mbinu hii. Data ifuatayo imekusanywa kutoka kwa vifungu vilivyotajwa, ukiondoa ushahidi wa hadithi, na inaonyesha matatizo na baadhi ya mbinu za XP zinapotumika kwa miradi changamano.

Mradi ulianza Januari 1995. Tangu Machi 1996, kufuatia kujumuishwa kwa Kent Beck, imekuwa ikiendeshwa kwa kutumia XP. Kufikia wakati huu, tayari ilikuwa imevuka bajeti na mipango ya utekelezaji wa majukumu kwa awamu. Timu ya maendeleo ilikatwa, na kwa karibu miezi sita baada ya hapo mradi ulikua kwa mafanikio. Mnamo Agosti 1998, mfano ulionekana ambao unaweza kuhudumia wafanyikazi wapatao 10,000. Mradi huo awali ulitarajiwa kukamilika katikati ya mwaka wa 1999 na programu itakayopatikana ingetumika kusimamia mafao ya wafanyakazi 87,000 wa kampuni hiyo. Ilisimamishwa mnamo Februari 2000 baada ya miaka 4 ya kuendesha XP kwa sababu ya kushindwa kabisa kuadhimisha muda na bajeti. Programu iliyoundwa haijawahi kutumika kufanya kazi na data kwa zaidi ya wafanyikazi 10,000, ingawa imeonyeshwa kuwa inaweza kushughulikia data ya wafanyikazi 30,000 wa kampuni. Mtu ambaye alicheza jukumu la mteja aliyejumuishwa katika timu ya mradi aliacha baada ya miezi michache ya kazi kama hiyo, hakuweza kuhimili mzigo wa kazi, na hakupokea uingizwaji wa kutosha hadi mwisho wa mradi.