Straipsniai

Krioklio metodas versus Scrum ir Kanban

Kas nežino IT aplinkoje seniai pažįstamo ir dažnai „prakeikto“ projektų valdymo su krioklio metodu. Pagal jį gana išsamioje išankstinėje koncepcijoje pirmiausia sudaromas krūvių sąrašas, kuris aprašo reikalavimus projektui. Techninis šių reikalavimų vertimas vyksta pareigų sąraše, kuris pagal poreikį dar gali būti papildomas išsamesnėmis koncepcijomis. Tačiau dažnai praeina daug savaičių, netgi mėnesių, kol pagal sukurtus dokumentus gali būti pradėtas tikrasis programavimas.

Tuo tarpu šis veikimo metodas turi ženklų minusą, kuris praeityje vis naujai būdavo daromas: ne taip jau nereikšminga reikalavimų dalis projekto pradžioje yra arba dar nežinomi arba juos galima tik grubiai apibrėžti ir paaiškinti, kadangi dėl didėjančio sudėtingumo tinklo srityje dažnai tik projekto eigoje paaiškėja visi techniniai reikalavimai ir gali būti pritaikomi.

Be to, dažnai dėl besikeičiančių išorinių faktorių arba rinkos aplinkybių, beveik visada yra reikalingų pataisymų, kurių pasekoje daugumoje atvejų rezultatas atrodo arba turi atrodyti visiškai kitaip nei tai buvo suplanuota koncepcijos pradžioje. Jau prieš kelis metus ši aplinkybė buvo priežastis galvoti apie naujus projektų valdymo metodus, kurie teiktų daugiau lankstumo ir galiausiai daugiau saugumo visiems dalyvaujantiems: gimė agile projektų valdymas ir su augančia dinamika, ypač tinklo aplinkoje, padidėjo šių projektų valdymo metodų paklausa ir reikšmė. (Šaltinis: http://www.scrumalliance.org).

Tuo tarpu paskutiniu laiku labiausiai įsitvirtino Scrum ir Kanban.

Šaltinis: https://www.techdivision.com/_Resources/Persistent/a90c984a454ba0b8478694b83f7a8822514b8fc8/Agiles-PM-Whitepaper0502.pdf

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Projektų valdymo metodų kombinacija

Klasikinis būdas su Agile sukelia sinergijos efektą

Teiginys: Abiejų metodų kombinacija yra ideali. Galioja šūkis: viskas savo laiku ir visuomet tada, kai tinka.

Klasikinio projektų valdymo elementai galėtų ženkliai palengvinti agile metodų įvedimą ir pritaikymą. Taip rodo patirtis, kad klasikiniai laipteliai, kaip aiškiai suformuluoti tikslai, laikotarpiai arba terminų ir biudžeto nurodymai dažnai sutinkami teigiamai. Jie tarnauja visiems dalyvaujantiems kaip svarbi orientavimosi pagalba, taip pat vadovybei.

Tačiau Agile ir Klasikinį būdą galima kombinuoti. Vienoje ar kitoje vietoje aišku reikia patobulinti, pavyzdžiui ta prasme, kad įprastas ataskaitų pateikimas programavimo lygyje įgalina ir iteratyvius apatinių lygių procesus (ką dažnai naudojami krioklio metodai nebūtinai palengvina).

Jei agile ir klasikinė sinergija pavyksta, gali išsivystyti idealus procesas, kuris greitai atneša rezultatus ir intensyviau įtraukia dalyvaujančius bei veda lik didesnio dalyvaujančių projekte pasitenkinimo nei koks kitas procesas.

Apibendrintai

Agile metodai yra kiekvieno projektų vadovo ir atsakingo už projektą „Must have“. Jie yra naudingos pagalbinės priemonės, kai kalba eina apie tai, pasitikti projekto aplinkos iššūkius, kurie linkę nuolat kisti.

Daug pavyzdžių tiesa rodo, kad konkretus įgyvendinimas projekto kasdienybėje ne visai paprastas. Atsargus dozavimas pradžiai ir gera integracija į atskiros įmonės projekto valdymo kultūrą yra svarbūs sėkmės faktoriai.

Centrinis klausimas dalyvaujantiems projekte, susijęs su agile metodais, yra ne tai, ar juos reikia panaudoti ar ne, bet greičiau, ar ir kaip agile projekto aplinka gali būti prasmingai valdoma. Evoliucija vietoj revoliucijos – sutrumpinus – ligi šiol labiausiai sėkmę nešantis metodas.

Šaltinis: http://www.computerwoche.de/a/sieben-thesen-zum-agilen-projekt-management,2537362

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Agile metodai labiau tinka mažiems projektams

Mažiau yra daugiau

Teiginys: Agile metodai labiau tinka mažiems projektams.

Agile valdomi projekto kolektyvai turėtų turėti ne daugiau nei dešimt darbuotojų. Didesniuose kolektyvuose dalyvaujančios rolės turi būti įsisavintos ir saugiai pritaikomos. Bendrai pažiūrėjus yra naudinga, kai atskiri kolektyvo dalyviai yra susipažinę su agile metodika. Priežastis: daug labiau nei kiekvienas kitas metodas agile projektų valdymas atveria galimybę, nuo prototipų kūrimo pereiti tiesiai prie vėlesnių vartotojų reikalavimų – o ne plėtoti projektą pro šalį.

Agile projektų valdymas teikia lankstumo

Teiginys: ypač situacijose su neaiškiais reikalavimais agile metodai gali būti naudingi.

Ne tik projekto dydis yra lemiamas kriterijus, ir pradinė situacija gali būti prieš arba už agile metodų pritaikymą. Kadangi tuo tarpu, kai klasikiniai metodai dėl geresnio planavimo ir geresnio kontroliavimo labiau tinka dideliems projektams ir didesnės apimties programoms, agile metodai gali būti naudingi, kai reikalavimai (dar) yra neaiškūs arba ypač greitai keičiasi.

Projektas yra nelygus projektui

Teiginys: Agile projektų valdymas yra ne vien tik geras ar blogas. Tai yra tam tikromis sąlygomis prasmingas veikimo modelis.

Kiekvienas projektas yra kitoks, kiekviena aplinka turi savo dinamiką. Vis dėlto yra kriterijai, kurie nurodo, ar projektas tinka agile metodikai ir kokios kliūtys slypi agile projektų valdyme. Kiekviena įmonė turėtų iškelti sau sekančius klausimus:

  • Ar projektas arba įmonė randasi aplinkoje su sudėtingais produktais, neaiškumais ir dažnai besikeičiančiais reikalavimais?
  • Ar bendrovė turi reikalingas žinias ir personalą?

  • Kaip agile metodika sutampa su įprasta įmonės ir vadovavimo kultūra?

Šaltinis: http://www.computerwoche.de/a/sieben-thesen-zum-agilen-projekt-management,2537362

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Daugiau pasitikėjimo, mažiau kontrolės.

Teiginys: Agile projektų valdymas kelia didelius reikalavimus dalyvaujantiems projekte ir reikalauja vadovybės pasitikėjimo.

Agile projektų valdymas ir juo besiremiantis procesas kaip Scrum dirba su save kontroliuojančiais kolektyvais, nustatytomis rolėmis, kliento integracija ir tiksliais darbo ciklais (time boxes).

Projekto kolektyvas ir vadovybė turi pasikliauti visišku savarankiškumu. Vadovybei tai reiškia: ji turi daugiau galvoti į priekį (pavyzdžiui, kas liečia reikalavimų svarbos nustatymą) ir tinkamu momentu paleisti vadžias iš rankų. Darbuotojams tai reiškia: savarankišką darbą, daugiau atsakomybės, tačiau ir daugiau skaidrumo, kas liečia savo darbo našumą. Kadangi agile valdomame projekte pagal programavimo našumą kiekvieną dieną galima matyti, ką atskiras darbuotojas nuveikė dėl bendros sėkmės. Klasikiniame projekte atskiras darbuotojas gali labiau pasislėpti už kolektyvo rezultatų.

Neužtenka to, kad visa tai dažniausiai yra nauja ir neįprasta. Didžiajai daliai įmonių tai reiškia naują įmonės kultūrą, kuri kelia klausimus:

  • Ar atskiros funkcijos gali būti kompetentingai atliekamos?
  • Ar darbuotojai tam tinkami ir kvalifikuoti?

  • Ar klientų santykiai yra pribrendę šiam procesui, ar abi pusės pasitiki viena kita?

Agile projektų metodų naudojimas turi pasekmes – personalo vystymuisi ir vadovavimo kultūrai. Kadangi iš vienos pusės agile valdomi (daliniai) projektai turi būti vedami patyrusių projektų vadovų (arba taip vadinamų Scrum meistrų), dalyvaujantys asmenys ir suinteresuotos šalys apmokyti ir šalia projekto koučinami. Iš kitos pusės agile požiūris reikalauja savikontrolės ir valdymo. Tai atitinkamai reiškia kontrolės netekimą ir persiorientavimą jėgų santykiuose ir įmonės hierarchijoje. O tuo pagal patirtį yra ne iškart vis dalyvaujantys suinteresuoti.

Šaltinis: http://www.computerwoche.de/a/sieben-thesen-zum-agilen-projekt-management,2537362

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Agile projektų valdymo sprogstamumas

IT projektai tampa vis sudėtingesni

Teiginys: auganti paklausa agile projektų valdymo metodams kaip pavyzdžiui Scrum yra didžiulio sudėtingumo kilimo ypač IT projektuose pasekmė.

Projekto darbuotojai, kurie darbuojasi jau ilgiau, žino, apie ką eina kalba. Klientai vis dažniau ir vis greičiau keičia savo reikalavimus. Tačiau ir vien projekto turinio sudėtingumas ir tikslai vis didina inovatyvių veikimo būdų poreikį . Agile projektų valdymo metodų su veikimo modeliais kaip Scrum privalumai yra aiškiai matomi. Jie daug labiau nei klasikiniai metodai siūlo galimybę nuo pat pradžių įtraukti klientą į procesą . Tai ne tik padidina projekto sėkmės tikimybę, bet ir kolektyvo pasitenkinimą.

Agile projektų valdymas yra sprogstamas

Teiginys: nors agile metodai turi daug privalumų – pavyzdžiui greitesnius rezultatus ir daugiau klientų pasitenkinimo, toli gražu ne visos įmonės tam tinkamos.

Save kontroliuojantys kolektyvai ir didesnė projekto vykdymo laisvė yra sprogstama įmonės ramybei. Daug besitęsiančių iteracijų ir laikini prototipai neveda automatiškai link norimos greitos sėkmės, bet ir gali – dėl nuolatinių papildomų reikalavimų – skatinti nusivylimą ir stagnaciją.

Agile projektų valdymo metodų pritaikymas yra daugiau nei grynas įrankis, jie reikalauja mentaliteto ir užsakovų, suinteresuotų šalių ir vadovybės mąstymo kitimo. Apie šį agile projektų valdymo „politinį“ diapazoną visi dalyvaujantys turi žinoti iš anksto. Kitaip tai greitai reikš katastrofą.

Šaltinis: http://www.computerwoche.de/a/sieben-thesen-zum-agilen-projekt-management,2537362

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

IT projektai

IT projektai tampa vis sudėtingesni. Šalia klasikinių procesų vadovai projektų valdyme vis dažniau naudoja agile projektų valdymą kaip pavyzdžiui Scrum. Tačiau atsargiai! IT sistemą įvesti agile reikalauja naujo mąstymo.

Vis daugiau įmonių norėtų – ir privalo – būti agile, ir projektų valdyme. Tačiau nors šis metodas atrodo turi savotišką traukos galią, dauguma projektų vadovų baiminasi griebtis šių priemonių, kai eina kalba apie konkretų įgyvendinimą. Atsarga dažniausiai yra pagrįsta. Kadangi toli gražu ne kiekvienas projektas ir tuo labiau ne kiekviena įmonė yra tinkami taip vadinamam pačiam save kontroliuojančiam metodui.

Pavyzdys: didelė įmonė planuoja programą naujos IT sistemos vertinimui, programavimui ir įvedimui. Programa su 200 dalyvaujančių darbuotojų dalinama į dešimt projektų, kiekvienas iš jų su trim daliniais projektais. Devyniuose projektuose naudojamas klasikinis projektų valdymas, atskiruose daliniuose projektuose ir agile metodai. Dešimtas planas su 30 milijonų eurų biudžeto apimtimi yra pilnai valdomas agile.

Tarpinis balansas po trijų metų parodo sekančius rezultatus: devyni pirmoje eilėje klasikiniu būdu valdomi projektai yra visai sėkmingi. Tiesa klasikinis projektų planavimas ir iteratyvus, agile procesas daliniuose projektuose yra ne taip paprasta, kas liečia laiko planavimą ir vientisas ataskaitas, tačiau pabaigoje viskas dažniausiai funkcionuoja.

Vienintelis pralaimėjęs yra pilnai agile vestas projektas. Viso proceso metu jis kelia klausimų dėl neaiškaus išlaidų planavimo, nuolatinių reikalavimų dėl biudžeto ir neskaidraus laiko planavimo ir galų gale išsivysto iki rizikos faktoriaus visam išleidimo planavimui. Konkrečiame projekte buvo labai nukrypta nuo pradinio laiko planavimo.

Šaltinis: http://www.computerwoche.de/a/sieben-thesen-zum-agilen-projekt-management,2537362

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Scrum apibendrintai

Susirinkimai ir atviri penktadieniai

Susirinkimai Scrum nėra protokolai „iš apačios“ projektų vadovui „viršuje“. Jie tarnauja kaip viso kolektyvo informacijos šaltinis. Kiekvienas gali kasdieniame susirinkime pasakyti, ką jis padarė, ką reikės pradėti toliau ir taip pat, kas galbūt jį užlaikė. Čia įsimaišo ir Scrum meistras. Jis pasirūpina tuo, kad dėmesio centras susirinkimo metu nedingtų – pavyzdžiui todėl, kad kalba nenukryptų link sugedusio kavos aparato. AOE media taip pat įvedė specialias retrospektyvos formas. Prie to priklauso atviri penktadieniai, kurie būna kas ketvirtį metų pagal įvairius metodus, pavyzdžiui kaip atvira erdvė. Pavyzdžiui paskutinio atviro penktadienio metu darbuotojai aptarė, kokias galimybes AOE siūlo atsiliepimams, atvirumui ir skaidrumui arba kaip galima patraukliau organizuoti serviso kolektyvo darbą. Iš to reguliariai susidarydavo darbo grupės.

Apibendrinimas

Kas nori įvesti Scrum, tam neužtenka vien skaityti knygas: aišku Scrum ir Kanban pagrindai yra lengvai suprantami. Drausmingas įvedimas nėra taip lengvai įgyvendinamas. Tačiau tik jis galiausiai veda į „laisvę“ ir ištraukia iš klasikinio projektų valdymo chaoso. Apsimoka apmokyti (klasikinius) projektų vadovus, kolektyvą ir klientus. Ir Scrum koučeris gali būti naudingas. Scrum yra iš esmės daugiau nei naujas programinės įrangos arba produkto kūrimo instrumentas: Scrum veda link paradigmų kaitos, kuri reikalauja mąstymo pasikeitimo tiek iš viso kolektyvo tiek iš klientų. Sąlyga įvesti agile plėtrą kaip įmonės kultūrą, yra drąsa nuolatiniam pasikeitimui, mokymuisi iš klaidų ir noras pagerinti procesus. Esmė: visi darbuotojai, ne tik vadovybė, turi dalyvauti. Tik tuomet agile plėtra įmonėje bus įgyvendinta.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/2/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Kada naudoti Scrum, kada Kanban?

AOE media įvedė ir Kanban: Tam yra skirta daug iškabų su daugybe skirtingų dizainų ir daugybe skilčių. Pradžioje kolektyvai dar neturėjo daug patirties, kada koks metodas yra naudotinas: todėl naudojo Scrum ir Kanban paraleliai. Taip buvo galima labai gerai palyginti, koks metodas kokiam kolektyvui tiko geriausiai. Kanban veda link ženklių pagerėjimų kolektyvuose, kurie dirba ne tik su projektu, su nuolatinėmis, blogai planuojamomis užduotimis ir su mažesniais projektais, kurių negalima dalinti į iteracijas. Dideliems, sudėtingiems užsakymams ir ypač ilgalaikiams projektams labiau tinka Scrum.

Savęs motyvacija ir skaidrumas

AOE media įmonės vadovybė ir programuotojai tuo pačiu atrado agile vystymąsi sau. Pionieriai iš įvairių įmonės skyrių bendrai susikūrė agile metodų įvedimą, kurie stipriai susiję su savęs motyvavimu ir apsisprendimu ir taip labai tinka prie įmonės mažos hierarchijos ir agentūros vertybių. Agile vystymosi metu vadovybė vis daugiau mąstė apie vidinius veiksnius kaip dalyvavimas, atsakomybė arba motyvacija, kurie kyla iš asmens arba užduoties.

Kad darbuotojai savo užduotis – kaip Scrum ir Kanban – gali rinktis iš projekto patys, veda link didesnio pasitenkinimo darbu ir nuostabių rezultatų. Ypač Scrum įgalina didelį skaidrumą. Iš vienos pusės kolektyve, iš kitos klientui: išleidimo planai reguliarių aktualizavimų kiekvienos iteracijos pabaigoje dėka nebėra tylus noras, bet jau realybė. Ir taip tęsiasi iki sutarties formavimo: AOE media siūlo klientams pavyzdžiui savo sukurtą agile pastovių kainų sutartį.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/2/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Tipiški ScrumButs

AOE media agentūra jau 2007-ais metais pradėjo įgyvendinti pirmus projektus su agile metodų pagalba ir padarė pirmą praktinę patirtį su planavimais, atsiliepimais ir retrospektyvomis – ir pasiekė pirmus rezultatus. Retrospektyvos greitai parodė, kad Scrum galima nuolat gerinti. Tačiau šioje vietoje reikėtų būti atsargiems: kas įveda Scrum, tam dažnai kyla didelė pagunda, tiesiogiai daryti savo Scrum pakeitimus (ScrumButs) ir svarbius elementus pašalinti dėl racionalumo. Tačiau dažnai pasirodo, kad paprasčiausiai buvo nesuprasta šių elementų svarba, kurie yra svarbūs sėkmei pasiekti. Tipiški ScrumBut pavyzdžiai yra:

Mes naudojame Scrum, tačiau mes…

  • atsisakome Scrum meistro, kadangi kolektyvas per mažas.

  • mums nereikia sudėtingo atskirų užduočių apimties vertinimo.

  • prailginame sprintus, kol pasiekiame tikslą.

  • apsieiname be retrospektyvų.

Absoliutus Scrum privalumas yra reguliarūs, nustatyti laikotarpiai (Timeboxes). Jeigu darbas nustatytos iteracijos metu nesuspėjamas atlikti, kolektyvas jokiu būdu neturėtų prailginti laikotarpio. Daugiau reikėtų galvoti apie tai, kaip suskirstyti projektą į mažesnius prieaugius. Šūkis yra: „Kaip padalinti dramblį?“. Kita rizika yra, kad Scrum meistras elgsis kaip projekto vadovas ir įsivaizduos save kolektyvo vadovu. Tačiau Scrum atveju kolektyvas yra autoritetas. Šalia to klientas turi būti pasiruošęs agile plėtrai – taigi nebegyventi ir nebegalvoti plano varoma plėtra, bet perimti produkto savininko rolę. Jei tai neįvyksta, projektą galima tik sunkiai įgyvendinti su Scrum pagalba. Visa tai priveda prie to, kad organizacijos (tiek kliento, tiek paslaugų teikėjo pusėje) su blogomis Scrum interpretacijomis greitai linksta link to, metodą mesti kaip netinkamą per bortą ir padaryti atsakingu už projekto nepasisekimą. Tačiau Scrum reikia būtinai įgyvendinti tiksliai. Vėliau galima padaryti prasmingus, įmonei tinkamus pakeitimus. Šie neturėtų būti tokie radikalūs kaip ScrumBut, tačiau pavyzdžiui galima pritaikyti Scrum meistro rolę. AOE media pavyzdžiui rado savo kelią ir žiūri į Scrum kaip į pagrindą, kurį galima pritaikyti skirtingiems projektams ir situacijoms.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/2/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

 

Scrum ir Kanban

Kaip veikia Scrum?

Kiekvienas Scrum projektas prasideda tuo, kad taip vadinamas produkto savininkas sukuria produkto neatliktų darbų sąrašą, pirmenybinį užduočių sąrašą kolektyvui. Jei produkto savininkas yra netiesiogiai klientas, šis gali užduotį perleisti ir proxy produkto savininkui, kurį pasiūlo užsakovas. Visos užduotys sudarytos iš sprintų (iteracijų), tiksliai nustatytų dviejų savaičių laikotarpių. Planavimo fazėje – sprinto „planavime“ – kolektyvas pasiima užduotis iš produkto neatliktų užduočių sąrašo, kurias realiai galima įgyvendinti nustatytu laiku. Bendrai nusprendžiama, kaip bus dirbama (kolektyvo susitarimas).

Kai produkto savininkas yra atsakingas už projekto sėkmę ir investicijų grįžimą, Scrum meistras rūpinasi tuo, kad visi suprastų procesą ir jo laikytųsi. Taip pat jis prižiūri, kad kolektyvas galėtų netrukdomai dirbti. Kiekvieno sprinto rezultatas yra projekto prieaugis (pavyzdžiui veikiantis kliento prisijungimas), kurio kokybė atlaikė peržiūros procesą ir kurį galima tiekti klientui. Toliau sekanti retrospektyva tikrina pabaigtą sprintą, atsižvelgiant į Scrum proceso kokybę: Kaip jaučiasi kolektyvas? Ar veikia priemonės? Kito sprinto pradžioje kolektyvas renkasi sekančias užduotis iš produkto neatliktų darbų sąrašo, kurias produkto savininkas nustatė kaip ypatingai svarbias – ir sekantis sprintas prasideda.

Kaip galima pritaikyti Kanban?

Daugybė agentūrų naudoja Scrum ir Kanban skirtingiems projektams ir kolektyvams. Priešingai nei Scrum, Kanban yra metodas, kuris turi užtikrinti nepertraukiamą darbo eigą (Flow). Tam yra vizualizuojamos visos užduotys ir procesai (taigi ir problemos, kurios šiom trukdo) ir daromos suprantamomis. Tai vyksta iškabos pagalba, kuri yra padalinta į eilutes ir skiltis (Lanes). Į šią iškabą keliauja visos užduotys bilietų virš atskirų skilčių forma. Kiekviena skiltis reiškia darbo žingsnį. Taip projekto dalyviai gali bet kuriuo momentu matyti, koks statusas yra priskirtas kokiai užduočiai.

Šalia to yra riba paraleliai vykstančioms užduotims. Tai reiškia, kad skiltyje „Plėtra“ pavyzdžiui vienu metu gali būti tik keturi bilietai. Tikslas yra, kad kiekvienas darbuotojas pagal galimybes dirbtų tik su viena užduotimi, o ne su keliomis paraleliai. Už to slypi darbo eigos mintis: bilietai turi eiti pagal galimybes vienodai ir be didelių laukimo pauzių arba blokadų per neatliktų užduočių sąrašą. Kas trukdo darbo eigą, yra analizuojama ir galimai šalinama. Šiuo būdu galima vizualizuoti proceso problemas ir jas viena po kitos išspręsti. Priešingai nei Scrum, Kanban vizualizuoja tik aktualų procesą, tačiau šio reikšmingai nekeičia.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime