logi sisse meist KKK
0
1

Ma ei ole aru saanud, mis eelised annab kokkulepitud kord, et arendatava tarkvara uuendused lähevad live-i näiteks iga nädala esmaspäeval? Tean, et seda mõtet rakendavad väga paljud (suured) ettevõtted.

Olen töötanud vaid väikeettevõtetes ja ilmselt sellest minu küsimus. Ma ei mõista, miks ei panda tarkvara üles lihtsalt siis kui ta valmis saab. :)

küsitud Dec 30 '12 at 16:37

Kaiko%20Kaur's gravatar image

Kaiko Kaur
2306711


Ka meil toimuvad versioonimuudatused korrapäraselt. On paika pandud kindel "kava", mismoodi asjad jõuavad arenduskeskkonnas prelive ning sealt edasi live. See hõlmab samuti rakenduse testimist. Hea on see, et kõik on teadlikud, et VV (versioonivahetus) toimub sellel ajal. Arenduse tellija saab juba ette arvestada, millal tema tellitud arendus jõuab live, millist testperioodi ta vajab jne. Sel juhul puudub suurem segadus jms. Sellise protsessi juures on tagatud kõige parem vigade mitte jõudmine live. Ning isegi, kui peaks miskit olema, on teada, et näed, toimus VV - kas midagi läks tänu sellele "katki"?

link

vastatud Dec 31 '12 at 12:04

Kaspar%20Kalve's gravatar image

Kaspar Kalve
133118

Üks põhjus on see, et paigaldamata muudatused on nagu laoseis poes - selle eest on raha makstud, aga hetkel võtab see riiulipinda ja rikneb iga päevaga. Ladu tuleb hoida nii lühikesena kui võimalik.

Tarkvara kontekstis on paigaldamata muudatuste peale kulutatud aega analüüsiks, programmeerimiseks, testimiseks, aga kuni nad pole live'i pandud, ei teeni nad meile raha. Toimib sama loogika nagu poes - nii kui valmis saab, tuleb muudatus nii kiiresti kui võimalik panna raha teenima.

See muidugi ei õigusta poolikute või testimata asjade ülespanemist.

link

vastatud Dec 31 '12 at 14:27

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77781125

Tagantjärele üle lugedes sain vist küsimusest teistpidi aru - Kaiko tahtis teada, miks ta ei võiks panna asju varem üles, aga minule jäi mulje, et miks sunnitakse poolikuid asju üles panema. Samas vastus on endiselt asjakohane.

