Agile

Agile - tai toksai naujesnis projektų valdymo būdas, atsiradęs po to, kai IT srityje visi pamatė, kad projektų valdymas kažkodėl arba nevyksta, arba pavirsta į kažkokią nesąmonę, kuri dažnai ima ir nesuveikia. Arba suveikia visiškai ne taip, kaip reikia.

Nors ir paremtas labai geromis idėjomis, Agile projektų valdymas dabar yra privisęs visiškai atvirų ir nemokšiškų šarlatanų, panašiai, kaip ir Lean procesų gerinimas. Taigi, dažnai būna taip, kad daugiametis proto knisikas, išlindęs iš kokio nors klozeto, pasakoja visiems, kaip esą prie Agile nieko nereikia planuoti ir nereikia nieko normalaus daryti, nes esą tai trukdo darbui, ar skleidžia kitus absurdus.

Išties, nors dabar visiškų šarlatanų Agile srityje yra keleriopai daugiau, nei adekvačių projektų vadovų, pačios Agile idėjos turi racionalaus pagrindo. Svarbu tiktai suprasti, iš kur ir kaip tos idėjos atsirado, ir kokie tų idėjų apribojimai.

Klasikinio IT projektų valdymo problemos

Jau ne pirmą dešimtmetį daugelis pastebėdavo, kad IT projektai turi kraštutinai stiprias tendencijas būti pavėluotais ir nesėkmingais, o dažnai ir patirti visškai pilną krachą, kai išvis negaunamas rezultatas. Giluminės priežastys čia buvo trys, ir visos labai paprastos, tačiau sunkiai suvaldomos:

• Visokie kompiuterastai ir ypač programuotojai yra tokie atšokę nuo realybės, kad visiškai nesvuvokia jokių kliento poreikių, tiesiog iš principo, nes yra tokiame kosTmose, kad ne kiekvienas įprastas žmogus ten ir su kokiais nors psichodelikų tipo narkotikais sugebėtų pakliūti. Tai reiškia, kad nesvarbu, kas ir kaip, su IT specais susišnekėti yra baisiai sunku, o dažnai - tiesiog iš principo neįmanoma.
• Gero lygio projektų vadovai, kurie, negana to, dar mokėtų ir susikalbėti su tais IT specialistais tų IT specialistų kalba - tiek mažai, kad tik reta kompanija kada nors sau tokį gali gauti. Realiai geras ir sėkmingas projektų vadovas, dirbantis su IT specialistais, yra tokia retenybė, kad tai yra kaip kokie unikumai, kurių nesigauna rasti.
• Tam, kad softas būtų sėkmingas, būtina ne tik išgirsti kliento poreikius, ir ne tik suvaldyti projektą, bet ir suprasti, koksai procesas yra pas klientą. Įprasti projektų vadovai to irgi negali padaryti, o jau IT specialistai - dar menkiau. Tokiam žinojimui būtinas to lygio įsigilinimas į kliento veiklą, kad galėtum tai veiklai pats vadovauti. Praktikoje tokio įsigilinimo nebūna.

Praktikoje iš dviejų aukščiau minėtų problemų kyla įprasta praktika:

• Projektų vadovas, neturintis visiškai tiesioginių, realių IT ir ypač programavimo žinių (t.y., pats neatprogramavęs gan dideliais kiekiais) visiškai negali įsivertinti realaus klientų prašymo sudėtingumo, todėl planuojasi vėjus.
• Programuotojai, kurie imami konsultavimuisi - visiškai nesuvokia klientų procesų ar klientų kalbos, todėl supranta belenką belenkaip atbulai.
• Paskui programuotojai pasakoja vėjus projektų vadovui, o jis iš principo negali ir nesugeba nieko patikrinti
• Dar paskui paaiškėja, kad projekte buvo padaryta visiškai ne tai, ko reikėjo klientui
• Galų gale, po daugelio perdarymų, taisymų ir bandymų kažkaip išsisukti, projektas sužlunga

Kadangi dažniausiai viskas strigdavo, didelė dalis įmonių nueidavo į perteklinį biurokratizavimą, kur atsirasdavo nenormaliai griežti reikalavimai naudoti visokius specialius įrankius, daryti viską pagal griežtus (bet nebūtinai teisingai apibrėžtus) procesus, rašyti absurdiškus kiekius dokumentacijos (į kurios gerumą paskui niekas nežiūrėdavo), į viską įsiterpdavo dar ir parazitinio tipo teisininkai, o galų gale projektus imdavo valdyti žmonės, turintys anankastinį asmenybės sutrikimą.

Ta nusistovėjusia nesėkmių praktika buvo nepatenkinti ir projektų vadovai, ir klientai, ir patys programuotojai. Bet kadangi nei klientai, nei projektų vadovai neretai sprendimų nerasdavo, sprendimų paieška užsiėmė ir programuotojai. Ir programuotojai tų sprendimų ėmė ieškoti, netgi nesuprasdami, ką ir apie ką išvis jie bendrauja su klientais.

Taigi, Agile manifestas gavosi visiškai naivus ir nekompetentingas, tačiau visgi naudingas IT specialistų, ypač programuotojų bandymas išspręsti tas aukščiau minėtas problemas. Kadangi patys programuotojai nesuprato, kas ir kodėl daroma projektų valdyme ir kodėl tam tikri procesai organizuojami tam tikru būdu, jie padarė klaidingų prielaidų apie problemų kilmę, tačiau kai kurie paprasti jų sprendimai visgi labai ryškiai pagerino rezultatus, bendraujant su klientais.

