Jan 22 2013
Kuidas tellida tarkvaraprojekti
Eelmise aasta lõpupoole korraldas Äripäev seminari Kuidas korraldada edukaid tarkvarahankeid, kuulajaskonnaks mitmesugused avaliku ja erasektori esindajad, kellel aeg-ajalt vaja tarkvara tellida. Tegin ise ettekande agiilse arenduse teemal, refereerin nüüd ka siin. Osaliselt on kasutatud kaastöötajate Tiit Anmanni ja Aet Rahe koostatud materjale.
Aga kõigepealt väike viktoriin. Andke igale järgnevatest küsimustest vastusena 2 arvu: alampiir ja ülempiir. Püüdke teha nii, et olete 90% kindel, et õige vastus on nende 2 arvu vahel.
- Mis on Päikese pinna temperatuur?
- Mis on Šanghai laiuskraad?
- Mis on Aasia pindala?
- Mis aastal sündis Aleksander Suur?
- Kui palju on ringluses eurosid (sularaha)?
- Mis on Peipsi järve ruumala?
- Kui palju teenis film Titanic kinodes?
- Mis on Vaikse Ookeani rannajoone pikkus?
- Kui palju raamatuid on USA ajaloo jooksul välja antud?
- Kui palju kaalub raskeim sinivaal?
Väliseid abivahendeid ei tohi mõistagi kasutada. Kui vastused kirjas, võib neid kontrollida siit.
Kui vastata nii, et iga küsimuse puhul on 90% tõenäosus, et õige vastus jääb antud alam- ning ülempiiri vahele, peaks saama keskeltläbi 9 õiget vastust. Samas olen seda viktoriini aga päris mitu korda tegelikus elus korraldanud. Olukorras, kus inimesed häbenevad teiste kuuldes väga ebamääraselt vastata, on tavapärane õigete vastuste arv pigem 2.
Milles on point? Mõistagi mitte inimeste vaaladealaste teadmiste kontrollis. Pigem on asi selles, et enamvähem sellise metoodikaga antakse mahuhinnangud ka enamikule maailma tarkvaraprojektidest. Kuidas nii? Väga lihtne – iga projekt on tegijate jaoks uus. Kui järgmine projekt oleks täpselt samasugune nagu eelmine, poleks seal vaja midagi teha, vaid võiksime lihtsalt võtta olemasoleva koodi ja selle kopeerida. Väga tihti sisaldab uus projekt ka mingeid uusi tehnoloogiaid ja ärivaldkonda, mille kohta teostajatel pole vähimatki aimu.
Siiski leiab iga päev kusagil aset stseen, kus projektijuht näitab vanemarendajale mingit umbmäärast kirjeldust ja küsib, kui kaua sellega läheb. Vanemarendaja ei taha muidugi välja näidata, et tal on sellest sama vähe aimu kui Peipsi ruumalast, ning käibki mingi arvu välja. Sealjuures enamasti ühe arvu, mitte alam- ja ülempiiri.
Hinnang läheb pakkumisse, sealt lepingusse ja aasta-paari pärast kakeldakse, miks asjad õigeks ajaks valmis pole saanud. Samuti võivad tellija ja täitja esialgsed hinnangud olla radikaalselt erinevad.
Mis on tarkvaraprojekti tüüpilised mured?
- Asjad ei saa planeeritud eelarves ja ajakavas valmis.
- See, mida telliti, ei ole see, mida vaja oli.
- Projekti käigus muutuvad ja täienevad nõuded pidevalt.
Halvemal juhul võib juhtuda, et:
- “Teine pool” on laisk, loll jne.
- Projekt ei saagi valmis!
- Ja isegi raha juurde makstes ei saa valmis!!
Mispärast? See pole ju ometi esimene projekt, mida “te” teete? Te olete ju oma ala asjatundjad?! Professionaalid!?
Vaatleme järgnevat illustratiivset näidet (NB! Tegemist on üldistusega. Igasugune kokkulangevus reaalse elu sündmuste või tegelastega on juhuslik).
Oletame, et oled ehitusfirma omanik. Kui palju maksab see maja?
Pakkumise esitamise tingimused:
- Esitada fikseeritud hinnaga pakkumine 05.02.2013.
- Valmimise tähtaeg 15.06.2013.
- Täpsustavaid küsimusi saab esitada kirjalikult, vastame 3 tööpäeva jooksul.
- Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.
- Tööde käigus hinda suurendada ei ole võimalik, küll aga on Tellijal õigus vajadusel hinda vähendada.
- kaasas 10 lk-line maja „detailne“ kirjeldus.
- Kirjeldus sisaldab enamasti maja välimuse kirjeldust väljastpoolt vaadates. Erilist tähelepanu on pööratud detailse maja eestvaate kirjeldamisele (kuna see on tellija arvates eriti oluline osa!).
- Kirjelduses ka üldandmed. Näiteks: elamispind 200 m², maja taga terrass, 3 korrust jne.
- Kirjelduse on koostanud ehitusalase hariduseta ja kogemuseta isik.
Ainsaks valikukriteeriumiks on hind.
Hankega käib kaasas lepingu projekt.
- Lepinguks on Tellija tüüpleping, mis ei kuulu arutluse alla!
- Tellijal on õigused, Täitjal kohustused.
- Tähtajad on kivisse raiutud ning nende ületamisega kaasnevad märkimisväärsed sanktsioonid Täitja suunas.
Kui keegi nüüd arvab, et ma liialdan, siis valdav enamik tarkvarahankedokumente, mida ma olen elus lugenud, vastavad sellele kirjeldusele.
Aga egas midagi, hakkame tööga pihta!
- 10 lk-ses dokumendis kirja pandu oli enam-vähem korrektne.
- Küll aga on palju detaile, millele keegi hanget ega pakkumust kokku pannes ei tulnud.
- Pole hullu! Hind on ju lukus ja õnneks mahub lause „Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.“ taha palju, isegi väga palju!
Ainsateks muredeks on mõistagi vaid asjaolud, et kõik kaasatud osapooled on õnnetud ning ka lõpptulemini jõudmine ei tee kedagi õnnelikumaks.
Kirjeldatu oli praegu standardsituatsioon. Kui selline projekt juba alanud on, juhtub enamasti üks kahest variandist:
Esimene võimalus on see, et täitja projektijuht hoiab raudhammastega skoobist kinni. Aset leiavad järgmised tüüpilised dialoogid:
“Aga me tahaks seda ka.”
“Ei saa.”
“Aga kuidas sellega oleks?”
“Ei saa.”
“Aga…”
“Ei saa.”
Ja loomulikult kurdab tellija, et täitja on mõistmatu.
Siiski tuleb tähele panna, et see on pigem hea variant!
Alternatiiv on tavaliselt selline:
Kõigepealt tekivad haldamatud muudatused. Pärast mitmeid tähtaegadest üleminekuid on kaks võimalust: projekt ei valmigi mitte kunagi või siis tuleb seda saneerida, suurest osast ideedest (ja poolvalmis tööst) loobuda ning see, mis toodangusse antakse, võib olla isegi väiksem kui esialgne skoop ette oleks näinud.
Kõik tarkvaraprojektidega kokku puutuvad inimesed on ilmselt seda kolmnurka näinud. Samas keegi ei kasuta seda. Alati, kui kellegagi rääkida, et mida neist valida, saab sama vastuse nagu Karupoeg Puhhilt, kui küsiti, kas too soovib mett või kondenspiima: “Mõlemat!”
Tulemus on mõistagi selge: kui kolmnurga igat tippu väljapoole tirida, käriseb see seest ning ohverdatakse see, mida on kõige raskem mõõta – kvaliteet. On ka täiesti loomulik, et kui lepingusse ikka tähtaegade ületamise eest on trahv sisse kirjutatud, lükatakse kliendile ette mida iganes, et sellest pääseda – eks pärast jõuab klaarida.
Kuna senikirjeldatud probleemid on äärmiselt tavalised, on neile mõistagi ka mitmesuguseid vastumeetmeid leida püütud.
Üks levinumaid “lahendusi” on võimalikult põhjaliku nõuete loetelu koostamine enne projekti algust. Tavaliselt käib see nii, et tellija poolelt on keegi saatnud laiali ringkirja ja palunud kõigil huvilistel oma mõtted kirja panna. Tulemus copy-paste’itakse hankedokumenti ning öeldakse, et vaat, täpselt neid asju ongi vaja.
Selle lähenemise probleemid on muidugi ilmsed:
- Kirjapandu on prioritiseerimata – kuna igaühel on hirm, et tema soovid võivad välja jääda, fantaseeritakse kokku pigem rohkem kui vähem. Tulemuseks on süsteem, mille võimalustest rohkem kui 50% ei hakka keegi kunagi kasutama – enam kui pool tellija rahast läheb lihtsalt raisku! Halvemal juhul võib hankedokumendist leida ka omavahel risti vastu käivaid soove…
- Me välistame kõik head ideed, mis meil projekti käigus võivad tulla.
- Lõplikul süsteemil on kõik “design by committee” omadused.
Teine võimalus on, et lepingus fikseeritakse keerukas muudatuste haldamise protseduur. Iga muudatus tuleb kõigiga kooskõlastada, projektiplaani täiendada jne. See on natuke parem variant, aga toob kaasa äärmiselt koormava bürokraatia. Kui iga ettepanek nõuab projektiplaani mõjuhinnangut ja spetsifikatsioonide ümberkirjutamist enne muudatuse heakskiitu, võtab plaanide ümberjoonistamine ja kooskõlastamine lõpuks inimeste kogu aja ära ja keegi ei taha seda teha. Lõpuks jõuame olukorrani, kus muudatuste haldamise protseduurist on saanud muudatuste vältimise protseduur.
Täitja poolt pakutakse muidugi omi võimalusi. Raudhammastega projektijuhist oli juba juttu, aga kõige tüüpilisem on kõigi ajahinnangute korrutamine mingi konstandiga (näiteks π). Siin on muidugi tulemuseks, et tegelik ajakulu tuleb tõenäoliselt hoopis midagi muud, kui esialgu planeeritud, ning üks või teine pool tunneb paratamatult, et on pügada saanud.
Arendajate lemmikalternatiiv on mõistagi Time&Material – tellija maksab kogu aja eest, mis arendajal kulus. See on tellijaile tihti hirmutav ning õigusega – kulude kontrolli alt väljumine on arvestatav oht.
Kokkuvõttes jõuame arusaamisele, et:
- Mittetriviaalsed tarkvaraprojektid on põhimõtteliselt ennustamatud.
- Muudatused on vältimatud.
- Tarkvaraprojekti ei ole võimalik ega praktiline detailselt ette planeerida.
- Kombinatsioon “fikseeritud hind, skoop ja tähtaeg” lõpeb enamasti ebaõnnestumisega.
Järeldus: muudatustesse tuleb suhtuda nagu paratamatusse ning protsess tuleb üles ehitada nendega arvestamiseks, mitte nendega võitlemiseks.
Aga mida konkreetselt teha?
Peamine rohi, mida kirjeldatud probleemide vastu välja pakutakse, on agiilne arendus. Peaaegu kõigile tarkvaraorganisatsioonidele meeldib kirjeldada ennast kui agiilseid. Mis värk sellega aga tegelikult on?
Agiilse arenduse alustalad on:
- Suhtlemine on tähtsam kui protsess.
- Töötav tarkvara on tähtsam kui dokumentatsiooni täielikkus.
- Kliendi ja täitja koostöö on tähtsam kui lepinguläbirääkimised.
- Muudatustele reageerimine on tähtsam kui plaani järgimine.
Vaatlen siin lähemalt Scrumi, aga nimetatud printsiibid kehtivad ka kõigi teiste metoodikate (nt Kanban) puhul.
Scrumi peamine omadus on Product Backlog – tööde hulk, mille võiks ära teha. Kõik uued ideed lisatakse lihtsalt backlog’i. Iga alametapi ehk sprindi alguses valitakse tööde nimekirjast (tellijaga koostöös!) kõige olulisemad asjad, mida ära teha, ja tarnitakse selle tulemus mõned nädalad hiljem.
Siit on ka selgelt näha, et projekti lõplik skoop ja tähtaeg ei saa olla korraga fikseeritud! See tähendab ka loobumist konkreetseks tähtajaks valmivast detailsest projektiplaanist (ning selle pidevast ümberjoonistamisest).
Teine peamine omadus on sagedased (mõõdetavad nädalates, mitte kuudes) tarned ning see, et iga tarne tulemus peab olema kliendile kohe kasutatav.
Ja kolmas peamine omadus on kiire klienditagasiside. Siit tuleneb ka nimetus “agiilne” ehk väle. Asi pole mitte selles, et programmeerijad liigutaksid kiiremini näppusid, vaid selles, et klient vaatab tööde tulemusi kiiremini ja sagedamini üle!
Scrumi õnnestumise või ebaõnnestumise määrab üldjuhul see, kas tellija läheb metoodikaga kaasa või mitte. Tean paljusid projekte, kus tiimiliikmed ütlevad, et oh, meil on Scrum, sest nad teevad igapäevaseid koosolekuid, aga tegelikult on projektil ikka fikseeritud skoop ja tähtaeg. Kui projekti üks pool on agiilne ja teine mitte, on tulemus nagu absurdianekdoot:
See, et skoop pole fikseeritud, peab olema ka arenduslepingus kajastatud, vastasel korral ei tule asjast midagi välja.
Lisaks tagasisidele on vajalik ka tellija aktiivne osalus backlogi prioritiseerimises, mis nõuab detailset süvenemist ning inimesi, kellel on tegelikult ka võimalik panustada aega ja pingutust ning samas võtta vastu otsuseid prioriteetide osas. Kui iga otsust mingi komitee või juhtrühm kinnitama peab, ei tule jälle midagi välja.
Kuidas Scrumi hinnastada?
Heaks mudeliks on fikseeritud skoobi ja T&M vahepealne variant. Iga sprindi alguses lepitakse kokku mingi tulem ning vastava sprindi lõpus tasutakse selle eest. Enam pole vaja maagilisi konstante, millega hinnanguid korrutada ja mis emmale-kummale poolele kaotuse kaasa toovad!
Süsteem on õiglane, sest tellija maksab parasjagu selle eest, mis on kätte saadud (iga sprindi tulemus peab olema kasutatav!), ning täitja saab parasjagu nii palju raha, kui palju on tööd tehtud.
Siiski võib jääda kahtlus, et milleks see kõik? Tundub kangesti hirmutav, et kuidas me siis ei kirjelda kõiki nõudeid, kuupäevi ja eurosid algusest peale ära…
Agiilse arenduse konkreetsed kasutegurid, mida igaüks oma tuttavatele tarkvaratellijatele võib presenteerida, on:
- Tellija saab selle, mida ta tegelikult tahab – pool tööst ei lähe enam raisku!
- Arendus on efektiivsem – pidevatele plaanimuutustele läheb vähem auru -> suurem kasu nii tellijale kui täitjale
- Ebaõnnestumisel pole vaja kogu projektist loobuda – suur eelis klassikalise waterfalli ees!
- Dramaatiliselt kõrgem kvaliteet – enam pole vaja nui neljaks konkreetseks tähtajaks midagi tarnida.
- Ning last but not least, vähem inimestevahelisi konflikte – projektijuhid ei pea enam pärast projekti lõppu otsejoones Anonüümsetesse Alkohoolikutesse suunduma.
Hee, sa pole olnud riigi poolt tellija
Riigihange on väärastus, millega põhimõtteliselt ei ole võimalik tasakaalustada enne hanget tehtud töö kogust (mõtle ette, mida keegi suudab pakkuda, praktikas ma ei suutnud), hinda, saad mida tahad ning ei kaevata kohtusse. Ühes nendest tuleb järele anda.
Kõige praktilisem on tellida üle paisutatud hinnaga toode. Mõnes mõttes on see odavam kui alternatiivne, saad odavamalt aga midagi, mis ei sobi. Siis on tootja huvitatud tegema ka osa tellija tööd ära.
Hea näide on justmin mingi portaal. Justnagu töötab, aga silmnähtavalt pole tellija ja tegija omavahel üldse rääkinud, pole mingit testimist.
scrum ei ole riigihangetes kasutatav.
Tellija on liiga ükskõikne.
Riigihangete tellija probleem on, et tihti ei ole tegelikku karjuvat vajadust. Ei ole seda, et kui jätad tegemata, siis lendab tormiga katus minema. Raha ei ole, vabadust ei ole, tulemusi tegelikult vaja ei ole. Ametniku palk jookseb ikka.
Kliendile pakutakse tihti mitte vajalikke teenuseid. Kui ei ole vaja, siis tehakse “küsitlus”, kas soovite tasuta ühistransporti vmt. Mõnel juhul üritatakse luua midagi uut, kuid rõhk pole tasuvusel, vaid pigem kas saab endale alluvaid (palk tuleb alluvate pealt) või lihtsalt vähem tööd teha.
Kasutaja ei oma tegelikult tähtsust. Sisulist vajaduse huvi ei ole.
Tellijal peab olema lisaks projektijuhtidele ka testija.
Kui soovid lobiseda, siis hea meelega saaks Tallinnas kokku, lõunapausi paiku. Enne kui need kaootilised mõtted on kasutavad, peab veel mõtlema. Ma hetkel ei saa.
Kas peaprobleem pole selles, et riigihankes ei ole “olulisi” ja “ebaolulisi” featuure. S.t ära tuleb teha kas kõik või mitte midagi. S.t tavaliselt lõpuks vaieldakse mingite pisiasjade üle a la kas brauser Xver21 näitab tulemust ikka TÄPSELT samamoodi kui brauser Xver22. Tellija ehk isegi mõistab, et see pole eriti tähtis asi, aga ei julge järele anda, sest riigihangete seadus ei võimalda.
Kas äkki ideaalne riigihange oleks selline, et vot siin on funktsionaalsuste loetelu koos olulisus-punktidega ja riigihanke täitmise käigus on vaja realiseerida 80% olulisuspunktidest (s.t teha ära kõige olulisem funktsionaalsus). Sel juhul oleks ehk scrum rakendatav…
Kui tuleb teha 80%, siis see ongi sul uus 100% ja oleme jälle alguses. Riigihangete seaduse mõte on läbipaistvus sisse tuua ning ilma selle seaduseta ka igaüks tegi mis pähe tuli. Samas jah, tema paindumatus on suur probleem vahel kui soovid on head kuid teostust tahaks painduvamalt teha.
Jutt kümnesse, aga jahh… riigihangetel küll ei näe, kuidas seda varianti kasutada saaks. Sest selle jaoks tuleks:
a) iga sprindi jaoks korraldada omaette hange oma lõppsummaga – mis võib tähendada igale väiksele jupile uut tegijat… ja see oleks totaalselt jabur
b) teha hange “teostajale”, täpsustamata, mida ja mis ajaks (ja mis raha eest) ta teostab – mis parameetrite järgi siin “teostajat” valida?… ja lähebki käima lobbymeeste võiduajamine ja vaidlustamine jne jne
Ja kõige selle pärast, mis Sa siin kirjutasid, ongi mul hea meel, et ma enam IT projektidega tegelema ei pea.. aitäh, et meelde tuletasid, muidu oleks ehk tagasi igatsema hakanud
Katri, ei tule mingeid eraldi hankeid korraldada, selle jaoks on raamlepingud.
Ja teostaja valimine on ka täiesti objektiivsete kriteeriumite järgi võimalik. Üks variant on näiteks katseülesanne, sarnane sellistele, mida tegelike sprintide käigus tuleb teha, aga väiksem. Ja lepingu täitmise eelduseks on, et samad inimesed, kes täidavad katseülesannet, peavad osalema ka tegeliku projekti täitmisel.
Selliseid asju tehakse küll ning nad töötavad ka, aga kahjuks valdav enamik ei kasuta seda.
Mul on kahtlus et siin arutluses on jäetud tähelepanuta üks peamisi eeldusi eduka tarkvara projekti juures – keegi kliendipoole ülemustest peab olema projekti “sponsoriks”. St peab leiduma keegi kes on uuest tarkvarast huvitatud, kellel on võimu rahasi käsutada, kellel on võimu tellija organisatsioonis inimesi koostööle sundida ja kes ise või kelle volitatud isik omab julgust ning võimu algseid nõudeid ülevaadata/muuta. Kui sellist sponsorit ei ole, siis projekt läheb aiataha tõenäoliselt olenemata kasutatavast metoodikast, Kui sponsor on (ja ta ka natuke mõelda suudab), siis leiutatakse vajadusel ise töötav protsess projekti korralikuks ärategemiseks.
Targo kas sa annaksid mõne riigihanke viitenumbri, kus võitja on valitud katseülesande põhjal? Siis saab hangete registrist edasi lugeda, et kuidas see täpselt tehtud on.
Kas kuskil on ka Agiilse meetodil tehtud tarkvaraprojekti hankedokumendi näidist saada (soovitatavalt riigihanke näidist) ?
Lauri, neid on mitmeid, vaata nt 111663. Üsna vana hange juba, aga ülesanne oli minu meelest ilusasti sõnastatud (hankedokumentides lisa 5). Protseduur oli muidu selline: tellijal on salajane tabel, kus on kirjas, mille eest ülesannete lahenduste juures täpselt punkte antakse. Tabel avalikustatakse pakkumuste avamise hetkel.
Uuem, natuke erineva protseduuriga näide: 126574, lisa 3.
Minu meelest on see oluliselt parem hindamismeetod, kui hinnata
- projekti hinda (mis viib selleni, et täitja hakkab kohe suruma minimaalset, tegelikult kasutut skoobitõlgendust ja tekib suur kaklus),
- tähtaega (mis viib kvaliteedi ohverdamisele),
- tunnihinda (mille puhul valetatakse lihtsalt tunde juurde),
- või meeskonna CV-sid (mille puhul otsitakse kusagilt mingid variisikud).
Urmas, kõige lähedasem, mida ma tean, on http://www.fin.ee/index.php?id=82988&op=doc_details&dok_id=278514&asutus_id=1
Olen selles arutelus osalenud ühes või teises vormis erinevate inimestega umbes 15 aastat ja tundub, et planeerimise eitajad hakkavad peale jääma
riigihangetega õnneks kokkupuudet pole olnud, seega, selles osas kaasa ei oska rääkida. see, et hanke õnnestumiseks peavad nii tellija kui ka täitja kompetentsed olema, on samuti selge. samas häirib mind, et avaldusi tarkvaraprojektide mittehinnatavuse kohta ja planeerimise mõttetuse kota tehakse absoluutses võtmes: “teistmoodi ei olegi võimalik.” allpool ka lühike arutlus
Scrum on küll hea asi, aga millegipärast kadus agiilse meetodi kirjelduse juures antud arutluses ära ehituse paralleel, mis enne oli kasutusel. Kas keegi kujutaks ette, et ehitab maja sellisel viisil: paneme kirja, mida soovime ja siis hakkame sprintima. kasutaksime ehitusplatsil põhimõtteid:
Suhtlemine on tähtsam kui protsess.
Valmis seinad on tähtsam kui dokumentatsiooni täielikkus.
Kliendi ja täitja koostöö on tähtsam kui lepinguläbirääkimised.
Muudatustele reageerimine on tähtsam kui plaani järgimine.
Kuna katusekamber on kõge tähtsam, siis teeme selle esimesel kuul. Kas keegi julgeks sellises majas elada? Mida teeme siis, kui problemid tekivad? Kuuri võib ju nii ehitada või puu otsa onni, aga päris maja ehitusel ei tuleks selliste põhimõtete kasutamine kõne alla.
Olen nõus, et raske on hinnata ja hinnastada, aga tarkvara ongi keeruline ja tulebki vaeva näha, enne kui midagi tegema saab hakata. Ei ole seal nii väga müstilist midagi, tuleb oma kõrge trooni otsast alla ronida ja vaeva näha analüüsiga, rääkida inseneridega ja kõik ka kirja panna. Loomulikult ei suuda küündimatu projektijuht selliseid tegevusi läbi viia, küll aga suudab ta sprindi käigus küsida arendajatelt nende kolme taski tegemise progressi, mis hetkel töös. Samuti suudava kõik asjaosalised nende kolme taski ulatust ja keerukust hoomata.
Jah, enamik tellijaid ei ole nõus põhjaliku analüüsi eest maksma, aga siis tuleks ka öelda, et tegelikult tuleks teistmoodi teha, me teeme teadlikult valesti ja arvestame ka sellega, et mingi hetk tuleb asju palju ringi teha.
Researchi (või mingit tordisööjate infosüsteemi) tehes võib tõesti niisama kogu skoopi arvesse võtmata ja planeerimata koodi kirjutada, katsetada ja proovida, aga päris tarkvara (mis läheb näiteks mõne seadme sisse) tehes minu arvates päris nii ei saa. vabandust, saab küll, aga väga kalliks läheb.
olles kirjutanud tarkvara Nokiale ja Microsoftile, osalenud lennu- ja kosmosetööstuses kasutatava koodigeneraatori valideerimisel ning olles ka mõnda inimest selles töös juhtinud on mul mingi ettekujutus olemas, seega ei targuta niisama.
Jurgo Preden:
“Kuna katusekamber on kõge tähtsam, siis teeme selle esimesel kuul. Kas keegi julgeks sellises majas elada? Mida teeme siis, kui problemid tekivad?”
See läks nüüd demagoogiaks. Kui nüüd meeskond (ehk siis nii tellija kui täitja koos) otsustavad esimesel kuul teha katusekambri siis peab neil selleks olema kas väga hea põhjus. Nt tehase moodulmaja, mille puhul on see n.ö. esimeseks tööks, mille järgi otsustatakse projekti jätkamine, või on see protsessi optimeerimiseks või on meeskond mõistuse kaotanud.
Mõistuse kaotamise juhtumeid on, kuid need on reeglina tellija ja täitja ülemuste ajuvabadest nõudmistest tingitud.
Arendus toimib ja toob tulemuse siis, kui väärtused on paigas. Kui need on olemas siis on kõik võimalik. Kui väärtused on paigas saab parandada kommunikatsiooni ja koostöö vead, vead protsessis, tellimuses, analüüsis ja ka juba valmis tootes.
Probleemide otsimesel leitakse tavaliselt probleeme, mitte lahendusi.
ma ei ole kindel, kas peaks minu arutelu demagoogiaks pidama, pigem püüdsin teatavat klassikalist väitlusvõtet kasutada – reductio ad absurdum.
Agiilsete meetodite kasutamine eeldab taustal mingi(te) geniaalse arhitekti(de) olemasolu, kellel suur pilt peas on, aga kahjuks ei ole mina kohanud, et sellest räägitaks, selle asemel räägitakse pigem sellest, mis välja paistab: kuidas inimesed tegutsevad ja suhtlevad.
Võtsin uuesti sõna, sest unustasin eelmisel korral öelda ühe tsitaadi – Dwight D. Eisenhower (juhtis liitlasvägesid II maailmasõja ajal Euroopas) on öelnud: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”