{"id":207,"date":"2011-09-04T11:00:00","date_gmt":"2011-09-04T09:00:00","guid":{"rendered":"https:\/\/ecg.si\/clanki\/?p=207"},"modified":"2017-10-26T17:36:00","modified_gmt":"2017-10-26T15:36:00","slug":"agilno-projektno-vodenje","status":"publish","type":"post","link":"https:\/\/ecg.si\/clanki\/agilno-projektno-vodenje\/","title":{"rendered":"AGILNO PROJEKTNO VODENJE"},"content":{"rendered":"

Agilno projektno vodenje<\/strong><\/span><\/p>\n

Pri vsakem novem pristopu se pojavijo njegovi gore\u010di zagovorniki, pojavijo se tisti, ki trdijo, da je to pa\u010d \u0161e ena modna muha in pa seveda tisti, ki jim sploh ni mar za to. Ampak, ko gre za agilno projektno vodenje, bi morali biti pozorni vsi, ker gre za revolucijo v industriji za razvoj programske opreme.<\/span><\/p>\n

Prav zato se danes veliko podjetji, ki razvija programsko opremo, trudi biti \u010dim bolj agilnih. Kdo bi jim lahko zameril? Uspe\u0161ne agilne ekipe z ni\u017ejimi stro\u0161ki izdelajo kvalitetnej\u0161o programsko opremo, ki bolj ustreza uporabnikovim potrebam kot tradicionalne ekipe. Pa \u0161e, kdo si ne bi \u017eelel biti \u010dim bolj agilen? Saj se \u017ee sli\u0161i dobro.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Agilni manifesto<\/strong><\/span><\/p>\n

Prve agilne metodologije so se pri\u010dele pojavljati v 90-ih letih prej\u0161njega stoletja kot alternativa tradicionalnemu na\u010dinu vodenja projektov, ki temelji na treh napa\u010dnih in nerealnih predpostavkah: naro\u010dnik to\u010dno ve, kaj si \u017eeli; razvijalci to\u010dno vedo, kako to narediti; med izvajanjem projekta ne bo pri\u0161lo do sprememb. Februarja 2001 je sedemnajst strokovnjakov iz razli\u010dnih podro\u010dij, ki so se ukvarjali z agilnimi metodologijami napisalo tako imenovani agilni manifesto ter ustanovilo zdru\u017eenje Agile Software Development Alliance, ki so ga kasneje preimenovali v Agile Alliance.<\/span><\/p>\n

Potrebno je poudariti, da agilni manifesto ni metoda oz. skupek procesov in procedur, ki se jih moramo dr\u017eati. Agilni manifesto definira na\u010din razmi\u0161ljanja, ko gre za razvoj programske opreme in agilno projektno vodenje. Predpostavka, da \u010de uporablja\u0161 neko agilno metodo ali proces, potem si tudi agilen, je napa\u010dna.<\/span><\/p>\n

Agilni manifesto sestavljajo \u0161tirih vrednote in dvanajst na\u010del. V nadaljevanju so podrobneje razlo\u017eene vse \u0161tiri vrednote.<\/span><\/p>\n

    \n
  1. Posamezniki in njihovo sodelovanje<\/span> so pomembnej\u0161i od procesov in orodij.<\/strong> Zelo enostavno se je ujeti v dogmati\u010dno razpravo, katera orodja in procesi naj bi se uporabljali na projektu. Razvijalci so velikokrat navdu\u0161eni nad orodji in procesi, ker jim oboje ve\u010dinoma pomaga pri razvoju programske opreme. Lahko pa se zgodi, da sta ti dve stvari posameznikom v resnici v napoto in ovirata medsebojno komunikacijo. Izbrati moramo tak\u0161na orodja, ki pove\u010dajo u\u010dinkovitost posameznika in olaj\u0161ajo sodelovanje in komunikacijo. Najpomembnej\u0161i dejavnik na projektu so posamezniki ter sodelovanje med njimi in \u010de le-to ni u\u010dinkovito, tudi najbolj\u0161a orodja ter procesi ne bodo ni\u010d koristili.<\/span><\/li>\n
  2. \u00a0<\/span>Delujo\u010da programska oprema<\/span> je pomembnej\u0161a od obse\u017ene dokumentacije.<\/strong> Na agilnih projektih je delujo\u010da programska oprema najpomembnej\u0161e merilo napredka in statusa projekta. Manifesto ne trdi, da tehni\u010dna dokumentacija nima nobene koristne vrednosti. Pravi pa, da priprava natan\u010dne dokumentacije ne sme ovirati glavnega cilja projekta, in to je izdelava delujo\u010de programske opreme. \u010ce se to zgodi, je potrebno ustrezno zmanj\u0161ati koli\u010dino administrativnega dela in pisanja dokumentacije. Iskanje pravega razmerja med programiranjem in dokumentiranjem je umetnost in velikokrat razlog za frustracije razvijalcev. Glavna te\u017eava dokumentov je, da so stati\u010dni, napisani v nekem trenutku in zelo hitro izgubijo stik z realnim stanjem projekta. Zastareli dokumenti pa zvi\u0161ujejo stro\u0161ek in tveganje na projektu. Torej, dokumentacija naj se ne pi\u0161e samo zaradi nje same, ker je delujo\u010da programska oprema vrednej\u0161a in uporabnej\u0161a.<\/span><\/li>\n
  3. Sodelovanje z naro\u010dnikom<\/span> je pomembnej\u0161e od pogajanj glede pogodbe.<\/strong> Ve\u010dkrat sli\u0161imo kak\u0161nega razvijalca re\u010di \u201eStranka bo znorela, ampak dobila bo to\u010dno to, kar pi\u0161e v pogodbi.\u201c Pogodbe so pomembne in uporabne, zato si je za pripravo le-teh dobro vzeti dovolj \u010dasa. Te\u017eava pa je, \u010de to ovira u\u010dinkovito sodelovanje. Odnos med naro\u010dnikom in dobaviteljem je veliko bolj\u0161i, \u010de sta v partnerskem odnosu in se oba po\u010dutita varno. Na agilnih projektih naro\u010dnik dnevno sodeluje z razvojno ekipo in mora dati znati odgovoriti na vsa vpra\u0161anja razvijalcev. Ni dobro, \u010de morajo razvijalci ugibati, kaj si v resnici \u017eeli naro\u010dnik.<\/span><\/li>\n
  4. Prilagajanje spremembam <\/span>je pomembnej\u0161e od sledenja na\u010drtom.<\/strong> Priprava projektnega na\u010drta je pomemben proces, ki zajema popis nalog, vrstni red izvajanja le-teh ter identificiranje odvisnosti med posameznimi nalogami. Vendar sta inicialni projektni na\u010drt in realno dogajanje na projektu velikokrat precej razli\u010dna. Na\u010drt mora biti fleksibilen in pripravljen na prilagajanje spremembam, ki so neizogibne in se nima smisla boriti proti njim.<\/span><\/li>\n<\/ol>\n

    \u00a0<\/span><\/p>\n

    Manifesto dodatno razlo\u017ei zgornje vrednote z naslednjo trditvijo \u201e\u010ceprav imajo zapisi na desni neko vrednost, bolj cenimo zapise na levi\u201c.<\/span><\/p>\n

    Obstaja kar nekaj metod oz. ogrodij, ki temeljijo na agilni metodologiji. Bolj raz\u0161irjene med njimi so recimo Scrum, XP (eXtreme Programming), Kanban, Lean, FDD (Feature-Driven Development) in DSDM (Dynamic Systems Development Methods).<\/span><\/p>\n

    \u00a0<\/strong><\/span><\/p>\n

    Scrum<\/strong><\/span><\/p>\n

    Najbolj popularna agilna metoda se imenuje Scrum in je v resnici zelo enostaven pristop k vodenju kompleksnih projektov. Gre za iterativen in inkrementalen na\u010din dela, ki zagotavlja jasnost in preglednost vsem sodelujo\u010dim na projektu.<\/span><\/p>\n

    Na projektu, ki uporablja metodo Scrum, so vse stvari \u010dasovno omejene in zato tudi sam razvoj programske opreme poteka v \u010dasovno omejenih iteracijah oz. ciklih (Sprint). Vse naloge, ki jih je potrebno opraviti v celotnem projektu, se vodijo na prioritiziranem seznamu zahtev (Product Backlog). Na za\u010detku vsakega cikla ekipa sama dolo\u010di koli\u010dino dela, ki ga je sposobna opraviti v tej iteraciji (Sprint Planning) in se obve\u017ee, da bo naredila vse, kar je v njeni mo\u010di, da dose\u017ee zastavljeni cilj. Izbrane naloge se prenesejo na seznam zahtev tega cikla (Sprint Backlog). Vsak dan se izvede kratek sestanek (Daily Scrum), na katerem vsak \u010dlan ekipe pove, kaj je delal v\u010deraj, kaj bo delal jutri in ali ima pri delu kak\u0161ne te\u017eave. Na koncu vsakega cikla ekipa skupaj z naro\u010dnikom pregleda opravljeno delo (Sprint Review).<\/span><\/p>\n

    Naro\u010dnik dobi zaradi iterativnega na\u010dina dela ob koncu vsakega cikla delujo\u010do verzijo produkta (Potentionally Shippable Product), kar mo\u010dno izbolj\u0161a preglednost nad izvajanjem projekta in stanjem produkta. To naro\u010dniku omogo\u010di, da lahko redno in sproti podaja svoje mnenje o nastajajo\u010dem produktu ter tudi spreminja prioritete glede funkcionalnosti, ki se bo \u0161e razvijala in dodala k produktu. Ta poudarek na rednem ocenjevanju opravljenega dela veliko doprinese k priljubljenosti Scrum-a tako pri mened\u017eerjih kot pri razvijalcih.<\/span><\/p>\n

    Uporaba Scrum-a po vsem svetu skokovito raste, uporabljajo ga tudi podjetja, kot so Google, IBM, Siemens, Nokia, Philips, Microsoft, Yahoo!, Motorola, Xerox,…<\/span><\/p>\n

    \u00a0<\/span><\/p>\n

    VORANC KUTNIK<\/span><\/p>\n

    AGILSPOT D.O.O<\/span><\/p>\n

    DIREKTOR<\/span><\/p>\n

    E: voranc.kutnik@agilspot.si<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

    Agilno projektno vodenje Pri vsakem novem pristopu se pojavijo njegovi gore\u010di zagovorniki, pojavijo se tisti, ki trdijo, da je to pa\u010d \u0161e ena modna muha in pa seveda tisti, ki jim sploh ni mar za to. Ampak, ko gre za agilno projektno vodenje, bi morali biti pozorni vsi, ker gre za revolucijo v industriji za […]<\/p>\n","protected":false},"author":43,"featured_media":104,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[13],"_links":{"self":[{"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/posts\/207"}],"collection":[{"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/users\/43"}],"replies":[{"embeddable":true,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/comments?post=207"}],"version-history":[{"count":4,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/posts\/207\/revisions"}],"predecessor-version":[{"id":1302,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/posts\/207\/revisions\/1302"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/media\/104"}],"wp:attachment":[{"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/media?parent=207"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/categories?post=207"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ecg.si\/clanki\/wp-json\/wp\/v2\/tags?post=207"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}