Agile Manifestas

Agile Manifestas, nuo kurio prasidėjo Agile projektų valdymas, pateikiamas žemiau.

Mes atveriame geresnius kelius programinės įrangos kūrimui, patys tą darydami ir kitiems irgi padėdami.

Dirbdami šį darbą, mes atradome šias vertybes:

Asmenybės ir bendravimas (interakcijos) svarbiau, nei procesai ir įrankiai

Darbinga programinė įranga svarbiau, nei išsami dokumentacija

Bendradarbiavimas su klientu svarbiau, nei derybos dėl sutarčių

Reagavimas į pokyčius svarbiau, nei nenukrypstamas plano vykdymas

Tai reiškia, kad nors yra vertė tuose dešiniuose dalykuose, kairėje esančius dalykus mes vertiname labiau.

Apie Agile Manifesto principus

Skaitant Agile manifestą labai svarbu suprasti, kad dešinėje pusėje esantys dalykai yra svarbūs, o neretai (visuose bent kiek didesniuose projektuose) yra ir visiškai būtini: reikia ir sekti procesus, ir naudoti gerus įrankius, ir turėti pakankamą dokumentaciją, ir sudaryti tinkamas sutartis, ir sugebėti planuoti, o paskui - vadovautis planu. Esminis dalykas - suvokti, kad ne vien šiais dalykais paremti yra laimėjimai, todėl perteklinis užsibiurokratizavimas ir atšokimas nuo realybės prie gero nepriveda.

Svarbu suprasti, kad jokie procesai ir įrankiai nepakeis normalaus žmonių susišnekėjimo. Todėl susišnekėjimas (ir įvairūs netiesioginiai, nehierarchiniai ir nekontroliuojami ryšiai) projekto sėkmę ar nesėkmę nulemia labiau, nei procesai ir kontrolės įrankiai.

Svarbu suprasti, kad dokumentacija, kad ir kokia kritiškai svarbi didelių projektų vykdymui ir palaikymui, nėra programa. Jei programa neveikia, dokumentacija už ją neveiks.

Svarbu suprasti, kad jei klientas bus priešiškas, tai jokios sutartys nepadės uždirbti pinigų, o tik virs beprasmiais ir nuostolingais teisminiais ginčais. Tuo pat metu geras bendradarbiavimas su klientu ir realių jo norų vykdymas - tai dažniausiai gan stipri garantija, kad klientas bus patenkintas ir sutartinių problemų nekils.

Svarbu suprasti, kad jei paaiškės, kad plane nebuvo numatyta kažkas, kas buvo svarbu ir išlindo svarbūs dalykai - tai reikia perplanuoti ir juos numatyti. Idiotiškai bukas veikimas tiksliai pagal planą - gana neretas, bet beveik visada baigiasi prastai. Todėl planavimas turi būti su vėlesniu koregavimu ir su stipriu realybės pajautimu.

12 Agile principų

Kadangi vėliau daugelis nesuprasdavo tų bendrų Agile Manifesto idėjų, tai kiti iš gudresnių programuotojų ir projektų vadovų viską truputį padetalizavo ir papildė šiaip įvariomis geromis praktikomis. Gavosi gal truputį mažiau naivus, labiau empirine praktika pagrįstas idėjų rinkinys. Tos idėjos, jas smarkiau detalizuojant, jau gali virsti kažkuo artimesiu šiokioms tokioms projektų valdymo metodologijoms.

Štai čia tie 12 Agile principų:

1. Mūsų aukščiausias prioritetas yra patenkinti klientą, jam anksti ir nuolat suteikiant vertingą programinę įrangą
2. Priimame reikalavimų pokyčius, netgi vėlyvose kūrimo stadijose. Agile procesai įkinko pokyčius tam, kad padidintų konkurencingumą
3. Suteikiame darbingą programinę įrangą dažnai, su tarpais, kurių ilgis nuo kelių savaičių iki kelių mėnesiu, su prioritetu trumpesniems periodams
4. Verslo žmonės ir programuotojai turi kasdien dirbti kartu visą laiką, kiek tęsiasi projektas
5. Projektai turi būti kuriami aplinkui motyvuotus darbuotojus. Duokime jiems reikalingą aplinką ir palaikymą, pasitikėkime jais ir darbas bus padarytas
6. Efektyviausias ir mažiausiai sąnaudų naudojantis informacijos perdavimo metodas į ir iš programavimo grupės - tai gyvas pokalbis veidas į veidą
7. Dirbanti programinė įranga yra pirminis rodiklis (matavimo vienetas), pagal kurį turi būti vertinama darbų eiga
8. Agile procesai iškelia didelę išliekamąją vertę. Tai reiškia, kad projekto sponsoriai, programuotojai ir naudotojai turi sugebėti bendradarbiauti neribotą laiką.
9. Nuolatinis dėmesys techniniam tobulumui ir geram dizainui padidina programinės įrangos pokyčių galimybes
10. Paprastumas - menas maksimizuoti (nereikalingo) darbo nedarymą - yra esminis
11. Geriausios architektūros, reikalavimai ir dizainai iškyla iš save pačias organizuojančių grupių
12. Reguliariais laiko intervalais grupė peržiūri savo darbą, kad galėtų dirbti efektyviau, daro pokyčius ir atitinkamai koreguoja savo elgesį