(Dec 31 '12 at 14:29) Tambet Matiisen ♦♦

Tegelikult mõlemat pidi on probleem. Väikese veaparanduse puhul ei ole mõtet oodata ja suure muutuse puhul on selline tsüklilisus kohmakas (keegi ei tea, millal see valmis on ja kui on, siis oodata pole mõtet).

Lisaks sellele, et see vähendab riske olen vastustest aru saanud, et see on ka parema kommunikatsiooni pärast.

Sõltub tarkvarast, aga jään arvamusele, et kasutajale peaksid uuendused toimuma märkamatult (nagu veeb) ja ei ole vaja teavitada kui see teda ei puuduta. Väikesed parandused peaksid üles minema käigu pealt.

(Jan 06 '13 at 21:11) Kaiko Kaur

Suurtel firmadel võivad olla suured kliendid paljude arvutitega, seega võib neil olla tarkvarauuenduste paigaldamine lihtsam, kui see käib teatud korra järgi. Aga eks see sobiv praktika kujune välja vastavalt vajadusele ja klientide soovile. Liiga sagedased uuendused võivad ka lõppkasutajat väsitada, kui neid ei paigaldata silma eest peaaegu nähtamatult. Näiteks mõnel meediamängijal võib uuendustest teatamise aken hüpata ette pea iga päev, natuke tüütuks muutub, kui seal ei ole just mingit parandust, mida ma ootan.

link

vastatud Dec 31 '12 at 10:39

Teet65's gravatar image

Teet65
174911

Meil toimub ülekanne testkeskkonnast produktiivi 2 korda kuus. Suure süsteemi korral tuleb meeles pidada, et igasugune muudatus eeldab selle muudatuse fikseerimist, dokumenteerimist, lahendust ja testimist. Iga muudatus peab läbima kõik need tsüklid ja alles pärast kõike seda korjatakse kõik need asjad kokku ja tõstetakse üle. Meeles peab pidama, et kui süsteemis on kümneid arendajaid, siis peavad muudatused minema üle ka tehtud muudatuste järjekorras, vastasel juhul tekivad suured probleemid puuduvate või mittekonsistentsete andmestruktuuride või programmiosiste tõttu. Ehk siis kogu selline arendus on terve suur protsess ja seda ei saa teha siis, kui tuju tuleb.

link

vastatud Dec 31 '12 at 10:51

Kalev%20Haga's gravatar image

Kalev Haga
1

Kui tegemist on näiteks väikese veaparandusega. Muudatuse fikseerib koodihaldus, dokumenteeritakse väikese realise kommentaariga, mis tehti ja testimine ei tundu arendajale vajalik, siis ta võiks ju koheselt selle käiku lasta!?

(Jan 06 '13 at 15:47) Kaiko Kaur

See "testimine ei tundu arendajale vajalik" on küll asi, mida olla ei tohiks. Igasugune muutus võib vajada testimist arendaja soovidest sõltumata, klient (või äripool) tahab olla kindel, et muudatus tõesti on tehtud ja toimib. Samuti ei ole äripool tihti adekvaatne hindama, kas muudatus on väike, keskmine või suur.

(Jan 06 '13 at 17:18) Kalev Haga

Võibolla oligi minu küsimuse sisu hoopis "kui palju peaks arendaja vastutama?". Mulle tundub, et "testimine ei tundu vajalik" peaks olema arendajale lubatud suhtumine, et asjad liiguksid kiiremini. Loomulikult peab tunnetama riski. Et kui olulise koha peal ta seda teeb ja mis juhtub ikkagi kui asi katki läheb. Arendaja vastutuse tõstes sunnitakse kaudselt tõstma ka töö kvaliteeti.

Lisaks tarkvara stabiilsusele on oluline ka arenduse kiirus. Kus on see õige tasakaal?

(Jan 06 '13 at 20:05) Kaiko Kaur

Arendajale võib olla lubatud igasugune suhtumine, iseasi, kas sellega tellija alati nõus on. Mida, millal ja kui palju testida, see pole tegelikult arendaja mure, tema peab oma töö ära tegema. Iga oma muudatuse peab niiehknaa üle testima. Kui oled raporteerinud parandusest, siis pole ju lõppkokkuvõttes enam sinu mure, millal see asi produktiivi saab, sinu töö on tehtud niikaua, kui tellija ei arva teisiti.

(Jan 06 '13 at 20:10) Kalev Haga

Ma olen peaaegu alati programmeerinud ettevõttes, kus ei pakuta programmeerimist kui teenust. Firma sees võib olla olemas küll "tellija", aga see tellija ja mina võitleme sama asja eest: et meil koos hästi läheks.

Seega suhtumine "mul suva, millal see live-i läheb" pole olnud kunagi minu mõttes.

Sellises ettevõttes tööd tehes tekibki küsimus, et kas seda live-i mineku tsüklit on vaja. Minnakse siis kui kõik seotud isikud ütlevad, et muudatus on ok ja sellest antakse lisaks teada seotud inimestele. Väikest bugiparandust ei ole vaja üldse teada anda.

(Jan 06 '13 at 20:36) Kaiko Kaur

Siin on nüüd mingi arusaamatus. Arendajal peab olema võimalus öelda, millal on vaja testida ja millal vaja, samas võiks ju osad asjad otse produktiivsüsteemis kirjutada? Sain ma mõttest õigesti aru?

(Jan 06 '13 at 20:44) Kalev Haga

Jah. Õigesti.

Väikese paranduse ülespanekuks ei ole vaja kogu tsüklit läbi teha. Suurema muudatuse puhul tundub ettemääratud tsükkel natuke kohmakas, sest täpselt ei tea keegi, millal asi valmis.

(Jan 06 '13 at 20:57) Kaiko Kaur
näitan 5/7 näita kõiki
Sinu vastus
lülita eelvaade

Jälgi seda küsimust

By Email:

Pärast sisselogimist saad tellida muudatuse teavitusi siit

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *kaldkiri* või __kaldkiri__
  • **paks kiri** või __paks kiri__
  • link:[tekst](http://url.com/ "pealkiri")
  • pilt?![alt tekst](/path/img.jpg "pealkiri")
  • nummerdatud nimekiri: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • põhilised HTML märgendid on samuti toetatud

Pinu tööpakkumised

kõik pakkumised »

Küsimuse sildid:

×3

küsitud: Dec 30 '12 at 16:37

nähtud: 3,470 korda

viimati uuendatud: Jan 06 '13 at 21:11

Litsents: Creative Commons Attribution License | Kontakt: info@pinu.ee