‘projektijuhtimine’ sildiga artiklid

On teada üks kutsehaigus, kus igat ettejuhtuvat probleemi püüab spetsialist lahendada vastavalt oma professioonile. Juristid arvavad, et kõik probleemid saab lahendada vettpidavate lepingutega. Programmeerijad arvavad, et iga probleemi lahendamiseks on vaja kirjutada programm. Hiljem kui programm on valmis, tuleb seda hooldada ja käigus hoida, aga administreerimine ei ole arendajatele motiveeriv tegevus. Tutvustan Saikus kasutatavaid teenuseid, mis aitavad meil igapäevaselt oma töödega hakkama saada ilma, et peaksime pool (jah, ma pingutan üle) tööajast toetavate tegevuste tarkvarade haldamisega tegelema. Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , , ,

LOE EDASI »
31

August

Kasulikud iteratsioonid

Marek Tihkan Kommenteeri

Box Enne sai kirjutatud, et iteratsioonid on kasutud ning pidev voog on oluline. Siiski kõik see vastab tõele, kuid vaatleks veidi teise nurga alt iteratsioone.

Iga iteratsiooni alguses lepitakse kokku, mis funktsionaalsus süsteemi lisatud saab ehk hulk tööd. Lean tarkvaraarenduses märgitakse seevastu piirangud töö staatustele, et pooleliolevat tööd (WIP) liiga palju ei tekkiks. Mõlemal puhul üritatakse pooleli oleva töö hulka minimeerida, kuid iteratsioonil on juures ka ajaline piirang.

Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , , ,

LOE EDASI »
20

August

Suhtlusest projektides

Marek Tihkan Kommenteeri

Suhtlus on tähtsal kohal projektis. Suur osa probleeme, mis tekkivad, on tingitud vähesest suhtlusest. Sellest pikemalt või lugeda eelnevast postitusest “Miks projektid ebaõnnestuvad”. Selle postituse raames vaatlen, millised suhtluse liigid on ja mis nende eripärad on.

Esimese hooga võib suhtlust liigitada kaheks: sünkroonne ja asünkroonne. Scott W. Ambleri artiklis oli toodud ära suhtluse efektiivsuse kurv, mis algas e-postiga ja lõppes näost näkku suhtlusega tahvli juures. Kui x-teljel vahetada suhtluse rikkalikus ära sünkroonsusega, siis see näeks sama välja.

Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , ,

LOE EDASI »
4

Juuni

xDUF

Marek Tihkan Kommenteeri

Esimese GeekDinneri teemaks oli xDUF ehk Big Design Up Front (BDUF), Enough/Little Design Up Front ja No Design Up Front. Vestlus oli igati huvitav ning neile, kes ei jõudnud tulla, väikene tutvustus seisukohtadest.

Esimene äärmus, mille vaatluse alla võtame on BDUF. See parktika on tulnud otse ehitusest – kõigepealt tuleb plaanid valmis teha ja siis hakata reaalselt ehitama. Tundub esmapilgul loogiline samm, kuid tarkvara on siiski pehme ja lihtsamini muudetav kui maja, mida ehitatakse.  Teine problemaatiline koht selle vaate puhul on, et peaksime suutma võtta kõike arvesse võtta ja seda siiani inimesed teha ei suuda.

Mittetäielikkuse printsiip:
Ei ole võimalik kõike arvesse võtta, kõike määratleda, kõike põhjendada.
[Lorents, “Süsteemse käsitluse alused”, lk 26]

Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , ,

LOE EDASI »
18

Mai

Kasutud iteratsioonid

Marek Tihkan Kommenteeri

Scott Bellware väitis, et iteratsioonid on kasutud Oredev 2008 ettekandes “5 Things I Learned from Lean that Could Have Saved My Last Agile project”. Igati väärt vaatamist Lean Software Developmentiga praktiseerijatele ja tutvujatele. Sellega seoses meenus mulle ka kunagine Jeff Sutherlandi ettekanne “The Agile Enterprise: Real World Experience in Creating Agile Companies”, kus mainis ta erinevaid Scrumi tüüpe.

Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , , ,

LOE EDASI »

Poodi minnes soovime ikka saada kõike võimalikult odavalt. ODAV != HEA. Tellijad soovivad saada tarkvara odavalt ja kiirelt, mis viib enamjaolt üle tähtaegade minekuni ja ebakvaliteetse tooteni. Parema ajagraafiku ja tellija suhte hoidmiseks tasub teada, milline ajahinnangute iseloom on.

Ajahinnangud võivad olla kolme tüüpi:

  • (Enam-vähem) täpsed
  • Ülehinnatud
  • Alahinnatud

Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , ,

LOE EDASI »

Ammu aega tagasi sai käidud projektijuhtide koolitusel ning sealgi küsiti sama küsimust. Vastuseid oli palju: ebatäpsed nõuded, tehniline praak, halvad ajahinnangud, scope creep, vähene suhtlus jne. Siiski taandaksin ise ebaõnnestumise kahele peamisele probleemile: suhtlemine ja tehniline praak.

Uurides põhjalikumalt, miks on ebatäpsed nõuded, siis taandub see vähesele või ebaefektiivsele suhtlusele. Teine variant võib olla ka see, et ei saadud pidevalt tagasisidet, mis on üks suhtluse vorme. Ebatäpsed ajahinnangud viitavad samale probleemile. Kui arendada tsükliliselt, siis peaks olema võimalik ajahinnanguid korrigeerida. Tellijagi peaks aru saama, et ennast petta pole mõtet, kui teostaja soovib ajahinnanguid muuta (siinkohal võib tellija otsustada pigem, kas sellise kulu põhjal on tal vastavat funktsionaalsust kasulik osta). Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , ,

LOE EDASI »

Enne kui hakata rääkima kuidas tarkvara kvaliteet kaob, tuleks vaadata, mis see on ja kuidas see projektijuhtimise kolmnurgaga seotud on.

Mis on tarkvara kvaliteet?

Tarkvara kvaliteet jaguneb kaheks: toote ja struktuuriline kvaliteet. Esimese puhul võetakse vaatluse alla vastavus nõuetele, terviklikkus, kasutatavus, dokumenteeritus ja veatus. Teisel puhul võetakse vaatluse alla arhitektuuri paindlikus, lähtekoodi loetavus, haldamise kergus, ressursside kasutus ja laiendatavus [Wiki]. Loe edasi »

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » ,

LOE EDASI »